Alternativen zu VHDL und Verilog

[S. R. (svenska)]

Hi,

in den letzten Monaten habe ich mich in VHDL eingearbeitet und auch ein 
Setup für den bei uns verwendeten FPGA (Xilinx Zynq) gebastelt. Langsam 
geht es auf reale Anforderungen zu und meine Abneigung zu VHDL wächst 
beständig.

Einfache Sachen sind unglaubliche Tipperei, mal "eben schnell 3 
Instanzen erzeugen und verdrahten" dauert ewig und ständig überall die 
Interfaces neu beschreiben zu müssen geht mir auch auf die Nerven. 
(Vivado mag die verkürzte Instanziierung bei mir nur manchmal, keine 
Ahnung warum.)

Ich vermute mal, dass Verilog auch nicht viel besser ist als VHDL und 
wüsste gerne, ob es noch andere Sprachen gibt, mit denen man gut 
arbeiten kann.

Auf dem 33c3 wurde SpinalHDL vorgestellt 
(https://media.ccc.de/v/33c3-7873-spinalhdl_an_alternative_hardware_description_language) 
und aus der RISC-V-Ecke kommt CHISEL, beide setzen auf Scala auf. Dann 
läuft einem öfter das python-basierte MyHDL über den Weg. Ich kann weder 
Python noch Scala, müsste das also auch erst lernen. Bei allen diesen 
Sprachen fällt am Ende ohnehin VHDL oder Verilog hinten bei raus, also 
sollte es keine Probleme geben, existierende Module anzubinden.

Daher die Frage an Euch: Hat jemand mit diesen Sprachen schon gearbeitet 
und für gut befunden? Oder gibt es sogar eine ganz andere Sprache, die 
was taugt? Wie sieht es mit Testbenches aus, geht das bequem?

Gruß,
Svenska

[C. A. Rotwang (Gast)]

S. R. schrieb:

> Einfache Sachen sind unglaubliche Tipperei, mal "eben schnell 3
> Instanzen erzeugen und verdrahten" dauert ewig und ständig überall die
> Interfaces neu beschreiben zu müssen geht mir auch auf die Nerven.

Nimm einen Editor der was taugt bspw Emacs im VHDL-mode. Der generiert 
Instance templates und components aus der Entity ohne extra tipperei:
https://guest.iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.gif
http://www.geocities.ws/purnank/vhdlemacst.html
http://electronics.stackexchange.com/questions/220098/vhdl-is-there-a-tool-that-automatically-generates-the-signals-for-use-in-testb

[VHDL hotline (Gast)]

S. R. schrieb:
> ständig überall die Interfaces neu beschreiben zu müssen

Meinst du die component declaration? Dafür gibt es in VHDL packages, das 
ist analog zu .h Dateien in C.

[S. R. (svenska)]

Ich wollte jetzt weniger Tipps zu VHDL, als vielmehr Erfahrungen mit 
anderen Sprachen jenseits von VHDL und Verilog. ;-)

[C. A. Rotwang (Gast)]

S. R. schrieb:
> Ich wollte jetzt weniger Tipps zu VHDL, als vielmehr Erfahrungen mit
> anderen Sprachen jenseits von VHDL und Verilog. ;-)

VHDL ist super, wer damit nicht zurechtkommt weil es ihm zuviel Getippe 
ist der scheitert auch an den Alternativen.

[S. R. (svenska)]

Ich danke kopfschüttelnd für diese Nichtinformation.

[daniel__m (Gast)]

S. R. schrieb:
> Bei allen diesen
> Sprachen fällt am Ende ohnehin VHDL oder Verilog hinten bei raus, also
> sollte es keine Probleme geben, existierende Module anzubinden.

So ist auch mein Wissen, daher sollte man HDL nicht meiden, sondern 
versuchen, geeignete Entwicklungsumgebungen zu finden und zusätzlich die 
Sprache (z.b. VHDL) großzügig bzw. ausgiebig zu verwenden. Es gibt viele 
Dinge, die einem das Leben deutlich angenehmer machen können.

Als Umgebung findet ich Sigasi nicht verkehrt. Das übernimmt sehr viel 
Tipparbeit. Ist dann ähnlich komfortabel wie Eclipse für Java oder c/c++ 
und die Bedienung ist ähnlich.

Bei Xilinx gibt es noch SDSoC (habe ich noch nicht genutzt) und HLS. 
Beide helfen, die Aufgaben zu abstrahieren, indem programmtechnisch 
rangegangen wird. Das hat aber auch schnell Grenzen bzw. artet schnell 
aus. Hardware ist halt kein Programm.

In Vivado kann man dann alle Einzelteile (Verilog, VHDL, HLS, etc) als 
Blöcke grafisch verknüpfen. Da muss man dann mal experimentieren oder 
evtl. einen Kurs besuchen (mir fällt z.b. PLC2 ein). Das geht i.d.R. 
schneller.

grüße

[Marcel O. (rbecode)]

es gibt sogar ein pseudo VHDL was in python gebaut wird : myVHDL

[S. R. (svenska)]

daniel__m schrieb:
> So ist auch mein Wissen, daher sollte man HDL nicht meiden, sondern
> versuchen, geeignete Entwicklungsumgebungen zu finden und zusätzlich die
> Sprache (z.b. VHDL) großzügig bzw. ausgiebig zu verwenden.

In einem anderen Kontext heißt das, da bei jedem Hochsprachencompiler 
ein Assemblerprogramm hinten bei rausfällt, sollte man Assembler nicht 
meiden, sondern geeignete Entwicklungsumgebungen finden und zusätzlich 
die Sprache (d.h. Assembler) großzügig bzw. ausgiebig verwenden.

Es gibt einige Gründe, warum ich C einem beliebigen Assembler vorziehe. 
Da hilft auch keine tolle Entwicklungsumgebung mit 200 Features und 
AutoTipp, um die Schmerzen zu verstecken...

Und nein, HLS interessiert mich tatsächlich nicht.

[Georg (Gast)]

Hey,

ich habe mal ein kleines Praktikum mit SystemC gemacht: 
https://de.wikipedia.org/wiki/SystemC

War dann ähnlich wie C++ für einen AVR :)

[Nase (Gast)]

Wenn es um Verifikation geht: Nimm, was dir gefällt und was dein 
Simulator versteht, meistens fällt hinten ja doch RTL oder VHDL raus.

Wenn es um Synthese geht, bleib bei VHDL. Hardware-Design ist halt 
anders als Programmierung und das wird auch nicht besser, wenn man es 
als Programmierung zu tarnen versucht.
Wenn du unbedingt Schleifen und Kontrollstrukturen wie in einer 
Programmiersprache brauchst, ja mei, dann nimm halt einen Prozessor und 
kein FPGA.

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

S. R. schrieb:
> Erfahrungen mit anderen Sprachen jenseits von VHDL und Verilog. ;-)
Englisch ist einfach. Spanisch recht orthogonal...

S. R. schrieb:
> Langsam geht es auf reale Anforderungen zu und meine Abneigung zu VHDL
> wächst beständig.
Warum?
Wächst deine Abneigung gegen die HDL oder eher gegen 
Hardwarebeschreibung allgemein?

[Christian R. (supachris)]

Der Vergleich mit dem Assembler hinkt ordentlich, denn VHDL oder Verilog 
sind schon Hochspachen. Du kannst ja auch eine EDIF Netzliste selber 
schreiben, bzw.  auf Gatter Ebene Schaltungen malen.
Ich hab da auch lange gesucht, weil mir die Geschwätzigkeit von VHDL auf 
den Senkel geht, aber alles andere ist irgendwie Bastelkram oder 
akademischer  Schnickschnack. Nach ein, zwei Jahren kann man VHDL mit 
den meisten Fallstricken so sicher dass man zügig arbeiten kann.
Ich nutze übrigens Notepad++ mit dem VHDL Plugin, das spart viel 
Tipparbeit. Auch hab ich da in NPPExec gleich den Modelsim rein gehängt, 
um Fehler schnell zu finden. Packages helfen auch ungemein, die 
Übersicht zu behalten.

[Nase (Gast)]

Christian R. schrieb:
> die Geschwätzigkeit von VHDL
Die ist eigentlich garnicht so verkehrt.

Hardware-Design ist halt nicht Programmieren. Wenn ich mit VHDL arbeite, 
stelle ich mir immer vor, wie ich TTL-Bausteinchen in eine Schaltung 
integrierer. Der Vergleich ist nämlich garnicht so abwegig, wenn man den 
Ursprung von VHDL zurückverfolgt. Und um eine Schaltung aus 
TTL-Bausteinen zusammenzusetzen, muss man halt jeden Baustein 
durchdenken und bewusst einbauen.

Genauso sollte man eigentlich auch in VHDL sich immer ganz bewusst 
darüber sein, was man mit seinem Geschreibsel eigentlich auslöst. So von 
wegen Schleifen etc.

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

S. R. schrieb:
> ob es noch andere Sprachen gibt, mit denen man gut arbeiten kann.
Alle Jahre wieder, wie im Beitrag "VHDL Nachfolger"

Christian R. schrieb:
> Ich hab da auch lange gesucht, weil mir die Geschwätzigkeit von VHDL auf
> den Senkel geht
Mich stört die Geschwätzigkeit von C auch unheimlich... ;-)
Aus dem obigen Link dazu den Auszug dort:
http://www.lothar-miller.de/s9y/archives/88-VHDL-vs.-Verilog-am-Beispiel-einer-Stoppuhr.html

[C. A. Rotwang (Gast)]

S. R. schrieb:
> Ich danke kopfschüttelnd für diese Nichtinformation.

Dann schüttele mal weiter Deinen Kopf, vielleicht fällt ja der Groschen.

Ehrlich, ich kenne genug Code von tippfaulen, kaum Kommentare, keine 
identifier länger als 6 zeichen, testbench stimuli endet mit 
Takt-erzeugung und reset-release - die reinste Zumutung im Team.

Also wer Probleme mit dem Schreiben hat sollt nicht den Beruf eines 
Schriftstellers ergreifen. Und wer wegen Tipperei beim VHDL-Lernen 
aufgibt der sollte lieber ein Fach mit viel Laberei im Beruf studieren 
(Lehrer/Marketing).

Du kannst dich ja an den alten FPGA-sprachen versuchen, die wegen 
technischer unzulänglichkeiten meist knapp im Code waren wie ABEL oder 
AHDL.

https://de.wikipedia.org/wiki/Advanced_Boolean_Equation_Language
https://en.wikipedia.org/wiki/Altera_Hardware_Description_Language

Das Problem mit diesen: propietär und werden heute kaum noch 
unterstützt.


Oder du versuchst Dich am schematic entry - das haben viele versucht die 
die Mühen von VHDl scheuten - ist aber auch propitär und meist nicht 
kostenlos. Das gängigstes Tool ist der HDL-Designer von Mentor Graphics: 
http://s3.mentor.com/public_documents/datasheet/products/fpga/hdl_design/hdl_designer_series/hds_datasheet.pdf

State machine malen, Blockbilder malen, ... kann man als graphische 
Programmiersprache bezeichnen verbietet sich aber allein aus 
Kostengründen für Hobbyisten. Und wenn wir schon bei FPGA-Programmierung 
für Schreibbehinderte sind, schau dir Labview für FPGA an 
http://www.ni.com/labview/fpga/d/ auch sündhaft teuer. Das große Problem 
dieser graphischen tools ist aber m.E. die mangelnede Sichtbarkeit von 
Versionsunterschieden. Bei Texttools genügt ein diff und die Änderungen 
zu sehen.

Zusammengefasst:
1) Es gibt keine praktische Alternative zu VHDL/Verilog. Vielleicht wenn 
man ein paar 10k Euro für Lizenzen/Schulung ausgeben will.
2) Der Grund "Zuviel Tipperei - ich will eine Sprache für Tippfaule" ist 
der dämlichste Grund eine Programmiersprache zu wechseln. Besorg dir 
eine vernünftige Tastatur, brauchbaren Editor und mach einen 
Mehrfinger-Schreibmaschinenkurs.

[Guest (Gast)]

