Ich bastle gerade im Rahmen eines größeren Projekts an einer Art
Präprozessor für VHDL auf Basis von Lua, Bison und Flex.
Die Problemstellung war es, stark konfigurierbare VHDL Modelle schreiben
zu können. Dazu müssen Konfigurationseinstellungen auf einer recht hohen
Ebene getroffen werden und diese dann irgendwie in das VHDL File
einfliessen. Dazu sind manchmal relativ aufwändige Rechnungen nötig, die
in VHDL selbst nicht (einfach) durchzuführen sind.
Die hier vorgeschlagene Lösung ist es, die Berechnungen in einem Lua
Skript durchzuführen. Die Konfigurationsdaten dazu werden dann aus einem
weiteren File, evtl. XML gezogen. Das Lua Skript berechnet alles was zu
berechnen ist und baut mit den Ergebnissen eine Lookup Tabelle für den
eigentlichen Parser auf. Der Parser geht dann das annotierte VHDL File
durch und benutzt seine Tabelle für entsprechende Ersetzungen. Es sollen
aber auch einfache Rechnungen möglich sein, sowie for loops und if-else
Statements.
Da das ganze so nebenbei entsteht bin ich noch nicht sonderlich weit
gekommen, ich kann mit einem Lua Skript bereits die Tabelle füttern und
damit den Parser benutzen, letzterer dürfte aber noch ein paar Probleme
haben, besonders if-else ist noch nicht drinn. XML o.Ä. habe ich noch
nicht angefangen. Ich bin Etechniker und kein Informatiker, deswegen tue
ich mich schwer, auch C++ ist nicht so wirklich meine Stärke, VHDL sagt
mir eigentlich mehr zu.
Obwohl das ganze Lizenztechnisch eigentlich unkritisch ist (Lua ist MIT,
Bison und Flex erzeugen Code der frei benutzt werden darf, ohne GPL) bin
ich am Überlegen ob ich das ganze als Open Source Projekt weiterführen
soll. Daher ist meine Frage an euch: Hat jemand Interesse an einer
solchen Software? Würde jemand evtl. mitprogrammieren?
Hallo,
interessante Aufgabenstellung - kannst du evtl. ein paar mehr Details zu
den konkreten Problemen verraten, die du lösen möchtest?
Wir haben uns vor einiger Zeit Gedanken zur Konfigurierbarkeit von
VHDL-Code gemacht, es fehlte aber immer etwas an ausreichend komplexen
Problemstellungen, um den Aufwand zu rechtfertigen. Dabei haben wir
versucht, Techniken aus dem Bereich der Softwaretechnik (konkret
Aspektorientierung) auf Hardwarebeschreibungssprachen anzuwenden.
Ein paar Links dazu:
Ein frühes Konzeptpaper:
http://www.aosd.net/workshops/acp4is/2008/papers/Engel.pdf
und eine spätere Abschlußarbeit:
http://ess.cs.uni-dortmund.de/Teaching/Theses/2013/BA_Stelzner_2013.pdf
Auf sourceforge gibt es ein VHDL preprocessor-Projekt (vpp), evtl. kann
dir das einiges an Arbeit ersparen?
http://sourceforge.net/projects/vhdlpp/
-- Michael
Michael Engel schrieb:> Dabei haben wir> versucht, Techniken aus dem Bereich der Softwaretechnik (konkret> Aspektorientierung) auf Hardwarebeschreibungssprachen anzuwenden.
e ist ine in der Schaltkreisentwicklung eingesetzte Sprache, die
aspektorientiert ist. Somit als Vorbild geeignet?
http://en.wikipedia.org/wiki/E_%28verification_language%29
MfG,
Fpga Kuechle schrieb:> Michael Engel schrieb:>>> Dabei haben wir>> versucht, Techniken aus dem Bereich der Softwaretechnik (konkret>> Aspektorientierung) auf Hardwarebeschreibungssprachen anzuwenden.>> e ist ine in der Schaltkreisentwicklung eingesetzte Sprache, die> aspektorientiert ist. Somit als Vorbild geeignet?> http://en.wikipedia.org/wiki/E_%28verification_language%29
Ja, e hatten wir uns damals auch angeschaut, da waren ein paar
interessante Details bei - danke für den Tip, das hatte ich nach einigen
Jahren ausgeblendet... werde mal nachlesen, was sich in dem Bereich in
den letzten Jahren so getan hat.
Michael Engel schrieb:> interessante Aufgabenstellung - kannst du evtl. ein paar mehr Details zu> den konkreten Problemen verraten, die du lösen möchtest?
Es geht darum eine Sammlung von IP Cores zu einem ganzen Themengebiet zu
erstellen, eine Art Rapid Prototyping Lösung. Allerdings soll der Output
dann trotzdem verwendbar sein, also natürlich synthetisierbar und auch
soweit es geht einigermaßen optimiert. Das ist im Grunde eigentlich kein
Problem, erfordert aber, wie gesagt, einige Vorberechnungen.
Der Nutzer soll also seine Designvorgaben eintippen und dann fällt das
entsprechende VHDL hinten raus.
Michael Engel schrieb:> Auf sourceforge gibt es ein VHDL preprocessor-Projekt (vpp), evtl. kann> dir das einiges an Arbeit ersparen?> http://sourceforge.net/projects/vhdlpp/
Den habe ich schon gesehen, der Implementiert aber wohl seinen eigenen
Parser, so dass es Erweiterungen eher schwer macht. Mit Bison wird das
wohl besser.
Moin,
schau dir doch mal MyHDL an. Das macht eigentlich alles, was Du oben auf
der Wunschliste hast, ausser, ich habe was übersehen.
Von VHDL als Quellformat würde ich wegen des überaus mühsamen Parsens
(ja, hab's mir auch schon angetan) absehen.
Momentan lasse ich mir für die komplexeren SoCs mit konfigurierbarer
Peripherie einfach die VHDL-Files aus MyHDL bzw.
XML-Gerätebeschreibungen ausspucken, die generieren gleichzeitig auch
die Header-Files. Im Prinzip derselbe Arbeitsfluss wie bei Qsys und wie
die SoC-Builder alle heissen, nur ohne lästige GUI-Klicks :-) (einmal
"make" tippen...)
Ansonsten ist dein Ansatz nichtsdestotrotz interessant, das Problem nur
recht alt, und insgesamt eine rechte Knacknuss :-)
Ich mache das für (m)eine Forschungsplattform händisch:
Basierend auf einer Plattformkonfiguration aus XML wird mit einem C++
Tool von mir dann VHDL/Verilog/SystemC teilweise erzeugt und auch
teilweise nur instanziiert.
Das erzeugt mir dann für eine recht komplizierte Architektur sowohl
Simulation in SystemC als auch synthesefähigen Code....
Bestimmt nicht der Weisheit letzter Schluss, tut aber soweit und ist
Makefile gesteuert ;)
Das Thema ist interessant.
Ich habe ähnliche Probleme ein SOC zusammenzustellen.
Alle IP-Cores haben einen standardisierten Bus zur Kommunikation mit
einer CPU. So bekomme ich die Peripherie einfach zusammen.
Jetzt bringt jede Peripherie aufgrund ihrer Funktion eigene
Signalleitungen neu ins Spiel, die bis zum Top Entry durchgeroutet
werden müssen. Das einfachste Beispiel ist die UART mit den Signalen RX
und TX.
Für machen habe ich zum Setzen Generic benutzt wie z.B. die I2C
Taktgeschwindigkeit. Die Generic ziehe ich nicht bis zu Top hoch.
Somit sind wichtige Einstellungen in Unterdateien.
Damit ist die Übersichtlichkeit wieder hin.
Wenn da ein einfachen handhabaren Workflow gäbe, wäre es toll.
Hi Rene,
ev. könnte dir IP-XACT was bringen. Siehe auch
http://www.edautils.com/ip-xact.html. Allerdings widerspricht IP-XACT
etwas dem KISS (keep it simple and stupid)-Prinzip, die Sache
amortisiert sich für den Einzelkämpfer kaum. Im Rahmen grösserer
Projekte und voller SoC-Flexibilität a la Xtensa schon eher. Aber du
musst typischerweise in die XSLT-Methodik einsteigen, um eine
vollautomatische Soc-'make menuconfig' mit XACT-Quellen abzudecken. Die
Sache ist leider bei den Stylesheets noch nicht so recht zu ende
gedacht, aber es gibt immerhin ein paar nette *Autorentools".
Ansonsten sind in ghdlex 0.051 ein paar Beispiele (netpp/devdesc)
versteckt.
Gruss,
- Strubi
