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
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.