Meine VHDL Modelle (ein Großteil zumindest) sind geschrieben und mit
einem TB bzgl des Verhaltens getestet. In XST kann ich mir nun Post
Synthese VHDL Files kreieren lassen. Nun liegen die Files im Xst Dir
und nicht im Source Dir, na gut.
Die Frage ist, wie kann ich meinen bisherigen TB zur Post Synthese
Simulation benutzen? Mittels configurationen? Kann man den post
synthesis architecture default Namen ändern?, er ist "Structure" und
kann leicht zur Namenskollisionen führen. Sinnvoll wäre auch eine
Änderung des Ausgabeverzeichnisses.
Da ich die "do" scripte verwende, habe ich aber auch keine grosse
Lust jedesmal die neuen post synth. vhdl Files hinzu zuschreiben.
Wie macht ihre die Post Synthese? Mal von den kommenden Problemen bei
der Auswertung abgesehen, von denen ich bereits gelesen habe.
Viele Grüße
Olaf
PS: Happy XMas
Moin...
Womit simulierst du denn?
Wenn der Modelsim eingebunden ist, kannst du die entsprechenden Modelle
(Source, post Synthesis, post Routing) direkt anwählen. Das Tcl/Tk
Skript zum Aufruf wird automatisch generiert und um die
Namensverwaltung braucht man sich händisch nicht kümmern.
--
Sven Johannes
Vielen Dank! Nutze Xilinx Webpack, also Modelsim. Da gibt's im ISE
(nach Einfügen des TB im Navigator) wirklich die Möglichkeit diese
Modell zu testen.
Allerdings gehen jetzt die (unerwarteten) Fehler auf. Modelsim meldet
plötzlich "Unknown identifier" bzgl der Generics im TB. Beim
Anschauen des Post Synthesis Modells fehlen auch wirklich die Generics,
auch hat xst aus meinem unsigned Vector einen std_logic_vector gemacht -
damit habe ich nun nicht gerechnet (eher Timing/Verhaltensfehler).
Habe ich hier irgendeinen prinzipiellen Fehler?
Viele Grüße
Olaf
Moin...
Generics in Testbenches sind ein besonderer Fall. Verdreht unser
Mentor-Mensch auch immer die Augen, habe ich mir bereits abgewöhnt, ein
Kollege hier besteht aber drauf.
Die Generics müssen in der Synthese natürlich aufgelöst werden und
durch konkrete Werte ersetzt werden. Warum der ModelSim das nicht
frisst ist natürlich beliebig dusselig zu erraten. Ist dein "Problem"
klein genug um es zu veröffentlichen?
--
Sven Johannes
In dem Post Translate (entspricht das dem Post Synthese Modell?) sind
die generics alle bereits aufgelöst und das design platt getreten, bei
den records wurde ein name mangeling durchgeführt. Klar, dass dann mein
TB aus der Functional Simulation nicht mehr passt (zumindest bzgl. der
Generics). Ich habe aber auch keinen Schalter dafür gefunden (7.1.04
Web Editition).
Bis jetzt habe ich mir immer meine do scripte zusammengebastelt mit
ihren Depencies. Im ISE ist es mir noch nicht gelungen, diese
einzuführen. Nur Modelsim (MS) hat eine Compile Order. Da aber direkt
MS aus ISE aufgerufen wird, nutzt mir mein Script nichts, auch kein MS
Projekt. Die tolle Hierarchy mit den packages im ISE ist wohl nur
Makulatur, ich musste nach dem Aufruf aus dem ISE die packages in MS
selbst compilieren.
Viele Grüße
Olaf
Klar, dass dann der TB nicht mehr passt. Irgendwelche Hinweise? Möchte
nur ungern alles umschreiben auf RTL. Hat Quartus das gleiche Problem?
Viele Grüße
Olaf
Kann es sein, dass für die Postsynthesis Simulation (schätze mal auch
für die Post Mapping etc.) die generics des TB einfach weggelassen
werden müssen, d.h. der TB mit den Generic Defaults läuft? In diesem
Fall müsste ich dann für die Functional/Post Synthesis Simulation den
map generic part mit pragma synthesis_off/on "klammern" (mal
probieren); was aber wohl nicht gehen wird - hier fehlt dann wirklich
ein ifdef Konstrukt in der Sprache VHDL.
Das nach der Postsynthese der unsigned nicht mehr existiert ist zwar
ärgerlich, aber umgehbar. Annti schrieb 'mal, immer nur
std_logic_vector zu benutzen, trifft dieses generell zu oder nur auf
die Ports? Intern in der architectutr würde ich wieder mit unsigned
arbeiten.
Wie macht ihr die Postsynthese: keine Generics, nur std_logic?
Viele Grüße
Olaf
na ja, meine records erleiden ja auch einem namemangeling, so einfach
geht's wohl doch nicht. Wäre ein "TB-Port-Wrapper" eine
Möglichkeit?
Werde demnächst mal Web/ISE 8.1 probieren.
Viele Grüße
Olaf
Es gibt da eine tolle Erfindung, die nennst sich Suchmaschine, die
solltest Du mal ausprobieren.
Wenn ich bei Google die Suchbegriffe "testbench generic xilinx"
eingebe,
kommt an zweiter(!) Stelle ein Link auf die Xilinx-Antwortdatenbank mit
der Antwort auf Deine Frage.
Lustig, oder?
Du könntest natürlich auf gleich in der Xilinx-Datenbank suchen.
Wenn ich da "testbench generic" eingebe, kommt die Antwort an erster
Stelle...
Du brauchst nur eine neue Top-Level Entity ohne Generics schreiben,
welche eine Instanz Deiner konfigurierbaren Komponente enthält. Diese
Instanz wird mit den gewünschten Generics aufgerufen.
Schließlich ist es ja meisten so, daß man zwar die Komponenten
generisch hält, damit man sie wiederverwenden kann, aber bei der
Synthese für ein bestimmtes Projekt ergeben sich die Werte der Generics
(fast) immer aus den Spezifikationen (z.B. Busbreite).
Wenn Du dies machst, dann stimmt die Interface Beschreibung für deine
selbstgeschriebene Architecture und die vom Compiler überein und Du
hast keine Probleme über Configurationen die gewünschte architecture
auszuwählen.
Den Namen der generierten Post-Synthese Architecture kann man wählen,
ebenso wie den Filenamen. Außerdem ist es günstig, im generierten
VHDL-File die Interface-Beschreibung zu unterdrücken.
Du kannst dann das generierte File einfach in Deine Work-Library
kompilieren und voilà!, Du hast Deine Top-Level Entity mit 2
architectures.
Schreibe ein 2 Konfigurationen für Deine Testbench, eine für einen
Aufruf mit Deiner Architecture und eine für einen Aufruf mit der vom
Compiler generierten.
Oder ändere deine Testbench indem Du beide Architectures aufrufst und
die Ausgangssignale vergleichst.
Grüße
Klaus
was bezweckt eine post simulation überhaupt?
ein design muss man doch sowieso auf der hardware verifizieren. deshalb
bringe ich mein design nach einer verhaltenssimulation auf das board und
teste dann die gewünschten funktionen.
>ein design muss man doch sowieso auf der hardware verifizieren.
Stimmt. Aber mit der Begründung kannst Du Dir jede Simulation sparen.
Wenn Du grundsätzlich fehlerfreie Designs erstellst, Respekt!
>deshalb bringe ich mein design nach einer verhaltenssimulation auf>das board und teste dann die gewünschten funktionen.
Und was passiert wenn Dein Design sehr zeitkritisch ist und es durch
Laufzeiten z.B. zu gleichzeitigen Buszugriffen kommt? Wie willst Du das
denn mit 'nem Oszi rausfinden? Im Simulator sieht man das sofort.
Evtl. machst Du Dir sogar Deine Hardware kaputt.
@ xenu:
dein sarkasmus in allen ehren...(denn schliesslich bist du immer recht
hilfreich bei fragen hier im forum)
bin bisher immer ohne post simulation ausgekommen.
laufzeitverzögerungen sind sicherlich ein störendes problem, aber auch
mit messungen feststellbar, denn schliesslich kann man das erwartete
Ergebnis nachmessen.
wenn die post simulation so wichtig ist, warum hilfst du nicht bei opes
problem, sondern einen herablassenen kommentar? keiner ist
vollkommen....
>wenn die post simulation so wichtig ist, warum hilfst du nicht bei>opes problem, sondern einen herablassenen kommentar?
Habe ich das nicht?
Vielleicht solltest Du Dir meinen Beitrag nochmal genau durchlesen...
Gib auf der Xilinx-Seite in der Suchmaske "testbench" und "generic"
ein und das erste Suchergebniss ist die Antwort.
Wie ich oben bereits geschrieben habe.
Das Problem (ist kein wirkliches) das ich mit der "netgen -a" Lösung
habe ist, dass ich mal eben in der Console die architecture erzeugen
muss; d.h. ich kann es wohl weder mit den do-Scripten (wäre sicher mit
tcl machbar - kann ich aber (noch) nicht) noch im ISE durchführen.
Wenn man ständig hin- und herspringt, vergisst man leicht einen
Zwischenschritt und klickt, klickt und klickt und simuliert noch mit
den alten Daten...
Schwieriger ist das platt treten der records, was imo aus Hardwaresicht
verständlich ist, aus Sicht der Simu jedoch nicht unbedingt einleuchtend
ist.
Klaus sein Ansatz werde ich ebenfalls (hoffentlich) dieses Wochenende
probieren können, auch wenn ich noch keine konkrete Vorstellung von der
Umsetzung habe.
Bei google u.a. ist das Problem die richtigen Suchbegriffe zu finden,
ich hatte gleich zu Begin der Suche zu stark eingeschränkt; man lernt
eben nicht aus.
Vielen Dank für die Hilfe und viele Grüße
Olaf
Wenn
- das Design funktional verifiziert ist,
- das Timing der I/O Signale überlegt und mittels Timing Constraints
erzwungen wurde,
dann hat der Designer seinen Teil getan.
Die Post Simulation (Post Synthese und Post Place&Route) dienen dann
nur dazu zu sehen, ob die Tools Fehler gemacht haben.
Wer die Post Simulation braucht, um zu sehen ob das Timing korrekt ist,
ist wirklich ein bischen spät dran (gut, besser zu spät als nie).
Wenn man FPGA's entwirft, dann wird man meisten auf die Post
Simulation verzichten, aber jemand der ASIC's entwickelt wird sie
garantiert verwenden.
Klaus
@ xenu:
habe schon in deinem o.g. beitrag feststellen können, dass du auf
ope's problem ein gegangen bist, nur gefiel mir dein ton dabei nicht,
denn schliesslich ist es ein problem gewesen, dass nicht in neuen
threads hier alltäglich besprochen wird.
dass man nicht vollkommen ist, und das man eben nicht stundenlang
sucht, gibt doch den sinn dieses forums wieder, in dem man fragen
stellen kann, in der hoffnung auf lösungsansätze und hilfreiche tipps.
es kam mir so vor, als wenn es aus deiner sicht nichts einfacheres
gibt, als lösungsansätze selber zu erarbeiten. manchmal sieht man den
wald vor lauter bäumen nicht, deshalb habe ich auf den ton deines o.g.
beitrags nicht für sehr hilfreich empfunden. du bist doch recht
erfahren in vhdl plus designumgebung, ergo musst du nicht so erfahrende
leute me so über den mund fahren. nix für ungut.
by the way, danke klaus für die aussagen der post simulation. ich habe
nach einer funktionalen verhaltenssimualtion und nach festlegen der
time constraints und der festen zuweisung der i/o pins für mein design
in einer oder direkt benachtbarten i/o banks eigentlich kaum probleme
mit meinem design bezüglich des timings gehabt. sicherlich kommt es zu
laufzeitverzögerungen, die man aber mit area constraints auch wieder
minimieren kann.
>kann ich aber (noch) nicht) noch im ISE durchführen.
Bei "Generate Post-Place & Route Simulation Model" rechte Maustaste
->
Properties. Im Properties-Fenster "Property Display Level" auf
"Advanced" stellen.
Unter "Other NETGEN Command Line Options" kannst Du jetzt "-a" mit
einfügen.
Ich habe es wie Klaus vorgeschlagen das ganze Wochenende versucht, bin
aber immer irgendwie wieder gescheitert. Dazu habe ich ein kleines
Counter Projekt zum testen initiiert (ist übersichtlicher als das LA
Projekt):
Die Postsynthese erzeugt nur die architecture "Structural" (keine
entity, switch -a bzw. in 8.1 gab es an anderer Stelle direkt die
Möglichkeit des Abschaltens).
Die neue non-generic Top-Level entity für diese synthetisierte
architecture sieht wie folgt aus:
Bis zur Synthese bin ich gar nicht mal gekommen. Modelsim 6.0d
compiliert das behavioral architecture fehlerfrei durch, aber vsim
meldet nun:
Generic 'reset_active' has not been given a value.
Ich dachte durch die Konf. werden die Generics gleich gemapped. Das
Prinzip habe ich hoffentlich verstanden, nur in der Realisierung hapert
es noch ...
Viele Grüße
Olaf
Du muß mit deiner Testbench "TB_counter" die Entity
"reciprocal_counter_32" testen, nicht die generische.
Wenn Modelsim die Konfiguration synthesis_cfg compiliert, erwartet sie
für DUT eine Einheit mit dem selben Interface wie
"reciprocal_counter_g", also inclusive generics. Du setzt aber
"reciprocal_counter_32" ein, welche gar keine generics hat und mit
Interface Beschreibung nicht übereinstimmt.
Grüße
Klaus
irgenwie bringe ich das nicht :/
Ich habe mal das besagte Testprojekt angehängt. Das Problem liegt in
diesen Configurations, die ich nicht leider hinbekomme. Die behavioral
Simu selbst klappt.
Wäre schon, wenn hier ein Muster Bsp. für die Postsynthese mit generics
entstehen würde. Das Web ist da nicht hilfreich (zumindest mit meinen
Suchbegriffen), da nur non-generics examples exisitieren - und selbst
die Tests fallen nach der Synthese mit Web/ISE 8.1 oftmals durch.
Vielen Dank und Grüße
Olaf
so, inzwischen komme ich zur Postsynthese (abgesehen von config
Problemen aus dem Nachbar Thread), allerdings klappt der TB nicht bei
der Simu mit dem synthetisierten Modell.
Die folgende Meldung bekomme ich vom Fitter:
WARNING:Xst:737 - Found 1-bit latch for signal <arm>.
Der entsprechende Source schaut wie folgt aus:
1
entitysynchronized_gateis
2
port(
3
start:instd_logic;-- start synchronizing
4
stop:instd_logic;-- stop synchronizing
5
en:outstd_logic);-- status of synchronized gate
6
endentitysynchronized_gate;
7
8
architecturebehavioralofsynchronized_gateis
9
signalarm:std_logic;
10
begin
11
-- arming FF (asynchronous)
12
arming_ff:process(arm,start,stop)is
13
begin
14
if(start='1')and(stop='0')then
15
arm<='1';
16
elsif(start='1')and(stop='1')then
17
arm<='0';
18
elsif(start='0')and(stop='0')then
19
-- reset arming
20
arm<='0';
21
else
22
-- infer latch
23
arm<=arm;
24
endif;
25
endprocessarming_ff;
26
27
en<=arm;
28
endarchitecturebehavioral;
Soll das heissen, das er das Signal arm gleich durch das signal en
ersetzt hat? Dann wäre ISE/XST sehr geschwätzig ... Die einzige
verbleibende Meldung ist noch:
WARNING:Xst:737 - Found 1-bit latch for signal <arm>.
Ich denke, er meldet hier ein impliziet generiertes latch, welches ich
imo jedoch expliziet hingeschrieben habe.
Wie dem auch sei, die entity, welche das synchronized_gate benutzt
fängt nicht an zu zählen, ich vermute mal, da das enable signal nicht
aktiv wird:
An sich habe Einstellungen wie keep/retain hierarchy eingestellt, aber
im Post Synthese Modell fehlen mir die inneren Signale, so dass es ein
Black-Box (BB) Verhalten ist, was ich in MXE zu sehen bekomme.
Habe ich trozdem noch falsche Einstellungen, dass ich zur BB komme? Wie
kommt man solchen Problemen auf die Spur?
Viele Grüße
Olaf
Mist, die erste Fehlermedlung ist Mist, da habe ich das Falsche
gepasted. Die Meldung lautete sinngemäß:
Warning: Signal /path/to/arm minimized.
Kann heute Abend nochmals die genaue Meldung angeben.
Viele Grüße
Olaf
ich habe jetzt auch mal eine post place&route simulation gestartet, aber
nach 10 minuten wieder abgebrochen, da sich nichts tut.
dauert diese simulation wirklich so lange mit ise7.1 und modelsim?
gut, lange ist relativ und richtig sich sicherlich auch nach dem
design. ich habe eine simualtionslaufzeit von 1 ms eingestellt.
Ich habe mal mein Design (Mikroprozessor, BlocKRAM, Uart, LCD-Treiber
und Kleinkram) auch einer Post Synthese Simulation unterzogen. Das
dauert wirklich so lange ;-) Nach 45 Min. waren noch nicht mal 30ms
durch gewesen. Das kostenlose Modelsim ist aber auch ausgebremst, sonst
würde ja niemand mehr die Vollversion kaufen.
Hängt aber auch sehr von der Komplexität des Designs ab...
hier ist die aktuelle Fassung des synchronized gates. In ISE 8.1 macht
der Fitter für CPLD XC95000 Mist, habe also einen Bug erwischt (siehe
NG comp.arch.fpga).
Die Behavior Simu dauert kaum 1s bei mir (P4/2.6GHz). Die
Post-Fit/Synthese bricht zuvor ab (Selftest).
Ich nehme an, Du hast den counter selber synthetisiert und anschl.
simuliert - yep, das dauert. Aber auch, weil versch. Freq. und je Freq.
3 versch. duty cycles (90,50,10%) durchgetestet werden. Also unten im TB
nur einen Test scharf machen.
Viele Grüße
Olaf