Forum: FPGA, VHDL & Co. Anregungen für eine FPGA Entwicklungsumgebung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Leon B. (Firma: ONE WARE) (leon_one_ware)


Lesenswert?

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
von Bernd G. (Gast)


Lesenswert?

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?

von Antti L. (trioflex)


Lesenswert?

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.

von Flo H. (hintiflo)


Lesenswert?

Unterstützt die VHDPlus IDE auf Artix-7 ?

von Leon B. (Firma: ONE WARE) (leon_one_ware)


Lesenswert?

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

von Dergute W. (derguteweka)


Lesenswert?

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

von Leon B. (Firma: ONE WARE) (leon_one_ware)


Lesenswert?

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

von Thomas H. (thomash2)


Lesenswert?

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.

von Leon B. (Firma: ONE WARE) (leon_one_ware)


Lesenswert?

> 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

von Bernd G. (Gast)


Lesenswert?

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.

von Martin S. (strubi)


Lesenswert?

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.

von Antti L. (trioflex)


Lesenswert?

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.

von Leon B. (Firma: ONE WARE) (leon_one_ware)


Lesenswert?

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

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Leon B. (Firma: ONE WARE) (leon_one_ware)


Lesenswert?

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

von Martin S. (strubi)


Lesenswert?

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.

von Leon B. (Firma: ONE WARE) (leon_one_ware)


Lesenswert?

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
von Bernd G. (Gast)


Lesenswert?

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

von Kest S. (kest)


Lesenswert?

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

von Leon B. (Firma: ONE WARE) (leon_one_ware)


Lesenswert?

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
von Bernd G. (Gast)


Lesenswert?

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?)

von Leon B. (Firma: ONE WARE) (leon_one_ware)


Lesenswert?

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?

von Rick D. (rickdangerus)


Lesenswert?

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

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Martin S. (strubi)


Lesenswert?

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?

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Martin S. (strubi)


Lesenswert?

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

von J. S. (engineer) Benutzerseite


Lesenswert?

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!

von Martin S. (strubi)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von A. F. (chefdesigner)


Lesenswert?

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.

von Martin S. (strubi)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.