Mal ein Diskussionsbeitrag was ihr dazu haltet..
Ich bin mir noch nicht sicher, ob dies etwas neues ist oder von Cadence
gerade nur neuverpackt gepusht wird.
System-Verilog Real Number Modeling (SV-RNM) ist eine event-basierte
Beschreibung und soll es ermöglichen Mixed-Signal (analog und digital)
in einem digitalen Simulator komplett zu simulieren. Hierbei muss
natürlich das analoge Modell in eine SV-RNM Modell umgewandelt werden.
Im Unterschied zu V/VHDL-AMS zuvor wird es nicht auf Konvergenz-Lösern,
sondern zeitdiskret gelöst. (prinzipiell bedingt ungenauer, aber
wesentlich schneller).
Nun gibt es den real-type auch in VHDL. Gibt es da ein Package das auch
in diese Richtung wie SV-RNM schießt? oder kann VHDL das gar nicht?
Ich kenne das System jetzt nicht, würde aber sagen, dass es sicher
Optionen bietet, weil sie es sonst nicht anbieten würden.
Generell kann man sagen, dass man "Analoges" in der Tat sehr einfach
durch diskrete digitale Systeme modellieren und simulieren kann, wobei
sich "einfach" darauf bezieht, eine simple Beschreibung und
Vorgehensweise zu haben. Ob sie effektiv ist, steht auf einem anderen
Blatt. Der Knackpunkt dabei ist die Rechenzeit und die ist heute eine
gänzlich andere, als noch vor 10-15 Jahren, als VHDL/AMS den großen Hype
erlebte.
Ich bin öfters in Sachen Analogsimulation unterwegs, um angeflanschte
Elektronik mitzusimulieren und nutze dazu gerne diskrete Beschreibungen
in VHDL mit ModelSIM. Das kann man soweit treiben, dass man das
Verhalten realer Elektronik als black box mitrechnet um prädiktive
Aussagen über deren Verhalten machen und korrektes Funktionieren
beurteilen zu können.
Man "leidet" natürlich unter der begrenzten Genauigkeit, die dazu führt,
dass man mit linearen zeitdiskreten Simulationen erst einmal nur solche
Prozesse sauber abgebildet bekommt, deren Grenzfrequenz weit unterhalb
der Auflösung der Simulation liegt. Z.B. kann man Schwingungen im
Ultraschallbereich absolut hochgenau in Echtzeit berechnen, wenn man mit
einigen ns auflöst. Bei der Berechnung von selbstschwingenden
Oszillatoren z.B., die über physikalische Parameter und
Differenzquotienten gerechnet werden, kommt man bei Audiofrequenzen gut
und gerne auf 18Bit und mehr.
http://96khz.org/doc/vasynthesisvhdl
Im Gegensatz zu einer DDS verhalten die sich dann richtig natürlich und
reagieren in Echtzeit weich und auch mit Überschwingern auf
Parameteränderungen. Für gesteigerte Auflösungen und Frequenzen, kann
man das durch einfaches Verrauschen und Filtern verbessern. Geht so in
Richtung Dithering. Das hat aber Grenzen!
Für komplizierte, gegengekoppelte- oder gar differenziell gekoppelte
Systeme, wie man sie in technischen Anwendungen hat, muss man deutlich
mehr tun - z.B. durch gezielte oversampling-Methoden, die lokale Punkte
bearbeiten, Rechnungen mehrfach und mit verrauschten Parametern
durchführen und interpretieren und einigem mehr, wie das z.B. beim anti
aliasing beim 3D-Rendern an Kanten geschieht.
Soetwas muss man derzeit oft noch per Hand implementieren, geht nicht
ohne Weiteres in Echtzeit und ist auch nicht ohne strikte Optimierungen
und Strategien effektiv. Ich kann mir durchaus vorstellen, da einiges zu
automatisieren und zu verbessern.
Wo ich Einsatzgebiete sehe, ist die HW-gestützte Simulation mit
FPGA-Plattformen, weil sich die konkrete Schaltung und Physik dort gfs
sehr einfach durch den Nutzer formulieren und hineinsynthetisieren
lässt, dann entsprechend schnell läuft und so nicht mehr in z.B. MATLAB
vor sich hin eiern muss.
Moin,
bei den teuren Co-Simulations-Tools kann ich nicht mitreden, obwohl ich
da immer mal wieder auf der Embedded World spannende Sachen sehe. Aber
eben nur sehe :-)
Bestimmt haben diese Tools ne Menge Power, aber es sind auch
entsprechend Investitionen nötig (nicht nur in die Tools/Schulungen,
auch ne Menge Einarbeitung). Da ich aus 'Jux und Dollerei' erst mal nur
Eigenblut investieren wollte, bin ich bei GHDL/VHPI und Python/MyHDL
gelandet. Gibt da ne Menge netter Module (NumPy, CocoTB, ...) die
Wiederverwertbarkeit ist prima, und die Sache deutlich weniger
schwerfällig als die ganzen System*-Ansätze. Am Schluss sind es aber
vermutlich eben diese Kriterien wie Geschwindigkeit, besonders bei
komplexen Designs, wo event-getriebene interpretierte Simulatoren (in
dem fall der Python-Interpreter) an die Grenzen kommen und man tiefer in
die Tasche greifen/oder selber optimierten Code schreiben muss, um z.B.
einen Spice-Simulator mit VHDL zu verklinken. Über VHPI geht das im
Prinzip recht elegant, da kann man mit GHDL schöne Sachen machen. Qucs
hat eine VHDL-Extension drin, wie gut die mit den (teils exzellenten)
Analog-Modellen cosimuliert, kann ich nicht sagen.
Die Platzhirsche könnten sich allerdings mal darauf fokussieren,
Standards sauber zu implementieren (wie z.B. eben VHPI) und da auch APIs
designen, die von aussen für vom Kunden/User angepasste Cosimulation
genutzt werden kann. Bin mir nicht sicher, ob ModelSim FLI da ausreicht,
um Daten mal eben durch ein komplettes Spice-Modell zu routen und wieder
zurück, um z.B. eine komplette SDR-Mischerstufe mal durchzusimulieren,
und zwar schrittweise getrieben.
Leider geht die Tendenz immer mehr in Richtung "Möglichst kompliziert
und von uns abhängig.", also wird man möglichst den Standard a) vorgeben
und lizenzieren oder b) genug gut verstümmeln, dass Drittparteien nicht
plötzlich das bessere Tool anbieten können. Insofern frage ich mich, ob
der SV-RNM-Kram eine wirkliche Neuerung gegenüber pragmatischen Lösungen
darstellt, oder nicht halt einfach ein weiteres Patchwork ist, um die
für Cosimulation grundsätzlich mager ausgestattete Sprache Verilog
aufzuproppen.
Gruss,
- Strubi
Hallo,
wir haben verschiedensten Möglichkeiten für Co-Simulationen
Matlab/Simulink mit VHDL/Verilog bzw. Spice mit VHDL. Gegenwärtig
benutzen wir in keinem Projekt eine Co-Simulation. Jedes für sich
(Matlab/Simulink; VHDL/Verilog; Spice) wird benutzt, aber eben nicht
zusammen.
Für kleinere analoge Sachen (ADC, DAC, PCM) um einen FPGA herum schreibe
ich mir VHDL-Modelle. Üblicherweise reicht es, diese mit einem
(modulierten) Sinus anzuregen, geht auch wunderbar in VHDL, selbst
einfache Regestrecken sind kein Problem.
Ein großer Vorteil einer Co-Simulation Matlab-VHDL ist, dass beide in
einem eigenen Prozess laufen und damit je einen Core des Prozessors
benutzen. Konfrontiere damit mal Cadence.
Z.B. haben wir mal in einem Projekt ein Motor-Modell mit H-Brücke in
Simulink modelliert und über das FLI dann mit Modelsim verknüpft. Da
beide Hersteller diese Lösung unterstützen, hat das auch wunderbar
funktioniert.
Tom
Thomas R. schrieb:> Ein großer Vorteil einer Co-Simulation Matlab-VHDL ist, dass beide in> einem eigenen Prozess laufen und damit je einen Core des Prozessors> benutzen. Konfrontiere damit mal Cadence.
Das ist auch noch ein echt wichtiger Knackpunkt, damals als ich mir div.
Lösungen angesehen habe, war Modelsim weder ein teures Tool von Cadence
(vergessen, wie es heisst) nicht wirklich kntrollierbar multicorefähig,
aber das ist schon ein paar Jahre her. Als ich die Jungs auf verteilte
Simulation im Cluster angesprochen habe, wurde es auch erst mal wenig
konkret. Inzwischen habe ich kapiert, dass das sich 'event-basiert' und
'multithread' u.U. ziemlich beissen und ausbremsen können.
Was die Interfaces angeht: Angenommen, es ist eine komplexere
Regelschleife in VHDL zu stricken, die eine Analogschaltung (PLL, o.ä.)
mit einbezieht. Da müssen für jeden Zeitschritt Daten zwischen der
Analog-Sim und VHDL-Sim hin und her. Da würde mich mal interessieren, ob
Modelsim per FLI in der Lage ist, schrittweise durchzulaufen, ohne dass
sich die Threads allzusehr idle-locken (was bisher der Grund war, die
sachen schlicht single-threaded zu implementieren).
Ich meine, die MultiCore-Thematik müsse ziemlich an Bedeutung verlieren,
wenn die Arbeit von der HW gemacht wird, oder? Nach meinen Beobachtung,
besonders was SystemGenerator mit Simulink angeht, ist das
Tempobestimmende fast ausschließlich der Flaschenhals, der sich durch
die Übergabe des Testvektoren und Daten ergibt, als z.B. PCI oder
ETHERNET.
Die für mich interessante Frage hierbei wäre, ob es das CADENCE-Tool
schafft, die zu Emulation von RN erforderliche Genaugikeit so in
Rechenschritte abzubilden, dass diese in parallele HW ins FPGA fließen.
Jürgen S. schrieb:> Ich meine, die MultiCore-Thematik müsse ziemlich an Bedeutung verlieren,> wenn die Arbeit von der HW gemacht wird, oder? Nach meinen Beobachtung,> besonders was SystemGenerator mit Simulink angeht, ist das> Tempobestimmende fast ausschließlich der Flaschenhals, der sich durch> die Übergabe des Testvektoren und Daten ergibt, als z.B. PCI oder> ETHERNET.
Verstehe ich das richtig, du meinst also, dass man das Modell der
Analogkette per Simulink in HDL übersetzt, und damit auf dem FPGA den
Analogteil nachbildet, um die Regressionstests schneller abzuspulen?
Ich bin mir nicht sicher, ob das ausreicht, um komplexe Analogtechnik
ausreichend durchzusimulieren, gerade im HF-Bereich, wo man z.B. auch
MosFET-Modelle nicht mehr mal eben linear approximieren kann, und eben
hohe Taktzyklen eine Rolle spielen.
Wenn man da die Qualität der SPICE-Simulationen erreichen will, braucht
man doch sicher recht dicke FPGAs..
Kann Simulink denn einfach mal ne HF-Stufe auf dem FPGA virtuell
instanzieren? (vor 10 Jahren war das schon mit ner DSP-Pipeline eher
dürftig, fand ich). Oder wo kommt man da an die Grenzen?
Ansonsten finde ich es auch sinnvoll, für Regtests ab einem gewissen
Punkt in die HW zu gehen, wenn gewisse "Basics" in der Simulation
bewiesen sind und man da keine Fehler mehr suchen muss.
Prinzipiell geht das sicher, das Modell muss eben her. Generell ist es
so, dass die Sache in VHDL und damit auf Hardware um Zehnerpotenzen
schneller läuft. Ob allerdings alle Anwendungen sinnvoll in diskrete
Modelle zu übersetzen sind, kann ich auch nicht beantworten. Von der
ersten Betrachtung her würde ich sagen, nein.
Allerdings habe ich selber ein sehr nettes Gegenbeispiel einer
Applikation im Bereich BH-Kennlinienberechnung, konkret dem
hochfrequenten Verhalten magnetischer Werkstoffe. In pSPICE war das kaum
zu machen, weil die damals verfügbaren Modelle (Carpenter,
Jiles-Atherton) nur unzureichend zu simulieren waren. Außer vielen
Konvergenzproblemen und weglaufenden Simulationen hin ins Irrelevante
war nicht viel zu erzielen. Es mussten spezielle vereinfachte Modelle
mit jeweils optimierten Parametern erstellt werden, die in pSPICE zu
lokalen Lösungen und akzeptablen Simulationszeiten führten.
http://home.arcor.de/juergen.schuhmacher/japarameters.html
Später habe ich im Rahmen einer anderen Anwendung ein zeitdiskretes
Modell entwickelt, das in einer VHDL-Simulation lief und gute und
realistische Ergebnisse lieferte. War nur eben extrem langsam (Rechnung
auf hohen Vektorbreiten im fs-Mode). Sowas wäre ein schönes Ziel für
eine HIL-Simulation mit compiliertem VHDL gewesen. Damit würde man an
die Zeiten von SPICE schon herangereicht haben, würde ich schätzen.
MATHWORKS ist da ja ziemlich hinterher, alles Erdenkliche an Modellen
durch den HDL-Coder zu jagen und HW-cosimulationsfähig zu machen. -ich
denke, da tut sich was.
Wieviel man da automatisieren kann, bleibt abzuwarten. Wir wissen ja
auch der Praxis, das vielfältige Probleme nur par Hand und mit klugem
Denken effektiv übersetzt werden können.
Jürgen S. schrieb:> Wieviel man da automatisieren kann, bleibt abzuwarten. Wir wissen ja> auch der Praxis, das vielfältige Probleme nur par Hand und mit klugem> Denken effektiv übersetzt werden können.
Ich denke mal, das ist ein ähnlich gordischer Knoten, wie eine C-Routine
automatisch effizient in HDL umzusetzen. LLVM hätte das Framework, und
es gibt einige interessante Experimente, schlussendlich sind die alle
aber auf ein spezifisches Problem zurechtgeschnitten und eher starr als
dynamisch, das hat wohl die Code-Generierung aus compilierten Sprachen
so an sich.
Sicher könnte man für gewisse Modelle einen generischen Solver
einsetzen, der in der HW richtig Performance bringt, aber allein das ist
sicher so ein Aufwand, dass man's in der Zeit auch durch die
Co-Simulation gejagt hat.
Oder eben selbergemacht - wird sich hoffentlich bei Deiner Lösung auch
amortisiert haben, ne?
Grüsse,
- Strubi