Ich mache mal einen ernst gemeinten Vorschlag:
Lern neo ( https://www.neo-layout.org/ )

[C. A. Rotwang (Gast)]

Guest schrieb:
> Ich mache mal einen ernst gemeinten Vorschlag:
> Lern neo ( https://www.neo-layout.org/ )

Für VHDL/Verilog wäre aber eine auf die englische statt auf die deutsche 
Sprache optimierte Tastatur besser.

[Markus F. (mfro)]

... und weil das beste Layout nix taugt, weil das im Adler-Suchsystem 
nix schneller macht (ich bin regelmäßig verblüfft, wieviele IT-ler - 
zumindest in meiner Umgebung - tatsächlich nur mit zwei Fingern tippen 
können: gefühlt so gut wie alle): 10-Finger schreiben lernen!

[Strubi (Gast)]

Hi,

ich sag mal so: MyHDL ist das einzige Tool, das sich bei mir als 
wirklich produktiv herausgestellt hat. Es gibt noch andere 
Python-Alternativen wie migen, aber MyHDL ist der beste Mittelweg 
zwischen 'progressiv', Standard, und gut erweiterbar.
Was Testbenches angeht, ist MyHDL extrem stark, aber das wurde hier 
schon öfters in anderen Threads erläutert.
Die andern akademischen Ansätze kranken meist daran, dass sie einfach 
nur "anders" sein wollen oder das Rad neu erfinden, aber nur bis zu 
einem gewissen unproduktiven Punkt.
Ich würde mich mal einfach einen Nachmittag hinsetzen und ein einfaches 
Design in MyHDL nachbauen, auf dem HDL-Level, den man bisher kennt.
Sobald es komplexer wird, kann man sich auf die geilen Sachen stürzen, 
wie eigene HLS, CPU-Designs, usw. ohne an der Komplexität zu ersticken.
Nett ist auch cocotb, aber überhaupt alles, was man aus dem 
Python-Ökosystem für Verifikation nutzen kann.

[Michael B. (laberkopp)]

S. R. schrieb:
> Ich vermute mal, dass Verilog auch nicht viel besser ist als VHDL

Doch, natürluich, schliesslich werden die meisten Chips in Verilog 
definiert.

> wüsste gerne, ob es noch andere Sprachen gibt, mit denen man gut
> arbeiten kann.

Kaum, weil
1. für deinen Chip diese Sprache auch verfügbar sien müsste (nd manche 
wollen noch eine kostenlose Umgebung)
2. der Compiler/Fitter auch ausreichend getestet sein sollte
3. es auch fertige IP Module in der Sprache geben sollte damit man nicht 
alle Arbeit von 0 an beginnen müsste.

Ausser SystemC, welches aber auch schon Exot ist, werden die anderen 
Exoten noch schlimmer sein.

[Yalu X. (yalu) (Moderator)]

Michael B. schrieb:
>> wüsste gerne, ob es noch andere Sprachen gibt, mit denen man gut
>> arbeiten kann.
>
> Kaum, weil
> 1. für deinen Chip diese Sprache auch verfügbar sien müsste

Ich glaube, da hast du wieder einmal etwas überhaupt nicht verstanden :)

[Yalu X. (yalu) (Moderator)]

S. R. schrieb:
> Ich vermute mal, dass Verilog auch nicht viel besser ist als VHDL und
> wüsste gerne, ob es noch andere Sprachen gibt, mit denen man gut
> arbeiten kann.

Verilog ist nicht besser oder schlechter, sondern einfach etwas anders
als VHDL. Manche schwören auf VHDL, andere auf Verilog, letzendlich ist
das eine Frage des persönlichen Geschmacks und der eigenen Arbeitsweise.

Deswegen solltest du diesbezüglich keine Vermutungen anstellen, sondern
Verilog selber ausprobieren, um zu sehen, ob des deinen persönlichen
Vorlieben besser als VHDL entspricht.

Achte beim Vergleich aber darauf, dass du die Features der jeweils
neuesten Versionen berücksichtigst (IEEE 1364-2005 bei Verilog und IEEE
1076-2008 bei VHDL). Vieles, was in den jeweiligen Urversionen noch
nervig war oder gefehlt hat, ist mittlerweile korrigiert, verbessert
bzw. hinzugefügt worden.

> Auf dem 33c3 wurde SpinalHDL vorgestellt
> 
(https://media.ccc.de/v/33c3-7873-spinalhdl_an_alternative_hardware_description_language)
> und aus der RISC-V-Ecke kommt CHISEL, beide setzen auf Scala auf. Dann
> läuft einem öfter das python-basierte MyHDL über den Weg. Ich kann weder
> Python noch Scala, müsste das also auch erst lernen.

Vielleicht habe ich ja deine Aussage falsch verstanden, aber eine neue
Sprache musst du doch sowieso lernen, wenn du eine neue Sprache lernen
willst, und das willst du doch, oder?

Wenn du eine HDL lernst, die wie die genannten in eine gewöhnliche
Programmiersprache (in diesem Fall Scala oder Python) eingebettet ist,
hat das immerhin den Vorteil, dass du mit wenig Zusatzaufwand dieselbe
Sprache auch für klassische Programmieraufgaben verwenden kannst.

Der Nachteil bei eingebetteten DSLs besteht allerdings darin, dass sie
syntaktischen und semantischen Restriktionen von Seiten der Wirtssprache
unterliegen. Bei Stand-Alone-Sprachen wie VHDL und Verilog ist dies
nicht der Fall, weswegen sie – zumindest syntaktisch – evtl. besser auf
den konkreten Anwedungsfall (das Hardwaredesign) zugeschnitten sind.

> Daher die Frage an Euch: Hat jemand mit diesen Sprachen schon gearbeitet
> und für gut befunden?

Die Nutzerschaft dieser Sprachen (insbesondere Chisel und SpinalHDL)
dürfte verschwindend gering sein. Noch geringer ist die Zahl der Nutzer,
die deutsch sprechen und auf dieses Forum und hier drinnen auf deinen
Thread stoßen. Über Suchmaschinen findest du entsprechende Informationen
eher, aber auch dort ist die Ausbeute äußerst mager, wie ich gerade
festgestellt habe.

Solche neuen – und deswegen i.Allg. noch unreifen – Entwicklungen leben
davon, dass Interessierte sie aufgreifen, in unkritischen Bereichen
(bspw. Hobby oder Hochschule) testen und ggf. Verbesserungsvorschläge an
die Entwickler weitergeben.

Was spricht dagegen, sich die Tools einfach mal herunterzuladen und die
erste paar Abschnitte der Tutorials durchzuarbeiten? Wenn dir das Ganze
nicht taugt, wirst du das wahrscheinlich sehr schnell merken. Falls du
hingegen gleich zu Beginn schon mehrere Aha-Effekte erfährst, lohnt es
sich sicher, auch etwas mehr Zeit hinein zu investieren.

> Oder gibt es sogar eine ganz andere Sprache, die was taugt?

Es gibt noch eine ganze Reihe davon:

  https://en.wikipedia.org/wiki/Hardware_description_language#HDLs_for_digital_circuit_design

Aber für praktisch jede von ihnen trifft eine der folgenden Aussagen zu:

- Sie zielt auf HLS ab (wonach du, wenn ich dich richtig verstanden
  habe, nicht suchst).

- Sie ist veraltet und ausrangiert.

- Sie ist noch nicht nicht einmal ansatzweise etabliert (für sie gilt im
  Wesentlichen das, was ich oben zu Chisel und SpinalHDL geschrieben
  habe).

- Sie heißt Verilog oder VHDL.

Noch etwas:

Falls du vorhast, dich beruflich mit der Materie zu beschäftigen, kommst
du um VHDL oder Verilog sowieso nicht herum (meist kannst du nicht
einmal zwischen diesen beiden auswählen, sondern musst dich nach den
Vorgaben des Arbeitgebers richten). Selbst wenn SpinalHDL (oder
irgendeine anderer der neueren Entwicklungen) tatsächlich der Weisheit
letzter Schluss sein sollte, wird es Jahrzehnte dauern, bis es sich
etabliert. Und selbst dann werden VHDL und Verilog noch lange nicht
aussterben. Man kennt dieses Phänomen schon lange bei klassischen
Programmiersprachen, deren Geschichte schon weiter zurückreicht als die
der HDLs.

Ich habe mich eine Zeitlang hobbymäßig mit FPGA-Design beschäftigt, die
Sache dann aber mangels (für mich sinnvoller) Anwendungen wieder ruhen
lassen. Deswegen habe ich natürlich auch bei Weitem nicht den Überblick
und die Erfahrung von Lothar.

Wäre ich noch etwas aktiver in dem Bereich tätig, würde es mich aber
schon reizen, einmal etwas Neues auszuprobieren. Meine Favoriten wären
dabei Lava und SpinalHDL (in dieser Reihenfolge). Die hören sich von
dem, was ich bisher an Beschreibungen gelesen und Beispielen gesehen
habe, am interessantesten an.

Das würde ich aber wohlbemerkt nicht tun, um daraus irgendeinen
monetären Nutzen zu ziehen (so realistisch muss man einfach sein),
sondern allein mit dem Ziel der Horizonterweiterung und des
Erkenntnisgewinns.


@svenska:

Also pack einfach an und saug dir SpinalHDL. Außer ein paar Stunden Zeit
kannst du nichts verlieren :)

[ui (Gast)]

Ich seh das ähnlich,

gerade die "viele" Schreibarbeit von vhdl hat schon einige Vorteile. 
Auch das Typsystem (wenn es auch manchmal beschissen lange casts 
erforderlich macht) hat Vorteile, vor allem in Hinblick auf den 
Einsatzzweck (in HW zu laufen, auch auf ASICs, bei denen man über jeden 
Zeile 3 mal nachdenken sollte).

Du gehst aber die Sache IMHO etwas falsch an, hast die falschen 
Erwartungen.
In HW löst man entweder sehr generische Dinge (Protokolle, CPUs, etc.) 
oder sehr spezielle Probleme, wo SW zu langsam ist. Die ganzen 
generischen Dinge programmiert man genau EIN mal und instanziert sie 
dann nur noch. Das kann jeder vernünftige Editor in VHDL ohne das man 
sich die Finger wundtippt. Für die Spezialsachen nimmt man entweder 
generierten Code und integriert denn noch oder schreibt ihn selbst, dann 
ist die Hauptarbeit aber auch der Hirnschmalz, sodass man locker 
nebenbei die 10k Zeilen tippen kann. Alles andere macht man in SW.

Warum einen Nachfolger für eine Sprache (VHDL) finden, die mit die 
schönsten Dinge kann.

Ich habe noch in keiner (so verbreiteten Sprache wie VHDL) sowas tolles 
wie eigenen Typen gesehen. Richtig generisch, einfache Typen. Keine 
Klassen, sonder Typen

type res is rane 0 to 10E8
 units
  ohm;
  kohm = 1000 ohm;
end units resistance;

Und es gibt noch viele andere tolle Dinge in VHDL. Man muss sie halt nur 
nutzen und sich mit der Sprache richtig auseinandersetzen.
Auch der hierachische Ansatz ist (aus meiner Sicht, eher embedded als 
viel vhdl) sehr schön und gut definiert. Die Schnittstellen sind klar 
und schön.

[S. R. (svenska)]

Nase schrieb:
> Wenn du unbedingt Schleifen und Kontrollstrukturen wie in einer
> Programmiersprache brauchst, ja mei, dann nimm halt einen Prozessor und
> kein FPGA.

Es geht mir nicht um Schleifen und Kontrollstrukturen, und mir ist auch 
bewusst, dass Hardwaredesign keine Programmierung ist. Ich will auch 
nicht zu HLS wechseln, was andernfalls auch eine Möglichkeit wäre.

Lothar M. schrieb:
> Wächst deine Abneigung gegen die HDL oder eher gegen
> Hardwarebeschreibung allgemein?

Ersteres. Hardwarebeschreibung an sich macht Spaß.

Mich stört halt, dass der Boilerplate (für einfachere Sachen) teilweise 
doppelt so lang ist wie die eigentliche Hardwarebeschreibung und dass 
man viele Bedingungen mehrfach hinschreiben muss.

Christian R. schrieb:
> Ich hab da auch lange gesucht, weil mir die Geschwätzigkeit von VHDL auf
> den Senkel geht, aber alles andere ist irgendwie Bastelkram oder
> akademischer Schnickschnack.

Akademischer Schnickschnack wäre ja nicht schlimm, aber damit kann man 
nichts einigermaßen dauerhaftes produzieren. Nächstes Jahr kann der 
Compiler mit meinem Code nichts mehr anfangen, hat dafür aber drei neue 
halbfertige, aber publizierte Features.

Ich muss keine Projekte auf 20 Jahre auslegen und meine Ergebnisse 
müssen nichtmal verifiziert fehlerfrei sein. Andererseits ist mein 
Hauptarbeitsbereich eben auch nicht Hardwaredesign.

C. A. Rotwang schrieb:
>> Ich danke kopfschüttelnd für diese Nichtinformation.
> Dann schüttele mal weiter Deinen Kopf, vielleicht fällt ja der Groschen.

Wenn du der Meinung bist, ich sei schlicht zu doof zum Tippen, dann lass 
das Antworten doch einfach sein.

> Es gibt keine praktische Alternative zu VHDL/Verilog.
> Der Grund "Zuviel Tipperei - ich will eine Sprache für Tippfaule" ist
> der dämlichste Grund eine Programmiersprache zu wechseln.

Wenn ich etwas implementieren möchte, was ich auf Papier hinreichend 
skizziert habe (und dort nicht wirklich viel ist), dann möchte ich das 
nicht ewig beschreiben müssen - und vor allem möchte ich mich nicht 
ständig wiederholen. Bussysteme beschreiben macht z.B. deswegen keinen 
Spaß.

Kommas und Semikolons sind auch hinreichend inkonsistent (im 
Boilerplate), um nach ein paar Monaten hinreichend nervig zu bleiben. 
Generics können manche Dinge einfach aus Prinzip nicht (z.B. das 
konstante Ergebnis einer Funktion als Größe eines Vektors im Interface 
verwenden). Und Google weist einen dann auf übliche Workarounds hin, und 
wenn man mal in (offenen) Xilinx-Code schaut, findet man die dort auch. 
Nur ist der Code da noch grauslicher als das, was man selbst so 
verzapft.

Dann ist Vivado selbst ein Quell unendlicher Freude (schön, dass er nach 
3 Minuten auch feststellt, dass ich eine Datei vergessen habe zu 
ändern).

Michael B. schrieb:
>> Ich vermute mal, dass Verilog auch nicht viel besser ist als VHDL
> Doch, natürluich, schliesslich werden die meisten Chips in Verilog
> definiert.

Das scheint nach Aussagen Vieler weniger eine Eigenschaft der Sprachen, 
sondern der Geographie zu sein. Europa ist VHDL-Land, der Rest der Welt 
nimmt wohl eher Verilog.

Strubi schrieb:
> MyHDL ist das einzige Tool, das sich bei mir als
> wirklich produktiv herausgestellt hat. [...]
> Was Testbenches angeht, ist MyHDL extrem stark, aber das wurde hier
> schon öfters in anderen Threads erläutert.

Dann arbeite ich mich da mal ein. Danke.

[S. R. (svenska)]

Yalu X. schrieb:
> Vielleicht habe ich ja deine Aussage falsch verstanden, aber eine neue
> Sprache musst du doch sowieso lernen, wenn du eine neue Sprache lernen
> willst, und das willst du doch, oder?

Ich würde aber gerne vorher wissen, ob das Pferd, auf das ich gerade 
aufsteige, schon tot ist. Nachdem ich mal einen Codegenerator für ein 
totes System bauen durfte, bin ich da etwas gebrannt. Die 
Projektwebseite war gepflegt, hat aber netterweise nicht auf den 
Nachfolger verwiesen und das Projekt kam vollständig in Rundablage P. 
Naja, wurde bezahlt, trotzdem doof.

Yalu X. schrieb:
> Wenn du eine HDL lernst, die wie die genannten in eine gewöhnliche
> Programmiersprache (in diesem Fall Scala oder Python) eingebettet ist,
> hat das immerhin den Vorteil, dass du mit wenig Zusatzaufwand dieselbe
> Sprache auch für klassische Programmieraufgaben verwenden kannst.

Hmm, davon bin ich jetzt nicht so überzeugt. Wenn ich innerhalb eines 
Sprachsubsets mit eigenem Ökosystem lebe, kriege ich von der 
eigentlichen Sprache fast nichts mit. Vielleicht ein bisschen Syntax, 
aber das ist an Programmiersprachen ohnehin der eher unwichtige Teil.

Yalu X. schrieb:
> Die Nutzerschaft dieser Sprachen (insbesondere Chisel und SpinalHDL)
> dürfte verschwindend gering sein. Noch geringer ist die Zahl der Nutzer,
> die deutsch sprechen und auf dieses Forum und hier drinnen auf deinen
> Thread stoßen.

Die Chancen, hier auf kompetente Personen und gute Antworten zu stoßen, 
sind aber deutlich höher. Auch in den typischen C-vs-Assembler- oder 
AVR-vs-ARM-Threads taucht gelegentlich Kompetenz auf. :-)

Hätte ja sein können, dass jemand (außer Strubi) sich damit mal tiefer 
befasst hat.

Aber danke trotzdem für die ausführliche Antwort!

[Yalu X. (yalu) (Moderator)]

S. R. schrieb:
> Die Chancen, hier auf kompetente Personen und gute Antworten zu stoßen,
> sind aber deutlich höher. Auch in den typischen C-vs-Assembler- oder
> AVR-vs-ARM-Threads taucht gelegentlich Kompetenz auf. :-)

Es gibt auch sehr viel mehr Leute, die in C oder Assembler programmieren
können, insbesondere auch recht viele, die beides können.

Versuch aber mal jemanden zu finden, der die beiden gängigsten HDLs,
nämlich VHDL und Verilog, beherrscht¹ und damit in der Lage wäre, dir
fundiert die Vor- und Nachteile jeder der beiden Sprachen zu erklären.
Du wirst um Größenordnungen mehr Leute finden, die nicht nur zwei,
sondern sogar drei oder noch mehr klassische Programmiersprachen
beherrschen. Deswegen haben es neue HDLs noch schwerer, sich zu
etablieren, als dies bei neue Programmiersprachen der Fall ist.

——————————
¹) Mit "beherrscht" meine ich dabei mehr als nur ein Tutorial
   durchgearbeitet zu haben.

[Weltbester FPGA-Pongo (Gast)]

Ich finde es lustig, dass jemand, der gerade mal ein paar HDL-Zeilen 
formuliert hat, fordert, eine neue Programmiersprache zu definieren.

HDL hat alles was man braucht, um HW zu definieren, auch Verilog ist 
nicht wirklich sparsamer und eine neue wäre es sicher auch nicht.

Wer es nicht so textuell braucht, der nimmt Block Designs.

Wer mehr Text auf höherer Ebene will, nimmt System-Verilog /-C oder 
Python.

Alles da.

[VHDL hotline (Gast)]

S. R. schrieb:
> Kommas und Semikolons sind auch hinreichend inkonsistent

Vergleich das mal mit C, jeweils Deklaration, Definition und Instanz. So 
anders ist das gar nicht.

C-Code

int foo ( 
  int a,
  int b,
  int c
);

int foo ( 
  int a,
  int b,
  int c
)
{
  return a+b+c;
}

