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
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. 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. 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
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.
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.
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?
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.
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.
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_Languagehttps://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 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.
... 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!
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.
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.
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 :)
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 :)
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
1
typeresisrane0to10E8
2
units
3
ohm;
4
kohm=1000ohm;
5
endunitsresistance;
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.
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.
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!
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 VHDLundVerilog, 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.
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.
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
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).
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. :-)
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.
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
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:
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)?
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?
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:>
>> 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
1
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
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...)
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?
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.
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.
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.
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.
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.
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.
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.
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...
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!
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...
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.
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. :-)
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.
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.
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.
> 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...
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.
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...
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!
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
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
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
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
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!
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.
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".
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
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.
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.
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.
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.
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.
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...
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.
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...
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:
1
@blackbox
2
def memory_tdp(a, b, options):
3
@inference_rule(yosys)
4
def inf():
5
# Regel, um abstrakte Memory-Primitive zu verdrahten
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..
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 :-)
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.
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).
Thread beobachten
Seitenaufteilung abschalten