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?
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.
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.
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.
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.
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.
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.
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. ?
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.