Hallo, ich bin FPGA Quereinsteiger und habe nun mein erstes Projekt abgeschlossen. Als jemand der in der Softwareentwicklung von Assembler über C / C++ bis .Net alles mitgemacht hat muss ich sagen, dass ich noch nie so viel getippt und mit Copy & Paste entwickelt habe wie in VHDL. Überall merkt man dieser Sprache ihr hohes Alter an, und auch dass sie eigentlich gar nicht für die Synthese entwickelt wurde. Mag ja auch sein, dass dieses Empfinden nur auf meine Unerfahrenheit zurückzuführen ist. Dennoch frage ich mich, ob es nicht bereits Anstrengungen für eine Modernisierung der Sprache oder gar für eine komplette Neuentwicklung gibt. Verilog mag eine Alternative sein, aber DIE Lösung ist es auch nicht. Simulink HDL Coder und XSG ist ganz gut, aber zu speziell. Oder gibt es einfach keinen Bedarf an moderneren Werkzeugen?
Thomas schrieb: > Als jemand der in der Softwareentwicklung von Assembler über C / C++ bis > .Net alles mitgemacht hat muss ich sagen, dass ich noch nie so viel > getippt und mit Copy & Paste entwickelt habe wie in VHDL. Nimm Emacs im VHDL-mode das spart viel Tipperei. http://www.iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html MfG,
Thomas schrieb: > Verilog mag eine Alternative sein, aber DIE Lösung ist es auch nicht. > Simulink HDL Coder und XSG ist ganz gut, aber zu speziell. So wie ich dich verstehe, suchst du also eher eine abstraktere Methode um VHDL nicht zu schreiben, sondern mehr FPGA's zu beschreiben und dann mit, ich sags einfach mal so salopp, Codegenerierung die Drecksarbeit automatisiert machen zu können?
Hallo, ich habe mit der ISE entwickelt, aber hauptsächlich in Notepad++ getippt. Hat ja auch wirklich Spaß gemacht, sehr interessante Aufgabe. Suchen tue ich eigentlich konkret gar nichts. Das ist nur rein interessehalber, ob sich da irgendwo am Horizont was tut. In der Softwareentwicklung wird ja auch alle paar Jahre ein neuer Hype entfacht. Aber einiges davon ist auch wirklich hilfreich und hat zu einer enormen Qualitäts- und Effizienzsteigerung geführt. Mit Effizienz meine ich hier die der Entwicklungszeit.
@anderer Nee, ich würde schon gerne schreiben. Den grafischen Ansatz von Simulink mag ich zwar aber wie gesagt halte ich das für zu speziell um die Nachfolge von VHDL antreten zu können. Wenn VHDL sowas wie C wäre suchte ich also sowas wie C#.
> dass ich noch nie so viel > getippt und mit Copy & Paste entwickelt habe wie in VHDL. Ja - VHDL ist so ziemlich das Geschwätzigste was es überhaupt gibt. Ich komme mir auch manchmal vor wie ein Copy & Paste Krieger. :-(
Thomas schrieb: > Wenn VHDL sowas wie C wäre suchte ich also sowas wie C#. Vielleicht ist es SystemC was du suchst ... bis zur Simulation funktioniert das auch, aber mir ist kein gescheites frei erhältliches Synthesetool bekannt oder ein SystemC -> Vhdl Konverter.
Letztes Jahr gabs mal den Versuch ein vereinfachtes VHDL einzuführen, war im Prinzip eine Art Präprozessor.Links dazu ich aber grad nicht. Vielleicht erinnert sich ja ein anderer noch an den Namep pHDL oder so. MfG,
Hans-Georg Lehnard schrieb: > Vielleicht ist es SystemC was du suchst Verwendet das überhaupt jemand ausserhalb einer Universität? Wenn jemand mit C Software entwickelt hat, dann wird er System-C zur Hardwareentwicklung als Rückschritt empfinden... luppel schrieb: > Ja - VHDL ist so ziemlich das Geschwätzigste was es überhaupt gibt. Ja, das sagen die, die mit VHDL geschwätzig schreiben. Man kann auch mit C umständlich programmieren... Nehmen mal das: http://www.lothar-miller.de/s9y/archives/88-VHDL-vs.-Verilog-am-Beispiel-einer-Stoppuhr.html
:
Bearbeitet durch Moderator
Fpga Kuechle schrieb: > Letztes Jahr gabs mal den Versuch ein vereinfachtes VHDL einzuführen, > war im Prinzip eine Art Präprozessor.Links dazu ich aber grad nicht. > Vielleicht erinnert sich ja ein anderer noch an den Namep pHDL oder so. Es ist MyHDL: http://en.wikipedia.org/wiki/MyHDL Beitrag "Ist MyHDL für echte Anwendungen einsetzbar?" http://www.myhdl.org/ Python-basiert. MfG,
Fpga Kuechle schrieb: > Fpga Kuechle schrieb: >> Letztes Jahr gabs mal den Versuch ein vereinfachtes VHDL einzuführen, >> war im Prinzip eine Art Präprozessor.Links dazu ich aber grad nicht. >> Vielleicht erinnert sich ja ein anderer noch an den Namep pHDL oder so. > > Es ist MyHDL: > http://en.wikipedia.org/wiki/MyHDL > Beitrag "Ist MyHDL für echte Anwendungen einsetzbar?" > http://www.myhdl.org/ > > Python-basiert. > > MfG, Ich glaub Du meintest eher PSHDL http://pshdl.org/ Das kam ja letztes Jahr neu...
gg schrieb: > Fpga Kuechle schrieb: >> Fpga Kuechle schrieb: >>> Letztes Jahr gabs mal den Versuch ein vereinfachtes VHDL einzuführen, >>> war im Prinzip eine Art Präprozessor. >> Es ist MyHDL: > > > Ich glaub Du meintest eher PSHDL > http://pshdl.org/ Hm, ich muss gestehen ich hab die beiden für das selbe gehalten: eine von Hoschschulpädagogen didaktische aufbereitete VHDL-Variante um Einsteigern ein paar Brocken aus den dew Weg zu räumen ohne direkte Vorteile für Vollzeitentwickler. Beitrag "Elektronik-Stammtisch (Attraktor, Hamburg):FPGA/ PSHDL-Workshop" Beitrag "PSHDL => Erste Schritte für "Arduino" in der FPGAwelt?" http://www.heise.de/make/meldung/PSHDL-Board-fuer-FPGA-Einsteiger-2156768.html So ne Art Arduino für warmduschende FPGA-Möchtegerns (jajaja ich weiß das klingt arrogant - ist es wahrscheinlich auch , kann aber genauso wahr sein) MfG,
Ich kann verstehen, dass sich die alten Hasen gegen Neuerungen sträuben, aber die Zeit schreitet fort und irgendwann einmal wird man das alte Wissen nicht mehr brauchen. Früher hat einer auch noch Assembler programmiert und heute regieren Python und C++. Auch bei den FPGAs wird es so kommen.
FPGA-Neuling schrieb im Beitrag #4130793: > programmiert und heute regieren Python und C++. Nicht im Bereich der Hardwarenahen embedded Programmierung - dem Stammland der FPGA's. MfG,
Mich persönlich stört die Geschwätzigkeit von VHDL eher weniger, vor allem nicht, wenn ich Module schreibe, die auch synthetisiert werden. In diesem Fall überlege ich üblicherweise deutlich länger an einem Block als z.B. in C oder anderen Sprachen. Lothar Miller schrieb: > Verwendet das überhaupt jemand ausserhalb einer Universität? Ich habe vor einiger Zeit ein Praktikum bei einem Halbleiterkonzern absolviert und kann mich erinnern, dass der Einsatz von SystemC für die Verifikation zumindest diskutiert wurde. Die Entscheidung fiel dann aber zugunsten von SystemVerilog. Ob SystemC für andere Zwecke eingesetzt wird kann ich aber nicht sagen.
Was mich übrigens noch am meisten genervt hat war das Einbinden von Komponenten und Durchschleifen / Verbinden der Signale. Warum muss ich die Schnittstelle noch einmal definieren? Habe ich doch bereits in der Komponente selbst schon getan. Vielleicht ist das ja mit Packages einfacher, aber das wollte ich mir jetzt fürs erste Projekt nicht auch noch reinziehen. Hätte ja sein können, dass bereits ein Nachfolger Diskutiert wird. Exotische Emporkömmlinge wie MyHDL mögen interessant sein, kommen aber für mich nicht in Frage. Ich mache das was alle anderen auch machen, und das ist in DE eben VHDL.
Thomas schrieb: > Überall merkt man dieser Sprache ihr hohes Alter an, .. du meinst damit wahrscheinlich den Syntax (begin/end statt {/}, PortMapping sig => sig plus das nervige Komma statt Semicol. und das fehlende letzte Komma bzw. dann Semicol. etc.). Aber ansonst hat VHDL doch alles was ein C auch hat, inkl. Strukturen und Pointer (kann man sehr gut bei Simulationen verwenden, hat z.B. Verilog nicht!!). Für diese einfache Kosmetik kann man zT einen Präprozessor schreiben. Ein Äquivalent zur Klassen/Objektorientierung kann ich mir bei einer Beschreibungssprache wie VHDL nicht vorstellen. Das was mich persöhnlich am meisten aufregt, ist, dass man ellenlange Ports nicht zu Strukturen bzw. teilweise zu Strukturen inkl. IN/OUT-Decl zusammenfassen kann. Damit wird der Code erheblich übersichtlicher. > .., und auch dass sie > eigentlich gar nicht für die Synthese entwickelt wurde. Sie ist für Verifikation entwickelt worden, die Frage ist aber, ob Synthese nicht in Verifikation sematisch vollständig enthalten ist. Und natürlich: Synthese ist nicht gleich Synthese, selbst für FPGAs hat sich über Jahrzehnte einiges geändert.
Thomas schrieb: > Was mich übrigens noch am meisten genervt hat war das Einbinden von > Komponenten und Durchschleifen / Verbinden der Signale. Warum muss ich > die Schnittstelle noch einmal definieren? Habe ich doch bereits in der > Komponente selbst schon getan. Vielleicht ist das ja mit Packages > einfacher, aber das wollte ich mir jetzt fürs erste Projekt nicht auch > noch reinziehen. Variante 1: statt component bei der Instanzieirung auf die (compilierte) entityt in der work-lib referenzieren:
1 | HA1 : entity work.halfadder port map(a,b,s1,c1); |
siehe: http://vhdlguru.blogspot.de/2010/03/entity-instantiation-easy-way-of-port.html Variante 2: Emas vhdl mode http://www.iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.gif Funktioniert so: cursor in entity bewegen port -> copy anstossen an beliebiger stelle wird dann diese entity korrekt umgeformt als component , Instance, signal decleration etc eingefügt. > Hätte ja sein können, dass bereits ein Nachfolger Diskutiert wird. Im Prinzip wird permanent ein Nachfolger diskutiert. Da VHDL standardisiert ist, muß es aller 5 Jahre gereviewed werden . Gelehrt wohl VHDL-1993, aktuell (?) ist wohl VHDL-2008 https://www.doulos.com/knowhow/vhdl_designers_guide/a_brief_history_of_vhdl/
Sigi schrieb: > Das was mich persönlich am meisten aufregt, ist, dass man > ellenlange Ports nicht zu Strukturen bzw. teilweise zu Strukturen > inkl. IN/OUT-Decl zusammenfassen kann. Damit wird der Code erheblich > übersichtlicher. Die Verwendung von Records in Ports geht aber. Keine Ahnung ab welcher Version, aber ich mache das immer so. Man muss in- und out-Interfaces aber trennen.
Sigi schrieb: > du meinst damit wahrscheinlich den Syntax ([…] das fehlende > letzte Komma bzw. dann Semicol. etc.). Da hat sich letztens ein Anfänger drüber gewundert. Meinst du in der Portliste der Entity? Wenn ja, dann frage ich dich, wie für dich eine Funktionsdeklaration in C aussieht
1 | void Funktion(int a, int b, int c, ); |
So? Wenn nicht, was ist anders und wo ist dann das Problem mit VHDL? Wenn du nicht was komplett anderes meinst, wirst du merken, worauf ich hinauswill.
Funktionsprototypen kann man so schreiben:
1 | void func (int, int, int); |
und wenn man vergleicht zwischen C und VHDL, ist Zweiteres schon geschwätziger... Ich mags trotzdem und empfinde die Schreiberei nicht so arg.
Matthias schrieb: > und wenn man vergleicht zwischen C und VHDL, ist Zweiteres schon > geschwätziger... Ich mags trotzdem und empfinde die Schreiberei nicht so > arg. Zustimmung. Wenn VHDL geschwötzig dann ist C schwer verständliches Gebrabbel:
1 | while (!((line[i]>='a'&&line[i]<='z') || (line[i]>='A'&&line[i]<='Z' || line[i]=='\0'))) |
2 | {
|
3 | for(j=i;line[j]!='\0';++j) |
4 | {
|
5 | line[j]=line[j+1]; |
6 | }
|
7 | line[j]='\0'; |
8 | }
|
VHDL ist eben eine Computersprache, die versucht Naturspachlich zu sein. Eine VHDL-Verhaltensbeschreibung kann man 1:1 vorlesen und mit ein bißchen Englisch versteht man etwa was gemeint ist. Was für den einen geschwätzig, ist für den anderen selbsterklärend und verständlich. So isses auch im echten Leben, um etwas verständlich rüber zu bringen muss man in ganzen Sätzen sprechen. Ist jetzt geringfügig mehr Aufwand für den Erklärer aber goldeswert für den der die Schaltung verstehen soll. VHDL ist ja auch zur Dokumentation von Designs entwickelt worden. MfG,
Fpga Kuechle schrieb: > Wenn VHDL geschwötzig dann ist C schwer verständliches Gebrabbel: Der Code ist für mich problemlos verständlich. Ich finde ihn auch übersichtlicher, weil ganz klar Syntaxelemente (Klammern, Vergleiche, Rechensymbole etc.) von Daten (Variablen, Konstanten, etc.) getrennt sind. Übrigens will ich nichts gegen VHDL sagen. Mir gefiel und gefällt die Syntax nicht besonders, aber es ist absolut brauchbar und ich nutze es ohne zu meckern. Matthias schrieb: > Funktionsprototypen kann man so schreiben: Darum ging es mir nicht. ;-) Manche halten es für unlogisch, dass in der normalen Schreibweise der Portdeklaration hinter jeden Port ein Semikolon kommt, aber hinter den letzten nicht:
1 | entity Mux is |
2 | port ( |
3 | Inputs : in Std_Logic_Vector(7 downto 0); |
4 | Select_s : in Std_Logic_Vector(2 downto 0); |
5 | Output : out Std_Logic |
6 | );
|
7 | end Mux; |
Wenn man das aber in eine Zeile hintereinander schreibt, wird aber sofort klar, warum das Semikolon nicht da ist.
Wie wärs denn mit Chisel: https://chisel.eecs.berkeley.edu In Chisel beschreibt man Hardware in Scala. Der Scala Code wird dann für verschiedene Backends synthetisiert. Da gibt es zB ein zyklengenaues C++ Backend für Simulation oder ein Verilog-Backened, das dann in die FPGA/ASIC Toolchain geworfen wird. Das RISC-V Team von Berkley implementiert ihre Prozessoren in Chisel. Das ganze funktioniert auch im ASIC Tape Out. Siehe folgendes Paper dazu: http://www.cs.berkeley.edu/~yunsup/papers/riscv-esscirc2014.pdf Weiters gibt es das ganze auch als FPGA Impleemntierung. Siehe dazu die zugehörigen Repositories auf GitHub: https://github.com/ucb-bar
Fpga Kuechle schrieb: > Eine VHDL-Verhaltensbeschreibung kann man 1:1 vorlesen und mit ein > bißchen Englisch versteht man etwa was gemeint ist. Nicht wirklich. Nein nicht wirklich.
> du meinst damit wahrscheinlich den Syntax Mag sein, auch. Aber wie gesagt, vor allem die oben beschriebenen Copy & Paste Orgien aus eigenem Code missfallen mir. Liegt aber sicher auch an der Entwicklungsumgebung. Im Vergleich zu IDEs in der Anwendungs- oder Webentwicklung ist die ISE finsterste Steinzeit. Da bin ich echt mehr Komfort gewohnt. > Variante 1 Danke, klingt interessant. > Variante 2 Emacs ist mir viel zu kompliziert. Wer damit groß geworden ist OK, aber heutzutage heute kann man sowas doch wirklich nicht mehr empfehlen. Abgesehen davon limitiert das zwar die Tipparbeit, aber übersichtlicher wird der Code dadurch auch nicht. Aber ich will auch nicht zu sehr meckern, hat ja trotzdem Spaß gemacht. Wahrscheinlich liegt es auch daran, dass SW-Programmierer sich selbst helfen und Programmiersprachen / IDEs entwickeln und dabei ihren eigenen Bedarf einbringen können. Daher die große Vielfalt und Dynamik in dem Bereich. Ein HW-Entwickler kann das nicht. Er ist auf andere angewiesen.
Oh doch, oh doch.. ..eigentlich. Die Lesbarkeit in richtigen Worten ist ein echter Wert an sich, aber durch eine gewisse Verbildetheit von C-Programmierern ist dies für diese unverständlich geworden. Das ist aber ein C-Problem. Dussel schrieb: > Wenn man das aber in eine Zeile hintereinander schreibt, wird aber > sofort klar, warum das Semikolon nicht da ist. Das, was du da grad ansprichst, ist eben auch ein Problem von C-Leuten, die es eben nicht verstehen, daß das Semikolon ein Trennzeichen ist und eben ausdrücklich zum Trennen und nicht zum Abschließen gedacht ist. Naja, das Problem von VHDL ist nicht die Schreibweise, also daß man mit echten Wörtern wie begin und end arbeitet, sondern die innere Störrischkeit und einige Unüberlegtheiten bei Vektoren. Die Hälfte der VHDL-Literatur befaßt sich damit, wie man arithmetische Operationen auf Standard-Vektoren anwendet - trotz der ausdrücklichen Intention der Spracherfinder, selbiges partout nicht zulassen zu wollen. Es wird aber immer wieder gebraucht, das Verwenden von obigen Standard-Vektoren wird im gleichen Maße gelehrt und genau deshalb kommt ubiquitärer Frust auf und Leute wie z.B. ich nehmen dann lieber Verilog und Schematics, wo man all diesen Frust nicht hat. OK, dafür gibt's anderen, aber eben nicht DIESEN. W.S.
Thomas schrieb: > Wahrscheinlich liegt es auch daran, dass SW-Programmierer sich selbst > helfen und Programmiersprachen / IDEs entwickeln und dabei ihren eigenen > Bedarf einbringen können. Daher die große Vielfalt und Dynamik in dem > Bereich. > Ein HW-Entwickler kann das nicht. Er ist auf andere angewiesen. Den wirklichen Knackpunkt hast Du noch nicht gesehen. Du kannst Dich in VHDL auch mit den aktuellen Sprachmitteln wunderbar austoben. Das heißt aber noch lange nicht, dass das, was Du da hingeschrieben hast, auch tatsächlich in Hardware synthetisiert werden kann. Letztendlich versteht der Synthetisierer nur einen kleinen Teil von VHDL. Und einen guten Synthetisierer zu schreiben, ist keinesfalls trivial. fchk
Thomas schrieb: >> Variante 2 > Emacs ist mir viel zu kompliziert. Wer damit groß geworden ist OK, aber > heutzutage heute kann man sowas doch wirklich nicht mehr empfehlen. > Abgesehen davon limitiert das zwar die Tipparbeit, aber übersichtlicher > wird der Code dadurch auch nicht. ?Emacs bietet PullDown Menus und Maussteuerung wie jeder GUI-Editor auch. was meinst du mit "zu kompliziert" konkret? Und emacs hat auch syntax-highlight, beautify mode, templates das ganze übliche eye-candy. OK die widgets sehen a bisserl eingestaubt aus ... > Aber ich will auch nicht zu sehr meckern, hat ja trotzdem Spaß gemacht. > Wahrscheinlich liegt es auch daran, dass SW-Programmierer sich selbst > helfen und Programmiersprachen / IDEs entwickeln und dabei ihren eigenen > Bedarf einbringen können. Daher die große Vielfalt und Dynamik in dem > Bereich. > Ein HW-Entwickler kann das nicht. Er ist auf andere angewiesen. Nope, ein HW-Entwickler kann sehr wohl mit dem Computer auch programmierender weise umgehen. Viele CAE-Software stammt aus der Unix-Ecke bspw har Xilinx seine Soft auch für SUN-OS geschrieben und mit Tcl gibt es eine Scriptsprache die orginär für CAE entwickelt wurde. Und nicht zuletzt seit Softcores wie BIOS und microblaze zu FPGA-Entwicklungsumgebungen integral dazugehören ist C-Programmierung Alltags-werkzeug auch für FPGA embedded entwickler. MfG, PS: Variante 3: Im Editor seiner wahl ein Macro definieren/aufzeichnen das automatisch eine entity Port -zeile in eine Portmap - Zeile umformt. Variante 4: awk/perl/... script dafür schreiben.
> Und einen guten Synthetisierer zu schreiben, ist keinesfalls trivial. Das glaube ich gerne. Im Gegensatz zu Compilern gibt es Synthetisierer ja auch ausschließlich vom Hersteller des FPGAs, oder nicht? Ist die Aufgabe eines Synthetisierers eigentlich mit der eines Autorouters vergleichbar?
Thomas schrieb: > Im Gegensatz zu Compilern gibt es Synthetisierer ja auch ausschließlich > vom Hersteller des FPGAs, oder nicht? Nope, das ist eher ein neuer Trend. Synthese-tools werden klassischer Weise von (ASIC)-CAE/EDA Firmen programmiert: -Mentor Graphics -Cadence -Synopsys MfG,
Thomas schrieb: > Ist die Aufgabe eines Synthetisierers eigentlich mit der eines > Autorouters vergleichbar? Eher nicht. Der Autorouter findet sich dann im herstellerspezifischen Place&Route Tool. Der Synthesizer ist eigentlich der Compiler, der von der einen Sprache (VHDL) ind die andere (Schaltung) übersetzt. Dabei gibt es zwei "Eskalationsstufen" der Schaltung: die erste ist eine bausteinunabhängige Schaltung, wo ein 5-fach UND einfach als 5-fach UND "gezeichnet" wird. Die zweite Stufe ist dann die Übertragung in den realen Chip. Und da wird bei einem 6er-LUT-Baustein eine einzige LUT verwendet, bei einem 4er-LUT-Baustein werden 2 LUTs hintereinander geschaltet. Fpga Kuechle schrieb: > Nope, ein HW-Entwickler kann sehr wohl mit dem Computer auch > programmierender weise umgehen Aber dieser komplette Editorschnickschnack mit Autovervollständigung, Crossreferenzen und Wasweißichnochalles kommt eher als "Abfallprodukt" aus der Softwareentwickler-Ecke... Matthias schrieb: > Die Verwendung von Records in Ports geht aber. Schon lang. Frag mal Jiri Gaisler. Der lebt davon... ;-) FPGA-Neuling schrieb im Beitrag #4130793: > Ich kann verstehen, dass sich die alten Hasen gegen Neuerungen sträuben, > aber die Zeit schreitet fort und irgendwann einmal wird man das alte > Wissen nicht mehr brauchen. Früher hat einer auch noch Assembler > programmiert und heute regieren Python und C++. Ich kenne noch viele Leute, die C programmieren. Oder C++ auf "C-Ebene"... > Auch bei den FPGAs wird es so kommen. Das ist die ganze Matlab-Ecke, wo es erst mal nur darum geht, ein Modell schnellstmöglich in ein FPGA zu kloppen. Ob das FPGA dabei effizient genutzt wird ist nachrangig. Es ist erst mal schnell genug, und wenn sich der Algorithmus bewährt kann er hinterher noch optimiert werden. Diese Strategie kommt aus der Softwareentwicklung. Allerdings wird dort der Optimierungsprozess ausgelassen und gleich die erste halbwegs lauffähige Softwareversion auf den Markt geworfen. Nur so bekommt man auch Gigahertz schnelle Rechenboliden langsam... ;-)
Variante 5: Die component-Beschreibung in ein Package auslagern (Xilinx macht das ebenso). Das wäre dann ziemlich C-ähnlich. Ich fand es am Anfang auch geschwätzig. Aber mit den richtigen Varianten und Erfahrung ist es gut zu handeln. Am Ende spart man sich die Zeit beim Fehlersuchen.
Moin, achgott, mein "Lieblingsthema", und jetzt hab' ich's doch angeklickt. MyHDL hat schon IMHO die meisten Chancen, etwas wirklich brauchbares zu werden. Aber: eine neue Sprache zu HDL sollte man wirklich nicht mehr erfinden, auch so Sachen wie pshdl ist ehrlich gesagt eher akademische Frickelei. Es gibt noch recht projektspezifische Hacks wie "misoc" (wer erinnert sich nicht an die heissen Diskussionen auf der myhdl-Liste). Bei SystemC bin ich mir auch nicht so sicher, ob das wirklich Arbeit spart... Ich finde, man sollte das so sehen wie mit C und Assembler. Soll mal Verilog und VHDL die Low-Level-Sprache bleiben, und bloss nicht mehr geändert werden. Mehr Sinn machen dann eben Tools wie MyHDL, die das grob-funktionale Design und das Testbenching massiv erleichtern und das eine oder andere einfach ausgeben, was man dann nochmal mit den gängigen Simulatoren verifizieren kann. Inzwischen nutze ich VHDL faktisch nur noch als "Glue language" um die generierten Module zusammenzukleben. Auf sowas läuft es bei den IP-Core-Tools der üblichen Verdächtigen sowieso hinaus. Grüsse, - Strubi
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.