my_var = foo(
  x,
  y,
  z
);

VHDL-Code

component foo (
  a: std_logic_vector(7 downto 0);
  b: std_logic_vector(7 downto 0);
  c: std_logic_vector(7 downto 0);
  d: std_logic_vector(7 downto 0)
);

entity foo (
  a: std_logic_vector(7 downto 0);
  b: std_logic_vector(7 downto 0);
  c: std_logic_vector(7 downto 0);
  d: std_logic_vector(7 downto 0)
);
architecture behav of foo is
begin
  d <= a+b+c;
end architecture;

foo_instance: foo (
  a => x,
  b => y,
  c => z,
  d => my_var
);

[Strubi (Gast)]

Weltbester FPGA-Pongo schrieb im Beitrag #4855245:
> Ich finde es lustig, dass jemand, der gerade mal ein paar HDL-Zeilen
> formuliert hat, fordert, eine neue Programmiersprache zu definieren.
>

Wer redet denn von definieren?
Ich finde es ansich positiv, dass sich jemand im Hinblick auf 
Produktivität Gedanken macht, wo die Schwächen der klassischen HDL 
liegen und wie man da frühzeitig einen innovativeren Weg einschlägt. 
Auch wenn viele VHDL-Profis dagegen unken - man hat's halt nicht so 
gelernt ("Das haben wir schon immer so gemacht").

> HDL hat alles was man braucht, um HW zu definieren, auch Verilog ist
> nicht wirklich sparsamer und eine neue wäre es sicher auch nicht.
>

Leider hat VHDL eben etwas mehr als das, und damit wird es schwierig bis 
unmöglich für den HDL-Rookie, portable Konstrukte mit maximaler 
Wiederverwertbarkeit/Mindest-Wartungsaufwand zu schreiben. Das fängt 
beim klassischen Reset-Fall (asynchron in Architektur A, synchron in B) 
und Default-Werten an und endet bei Tools, die schlicht 
"generate"-Konstrukte nicht sauber unterstützen.
Das Problem hat man bei Python/MyHDL allerdings auch, dass einige 
Konstrukte nicht übersetzen. Es ist aber deutlich einfacher, den Code 
daraufhin zu analysieren als per VHDL (obwohl sich da bei GHDL/XML etwas 
tut).

> Wer es nicht so textuell braucht, der nimmt Block Designs.
>

Zum grafischen Programmieren mag ich mich nicht mehr äussern...

> Wer mehr Text auf höherer Ebene will, nimmt System-Verilog /-C oder
> Python.
>
> Alles da.

D'accord. Drum ist doch die Frage gut, welcher von diesen zig Ansätzen 
auch akademischer Art wirklich "hands on" brauchbar ist, aber auch noch 
einen guten Standard setzt. Mir laufen immer wieder Leute über den Weg, 
die auf ihrem Gebiet mit irgend einer Exotensprache eine prima Leistung 
bringen, sobald das aber mit irgendwas Konkretem interfacen muss, geht 
eine Menge Arbeitszeit drauf (Wiederverwertbarkeit adieu).

[S. R. (svenska)]

Weltbester FPGA-Pongo schrieb im Beitrag #4855245:
> Ich finde es lustig, dass jemand, der gerade mal ein paar
> HDL-Zeilen formuliert hat, fordert, eine neue
> Programmiersprache zu definieren.

Ich sprach nicht davon, eine neue Sprache zu definieren. Lern lesen.

> HDL hat alles was man braucht, um HW zu definieren, auch Verilog ist
> nicht wirklich sparsamer und eine neue wäre es sicher auch nicht.

Sicher kann man in VHDL und Verilog beliebige Hardware definieren. Man 
kann auch in Brainf?ck beliebige Programme schreiben, 
Turing-Vollständigkeit reicht vollkommen.

Das heißt aber nicht, dass es mit einem anderen Werkzeug nicht 
möglicherweise besser (für hinreichende Definition von "besser") ginge 
und ich wollte wissen, welche Werkzeuge es da gibt und was sie taugen. 
Wer sich in die Schreinerei einarbeitet, wird sich auch erstmal 
informieren, welche Sägen es so gibt und ob eine Kreis- oder eine 
Laubsäge anzuraten ist und für was.

Mehr Informationen zu dem Thema werden wohl nicht kommen und daher danke 
ich den üblichen Verdächtigen (Lothar, Yalu, Strubi) für die Antworten 
und bin dann mal weg. Python lernen. :-)

[Nase (Gast)]

Strubi schrieb:
> unmöglich für den HDL-Rookie, portable Konstrukte mit maximaler
> Wiederverwertbarkeit/Mindest-Wartungsaufwand zu schreiben.
Vielleicht ist Hardware-Synthese auch nicht das sinnvollste 
Betätigungsfeld für den Rookie...?

> Das fängt
> beim klassischen Reset-Fall (asynchron in Architektur A, synchron in B)
Das fängt noch viel früher an.
Das fängt schon damit an, dass vermutlich 50% der Hardware-Designer 
überhaupt nicht kapieren, wie und weshalb sie einen Reset einbauen. 
Würden sie das nämlich kapieren, dann hätte man in etlichen Designs 
weder synchronen noch asynchronen Reset sondern schlicht garkeinen, weil 
absolut überflüssig.

[C. A. Rotwang (Gast)]

S. R. schrieb:

> Mich stört halt, dass der Boilerplate (für einfachere Sachen) teilweise
> doppelt so lang ist wie die eigentliche Hardwarebeschreibung und dass
> man viele Bedingungen mehrfach hinschreiben muss.

Muss man nicht, verwende (mit Verstand)  procedure oder 
Preprozessormakros, oder editormakrsTsipparbeit abnehmen. Die bauen die 
"Boilerplate" ziemlich gut automatisch als template und der Anwender 
muss nur die identifier eingeben.

S. R. schrieb:
> C. A. Rotwang schrieb:
>>> Ich danke kopfschüttelnd für diese Nichtinformation.
>> Dann schüttele mal weiter Deinen Kopf, vielleicht fällt ja der Groschen.
>
> Wenn du der Meinung bist, ich sei schlicht zu doof zum Tippen, dann lass
> das Antworten doch einfach sein.

Nein ich bin nicht  der Meinung das Du zu doof bist, an hoffnungslose 
Fälle verschwende ich keine Zeile. Ich bin der Meinung
-das dir (derzeit) der kritische Umgang mit eigenen Unzulänglichkeiten 
beim Programmieren fehlt
-das du (derzeit) tippfaul bist und insgesamt ignorant in Bezug auf 
handwerkliche Grundfertigkeiten eines Programmier bist. Dazu gehört nun 
mal das man verschiedenen Editoren antestet und durch 
Makroprogrammierung und Templateverwendung effizient einsetzen kann.

> Kommas und Semikolons sind auch hinreichend inkonsistent (im
> Boilerplate), um nach ein paar Monaten hinreichend nervig zu bleiben.

Wenn man die Konsistenz nicht erkennt, heisst nicht, das sie nicht 
vorhanden ist. Und wer nach Monaten immer noch Komma und Semicolon 
verwechselt und darüber in Rage kommt muss sich schon den Vorwurf 
gefallen lassen, den Syntax nicht richtig gelernt zu haben und auch kein 
Interesse daran zu haben. Das eigene Unvermögen mit "Fehler im 
Sprachdesign" zu begründen ist m.E. reichlich peinlich. Kleiner Tipp: es 
ist keine Schande im Zweifel den VHDL-Syntax auf einer Referenzkarte wie 
dieser http://fpga4fun.com/files/card_vhdl.pdf nachzuschlagen. Und 
Error-meldungen die der Compiler dem User um die Ohren schlägt sollte 
man mit einer vulkanischen Emotionslosigkeit begegen. Der Compiler meint 
das nicht persönlich und Fehler sind eh dazu da das man daraus lernt.

>> Es gibt keine praktische Alternative zu VHDL/Verilog.
>> Der Grund "Zuviel Tipperei - ich will eine Sprache für Tippfaule" ist
>> der dämlichste Grund eine Programmiersprache zu wechseln.
>
> Wenn ich etwas implementieren möchte, was ich auf Papier hinreichend
> skizziert habe (und dort nicht wirklich viel ist), dann möchte ich das
> nicht ewig beschreiben müssen

Schau, wenn Du ewig dafür brauchst dann ist das erst mal dein ganz 
persönliches Problem. Und wenn Du die gemachten Lösungsvorschläge nicht 
annimmst dann bleibt das auch Dein Problem. Ungeduld ist ohnehin ein 
schlechter Ratgeber und verleitet nur zu unsauberen Arbeiten.

Lesetipp: 
https://www.heise.de/developer/artikel/Weniger-schlecht-programmieren-2173247.html

[S. R. (svenska)]

C. A. Rotwang schrieb:
> Ich bin der Meinung das dir (derzeit) der kritische Umgang mit
> eigenen Unzulänglichkeiten beim Programmieren fehlt und
> das du (derzeit) tippfaul bist und insgesamt ignorant in Bezug auf
> handwerkliche Grundfertigkeiten eines Programmier bist.

Ich habe bisher viel Software programmiert, von Startup-Code und 
Treibern bis hin zu kleineren Anwendungen und Auswertelogik, außerdem 
mal ein komplettes Z80-System mit TTL und CP/M selbst entworfen und 
gelötet. Daher behaupte ich mal, dass ich (was Programmieren und 
Schaltungen angeht) relativ fit bin und inzwischen relativ gut 
einschätzen kann, was für mich funktioniert und was nicht. Ich mach 
sowas schon ein paar Jährchen, nur eben nicht mit FPGAs.

Im Sprachstandard vorgeschriebene Wiederholungen mit Editormakros 
auszumerzen, halte ich auch nicht gerade für ein gutes Feature einer 
Sprache. Man sollte nicht viel mehr aufschreiben müssen als nötig, aber 
auch nicht viel weniger (viele Sprachen tendieren dann dazu, alles in 
Bibliotheken auszulagern, was auch keine Lösung ist).

C. A. Rotwang schrieb:
> Wenn man die Konsistenz nicht erkennt, heisst nicht, das sie nicht
> vorhanden ist.

Alternativ ist es auch einfach persönliche Präferenz. Ich bevorzuge es, 
wenn ein Semikolon einen Ausdruck abschließt, statt Ausdrücke zu 
trennen. Weil dann schreibt man einfach ein Semikolon hin, wenn man 
fertig ist.

Beispiel: In Pascal wird "im Prinzip jede" Zeile mit einem Semikolon 
abgeschlossen, aber wenn die nächste Zeile mit "else" oder "end" 
anfängt, dann darf man das nicht. Theoretisch kann man das wunderbar 
begründen, praktisch ist das nur eine weitere blöde Ausnahme, die man 
lernen muss.

In VHDL ist das nicht anders. Beispiel:

entity X is         << "is" trennt Entity-Namen von Beschreibung
generic ( a; b );   << hier muss ein Semikolon hin
port    ( c; d );   << hier muss ein Semikolon hin
           ^-- Semikolon-getrennte Listen, Leerelemente sind verboten
end entity X;       << "end" beendet die Entity-Beschreibung

inst : X               << kein Trennzeichen zwischen Entity und Mapping
generic map ( a, b )   << hier darf *kein* Semikolon und *kein* Komma hin
port map    ( c, d );  << hier *muss* ein Semikolon hin
               ^-- Komma-getrennte Listen, Leerelemente sind verboten
                       << kein Keyword beendet die Instanziierung

Davon abgesehen, dass man im zweiten Fall besser "aa => ab" schreiben 
sollte: Warum muss die Syntax für Entity und Instanz so unterschiedlich 
sein, hätte nicht eine Variante auch gereicht?

Warum sind Semikolons in generics, ports und deren maps als Trennzeichen 
definiert (und weil leere Elemente nicht zulässig sind, darf das letzte 
Element nicht damit abgeschlossen werden), innerhalb von Prozessen aber 
nicht (vor "else" muss ein Semikolon stehen)?

[daniel__m (Gast)]

S. R. schrieb:
> Man sollte nicht viel mehr aufschreiben müssen als nötig,

wie sollte/könnte denn deiner Meinung nach ein Modul in Minimal 
aussehen, dass, sagen wir mal a := v + n * (o - v) berechnet?

[daniel__m (Gast)]

daniel__m schrieb:
> a := v + n * (o - v)

v und o seien 10 bit unsigned, n sei fixed point unsigned 0q10 (0 
Integerstellen, 10 Nachkommastellen).

[C. A. Rotwang (Gast)]

S. R. schrieb:
> C. A. Rotwang schrieb:
>> Ich bin der Meinung das dir (derzeit) der kritische Umgang mit
>> eigenen Unzulänglichkeiten beim Programmieren fehlt und
>> das du (derzeit) tippfaul bist und insgesamt ignorant in Bezug auf
>> handwerkliche Grundfertigkeiten eines Programmier bist.
>
> Ich habe bisher viel Software programmiert, von Startup-Code und
> Treibern bis hin zu kleineren Anwendungen und Auswertelogik, außerdem
> mal ein komplettes Z80-System mit TTL und CP/M selbst entworfen und
> gelötet. Daher behaupte ich mal, dass ich (was Programmieren und
> Schaltungen angeht) relativ fit bin und inzwischen relativ gut
> einschätzen kann, was für mich funktioniert und was nicht. Ich mach
> sowas schon ein paar Jährchen, nur eben nicht mit FPGAs.

Auch wenn der Vergleich hinkt, wenn man jahrelang eine romanische 
Sprache spricht beispielsweise Ladinisch, heisst das nicht das man eine 
andere romanische Sprache bspw. Rumänisch fehlerfrei beherrscht. Gerade 
bei ähnlichen "Sprachen" ist die Gefahr gross, das man jahrelang auf 
Anfängerniveau "kauderwelscht" weil es ja halbwegs klappt und man keine 
dringende Notwendigkeit sieht, sich nochmal auf die Schulbank zu setzen. 
Auch wenn das nötig wäre.


> C. A. Rotwang schrieb:
>> Wenn man die Konsistenz nicht erkennt, heisst nicht, das sie nicht
>> vorhanden ist.
>
> Alternativ ist es auch einfach persönliche Präferenz. Ich bevorzuge es,
> wenn ein Semikolon einen Ausdruck abschließt, statt Ausdrücke zu
> trennen. Weil dann schreibt man einfach ein Semikolon hin, wenn man
> fertig ist.
>
> Beispiel: In Pascal wird "im Prinzip jede" Zeile mit einem Semikolon
> abgeschlossen, aber wenn die nächste Zeile mit "else" oder "end"
> anfängt, dann darf man das nicht. Theoretisch kann man das wunderbar
> begründen, praktisch ist das nur eine weitere blöde Ausnahme, die man
> lernen muss.
>
> In VHDL ist das nicht anders. Beispiel:
>

> entity X is         << "is" trennt Entity-Namen von Beschreibung
> generic ( a; b );   << hier muss ein Semikolon hin
> port    ( c; d );   << hier muss ein Semikolon hin
>            ^-- Semikolon-getrennte Listen, Leerelemente sind verboten
> end entity X;       << "end" beendet die Entity-Beschreibung
> 
> inst : X               << kein Trennzeichen zwischen Entity und Mapping
> generic map ( a, b )   << hier darf *kein* Semikolon und *kein* Komma 
> hin
> port map    ( c, d );  << hier *muss* ein Semikolon hin
>                ^-- Komma-getrennte Listen, Leerelemente sind verboten
>                        << kein Keyword beendet die Instanziierung
>

