Moin, ich wollte mal ein bisschen rumhören, womit sich die Fachwelt im Bezug auf Generieren von VHDL beschäftigt. Vorerst zur Motivation: Für komplexe Geräte braucht's ja meist: a) VHDL-Registertabellen b) Zugehörige C-Header und Treiber c) Dokumentation Dass sich das alles aus einer einzigen Beschreibungsdatei relativ wenig aufwendig generieren lässt, ist ja nicht mehr so neu, einige Hersteller beschreiben ihre Chips bzw. Geräte komplett in XML. In den letzten Jahren habe ich damit auch auf diversen Baustellen herumexperimentiert und bin nun an dem Punkt, wo es sich langsam lohnt, die Peripherie-Konfiguration zu einem SoC (Soft-CPU und div. Peripherie) nur noch in einer einzigen XML-Datei zu beschreiben. Daraus generiert ein XSLT stylesheet die ganzen Register-Definitionen als VHDL package, die C-Header, und den Adress-Decoder in VHDL. Heisst: Brauche ich z.B. ein neues Konfigurations-Bit, fasse ich nur noch die XML-Beschreibung und die VHDL-Datei mit der Implementation an. Spart Zeit, und vermeidet v.a. Fehler-Einschleppen bei Änderungen, "make" hält alles 'in sync'. Mal den div. Tool-Herstellern über die Schulter geguckt: - Lattice MicoSystemBuilder: Erlaubt Peripherie-Anbindung per Mausklick, generiert ebenfalls Base-Adressen - HPE-Desk: ähnlich, habe ich aber nicht ausprobiert Mit grafischen Tools stehe ich ziemlich auf Kriegsfuss, die Diskussion dazu ist immer kontrovers, drum will ich sie gar nicht anreissen (bitte auch nicht dazu herumtrollen/flamen). Für mich persönlich hat es sich einfach als effizienter (und in punkto Wiederverwertbarkeit als besser) herausgestellt, mit Source-Files im Textformat und Gnu Make zu arbeiten. Nichtsdestotrotz liesse sich das alles auch für Einsteiger in eine IDE packen. Da gibt's garantiert auch ne Menge, nur ist mein Blick über den Tellerrand (da eher an Projekten als an Tools orientiert) recht beschränkt. Was nutzt Ihr so an Werkzeugen/Hilfsmitteln, und wieviel kann/muss man dabei selbermachen? Ein Aspekt auch istdie Portabilität: - Betriebssysteme (Windows, Linux, ..?) - Unabhängig vom FPGA-Hersteller Grüsse, - Strubi
Schau dir mal den LEON3 an http://gaisler.com/index.php/products/processors/leon3 da wird das über vhdl dateien gemacht
Ist ja witzig. Ich mach mir seit geraumer Zeit Gedanken über das gleiche Thema und habe kürzlich überlegt hier mal rumzufragen, ob sich jemand für das Thema interessiert. Meine Überlegungen gingen in die gleiche Richtung: Ein zenrtales XML (Wobei ich bisher nur an Adressräume gedacht habe) für die Definition eines Systems und Tools, die daraus: - Doku - VHDL-Deklarationen - VHDL-Adressdecoder (Insbesondere Wishbone-Arbiter) - C/C++ Header - Doku (Register-Tabellen etc.) - ... erstellen. Grundlage wäre zunächst ein offener Standard für die XML-files und ein (GUI-) Tool um diese zu generieren. Martin S. schrieb: > Mit grafischen Tools stehe ich ziemlich auf Kriegsfuss Ich nicht:-) Aber ich finde die beste Variante ist immer ein Satz von Commandline-Tools, die man wenn man möchte mit einem GUI-Frontend versehen kann. Ich finde jedenfalls, das ganze wäre ein schönes Open-Source Projekt. Es braucht nur jemanden, der es ins Leben ruft :-)
Zu "user": Den Leon kenne ich aus der Ferne, ist aber für meine Anwendung zu 'overdosed'. Das tk-config-Scripting a la Linux ist nett, aber löst soweit ich sehen kann noch nicht das Problem der Synchronisation mit Headern und Dokumentation und erschlägt auch nicht den Aufwand der Implementierung. An pks: XML-Beschreibungen gibt es schon einige, aber jeder kocht bisschen seine eigene Suppe. Ich habe mal meinen internen Standard (DClib/netpp) als OpenSource rausgehauen (http://www.section5.ch/netpp), rücke aber momentan eher von der kompletten Offenlegung des Gesamtprojekts ab, da sich einige grosse Player im Geschäft fröhlich und lizenzfrei bedienen und auch unbezahlten Support kosten, aber nichts zurückgeben. Ansonsten ist das "Produkt" sehr gut gereift und hat sich in der Grundstruktur seit 2006 kaum noch verändert. Es geht soweit schon alles, was Du auf deiner Wunschliste stehen hast. Die DClib automatisiert momentan halt vor allem die Software-Entwicklung und bisher hatte ich v.a. VHDL-Registertabellen analog zum Leon3 daraus generiert. Der momentane nächste Schritt einer "Standardisierung" wäre, wie Du es schon genannt hast, das komplette Adress-Decoding vernünftig zu erschlagen. Hänge mal ein Beispiel an. - iomap.xml: Die Beschreibung der einzelnen Geräte - i2cmap.vhdl: Generierte Source zur i2c registermap Was noch fehlt, ist das XSL-Sheet, dafür schäme ich mich noch etwas, da es ein rechter Hack ist :-) Wenn ich jetzt aber mehrere Controller instanzieren möchte, müsste ich ein weiteres XML schreiben, in das ich die <registermap>-Knoten mehrmals include. Das ist unschön, also bietet sich eine weitere Semantik für die Instanzierung definierter Registermaps an (experimentell ganz unten im iomap.xml). Der Punkt ist bei dieser Entwicklung, dass ich mich a priori nicht auf einen Bus festlegen will, sondern für relativ rohe IP-Cores (ohne Bus-Decoder-Logik) ohne grossen Aufwand und Fehlereinschleppen Bus-Wrapper (wie das obige VHDL-File) generieren möchte. Pro Controller gibt es also eine rohe Implementation mit primitiven Config, Status, und Data I/O-Pins und einen zugehörigen Decoder. Nichtsdestotrotz sollten mit demselben Dialekt auch bestehende Busse (und bereits entsprechende Controller-Wrapper) erschlagen werden können. Dementsprechend würde man XSL-Dateien für wishbone, AHB, usw. schreiben und über dasselbe XML-File rödeln lassen. Das alles zu implementieren und standardisieren ist ein rechter Wahnsinn. Mit diversen Standardisierungsprozessen in der Industrie habe ich schon so meine schlechten (politischen) Erfahrungen gemacht, aber es geht ja auch anders, wenn auch bisschen von hinten durch die Brust. Würde mich freuen, wenn vom einen oder andern Hacker ein paar gute Ideen oder sogar XSLs reinschneien.. Grüsse, - Strubi
Solche Themen haben wir ja bereits des Öfteren in der einen oder anderen Weise diskutiert. Ich bin absolut d'accord was die Idee und die Vorgehensweise anbelangt, fürchte aber, dass es mit den Standardisierungen aus mehreren Gründen nichts wird. Martin S. schrieb: > XML-Beschreibungen gibt es schon einige, aber jeder kocht bisschen seine > eigene Suppe. Das ist eines der Probleme und das hat Methode: Die Hersteller möchten sich abgrenzen und tendieren stark vom allgemeinen VHDL weg. Damit werden allgemeine Verwaltungstools immer nutzärmer, seien es VHDL-basierte oder Scriptbasierte Systeme. Wenn man zweitens noch beschaut, dass die FPGAs immer herstellerspezifischer werden, zusätzliche MCUs beihalten, wird man wohl oder über SOC-Systeme mit Unterstützung der Herstellertools benutzen. Das bischen, was noch aussenrum an VHDL ist, scheint mir immer weniger zu werden. Und ob das lohnt? Ich fahre, soweit das jeweils möglich ist, alle Dokumentation tabellerasich mit Excel, weil ich damit per Programmierung in fast jedes Format übersetzen und parsen kann. Importier- oder lesbar sein muss das nicht und im Grunde möchte ich auch nicht ein allgemeines Format, das von anderen Tools gelesen werden kann - letztlich ist das geschickte Zusammenfüngen der Komponenten (SW und HW, SOC etc) genau die eigentlich Arbeitsleistung im Systemdesign :-)
Salut, Jürgen S. schrieb: > Solche Themen haben wir ja bereits des Öfteren in der einen oder anderen > Weise diskutiert. Ich bin absolut d'accord was die Idee und die > Vorgehensweise anbelangt, fürchte aber, dass es mit den > Standardisierungen aus mehreren Gründen nichts wird. Also nicht dass wir uns falsch verstehen: Einen 'Industriestandard' tue ich mir aus obigen erwähnten politischen Gründen nicht mehr an. Das kann man als komplett vergessen, sofern man nicht zum 'grossen S' gehört, drum gilt: lieber machen als totquatschen :-) Die Diskussionen zum Thema grafischen Programmieren sind mir grossteils bekannt, da will ich nicht hin. > > Martin S. schrieb: >> XML-Beschreibungen gibt es schon einige, aber jeder kocht bisschen seine >> eigene Suppe. > Das ist eines der Probleme und das hat Methode: Die Hersteller möchten > sich abgrenzen und tendieren stark vom allgemeinen VHDL weg. Damit > werden allgemeine Verwaltungstools immer nutzärmer, seien es > VHDL-basierte oder Scriptbasierte Systeme. > Glaube nicht, dass das was mit der Wahl der generierten Synthesesprache/Programmiersprache zu tun hat. Eher, dass Firmen a) ihr IP nicht verschenken wollen, b) möglichst ihren 'Standard' etablieren möchten, c) möglichst dafür Lizenzgebühren kassieren können (Ich will es nicht, mich interessieren die Projekte). Natürlich möchte man Kundenbindung, aber muss den Kompromiss eingehen, weil sich der Kunde tendentiell nicht binden möchte und prinzipiell nach einem unabhängigen offenen Standard strebt. Deswegen wurden ja auch Standards wie GenIcam (Gerätebeschreibung/Fernsteuerung für Kameras) ins Leben gerufen (die allerdings so ihre Probleme bzgl. Offenheit und Flexibilität haben) Interessant ist aber, dass der Trend bei den in-house Tools immer in irgend einer Weise Richtung XML geht und dazu auch von third parties viel Knowhow vermarktet wird. Was bedeutet, dass XML als de-facto-Standard-Mechanismus zur Hardwarebeschreibung inzwischen gut etabliert ist. > Wenn man zweitens noch beschaut, dass die FPGAs immer > herstellerspezifischer werden, zusätzliche MCUs beihalten, wird man wohl > oder über SOC-Systeme mit Unterstützung der Herstellertools benutzen. > > Das bischen, was noch aussenrum an VHDL ist, scheint mir immer weniger > zu werden. Und ob das lohnt? > Für mich schon, spart mir seit Jahren ne Menge Arbeit und Fehler. Es hört ja beim FPGA nicht auf, die Geschichten sollen früher oder später von aussen konfiguriert werden ('the internet of things'). Ob VHDL, Verilog oder Meta-Sprachen: Im Endeffekt ist relativ egal, was drin steckt. Der Knackpunkt ist die Wiederverwertbarkeit und eine sehr strenge Standarddefinition der XML-Semantik. Ändert sich die, übersetzt man die ganzen Datenbanken/Quellfiles mit relativ wenig Aufwand in die neue Revision. Gibt es eine neue Synthesesprache, muss ich halt die Stylesheets anpassen. Das knifflige ist(war) die Definition und Struktur des XML-Dialekts (für Spezis: Die XSD-Schemas). Faktisch definieren die XSDs den Standard und kriegen eine Versionsnummer. > Ich fahre, soweit das jeweils möglich ist, alle Dokumentation > tabellerasich mit Excel, weil ich damit per Programmierung in fast jedes > Format übersetzen und parsen kann. Importier- oder lesbar sein muss das > nicht und im Grunde möchte ich auch nicht ein allgemeines Format, das > von anderen Tools gelesen werden kann - letztlich ist das geschickte > Zusammenfüngen der Komponenten (SW und HW, SOC etc) genau die eigentlich > Arbeitsleistung im Systemdesign :-) Hast Du das wo dokumentiert, oder magst Du das genauer erläutern? Excel bzw. OOffice habe ich immer mal wieder als Hilfsmittel genutzt, die Wiederverwertbarkeit und Wartung war aber über die Jahre problematisch, mal abgesehen von der Nutzbarkeit von MS VB bzgl. verschiedener Versionen/Plattformen. Ein grosses Problem ist dabei die Synchronisation, wie oben erwähnt. Erst ein grafisches Tool starten müssen, um Source mit generiertem Code zu synchronisieren ist aus diversen Gründen no-go, abgesehen von Problemen mit der Versionskontrolle und einer Kollaborative (modular, ...). Auf lesbare Standard-Formate, die in 20 Jahren noch geparst werden können, legen halt einige in der Branche viel Wert. Von dem XML-Zug komme ich also nicht mehr runter, aber gewisse (auch xml-fremde) Methodik wäre durchaus interessant, um die Beschreibungsprache (den XML-Dialekt) entsprechend aufzubohren, also konkret, im Hinblick auf das einfache Wrappen von IPcores auf beliebige Bussysteme, wie von pks skizziert. Gruss, - Strubi
Strubi schrieb: > Erst ein grafisches Tool starten müssen, um Source mit generiertem Code > > zu synchronisieren ist aus diversen Gründen no-go, Man nenne mir ein Tool, das vor 10 Jahren neu war und heute noch aktuell gepflegt wird. Speziell im VHDL Bereich gibt es inzwischen weit über 50 Programme, die den Versuch unternahmen, VHDL-entry zu automatisieren und die sind alle wieder wech, während neue entstehen. Da möchte sich keiner mehr auf irgendwas festlegen, weil man ja gesehen hat, wie rasch sowas wieder verschwindet. Robei gebe ich 3 Jahre.
TippGeber schrieb: > Man nenne mir ein Tool, das vor 10 Jahren neu war und heute noch aktuell > gepflegt wird. Mentor Graphics HDL Designer
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.