hi kann man fpga designs auch schneller simulieren, in dem man keine waveforms verwendet? Danke!
Ja, aber die 'Beschleunigung' haengt vom verwendeten Simulator ab. Mehr Performancegewinn bringen grundsaetzlich Simulatoren, die kein delta-cycling machen, dementsprechend bremst man die mit ausgiebigem Wellenform-Tracing auch eher aus.
Also in "richtiger" Entwicklung wird eigentlich immer erstmal ohne Waveform simuliert. Die Waveforms machst du dann an wenn deine automatische self-checking Testbench einen Fehler aufgeworfen hat und du mit internen Signale debuggen willst. Mit Waveform direkt simulieren macht man eher in der Anfangsphase zum schnellen Bringup. Für sehr einfache Designs (vermutlich also fast alles im Rahmen von Uniprojekten) macht das aber nicht den großen Unterschied in der Performance.
Cle schrieb: > Mit Waveform direkt simulieren macht man eher in der Anfangsphase zum > schnellen Bringup. Wahrscheinlich mache ich keine richtigen Entwicklungen mehr, ich komme selten über die Waveformphase hinaus. 'Richtige' Testbenches zu schreiben, die alle Aspekte eines spezifischen Protokolls abdecken ist keine einfache Aufgabe. Duke
Duke Scarring schrieb: > 'Richtige' Testbenches zu schreiben, die alle Aspekte eines spezifischen > Protokolls abdecken ist keine einfache Aufgabe. Es ist einiges an Aufwand Bus Functional Models (BFM) und Transaction Level Models (TLM) für ein neues Protokoll zu erstellen aber wenn die stehen kann man die eigentliche Testbench auf einer höheren Abstraktionsebene schreiben. Bekannte Frameworks die einen dabei unterstützen sind UVM (Verilog) und UVVM (VHDL). Auf Waveforms zu starren um zu checken ob alles korrekt ist skaliert einfach nicht.
man kann auch mit kleinen Modulen einen einfachen Generator und Checker bauen. Ich muss ehrlich sagen, dass das mit Verilog (noch nicht mal SystemVerilog) viel einfacher ist, da man Tasks aus Modulen starten kann. Bei VHDL-93 ist das aus meiner Erfahrung viel schwerer. Mit VHDL-2008 und OSVVM/VUNIT/UVVM wird es schon einfacher. Ich kann nur jedem empfehlen Self-Checking-Tests zu schreiben. Nach ein paar Monaten traut man sich sonst nur noch ungern an Design-Änderungen. Allgemein läuft die Simulation ohne Waveform schneller, da keine Waveformdaten aufgezeichnet werden müssen.
Man kann auch mit relativ wenig Aufwand und unter Nutzung der Modelle aus der FMF (https://freemodelfoundry.com/) komplett virtualisierte HW aufbauen. Dann legt man noch den Clock an und flanscht externe Software/Datenlieferanten per virtuelles FIFO oder vAXI ran. Ansonsten bin ich eher Fan von selbstverifizierenden Komponenten als Schreiben aufwendiger TBs (und schon gar nicht in VHDL).
Martin S. schrieb: > Man kann auch mit relativ wenig Aufwand und unter Nutzung der Modelle > aus der FMF (https://freemodelfoundry.com/) komplett virtualisierte HW > aufbauen. Dann legt man noch den Clock an und flanscht externe > Software/Datenlieferanten per virtuelles FIFO oder vAXI ran. Das hört sich theoretisch gut an, scheitert aber meistens an der Nichtverfügbarkeit der Modelle, die man für seine aktuelle Schaltung konkret braucht. Der eigentliche Anspruch bei VHDL-Entwicklung rührt ja daher, mit neuen Systemen und veränderten Schaltungstopologien zu arbeiten und da kann man auf nichts Existentes zurückgreifen, sonst wäre es ja schon da :-) Das ist wie mit open cores: Da wird nur fündig, der noch nichts hat und schnell etwas zusammenstecken möchte. Das was es dort gibt und was eine Firma gleichzeitig auch braucht, hat sie schon, wenn man als Entwickler dort ankommt und dies oft in ausgereifterer Form, als die oft spärlich dokumentierten Cores. Schaue ich mir die Modelle der FMF an, sieht es auch da nicht unbedingt sehr "mature" aus. Was interessant wäre, sind Prozessormodelle und zwar für ganz bestimmte Anwendungen, die über das Normale hinausgehen. Dazu hatte ich vor einigen Jahren mal echten Bedarf, aber wie zu erwarten können die Modelle das eben genau nicht. Das was sie über typische Interface-Modelle hinaus können, möchte man in VHDL-Simulatoren aber eigentlich nicht simulieren. Anders herum ist es so, dass man das, was im Zusammenspiel mit CPUs wirklich interessant ist und auf VHDL-Ebene simuliert werden muss, nämlich Interfaces und low level timing, meist schon in 5-facher Ausfertigung in der Kiste hat und nur noch rasch anpassen muss. Also wait state Verhalten, min-max und Setup Zeiten im ps-Bereich. Auch die Art der unterschiedlichen Zugriffssituationen hat man in Testbenches schon x-mal realisiert und nutzt einfach copy&paste.
Was jetzt die Frage nach Waveforms angeht: Natürlich sind die nützlich. Man muss bei jedem low-level timing zumindest mal sehen, ob die Testbench überhaupt das richtige bringt, was dann beim Vergleich als Soll herangezogen wird. Manche Sachen lassen sich auch optisch einfacher und schneller verifizieren und Fehler finden, an die man nicht gedacht hat. Wenn alles mal steht kann man insbesondere für immer wiederkehrende Regressionstests eine automatisierte Testbench nehmen, besonders für die schon stabilen Funktionen, die sich bei Codeänderungen nicht ändern dürfen. > kann man fpga designs auch schneller simulieren, in dem man keine > waveforms verwendet? Was immer man rauslassen kann, spart Zeit. Hauptsparer ist aber, ungenutzte Signal nicht anzuzeigen und sie bei der Optimierung rausfliegen zu lassen. Allerdings hat man dann wieder das Problem, einen Unterbruch in Signalen zu finden, wenn es über mehrere Hierarchien geht, weil alles wegbröselt.
park schrieb: > hi kann man fpga designs auch schneller simulieren, in dem man keine > waveforms verwendet? Generell zum Thema schneller Simulieren: Mit viel Geld kann man auch schneller Simulieren dank besserer Simulatoren, weniger eingebaute Handbremse oder durch Unterstützung von Hardware-emulatoren. In meinem Alltag war ich aber noch nie in der Nähe, an so etwas zu denken, weil zu kleine Firma, zu knausrig etc. Dazu kommt, das die weitverbreiteten Simulatoren immer noch Single-Threaded sind, sie also unsere Multi-Core Prozessoren die wir mittlerweile alle nutzen gar nicht ausreizen. Was bei uns aktuell am meisten Geschwindigkeitszuwachs bringt ist das es mit vUnit sehr einfach ist mehrere Testcases in parallel gestarteten Simulatoren zu simulieren. Kann man sich natürlich auch selber so scripten.
Jürgen S. schrieb: > Das hört sich theoretisch gut an, scheitert aber meistens an der > Nichtverfügbarkeit der Modelle, die man für seine aktuelle Schaltung > konkret braucht. Der eigentliche Anspruch bei VHDL-Entwicklung rührt ja > daher, mit neuen Systemen und veränderten Schaltungstopologien zu > arbeiten und da kann man auf nichts Existentes zurückgreifen, sonst wäre > es ja schon da :-) > Naja, welche Modelle fehlen Dir da? Was Komponenten fuer klassische SoC angeht, wird man da schon fuendig (DDR3, SPI-Flash, EEPROM, usw.). Nur GHDL hatte frueher ab und an Muehe mit Vital2000-Konstrukten. > Schaue ich mir die Modelle der FMF an, sieht es > auch da nicht unbedingt sehr "mature" aus. > Da sind Modelle und jahrelang bewaehrte Simulationen vom Hersteller dabei...die sind auf jeden Fall verifiziert 'mature'. Bin noch in kein einziges Problem gerasselt. Ansonsten bekommt man auch von den Herstellern wie insbesondere DDR-Memory-Manufakturen Modelle zu spezifischen Kaefern die offenbar auch gut verifiziert sind. > Was interessant wäre, sind Prozessormodelle und zwar für ganz bestimmte > Anwendungen, die über das Normale hinausgehen. Dazu hatte ich vor > einigen Jahren mal echten Bedarf, aber wie zu erwarten können die > Modelle das eben genau nicht. Das was sie über typische > Interface-Modelle hinaus können, möchte man in VHDL-Simulatoren aber > eigentlich nicht simulieren. Wenn's nicht gerade x86 mikrocodierte Monsterpipelines sind, kann man die gut zyklengenau/timinggenau in GHDL simulieren und den Wellenformen interaktiv beim Zappeln zugucken. Kommt halt auf den Core und auf den Simulator an, RISC-V-Loesungen gibt's in VHDL einige, bei ARM sieht's mau aus, da die nur in Verilog ausgeliefert werden. Ansonsten kann man sich in der OpenSource bei qemu und skyeye fuer klassische Architekturen bedienen und seine Peripherie anflanschen, Stichwort 'Co-Simulation'. Sonst gabs von Cadence zumindest eine interessante Loesung mit entsprechendem Budget, Name faellt mir grade nicht ein. Renode scheint auch ganz flott zu werkeln, habe ich aber nur kurz angesehen, da Verilog-zentrisch. Christoph Z. schrieb: > Dazu kommt, das die weitverbreiteten Simulatoren immer noch > Single-Threaded sind, sie also unsere Multi-Core Prozessoren die wir > mittlerweile alle nutzen gar nicht ausreizen. Ich habe mich damit mal eine Weile beschaeftigt, bin zu dem Schluss gekommen, dass MT kaum Sinn macht fuer klassische V* HDL-Modelle und 'exakte' Low-Budget-Simulatoren, der Grund dafuer liegt im Delta-Cycling (Null-Zeitschritte), das bei Propagation von Ereignissen (Signal-Sensitivitaet!) in komginatorischer Logik noetig wird, bis die korrekten Resultate anliegen. Man kann aber eine Vorauswahl von strikt synchronen Prozessen machen, die moeglichst balanciert multi-threaded laufen, allerdings bringt das seltenst einen Performancegewinn, wenn die Prozesse aufeinander warten muessen. Also fuer synchrone Simulation eher problematisch, da nimmt einem auch ein SMP-Kernel das Problem nicht ab. Aber wie du sagst, mit komplett eigenstaendigen (asynchron laufenden) Prozessen gewinnt man eher, qemu und virtuelle Co-Simulation laufen jeweils auf einem Kern. Was ziemlich vielversprechend aussieht, ist das CXXRTL-Backend von yosys, das nimmt eine gewisse Vorsortierung vor und giesst sie statisch in C++. Allerdings findet da auch kein Delta-Cycling statt, das muss der aufrufende Stimulator (Testbench) selbst vornehmen, oder man beschraenkt sich auf gewisse Designregeln, damit komplett taktsynchron aufgeloest werden kann. Damit geht dann aber auch quasi mixed-HDL mit virtuellen Interfaces, etc. im MT-Betrieb, man muss aber von oben (vom Stimulatorprogramm) genau wissen, was man tut, d.h. sein eigenes Scheduling (wann welcher Simulator-Thread steppen muss) implementieren.
Christoph Z. schrieb: > In meinem Alltag war ich aber noch nie in der Nähe, an so etwas zu > denken, weil zu kleine Firma, zu knausrig etc. Man braucht z.B. das Blockset in Simulink oder nutzt nur den HDL-Coder. Als HW kann dann jedes Eval board dienen. Besonders für Bildverarbeitung hat sich das sehr bewährt. Als Beispiel habe ich von einem Projekt noch im Kopf, dass man statt 6 komplette Raumpunkte einer Regelung die per Bildverarbeitung gesteuert wurde (Flugregelung) immerhin 100 je Minute errechnen konnte. Damit lässt sich in 20-30 min die Regelgüte bestimmen und nach optimieren. Ansonsten läuft die SIM die ganze Nacht.
Der eigentliche Performance-Unterschied kommt hinzu, wenn man alle Randbedingungen aus einem gerouteten Chip per Backannotation und Best- und Worst-Case-Bedingungen in die Simulation einbezieht. Ich bin eher ein Freund der alten Schule und trenne Logiksimulation (Setup, Hold, fmax passen per Definition) und Timing-Analyse. Das gibt mir mehr Sicherheit, wenn die Timing-Analyse stimmt, als wenn eine durch Performance-Einbruch Tage dauernde Simulation nicht mit sich fertig wird. Cross-Clock-Domain-Analysen sind auch so ein Punkt, den man nur schlecht simulieren kann, oder man versucht sich hier mit Monte Carlo. Meist hat man drei Abstraktionsstufen. Auf Source-Basis synthetisiert Modelsim z. B. selbst und simuliert entsprechend schnell. (Witziger Nebeneffekt: Hier und da gibt es kleine Unterschiede in der Syntax oder Semantik und es werden Sachen angemeckert, die der eigentliche Synthesizer schon gut verdaut hatte - und/oder umgekehrt.) Man kann ansonsten eine fremdsynthetisierte Netzliste/EDIF mit typischen oder ohne Delays (Pre-PAR) oder backannotiert (Post-PAR) durchführen. Man muss allerdings trennen zwischen Simulationen zum reinen Code-Debugging und Simulationen zur Validierung der Spezifikationen. Letztere dürfen dann natürlich auch mal etwas dauern.
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.