>
> Davon abgesehen, dass man im zweiten Fall besser "aa => ab" schreiben
> sollte: Warum muss die Syntax für Entity und Instanz so unterschiedlich
> sein, hätte nicht eine Variante auch gereicht?
>
> Warum sind Semikolons in generics, ports und deren maps als Trennzeichen
> definiert (und weil leere Elemente nicht zulässig sind, darf das letzte
> Element nicht damit abgeschlossen werden), innerhalb von Prozessen aber
> nicht (vor "else" muss ein Semikolon stehen)?

Der Grund ist meines erachtens das was hier als "Ausdruck" zusammen 
bezeichnet wird unterschiedliche Dinge sind, nämlich declaration, 
assignment oder association. Association insbesonders named associations 
meint hier eine zuordnung über den Index, keine direkte zuweisung.
Schau mal die mal vektorzuweisungen an, da ist es möglich den index 
mitanzugeben also

vector_a(0 => sig_a, 1 => sig_b; , others => '0'); --(hoffentlich hab ich mich nicht vertippt)

hier wird nicht 0 dem signal sig_a zugewiesen; sondern dem 
Vector-Element mit dem Index 0 das Signal sig_a). So ist es auch bei den 
anderen "Mappings)" beispielsweise PORT MAP, das ist es kein vecort 
sondern ein Interface PORTS genannt, das aus einzelnenen Elementen PORT 
genannt besteht, die in der Portmap wie ein Vector einzeln anhand ihrer 
"Index" zugewiesen werden. Dagegen ist das im PORT block, einzelne 
Declarations (port_identifier, richtung, typ) und nicht associations wie 
bei PORT Map (Element-bezeichner(Identifier oder index) => zugewiesenes 
"Objekt", nächstes element ); -- Ende der Vector/PORTS zuweisung.

das '=>' ( englisch ausgesprochen "gets") verleitet das ganze mit '<=' 
ausgesprochen "assigned with" zu verwechseln. es sind aber 
unterschiedliche dinge "Elementeweise zuordnung" versus 
elemtdeklaration.
Da mal ein schnippsel aus dem LRM (Language Referenz Manual -> dem 
VHDL-Standard) dazu: 
http://www.ics.uci.edu/~jmoorkan/vhdlref/aggregat.html

[Strubi (Gast)]

Hat zwar nix mit dem Thema zu tun, aber das finde ich dann doch 
reichlich frech:

C. A. Rotwang schrieb:
> Nein ich bin nicht  der Meinung das Du zu doof bist, an hoffnungslose
> Fälle verschwende ich keine Zeile. Ich bin der Meinung
> -das dir (derzeit) der kritische Umgang mit eigenen Unzulänglichkeiten
> beim Programmieren fehlt
> -das du (derzeit) tippfaul bist und insgesamt ignorant in Bezug auf
> handwerkliche Grundfertigkeiten eines Programmier bist. Dazu gehört nun
> mal das man verschiedenen Editoren antestet und durch
> Makroprogrammierung und Templateverwendung effizient einsetzen kann.
>

Zu den Editoren muss ich anmerken, dass es in einer gewissen Gemeinde 
alles was mit Autocompletion und Template-Generierung zu tun hat, strikt 
abgelehnt wird.
Möchte man sich nicht mit Wohlfühl-Pipifax aufhalten (leider scheinen 
das eine Menge Entwickler zu tun), ist man u.U. irgendwann an einem 
Punkt, wo man einfach nur schnell ein paar Zeilen duplizieren oder 
bulk-anpassen muss, also solche IDEs einfach nur bremsen und man mit 
vi/notepad++ um Längen schneller arbeitet.
Genau da hat VHDL mit seiner komplexen Ada-Syntax Mängel, die auch immer 
wieder berechtigterweise von Softwerkern, die anderes gewöhnt sind, 
aufgezeigt werden.

>> Kommas und Semikolons sind auch hinreichend inkonsistent (im
>> Boilerplate), um nach ein paar Monaten hinreichend nervig zu bleiben.
>
> Wenn man die Konsistenz nicht erkennt, heisst nicht, das sie nicht
> vorhanden ist. Und wer nach Monaten immer noch Komma und Semicolon
> verwechselt und darüber in Rage kommt muss sich schon den Vorwurf
> gefallen lassen, den Syntax nicht richtig gelernt zu haben und auch kein
> Interesse daran zu haben. Das eigene Unvermögen mit "Fehler im
> Sprachdesign" zu begründen ist m.E. reichlich peinlich. Kleiner Tipp: es
> ist keine Schande im Zweifel den VHDL-Syntax auf einer Referenzkarte wie
> dieser http://fpga4fun.com/files/card_vhdl.pdf nachzuschlagen. Und
> Error-meldungen die der Compiler dem User um die Ohren schlägt sollte
> man mit einer vulkanischen Emotionslosigkeit begegen. Der Compiler meint
> das nicht persönlich und Fehler sind eh dazu da das man daraus lernt.

Ich bin der Meinung, dass Computersprachen nicht sinnlos verkompliziert 
werden sollten. Ein Grossteil der Probleme mit VHDL rühren vom in der 
Tat inkonsistenten und reichlich unlogischen Syntax-Baum (AST) her. 
Schon mal versucht, einen kompletten VHDL-AST abzudecken? Kann man sehr 
schön bei GHDL in OpenSource verfolgen, und sich bei vielen 
Synthese-Tools drüber ärgern, dass:

- nicht standardkonform
- fehlerhaft, aber ohne Warnung

So schön die Lesbarkeit von VHDL sein mag, die BNF ist komplett 
überladen - gerade bei Python kann man sehen, dass ein nüchtern 
denkender Mathematiker dahintersass und es einen Standard gibt. Den 
gibts bei VHDL-Tools seltenst.

Dementsprechend kann man in Python einen wunderbaren Kompromiss, um Code 
aller Arten, sei es HDL, TB oder Matlab-alike zu entwickeln, unter dem 
Aspekt lesbar, wiederverwertbar, sparsam, typensicher

Warum ich eigentlich auch immer wieder Anfängern MyHDL empfehlen kann, 
hat unter diesen Aspekten damit zu tun, dass man sich primär auf die 
Designidee fokussieren kann und sich nicht mit Schwerfälligkeiten eines 
Tools/einer Sprache rumschlagen muss. Bei System* wäre das ja in der 
Theorie auch so, nur in der Praxis...

Nase schrieb:
> Würden sie das nämlich kapieren, dann hätte man in etlichen Designs
> weder synchronen noch asynchronen Reset sondern schlicht garkeinen, weil
> absolut überflüssig.

Ahja? Das erzählst du jetzt am besten noch mal einem ASIC-Designer...
(wie war das noch mit den Initialwerten für Register...)

[S. R. (svenska)]

C. A. Rotwang schrieb:
> Auch wenn der Vergleich hinkt, wenn man jahrelang eine romanische
> Sprache spricht beispielsweise Ladinisch, heisst das nicht das man eine
> andere romanische Sprache bspw. Rumänisch fehlerfrei beherrscht.

Nein, aber dafür kann man sie relativ schnell erlernen und macht gewisse 
Fehler von vornherein nicht (Russen oder Chinesen machen völlig andere 
Fehler im Englischen als Deutsche).

C. A. Rotwang schrieb:
> Der Grund ist meines erachtens das was hier als "Ausdruck" zusammen
> bezeichnet wird unterschiedliche Dinge sind, nämlich declaration,
> assignment oder association.

Das ist genau das, was ich schrieb: Es gibt eine theoretische 
Begründung, warum das so ist, aber praktisch sind das für den 
Programmierer nur unnötige Ausnahmen, die er beherrschen muss. Eine 
gemeinsame Syntax für ähnliche Dinge vereinfacht vieles.

C. A. Rotwang schrieb:
> vector_a(0 => sig_a, 1 => sig_b; , others => '0');

Ohne das jetzt getestet zu haben, das erste Semikolon darf da nicht 
sein. Die Kombination "; ," ist sowieso immer falsch. Ob das jetzt ein 
Vertipper war, weiß ich nicht. :-)

Strubi schrieb:
> Ich bin der Meinung, dass Computersprachen nicht sinnlos verkompliziert
> werden sollten. Ein Grossteil der Probleme mit VHDL rühren vom in der
> Tat inkonsistenten und reichlich unlogischen Syntax-Baum (AST) her.

Eben. Meine Probleme mit VHDL hängen nicht mit den Konzepten 
(hierarchisches Design, saubere Interfaces, strenge Typisierung) 
zusammen, sondern mit Unzulänglichkeiten, die nicht sein müssten.

In einer guten Programmiersprache ist der Standardfall einfach und der 
komplizierte Fall möglich. Außerdem sollten Programmiersprachen sich an 
den Programmierer richten, nicht mehr an den Computer.

Ein Structural hat als Hauptaufgabe, Komponenten zu instanziieren und 
miteinander zu verbinden. Warum muss ich jedes einzelne Signal im 
Interface einzeln instanziieren und anschließen? Warum kann ich nicht 
einfach zwei Komponenten zusammenschließen, wenn sie das gleiche 
Interface benutzen? Wenn ich die Interfaces ändere, warum muss ich das 
Structural auch noch anpassen?

[Nase (Gast)]

Strubi schrieb:
> Nase schrieb:
>> Würden sie das nämlich kapieren, dann hätte man in etlichen Designs
>> weder synchronen noch asynchronen Reset sondern schlicht garkeinen, weil
>> absolut überflüssig.
>
> Ahja? Das erzählst du jetzt am besten noch mal einem ASIC-Designer...
> (wie war das noch mit den Initialwerten für Register...)
Ja, der wird das ähnlich sehen, wie ich.

Außerdem hast du mit Initialwerten eigentlich genau das Problem 
getroffen.
Welchen Nutzen versprichst du dir denn davon, in VHDL händisch einen 
Reset zu programmieren, der ein Register auf einen Anfangswert setzt?

In leider viel zu vielen Fällen ist es Blödsinn, der unnötig Logik 
verbrät. Wenn du ohnehin in VHDL händisch einen Reset für /jedes/(...) 
Register ausformulierst, dann kannst du das auch gleich weglassen und 
einfach das ganze FPGA neu laden.
Da passiert nämlich auch nix andres, als dass die Register mit den 
Werten aus dem Bitstream vorbesetzt werden.


Absolut ohne Zweifel gibt es Fälle, wo ein Reset auf die eine oder 
andere Art trotzdem nötig ist. Aber ein händisch formulierter globaler 
"aus Angst alles nochmal auf definierten Zustand setzen"-Reset ist 
meistens Mist.

[Charles G. (Firma: Ingenieurbuero Gardiner) (cfgardiner)]

S. R. schrieb:
> Warum muss ich jedes einzelne Signal im
> Interface einzeln instanziieren und anschließen? Warum kann ich nicht
> einfach zwei Komponenten zusammenschließen, wenn sie das gleiche
> Interface benutzen? Wenn ich die Interfaces ändere, warum muss ich das
> Structural auch noch anpassen?


Wenn das dein eigentliches Problem ist, musst du nicht. Definiere ein 
Typ als Record in einem globalen Package und verbinde deine Komponenten 
über die Records. Wenn du aus irgend einem Grund die Record Beschreibung 
änderst, musst du nur das Package ändern und neu kompilieren, mehr 
nicht.

e.g. für Wishbone
Package ...
   type t_wb_request_port is record
      adr   : std_logic_vector(31 downto 0);
      bte   : std_logic_vector(1 downto 0);
      cti   : std_logic_vector(2 downto 0);
      cyc   : std_logic;
      dat   : std_logic_vector(31 downto 0);
      lock  : std_logic;
      sel   : std_logic_vector(3 downto 0);
      stb   : std_logic;
      we    : std_logic;
   end record;

   type t_wb_response_port is record
      ack   : std_logic;
      dat   : std_logic_vector(31 downto 0);
      err   : std_logic;
      rty   : std_logic;
   end record;
     . . .
End Package;

Entity wb_mst_comp is
   Port (
      i_clk       : in    std_logic;
      i_rst_n     : in    std_logic;

      i_wb_resp   : in    t_wb_response_port;

      o_wb_req    : out   t_wb_request_port
      );
End wb_mst_comp;

Architecture Rtl of wb_sys
   signal s_u1_wb_req    : t_wb_request_port;
   signal s_u2_wb_resp   : t_wb_response_port;
    . . . . .


Es gibt übrigens auch ein IEEE Standard, die als Basis für die 
automatisierten Verbindung von Komponenten dienen soll, SPIRIT aka 
IP/XACT aka IEEE-1685. Meines Wissens baut z.B. Altera Qsys darauf oder 
auf einen Varianten davon. ARM hat auch einiges dazu veröffentlicht.

Übrigens, auch wenn es nach Haarspalterei klingt, aber einen Punkt hätte 
ich noch in deiner Ausführung zu bemerken. VHDL ist eigentlich keine 
Programmiersprache, es ist eine Modellierungsbeschreibung. Auch wenn 
viele Sprachkonstrukte ähnlich erscheinen. Ein guter Programmierer ist 
nicht zwingend auch ein guter Modellierer.

[Charles G. (Firma: Ingenieurbuero Gardiner) (cfgardiner)]

Nase schrieb:
>> Ahja? Das erzählst du jetzt am besten noch mal einem ASIC-Designer...
>> (wie war das noch mit den Initialwerten für Register...)
> Ja, der wird das ähnlich sehen, wie ich.

Diese Diskussion würde ich auch gerne miterleben!

Sein Design wird spätestens beim DfT (Design-for-Test) scheitern. Die 
Simulation wird lange durch irgendwelche 'X' oder 'U' gestört. Wenn 
Linting oder sowas wie DO-254 Zertifizierung gefordert ist, dann noch 
zusätzlich. Standard DfT Tools betrachten jeden Flipflop als virtueller 
Pin. Sein Zustand muss jeder Zeit bekannt/berechenbar sein.

Der Ideal ASIC ist nichts anders als eine große/gigantische FSM. Es ist 
ein Bisschen wie der Urknall. Wenn der Anfangssingularität nicht bekannt 
ist, hat das was folgt seine Rätsel und die darfst du beim debuggen 
gerne suchen.

[C. A. Rotwang (Gast)]

Strubi schrieb:
> Hat zwar nix mit dem Thema zu tun, aber das finde ich dann doch
> reichlich frech:
>
> C. A. Rotwang schrieb:
>> Nein ich bin nicht  der Meinung das Du zu doof bist, an hoffnungslose
>> Fälle verschwende ich keine Zeile. Ich bin der Meinung
>> -das dir (derzeit) der kritische Umgang mit eigenen Unzulänglichkeiten
>> beim Programmieren fehlt
>> -das du (derzeit) tippfaul bist und insgesamt ignorant in Bezug auf
>> handwerkliche Grundfertigkeiten eines Programmier bist. Dazu gehört nun
>> mal das man verschiedenen Editoren antestet und durch
>> Makroprogrammierung und Templateverwendung effizient einsetzen kann.
>>
>
> Zu den Editoren muss ich anmerken, dass es in einer gewissen Gemeinde
> alles was mit Autocompletion und Template-Generierung zu tun hat, strikt
> abgelehnt wird.

Und aus welchen (gutem) Grund? Masochismus?! Genau weil der TO seine 
Weigerung mal einen der etablierten Editoren aunzutesten nicht begründet 
hat kann man nur auf 2 Beweggründe schliessen:
-er will es einfsch nicht, das nenne ich dann ignaorant resp. dämlich
-er kann es nicht, aber das glaube ich nun wirklich ist


> Möchte man sich nicht mit Wohlfühl-Pipifax aufhalten (leider scheinen
> das eine Menge Entwickler zu tun), ist man u.U. irgendwann an einem
> Punkt, wo man einfach nur schnell ein paar Zeilen duplizieren oder
> bulk-anpassen muss, also solche IDEs einfach nur bremsen und man mit
> vi/notepad++ um Längen schneller arbeitet.

