mikrocontroller.net

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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Oli (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Schmutz Schauffel (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Oli (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

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

Bewertung
0 lesenswert
nicht 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.

Autor: Oli (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

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

Bewertung
0 lesenswert
nicht 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.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.