mikrocontroller.net

Forum: FPGA, VHDL & Co. Teststrategie


Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche gerade, mir eine Teststrategie zurechtzulegen.

Ganz konkret habe ich momentan das Problem, dass eine funktionale
Simulation funktioniert, die Timingsimulation aber nicht. Es treten
dummerweise keine Setup/Hold-Verletzungen auf, so dass ich keinen
Anhaltspunkt habe, wo denn der potenzielle Fehler zu finden ist. Das
Timingmodell ist auch im Vergleich zum funktionalen Modell schon recht
groß und unübersichtlich. Es geht mir nicht so sehr um diese spezielle
Simulation, sondern allgemeiner:

Wie geht man sowas an?

Ich könnte jetzt versuchen, in den vielen Instanzen ein paar "Namhafte"
herauszupicken und zu gucken, ob das überhaupt stimmen kann -- allein,
das gleicht der Suche nach der Nadel im Heuhaufen.

Ich könnte ein paar interne Signale nach außen legen.

Mit dem "Boundary Scan"-Verfahren habe ich mich noch nicht wirklich
auseinandergesetzt, scheint mir aber "Overkill" zu sein.

Ein Aspekt des Ganzen ist, dass der "Eingriff" minimal-inversiv sein
sollte. Wenn die Testlogik später wieder rausfliegt, sollte das Design
möglichst wenig beeinträchtigt werden (sowohl Sourcecode als auch das
Timing des Designs).

Und damit ist ja noch nicht gewährleistet, dass das Design auch auf dem
FPGA tut ... :-/

 -- stefan

Autor: Walt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie man bei der Softwareentwicklung das Debuggen im Auge behalten muss, 
sollte man auch bei der Hardware das Debugging einplanen. Ja, interne 
Signale nach aussen legen. Man kann auch einen Mux mit einem pin nehmen 
und diesen Mul per steuersignal ein signal auslesen lassen. Gewisse 
Bausteine unterstuetzen auch einen internen Logikanalyzer.

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Erfahrungen beziehen sich hauptsächlich auf CPLD's und 
selbstprogrammiertem Flow unter Linux, aber vielleicht hilft's trotzdem. 
Timingsimulation habe ich mit GHDL noch nicht hinbekommen, da die 
SIMPRIMS nach VITAL2000 verlangen...
Sobald es intern komplex wird, nützen setup/hold Bedingungen nach meinen 
Erfahrungen nicht mehr sehr viel. Viel interessanter scheint mir da der 
timing-report zu sein. Dort stehen ganz oben die maximalen Frequenzen 
für die Taktsignale (die oftmals drastisch niedriger ausfallen als das 
einem lieb ist). Darunter folgen dann jeweils die "path delays" in denen 
der Übeltäter oft schnell enttarnt wird. Das Problem zu lösen, steht 
dann auf einem anderen Blatt...
Manchmal helfen auch Periodendauer-Constraints im ucf-file, wenn die 
aber nicht realisierbar sind, wird abgebrochen und ist die Ursache kaum 
zu finden.

Gruß Jörg

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was genau funktioniert denn nicht?
Funktioniert das Post-Synthesis-Modell und Post-Translate-Modell auch 
schon nicht?


Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Xenu, ich habe den Fehler bereits gefunden. Tja, wenn man das 
LOCKED-Signal der DLL nicht beachtet, dann passieren unvorhergesehen 
Dinge ;-)

Das mit dem Mux klingt interessant. Das Problem, das ich mit der Methode 
habe, ist, dass ich dafür mein Design anpassen muss -- die Analogie zur 
SW-Welt scheitert hier, da muss nichts angepasst werden. Aber eventuell 
kommt man darum nicht herum...

Die Taktfrequenzen im Auge zu behalten, ist auch ein guter Tipp. Ich 
habe hier laut Synthese max 66 MHz, laut Static-Timing (Post-PAR) 143 
MHz, das reicht locker aus. Ich hoffe, die Zahlen bedeuten wirklich das, 
was ich glaube ;-)

UPDATE: Nein, zumindest die zweite Zahl bedeutet was anderes. Ich hatte 
gerade gemerkt, dass die Taktperiode noch auf 20 ns gestellt war. Mit 10 
ns fliegen mir ein paar Setup/Hold-Verletzungen entgegen.

UPDATE2: Ich dachte, Dienstag sei mein schlechter Tag ;-) 20 ns stimmt 
natürlich, es wird ja intern auf 10 ns hochgezogen.

 -- stefan

Autor: VHDL_Mensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wofür verwendest du das Locked Signal nun? Als Reset?

Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Locked als Reset?!

Das Locked-Signal wird nur intern verwendet und nicht aus der Top-Entity 
herausgeführt. Die Testbench kann also nicht wissen, wann der Takt 
verläßlich ist. Der Stimulus wurde also zu früh angelegt.

 -- stefan

Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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