Nein es geht hier nicht um IDE's, ich persönlich meide ISE/Vibado wo es 
geht und setze auf Emacs im VHDL-mode oder notepad oder vim. Auch für 
den vim gibt es Makros sich die Arbeit bei der Instanzierung zu 
erleichtern, bspw http://0x7.ch/vim/vhdl/


> Genau da hat VHDL mit seiner komplexen Ada-Syntax Mängel, die auch immer
> wieder berechtigterweise von Softwerkern, die anderes gewöhnt sind,
> aufgezeigt werden.
>

> Ich bin der Meinung, dass Computersprachen nicht sinnlos verkompliziert
> werden sollten. Ein Grossteil der Probleme mit VHDL rühren vom in der
> Tat inkonsistenten und reichlich unlogischen Syntax-Baum (AST) her.
> Schon mal versucht, einen kompletten VHDL-AST abzudecken? Kann man sehr
> schön bei GHDL in OpenSource verfolgen, und sich bei vielen
> Synthese-Tools drüber ärgern, dass:
>
> - nicht standardkonform
> - fehlerhaft, aber ohne Warnung

Völlig falsche Herangehensweise, wir wollen hier Digitaldesigns mit VHDL 
realisieren aber keinen VHDL-Parser schreiben.
Und was Synthesetools betrifft, die beschränken sich notwendigerweise 
auf ein synthesefähiges subset. das ist auch so dokumentiert. Für 
VHDL-Synthese
gehört eben nicht nur die kenntniss der VHDL-Syntax, sondern auch die 
Kenntniss wie das jeweilige tool die gewünschte Hardware beschrieben 
haben möchte.

>
> So schön die Lesbarkeit von VHDL sein mag, die BNF ist komplett
> überladen - gerade bei Python kann man sehen, dass ein nüchtern
> denkender Mathematiker dahintersass und es einen Standard gibt. Den
> gibts bei VHDL-Tools seltenst.

Tief durchatmen, nicht losschreien ... - klar gibt es einen 
VHDL-standard, ein Standardisierungskomission ein LRM. Und wenn ein 
(Synthesetool) von diesem abweicht oder nicht unterstütz dann ist das 
auch entsprechend dokumentiert. BTW schon mal einen VHDL-Standard, das 
LRM oder wenigstens in den Design Guide eines FPGA-Herstellers wie 
diesen: https://www.xilinx.com/itp/xilinx10/books/docs/sim/sim.pdf


> Dementsprechend kann man in Python einen wunderbaren Kompromiss, um Code
> aller Arten, sei es HDL, TB oder Matlab-alike zu entwickeln, unter dem
> Aspekt lesbar, wiederverwertbar, sparsam, typensicher

So langsam verstehe ich das Problem.
Zum "Code entwickeln" ist VHDL aber nicht entwickelt worden. VHDL 
entstand als Dokumentationssprache genauer als Spezifikationssprache. 
Beispielsweise wenn ein Flugzeughersteller eine Steuerung benötigt, die 
im ein Elektronikhersteller zuliefern soll dann beschreibt er das 
möglichst naturprachlich ("wenn Endlageschalter a aktiv und Verriegelung 
C freigegeben dann stellmotor E an") in VHDL und der 
elektronikhersteller liefert was. Das war der Plan, jetzt haben die 
Hersteller gedacht sie könnten diese Auftragsbeschreibung gleich 
benutzen un die Simulation als Verifikation des Arbeitsergebniss nutzen 
oder noch besser gleich eine Netzliste für die 74 verdrahtung oder 
ASIC-Standardcell bibliothek oder programmierbaren Gate Array zu 
generieren.


> Warum ich eigentlich auch immer wieder Anfängern MyHDL empfehlen kann,
> hat unter diesen Aspekten damit zu tun, dass man sich primär auf die
> Designidee fokussieren kann und sich nicht mit Schwerfälligkeiten eines
> Tools/einer Sprache rumschlagen muss.

Ich werde mir myHDL mal anschauen und kann zum jetzigen Zeitpunkt nichts 
dazu sagen.

Mir scheint aber das die meisten Probleme des TO bereits mit einem 
Wechsel des Editors und ein bißchen Lernwillen VHDL als 
Hardwarebeschreibungssprache und nicht als Code-hacking 
Programmiersprache zu lernen.

[Strubi (Gast)]

C. A. Rotwang schrieb:

> Und aus welchen (gutem) Grund? Masochismus?! Genau weil der TO seine
> Weigerung mal einen der etablierten Editoren aunzutesten nicht begründet
> hat kann man nur auf 2 Beweggründe schliessen:
> -er will es einfsch nicht, das nenne ich dann ignaorant resp. dämlich
> -er kann es nicht, aber das glaube ich nun wirklich ist
>

Er hat glaube ich schon deutlich dargelegt, sich mit der Syntax und 
deren Logik auseinandergesetzt zu haben.
Warum ich zu schlaue Editoren ablehne, hat meist mit Coding-Style zu 
tun, aber auch damit, dass einige gerne das Nachdenken an den Editor 
abgeben. Da kommt regelmässig immer wieder ein Gau zusammen.

>
> Völlig falsche Herangehensweise, wir wollen hier Digitaldesigns mit VHDL
> realisieren aber keinen VHDL-Parser schreiben.

Unsereiner nicht zwingend. Aber probier doch mal eine der gängigen 
Standard-Testsuites an einem Synthesetool aus. Denn dessen Hersteller 
musste mal einen VHDL-Parser schreiben...

> Und was Synthesetools betrifft, die beschränken sich notwendigerweise
> auf ein synthesefähiges subset. das ist auch so dokumentiert. Für
> VHDL-Synthese
> gehört eben nicht nur die kenntniss der VHDL-Syntax, sondern auch die
> Kenntniss wie das jeweilige tool die gewünschte Hardware beschrieben
> haben möchte.
>

Das genau ist die Crux. Und schon habe ich ein n*m problem (n = IPcores, 
m = anzahl Tools/Archs)
Abgesehen davon funktioniert das weder bei Xilinx bis ISE 100% korrekt, 
noch bei Synopsys richtig standardkonform. Geht schon bei komplexeren 
"block"/"generate"-Geschichten los...

>>
>> So schön die Lesbarkeit von VHDL sein mag, die BNF ist komplett
>> überladen - gerade bei Python kann man sehen, dass ein nüchtern
>> denkender Mathematiker dahintersass und es einen Standard gibt. Den
>> gibts bei VHDL-Tools seltenst.
>
> Tief durchatmen, nicht losschreien ... - klar gibt es einen
> VHDL-standard, ein Standardisierungskomission ein LRM. Und wenn ein
> (Synthesetool) von diesem abweicht oder nicht unterstütz dann ist das
> auch entsprechend dokumentiert. BTW schon mal einen VHDL-Standard, das
> LRM oder wenigstens in den Design Guide eines FPGA-Herstellers wie
> diesen: https://www.xilinx.com/itp/xilinx10/books/docs/sim/sim.pdf
>

Ich meine nicht den VHDL-Standard, sondern den praktischen Standard, den 
man als Programmierer erwartet. Ich habe mich länger mit den Details 
beschäftigt, um eine Art Mass zu haben, welcher Code für welche 
Architektur synthetisiert. Fazit: Von Mentor bis zum grossen X sieht's 
mau aus. Xilinx hat gehörige Verstümmelungen eingebaut, um relativ 
sinnfreie Obfuscation zu unterstützen und dabei ein paar Sachen 
verbockt, die sie seit Jahren nicht beheben und um die man herumarbeiten 
muss.

Wenn man nur ein Subset einer Sprache verwenden kann und das erst nach 
Pass "n" in einer obskuren Fehlermeldung liest, ist primär das Tool 
schuld, aber man darf sich fragen (und nachvollziehen), warum das mit 
VHDL jeweils ein Krampf ist und mit Verilog weniger.
Wenn man sich GHDL (welches mit korrekter Umsetzung des Standards wohl 
auf weiter Flut bei den OS-Tools steht) ansieht, wird einem klar, warum.

> So langsam verstehe ich das Problem.
> Zum "Code entwickeln" ist VHDL aber nicht entwickelt worden. VHDL
> entstand als Dokumentationssprache genauer als Spezifikationssprache.
> Beispielsweise wenn ein Flugzeughersteller eine Steuerung benötigt, die
> im ein Elektronikhersteller zuliefern soll dann beschreibt er das
> möglichst naturprachlich ("wenn Endlageschalter a aktiv und Verriegelung
> C freigegeben dann stellmotor E an") in VHDL und der
> elektronikhersteller liefert was. Das war der Plan, jetzt haben die
> Hersteller gedacht sie könnten diese Auftragsbeschreibung gleich
> benutzen un die Simulation als Verifikation des Arbeitsergebniss nutzen
> oder noch besser gleich eine Netzliste für die 74 verdrahtung oder
> ASIC-Standardcell bibliothek oder programmierbaren Gate Array zu
> generieren.

Nur da beisst sich eben das Konzept: Einerseits ist es Hochsprache, in 
der du recht viel machen kannst, andererseits fehlen ihr die Mittel des 
Schemas, Selbst-validierung des Codes auf (für den Prozess) unerlaubte 
Konstrukte, d.h. alles was für die Zielarchitektur explizit 
ausgeschrieben ist, muss beim Port wieder explizit umgeschrieben werden. 
Nimmt einem kein noch so fancy Editor ab.

Und zur Erinnerung: Ada ist eine Programmiersprache und VHDL ist es nach 
Gesichtspunkten der Informatik ebenso, auch wenn die Hardwerker immer 
auf der "Beschreibung" herumpochen. Letzhin soll es das machen: Eine 
korrekte Beschreibung für die Synthese liefern. Aber der Programmierer 
muss sehr viel Fachwissen aufbringen, inwieweit sein Programmcode eine 
korrekte Beschreibung darstellt/erzeugt.


> Mir scheint aber das die meisten Probleme des TO bereits mit einem
> Wechsel des Editors und ein bißchen Lernwillen VHDL als
> Hardwarebeschreibungssprache und nicht als Code-hacking
> Programmiersprache zu lernen.

Dir scheint, ok. Das hast du jetzt ja auch ausreichend dargelegt.

Nase schrieb:
> In leider viel zu vielen Fällen ist es Blödsinn, der unnötig Logik
> verbrät. Wenn du ohnehin in VHDL händisch einen Reset für /jedes/(...)
> Register ausformulierst, dann kannst du das auch gleich weglassen und
> einfach das ganze FPGA neu laden.
> Da passiert nämlich auch nix andres, als dass die Register mit den
> Werten aus dem Bitstream vorbesetzt werden.

Sowas ist bei einem SoC mit Peripherie schon mal broken by design.
Wenn du ein purer Xilinxjünger bist, mag das hinhauen. Es ist aber schon 
schlechte Designpraxis z.B. bei Lattice-Logik, Ergebnis kann sein, dass 
deine Soft-CPU einfach mal einen Interrupt beim Reset feuert (beachte 
obengenannte 'X' und 'U') und es macht puff (nicht-initialisierte 
Vektoren).

Ein Initialwert a la a "signal pc: reg_32 := (others => '0')" gibs im 
harten Silizium nur als ROM-Maske/Flashzelle, und du musst explizit 
spezifieren, wie der ins Register kommt.
Bei so einigen Tools ist der Reset einfach implizit vorhanden, manchmal 
motzen die Tools und spucken irgend eine Warnung aus, wenn der global 
reset nicht explizit verwendet wird. Und dann macht's wieder ab und an 
puff...

Ein synchroner Reset ist ja bei der grossen FSM gleichbedeutend wie 
irgend eine andere enable-Leitung, die zur Zustandsänderung führt. Wo 
soll das also unnötig Logik fressen?

Aber zurück zur alten Problematik: VHDL erlaubt dir nicht, sowas 
umschaltbar und architekturunabhängig zu gestalten. Sowas kriegst du nur 
mit hässlichen Preprocessing-Verstümmelungen hin. Deswegen ist da VHDL 
weder so richtig voll-funktionale Hochsprache noch mit Asm vergleichbar.

[Strubi (Gast)]

Charles G. schrieb:
> Es gibt übrigens auch ein IEEE Standard, die als Basis für die
> automatisierten Verbindung von Komponenten dienen soll, SPIRIT aka
> IP/XACT aka IEEE-1685. Meines Wissens baut z.B. Altera Qsys darauf oder
> auf einen Varianten davon. ARM hat auch einiges dazu veröffentlicht.

IP-XACT ist ansich noch spannend. Ich nutze sowas ähnliches, um 
SoC-Peripherie und die Header für die HW-Treiber zu generieren. Das 
nimmt einem auch die obige Reset-Problematik ab, ohne dass man Umwege 
über MyHDL gehen muss.
Nur frickelt da jeder Hersteller wieder sein eigenes Ding, und wir unten 
an der Basis kriegen davon nicht so viel mit, ausser, dass eben solche 
Tools wie Qsys/SOPC oder die Lattice-Variante davon ab einem gewissen 
Punkt recht mühsam zu bedienen sind.
Hatte mir mal kactus2 angesehen, was kein schlechter Ansatz war, aber 
bin nun doch wieder bei xsltproc und Makefiles gelandet. Pure Faulheit 
und für CI will man einfach keine IDE aufrufen.

[Michael B. (laberkopp)]

Yalu X. schrieb:
> Michael B. schrieb:
>>> wüsste gerne, ob es noch andere Sprachen gibt, mit denen man gut
>>> arbeiten kann.
>>
>> Kaum, weil
>> 1. für deinen Chip diese Sprache auch verfügbar sien müsste
>
> Ich glaube, da hast du wieder einmal etwas überhaupt nicht verstanden :)

Im Gegensatz zu dir habe ich verstanden, daß svenska ein existierendes 
FPGA programmieren will und nicht Masken für einen neuen Chip definieren 
will. Hat er dafür nicht die nötige Entwicklungsumgebung (meist wird ja 
noch kostenlos gefordert), kann er es einfach vergessen.

Aber wenn der Dümnmste nicht mehr weiter weiss, löscht er missliebige 
Wahrheiten lieber, nicht wahr Yalu.

[Gabriel (Gast)]

Versuche es doch einfach mal mit verilog.
Wenn du damit auch nicht klar kommst, hmm früher hat es mal GALs 
gegeben?

[mhm (Gast)]

Michael B. schrieb:
> Yalu X. schrieb:
>> Michael B. schrieb:
>>>> wüsste gerne, ob es noch andere Sprachen gibt, mit denen man gut
>>>> arbeiten kann.
>>>
>>> Kaum, weil
>>> 1. für deinen Chip diese Sprache auch verfügbar sien müsste
>>
>> Ich glaube, da hast du wieder einmal etwas überhaupt nicht verstanden :)
>
> Im Gegensatz zu dir habe ich verstanden, daß svenska ein existierendes
> FPGA programmieren will und nicht Masken für einen neuen Chip definieren
> will. Hat er dafür nicht die nötige Entwicklungsumgebung (meist wird ja
> noch kostenlos gefordert), kann er es einfach vergessen.

Nein Michael, du hast einfach mal wieder grundsätzliche Dinge nicht 
verstanden und gibst dennoch unnötigerweise deinen Senf dazu.

Der Witz an diesen ganzen alternativen HDLs wie SpinalHDL und Chisel ist 
doch, dass sie Netzlisten in VHDL/Verilog ausspucken. Diese Netzlisten 
kannst du dann problemlos in die verfügbaren Synthesetools füttern, weil 
es ist ja VHDL/Verilog.
Würden die alternativen Sprachen dieses Konzept nicht verfolgen, hätten 
sie von vorne herein überhaupt keine Chance, denn überzeug mal einen 
großen FPGA-Hersteller, deine HDL mit momentan 5 aktiven Usern in ihrer 
Synthese zu supporten...

