Wer hat schon mal versucht ein VHDL-Design objektorientiert anzugehen? Das Thema klingt für mich hochinteressant und ich würde gerne von euch Tipps bekommen, wo ich gezielt ansetzen soll. Ich hab diese Diss hier gefunden: http://deposit.ddb.de/cgi-bin/dokserv?idn=958338353. Derzeit bin ich nur drübergeflogen, aber es sieht schon mal aus, als ob das in die gleiche Richtung geht.
VHDL objektorientiert angehen, heißt doch m.E. nach, von Sub-Level-Entities ordentlich Gebrauch zu machen. Entity=Klasse, Instanz=Objekt, Port=öffentliche Attribute usw. Damit ist VHDL doch bereits ziemlich "objektorientiert".
naja, vhdl ist grundsaetzlich sehr objektorientiert, durch die kapselung mit entities, sowie gibt's noch andere OO-Features wie zb overloading, usw. u ich wuesste spontan nicht, was sonst noch an OO bei einer HDL sinn machen wuerde, aber ich hab die verlinkte arbeit auch noch nicht gelesen, hab grad keine zeit.
Ich denke da eher an so Sachen wie Vererbung, Ableitung und Polymorphismus.
Ganz konkret möchte ich Records implementieren, die eben mehrfach verschachelt sind. Gut, hört sich jetzt mal nicht so arg an, aber spätenstens, wenn man innerhalb eines Records, dann wiederum Records oder gleich Arrays von Recordssets hat, habe ich Probleme, weil ich dieses große "Basisrecord" als Generic-Parameter einbinden will und mit einem einzigen großen Zuweisungsstatement alle Daten eingeben will. Die Arrays sollen zudem noch unconstrained sein!
also rein VHDL-maessig ist so eine verschachtelung eigentlich kein problem, nur haben manche synthese-tools wie zb XST damit probleme. und willst du die groesse des arrays zur compile-time oder zur run-time festlegen koennen?
Die Größe soll schon zu Compilezeit feststehen, allerdings, wenn ich mir meine Typen deklariere, dann verlangen die Compilier bereits ein constraint Array. Folgendes geht zB nicht:
1 | subtype aByte is std_ulogic_vector (7 downto 0); |
2 | |
3 | type aStage1 is record |
4 | StageNum : aByte; |
5 | Flag : std_ulogic; |
6 | end record; |
7 | |
8 | type aStage1Set is array (integer range <>) of aStage1; |
9 | |
10 | type aStage2 is record |
11 | StageNum : aByte; |
12 | Flag : std_ulogic; |
13 | OneStages : aStage1Set; -- FEHLER: Hier wird ein Range verlangt |
14 | end record; |
naja, also meiner meinung nach ist ein array so auch kein wirklicher datentyp, das kannst du ja in C++ oder aehnlichem auch nicht so definieren (zumindest haett ich das noch nie gesehn oder gehoert). der compiler kann ja nicht raten, wie der datentyp jetzt wirklich aussehn soll. in C++ wuerde ich sowas mit einem Template loesen, u dementsprechend wuerde ich das in VHDL mit einem generic loesen.
Definier genauer: ob für synthese oder verifikation/simulation was es bringen soll. was VHDL noch fehlt zur Objektorientierung wenn es um simu/veri geht da steht der Trend weg von VHDL zum objektorientierten E. bei der Synthese (also um FF und Logik zu beschreiben) sehe ich keine Möglichkeit objektorientiert zu arbeiten. Also wahrscheinlich vermeinst Du perr OO comnponenten einfach erweitern zu können. Hm, das geht nicht schmerzfrei, im FPGA sind die resourcen begrenzter. da nutzt keine schnelle Codefertigstellung durch Vererbeung, wenn dein chip plötzlich halb so schnell ist. In einer CPU mögen die 5% Leistungseinbruch durch OO verschmerzbar sein. letzlich ist die Frage wie man besser und schneller FPGA bastelt. Softwareentwicklung geht besser durch OO (sagen die Softwerker), FPGA entwicklung geht besser durch ... (OO hat da noch kein Hardwerker gesagt)
>Wer hat schon mal versucht ein VHDL-Design objektorientiert anzugehen? Hat schon einmal jemals etwas anderes versucht? (abgesehen von denen, die aus dem C-Umfeld stammen und alles als flow anehen) VHDL-module SIND Objekte! Gegenteilige Ansichten ?
FPGAküchle wrote: > Definier genauer: > ob für synthese oder verifikation/simulation > was es bringen soll. > was VHDL noch fehlt zur Objektorientierung Es soll sowohl für Simulation als auch Synthese sein. Ich will damit ein ROM beschreiben mit fixer Größe, also werden die Ressourcen sicher nicht zu knapp! Das ROM speichert halt Gerätespezifische Daten, die aber von Einsatz zu Einsatz variieren und das ROM ist auch nicht immer voll mit Information. Das steht aber schon zur Compilezeit fest, welche Daten drin stehen. Da aber das ROM in mehreren Testbeds eingesetzt wird muss ich das generisch angehen, weil ich sonst 50 Mal die VHDL-Datei welche das ROM beschreibt anlegen muss und dies früher oder später im Chaos endet. VHDL fehlt zu Objektorientierung die Tatsache, dass man die Daten nicht dynamisch zur Verfügung stellen kann. Wie man im Beispiel oben sieht verlangt VHDL bereits bei der Typdeklarierung eine definierte Länge. Das hat jetzt insofern mit OO zu tun, weil ein definierter Datentyp andere Datentypen beinhält (nämlich ein Array) und somit andere Funktionalität, bzw. Daten "erbt". >VHDL-module SIND Objekte! Wenn man genauer darüber nachdenkt, ist was Wahres dran. Da geb' ich dir recht!
wie schon mal oben gesagt, auch in keiner OO-Software Programmiersprache laesst sich ein type mit einem unconstrained array definieren, das geht hoechstens bei der definition mit einem void-pointer (das ist dann aber nur eine variable, mit diesem typen, und kein generell deklarierter type) bzw. mit templates (siehe STL bitsets). und genau sowas laesst sich auch in VHDL mit einer signal-definition, die von einem generic abhaengt, realisieren. Ich finde, du hast da einfach unrealistische Vorstellung von Sprachfeatures, die kein Compiler der Welt unterstuetzen kann, weil kein Compiler telepathisch erfahren kann, was du gern haettest. Und was heissen soll, man kann die Daten, man in ein ROM schreibt, nicht dynamisch uebergeben, wenn sie eh schon zur compile-time feststehen, das musst du mir auch mal erklaeren. denn mit generics laesst sich das definitiv machen. Das einzige was ich mir noch OO-maessig bei einer HDL vorstellen koennte, waere zb aus einem Up-Down-Counter einen reinen Up-Counter abzuleiten o.ae., aber ob das wirklich einen Sinn macht, wage ich auch sehr zu bezweifeln.
> wie schon mal oben gesagt, auch in keiner OO-Software Programmiersprache > laesst sich ein type mit einem unconstrained array definieren In Java: Variablentyp "int[]", Klasse "[I" stellt ein zur Compilezeit unbeschränktes Array von Integerzahlen dar - die Elementezahl wird bei Instanziierung festgelegt und bleibt danach. (Okay, limitiert auf max. 2^32 Elemente, aber ich glaube nicht dass das hier gemeint ist. Außerdem könnte man die Idee leicht auf 2^64 ausweiten und ist alle Probleme los). Mit dem Variablentyp "List<Integer>", Klasse "List" ist die Elementezahl auch nach der Instanziierung variabel (wieder auf 2^32 bzw. durch verfügbaren Speicher beschränkt). Das ändert nix daran dass im Beispiel von Johannes Traxler generics angebracht wären. Softeware-Programmiersprachen sind eben was anderes als Harwarebeschreibungssprachen.
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.