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
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?
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.