Hallo, vielleicht kennt der ein oder andere schon die VHDPlus IDE die ich mitentwickelt habe. Wir haben viel Feedback und eigene Ideen gesammelt um jetzt eine neue Entwicklungsumgebung ONE WARE Studio zu erstellen, die auf die Anforderungen von professionellen FPGA Entwicklern zugeschnitten ist. Damit wir aber nicht Wünsche überhören habe ich gedacht, vielleicht kann ich hier noch ein offenes Forum starten für Anregungen, was euch noch fehlt bei aktuellen Entwicklungsumgebungen oder besonders wichtig wäre. Vorab ein kurzer Disclaimer: Die neue Version wird kostenpflichtig sein und niemand muss hier seine Ideen uns kostenlos mitteilen, während wir davon profitieren könnten. Aber wer z.B. eh für so eine Software wie HDL Works EASE bezahlt und gerne das ein oder andere Feature mehr hätte, kann gerne seine Ideen uns teilen. Und natürlich verstehe ich es auch wenn man mit der Software vom Hersteller zufrieden ist. Aber das ist auch nicht bei jedem FPGA gleich und an Features um besser und effizienter im Team zu arbeiten gibt es denke ich bei jedem Programm noch etwas potential. Hier auf unserer Website: https://one-ware.com/studio könnt ihr schon einen kleinen Teil der Features angucken, aber die Seite ist noch in ihren Anfängen. Schonmal viele Dank im Vorraus und in der neuen Version geht es natürlich nicht mehr um VHDP wie bei VHDPlus, wir setzen darauf bei der VHDL, Verilog, Firmware, etc. Programmierung zu unterstützen.
:
Bearbeitet durch User
Leon B. schrieb: > Die neue Version wird kostenpflichtig sein womit sie niemand kaufen oder supporten wird. Leon B. schrieb: > n der neuen Version geht es natürlich nicht mehr um VHDP heißt, ihr habt euch von dieser Idee verabschiedet? Wer soll in eure tool investieren, um in 3 Jahren festzustellen, dass ihr Festangestellte werdet, was anders macht und für die Weiterentwicklung keine Lust mehr habt? So einen Spezialfall habe ich gerade zu managen! Ein self-made-Selbständiger hat eine SW im Markt, die meine Firma seit 2 Jahren benutzt. Neue Funktionen können nicht mehr bestellt werden, weil der Herr sich abgeseilt hat. Leon B. schrieb: > wir setzen darauf bei der VHDL, Verilog, Firmware, etc. > Programmierung zu unterstützen. Was möchtet ihr unterstützen? Die Programmierung als Text geht in VHDL. Die in Grafik mit MATLAB. Welche Niesche möchtet ihr besetzen?
Leon B. schrieb: > > Vorab ein kurzer Disclaimer: Die neue Version wird kostenpflichtig sein > und niemand muss hier seine Ideen uns kostenlos mitteilen, während wir > davon profitieren könnten. Aber wer z.B. eh für so eine Software wie HDL > Works EASE bezahlt und gerne das ein oder andere Feature mehr hätte, > kann gerne seine Ideen uns teilen. Und natürlich verstehe ich es auch > wenn man mit der Software vom Hersteller zufrieden ist. Aber das ist > auch nicht bei jedem FPGA gleich und an Features um besser und > effizienter im Team zu arbeiten gibt es denke ich bei jedem Programm > noch etwas potential. Was fehlt am markt ist ein IP-XACT Integrator. Sollte alles machen was Vivado IPI macht, nur mit generischen IP-XACT IP cores. Notürlich sollte das RTL module support auch da sein. Für so etwas würde ich 99EUR bezahlen, und sofort.
🐻 Bernie - Bär schrieb: > Leon B. schrieb: >> n der neuen Version geht es natürlich nicht mehr um VHDP > heißt, ihr habt euch von dieser Idee verabschiedet? Die VHDPlus IDE und VHDP Sprache wird bestehen bleiben und es gibt genug Bastler etc. die weiter beides benutzen. In Zukunft wird die VHDPlus IDE aber durch eine Version von ONE WARE Studio mit gleichem (reduzierten) Funktionsumfang ersetzt. VHDP wird also immernoch unterstützt, aber wird für den professionellen Einsatz nicht der Fokus sein. > Wer soll in eure tool investieren, um in 3 Jahren festzustellen, dass > ihr Festangestellte werdet, was anders macht und für die > Weiterentwicklung keine Lust mehr habt? Wir sind jetzt schon 4 Jahre dabei und haben genug Ideen, Unterstützer und Motivation. Letztendlich können auch große Firmen Software abkündigen > Welche Niesche möchtet ihr besetzen? Einmal setzen wir auf umfangreiche Dokumentations Funktionen, Versionskontrolle und der Erstellung von digitalen Zwillingen der erstellten Elektronik um eine Schnittstelle von bestehender IP und Elektronik zu bilden. Dazu gibt es die Möglichkeit die Entwicklungsumgebung für unterschiedliche Anwendungen anzupassen mit Add-ons und außerdem bieten wir einen KI Generator der bei der effizienten Integration von verschiedenen neuronalen Netzen in FPGAs, Prozessoren oder Mikrocontroller unterstützt.
Moin, Leon B. schrieb: >> Welche Niesche möchtet ihr besetzen? > Einmal setzen wir auf umfangreiche Dokumentations Funktionen, > Versionskontrolle und der Erstellung von digitalen Zwillingen der > erstellten Elektronik um eine Schnittstelle von bestehender IP und > Elektronik zu bilden. Dazu gibt es die Möglichkeit die > Entwicklungsumgebung für unterschiedliche Anwendungen anzupassen mit > Add-ons und außerdem bieten wir einen KI Generator der bei der > effizienten Integration von verschiedenen neuronalen Netzen in FPGAs, > Prozessoren oder Mikrocontroller unterstützt. Na, ohne eine disruptive Blockchaintechnologie wird das aber nix. scnr, WK
Antti L. schrieb: > Was fehlt am markt ist ein IP-XACT Integrator. Sollte alles machen was > Vivado IPI macht, nur mit generischen IP-XACT IP cores. Notürlich sollte > das RTL module support auch da sein. An einem grafischen Editor arbeiten wir sowieso. Aber ich nehme gerne auf, dass hier möglichst viele Standards unterstützt werden. Generell versuchen wir möglichst offen allen Standards gegenüber zu sein und hier über verschiedene Hersteller Brücken zu schlagen
Dazu seid ihr im falschen Land, Deutschland ist fast überall in dem Bereich abgehängt und die Scheisser beim Finanzamt wollen eure Kohle jetzt dringender denn je - was euren Gewinn also die Entlohnung ordentlich schmälern wird. In diversen anderen Ländern würde deutlich mehr übrig bleiben - also man kann von normaler Leistung sogar noch recht gut leben. Glaube nicht dass das was werden wird, so nen Glücksfall wie mit Attolic Truestudio - was von St aufgekauft wurde wird's wohl nicht werden. Soweit bin ich eigentlich auch mit den ganzen anderen Entwicklungssystemen zufrieden.
> Na, ohne eine disruptive Blockchaintechnologie wird das aber nix. Tatsächlich laufen unsere neuronalen Netze zur Bilderkennung auf dem Intel MAX10 mit nur 3000 Logikelementen auch ganz ohne Blockchain
Leon B. schrieb: > Blockchain wird allgemein überschätzt! Leon B. schrieb: > An einem grafischen Editor arbeiten wir sowieso. Von denen gibt es schon welche und keiner war so wirklich zielführend.
Leon B. schrieb: > Einmal setzen wir auf umfangreiche Dokumentations Funktionen, > Versionskontrolle und der Erstellung von digitalen Zwillingen der > erstellten Elektronik um eine Schnittstelle von bestehender IP und > Elektronik zu bilden. Dazu gibt es die Möglichkeit die > Entwicklungsumgebung für unterschiedliche Anwendungen anzupassen mit > Add-ons und außerdem bieten wir einen KI Generator der bei der > effizienten Integration von verschiedenen neuronalen Netzen in FPGAs, > Prozessoren oder Mikrocontroller unterstützt. Klingt wie LabVIEW-Marketing-Sprech. Aber: Was koennt ihr, was Jupyter Notebooks nicht schon lange koennen? Der KI-Hype duerfte auch langsam vorbei sein. Ich bin allerdings auch nicht der Zielkunde fuer yet another IDE, bei meinen usual suspects ist vor allem wichtig, dass das Zeug in 10 Jahren noch wartbar ist und die 'unit tests' in einer CI (Continuous Integration)-Pipeline laufen koennen. Fuer solche Services wuerde ich auch ein Abomodell abschliessen, wenn es nicht schon gitlab gaebe. Ich bin mir auch nicht sicher, ob das Forum hier der richtige Platz fuer Marktforschung ist. Antti L. schrieb: > Was fehlt am markt ist ein IP-XACT Integrator. Sollte alles machen was > Vivado IPI macht, nur mit generischen IP-XACT IP cores. Notürlich sollte > das RTL module support auch da sein. kactus2 kennst du ja vermutlich. Ich fuerchte nur, die Register-Beschreibungssprache (ja, in diesem Fall wirklich) von IP-XACT ist ein echter Augenroller (a.k.a broken by design), und den Aufwand kaum wert. Und einen guten XML-Editor zu stricken ist eine ganz andere Nummer als ein akademisches Experiment (von denen es viele gibt) wie VHDP.
Martin S. schrieb: > Leon B. schrieb: > kactus2 kennst du ja vermutlich. klar kennen ich Kactus2, aber das ding ist (war) kein IP Integrator? Damit kann man was machen, klar, aber irgendwie benutzbar ist Kactus2 ja nicht.
Martin S. schrieb: > Klingt wie LabVIEW-Marketing-Sprech. > Aber: Was koennt ihr, was Jupyter Notebooks nicht schon lange koennen? Also so was ich sehe gibt es entweder tools die unterstützen Netze zusammenzustellen oder fertige Netze für seine Daten zu nutzen. Wir nehmen Wissen zu der Art wie netze aufgebaut sein sollten und erstellen individuell für jede Anwendung ein passendes Netz auf dem aufgebaut werden kann. So ermöglichen wir höhere Effizienz mit weniger KI know how. Und generell was die Entwicklungsumgebung an geht gibt es mit 4 verschiedenen Programmen vielleicht eine ähnliche Funktionalität, aber wenn eine Firma jemanden einstellt muss der auch immer alles neu lernen. Da sind wir ganz gut darin einfache Oberflächen und passende Dokumentation zu erstellen. Also ich verstehe natürlich wenn hier Leute bereits Programme benutzen und dann nicht umsteigen, aber wer eh ein Programm auswählt könnte unsere Software dann ansprechender finden
Leon B. schrieb: > An einem grafischen Editor arbeiten wir sowieso. Aber ich nehme gerne > auf, dass hier möglichst viele Standards unterstützt werden. Der müsste vor allem dynamisch sein. D.h. man muss Teile der Schaltung über Hierarchien hinweg schieben können. Ferner muss man Teile rein- und raus schieben können. Um das zu leisten, braucht es 2 Dinge: 1) Man muss einen Teil einer Schaltung markieren und zu einer Subschaltung zusammenfassen können - ebenso muss man sie wieder auspacken können. Diese Subschaltung 2) Die Schaltung muss virtuell verwaltet werden, d.h. es müssen neue Entity-Namen erzeugt und angeschlossen werden. Als Konsequenz muss man dann sowohl den hierachischen, als auch den flachen Schaltplan in VHDL erzeugen und einlesen können. Um dies zu tun, braucht es wieder 2 Dinge: 1) Es muss sowohl die textuelle, als auch grafische Repräsentation gleichzeitig analog aufrecht erhalten werden. 2) Eine Änderung an dem Text einer Entity, einem Port etc muss sich in der Grafik abbilden und umgekehrt. Wenn ihr DAS habt, dann seid ihr an den Möglichkeiten von der XI IDE und auch an solchen Tools wie Mentor HDL-Designer vorbei. Wenn das steht, dann ließen sich solche geformten Komponenten auch weiter platzieren, d.h. eine als Subkomponente definierte HDL/Grafik-Struktur würde man mehrfach platzieren und anschließen können. Als Erweiterung müsste man das dann virtuell platzieren und dies auch dynamisch, d.h. man schreibt an eine Komponente eine Zahl und bekommt mehrere davon angezeigt, so wie Modelsim das z.B. tut, wenn man ein Array aufzieht. Dafür gibt es momentan keine Lösung. Ich mache das rein grafisch mit Excel, um mir einen Überblick zu verschaffen. Als Beispiel sei das Bild hier erwähnt: Beitrag "Re: Effizienz von MATLAB und HLS bei VHDL" Wenn man das hat, braucht es ein Konzept, wie man das mehrdimensional verdrahten kann, also teilsequenzielle und teilparallele Einheiten quer verknüpfen. Das könnte ich beisteuern.
Danke für die Hinweise zum grafischen Editor. Das sollten wir hinbekommen (mit genug Zeit), auch wenn ich den grafischen Editor ehr für die Top Datei benutzen würden
Ein Kommentar noch: Ich wuerde mir bei einem solchen Vorhaben schon gut ueberlegen, wie ihr das Zielpublikum auch haltet. Denn mit grafischen Erleichterungen zieht man eventuell die Neueinsteiger oder Wohlfuehl-Coder an, schlussendlich migrieren die euch dann als Kunden tendentiell weg und der Aufwand hat sich nicht gelohnt. Und wie schnell vielversprechende Oekosysteme wie Papilio und ZPUino versandet sind, wisst Ihr ja vermutlich auch. Schlussendlich bin ich nach vielen Experimenten mit grafischen Tools wieder auf 'bare metal' gelandet, schlicht deswegen, weil 'make' und 'vim' ueberall verfuegbar sind und man nur eine vernuenftige Beschreibungsform finden muss, die die CI-Pipeline verarbeitet. Das hoechste der grafischen Gefuehle ist nur noch der XML-Editor. Dem entgegen stellt sich die Weigerung vieler Hardware-Coder, ihre Effizienz mit modernen Methoden zu verbessern. Da muesst ihr dann mit neuen Ideen ebenfalls anstinken, denn schlussendlich kommt die Kohle von den Firmen, die konservative Coder im Hause haben. Das einzige, wo ich bisher eine Bereitschaft festgestellt habe, sich auf Neues einzulassen, sind erweiterte Testmethoden wie Co-Simulation und Co-Verifikation der automatisierten Art, wie es mit Python HDLs gut vonstatten geht. Ein weiterer Punkt ist, HDL-Designregeln umzusetzen, dass Neuankoemmlinge per Editor schon gleich angemahnt werden, Codestil XY zu verwenden. Nur macht's absolut keinen Spass, einen VHDL-Parser zu entwickeln, es stecken z.B. viele unbezahlte Mannjahre in der goldenen Referenz GHDL.
Hi, da wir auch viel mit Bildverarbeitung etc. machen, die man sich zusammenklicken kann ist hier auch ein grafischer Editor z.B. hilfreich das zu visualieren. Auch wenn man einfach fertige Bausteine aus seiner oder unserer Bibliothek zusammenstellt hilft so ein grafischer Editor. Wir würden auch zunächst oberflächlicher die Dateien parsen um z.B. die Ein- und Ausgänge zu finden, aber Simulation z.B. würden wir dann mit bestehenden Tools machen. Unsere Software würde dann nur die Bedienung erleichtern. Später könnte man natürlich noch überlegen so ein vollumfäglichen Editor wie von J.S. vorgeschlagen umzusetzen Unser Alleinstellungsmerkal soll einmal die Integration von den wichtigsten Features in einer Software sein mit einfacher Benutzeroberfläche und dann z.B. die Integration von neuronalen Netzen. Dazu muss man aber wissen was die wichtigen Funktionen sind, die gebraucht werden. Wäre es denn z.B. hilfreich es einfacher zu machen make Files oder Simulation-Pipelines zu erstellen? Die Dateien könnte man natürlich dann immernoch auf jedem System ausführen
:
Bearbeitet durch User
Leon B. schrieb: > z.B. die Integration von neuronalen Netzen. Wieviele FGPA-Schaltungen arbeiten mit neuronalen Netzen, dass dies ein Marketingargument sein soll? Wie unterscheidet sich deren Intergration von der einer "normalen" Schaltung? Ein gutes Werkzeug zum Erzeugen umständliche state machines wäre nützlich
Mir ist nicht ganz klar, welches Problem gelöst werden soll. Ich beschäftige mich nun seit 25 Jahren mit FPGAs und habe schon Vieles gesehen. Was ich sehr oft erlebt habe ist, dass immer wieder nach neuen Tools (Compilern, IDEs, Frameworks, ...) gefordert wurde, weil man angeblich sonst nicht weiter kommt. (Fast) Jedes Mal jedoch, saß das Problem vor dem Bildschirm. Bei GUIs und graphischen Editoren ist es besonders deutlich gewesen: von z.B. 3 Mann-Monaten, die veranschlagt wurden, wurde nach 2 Monaten festgestellt, dass es schön wäre, die VHDL-Entitys graphisch in einer GUI darstellen zu lassen und dann auch noch Umbenennung der Signale (Refaktoring) schneller durchführen zu lassen. Dazu soll dann die 5000$ Software beschafft werden. Gesagt - getan. Die Demo ist beeindruckend -- "du ziehst einfach die Entity in das toplevel, die Verdrahtung passiert automatisch, du musst nichts mehr machen, alle Signale werden umbenannt". Klasse, hat nur 5 Minuten gedauert! Rest der veranschlagten Zeit wird damit verbracht die Entyties hin und her zu schieben und umzubenennen, in der Hoffnung, dass das Design funktioniert. Ende vom Lied: für 5 Minuten Einsatz - wurde viel Geld ausgegeben. Das Ganze hat dann 6 Monate gedauert, statt veranschlagten 3 Mann-Monaten. Die Änderung mit Umbenennung hätte ich aber in 30 Minuten mit Emacs erledigt. Ich gebe aber offen zu, dass Tooling (Entwickeln solcher Tools) sehr viel Spaß macht :-) Ist auch nicht so, dass ich mich daran nicht selber probiert habe ;-) just my 2 ct Kest
Berni-Bär 🐼 schrieb: > Wieviele FGPA-Schaltungen arbeiten mit neuronalen Netzen, dass dies ein > Marketingargument sein soll? Also wir unterstützen generell Edge AI entweder mit Linux und TPU auf einem SoC, mit Mikrocontroller oder auf dem FPGA. Da sind wir schon mit vielen Firmen in Kontakt die das für die Echtzeit Qualitätskontrolle, Ausfallvorhersage oder Roboter/Drohnen Steuerung einsetzen wollen Wenn man dann das erstellt hat kann man in unserer IDE die FPGAs oder Mikrocontroller programmieren. Weil es für Mikrocontroller mit TF Lite schon genug gibt aber bei FPGAs das Hersteller abhängig nicht ganz so gut geht haben wir für FPGAs dann unsere eigenen IPs.
:
Bearbeitet durch User
Leon B. schrieb: > Also wir unterstützen generell Edge AI Edge AI, ja klar. Na DANN ist ja alles in Butter. (Was soll das nun heißen und inwiefern ist das eine Antwort auf meinen Vorschlag?)
Meine Antwort zielte mehr darauf ab, dass wir neuronale Netze nicht nur für FPGAs erstellen und, dass es schon Nachfrage nach neuronalen Netzen in FPGAs gibt. Z.B. für die Bilderkennung. Mit der Entwicklungsumgebung bieten wir dann die Möglichkeit gleich diese netze in FPGAs (oder in Zukunft vielleicht auch Mikrocontroller) zu implementieren, alles drum herum im Team zu entwickeln und hier immer nur eine Software für egal welche Hardware nutzen zu müssen. Zu dem State Machine Tool: Es gibt ja bereits grafische Editoren wo man State machines in HDL wandeln kann. Ich bin aber generell nicht der Typ der Blockdiagram oder State Machine Editoren benutzt. Gibt es da Punkte die bei bisherigen Tools fehlen?
Leon B. schrieb: > Ich bin aber generell nicht der Typ > der Blockdiagram oder State Machine Editoren benutzt. Ich auch nicht. Ich bin aber Fan von parametrierbaren Codegeneratoren, die sich gut verskripten lassen. Das kann man gut revisionieren, jeder im Team hat einen definierten Stand und die CI-Pipeline ist auch glücklich...
Leon B. schrieb: > uch wenn ich den grafischen Editor ehr > für die Top Datei benutzen würden Nein, der soll schon das gesamte Design strukturieren helfen. Er soll ja dabei helfen, aus den jeweiligen Teilen neue unter- und übergeordnete Teile zu entwerfen, z.B. das Platzieren von 2 vormaligen FPGA-Top Designs in einen einzigen und umgekehrt. Das muss über alle Hierarchienn in beide Richtungen erfolgen, da es beim Planen TOP-DOWN und dem Desigen oft auch BOTTOM-UP läuft.
Moin, mir ist bei einer Diskussion um den generellen Sinn grafischer Tools noch ein Argument eingefallen, moeglicherweise schon mal erwaehnt. Eine nicht naeher zu bezeichnende Entwicklergruppe verbraet relativ viel Zeit, ihre HDL auf gewisse Konstrukte zu durchforsten und anzupassen. Das kann teils automatisiert geschehen, aber teils gibt es Spezialfaelle, die in der Verifikation durchfallen. Beispielszenario: Neu entwickelter RISC-V-Core soll zum alten zyklusgenau kompatibel sein. Die alten Regressionstests will man weiterverwenden. Alter und neuer Kern werden im 'Lock step' Modus in die Simulation gesteckt, und per Debug-Backtrace-Kanal (im Simulator) das neue Verhalten mit dem alten abgeglichen, bei Diskrepanzen wird die Simulation abgebrochen. Was dabei massiv Zeit verbraet, ist das Zurueckverfolgen der Ursachenkette in der Signal-Hierarchie. Es gibt zwar ein Multi-Dollar-Tool von Cadence, was das fuer SystemVerilog et al kann, aber zwischen den Selbermachloesungen und Dollar gibt es lange nichts, koennte allenfalls sein, dass Sigasi sowas inzwischen kann. Der Wunsch waere folgender: Simulation schlaegt fehl, Tool untersucht Backtrace fuer beide UUT (units under test), filtert die generierte Backtrace und springt im Source an die Stelle, an der es mutmasslich geschieht, plus zeigt die Wellenformen in einer Ereignisdarstellung fuer die beteiligten Signale an. Das geht natuerlich nur fuer gewisse Simulatoren-Backends, die von einer angepassten Master-Testbench getrieben werden werden, ergo Co-Simulation koennen. Bei compilierten Binaries muss man die interne debug-Trace bei einer Exception auswerten. Da eine permanent aktive Backtrace fuer jede Signalaenderung zu aufwendig ist, wuerden schon klassische Debugger-Funktionen helfen: Im ersten Anlauf sieht man, wann die Simulation in der Top-TB abbricht, im zweiten setzt man den Backtrace-Watchpoint, der, wenn getriggert, die Signalkette aufdroeselt. Mit CXXRTL ist das z.B. bis zu einem gewissen Punkt machbar. Was fehlt, ist direkt von einer beliebigen Ursprungssprache (nicht nur VHDL und Verilog, auch Scala und Pyhon-HDL) eine Zuordnung von Zeile zu DWARF-Debug-Info im Simulator-Binary herzustellen. Ich loese momentan das Problem auf haessliche Weise, indem der Ursprung in die Namen der synthetisierten Entities codiert werden. Das ist leider nur uebel redundant und blaest die Binaries ueber Gebuehr auf. Sinnvoller waere vermutlich, eine Datenbank anzulegen. Sonstige Ideen?
Das (lock step, datenbank) ist ein Ansatz, der bei mir eine Assoziation weckt: Um Regressionstest zu machen, war ein Vorschlag von mir, die Simulation und auch den Code per Script mit Zusatzinfos zu versehen, die den Simulationslauf mitprotokollieren. Angedacht war ein Python-Script, dass alle Codes einer Simulation kopiert und dabei hinter die einschlägigen Codezeilen Asserts und Schreibaufrufe durchführt welche in einer von ModelSim geöffneten Datei auf der Platte laufen. So muss der Entwickler das nicht einbauen, sondern es wird für ihn eingebaut. In der Datei finden sich dann Zeilennummern, der Wert der zuletzt geänderten Signale und Variablen, sowie die Zeilennummer und der Code, was dafür ursächlich war. Damit kann man in einen beliebigen Punkt der Datei einspringen und von dort aus rückwärts einen Baum aufbauen, wodurch ein Signal zuletzt beeinfluss wurde. Bei einer Rechnung C = A * k ( B + C ) werden dann die 4 Werte rechts des Gleichheitszeichens zurückverfolgt und deren Entstehung dokumentiert. Das Entscheidende ist, dass zu jedem Knotenpunkt auch der Simulationszeitpunkt bekannt ist und man damit erkennt, wenn das timing in einer 2D-pipeline nicht stimmt, wo es Iterationen gibt und werte falsch verrechnet werden, was in der Zeilenansicht von ModelSim nicht zu sehen ist ohne querzulesen. In ModelSim sieht man z.B. immer nur die Kette an sich, kann aber nicht beliebig in die zeitliches Historie zurück und andere Quellen sehen. Das würde jetzt über eine IDE-Entwicklung weit hinausgehen, ergäbe aber ein sehr interessantes und nützliches tool! Das wäre auch sehr einfach mit der Lockstep-Anforderung zu verheiraten, wenn man sich das nebeneinander darstellen ließe. So könnte man auch Regressionstests durchführen und die Abweichungen von der vorherigen VHDL-Version gegeneinander vergleichen. Das braucht man ja relativ oft, auch wenn man kein CPU-Verhalten checken möchte. Die Firma hat das leider nicht weiterverfolgt, weil keine Resourcen für die Pythonentwicklung freigeräumt werden konnten.
Wenn du bestehende HDL so annotieren willst, gibt's aber gehoerig was zu tun, und ich hoere schon den Einwand: Damit wird ja der Code modifiziert und man muss den Annotator mittesten. Wrapper fuer HDL-Module erzeugen, die in eine separate Trace in eine Datenbank schreiben, fuehrt per GHDL zumindest zum Erfolg. Aufwendig, nur fuer VHDL, aber non-intrusiv. Statische Testbenches ausrollen, so dass sie sich selber verifizieren, ist zumindest hier per Python-HDL/HLS kein Problem, so mache ich die Unit-Tests von Rechenpipelines. Was eben fehlt ist die dynamische Seite. GHDL kann zwar so einiges, nur kein Verilog... CXXRTL kann es grundsaetzlich fuer alle HDL-Sourcen, solang sie per yosys synthetisieren. Momentaner Stand der hiesigen 'dynamischen' Cosimulationstechnik ist, dass die Berechnung in Python parallel gegen das Resultat der Hardwaresimulation (bis Gatelevel) automatisch evaluiert wird. Da aber auch noch eine Menge Hinterlassenschaft in Form von V*HDL vorliegt, waere es wuenschenswert, die gesamte Fehlerfortpflanzung auf Simulator-Ebene zu tracken und die Verbindung zur Source herzustellen. Ich fuerchte das loest man nicht mit einem einfachen Script. Besser, man loest es aus der ausgegebenen 'trace' auf. Ein gutes Waveform-Display mit automatischer Annotation waere auch schon was. Was ich mir noch nicht angesehen habe, sind die relativ neuen Entwicklungsn vom CIRCT-Team, also insbesondere Arcilator. Wie gut das moore-frontend gegenueber GHDL oder icarus allerdings ist, ist noch fragezeichenbehaftet, genauso wie die lizenzrechtliche Thematik mit dem Einbau von OpenSource-Tools in eine IDE (siehe auch Eclipse).
Martin S. schrieb: > Damit wird ja der Code modifiziert > und man muss den Annotator mittesten. Nein, das wird nur zur Analyse und Simulation gemacht. Der Code ist nicht synthetisierbar. Auch der zuvor synthetisierbare Code ist es dann ja nicht mehr. Es wird jeweils ein neuer Code im Zuge der Analyse übersetzt und das dynamisch anhand aktueller Einstellungen, was man sehen möchte.Für den Entwickler ist das nur ein Mausklick. Der Simulator hat natürlich ungleich mehr zu tun. In einem anderen Zusammenhang für einen anderen Zweck hat ein Kunde von mir so ein System am Laufen. Es wurde von mir mitentwickelt und verfeinert, ich darf aber die Methode und das Ziel dahinter hier nicht beschreiben. Um den Gedanken außerhalb dieses Zusammenhangs darzustellen, skiziere mal folgendes Beispiel, das damit direkt nichts zu tun hat, das wir aber im Bereich TMR und Asymmetrie brauchen und bislang vielfach händisch implementieren müssen: Ich möchte einen FPGA Code haben, der alle statemachines überwacht und absichert. Um den nicht selber schreiben zu müssen, läuft ein Script über das VHDL, schnappt sich die FSM (man kennzeichnet sie z.B. mit einem -- CODE : FSM - Beginn --) und dupliziert jede Anweisung darin in neue Signalnamen mit einem "_TWIN" dahinter. Damit existiert die FSM zweimal. Die TWIN-Signale werden werden per "keep" erhalten und die FSM durch geeignete Clock-Contrukte zeitlich um 3 Takte versetzt. Damit macht die TWIN FSM mit allen ihren Variablen und Signalen genau das gleiche, wie das Original. Dann werden deren Ausgangsignale ebenfalls um 3 Takte verzögert und mit denen des TWIns verglichen. Die Vergleiche werden überwacht. Kommt es zu einer Fehlfunktion des FPGAs durch z.B. Strahlung, wird das sichtbar werden. Der Knackpunkt ist jetzt, dass man diese so erzeugten Signale auch "modifizieren" kann, um sicherzustellen, dass ein Kippeinfluss jeweils komlementär wirkt. Ferner kann man sie in verschiedene SLRs und BRAMs verlegen, die weit entfernt sind. Solche Asymmetrien werden an verschiedenen Stellen in der Industrie eingesetzt, wenn designs sicher gemacht werden müssen. Es gibt inzwischen tools, die das teilweise können, aber standardmäßig sind die freien Werkzeuge der einschlägigen Hersteller nicht dazu in der Lage. Man kann nun, als Erweiterung, den Code 2x durchlaufen lassen, das Original mit einem Suffix versehen, die Verzögerung auf 4 und 2 stellen und bekommt so erst 2, dann 4 FSMs mit dnr Verzögerungen: FSM_ORIG = 0, FSM_TWIN = 4 -> FSM_ORIG_ORIG=0, FSM_TWIN_ORIG=4, FSM_ORIG_TWIN=2, FSM_TWIN_TWIN=6 Ich habe die zuletzt genannte Idee Mitte der 2000er in ein strahlungsgefährdetes Design eingebracht, damals allerdings mit meinem Excel, das state machines und calc pipelines erzeugen kann und es händisch dupliziert. Das 2x zu verdoppel, war ein Akt! Mit einer SW, die das automatisch macht, wäre das ein Klacks!
J. S. schrieb: > Nein, das wird nur zur Analyse und Simulation gemacht. Der Code ist > nicht synthetisierbar Das spielt ja keine Rolle. Du musst dennoch garantieren koennen, dass das Script nicht ein Konstrukt falsch uebersetzt/parst. Wenn neuer Code erzeugt wird, artet das spaetestens bei prozeduralen Sachen in einen Wust gordischer Knoten aus, die alle verifiziert werden wollen. Generierung von redundanten Strukturen ist ein komplett anderes Thema, das laesst sich deutlich eleganter und selbst-verifizierbarer loesen, aber nunmehr nicht auf V*-Ebene. Aber dann ist es in der Tat ein Klacks in Form eines Python-Dekorators :-) Mir geht es darum, dass die meisten Simulatoren ja die noetige Information und Struktur fuer Propagations-Tracking bereits vorliegen haben und man sie nur noch auswertet. Also Credo Nr. 1: NICHTS am bestehenden Source aendern, annotieren, oder ohne direkte granulare Verifikation uebersetzen muessen. In die Luecke koennte man mit 1 Mannjahr vermutlich vorstossen, und mit etwas Foerdermitteln fuer Innovationen dann auch noch mit einem Preis deutlich unter dem $$$-Tool wirtschaften. Aber: ich stecke im IDE-Geschaeft nicht drin.
Martin S. schrieb: > Du musst dennoch garantieren koennen, dass > das Script nicht ein Konstrukt falsch uebersetzt/parst. Das muss natürlich verifiziert werden und das tool als solches muss validiert werden, absolut richtig. Das ist aber ein einmaliger Vorgang für jede Form des Konstruktes. Wenn das tool das einmal kann, wird es dass immer wieder tun. Wenn ich FSMs oder andere Komponenten, die ich als TMR haben will, oder in anderer Weise duplizieren möchte, weil ich das brauche, immer per Hand vervielfachen muss, dann unterlaufen mir schon in dieser Phase u.U. Fehler, die per Simulation in der Entwicklung rausgeworfen müssten - BEVOR ich überhaupt dazu komme, die dann technisch stimmige Simulation auf eventuelle funktionelle Diskrepanzen untersuchen zu können. Grundsätlzlich muss dieser Parsar auf dem gleichen Güteniveau sein, wie der Parser im Vivado, der das VDHL in eine Netzliste übersetzt, bzw alle anderen Teile der tool chain. Die finale Simulation und der finale Exemplar-Test bleiben einem sowieo immer. Mir geht es um die Beseitigung des Arbeitsaufwandes, um überhaupt erst dahin zu kommen, eine Simulation zu haben, die zwei gleiche Ergebnisse zeigt.
Leon B. schrieb: > it der Entwicklungsumgebung bieten wir dann die Möglichkeit gleich > diese netze in FPGAs (oder in Zukunft vielleicht auch Mikrocontroller) > zu implementieren, Ist das irgendwo schon skizziert? Ich lese hier viel von Absichten, doch habt ihr euch schon durchgerechnet, wie lange solche Implementierungen brauchen, was es an Personal für Entwicklung, Vortrieb und Erhalt sowie Pflege der Software braucht? Das geht nicht nur um Investitionen, sondern muss langfristig Gewinn abwerfen. SW-Entwickler müssen bezahlt werden. Die zu optimistische Projektplanung und weglaufende SW-Entwickler mit verhackstücktem Wissen und Code sind oft schon der Tod solcher Firmen und Projekte gewesen. Die hier geäußerten Ideen und Hoffnungen sind ganz nett, doch haben das sicher viele Firmen schon probiert und wieder verworfen und fallen gelassen.
J. S. schrieb: > Grundsätlzlich muss dieser Parsar auf dem gleichen Güteniveau sein, wie > der Parser im Vivado, der das VDHL in eine Netzliste übersetzt, bzw alle > anderen Teile der tool chain. Oergs, nein, bitte nicht. Xilinx haelt sich nicht 100% an den VHDL-Standard und es gibt immer noch Diskrepanzen zwischen Simulation und Synthese. Abgesehen davon, dass das Rad nicht neu erfunden werden sollte, da GHDL die AST-Analyse schon '1993 bis '2008 standardkonform abdeckt, sollte man sowas nur in Spezialfaellen der Sourcecode-Analyse anfassen muessen, aber nicht um Code zu generieren.
Martin S. schrieb: > nein, bitte nicht. Sooo meinte ich das nicht :-) Ich wollte ausdrücken, dass ein solcher Parser grundsätzlich einfach genau so gut validiert werden muss und man ihm dann auch so vertrauen kann, wie man der Synthese und all den Schritten vertrauen muss und kann. Nicht mehr nicht weniger. > Xilinx haelt sich nicht 100% an den VHDL-Standard Das ist nochmal ein anderer Punkt. Bezüglich dieses Sachverhaltes sollte man in der Tat nicht XI als Vorbild nehmen. Wäre ein weiteres Plus für eine gute IDE.
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.