ENTITY und COMPONENT in VHDL

[S. R. (svenska)]

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

[Bernhard R. (bernhard_r28)]

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

[VHDL hotline (Gast)]

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.

[VHDL hotline (Gast)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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"

[René D. (Firma: www.dossmatik.de) (dose)]

> 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.

[Bernhard R. (bernhard_r28)]

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. :-/

[S. R. (svenska)]

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... ;-)

[Bernhard R. (bernhard_r28)]

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...! :-)

[Tim (Gast)]

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

[Alabama J. (alabamajack)]

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...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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...

[Strubi (Gast)]

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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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)" ... ;-)

[S. R. (svenska)]

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. :-)

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Christian R. (supachris)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
 
ENTITY tb_stopwatch IS
END tb_stopwatch;
 
ARCHITECTURE behavior OF tb_stopwatch IS 
   signal clock : std_logic := '0';
   signal reset : std_logic := '1';
   signal start : std_logic := '0';
   signal segments : std_logic_vector(6 downto 0);
   signal dp : std_logic;
   signal an : std_logic_vector(3 downto 0);
BEGIN
   uut: entity work.stopwatch PORT MAP (
          clock => clock,
          reset => reset,
          start => start,
          segments => segments,
          dp => dp,
          an => an
        );

   clock <= not clock after 100 ns;
 
   stim_proc: process
   begin    
      wait for 100 ns;  
      reset <= '0';
      wait for 100 ns;  
      reset <= '1';
      wait for 100 ns;  
      reset <= '0';
      wait for 100 ns;  
      start <= '1';
      wait;
   end process;
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... ;-)

[Tim (Gast)]

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.

[Tim (Gast)]

bzw. meinst du was anderes? Für mich ist das Argument, die vom Vorposter 
größere Fehlersicherheit gegen Multiple Driver.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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...

[Strubi (Gast)]

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

process(clk)
begin
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

[Tim (Gast)]

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.

[S. R. (svenska)]

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