Vivado VIO zeigt irre werte aber design läuft

Für mich sieht das auf den ersten Blick nach 'timing violations' auf dem Datenbus aus. Wird am Microblaze ein (Timer-)Interrupt genutzt, der da ggf. dazwischenfunken kann?

Rick D. schrieb:

Für mich sieht das auf den ersten Blick nach 'timing violations' auf dem Datenbus aus. Wird am Microblaze ein (Timer-)Interrupt genutzt, der da ggf. dazwischenfunken kann?

VIO zeigt an an 10 ports:

• Reset signal generiert von MicroBlaze MCS
• mehrere 32 bit breite busse von Frequenz messung IP core

ALLE werte schwanken irre mit entweder alle null oder alle müll. Nur manchmal kommen manche werte richtig an.

Microblaze gibt es in system auch ist aber nicht mit VIO verbunden

Läuft der vio am selben takt wie der µblaze ? Wie wäre es mit ila statt vio ?

Der VIO läuft von configurations clock.

Hm, es gibt (gab?) einige Optionen für den config-clock beim bitgen. Ich persönlich würde nie den config-clock verwenden (weil extern) eher einen internen vpn der selben PLL/MMCM wie der µBlaze.

Bradward B. schrieb:

Läuft der vio am selben takt wie der µblaze ? Wie wäre es mit ila statt vio ?

Der VIO läuft von configurations clock.

Hm, es gibt (gab?) einige Optionen für den config-clock beim bitgen. Ich persönlich würde nie den config-clock verwenden (weil extern) eher einen internen vpn der selben PLL/MMCM wie der µBlaze.

das dumme ist der VIO läuft deswegen von config clock weil davon auch ein MicroBlaze MCS läuft der den Si5338 PLL programmiert. Das heisst das system clock kommt schon viel später als config clock. Und bisheute ist alles gelaufen OK. Heute habe dem VIO 2 ports hinzugefügt und seitdem gibt es problem.

Antti L. schrieb:

ein Microblaze design läuft, aber die interne werte die an VIO verbunden sind zeigen irre werte, so etwa in 4 sekunden zyklus. Fast alle null, dann random werte, und wieder meist nulls. Aber die werte können nicht stimmen da der design fehlerfrei weiterläuft. Ideen? Der VIO läuft von configurations clock.

Ich habe die VIO port anzahl wieder von 10 auf 8, dann geht plötzlich wieder alles normal. Keine Ahnung warum es bei 10 VIO ports nicht mehr ging.

Das ist doch erst mal gut, wobei ich meine, daß es weniger an der Portanzahl liegt, sondern an den internen Signalen, die an Port 9 und 10 lagen.

Mal diese beiden mit zweien von den ursprünglichen acht tauschen und schauen ob es geht. Wenn nicht, gibt es vielleicht 'ne hilfreiche warning beim P&R, vielleicht in Richtung Zusammenführung verschiedenener clock/reset domains o.ä..

Am vio selbst kann man ja nicht viel configurieren (siehe Anhang).

Oder der initial value im vio (bei OUT-Ports) passt nicht mit dem internen signal. Wobei ich annehme das an dem vio alles In-Ports sind ?!

Ohne die Trace der Werte gesehen zu haben, kann man da beliebig im Dunkeln stochern, mir faellt dazu ein:

• Unguenstige Abtastung (Aliasing), JTAG-Clock zu gering
• Schlichter Bug betr. Limite in der Anbindung an die BSCAN-Primitive (ueber die wird es wohl laufen, oder?)

Falls bei sowas ueberhaupt noch eine Post-Map-Simulation (oder Netzliste -> Verilog) geht, ist das allenfalls aufschlussreich. Zumindest war es das bei aelteren ChipScope-Setups. Bei einer Plattform biss sich der ILA schon mal mit dem JTAG TAP zum SoftCore.

Martin S. schrieb:

Unguenstige Abtastung (Aliasing), JTAG-Clock zu gering

sicher nicht das problem, warum sollte JTAG clock was ausmachen beim 8 zu 10 port design Änderung.

Schlichter Bug betr. Limite in der Anbindung an die BSCAN-Primitive (ueber die wird es wohl laufen, oder?)

muss irgendwas mit BSCAN lofgic gewesene sein. Manchmal sind auch plausible werte gekommen, mal an richtigen stelle, mal nebenan. Irgendwas fehler mit shift.

Antti L. schrieb:

sicher nicht das problem, warum sollte JTAG clock was ausmachen beim 8 zu 10 port design Änderung.

Da wir nicht wissen, was der Krempel intern mit den BSCAN-registern genau macht: Probier doch mal spasseshalber auf ein Vielfaches von 8 zu gehen. Wenn sich dann nix mehr umherschiebt, ist's ein Deja-Vu, und es gaebe dann eine Erklaerung.