Hallo, ich habe mich jetzt etwas tiefer mit VHDL befassen dürfen und fluche zunehmend über hierarchisches Design damit. Und zwar nervt es ungemein, dass man ein Interface im betreffenden Block angeben muss (als ENTITY), zusätzlich in jedem Block, der es benutzen will (als COMPONENT) und für jede Instanz nochmal als Portmap. Wenn ich in einem kleinen Block das Interface ändern möchte, zieht das im Zweifelsfall viele Änderungen nach sich, und alleine das geradezuziehen dauert ewig (auch, weil das Verhältnis von Tipparbeit zu Ergebnis ziemlich bescheiden ist). In einem (in einem anderen Thread beschriebenen) Lab haben wir mehrere Stunden allein damit verbracht, bereits vorhandene Blöcke in eine hierarchische Struktur zu bringen und zu testen (ein Großteil davon nervtötende Tipperei). In C wäre das eine Sache von 20 Minuten gewesen. In C definiert man die Schnittstellen in einem gemeinsamen Header. Gibt es etwas vergleichbares in VHDL - oder wie kommt ihr damit klar, Schnittstellen x-mal kopieren zu müssen? Kann Verilog das besser? (Und wer hat sich eigentlich das Wort "std_logic_vector" ausgedacht? Hätte es "vec" nicht auch getan?) Schönen Gruß, svenska
Die Component musst du glaube ich seit VHDL2008 nicht mehr mit angeben. Es reicht die Komponente in der Port Map zu instanzieren: instance : entity work.your_component port map( -- your interface mapping! ); Wenn dir std_logic_vector zu lang ist, kannst du in vhdl auch eigene typen definieren. Der Name ist aber finde ich sehr aussagekräftig. Es handelt sich um ein signal aus der Standard-Lib, es ist ein logisches Signal, kann also 0 und 1 sein und ist mehrdimensional also ein Vektor. C und VHDL kann man nicht vergleichen. In C programmierst du einen Ablauf, in VHDL beschreibt man einen Aufbau. Es ist auf jeden Fall eine enorme Umstellung von C auf VHDL und die Tipperei nervt teilweise wirklich. Mit Verilog kenne ich mich leider nicht aus. Das was in C die Header Datei ist, ist in VHDL die Entity. Ich sehe da jetzt keinen Unterschied. Du kannst deine Schnittstellen auch in einer eigenen Library definieren und diese in deine Komponenten einbinden. Dann musst du deine Schnittstelle nur noch an einer Stelle anpassen. Übrigens in diesem Paper schön beschrieben: http://www.gaisler.com/doc/vhdl2proc.pdf Viele Grüße, Bernhard
Ja, es gibt so etwas wie header, in denen du die Entities als component nur einmal deklarierst und dann überall benutzen kannst, wo du die Datei einbindest. Nennt sich in VHDL package.
Und nein, "vec" hätte es nicht getan, weil damit der Datentyp des Vectors noch nicht klar ist, in diesem Fall ein Vektor von std_logic.
Bernhard R. schrieb: > Übrigens in diesem Paper schön beschrieben: > http://www.gaisler.com/doc/vhdl2proc.pdf Das mit den Records als Port ist ja durchaus sinnvoll, aber über den Rest in diesem Papier lässt sich aber trefflich diskutieren und ausdauernd streiten... Im Beitrag "Gaisler-Religion?" ist dazu mal ein kleiner Abriss. Und (jetzhabichihndochnochgefunden) den Beitrag ""Guter Programmierstil" VHDL"
:
Bearbeitet durch Moderator
> In C definiert man die Schnittstellen in einem gemeinsamen Header. Gibt > es etwas vergleichbares in VHDL - oder wie kommt ihr damit klar, > Schnittstellen x-mal kopieren zu müssen? > Ja es gibt so was. Das ist eine package Datei. Das ist eine VHDL Datei in der man Funktionen oder Components deklariert. Muss natürlich eigebunden werden.
Ja stimmt der Rest des Papers ist wohl Ansichtssache. Den "Guter Stil" Thread habe ich gleich mal auf 'Beobachten' gesetzt. Da kann ich sicher gut was mitnehmen. :-) VHDL klar und simpel zu schreiben scheint für viele nicht machbar zu sein. :-/
Bernhard R. schrieb: > Die Component musst du glaube ich seit VHDL2008 nicht mehr mit > angeben. Das ist schonmal eine Erleichterung. Wobei ich nicht glaube, dass wir das in dem Kurs benutzen dürfen, aber immerhin. > Wenn dir std_logic_vector zu lang ist, kannst du in vhdl auch eigene > typen definieren. Der Name ist aber finde ich sehr aussagekräftig. Es > handelt sich um ein signal aus der Standard-Lib, es ist ein logisches > Signal, kann also 0 und 1 sein und ist mehrdimensional also ein Vektor. Eben nicht. Ein std_logic ist nicht nur "0" oder "1". Ich finde diese sinnlose Tipperei nur nervig. > C und VHDL kann man nicht vergleichen. In C programmierst du einen > Ablauf, in VHDL beschreibt man einen Aufbau. Es ging mir gerade nicht um die Beschreibung der Hardware, sondern nur um die Beschreibung der Struktur. Nach einem Tag Structurals zusammentippen will man mit der Maus Boxen zusammenklicken... VHDL hotline schrieb im Beitrag #4759559: > Und nein, "vec" hätte es nicht getan, weil damit der Datentyp des > Vectors noch nicht klar ist, in diesem Fall ein Vektor von std_logic. Warum verlangt man dann nicht "ieee.std_logic_1164.std_logic_vector" als Datentyp? Es ging mir darum, den (wie es scheint) häufigst verwendeten Datentypen von 16 auf 3 Zeichen zusammenzukürzen. VHDL hotline schrieb im Beitrag #4759549: > Ja, es gibt so etwas wie header, in denen du die Entities als > component nur einmal deklarierst und dann überall benutzen kannst, > wo du die Datei einbindest. Nennt sich in VHDL package. Das impliziert irgendwie Wiederverwendbarkeit, die in einem Uni-Kurs eher nicht gegeben ist. ;-) Lothar M. schrieb: > Das mit den Records als Port ist ja durchaus sinnvoll, aber über den > Rest in diesem Papier lässt sich aber trefflich diskutieren und > ausdauernd streiten... Naja, uns wurde eingetrichtert: - FSM mit 2 Prozessen, Ausnahmen: Reset und Enable (weil die fertigen Blöcke das schon haben, also keine Zusatzlogik) - Variablen und for-Schleifen sind verboten. Beides aber mit dem Hintergrund, dass das ein Einführungskurs ist und wenn man das begriffen hat, darf man davon abweichen (ist mMn sinnvoll). > Im Beitrag "Gaisler-Religion?" ist dazu mal ein kleiner > Abriss. > Und (jetzhabichihndochnochgefunden) den > Beitrag ""Guter Programmierstil" VHDL" Hmm. Klingt, als ob das, was mich an VHDL massiv nervt, da alles nicht so drin ist. Außer "in modernem VHDL darf man COMPONENTs weglassen" und "ALL darf in die Sensitivliste". Bleibt die Frage: Ist Verilog da besser? Vom Stil her ähnelt es eher C (kürzer und dreckiger; mehr Pistolen für die eigenen Knie). Bernhard R. schrieb: > VHDL klar und simpel zu schreiben scheint für viele nicht machbar zu > sein. :-/ Wenn ich in einem Roman erstmal ein Drittel inhaltslose Strukturbeschreibung lesen muss, dann bin ich schon so übermüdet, dass ich den eigentlichen Inhalt auch nicht mehr erfassen kann... ;-)
S. R. schrieb: > Wenn ich in einem Roman erstmal ein Drittel inhaltslose > Strukturbeschreibung lesen muss, dann bin ich schon so übermüdet, dass > ich den eigentlichen Inhalt auch nicht mehr erfassen kann... ;-) Beim Herr der Ringe muss man auch erst mal die ersten 50 Seiten überwinden! Danach wird die Story erst interessant. Also dran bleiben...! :-)
:
Bearbeitet durch User
Bernhard R. schrieb: > Die Component musst du glaube ich seit VHDL2008 nicht mehr mit angeben. > Es reicht die Komponente in der Port Map zu instanzieren: > > instance : entity work.your_component > port map( > -- your interface mapping! > ); Das geht auch schon mit VHDL93
S. R. schrieb: > Warum verlangt man dann nicht "ieee.std_logic_1164.std_logic_vector" als > Datentyp? Es ging mir darum, den (wie es scheint) häufigst verwendeten > Datentypen von 16 auf 3 Zeichen zusammenzukürzen. nutz nen gscheiden Editor. Manche Sachen sind in VHDL nervig. Siehe dazu auch http://electronics.stackexchange.com/questions/16767/vhdl-or-verilog Nichtsdestotrotz. Ich denke, auch weil es mir ähnlich ging, dass VHDL die bessere Sprache VOR ALLEM für Einsteiger ist. Ich habe auch schon ein paar Dinge in Verilog probiert. Aber vor allem die C-Syntax verleitet dazu Sachen so zu machen, wie sie definitiv nicht synthetisierbar sind... Als Editor, gerade als Student, kann ich sigasi empfehlen. Autocomplete, Integration mit Modelsim etc. Ganze Textblöcke lassen sich so rel. einfach erstellen. Der Atom Editor mit VHDL/Verilog Erweiterung befindet sich auch auf dem richtigen Weg...
S. R. schrieb: > Bleibt die Frage: Ist Verilog da besser? Vom Stil her ähnelt es eher C Und verleitet dann zum "Programmieren" statt zum "Hardware beschreiben"... > (kürzer und dreckiger; mehr Pistolen für die eigenen Knie). Und viel mehr implizites Wissen zur Sprache und zum Design nötig. Mir reicht es aus, wenn ich Verilog so gut lesen kann, dass ich einen strukturellen Fehler im Design finde. Ich muss es nicht auch noch "elegant" schreiben können...
Moin, jajaja, VHDL versus Verilog... Wenn man sich an das Copy-Paste-Engineering gewöhnt hat, und seinen VHDL-Code wie sauberes ADA formatiert, ist das deutlich lesbarer als Verilog, aber das ist mal wieder eine redundante Meinungskundtuung :-) Bei Hardware mag ich generell kein "lazy coding", wie Verilog gerne zu verführt. Also lieber was strenges, was viel motzt, aber später auch im Zusammenspiel mit anderen Modulen leichter zu debuggen ist. Man kann aber auch andere Ansätze gehen (hier wieder etwas Werbung): Python/MyHDL. Dann wird VHDL/Verilog zur Transfersprache für die Synthese bzw. Simulation mit seinem Lieblings-Simulator. Was aber nicht heisst, dass man die Transfersprache nicht verstehen sollte. Da hat man dann quasi beides: schnell mal was ausprobieren und im Grundprinzip funktional simulieren können, ohne sich in Copy&Paste-Orgien zu verstricken, und für die strengen Tests dann mit dem generierten VHDL nur noch auf die Fehlersuche in der Logik/Arithmetik konzentrieren können. Nachteil ist bei MyHDL, dass die gesamte Architektur in der Ausgabe flach ausgerollt wird und die Modularisierung im Zusammenspiel mit existierender V*-HDL etwas Handarbeit benötigt. Ansonsten ist es meiner Meinung nach das bisher gelungenste Mischkonzept zwischen Verilog/VHDL/SystemXXX. Grüsse, - Strubi
Strubi schrieb: > Wenn man sich an das Copy-Paste-Engineering gewöhnt hat, und seinen > VHDL-Code wie sauberes ADA formatiert, ist das deutlich lesbarer als > Verilog, aber das ist mal wieder eine redundante Meinungskundtuung :-) Ich habe nicht damit angefangen, deshalb darf ich auf das hier verweisen: http://www.lothar-miller.de/s9y/archives/88-VHDL-vs.-Verilog-am-Beispiel-einer-Stoppuhr.html Aber allemal besser VHDL oder Verilog zu nehmen, als das Zeug mit dem Schematic-Editor zusammenclicken zu wollen wie im Beitrag "kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)" ... ;-)
Alabama J. schrieb: > nutz nen gscheiden Editor. Da sind wir etwas auf Vivado angewiesen (alternativ wäre auf den Rechnern noch Wordpad drauf...). Nervig ist, dass Vivado Syntaxfehler nicht immer erkennt, bzw. manchmal Fehler anmeckert, wo keine (mehr) sind. Irgendwie ist mir Vivado unsympathisch, aber Alternativen dazu gibt's ja auch nicht. Strubi schrieb: > Wenn man sich an das Copy-Paste-Engineering gewöhnt hat, und seinen > VHDL-Code wie sauberes ADA formatiert, ist das deutlich lesbarer als > Verilog, aber das ist mal wieder eine redundante Meinungskundtuung :-) Och, mit genügend Aufwand kann man so ziemlich jede Sprache extrem gut lesbar / verständlich formatieren (Basic mal ausgenommen), insofern glaube ich mal, dass das auch mit Verilog ginge. Mich stört halt schlicht das Copy-Paste-Engineering. Einmal das Gefühl, nicht voranzukommen (ich tippe oft neu statt zu kopieren, weil es mir dann besser im Hirn hängenbleibt und ich den Überblick nicht verliere), zum anderen ist es bei Softwaredesign extrem schlechter Stil. VHDL fühlt sich für mich an wie Assembler. Kann ich einigermaßen lesen und sicherlich auch schreiben, will ich aber nicht. Das ist so viel unnütze Arbeit, die ich einem Tool überlassen kann und dafür auch gerne bereit bin, 10% Leistung abzudrücken. Allein der Aufwand, den ganzen Mist für eine Testbench (besser: mehrere Testbenches) nochmal zusammenbasteln zu müssen, ist mir zuwider. In der Zeit kann ich 100 Bitstreams erzeugen und testen ("genug für das Projekt", und perfekt muss es auch nicht sein). Mir ist klar, dass für größere Projekte da andere Strategien verfolgt werden und andere Regeln gelten, aber für ein Hello-World ziehe ich auch keine Repository-Infrastruktur mit verteilten Backups und Regression-Tests hoch... > Man kann aber auch andere Ansätze gehen (hier wieder etwas Werbung): > Python/MyHDL. Dann wird VHDL/Verilog zur Transfersprache für die > Synthese bzw. Simulation mit seinem Lieblings-Simulator. Das klingt wieder äußerst interessant. ;-) Wobei wir - akademisches Umfeld - dann wieder zu irgendwelchem akademischen Zeug gezwungen sind, z.B. Chisel (basiert auf Scala und ist mir allein deswegen eher unsympathisch - Link: https://chisel.eecs.berkeley.edu/). Seufz. > Nachteil ist bei MyHDL, dass die gesamte Architektur in der Ausgabe > flach ausgerollt wird und die Modularisierung im Zusammenspiel mit > existierender V*-HDL etwas Handarbeit benötigt. Muss man bei MyHDL das Ergebnis noch nachbearbeiten oder funktioniert das eher "einfach so"? Kann man da VHDL-/Verilog-Blöcke einfach einbinden? Nein, ich habe mich damit nicht beschäftigt und frage deswegen einfach nach. ;-) Lothar M. schrieb: > Ich habe nicht damit angefangen, deshalb darf ich auf das hier > verweisen: > http://www.lothar-miller.de/s9y/archives/88-VHDL-vs.-Verilog-am-Beispiel-einer-Stoppuhr.html (a) Dein VHDL-Stil gefällt mir, zumindest ist er deutlich kürzer und verständlicher als der uns beigebrachte. Dein Blog ist klasse! (b) Mir gefällt aber insbesondere die kurze Verilog-Testbench... nur müsste man dazu eben Verilog können. ;-) In dem verlinkten Thread stand auch drin, dass die Sensitivliste nur für die Simulation relevant ist. Das hatte ich auch noch nicht so auf dem Schirm... danke dafür. Ich ziehe mal für mich die Schlussfolgerung, dass es die Silberkugel nicht gibt und man wenigstens eine Kröte schlucken muss. Der Thread darf gerne weiter abdriften, so lerne ich mehr. Insbesondere aus Fehlern anderer, denn das spart mir Zeit und ist im Allgemeinen weniger peinlich. :-)
:
Bearbeitet durch Moderator
S. R. schrieb: > Warum verlangt man dann nicht "ieee.std_logic_1164.std_logic_vector" als > Datentyp? Es ging mir darum, den (wie es scheint) häufigst verwendeten > Datentypen von 16 auf 3 Zeichen zusammenzukürzen. std_logic kommt sicherlich häufiger vor als std_logic_vector. Aber bei beiden Datentypen gibt es auch noch die beiden Ausprägungen std_logic/std_ulogic bzw. std_logic_vector/std_ulogic_vector. Für die meisten Zwecke wären sicherlich die unresolved-Varianten sinnvoller, da weniger fehlerträchtig. Nur auf Grund von Tippfaulheit oder Vergesslichkeit beim Tippen gibt es überhaupt so viele std_logic/std_logic/vector. Daher hätte man bei der Definition der Bibliotheken lieber std_logic für den "normalen" unresolved-Typ und für die "speziellen" resolved-Typ z.B. std_rlogic/std_rlogic_vector einführen sollen.
:
Bearbeitet durch User
S. R. schrieb: > Allein der Aufwand, den ganzen Mist für eine Testbench (besser: mehrere > Testbenches) nochmal zusammenbasteln zu müssen, ist mir zuwider. In der > Zeit kann ich 100 Bitstreams erzeugen und testen ("genug für das > Projekt", und perfekt muss es auch nicht sein). Kannst ja auch, falls möglich Notepad++ mit dem VHDL Plugin benutzen. Ich nehme das täglich in Zusammenhang mit Vivado und da geht vieles ziemlich einfach, Instanziierung, Testbench...kann man sich automatisch erzeugen lassen. Dazu hab ich noch NPPExec und kann per Knopfdruck das aktuelle File durch den Modelsim Kompiler jagen, samt Error parsing im Output mit Sprung zur Zeilennummer usw. Einmal eingerichtet erspart das Stunden an Arbeit.
Andreas S. schrieb: > Für die meisten Zwecke wären sicherlich die unresolved-Varianten > sinnvoller, da weniger fehlerträchtig. Das Totschlagargument für die Verwendung der nicht aufgelösten Typen war früher(tm), dass die Simulation dann keine Auflösungstabelle zu durchlaufen hatte. Man konnte deshalb Simulationszeit sparen. Dieses Argument zählt heute nicht mehr, die Simulatorhersteller haben das inzwischen optimiert. S. R. schrieb: > (b) Mir gefällt aber insbesondere die kurze Verilog-Testbench... > nur müsste man dazu eben Verilog können. ;-) Naja, das ist ein Stimuligenerator. Für eine echte Testbench müssten da schon noch ein paar Abfragen und Testvektoren rein. Eine funktionsgleicher VHDL-Stimuligenerator für die Stoppuhr ist übrigens auch nicht länger:
1 | LIBRARY ieee; |
2 | USE ieee.std_logic_1164.ALL; |
3 | |
4 | ENTITY tb_stopwatch IS |
5 | END tb_stopwatch; |
6 | |
7 | ARCHITECTURE behavior OF tb_stopwatch IS |
8 | signal clock : std_logic := '0'; |
9 | signal reset : std_logic := '1'; |
10 | signal start : std_logic := '0'; |
11 | signal segments : std_logic_vector(6 downto 0); |
12 | signal dp : std_logic; |
13 | signal an : std_logic_vector(3 downto 0); |
14 | BEGIN
|
15 | uut: entity work.stopwatch PORT MAP ( |
16 | clock => clock, |
17 | reset => reset, |
18 | start => start, |
19 | segments => segments, |
20 | dp => dp, |
21 | an => an |
22 | );
|
23 | |
24 | clock <= not clock after 100 ns; |
25 | |
26 | stim_proc: process |
27 | begin
|
28 | wait for 100 ns; |
29 | reset <= '0'; |
30 | wait for 100 ns; |
31 | reset <= '1'; |
32 | wait for 100 ns; |
33 | reset <= '0'; |
34 | wait for 100 ns; |
35 | start <= '1'; |
36 | wait; |
37 | end process; |
38 | END; |
BTW: in der Verilog-Beschreibung der Uhr ist noch der beliebte n+1 Fehler drin. Der Teiler zählt nicht 5000000 Schritte, sondern 5000001 und ist damit um 0,2ppm zu langsam... ;-)
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Andreas S. schrieb: >> Für die meisten Zwecke wären sicherlich die unresolved-Varianten >> sinnvoller, da weniger fehlerträchtig. > Das Totschlagargument für die Verwendung der nicht aufgelösten Typen war > früher(tm), dass die Simulation dann keine Auflösungstabelle zu > durchlaufen hatte. Man konnte deshalb Simulationszeit sparen. Dieses > Argument zählt heute nicht mehr, die Simulatorhersteller haben das > inzwischen optimiert. Was haben die denn bitte optimiert? Dort keinen Fehler zu werfen ist doch mMn schlicht falsch.
bzw. meinst du was anderes? Für mich ist das Argument, die vom Vorposter größere Fehlersicherheit gegen Multiple Driver.
Tim schrieb: > Was haben die denn bitte optimiert? Die Zeit, die zum Durchrechnen der Auflösungstabelle gebraucht wird. > Dort keinen Fehler zu werfen ist doch mMn schlicht falsch. Warum? Buskollisionen werden da durchaus entsprechend der Regeln aufgelöst und angezeigt. Eine '1' und eine '0' auf dem Bus ergibt ein 'X'. Mit einem std_ulogic könntest du nicht mal einen Tristate-Port beschreiben, denn wenn ein Treiber 'Z' auf den Bus legt und einer '0', dann ist das eine Kollision und die Simulation wird abgebrochen... > Für mich ist das Argument, die vom Vorposter größere Fehlersicherheit > gegen Multiple Driver. Das haut dir der Synthesizer sowieso um die Ohren...
:
Bearbeitet durch Moderator
Moin, > > Strubi schrieb: >> Wenn man sich an das Copy-Paste-Engineering gewöhnt hat, und seinen >> VHDL-Code wie sauberes ADA formatiert, ist das deutlich lesbarer als >> Verilog, aber das ist mal wieder eine redundante Meinungskundtuung :-) > > Och, mit genügend Aufwand kann man so ziemlich jede Sprache extrem gut > lesbar / verständlich formatieren (Basic mal ausgenommen), insofern > glaube ich mal, dass das auch mit Verilog ginge. > Ich sag's mal so: Es gibt Leute, die behaupten, dass Perl nie gut lesbar sein wird...:-) (Stichwort unklare Sonderzeichen wie in Verilog: `) > Mich stört halt schlicht das Copy-Paste-Engineering. Einmal das Gefühl, > nicht voranzukommen (ich tippe oft neu statt zu kopieren, weil es mir > dann besser im Hirn hängenbleibt und ich den Überblick nicht verliere), > zum anderen ist es bei Softwaredesign extrem schlechter Stil. Mit Copy/Paste meine ich eigentlich, so redundante Gschichten wie
1 | process(clk) |
2 | begin |
3 | end process |
einfach im vi (z.B:) per YP-Tastendruck schnell zu duplizieren. > > VHDL fühlt sich für mich an wie Assembler. Kann ich einigermaßen lesen > und sicherlich auch schreiben, will ich aber nicht. Das ist so viel > unnütze Arbeit, die ich einem Tool überlassen kann und dafür auch gerne > bereit bin, 10% Leistung abzudrücken. Ich finde das voll legitim, die Syntaxregeln nicht 100% auswendig zu kennen und den Rest dem Editor zu überlassen. Es gibt da auch nette Erweiterungen für Emacs, scheint verbreitet in manchen Hochschulen. Mit welchem Editor man am produktivsten ist, muss sich jeder halt selber drauf einschwingen (und bloss hier nicht diskutieren). > > Allein der Aufwand, den ganzen Mist für eine Testbench (besser: mehrere > Testbenches) nochmal zusammenbasteln zu müssen, ist mir zuwider. In der > Zeit kann ich 100 Bitstreams erzeugen und testen ("genug für das > Projekt", und perfekt muss es auch nicht sein). > Ich denke, man durchläuft typischerweise diese Phasen: a) Viel Zeit mit Syntax-Errors verbraten b) Wohlfühl-Coding c) Produktive Entwicklung (a) kann man ev. mit andern Ansätzen überspringen. Aber gerade wenn man von der Seite der eher ungeduldigen SW-Entwickler kommt (und auch Luxus gewöhnt ist), sollte man in den sauren Apfel beissen und eher (b) auslassen. Was MyHDL angeht, ist es genau beim Testbenching sehr stark. In VHDL eine vollständige Coverage für z.B. ein CPU-Design hinzukriegen, ist eine echte Pein, da greift man besser zur Co-Simulation (Testbench in C/Python entwerfen). > Wobei wir - akademisches Umfeld - dann wieder zu irgendwelchem > akademischen Zeug gezwungen sind, z.B. Chisel (basiert auf Scala und ist > mir allein deswegen eher unsympathisch - Link: > https://chisel.eecs.berkeley.edu/). Seufz. Hab ich mir mal angesehen. Sehe ich eher als ein schwerfälliges Konstrukt, wo sich mal wieder ein paar Leute mit "me too" richtig ausgetobt haben. Fürs Lernen: ok. Industrie: Njet. > >> Nachteil ist bei MyHDL, dass die gesamte Architektur in der Ausgabe >> flach ausgerollt wird und die Modularisierung im Zusammenspiel mit >> existierender V*-HDL etwas Handarbeit benötigt. > > Muss man bei MyHDL das Ergebnis noch nachbearbeiten oder funktioniert > das eher "einfach so"? Kann man da VHDL-/Verilog-Blöcke einfach > einbinden? > Nachbearbeiten ist für mich "no go". Es funktioniert erstaunlicherweise "einfach so", wenn man auf Python-Layer korrekt codet. Ist wie in VHDL: wo dort manche Konstrukte nicht synthetisieren, gibt es in MyHDL Dinge, die nicht in VHDL übersetzen. Ist eben pures Python. Wer also munter loslegt, ohne mal nach VHDL testzuübersetzen, hat erst mal nur eine funktionale Simulation und noch nix synthetisierbares. Blöcke einbinden geht gut, es lässt sich auch ein VHDL/Verilog-Snippet 1:1 inline in die Ausgabe einfügen. Per _vhdl_ = '''<code''' kann man sich dann Wrapper-Entities basteln, die beim "Elaborieren" der Simulation (ich weiss nicht, wie man das am besten übersetzen würde...Lothar?) per Konfiguration die HDL für die entsprechende Architektur ausspucken. Anfangs kosten diese Test-Transfers etwas Zeit, und ein Bug trat schon mal auf (in einer kniffligen Arithmetik-Sache). Die ganze Sache hat sich aber schon nach wenigen Monaten amortisiert, in VHDL wäre das eine kaum zu unterhaltende Nummer geworden. > > Ich ziehe mal für mich die Schlussfolgerung, dass es die Silberkugel > nicht gibt und man wenigstens eine Kröte schlucken muss. Der Thread darf > gerne weiter abdriften, so lerne ich mehr. Insbesondere aus Fehlern > anderer, denn das spart mir Zeit und ist im Allgemeinen weniger > peinlich. :-) Kröten schlucken: Immer! Mein Fazit ist, dass man, wenn man den Wohlfühlaspekt über Bord wirft, mit den genannten Tools echt produktiv sein kann und kleine detaillierte Sprachaspekte irrelevant gegenüber Robustheit und entsprechend geforderten Testbenches sind. Könnte man auch sagen: Man muss an der Kröte nur noch lecken :-) Salute, - Strubi
Lothar M. schrieb: >> Dort keinen Fehler zu werfen ist doch mMn schlicht falsch. > Warum? Buskollisionen werden da durchaus entsprechend der Regeln > aufgelöst und angezeigt. Eine '1' und eine '0' auf dem Bus ergibt ein > 'X'. In größeren Designs propagiert das öfters erst ein Weilchen durchs System und schlägt dann in irgendeiner kruden Assertion oder in der Testbench aus. Diese Sucherei kann man sich mit ulogic echt sparen. Lothar M. schrieb: > Mit einem std_ulogic könntest du nicht mal einen Tristate-Port > beschreiben, denn wenn ein Treiber 'Z' auf den Bus legt und einer '0', > dann ist das eine Kollision und die Simulation wird abgebrochen... Dafür nimmt man einfach wieder logic. Lothar M. schrieb: >> Für mich ist das Argument, die vom Vorposter größere Fehlersicherheit >> gegen Multiple Driver. > Das haut dir der Synthesizer sowieso um die Ohren... Stimmt, der Schritt ist jedoch spät, wenn man sich erst mal intensiv mit der Testbench beschäftigt. Es wird wohl Ansichtssache sein, ob man diese feine Unterscheidung noch mitnehmen möchte. Überflüssig ist es nicht.
Ich fürchte, ich habe nichts sinnvolles mehr beizutragen. Daher bedanke ich mich an dieser Stelle einfach mal für die netten und hilfreichen Kommentare. Ein besonderer Dank geht an Lothar und Strubi. War ziemlich augenöffnend. Schöne Grüße, svenska
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.