Aufgrund einiger Projekte, die so langsam aber sich in Richtung meines
Arbeitstisches wachsen, welche von Kollegen beackert wurde, die vor
meiner Zeit in der Abteilung waren, gewinne ich immer mehr den Eindruck,
dass es VHDL-Entwickler gibt, die überhaupt nicht zu simulieren
scheinen, sondern was zusammenhacken und es direkt bauen, um dann mit
dem Oszi zu suchen.
Gibt es das?
Auch hier im Forum scheint es Leute zu geben, die keinen Simulator
nutzen wollen, wie mir solche Fragen zu suggerieren scheinen, denn mit
einer kleinen TB liesse sich das rasch erhellen.
Beitrag "Wurzel mit Xilinx Cordic Core"Beitrag "Unsigned to Signed manuell in VHDL aus Vektorebene"
Wie seht ihr das? Bis wohin muss simuliert werden?
Von den ASIC Entwicklern ist ja bekannt, dass sie glauben, die toolchain
erfunden zu haben und aufs Simulieren schwören. Da geht nichts in die
Synthese, was nicht dreimal im Simulator war.
M. F. schrieb:> Gibt es das?
Ohja, und ob! Mein Vorgänger genauso. Hat promoviert sogar auf
numerischer Simulation. Aber als Entwickler der Ober-Held. Das
Überfliegen des Summary Sheets ersetzt das Datenblatt. Simulation bei
FPGA gibts gar nicht, geklickert werden selbst die größten Projekte in
Schematic. 5 Test-Pins für den Logic-Analyzer müssen reichen. Bei 90%
Funktion ist das Projekt "fertig" und die nächste geniale Idee kann
angegangen werden. Das schärfste war mal eine DDR-SDRAM Ansteuerung:
"Wieso ein Pärchen für den differenziellen Clock benutzen? Da nehm ich
zwei I/Os und betreibe den einen mit Inverter." Und: "Jaja, ich habs
gleich." Sein schönster Spruch war: "Bei mit gibts nur eine Version und
das ist die aktuelle". Nunja, Fehlersuche kann man sich ja dann
vorstellen.
Das alles hat mich so geprägt, dass ich gleich alles bei der Übernahme
in VHDL umgeschrieben und ins SVN gesteckt habe. Außerdem eine
Simulation zu allen Modulen und zum Gesamtsystem.
M. F. schrieb:> gewinne ich immer mehr den Eindruck, dass es VHDL-Entwickler gibt, die> überhaupt nicht zu simulieren scheinen, sondern was zusammenhacken und> es direkt bauen, um dann mit dem Oszi zu suchen.> Gibt es das?
Ja. Genauso wie die Softwaregläubigen, die nur simulieren, und ein
Design als "Fertig!" betrachten, wenn die simulation einmal ohne Fehler
durchläuft...
> Wie seht ihr das? Bis wohin muss simuliert werden?
Kommt darauf an, wie komplex das gesamte Design ist. Ich habe auch schon
klein(st)e Designs ohne Simulation ans Laufen gebracht... ;-)
Aber im Normalfall wird das funktionale Verhalten einzelner Module
und/oder Submodule per Simulation sichergestellt. Und erst die oberste
Verdrahtungsebene mache ich dann freihändig, denn da kann nicht mehr
viel passieren, was man nicht auch in der Hardware sofort merken würde.
Und ab hier ist dann ein wie auch immer geartetes Versionsmanagement
unabdingbar. Denn was hilft es mir, wenn sich das Design jetzt anders
verhält, ich aber nicht mehr weiß was vorher war?
Was ich aber seit Jahren nicht mehr gemacht habe, ist eine
Timingsimulation.
> Da geht nichts in die Synthese, was nicht dreimal im Simulator war.
Jede Simulation ist genau so gut, wie die Modelle und die Testbench, die
ihr zugrunde lagen...
Wenn die Jungs dann wenigstens ein halbwegs vollstaendiges Testszenario
auf der Hardware haetten. Ich habe schonmal eine Uebernahme eines
Projekts verweigert,weil keine Testbench vorhanden war.
Rosa
Es wird halt immer wieder "Test" mit Simulation" gleichgestellt, was
IMHO sehr kurz gedacht ist. Die Simulation ist selber fehleranfällig
(modell der Peripherie, verinfachtes zeitmodell, optimistische Annahmen
über zeitliche Änderungen (Takt immer konstant), kaum Berücksichtigung
Temperatur- und Lasteinflüße). Der Vorteil der Simulatiom liegt in der
zugänglichkeit innere Zustände (Beobachtung, beieinflußung), der
Anwendbarkeit von Softwaremetriken zur Qualitätsbestimmung (Code
Coverage der Testcases, Stylecode, formale Verifikation) und der
unabhängigkeit von produktionszyklen für Hardware resp dem Aufbau von
tetumgebungen. Hat man dagegen einen funktionierenden Laboraufbau der
auf design for Test (Chipscope, testmultiplexor, LA, Scope, testtreiber)
designed wurde entfallen die meisten Vorteile.
Und ohne reale Messung kommt man über das Statement "Aber in der Simu
funktioniert" nicht hinaus. Und auf eine synthese kann man wochen
warten, weil vor lauter Simulieren verpasst wurde das timing
einzuhalten. Oder, oder oder. Simu ist kein Selbstzweck sondern Schritt
auf dem Weg. Und fertige und modulare real-life test kann man später
beim End-test und im Service zur fehlereingrenzung nutzen.
Also soweit simulieren das man sich sicher ist das Design im Prototypen
durchstartet und man damit die Testcases in echt durchspielen kann ist
m.E. eine sinnvolle Grenze. Oder anders, Pflicht ist es in der simu takt
dranzuschalten, reset wegzunehmen und config-bits setzen (das geht auch
per force signal, da muss man nicht das gesamte prozessorinterface
nachmodellieren) und schaun ob die richtigen Signal wackeln. Je nach
Bedarf (Debug) respektive unzulänglichkeit der Laborumgebung die
simulation vertiefen.
MfG,
Hallo,
ich gehe inzwischen so weit, nicht nur das FPGA-Design zu simulieren,
sondern auch den ganzen Kram darum herum zu virtualisieren.
Fremdmodule ohne eine brauchbare Testbench kommen mir gar nicht mehr in
die Tüte, musste schon öfters Reverse Engineering in dem Aufwand
betreiben, dass ich's auch selber gleich neu hätte richtig machen
können.
Ist natürlich immer eine Frage der Komplexität des Systems, aber meist
beschleunigt ein vollständiger Simulator die Entwicklung das Debugging
des Systems ungemein. Bei den "Jungen Wilden" ist einfach das saubere
Testen mit Fehlergenerierung usw. generell sehr unpopulär. Kommt auch
nur zu oft vor, dass ein erfahrener Entwicklungsleiter dem
jungdynamischen PhD zu selten auf die Finger klopft und so Wildwüchse
entstehen, die eine kleine Firma viel Lehrgeld kosten können.
Dazu kommt aber noch, dass viele Simulatoren nur bedingt gut zu brauchen
sind, und die brauchbaren Tools sehr viel kosten. Gute
Billig-Alternativen sind schwer zu finden und benötigen wiederum recht
viel Eigeninitiative was das Entwickeln von komplexeren Testmodulen (ev.
in anderen Sprachen als VHDL) angeht.
Soll aber im Endeffekt jeder selber wissen, wie er am besten zum Ziel
kommt. Oder vom Projektleiter auf die Finger kriegen :-)
>Bei den "Jungen Wilden" ist einfach das saubere>Testen mit Fehlergenerierung usw. generell sehr unpopulär. Kommt auch>nur zu oft vor, dass ein erfahrener Entwicklungsleiter dem>jungdynamischen PhD zu selten auf die Finger klopft und so Wildwüchse>entstehen, die eine kleine Firma viel Lehrgeld kosten können.
Naja, ich habe die Erfahrung gemacht, dass die "Jungen Wilden" sich eher
auf das Testbench-Schreiben einlassen als alte Hasen (z.B. unser
Teamleiter), die angeblich mit der Methode des Scharfen Hinsehens alles
hinbekommen.
Leo
Leo schrieb:>>Bei den "Jungen Wilden" ist einfach das saubere>>Testen mit Fehlergenerierung usw. generell sehr unpopulär. Kommt auch>>nur zu oft vor, dass ein erfahrener Entwicklungsleiter dem>>jungdynamischen PhD zu selten auf die Finger klopft und so Wildwüchse>>entstehen, die eine kleine Firma viel Lehrgeld kosten können.>>> Naja, ich habe die Erfahrung gemacht, dass die "Jungen Wilden" sich eher> auf das Testbench-Schreiben einlassen als alte Hasen (z.B. unser> Teamleiter), die angeblich mit der Methode des Scharfen Hinsehens alles> hinbekommen.
Meine These:
Personen mit Softwarehintergrund (Informatik, mathematiker) neigen zu
einer
Übergewichtung der Simulation, während Personen mit Hardwarehintergrund
(Bastler, abgeschlossene Elektronik-Lehre, Ing. Nachrichtentechnik)
früher zum Ausprobieren und Messen übergehen.
Gruß
Meine erste Bastelprojekte habe ich auch ganz ohne
Simulation gemacht. Wollte gar nicht wissen,
wofür es gut sein sollte.
Aktuelle Projekte werden zu 95% im Active-HDL geschrieben
und getestet. Erst dann geht es richtung Quartus (aktuell
auch ISE).
Ich hatte mal sehr blöde Fehler, die ohne Simulation
nur sehr schwehr zu finden war.
MfG
Fitzebutze schrieb:> ich gehe inzwischen so weit, nicht nur das FPGA-Design zu simulieren,> sondern auch den ganzen Kram darum herum zu virtualisieren.
ebenso
> Bei den "Jungen Wilden" ist einfach das saubere> Testen mit Fehlergenerierung usw. generell sehr unpopulär.
Woher sollten sie es auch können? Wurde lange nicht gelehrt. Inzwischen
schon.
Es ist eine Frage der Machbarkeit. Wenn Simulieren und Testen so einfach
ginge wie eben mal den Oszi einzuschalten, dann würden das sicherlich
viel mehr Leute machen, z.B. ich. Aber die reale Welt sieht (zumindest
für mich) völlig anders aus. Da ist das gesamte Thema "programmierbare
Logik" nur ein Randgebiet ohne eigenes Budget, was vom Rest der Firma
überhaupt nicht wahrgenommen wird.
W.S.
@ W.S. (Gast)
>Es ist eine Frage der Machbarkeit. Wenn Simulieren und Testen so einfach>ginge wie eben mal den Oszi einzuschalten, dann würden das sicherlich>viel mehr Leute machen, z.B. ich.
Ja komlexer das Design, umso einfacher ist Simulation im Vergleich zur
realen Messung. Und die Schwelle ist eher als sehr niedrig zu
betrachten. Allein ein normaler UART ist einfacher simuliert als per
Oszi / Logikanalysator debuggt. 100 Signale kann man sich leicht im
Simulator ansehen, im Logikanalysator wird das mal eher stressig. First
time right ist zwar eher eine Platitüde, aber auch nicht vollkommen
falsch. Eine solide, funktionierende Simulation deckt sehr viele
Probleme ab. Der Frickelansatz mit einer handvoll Testpins und Oszi geht
nur bei FPGAs. Schau dir die ASIC-Leute an, die MÜSSEN auf Teufel komm
raus simulieren, vor allem bei den heutigen Technologien mit ihrem
Integrationsgrad und den schweineteuren Masken etc.
Also ein Design das nur wenig von von aussen bekommt oder zumindest fest
definierte Daten von aussen bekommt das kann man natürlich schön
simulieren.
Ich bastel gerade mit ADCs, und will das dann über VGA ausgeben. Klar
kann man in der Testbench einen konstanten Wert als Wert vom ADC an das
zu simulierende anlegen und gucken was passiert. Aber zumindest ich kann
nicht anhand der Simulation erkennen ob z.B. das VGA Bild dann auch am
Monitor richtig aussieht und auch ob das mit dem richtigen ADC dann auch
funktioniert.
Ich bin dazu übergegangen immer wieder einzelne Bausteine zu simulieren
die man auch gut simulieren kann und andere wie mein VGA Modul das habe
ich auf der Hardware getestet.
Es gibt auch Sachen wie eben einen UART der schön funktioniert, auch
ohne Simulation. Den Teste ich dann indem ich den viele Daten schicken
und empfangen lasse und nutze die Simulation eher zur Fehlersuche wenn
etwas auf der Hardware nicht so funktioniert wie es soll.
Für mich gehe ich also sehr oft direkt auf die Hardware und simuliere
dann die Stellen an denen Fehler auftreten die ich nicht an der Hardware
sehen und herausfinden kann. So LED debugging und mit Oszi angucken
mache ich dann aber auch nicht, da finde ich eine Testbench dann
übersichtlicher.
Ich bastel aber auch nur für mich und nichts irgendwie
sicherheitskritisches oder so, es soll also schnell funktionieren und
das geht sehrgut durch Ausprobieren ob es läuft und dann einer
Fehlersuche und wo nötig muss dann simuliert werden.
Simulation ist einfach ein muss wenn man produktiv arbeiten will. Dass
das nicht als selbstverständlich angesehen wird, ist mir auch
unverständlich. Auch wenn das Generieren der Stimuli und die Auswertung
oft mehr Zeit verursacht als der eigentliche RTL Code. Bei größeren
Projekten bei jedem kleinen Problem eine neue Synthese und P&R
anzuschmeißen bis das Problem gefunden und gelöst ist, ist alles andere
als professionell. Da gehen uU Tage oder Wochen drauf für etwas was man
im Simulator in Minuten getraced hat.
Ganz so exzessiv wie bei ASICs muss man es natürlich nicht treiben. Dort
gibt es eigene Tools die prüfen ob die Testbench auch wohl jedes Signal
mindestens einmal toggelt, ob jeder Branch im RTL auch erreicht wird,
usw. Dann gibt es zB noch von Tool die zufällige Fehler einschleusen und
überprüfen wieviel die TB davon erkennt. Die Anforderung fällt beim FPGA
meistens weg, da dort keine Maskensätze im 6-oder 7-stelligen Bereich
notwendig sind und der Kunde nicht zum nächsten Tapeout warten muss.
Dennoch, bevor man da in mit ständig neusynthetisieren "herumpfuscht"
ist es doch deutlich einfacher, man schreibt sich eine kleine aber feine
TB für das Problem.
Manfred Menschenkenner schrieb:> Meine These:> Personen mit Softwarehintergrund (Informatik, mathematiker) neigen zu> einer> Übergewichtung der Simulation, während Personen mit Hardwarehintergrund> (Bastler, abgeschlossene Elektronik-Lehre, Ing. Nachrichtentechnik)> früher zum Ausprobieren und Messen übergehen.
Eher umgekehrt. Hardware-Leute wissen, wie ärgerlich Fehlersuche und
vorallem -korrektur in späteren Projektstadien ist. Software-Leute
hingegen sind sich geradezu gewohnt "mit der heissen Nadel" zu arbeiten.
P. M. schrieb:> Software-Leute> hingegen sind sich geradezu gewohnt "mit der heissen Nadel" zu arbeiten.
Hängt davon ab, die mit "modernerer" Ausbildung / Herangehensweise haben
da öfters eine andere Herangehensweise, bis zum Extremfall TDD (Test
Driven Design -> man schreibt nur Code der dazu dient einen Test der
bisher nicht geht zu erfüllen. Wird man für VHDL wohl nicht machen und
ist erstmal gewöhnungsbedürftig, hat aber auch echte Vorteile)
Christian R. schrieb:> Ohja, und ob! Mein Vorgänger genauso. Hat promoviert sogar auf> numerischer Simulation. Aber als Entwickler der Ober-Held.
Sehr unverständlich, man sollte eigentlich das Gegenteil vermuten. Da
kenne ich aber auch einige, die an der Uni Software und Simulationen
gemacht haben und dann über Umwege bei den FPGAs gelandet sind.
Entsprechend sieht der Code aus. Komischerweise stricken die teilweise
schlimmer umher, als manche, die von der HW-Schiene her kommenn.
> Simulation bei FPGA gibts gar nicht, geklickert werden selbst die> größten Projekte in Schematic.
Wie gesagt: unverständlich. Eigentlich sind es eher die alten HW-Hasen,
die so vorgehen, weil sie mal mit kleinen PLDs angefangen haben, wo man
dies noch so handhaben konnte.
> 5 Test-Pins für den Logic-Analyzer müssen reichen.
:-)
Letztlich kommt es bei der gesamten Problematik darauf an, wie komplex
das Design ist. Als Fausformel kann man sich merken:
Kleines Design, schnell synthetisierbar, wenige innere Zustände etc
sollte ohne Simulation direkt in den Test gehen. (Sagen wir mal korrekt,
die Verfikation im Bereich der Entwicklung). Ansonsten eine Simulation
ansetzen und die Komplexität der möglichen Zustände über enstprechende
cases beschreiben und mögliche Fehler abfangen. Dies stösst erst dann
wieder an seine Grenzen, wenn die Simulation zu zeitaufwändig ist und
man nur mit Echtzeittests in realistischen Zeiträumen voran kommen kann.
Dann am besten das Design stark modularisieren, die Module einzeln
qualfizieren und das System insgesamt dann mit Tests durchfahren.
Wo da die optimalen Grenzen sind, ist Erfahrungssache.
M. F. schrieb:> Von den ASIC Entwicklern ist ja bekannt, dass sie glauben, die toolchain> erfunden zu haben und aufs Simulieren schwören. Da geht nichts in die> Synthese, was nicht dreimal im Simulator war.
:-) Da ist was dran. Allerdings ist die toolchain im Bereich der
HW-Synthese in der Tat durch den ASIC-Bereich vorangetrieben worden und
die Simulation dient dort der Validierung und Sicherstellung, dass das
System wirklich läuft, weil man nicht 5x ASICs auf Probe bauen kann. Da
man das aber bei FPGAs durchaus kann, verschiebt sich der optimale Punkt
des Übergangs von der Simulation zur Synthese sowohl aus praktischer als
auch wirtschaftlicher Sicht deutlich weiter nach vorn, d.h. es wird
früher synthetisiert, wenn das Design noch nicht angenommen fertig
läuft. Dass dies sinnvoll ist, ist offenkundig, dennoch sind zu dieser
Schlussfolgerung viele ASICler in der Tat nicht in der Lage.
Juergen S. schrieb:> Letztlich kommt es bei der gesamten Problematik darauf an, wie komplex> das Design ist. Als Fausformel kann man sich merken:>> Kleines Design, schnell synthetisierbar, wenige innere Zustände etc> sollte ohne Simulation direkt in den den Test Design gehen. Ansonsten> Simulation ansetzen und die Komplexität der möglichen Zustände über> enstprechende cases beschreiben und mögliche Fehler abfangen. Dies> stösst erst dann wieder an seine Grenzen, wenn die Simulation zu> zeitaufwändig ist und man nur mit Echtzeittests in realistischen> Zeiträumen voran kommen. Dann am besten das Design stark modularisieren,> die Module einzeln qualfizieren und das System insgesamt dann mit Tests> durchfahren.>> Wo da die optimalen Grenzen sind, ist Erfahrungssache.
tja, wenn's so einfach waere...
Meine Meinung: Eine Simulation mit TB, bevorzugt 'self-checking', hat 2
riesige Vorteile:
1.) Du kannst es einfach mal uebers Wochende laufen lassen und hast
Montags ein aussagekraeftiges Ergebnis
2.) Eine TB ist eine klasse Dokumentation, wie denn das Modul/der Design
funktioniert. Besser als eine separate Doku die dann meist veraltet ist
Ich habe frueher auch 'chips' gemacht. Da geht ohne Simulation gar nix.
Neue Masken sind schweineteuer, ganz zu schweigen von einem
'show-stopper' bei dem du neues Silizium brauchst. Beim FPGA ist das
wesentlich entspannter. Aber auch da gehoeren fuer mich TB(s) dazu, die
wenigstens den einfachen Gutfall durchfahren (siehe oben Punkt eins und
vor allem Punkt zwei).
Und klar, "wenn" dein Design "sauber" ist (synchron, nur eine Clock,
keine ueblen Sauereien), dann kannst du verschiedene Komponenten auch
mal neu zusammenstellen und einfach auf die HW geben. Aber eine einfache
TB kostet da nicht wirklich viel Zeit...
Ich habe sowohl privat als auch auf Arbeit momentan aehnliche FPGAs
laufen: Ein Dateninterface (privat ein RaspPi, im Geschaeft ein recht
dicker uC) und sonstige periphere Interfaces. Und ich habe fuer beide
Typen einen TB-Rahmen geschrieben, um das FPGA wirklich 'von aussen' zu
stimulieren und sich selber zu checken. Damit kannst du extrem schnell
und sauber auch ein neues Projekt aufsetzen. Und ich hab's im Geschaeft
(fuer die gleichen internen Designs) mit X, A, und L zu tun. Da gewoehnt
man sich recht schnell einen halbwegs sauberen und modularen Stil an...
Also mein Fazit: Lieber mehr TB als weniger
Und: Ich kann keine Unterscheidung zwischen Alt und Jung sehen. Es
haengt wirklich vom Background ab (imho)
berndl schrieb:> Juergen S. schrieb:>> Wo da die optimalen Grenzen sind, ist Erfahrungssache.> tja, wenn's so einfach waere...
Alles, was man entscheidet basiert letztlich auf Erfahrung. Ich
simuliere heute wo ich früher real probiert hat und umgekehrt. Ist ein
fliessender Prozess, der auch viel mit der Entwicklung der
Chipstrukturen zu tun hat.
> Also mein Fazit: Lieber mehr TB als weniger
Das unterschreibe ich zu 100%!
> Eine Simulation mit TB, bevorzugt 'self-checking', hat 2> riesige Vorteile:> 1.) Du kannst es einfach mal uebers Wochende laufen lassen und hast> Montags ein aussagekraeftiges Ergebnis
Wenn man die Zeit hat, ja. Unterschreibe ich zu 90%.
> 2.) Eine TB ist eine klasse Dokumentation, wie denn das Modul/der Design> funktioniert. Besser als eine separate Doku die dann meist veraltet ist
Nun ja, das Ergebnis der TB/Simulation ist die Doku, wobei die TB einem
stark hilft, sich in unbekannte Designs einzudenken, weil man sieht, was
das Design könnten sollte und welche Fälle der Ersteller im Kopf hatte
und mutmasslich im Design dann auch realsiert und abgefangen hat, bzw.
was er so alles nicht in der TB hat und nicht abgefangen hat und das
design folglich nicht kann, aber nun können soll. Damit ist eine TB für
mich eine Art Pflichtenheft, oder nennen wir es Requirement-Set.
Juergen S. schrieb:>> Simulation bei FPGA gibts gar nicht, geklickert werden selbst die>> größten Projekte in Schematic.> Wie gesagt: unverständlich. Eigentlich sind es eher die alten HW-Hasen,> die so vorgehen, weil sie mal mit kleinen PLDs angefangen haben, wo man> dies noch so handhaben konnte.
Genauso wars bei ihm auch. Er "entwickelt" schon ewig Hardware und
Software und Verfahren und überhaupt alles, aber immer mit der selben
Arbeitsweise. Das meiste funktioniert zwar so irgendwie, aber bei 90%
Funktionalität ist er "fertig" und wehe es tritt mal irgendwo ein Fehler
auf.
Ich komme auch von der Software her. Da probiert man nach dam
Compilieren mal schnell aus, und guckt hier und da.
Das ist bei VHDL/FPGA schwieriger, das kann man keine printf's
einstreuen.
Nach frustrierenden Fehlersuchen bin ich hdazu übergegangen, jedes Modul
zu simulieren. Das geht auch zeitlich schneller als Synthese und
Osziloskop (etc). Und man kann alle Möglichkeiten durchpermutieren.
Und man findet wirklich gut die Fehler: 'Huch, warum ist das Signal da
immer noch Low, und warum kommt das erst einen Takt später'.
Nicht mehr ohne Simulation.
Zumal man sich die gut als Unit-Tests mit einchecken kann, wenn man mal
später etwas ändert und dann schauen muss, ob noch alles geht.
Ich simuliere immer weniger, auch wenn die Designs komplexer werden. Das
hat viele Gründe: Zeitmangel, Trivialität der Module, Simulationszeit zu
lang und so weiter.
Sicher, ein DDR3 Design würde ich lieber simulieren, bevor ich es
einsetze, aber meist funktioniert es einfach out-of-the-box. Die
IP-Cores (bei Altera) sind ausgereift, die Verschaltung recht
übersichtlich.
Bevor ich anfange eigene Module zu machen, überlege ich schon etwas
länger... Aber mit einer TB anzufangen würde ich nicht machen, wenn man
gute Erfahrungen ohne hat.
In den ersten Jahren habe ich viel simuliert (SPI, UART und zeugs) Mit
den Jahren sieht man dann doch, dass alles immer dasselbe ist, man muss
nur die Probleme in kleinere Häppchen aufteilen ;-)
Oft baue ich allerdings Zusatzlogik rein, um die Vorgänge zu
kontrollieren (bestimmte Bittmuster einspeisen, Daten durchnummerieren,
...) Also sozusagen eine TB im FPGA.
Kest
Kest schrieb:> Ich simuliere immer weniger, auch wenn die Designs komplexer werden. Das> hat viele Gründe: Zeitmangel, Trivialität der Module, Simulationszeit zu> lang und so weiter.
Zeitmangel ist ein schlechtes Argument. Entweder ist die Simulation
angezeigt, um effektiv ins Ziel zu kommen oder nicht. Wenn sie es ist,
darf sie auch nicht ersetzt werden. Der Hauptgrund ist meist die
Verwendung von Cores, die schon fertig sind und deren Verhalten und
Timing bekannt sind. Die sind dann einfach zu verbauen. Bei
Selbstgeschriebenem, vor allem dem Steuercode im Design, geht das
weniger. Ich simuliere an einer FSM mit 10 states daher auch erheblich
länger rum, als einer kompletten FFT :-)
> Oft baue ich allerdings Zusatzlogik rein, um die Vorgänge zu> kontrollieren (bestimmte Bittmuster einspeisen, Daten durchnummerieren,> ...) Also sozusagen eine TB im FPGA.
dito. Läuft bei mir unter testfreundlicher Entwicklung. Da gibt es
etliche sinnvolle Methoden, die ungenutzt in Büchern dahin dämmern. Ich
hatte das Glück bei einem Prof zu studieren, der diesbezüglich ein
echter Verfechter war und das früh verinnerlicht. Mich wundert, dass
sich das nicht stärker verbreitet hat.
PittyJ schrieb:> Ich komme auch von der Software her. Da probiert man nach dam> Compilieren mal schnell aus, und guckt hier und da.
Klar, musst ja keine HW bauen, sondern nur nutzen. Bei einem NIOS System
wird's bei FGPAs ja genau so gemacht.
> Das ist bei VHDL/FPGA schwieriger, das kann man keine printf's> einstreuen.
Das ginge schon, man kann es im Ggs. zu Software sogar weitgehend ohne
Beschädigung der Laufzeiteigenschaften, indem man einen Serial Core
nutzt, der Daten ausgibt, nur ist es bei FPGAs ja so, dass sie gehörige
Daten produzieren und umherschauffeln und das kann kaum per klassischem
Monitoring beobachtet werden. Dafür kann man kleine Oszilloskope und
Zeichensätze ins FGPA bringen, die Daten direkt anzeigen. Damit geht
einiges.
Karl Könner schrieb:> Und ohne reale Messung kommt man über das Statement "Aber in der Simu> funktioniert" nicht hinaus. Und auf eine synthese kann man wochen> warten, weil vor lauter Simulieren verpasst wurde das timing> einzuhalten.
Wieso sollte man "verpassen", das richtige timing einzuhalten? Und wie
könnte eine Messung hier helfen? Die Synthese liefert doch den Hinweis,
dass das timing nicht passt, nicht die Messung. Oder an was hast Du nun
gedacht?
M. Fritsch schrieb:> Karl Könner schrieb:>> Und ohne reale Messung kommt man über das Statement "Aber in der Simu>> funktioniert" nicht hinaus. Und auf eine synthese kann man wochen>> warten, weil vor lauter Simulieren verpasst wurde das timing>> einzuhalten.> Wieso sollte man "verpassen", das richtige timing einzuhalten? Und wie> könnte eine Messung hier helfen? Die Synthese liefert doch den Hinweis,> dass das timing nicht passt, nicht die Messung. Oder an was hast Du nun> gedacht?
Ich seh das ähnlich wie Karl Könner.
Die Synthese liefert kein exaktes timing, erst nach place und route
steht die Verdrahtung und damit die propagation delays fest. Da aber ein
kompletter designflow eine halbe Stunde braucht, wird das gern auf einen
zeitpunkt nach Abschluß der Simulation verschoben. Also nicht 30 min
synthese + place und route sondern nur 10 sek modelsim compile und test
case simulation (geht ja schneller).
Meist verschiebt sich so die Fertigstellung des timings kurz vor
Freigabe, weil "die paar picosekunden schafft die volle Optimierung
noch". Schafft die Tools-intelligenz aber nicht, weil je "voller desto
schwieriger zu routen " und künstliche Intelligenz ist nun mal nicht
wirklich intelligent sondern nur stures rumschieben von Logic und
routing-resourcen. Aber man verbrennt erst mal ein paar Mann-Tage mit
ausprobieren aller optimierungs-schalter
Nun dann doch Umbau des Designs "pipeline stufen rein, und nicht selten
die spec umschreiben (zusätzliche Latenz einbauen, adressdecoder
vereinfachen etc). An einem fertigen design ist das natürlich
schwieriger wegen Seiteneffekte und der nötigen Wiederholung aller Test.
Besser täglich volles "Place und Route" durchziehen, um Flaschenhälse
sofort zu erkennen und am Design beseitigen. Manchmal hilft ein
einzelnes Location constraint, was natürlich einfacher zu finden ist,
wenn es noch nicht zuviel zu locaten ist.
Und ich erinnere mich an eine Trickschaltung (3 ns _puls im Spartan 3
erzeugen) eines alten Hasens die in der Simu wunderbar funktionierte
aber nicht in echt, der Puls war immer länger als erwartet (Scope), da
half auch kein umlöten der C am Besselfilter. Oder ein rumdrehen an den
anderen Design-ecken. Ursache war das die Laufzeit zum synchronen Reset
des FF eine andere ist als die zum asynchronen (pre-)set. Eine
behaviroul Simu weiss davon leider nichts....
"Messung" bezieht sich bei Karl aber wohl eher auf den "Aber in der Simu
funktioniert" Fall, weniger auf das timing. Es war schon mancher
überrascht das die Signale vom DSP mit invertierter Polarität oder Takte
früher/später einliefen als in seinem Simulationsmodell. Kommt schon mal
vor das man das Datenblatt von der nichtbenutzten Betriebsart verwendet.
Oder der DDR-Ram mit einer anderen timings (Latencies) angesteuert wird
als beim Powerup konfiguriert. Oder big statt little endian. Oder lsb
statt msb first, oder oder. In der Simu stecken eben auch nur Modelle
und nicht das wirkliche leben. Da verhilft am schnellsten eine Messung
(LA,DSO) zum Abgleich Simulation/Realität.
MfG,
Fpga Kuechle schrieb:> Meist verschiebt sich so die Fertigstellung des timings kurz vor> Freigabe, weil "die paar picosekunden schafft die volle Optimierung> noch".
Ist das wirklich so? Wer arbeitet so?
> Nun dann doch Umbau des Designs "pipeline stufen rein, und nicht selten> die spec umschreiben (zusätzliche Latenz einbauen, adressdecoder> vereinfachen etc). An einem fertigen design ist das natürlich> schwieriger wegen Seiteneffekte und der nötigen Wiederholung aller Test.> Besser täglich volles "Place und Route" durchziehen, um Flaschenhälse> sofort zu erkennen und am Design beseitigen.
Jo!
high tec ing schrieb:> Fpga Kuechle schrieb:>> Meist verschiebt sich so die Fertigstellung des timings kurz vor>> Freigabe, weil "die paar picosekunden schafft die volle Optimierung>> noch".> Ist das wirklich so? Wer arbeitet so?
Weltkonzern mit zwei Buchstaben (Hinweis: R&S ist nicht gemeint).
MfG
anynmous schrieb:> Na das wollen wir jetzt aber wissen.>> Ein Halbleiterhersteller? BB? TI? NS? AD?>> Oder ein OEM? GM? VW? AT?>> Sicher nicht H&M oder C&A?
Halbleiterhersteller machen nicht in FPGA (außer FPGA-Hersteller ;-) ),
Automobilhersteller auch nicht die kaufen zu (Alpine, Magna, Bosch) oder
lassen von Leiharbeitern frickeln. Gesucht ist dadegen ein
Elektro-(misch)-Weltkonzern mit zwei Buchstaben, da ist die Auswahl nun
wirklich überschaubar, auch seit es S+H (Siemens+Halske) nicht mehr
gibt. Abgesehen davon das diese im Röhrengechäft tätig waren.
MfG,
Fpga Kuechle schrieb:> Gesucht ist dadegen ein> Elektro-(misch)-Weltkonzern mit zwei Buchstaben, da ist die Auswahl nun> wirklich überschaubar
Diese Frickel-Bude! Mit denen (USA) haben wir ein Projekt (wir liefern
Hardware und Software). Wenn wir das vorher gewusst hätten, hätten wir
den Auftrag abgelehnt. Kann ich mir gut vorstellen, wie das intern bei
denen zugeht.
Fpga Kuechle schrieb:> Halbleiterhersteller machen nicht in FPGA
Teile von digitalen ASICs werden schon gern mal auf schönen
FPGA-Prototyping-Gräbern vorab untersucht. Gängige Praxis.
Panzer H. schrieb:> Fpga Kuechle schrieb:>> Halbleiterhersteller machen nicht in FPGA>> Teile von digitalen ASICs werden schon gern mal auf schönen> FPGA-Prototyping-Gräbern vorab untersucht. Gängige Praxis.
Würde ich auch gesagt habe. Keine keinen Hersteller, der Asics macht,
der nicht vorher prototyped.
>GE
General Electric kann es nicht sein. Das ist ein ganz grossartiger
Konzern mit super gut aufgestellten BUs, die mit ihren Produkten überall
drin sind. Hab ich in der Werbung gesehen!!
Panzer H. schrieb:> Fpga Kuechle schrieb:>> Halbleiterhersteller machen nicht in FPGA>> Teile von digitalen ASICs werden schon gern mal auf schönen> FPGA-Prototyping-Gräbern vorab untersucht. Gängige Praxis.
Hm, das hab ich zwar auch so gelernt, aber passend zum Thread-topic
sollte man das hinterfragen. Hier in diesem Thread wird doch die
Simulation als DAS Test-tool propagiert aber jetzt FPGA-Prototypen zum
Test? Ich kenn beispiele wo FPGA-Prototypen für Treiberentwicklung
eingesetzt werden, die Designüberprüfung findet dagegen im Cluster mit
Simulationen oder formaler Verifikation statt. Nokia hatte FPGA-Handys
im Einsatz um eigene Basestations zu testen (geht schlecht mit modelsim)
oder um bei der LTE-Standardentwicklung schnell ein paar proposals
anzutesten.
Der große Nachteil an FPGA- Prototypen ist die schlechte Beobachbarkeit
von internen Zuständen (FSM, BRAMS,...). Man kann zwar schnell x
Testpattern durchnudeln und schauen ob das erwartete rauspurzelt. Was
aber genau bei einem "Test Fail" schiefgelaufen ist und was im ASIC zu
patchen ist bleibt erstmal ungeklärt. Und FPGA-timing im Vergleich zu
ASIC-timing ist selten das gleiche. Ich schätze, das bei ASIC's die
Simulation mindestens die gleiche Testtiefe und -güte erreicht wie
FPGA-Prototyp und der FPGA eher als Prototyp für die Softwareentwicklung
und system-evulation eingesetzt wird, denn als (einziges) Mittel zur
Validierung des RTL-Designs.
Irgendwer hatt mir mal erzählt , das man bei FPGA-Prototyping u.U. mehr
Fehler bei der FPGA-Synthese und in der FPGA-Toolchain aufdeckt als
Fehler im (vorab tiefst simulierten) ASIC-Design.
MfG,
Christian R. schrieb:> Wir sind das GE in GEscheitert.
geil!!!!! Wenn Du jetzt in München wärst, würde ich Dir dafür ein Bier
ausgeben!!!!
Fpga Kuechle schrieb:> Hier in diesem Thread wird doch die> Simulation als DAS Test-tool propagiert aber jetzt FPGA-Prototypen zum> Test?
Simulation -> Verfikation und Valdierung
Prototying -> Baugruppentest und Funktionstest
> Und FPGA-timing im Vergleich zu ASIC-timing ist selten das gleiche.
Das wird nicht in Echtzeit gemacht. Der Digitalteil und funktionelle
Modelle des Analogteils werden abgebildet und mit der machbaren
Geschwindikeit laufen lassen. Die Testvektorenvon Aussen kommen
entsprechend langsam. Im Prinzip eine HIL Simulation.
GE (Generous Electric! :-) kann es gaaanz wirklich nicht sein, da ist
definitiv alles im Griff. Was alle gegen den Laden haben .... so
schlecht ist der doch nicht.
Fpga Kuechle schrieb:> Hm, das hab ich zwar auch so gelernt, aber passend zum Thread-topic> sollte man das hinterfragen. Hier in diesem Thread wird doch die> Simulation als DAS Test-tool propagiert aber jetzt FPGA-Prototypen zum> Test?
Das eine ersetzt ja das andere nicht! Das läuft Hand in Hand.
Ich kenne diese Vorgehensweise aus der Videoverarbeitung.
Es macht keinen Spass, irgendwelche Videoformate tagelang zu simulieren,
die Testbenches müssten ja auch mal erstellt werden; also:
Verarbeitungsengine im FPGA geprototyped, Datenquelle und Datensenke
angestöpselt und geschaut, ob ein Bild kommt. B-)
Ganz so einfach ist es nun auch wieder nicht, denn die Testfälle müssen
ja die mögliche Realität kapseln und dazu müssen die Quellen die
Testfälle hergeben. In der Regel braucht es also paramtrierbare Quellen,
die gesteuert werden.
Allerdings kann man soetwas (Test und Simulation) sehr schön
kombinieren:
Niemand schreibt einem vor, dass Testbenches nur im Simulator laufen
müssen. Wenn sie synthesefähig gemacht oder gehalten werden, kann man
sie auch einfach vor seinen Eingang hängen (oder stattdessen) und die
Testfälle in Echtzeit abspulen lassen. Letztlich ist es auch hier wieder
nur eine Frage, wie lange dauert - je Entwicklungsschritt - die
Simulation im ogischen Simulator und wie lange dauert sie dagegen als
Echtzeittest, wo noch mindestens eine Synthese mehr dazu kommt. Irgendwo
beginnt der real Test zu lohnen.
Real aufgebaute Testfunktionen im VHDL-Design können zudem auch als
Power-ON-Selbsttest und zum Baugruppenendtest in der Fertigung verwendet
werden.
Es gibt Dinge, die kann man mit einer Testbench testen. Und andere eben
nicht. Die Testbench geht genau so weit, oder zumindest fast soweit wie
ein Modell der Umgebung existiert, resp es hinreichend genau ist. Ein
Entwicklungsprozess ist eine dynamische Sache.
Speziell wenn ein Controller an das FPGA angeschlossen ist kann viel
schiefgehen. Wenn das Interface zwischen den Beiden nicht identisch ist
hat man ein Problem. Damit ist jetzt nicht ein paar Datenleitungen und
Handshakes gemeint, sondern Funktionalitaet.
Zu irgend einem Entwicklungs-Zeitpunkt wird Funktionalitaet durch das
Interface verschoben - "weil's auf der anderen Seite geschenkt ist".
Diese Aenderung muss auf der anderen Seite auch ankommen und nicht als
"mach ich gleich, aber erst mal noch ..." enden.
Dh man kann nicht genug in Hardware testen, und sei es auch nur um zu
sehen, dass das Modell noch mit der Realitaet uebereinstimmt.
Siebzehn mal Fuenfzehn schrieb:> Speziell wenn ein Controller an das FPGA angeschlossen ist kann viel> schiefgehen. Wenn das Interface zwischen den Beiden nicht identisch ist> hat man ein Problem.
Sagen wir mal, "wenn es nicht komplementär" ist, hat man Probleme. Sows
lässt sich aber auch der Logikebene gut teste, weil ein Controller immer
nur Standardzugriffe (RAM-like) macht. Problem ist, wenn die Abläufe
nicht passen. Das ist aber dann Funktionelles Desin.
> Dh man kann nicht genug in Hardware testen, und sei es auch nur um zu> sehen, dass das Modell noch mit der Realitaet uebereinstimmt.
Unterschrieben. Ich veweise an diesem Punkt auf eigene Erfahrungen mit
ASIClern, die sich teilweise pathologisch weigern, eine Synthese zu
initiieren und sich lieber totsimulieren.