[S. R. (svenska)]

C. A. Rotwang schrieb:
> Nein es geht hier nicht um IDE's, ich persönlich meide ISE/Vibado wo es
> geht und setze auf Emacs im VHDL-mode oder notepad oder vim.

Wieviele Jahre hast du gebraucht, um deinen Editor mit diesen Makros 
vernünftig und produktiv bedienen zu können? Nur, um Schwächen der 
Sprachdefinition zu umgehen?

C. A. Rotwang schrieb:
> Völlig falsche Herangehensweise, wir wollen hier Digitaldesigns mit VHDL
> realisieren aber keinen VHDL-Parser schreiben.

Die Grammatik einer Sprache ist sowohl für das Verstehen als auch für 
das Generieren notwendig. Eine schlechte Grammatik macht also auch das 
Schreiben gültiger Sätze unnötig kompliziert. VHDL hat eine schlechte 
(weil inkonsistente) Grammatik.

> Und was Synthesetools betrifft, die beschränken sich notwendigerweise
> auf ein synthesefähiges subset. das ist auch so dokumentiert.

Das hilft mir aber nicht, wenn ich mehr als ein Tool auf einer Plattform 
einsetzen möchte. Mag ja sein, dass mein realer FPGA ein "Xilinx Zynq" 
ist und mein Tool ein "Xilinx Vivado". Nächstes Jahr muss ich das Design 
aber vielleicht in einen Lattice tun (die Chancen stehen gut, weil 
Akademie) und dessen Tool beherrscht ein anderes Subset.

> Für VHDL-Synthese gehört eben nicht nur die kenntniss der VHDL-Syntax,
> sondern auch die Kenntniss wie das jeweilige tool die gewünschte
> Hardware beschrieben haben möchte.

Beschreibe in VHDL mal einen Speicher mit zwei Ports, von denen einer 
byte- und einer wortweise zugreifbar ist. Kein Problem. Jetzt bringe 
Vivado dazu, daraus einen Block-RAM zu inferieren. Das ist unmöglich.

Also beschreibe ich es mit Hilfe der Xilinx-Bibliothek und verliere 
sofort jede Möglichkeit, einen Nicht-Xilinx-Simulator (z.B. GHDL) zu 
verwenden. Ist das nicht super?

Versuche mal, aus einer VHDL-Beschreibung ein Block-RAM mit einem 
byteweisem Port oder zwei identischen Ports inferieren zu lassen, über 
mehr als ein Tool. Das ist immerhin nicht unmöglich, aber unglaublich 
zerbrechlich.

C. A. Rotwang schrieb:
> Und wenn ein (Synthesetool) von diesem abweicht oder nicht
> unterstütz dann ist das auch entsprechend dokumentiert.

Das hilft mir nicht, wenn ich mehr als ein Tool benutzen möchte. Deine 
Vorstellung scheint mir ein bisschen wie ein Gebrauchtwarenhändler, der 
in seinem Leben nur "VW Golf" verkauft hat und glaubt, er wisse daher 
alles über Autos.

Michael B. laberte:
> viel heiße Luft.

> Im Gegensatz zu dir habe ich verstanden, daß svenska ein existierendes
> FPGA programmieren will und nicht Masken für einen neuen Chip definieren
> will.

Ich produziere kein Produkt auf Basis eines bestimmten FPGAs. Das heißt 
auch, dass ich mich nicht fest auf einen FPGA (oder eine Familie) 
einschießen kann.

Michael B. schrieb:
> Aber wenn der Dümnmste nicht mehr weiter weiss, löscht er missliebige
> Wahrheiten lieber, nicht wahr Yalu.

Nicht ein Geisterfahrer... Hunderte!

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

OT, aber nötig:
Michael B. schrieb:
> Aber wenn der Dümnmste nicht mehr weiter weiss, löscht er missliebige
> Wahrheiten lieber, nicht wahr Yalu.
Wenn jemand (in diesem Fall DU!) sich seines Namens nicht mehr erinnern 
kann und entgegen den Forenregeln (Nutzungsbedingungen) mit mehreren 
Namen in einem Thread eine Sammlung von Beschimpfungen schreibt, dann 
kann er m.E. froh sein, dass nur der letzte der Posts gelöscht wird und 
nicht einfach alle.
Und das mit dem Löschen war nicht Yalu. Auch wenn es gut ins 
"Feindbild" gepasst hätte. Klar soweit?

Und wenn das dann mal zur Synapse durchgesickert ist, dann kommen wir 
nochmal auf den "Dümnmsten" zurück...

[C. A. Rotwang (Gast)]

S. R. schrieb:
> C. A. Rotwang schrieb:
>> Nein es geht hier nicht um IDE's, ich persönlich meide ISE/Vibado wo es
>> geht und setze auf Emacs im VHDL-mode oder notepad oder vim.
>
> Wieviele Jahre hast du gebraucht, um deinen Editor mit diesen Makros
> vernünftig und produktiv bedienen zu können? Nur, um Schwächen der
> Sprachdefinition zu umgehen?

Erster Teildesign das produktiv eingesetzt wurde, hab ich während der 
Abschlussarbeit (Diplom-ET) erstellt. Das hat kein Jahr gedauert, 
sondern ein halbes. Kein Gaga-design, aber auch keinSuper-SoC, die gab 
es vor 20 Jahren noch nicht. Dann Job im Ingenieurbüro, Kollege setzt 
mir den Editor Emacs vor die die Nase, zeigt ein paar Kniffs, setzt mir 
makefile und altes Design mit Firman-Package ins Home-dir und nach ca. 4 
Wochen liefen die erste Erweiterungen (handgeschriebener 
DMA-controller). Das Prädikat effektiv oder akademisch_elegant hat 
der Code sicher nicht verdient, aber das interessiert auch nicht. 
Vielleicht kann man das als Tipp ableiten: "Schert Euch in der ersten 
Woche nicht um Code-eleganz sondern bringt die Sache ans Laufen. "
Ein Grossteil  dieser Zeit hab ich mit Verstehen des Makefiles 
insbesonders der kommandlineoptionen der xilinx-toolchain xst, 
ngd_built, map und par verbracht. Zu Zeiten von ISE ging das noch, bei 
Vivado verschwindet alles unter einen grossen deckel. Die Toolchain 
schert sich wenig ob VHDL, Verilog oder irgendwelchen sonstigen 
Syntax-schmarrn, da gehts immer nur um die "Hardware die hinten raus 
kommt".



> C. A. Rotwang schrieb:

> Die Grammatik einer Sprache ist sowohl für das Verstehen als auch für
> das Generieren notwendig. Eine schlechte Grammatik macht also auch das
> Schreiben gültiger Sätze unnötig kompliziert.

Beim FPGA-Design geht es nicht um das Schreiben "gültiger Sätze" sondern 
um das Schreiben Synthesefähigen Codes. Dies schafft man, wenn man dem 
für das jeweilige Synthesetool Design guide liest und die dort genannten 
Beschreibungen bspw für D-FF pipelines verwendet. Mit "Standardkonformen 
Gültige Sätze generieren" schafft man das nicht. Weil, es ist keine 
programmiersprache sondern eine Beschreibungssprache. Nicht alles was 
man beschreiben kann, ist fpga-technisch machbar.

Im Rückblick, würde ich das als den Durchbruch bei "FPGA-Lernen" 
bezeichen. Man nutzt VHDL nicht so wie beim (bare-bone) C programmieren, 
sondern hat eine Blockskizze von "gültiger Hardware" (Mux, Logikwolke, 
FSM, Buffer,...) die man mit dem jeweiligen VHDL-subset runterschreibt.

> VHDL hat eine schlechte
> (weil inkonsistente) Grammatik.

Kann ich nicht einschätzen, da ich mit ET-Abschluss keine tiefe Ahnung 
von Computergrammatik habe. Daher störe ich mich auch nicht dran ob die 
nun als gut oder schlecht gilt. Mit dieser pragmatischen Vorgehensweise 
habe ich Dutzende Designs abgeschlossen.

> Beschreibe in VHDL mal einen Speicher mit zwei Ports, von denen einer
> byte- und einer wortweise zugreifbar ist. Kein Problem. Jetzt bringe
> Vivado dazu, daraus einen Block-RAM zu inferieren. Das ist unmöglich.
>
> Also beschreibe ich es mit Hilfe der Xilinx-Bibliothek und verliere
> sofort jede Möglichkeit, einen Nicht-Xilinx-Simulator (z.B. GHDL) zu
> verwenden. Ist das nicht super?
>
> Versuche mal, aus einer VHDL-Beschreibung ein Block-RAM mit einem
> byteweisem Port oder zwei identischen Ports inferieren zu lassen, über
> mehr als ein Tool. Das ist immerhin nicht unmöglich, aber unglaublich
> zerbrechlich.

Kenn ich, die Problematik, die Lösung ist eine entity und mehrere 
architectures zu schreiben, zwischen denen schaltet man per config-use 
um.
Oder wenn die tools das nicht mögen, dann packt man die architectures in 
seperate files und füttert dann im makefile die tools mit den passenden.

Das ist beim (PC-)Programmieren oft auch nicht anders, toolunabhängig, 
heisst dort nicht selten, den code zweimal zu schreiben und mit 
bedingeten kompilieren umzuschalten.

"Architekturunabhängis Design" ist auch so eine Augenwischerei. Mancher 
denkt das wäre ein code für jede platform. Die realität ist dann aber 
ein Software-Package in dem sich spezif. code für die jeweilige Platform 
findet.
Jetzt gibt es aber auch Java. Ja, aber das erreicht die Portierbarkeit 
über eine Hardware Abstraction Layer. Kein Problem? Nun wir reden hier 
vom Hardwareentwurf, jetzt versuche mal Hardwareunabhängige (aka 
Architekturunabhängig) Hardware zu entwerfen in dem man eine 
Hardwareabstraktionsschicht auf der Hardware implementiert - das klingt 
für mich als Hardwareentwickler irgendwie Gaga.

> C. A. Rotwang schrieb:
>> Und wenn ein (Synthesetool) von diesem abweicht oder nicht
>> unterstütz dann ist das auch entsprechend dokumentiert.
>
> Das hilft mir nicht, wenn ich mehr als ein Tool benutzen möchte. Deine
> Vorstellung scheint mir ein bisschen wie ein Gebrauchtwarenhändler, der
> in seinem Leben nur "VW Golf" verkauft hat und glaubt, er wisse daher
> alles über Autos.

mein Erfahrungsportfolio:
Xilinx: Spartan-XL bis Kintex, Zynq
Altera: cyclone ii bis IV, ARRIA SoC
Actel: MACH irgendwas

Synthesetools: XST, Quartus2, Cadance fpga-designer, Synopsies synplify, 
mentor graphics Leonardo/precision

Ich hab nicht alles in 20 Jahren gelernt, aber ne ganze Menge.

[S. R. (svenska)]

C. A. Rotwang schrieb:
> Dann Job im Ingenieurbüro, Kollege setzt mir den Editor Emacs vor
> die die Nase, zeigt ein paar Kniffs, setzt mir makefile und
> altes Design mit Firman-Package ins Home-dir

So einen Kollegen hab ich leider nicht. :-(

Hab über einen Monat damit verbraten, ein Testdesign (reproduzierbar und 
mit Versionskontrolle) in Vivado auf den Zynq zu kriegen. Erst dann 
wurde es einigermaßen produktiv.

C. A. Rotwang schrieb:
>> VHDL hat eine schlechte (weil inkonsistente) Grammatik.
> Kann ich nicht einschätzen, da ich mit ET-Abschluss keine tiefe Ahnung
> von Computergrammatik habe.

Ich bin auch kein Informatiker. Aber wenn die Syntax in sich 
inkonsistent ist (d.h. grundsätzlich ähnliche Dinge unterschiedliche 
Syntax haben), dann ist die Grammatik der Sprache scheiße.

C. A. Rotwang schrieb:
> Das ist beim (PC-)Programmieren oft auch nicht anders, toolunabhängig,
> heisst dort nicht selten, den code zweimal zu schreiben und mit
> bedingeten kompilieren umzuschalten.

Ich arbeite zwar über verschiedene Architekturen hinweg, aber mache C 
nur mit gcc (Assembler mit ARM-MDK, weil ich gezwungen werde). Damit 
sehen die Startup-Codes für verschiedene Architekturen ziemlich gleich 
aus.

C. A. Rotwang schrieb:
> Ich hab nicht alles in 20 Jahren gelernt, aber ne ganze Menge.

Davon hab ich noch 19,5 Jahre vor mir. Aber ich bin mir sicher, du wirst 
in der Zeit auch viel unter Fluchen gelernt haben. :-)

[C. A. Rotwang (Gast)]

Jetzt bin ich es müde mit diesem Thread, letzter Beitrag meinerseits:

S. R. schrieb:

> So einen Kollegen hab ich leider nicht. :-(

Bist du an einer Hochschule? Zu meinen Diplomzeiten hatten sich die 
FPGA-Entwickler im Campusbereich ziemlich gut zum Tippaustausch 
zusammengefunden. Also die Diplomanden der Fakultäten Inf und ET und 
Doktoranden der Lehrstühle und aus der Frauenhofer Gesellschaft. Hies 
damals "User Group treffen".
Dergleichen lässt sich sicher auch woanders initiieren.

> Hab über einen Monat damit verbraten, ein Testdesign (reproduzierbar und
> mit Versionskontrolle) in Vivado auf den Zynq zu kriegen. Erst dann
> wurde es einigermaßen produktiv.

Ein Monat für Einarbeitung in Vivado und Zynq ist nicht schlecht, das 
ist sogar gut. Und ich schätze die "Zeitfresser" lagen eher bei 
Vivado/tool chain als in der HDL.

> Aber wenn die Syntax in sich
> inkonsistent ist (d.h. grundsätzlich ähnliche Dinge unterschiedliche
> Syntax haben), dann ist die Grammatik der Sprache scheiße.

Ja und? Bei den englischen Verben ist die Zeitformbildung auch nur 
begrenzt "konsistent" (bspw. (clear, cleared, cleared) vs. (set, set, 
set)), da muss man halt die Ausnahmen pauken und täglich anwenden bis es 
sitzt. Und der Editor kann helfend eingesetzt werden.

> Aber ich bin mir sicher, du wirst
> in der Zeit auch viel unter Fluchen gelernt haben. :-)

Ich leb nach dem Motto: "Ärgern macht mich nicht fröhlich", jedenfalls 
versuch ich das; fluchen ist m.E. keine Lern-/Lösungsstrategie.

[S. R. (svenska)]

