Liebe Community,
ich habe ein Design für einen ASIC, was ich auf einem FPGA (Altera
Cyclone) testen möchte. Um besser die inneren Abläufe zu sehen, möchte
ich einige Signale auf die IO-Pins legen.
Beispiel:
module FPGA_Design (GPIOs zu FPGA...);
ASIC_Design ASIC_Design_0 (
.Standard_Ports ()
...
);
endmodule
module ASIC_Design (Standard_Ports ...);
Inneres_Modul Inneres_Modul_0(...);
endmodule
module Inneres_Modul(...);
reg Beliebiges_Signal;
endmodule
Wie kann ich einfach auf die inneren Signale wie Beliebiges_Signal
zugreifen? Ich erzähl mal, was ich bisher mit wenig zufriedenstellenden
Erfolg probiert habe und würde mich freuen, wenn ihr mir einen
Fingerzeig geben könntet, wie man sowas elegenat machen kann.
Variante 1: XMR - xross module reference. In Verilog gibt es wohl die
Möglichkeit auf Signale anderer Module über XMR zuzugreifen. Das ähnelt
etwas der Objektorientierten Programmierung und würde hier nach meinem
Verständnis wie folgt aussehen:
FPGA_Design.ASIC_Design_0.Inneres_Modul_0.Beliebiges_Signal
Funktioniert leider aber nicht. Zumindest beschwert sich entweder
Quartus oder es kommt nichts raus. Stimmt es, dass dieses Konstrukt
tatsächlich nicht Synthesefähig ist? Wäre schade, denn sonst könnte ich
gleich noch weitere Auswertelogik auf dem FPGA platzieren, die die
inneren Zustände automatisch auswertet.
Variante 2: SignalProbe Pins nutzen. Damit kann ich Pins des FPGA
definieren, die bestimmte Signale nach außen führen können. Zwei
Nachteile: Es können nur Signale genutzt werden, die nach der Synthese
zur noch vorhanden sind. Und nach jedem Compile-Vorgang muss per Hand
jedes Mal erneut Quartus angewiesen werden, die Signale auf die Pins zu
routen und erneut fast komplett compiliert werden. Also leider nicht
praktikabel.
Variante 3: Die Ports von meinem ASIC_Design und Inneres_Modul usw.
immer wieder anpassen und die Debug-Signale nach außen führen. Absolutes
NoGo für mich, weil ich erstens im Design Änderungen vornehmen müsste
und ich zweitens enormen Aufwand mit der Portdefinition hätte, nur um
ein Signal nach außen zu routen.
Variante 4: Das LogicAnalyzer Interface nutzen. Ich habe zwar einen
guten LA von Agilent zur Verfügung, aber leider kein Altera-Interface um
die JTAG-Schnittstelle zu nutzen. Deswegen diese Variante nicht weiter
verfolgt.
Variante 5: SignalTab II. Prinzipiell keine schlechte Erfindung, nützt
mir aber nur bedingt, da ich auf zwei verschiedenen FPGAs arbeite, die
miteinander kommunizieren. Deswegen würde ich gern auf einem LA
zeitbezogen die Signale sehen wollen, auch über längere Zeiträume die
der interne FPGA-Speicher nicht abdecken könnte.
Was habe ich übersehen? Oder gibt es wirklich keine einfache
Möglichkeit, sein Design zu debuggen, ohne es bearbeiten zu müssen? Wie
macht ihr sowas? Würde mich über eine einfache Variante freuen, weil die
bisherigen für mich so leider nicht zufriedenstellend sind... :-(
Viele Grüße, ElKo
Variante6: Simulieren und Waveform anschauen, denn
> (...) habe ein Design für einen ASIC, was ich auf einem FPGA (...)
wenn es vorher ein Asic war, sollte es zu diesem eine testbench
mit vielen testcases für die Simulation geben, da im Asic noch weniger
observierungsmöglichkeiten als im FPGA vorhanden sind. Ein Asic sollte
ausführlich mittels Simulation auf seine Funktionalität verifiziert
worden sein.
Also wenn ich mir Signale aus inneren Modulen nach außen legen will,
dann mach ich das immer mit Variante 3 und kotze dabei ab.... aber ne
andere kenn ich nicht! Bin aber auch kein pro!
Wäre interessant zu wissen ob es sowas gibt und wie es umgesetzt ist!
bko schrieb:> wenn es vorher ein Asic war, sollte es zu diesem eine testbench> mit vielen testcases für die Simulation geben ...
Ich habe mich anscheinend etwas missverständlich ausgedrückt. Das Design
gibt es noch nicht als ASIC, sondern soll später als ASIC gefertigt
werden. Ich entwickle gerade ein Design aus dem Nichts, inklusive
Testbenches usw. Aber Testbenches in allen Ehren, manche Sachen möchte
ich doch direkt auf dem FPGA testen, weil es eben doch noch etwas
realitätsnäher ist. Ansonsten geb ich dir recht, dass die Testbenches
und Simulationen auf jeden Fall ein komfortabler Ansatz sind, um das
Verhalten des Systems zu beobachten.
Es gibt ab VHDL2000 und richtig erst ab VHDL2008, um auf interne Signale
zuzugreifen. Da wird der Instanzname und er Pathname miteinader
kombiniert. Ich hatte es mal bei Xilinx ISE ausprobiert wurder leider
unterstützt und dann habe ich es nicht weiterverfolgt. Könnte sein dass
es jetzt unterstützt wird.
Must mal unter Neuerungen VHDL2008 suchen da steht es meistens dabei.
Ob es dier bei deinem Verilog hilft weiß ich nicht. Kannst ja eine
VHDL-top Instanz davorsetzen.
Eigener eigen Logik-Analyser im Design nutzen. Internem RAM des FPGAs
nutzen.
Ein Dual Ram von der einen Seite mit den Testsignalen füllen und auf der
Anderen Seite herausholen. (z.B. über eine Uart Leitung)
In VHDL gibt es den Typ record. Ich habe mein Design mit Records durch
verdrahtet und wenn ich mal so ein Debugsignal brauche dann wird dem
Record ein Signal hinzugefügt und es wird durch alle Instanzen mit
geschleppt. So muss ich nicht so aufwendig das Design geändert werden.
Ich bau hier ein System mit einigen Timing-kritischen Signalen. Alles wo
es auf korrektes Timing ankommt verifiziere ich immer mit Modelsim.
Ist zwar sicher etwas komplexer wenn ein zweites System dazu kommt, aber
auch das sollte sich mit Modelsim darstellen und testen lassen. Der
unschlagbare Vorteil ist halt, dass du wirklich auf alle Signale Zugriff
hast.
Wenn das Timing in Modelsim stimmt (und keine Latches oder so ein Käse
drin sind) dann stimmt bei mir das Timing in Realität immer!
Ach ja, Modelsim unterstützt auch Variante 1, ich bin allerdings noch
nie auf die Idee gekommen das in der Synthese zu testen da mein Design
Rule Subprozessor im Hirn droht, die Zehennägel hochzurollen ;-)
abcd schrieb:> Ach ja, Modelsim unterstützt auch Variante 1, ich bin allerdings noch> nie auf die Idee gekommen das in der Synthese zu testen da mein Design> Rule Subprozessor im Hirn droht, die Zehennägel hochzurollen ;-)
Da er es ja explizit für die Verifikation auf einem FPGA einsetzen will,
ist das aus meiner Sicht legitim. Für das eigentliche Design ist das
klar ein No-Go (Er will ja auch explizit verhindern, dass durch die
Verifikation das Ursprungsdesign verändert wird, was auch zu begrüssen
ist).
ElKo schrieb:> Variante 4: Das LogicAnalyzer Interface nutzen. Ich habe zwar einen> guten LA von Agilent zur Verfügung, aber leider kein Altera-Interface um> die JTAG-Schnittstelle zu nutzen. Deswegen diese Variante nicht weiter> verfolgt.
Wenn ihr schon Geld habt, einen ASIC zu fertigen, sollten das Geld für
diese SW Option auch vorhanden sein. Bei deinem beschriebenen Multi-FPGA
System mit zusätzlicher externer Hardware lohnt sich das auch.
Hatte diese Option mal mit Xilinx für kurze Zeit zur Verfügung.
René D. schrieb:> Es gibt ab VHDL2000 und richtig erst ab VHDL2008, um auf interne Signale> zuzugreifen. Da wird der Instanzname und er Pathname miteinader> kombiniert. Ich hatte es mal bei Xilinx ISE ausprobiert wurder leider> unterstützt und dann habe ich es nicht weiterverfolgt. Könnte sein dass> es jetzt unterstützt wird.
Habe das gerade schnell mit dem Synplify Pro 2012 (Bei Lattice Diamond
dabei) ausprobiert. Damit verwende ich erfolgreich schon andere
VHDL-2008 Features.
"Hierarchical names", wie das Feature in VHDL-2008 genannt wird, werden
nicht unterstützt.
>Ich habe mich anscheinend etwas missverständlich ausgedrückt. Das Design>gibt es noch nicht als ASIC, sondern soll später als ASIC gefertigt>werden. Ich entwickle gerade ein Design aus dem Nichts,
Ah sorry, ich korrigiere mich:
Ein Asic muss ausführlichst mittels Simulation auf seine Funktionalität
verifiziert werden!
So ab dem 5 ASIC redesign herrschen in einer Firma meine Erfahrung nach
Kriegsähnliche Zustände ...
bko schrieb:> So ab dem 5 ASIC redesign herrschen in einer Firma meine Erfahrung nach> Kriegsähnliche Zustände ...
:-) Das glaub ich dir gerne!
Christoph Z. schrieb:> Wenn ihr schon Geld habt, einen ASIC zu fertigen, sollten das Geld für> diese SW Option auch vorhanden sein. Bei deinem beschriebenen Multi-FPGA> System mit zusätzlicher externer Hardware lohnt sich das auch.
Naja, das mit dem Geld zur Verfügung haben, ist leider so eine Sache.
Geld ist da, wenn entsprechende Projekte da sind, auf die das Geld
ausgegeben werden kann. Ist aber nicht. Und deswegen ist zur Zeit gerade
kein Geld da. Der LA wurde mal zu anderer Gegelegenheit angeschafft.
Vielleicht kennt sich jemand anderes da in den UNI-Strukturen besser
aus. Als Student sind mir da ein wenig die Hände gebunden...
Vielen Dank für die zahlreichen Rückmeldungen und Erfahrungsberichte!
Ich bin schonmal froh, dass ich keine grundlegende Vorgehensweise
übersehen habe. Wenn auch leider keine einfacherer Lösung zu Tage kam.
Naja, in dem Fall werde ich wohl, wie ihr emfohlen habt, einfach mehr
simulieren müssen. In der Hoffnung, dass ich da die meisten Fehler
aufdecken kann. Leider kann ich dadurch immer noch nicht richtig die
analoge Schnittstelle zwischen den FPGAs testen, aber das schaffe ich
dann hoffentlich auch ohne tieferen Einblick in das Design.
ElKo schrieb:> Vielleicht kennt sich jemand anderes da in den UNI-Strukturen besser> aus. Als Student sind mir da ein wenig die Hände gebunden...
Du hast Glück, es geht auf Ende Jahr zu. Geh mal zu deinem Prof und
frag, ober noch irgendein Buchhaltungskonto hat, mit Geld das er bis
Ende des Jahres ausgeben muss (damit im nächstes Jahr das Geld nicht
gekürzt wird).
Und dann "wünscht" du dir die FPGA Debug Option für den LA zu
Weihnachten.
Im Januar musst du mit so einer Anfrage dann nicht mehr kommen :-)
Christoph Z. schrieb:> Und dann "wünscht" du dir die FPGA Debug Option für den LA zu> Weihnachten.
Die "FPGA Debug Option" taugt nix. Das ist nur, damit der LA im FPGA
einen Multiplexer steuern kann. Wenn man aber z.B. nur vier Signale
rausgelegt hat, kann man auch nur vier Signale gleichzeitig sehen. So
einen Multiplexer kann man auch anders ansteuern, da braucht man kein
JTAG dafür.
Duke
