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
:
Bearbeitet durch User
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
Ich hatte mir schon mal XSLT angeschaut. Wenn es läuft sicher eine hifreiceh Variante. Das wäre eine neue Baustelle für mich.
Ich habe vor einiger Zeit mal damit experimentiert, C++ Code aus XML Beschreibungen zu generieren. Verwendet habe ich dafür Python und Mako.
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.