C. A. Rotwang schrieb:
>> So einen Kollegen hab ich leider nicht. :-(
> Bist du an einer Hochschule?

Ja, aber nur an einer sehr kleinen. Hardwareentwicklung wird bei uns 
nicht gelehrt, daher kann ich nichtmal Studenten für die länglichen 
Fingerübungen benutzen.

C. A. Rotwang schrieb:
>> Aber wenn die Syntax in sich
>> inkonsistent ist (d.h. grundsätzlich ähnliche Dinge unterschiedliche
>> Syntax haben), dann ist die Grammatik der Sprache scheiße.
>
> Ja und? Bei den englischen Verben ist die Zeitformbildung auch nur
> begrenzt "konsistent", da muss man halt die Ausnahmen pauken und
> täglich anwenden bis es sitzt.

Bei natürlichen Sprachen kann man so argumentieren, aber bei 
Computersprachen muss das nicht sein.

Ich hab mich jetzt ein bisschen in MyHDL eingelesen und im Prinzip 
gefällt mir das. Die Einbindung von VHDL-/Verilog-Blöcken ist irgendwie 
hässlich, und wie man eine Abstraktion von Bussen (entweder als records 
oder besser als Objekte mit read/write-Methoden) synthetisierbar 
hinbekommt, weiß ich noch nicht. Mein derzeitiges Projekt mache ich 
jetzt erstmal in VHDL weiter.

Wenn das läuft, habe ich eine Grundlage, wo ich MyHDL sinnvoll 
integrieren kann und dann sehe ich weiter.

Danke nochmal für die Diskussion.

[S. R. (svenska)]

berndl schrieb im Beitrag #4862493:
>> Ja, aber nur an einer sehr kleinen. Hardwareentwicklung wird bei uns
>> nicht gelehrt, daher kann ich nichtmal Studenten für die länglichen
>> Fingerübungen benutzen.
>>
> mit Verlaub: Du scheinst ein >>Schimpfwort gelöscht!<< zu sein!

Aufgaben der Form:
- hier ist ein Prozessor-Core,
- hier ist die dazu passende Toolchain,
- hier ist ein FPGA-Board,
- hier ist ein fertiges Programm "LED-Blinker und Schalter",
- baue daraus ein System, welches programmgesteuert (z.B. mit C)
  die LEDs blinken lässt,

sind durchaus angemessene Aufgaben für ein zweimonatiges 
Studentenprojekt (oder sogar eine Bachelorarbeit) im Bereich 
"programmierbare Logik" oder "Steuerungs-/Automatisierungstechnik".

Wenn du das nicht einsiehst, hast du entweder nie eine Hochschule von 
innen gesehen oder hättest es auch gleich sein lassen können.

[berndl (Gast)]

> Aufgaben der Form:
> - hier ist ein Prozessor-Core,
> - hier ist die dazu passende Toolchain,
> - hier ist ein FPGA-Board,
> - hier ist ein fertiges Programm "LED-Blinker und Schalter",
> - baue daraus ein System, welches programmgesteuert (z.B. mit C)
>   die LEDs blinken lässt,
klingt spannend, so lernen also junge Leute wie 
HW-Entwicklung/Logic-Design funktioniert. Interessant...

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

S. R. schrieb:
> Aufgaben der Form:
> - hier ist ein Prozessor-Core,
> - hier ist die dazu passende Toolchain,
> - hier ist ein FPGA-Board,
> - hier ist ein fertiges Programm "LED-Blinker und Schalter",
> - baue daraus ein System, welches programmgesteuert (z.B. mit C)
>   die LEDs blinken lässt
> sind durchaus angemessene Aufgaben für ein zweimonatiges
> Studentenprojekt (oder sogar eine Bachelorarbeit) im Bereich
> "programmierbare Logik" oder "Steuerungs-/Automatisierungstechnik".
Ich hätte für ein zweimonatiges Praktikum gleich mit der letzten Aufgabe 
"Hallo Welt" angefangen und zwar direkt in VHDL ganze ohne das im Grunde 
unnötige Zinnober mit dem Prozessorcore, das in der freien Industrie eh' 
so gut wie keiner macht.
Denn mal ehrlich: ein fertiger Prozessor ist schneller, potenter und 
viel, viel billiger. Das daran angeflanschte wesentlich kleinere FPGA 
darf dann die Aufgaben machen, die ich brauche, die aber nicht im 
Prozessor drin oder als fertiges ASIC erhältlich sind.

Und dann hätte es in den zwei Monaten über RS232, VGA, und "Pong" hinweg 
sicher noch bis zur Implementierung eines aufwändigeren Projektes 
gereicht.

> Wenn du das nicht einsiehst, hast du entweder nie eine Hochschule von
> innen gesehen
Ich für meinen Teil habe über meine 
Praktikanten/Diplomanden/Bacheloranden/Masteranden schon einige 
Hochschulen von innen gesehen. Und war des Öfteren über deren 
unglaublich abstrakte Vorgehensweise beim Hardwaredesign erschrocken. 
Und ich habe mit einigen Professoren schon exzessive Diskussionen zum 
Thema "zu Tode simulieren" oder "mal auf die Hardware gehen" geführt.

> oder hättest es auch gleich sein lassen können.
Sind das nicht ziemlich gewagte Worte, wenn man gerade mal ein halbes 
Jahr mit FPGAs rummacht?
Denn S. R. schrieb:
> C. A. Rotwang schrieb:
>> Ich hab nicht alles in 20 Jahren gelernt, aber ne ganze Menge.
> Davon hab ich noch 19,5 Jahre vor mir.

[Georg A. (georga)]

Lothar M. schrieb:
> Ich für meinen Teil habe über meine
> Praktikanten/Diplomanden/Bacheloranden/Masteranden schon einige
> Hochschulen von innen gesehen. Und war des Öfteren über deren
> unglaublich abstrakte Vorgehensweise beim Hardwaredesign erschrocken.

Kein Wunder, denn die haben selber nie Hardware für ein reales Produkt 
designed. Da bleibt ihnen dann auch nur theoretisches RumgewiXXe 
übrig...

[S. R. (svenska)]

Lothar M. schrieb:
> Ich hätte für ein zweimonatiges Praktikum gleich mit der letzten Aufgabe
> "Hallo Welt" angefangen und zwar direkt in VHDL ganze ohne das im Grunde
> unnötige Zinnober mit dem Prozessorcore, das in der freien Industrie eh'
> so gut wie keiner macht.

Das hängt davon ab, warum man es will. Uns geht es nicht darum, einen 
Softcore für produktive Zwecke zu verwenden, denn dafür gibt es 
tatsächlich sinnvollere Ansätze.

Wenn man aber mittelfristig eine Experimentierplattform auf Basis von 
vielen Prozessoren braucht, um daran bestimmte Algorithmen, Netzwerke 
und Beschleuniger auszuprobieren, ist das was anderes.

Am Ende ist es ohnehin egal, welche IP-Cores ein Student nun 
zusammenkleben muss, um seine Aufgabe zu lösen - es bleibt ein Projekt, 
wo das Drumherum (Management, Dokumentation) wichtiger ist als der 
fachliche Teil.

Lothar M. schrieb:
>> oder hättest es auch gleich sein lassen können.
> Sind das nicht ziemlich gewagte Worte, wenn man gerade mal ein halbes
> Jahr mit FPGAs rummacht?

Bitte verzeihe mir die gewagten Worte, aber sie richteten sich an 
denjenigen, der mich grundlos anonym als (weggelassen) beschimpfte und 
dessen Nachricht von einem Mod schon gelöscht wurde. Im Zitat steht's 
noch drin.

Das ging explizit weder an dich noch an C.A.Rotwang!

[Steffen Reith (Gast)]

Hallo Svenska,

gleich mal vorneweg: Ich finde VHDL eine schöne Sache und
die Schreiberei ist nun wirklich nicht das Problem (bedenke
wie oft man Dinge neu schreibt und wie oft man Dinge nur pflegt),
d.h. es kommt (meiner Meinung nach) ehr auf die Lesbarkeit und
Wartbarkeit von Code an.

Was ich gegenwärtig in der FPGA-Welt nicht toll finde ist, dass
man sich schnell an einen Hersteller bindet. Insbesondere die
unsäglichen IP-Core Orgien (einmal so ein Teil von Xilinx verwendet
und man kommt ohne großen Aufwand nicht mehr von Xilinx weg). Da ist
der Ansatz von Standardbibliotheken wie bei C oder anderen
Programmiersprachen schon viel besser. Würde für die Synthese der
komplette Sprachumfang von VHDL-2008 von allen Herstellern unterstützt,
dann könnte man sich "leicht" solche Bibliotheken bauen, aber zumindest
Vivado unterstützt nur einen kleinen Subset (zumindest bei meinem
letzten Versuchen).

Also war ich auch auf der Suche nach einer HDL "höheren Levels", die
mich nicht an einen Hersteller bindet. Chisel fand ich nicht so schön,
weil die generierten Signalnamen nicht mit den eigenen übereinstimmen
(das macht die Simulation z.B. mit GHDL schwer). Das hat mich zu Spinal
gebracht. Also habe ich mal ein Demoprojekt gebaut, um für mich zu
lernen, ob es für mich taugt. Dazu wurde die J1 CPU von James Bowman
reimplementiert

https://github.com/SteffenReith/J1Sc

und gleich noch der dazugehörige FORTH-Interpreter angepasst. Ich
kann nur sagen, dass ich von Spinal extrem positiv überrascht bin,
denn alles funktioniert recht reibungslos (gekämpft habe ich nur 3
Wochen an einem fehlerhaft synthetisierten BlockRAM, das hat aber
Vivado vermasselt), die Abstraktionsfähigkeit ist enorm (manchmal wirkt
der Code von Charles Papon wie Magie), es gibt eine mächtige
Standardbibliothek (enthält z.B. eine RISCV Implementierung) und alles
wird brav in portables VHDL oder Verilog übersetzt. Nachteil ist, dass
die Dokumentation noch nicht auf dem Stand ist den man sich so wünschen
würde. Allerdings ist Charles Papon extrem schnell mit den Antworten
(mancher hochpreisige Herstellersupport würde dagegen vor Scham im Boden
versinken).

Kurz: Lerne es. Schaden kann es nicht und Scala ist nun auch nicht
wirklich eine Hürde.

Viele Gruesse,
Steffen

[Andreas H. (Gast)]

Sry, hatte den Fred im Januar anscheinend übersehen. Nur ganz kurz (und 
ohne Anmeldung. Sry, zu faul):

Nase schrieb:
> Strubi schrieb:
>> Nase schrieb:
>>> Würden sie das nämlich kapieren, dann hätte man in etlichen Designs
>>> weder synchronen noch asynchronen Reset sondern schlicht garkeinen, weil
>>> absolut überflüssig.
>>
>> Ahja? Das erzählst du jetzt am besten noch mal einem ASIC-Designer...
>> (wie war das noch mit den Initialwerten für Register...)
> Ja, der wird das ähnlich sehen, wie ich.

Nein, tut er nicht (und wir machen ASICs).
Was Du da schreibst gilt nur für FPGAs. Die UnArt den Reset wegzulassen 
ist bei ASICs ein absolutes NO-GO.

/regards

[C. A. Rotwang (Gast)]

Andreas H. schrieb:

> Nein, tut er nicht (und wir machen ASICs).
> Was Du da schreibst gilt nur für FPGAs. Die UnArt den Reset wegzulassen
> ist bei ASICs ein absolutes NO-GO.

Ihr sprecht hier von zwei verschiedenen Realisierungen der 
FF-Initialisierung. Per Reset-leitung (asynchron oder synchron) oder 
durch IC-weite Initialiierungsphase (bspw. serielles Beschreiben der im 
Scanpath verbundenen SRAM-Zellen des FPGA's).

Beim FPGA gibt es sehr wohl einen funktionalen globalen Reset. Da wird 
nix essentielles weggelassen. Es wird halt (stärker) nach lokalen und 
globalen Reset unterschieden.

Zum Nachlesen der Klassiker hierzu:
https://www.xilinx.com/support/documentation/white_papers/wp272.pdf

Als "Unart" würde ich das nicht bezeichnen. Wo die Funktion des globale 
Reset-Netzwerk durch andere Designteile realisiert/Ersetzt wird, macht 
es keinen Sinn es zu verwenden.


PS:
Was anderes wäre der Einwurf das einige Designer ausschliesslich auf 
D-FF statt auf (synchrone) RS-FF setzen. Da ist tatsächlich ineffizient. 
Und dazu gibt es auch eine Appnote 
https://www.xilinx.com/support/documentation/white_papers/wp275.pdf

[Tippgeber (Gast)]

Gestern hat einer einen link im FPGA-Forum gepostet, wo er eine neue 
Programmiersprache für FPGAs vorgestellt hat.

Ein Großteil der Tipparbeit entfällt, weil man diese von einem 
link-script erzeugt werden, welches nur die grundsätzlichen entity-namen 
und Ports braucht und den Rest logisch vergibt. Ist natürlich alles 
manuell änderbar.

Das schöne ist, dass individuelle Strukturen für Lattice und Xilinx 
selber erzeugt werden. Man hat also den Code pauschal und muss nicht so 
viel an den Hersteller anpassen. Für Altera und Actel wird es gerade 
angepasst.

Es gibt sogar workarounds für die Cores, die nur bei einem Hersteller 
vorhanden sind, oder lizenzoflichtig sind.

Das Beste ist, dass es die meisten Cores schon fertig als Macro gibt und 
man sie nur per COPY und PASTE einfügen muss. Eigene MACROS brauchen nur 
einen wrapper, die man selber schreiben kann. Langfristig sind auch 
wrapper und conversions scripte für die SOPC Systeme geplant, die von 
Altera und Xilinx ausgeworfen werden.


Hab es mal ausprobiert: Sieht sehr gut aus und könnte die Zukunft der 
FPGA-Entwicklung sein.

http://minas.berkeley.edu/department13/evals/public/minas-tryout/firstofapriljoke/forgermans

[ErBl (Gast)]

System Verilog + Interfaces. Weniger schreiben geht kaum.

[Daniel -. (root)]

Haskell :)

https://en.m.wikipedia.org/wiki/Bluespec
http://blog.raintown.org/p/lava.html
http://www.clash-lang.org/

[Weltbester FPGA Pongo (Gast)]

Arbeitet jemand ernsthaft mit solchen Alternativen?

[Timo (Gast)]

Ich möchte nur eine Sache zur zugegebenermaßen alten Diskussion 
hinzufügen:

Hardware- Design/Synthese macht unglaublich viel Spaß. Gewissen Züge von 
VHDL sind angenehm und logisch, die denke ich sehr gut widerspiegeln was 
in der wahren Welt abgeht.

Allerdings bin ich der Meinung, es müsste langsam mal eine 
Hardwaresynthesesprache geben, die heutigen Anforderungen gerecht wird 
und konsistenter ist.

Mit VHDL ist nichts falsch, allerdings ist der Syntax unglaublich 
schei** und einige Sachen sind zu umständlich gelöst.
Ich hoffe immer noch, dass irgendwer mal irgendwann ein "neues" VHDL 
erschafft. Und vorallem auch freie/erschwingliche Tools dafür 
entwickelt.
Aber da braucht man wohl einen barmherzigen Samariter für...

Die Hoffnung stirbt zuletzt!

[Gustl B. (-gb-)]

Timo schrieb:
> Mit VHDL ist nichts falsch, allerdings ist der Syntax unglaublich
> schei** und einige Sachen sind zu umständlich gelöst.

Ist das wirklich ein Problem? Den Großteil der Zeit verbringt man doch 
nicht mit dem Schreiben von Code sondern mit Nachdenken. Das Schreiben 
selbst ist bei mir nur ein kleiner Teil der Zeit. Da finde ich es dann 
eher sogar gut, dass VHDL so "geschwätzig" ist. Dadurch kann man den 
Code gut lesen und verstehen.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Vll. noch ein kleiner Tipp:

Wem Konstrukte an VHDL nicht gefallen, darf sich gerne aktiv beteiligen

http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/WebHome

[S. R. (svenska)]

Gustl B. schrieb:
> Ist das wirklich ein Problem?

Ja, denn damit lässt sich schlecht etwas schnell prototypisch aufsetzen 
und testen. Als Profi muss man das vermutlich nicht, aber wenn man nicht 
täglich mit VHDL zu tun hat, tut man das eigentlich ständig.

Wenn ich für einen "hmm, könnte man das vielleicht so lösen?"-Test 
zuviel Zeit versenken muss, dann verzichte ich auf den Test und löse 
lieber entweder nach 08/15-Standardschema oder lass es ganz bleiben.

Das kann man gut finden. Ich finde es nicht gut.

Gustl B. schrieb:
> Dadurch kann man den Code gut lesen und verstehen.

Aus "viel Code" folgt nicht "verständlicher Code". Das ist ähnlich 
hilfreich, wie jemandem schlicht ein Datenblatt/Lexikon vor den Latz zu 
knallen und zu sagen "steht doch alles drin".

[Klakx (Gast)]

kommt auf die Anwendung an. Genauso sowas:

"Schnell mal ein C#-Programm mit GUI erstellen"

"Schnell mal eine analoge Schaltung aufbauen"

..das könnte ich auch nicht aus der kalten und würde dauern, wenn ich 
das nicht so oft mache.

Für Algorithmen könnten dir die Ansätze mit HLS und SystemC helfen, um 
schneller zum Ergebnis zu kommen. Ist aber auch nichts für mal nebenbei.

Prinzipiell brauchst du eigentlich wie bei der C-Entwicklung:
* eine relativ universelle Eval-Platine (am besten mit integriertem 
Programmer)
* einen Designflow für ein "Hello World" bzw. "Hello Blink" Projekt

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

S. R. schrieb:
> Ja, denn damit lässt sich schlecht etwas schnell prototypisch aufsetzen
> und testen.
Kann ich so nicht bestätigen...  ;-)
Siehe das Zwischenergebnis im 
Beitrag "Re: kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)"

