Microblaze - seltsames Verhalten

[Philip (Gast)]

Hallo,

ich beobachte bei meinem Microblaze Sytem ein Verhalten, das mir absolut 
rätselhaft ist. Ich habe bisher nur eine einfache Testsoftware 
geschrieben, die ein bisschen LEDs blinken lässt und Messages per UART 
versendet. Bis gestern hat das alles wunderbar funktioniert. Jetzt kommt 
es immer wieder vor, dass sobald ich Änderungen am Code mache einfach 
gar nichts passiert, so als würde die Software "abschmieren". Es ist 
nicht möglich den Fehler auf irgendeinen Aufruf einzugrenzen. Ich kann 
Beispielsweise ausgehend von einem laufenden Stand einen leeren(d.h. 
Funktion macht nichts) Funktionsaufruf einfügen und nichts geht mehr. 
Kennt jemand ein solches Verhalten?
Das Einzige was mir dazu noch einfallen würde sind Timing-Probleme. 
Allerdings ist die Synthese ohne Fehler durchgelaufen...

[Uwe (Gast)]

Stack overflow ?!

[Philip (Gast)]

Nachdem ich meinen clock etwas überconstraint habe, ist das Problem weg. 
Also wohl doch Syntheseproblem...

[Duke Scarring (Gast)]

Philip schrieb:
> Nachdem ich meinen clock etwas überconstraint habe, ist das Problem weg.
> Also wohl doch Syntheseproblem...
Du hast eine seltsame Methode um Fehler zu beheben. Ich musste noch nie 
ein Design überconstrainen, damit es läuft. Auch nicht mit einem 
Microblaze.

Duke

[Philip (Gast)]

So ungewöhnlich find ich das nicht...
In diesem Fall habe ich allerdings versehentlich einen falschen 
Speed-Grade eingestellt :-)

[Philip (Gast)]

Jetzt muss ich das Thema doch nochmal aufgreifen...
Leider habe ich immer noch Probleme und offenbar stimmt was mit meiner 
Timing-Analyse nicht. Im Timing-Report finde ich bei der Timespec für 
meinen Systemtakt den Eintrag "0 paths analyzed".  An andere Stelle 
finde ich diesen Eintag:

 ================================================================================ 
 Timing constraint: PATH "TS_AXI_MB_FP_axi_intc_0_path" TIG; 
  540038 paths analyzed, 20717 endpoints analyzed, 0 failing endpoints 
  0 timing errors detected. (0 setup errors, 0 hold errors) 
 --------------------------------------------------------------------------------

In der nachfolgenden Pfad-Auflistung finde ich Pfade wieder, die ich 
eigentlich von der Systemtakt-Timspec erfasst werden sollten. Das TIG 
stammt nicht von mir, muss also automatisch generiert worden sein. Kann 
mir jemand erklären warum?

Im pcf-file finde ich den entsprechenden Eintrag:

 
PATH TS_AXI_MB_FP_axi_intc_0_path = FROM TIMEGRP "S_AXI_ACLK_axi_intc_0" TO
        TIMEGRP "Processor_clk_axi_intc_0";
PATH "TS_AXI_MB_FP_axi_intc_0_path" TIG;
ich diesen Eintag:

[Philip (Gast)]

Ich denke ich habe das Problem gelöst, auch wenn es mir immer noch etwas 
rätselhaft ist. Im MB-Design befindet sich ein Interrupt-Controller. 
Dieser hast einen Pin für den AXI- und einen für den Prozessor-Clk. 
Diese Pins waren beide mit dem selben 125 MHz Clk verbunden. Im 
Datenblatt des INTC steht, dass man wenn die Clk identisch sind den 
Prozessor-Clk auch weglassen kann und dann C_MB_CLK_NOT_CONNECTED = 1 
setzen soll. Das habe ich gemacht und damit verschwinden die TIGs im 
pcf-file.

[Georg A. (Gast)]

Vermutlich wollten die den Taktübergang AXI->MB nicht analysieren. Dumm 
nur, wenn beide Takte zusammenfallen, dann breitet sich das TIG auf 
alles aus. Deswegen gibts wohl die komische Option überhaupt :)

[Philip (Gast)]

Es steht aber leider nichts davon da, dass man das zwingend so machen 
muss. Hat mich jetzt einiges an Stunden und Nerven gekostet...