Forum: FPGA, VHDL & Co. ILA-Signale können nicht gebaut werden


von Oli (Gast)


Lesenswert?

Ich verwende ILA um meine Schaltung zu debuggen und erhalte einen Fehler 
in der Implementierung, dass er die Bits eines Differenzbilders nicht 
finden kann und nicht einbauen will.

Fehlermeldung "undriven net".

Die Geschichte sieht in etwa so aus:

Signal_A, Signal_B, Dif_AB

Die beiden Signale kommen aus Registern,  DiFF AB wird direkt ohne Takt 
gebildet.

Alle drei haben keeper und maintainance contraints, worauf sie nach der 
Synthese im Debug Setup auch auswählbar waren.

Alle drei wurden auch schon angezeigt.

Der Debug Core wurde um weitere Signale erweitert, nun kann er dieses 
DIFF nicht mehr einbauen. An dem DIFF hängt nichts ausser dem ILA 
selber.

Idee?

von Schmutz Schauffel (Gast)


Lesenswert?

Oli schrieb:
> Idee?

Poste den Code, aus deinem geschreibsel wird man nicht schlau.
Hilfreich wäre auch die Nennung des FPGA-Types und der benutzten 
Tool-chain.

von Oli (Gast)


Lesenswert?

Den Code kann ich nicht posten. Tool Xilinx Vivado 2019.1.

Der Fehler ist irgendwie verrückt. Noch nie gesehen. Irgendwie scheint 
es, als ob durch das Hinzufügen von Debug-Signalen im ILA-Setup etwas 
verrutscht, oder es gibt einen anderen inhaltlichen Grund, warum die 
Implementierung nicht funktioniert.

Wie gesagt, konnte er in einem ersten Lauf das aus Kombinatorik 
gebildete Signal darstellen. Das geht nun nicht mehr.

Abhilfe: Ich habe das Signal im ILA gelöscht, es getaktet, synthetisiert 
und neu hinzugefügt. Nun baut er es.

Ohnedies habe ich den Verdacht, dass der ILA nicht so 100% ausgereift zu 
sein scheint. Es kommt häufiger vor, dass er nach einer Änderung von 
Signalen etwas baut, womit er später nichts anfangen kann. Der Core wird 
gar nicht gefunden. Abhilfe: Alle Signale aus. Debug-Anweisungen im XDC 
säubern (da bleiben nämlich trotz Entfernen Reste), "runs" löschen und 
alles einmal neu durch.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

Das Problem ist dein Design Flow. Du hast dein Design synthetisiert und 
anschliessend den ILA Core hinzugefuegt, wodurch die ILA Signale 
entweder in ein bestehendes XDC File geschrieben wurden oder du hast ein 
neues angelegt.

Damit hast du Vivado gezwungen einen neuen Syntehselauf zu starten, 
wodurch die Signale nicht mehr identisch sind zu den vorherigen. In der 
Regel wurden die nicht weg synthetisiert, sondern heissen jetzt einfach 
anderst.

Kannst ja mal schauen, wenn du nach der synthese den Debug View auf 
machst, ob dann manche Debug Ports leer sind.

Mein Tipp:

Du legst vor der Synthese ein neues XDC File an, z.B. debug.xdc. Dieses 
setzt du mit einem Rechtsklick als "Target File" (odermso aehnlich 
heisst das). Dann laesst du die Synthese laufen und erzeugst dein ILA 
Setup wie gewohnt. Nach dem speichern wird er nicht nochmal die Synthese 
starten wollen, sondern geht gleich zum P&R ueber.

Oli schrieb:
> Ohnedies habe ich den Verdacht, dass der ILA nicht so 100% ausgereift zu
> sein scheint. Es kommt häufiger vor, dass er nach einer Änderung von
> Signalen etwas baut, womit er später nichts anfangen kann. Der Core wird
> gar nicht gefunden. Abhilfe: Alle Signale aus. Debug-Anweisungen im XDC
> säubern (da bleiben nämlich trotz Entfernen Reste), "runs" löschen und
> alles einmal neu durch.

Finde ich eigentlich garnicht, gerade mit 2019.1 sind viele Krankheiten 
behoben worden. Man sollte allerdings im Detail verstehen was passiert, 
sonst passieren genau solche Fehler.

von Oli (Gast)


Lesenswert?