Und meist ist es so, dass durch "längeres Nachdenken" statt "sofort 
Lostippen" so viel Tipparbeit eingespart wird, dass man hinterher gleich 
lang gebraucht, aber ein schöneres Ergebnis hat. Da gefällt mir der 
Beitrag "Hilfe für Code - VHDL" ganz gut.

> Aus "viel Code" folgt nicht "verständlicher Code".
Korrekt. Wenn einer einfach nicht weiß, was er überhaupt will und 
braucht, dann wird es auf jede Art umständlich. Auch mit einem 
Schaltplan oder mit Verilog oder mit System-C.

[Gustl B. (-gb-)]

S. R. schrieb:
> Ja, denn damit lässt sich schlecht etwas schnell prototypisch aufsetzen
> und testen.

Was beim Aufsetzen von einem einfachen Testprojekt bei mir am meisten 
Zeit kostet ist der Kampf mit Vivado. Also anlegen vom Projekt, 
hinzufügen von Dateien, ...

Daher habe ich für so Spielereien ein kleines Spielwieseprojekt das ich 
einfach nur kopieren und umbenennen muss. Dann steht da ein kleines 
Projekt mit Beschreibung und Testbench das ich an die neue Spielerei 
leicht anpassen kann. Besonders hilfreich ist dabei die Funktion "Suchen 
und Ersetzen". Klar, das könnte man auch allgemein lösen. Man könnte z. 
B. vorgeben, dass ein Projekt immer einen fixen Aufbau haben muss. Die 
Topleveldatei muss Top genannt werden, die Testbenchdatei muss auf 
_bench.vhd enden, ... aber das engt eben auch wieder ein. Bei VHDL ist 
es erlaubt das komplette Projekt inklusive Testbench und aller 
Components in einer einzigen .vhd Datei zu beschreiben. Mit einem 
geeigneten Texteditor wie Notepad++ kann man dann sogar alles was man 
nicht sehen will zusammenklappen und erhält dann eine gute Übersicht.

Ja, Portdeklarationen nerven, aber für Port Map gibt es ja Abkürzungen. 
Sonst finde ich die Geschwätzigkeit gut. Man könnte natürlich wie in 
Python den ":" und Einrückungen verwenden aber was wird dann aus sehr 
langen Statements? Ich will den Quelltext so formatieren können wie es 
mir gefällt. Und wie in C mit den verschiedenen Klammerarten finde ich 
auch eher unleserlich. Je knapper du die Syntax machst, desto größer 
wird dann der Übersetzungsaufwand den du immer betreiben musst wenn du 
den Quelltext liest. Das ist wie bei Schülern in der Schule. Wenn die in 
Physik gleich mit Buchstaben anfangen zu rechnen, dann können die zwar 
mit Buchstaben rechnen, verstehen aber oft nicht mehr den Sinn. Da finde 
ich es auch sehr zielführend erstmal bei der Einführung eine Rechnung 
mit vollständigen Wörtern zu machen.

[S. R. (svenska)]

Gustl B. schrieb:
> Also anlegen vom Projekt, hinzufügen von Dateien, ...

Genau den Teil hab ich bei mir automatisiert (d.h. ein Makefile, welches 
die Tcl-Scripte anlegt und dann mit Vivado automatisch das Projekt 
anlegt und baut). Der Kram lässt sich sonst nicht vernünftig 
versionieren.

Der Rest ist Geschmackssache, gebe ich zu.

[Markus F. (mfro)]

Das ist, was mir an ghdl so gefällt.

Einfach schnell was ausprobieren und in zwei Minuten fertig. .vhd-Datei 
schreiben, Testbench kann gleich mit drin sein,

ghdl -i xxx.vhd
ghdl -m xxx
ghdl -r xxx

Schon fertig.

[Gustl B. (-gb-)]

GRML Führt wohl doch kein Weg an diesem GHDL vorbei ... (-:

S. R. schrieb:
> Der Kram lässt sich sonst nicht vernünftig
> versionieren.

Das ist die nächste eitrige Wunde die ich in Angriff nehmen müsste.

> Der Rest ist Geschmackssache, gebe ich zu.

Mir wurde damals™ von einem E-Technik Professor empfohlen wo immer 
möglich die Sprach Templates zu nutzen die bei ISE/Vivado dabei sind. 
Seine Begründung war, dass die getestet sind und sicher funktionieren.
Das macht aber eben das Schreiben noch umständlicher wenn man da dauernd 
in der GUI rumklicken und nach Sprachschnipseln suchen muss. Aber ist 
wohl alles Geschmackssache.

[S. R. (svenska)]

Gustl B. schrieb:
> Mir wurde damals™ von einem E-Technik Professor empfohlen wo immer
> möglich die Sprach Templates zu nutzen die bei ISE/Vivado dabei sind.

Das ist auch wahr. Nicht alle möglichen Funktionen werden von den Tools 
zuverlässig aus generischem Code inferiert. Ich erinnere mich an eine 
Seite, die verschiedene Tools mal darauf abgeklopft hat, welcher Code in 
allen Tools korrekt ein Dualported BRAM mit verschiedenen Busbreiten 
erzeugt...

[Strubi (Gast)]

Moin,


Gustl B. schrieb:
> GRML Führt wohl doch kein Weg an diesem GHDL vorbei ... (-:
>

Kaum, wenn du wirklich standardkonform und ohne Einsatz von Dollartools 
arbeiten willst. ISE/Vivado sind diesbezueglich grossartig verstuemmelt.

>
> Mir wurde damals™ von einem E-Technik Professor empfohlen wo immer
> möglich die Sprach Templates zu nutzen die bei ISE/Vivado dabei sind.
> Seine Begründung war, dass die getestet sind und sicher funktionieren.
> Das macht aber eben das Schreiben noch umständlicher wenn man da dauernd
> in der GUI rumklicken und nach Sprachschnipseln suchen muss. Aber ist
> wohl alles Geschmackssache.

Die meisten solcher Projekte kranken an Unmengen von Copy/Paste-Code und 
sind dann meist nicht allzu portabel.

S. R. schrieb:
> Das ist auch wahr. Nicht alle möglichen Funktionen werden von den Tools
> zuverlässig aus generischem Code inferiert. Ich erinnere mich an eine
> Seite, die verschiedene Tools mal darauf abgeklopft hat, welcher Code in
> allen Tools korrekt ein Dualported BRAM mit verschiedenen Busbreiten
> erzeugt...

Die Seite wuerde mich interessieren, insbesondere die Testcases dazu.
Grade bei yosys wieder aktuell.

Die grundsaetzliche Frage ist allerdings, ob man nicht besser eine 
gewisse Inference-Logik ignoriert und nicht lieber versucht, eine 
vendor-unabhaengige Bibliothek fuer gewisse Meta-Primitiven des 
Synthese-Tools zu etablieren (z.B. yosys). Die Legacy-Tools, die dann 
die tolle Inference koennen, fressen das dann immer noch, wenn das 
Primitiven-Modell vorliegt.

In Python laesst sich das recht elegant kapseln, und auch dem 
Synthesetool (yosys) so fuettern, dass es was draus machen kann. 
VHDL/Verilog sind dabei nur noch Transfer/bzw. Verifikationssprachen und 
somit fuers Erstellen von Code aufgrund der schlechten 
Wiederverwertbarkeit und einiger anderer Faktoren weniger relevant 
geworden.

D.h. Python kann die ganze Kette abdecken, vom 'HLS'-Konstrukt wie einer 
Rechenformel (a += x * c0) zum Transfer in die verwendete 
Fixpoint-Arithmetik, weiter in die Ausgabe eines 
Abstrakten-Syntax-Trees, und per pyosys in synthetisierbare Konstrukte 
wie DSP-Slices, Muxer, FFs, usw.

Die grosse Streitfrage zur logischen Schreibweise in klassisch oder 
Yet-Another-HDL wird eh nie verebben - die einen Coder wollen ein 
'Programm' mit 'wait for'-Prozessen, die 74xx-Denke-Fraktion sieht alles 
eher unter dem Aspekt der ereignisbasierten Flipflop-Logik und 
Pipelines.
Fazit ist fuer mich, dass letzteres viel einfacher zu Debuggen  ist.

[S. R. (svenska)]

Strubi schrieb:
> Die Seite wuerde mich interessieren, insbesondere die Testcases dazu.
> Grade bei yosys wieder aktuell.

Das war der Artikel hier:
https://danstrother.com/2010/09/11/inferring-rams-in-fpgas/

Ist schon etwas älter, aber ich habe mich mit FPGAs seit einigen Jahren 
nur sehr am Rande befasst. Hab damit beruflich nicht mehr zu tun.

Strubi schrieb:
> Die grundsaetzliche Frage ist allerdings, ob man nicht besser eine
> gewisse Inference-Logik ignoriert und nicht lieber versucht, eine
> vendor-unabhaengige Bibliothek fuer gewisse Meta-Primitiven des
> Synthese-Tools zu etablieren (z.B. yosys).

Naja, mit den großen Tools kann ich entweder das BRAM direkt 
integrieren, oder eine allgemeine Beschreibung dessen, die das Tool 
hoffentlich in das vorhandene BRAM inferiert.

Da sich die BRAMs verschiedener FPGAs aber unterscheiden, ist die 
allgemeine Beschreibung nicht immer möglich (d.h. das Tool kann nicht 
inferieren, weil die Primitive nicht existiert) und die direkte 
Instanziierung feht mangels Primitive natürlich auch.

Da kann man im Synthesetool auch mit Bibliotheken nur recht wenig dran 
drehen, solange man auf der niedrigen Ebene rumdruckst. Das sind 
Probleme, die man in Assembler hat, und daher sehe ich VHDL/Verilog auf 
der gleichen Ebene wie Assembler in der Software-Welt. Obwohl es 
technisch Hochsprachen sind.

Dass die Inferenz in den Tools auf irgendwelchen 
Pattern-Matching-Algorithmen basiert und daher nur dann ordentlich 
funktioniert, wenn man sich an die passenden Regeln hält (die sich auch 
zwischen den Tools leicht unterscheiden), ist noch eine andere Welt. Da 
würde Yosys maximal einen zusätzlichen Standard schaffen...

[Martin S. (strubi)]

S. R. schrieb:
> Da sich die BRAMs verschiedener FPGAs aber unterscheiden, ist die
> allgemeine Beschreibung nicht immer möglich (d.h. das Tool kann nicht
> inferieren, weil die Primitive nicht existiert) und die direkte
> Instanziierung feht mangels Primitive natürlich auch.

Ich meine erst mal nur den Synthese-Schritt, die '$mem'-Zellen von yosys 
abstrahieren das soweit, sobald ein memory-Prozess erkannt wird. Nur das 
Gerate (wie auch von aus Dans Untersuchungen), was jetzt auf welchem 
FPGA/Toolchain wie umgesetzt wird, will man einfach nicht mehr.
Also konkret in Python-Sprech:

@blackbox
def memory_tdp(a, b, options):
    @inference_rule(yosys)
    def inf():
        # Regel, um abstrakte Memory-Primitive zu verdrahten

    ...

@block
def unit():
    ...
    instance_mem = memory_tdp(port_a, port_b, READ_AFTER_WRITE)

kann gleich eine $mem-Zelle mit der entsprechenden Konfiguration 
inferieren und muss nicht mehr 'pattern matchen'.

Im Mapping-Schritt (auf die eigentliche architekturspezifische 
Primitive) wird's dann knifflig, weil es Unmengen an Faellen gibt, das 
ist fuer den Code-Autor allerding nicht mehr relevant.

S. R. schrieb:
> Da kann man im Synthesetool auch mit Bibliotheken nur recht wenig dran
> drehen, solange man auf der niedrigen Ebene rumdruckst. Das sind
> Probleme, die man in Assembler hat, und daher sehe ich VHDL/Verilog auf
> der gleichen Ebene wie Assembler in der Software-Welt. Obwohl es
> technisch Hochsprachen sind.

Naja, der Unterschied ist nur, dass man in Assembler die maximale 
Kontrolle darueber hat, was ausgefuehrt wird.
Im Synthesefall macht das Tool einfach irgendwas draus, und man muss 
eben 'raten'. Bei Lattice/Xilinx kann man da in ueble Mismatches 
reinstolpern, die bei Xilinx in der HW so gut wie nie glitchen, bei 
Lattice schon (und nicht das gleiche machen wie in der Simulation).

Die Kontrolle hat man dann nur, wenn man die Vendorprimitiven komplett 
manuell (und non-portabel) instanziert.
Wuerde eher die Netzlisten oder die yosys-internal-language mit asm 
vergleichen..

[Christoph Z. (christophz)]

Martin S. schrieb:
> Die Kontrolle hat man dann nur, wenn man die Vendorprimitiven komplett
> manuell (und non-portabel) instanziert.

Darum hatte ich mir einen schönen generischen Wrapper für ein Dual-Port 
RAM geschrieben in VHDL-2008. Nach oben alles schön mit Generics 
configurierbar und nach unten werden dann je nach Technologie, Grösse 
und Breite passende Vendorprimitiven instantiiert.

Am Anfgang steht da genau ein RAM und ein FPGA Typ zur Verfügung, das 
wächst dann mit jedem Projekt und Portierung :-)

[TR.OLL (Gast)]

https://icestudio.io/

[Martin S. (strubi)]

Christoph Z. schrieb:
> Am Anfgang steht da genau ein RAM und ein FPGA Typ zur Verfügung, das
> wächst dann mit jedem Projekt und Portierung :-)

Genau von dieser Komplexitaet will man eigentlich weg. Das kann/soll das 
Synthesetool machen.

[Christoph Z. (christophz)]

Martin S. schrieb:
> Genau von dieser Komplexitaet will man eigentlich weg. Das kann/soll das
> Synthesetool machen.

Ja, natürlich wollen wir davon eigentlich weg. Einer der Themen in 
diesem Thread. Aber da es weder für *verilog noch VHDL eine STL 
(standard template library) vergleichbar zu C++ gibt (oder "Batterien" 
wie bei Python) und die Hersteller sich nicht dafür interessieren, dann 
muss man sich halt (im kleinen) sowas selber bauen.

Leider ist gibt es auch zu wenig Engagement von Anwendern/Firmen Dinge 
als open Source gemeinsam anzupacken. Eine solche HDL STL wäre ja ein 
Kanditat dazu.

Es fühlt sich halt alles an wie bei C. Es ist lösbar mit dieser Sprache 
aber wir sind nicht mehr in den 70ern. Verkette Listen und 
Suchalgorithmen sollte niemand mehr selber nieder schreiben müssen (So 
als Vergleich zu Dualport RAM und FIFOs, alles gut dokumentierte 
Standardsachen aber nicht-trivial im Detail).