Tobias B. schrieb:
> Du legst vor der Synthese ein neues XDC File an, z.B. debug.xdc. Dieses
> setzt du mit einem Rechtsklick als "Target File" (odermso aehnlich
> heisst das). Dann laesst du die Synthese laufen und erzeugst dein ILA
> Setup wie gewohnt. Nach dem speichern wird er nicht nochmal die Synthese
> starten wollen, sondern geht gleich zum P&R ueber.

Schon richtig, allerdings habe ich ja die Synthese neu gestart und 
erst danach die neuen Signale eingesetzt. Da er dann wieder eine neue 
Synthes macht (gfs unnötig) müsste alles aktuell sein. Genau genommen, 
beschreibst du ja richtigerweise, dass sich nach dem Definieren der 
debug Sigs an der Synthese nichts tun sollte. Gleichwohl führe ich sie 
durch.

In jedem Fall ist es ominös, wenn er das design nicht bauen kann. Der 
Fehler, dass er eine alte Debug-Definition nicht verwenden kann, weil 
das Signal weg ist, sieht auch anders aus.

Tatsache bleibt auch, dass nach dem Entfernen des debug Cores immer 
gerne mal Reste im XDC über bleiben. Egal, ob man ein zusätzliches XDC 
benutzt oder nicht. Kannst du gerne mal probieren. 2-3m Signal geändert 
und er hat Reste, an denen er sich auch gerne mal stört.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

Oli schrieb:
> Da er dann wieder eine neue
> Synthes macht (gfs unnötig) müsste alles aktuell sein.

Genau das Gegenteil ist der Fall. Du willst nach dem definiere der 
Signale eben keine neue Synthese haben!

Oli schrieb:
> Genau genommen,
> beschreibst du ja richtigerweise, dass sich nach dem Definieren der
> debug Sigs an der Synthese nichts tun sollte. Gleichwohl führe ich sie
> durch.

Nein, genau das Gegenteil beschreibe ich. Das hinzufuegen der Debug 
Signale kann und hat auch Einfluss auf die Synthese. Deshalb solltest du 
unbedingt einen Workflow waehlen, der eine neue Synthese nach dem 
hinzufuegen der ILA Cores vermeidet.

Oli schrieb:
> Tatsache bleibt auch, dass nach dem Entfernen des debug Cores immer
> gerne mal Reste im XDC über bleiben. Egal, ob man ein zusätzliches XDC
> benutzt oder nicht. Kannst du gerne mal probieren. 2-3m Signal geändert
> und er hat Reste, an denen er sich auch gerne mal stört.

Deshalb nehme ich immer ein eigenes XDC File fuer die Debug Geschichten. 
Das wird im Anschluss einfach geloescht, bzw. ist kein Bestandteil des 
Git Repos.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

Oli schrieb:
> Tool Xilinx Vivado 2019.1.
Mir ist aufgefallen, dass es häufiger zu Fehlinterpretationen des tool 
kommt, was die Zwischenergebnisse angeht, die es anlegt. Ich nehme an, 
Xilinx hat (wieder einmal) versucht, die Synthesezeit zu verkürzen, 
indem es inkrementales Implementieren verwendet und zwischengespeicherte 
Ergebnisse aus ehemaligen runs verwendet.

Oft hilft nur, das ganze *.runs zu löschen und was ILA anbelangt, das 
*.hw gleich mit. Dort verstecken sich alte ILA-Konfigurationen, die den 
Start des Analyzers selbst verhindern. D.h. er findet den Core erst gar 
nicht.

von Michel (Gast)


Lesenswert?

Ich habe auch so ein Problem:

Gerade einige Signale mit "Set Debug" in der Liste ausgesucht und 
eingefügt, gespeichert und Senthese aktiviert.

Sofort kommt binnen 2 Sekunden die Meldung dass ein Signal nicht 
angeschlossen ist und es Implementierungsprobleme geben wird. Welches 
Signal es ist, wird nicht genannt.

Und bei der Implementierung kommt dann auch:

[Chipscope 16-213] The debug port 'u_ila_0/probe0' has 1 unconnected 
channels (bits). This will cause errors during implementation.

Alle Signale, die ich anschauen möchte, sind aber mit keep und dont 
touch versehen worden.

?

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

Michel schrieb:
> Alle Signale, die ich anschauen möchte, sind aber mit keep und dont
> touch versehen worden.

Verwende das Attribut mark_debug:

https://www.xilinx.com/support/answers/58963.html

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.