mikrocontroller.net

Forum: FPGA, VHDL & Co. Neue IDE und Programmiersprache zur FPGA Programmierung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Leon B. (leonbeier)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
Hallo Zusammen,

mein Kumpel (Informatik Student) und ich (Elektrotechnik Student) haben 
jetzt ein Jahr vorm PC verbracht und suchen Betatester, um die letzten 
Bugs in unserem Programm zu finden.

https://vhdplus.com

Aber erstmal warum:
Ich habe schon mit 17 angefangen FPGAs zu programmieren aber im 
Vergleich zu Mikrocontrollern war das ein schwerer Umstieg.

Hier mal ein paar Sachen die mich gestört haben:
1. Weniger und kompliziertere Tutorials und Dokumentation
2. Kompliziertere IDE (bei mir Quartus): Fehler werden beim 
Programmieren nicht angezeigt, keine Unterstützung beim Programmieren 
und unübersichtlich.
3. Kompliziertere Sprache (bei mir VHDL): Viel Text, anstatt einfach 
eine Klammer zu schreiben und man kann nur if oder case (hauptsächlich) 
benutzen um hier nur meine      Hauptkritikpunkte zu äußern.

Was wir anders machen:
Es gibt schon viele Ansätze und ich habe auch einige (die die kostenlos 
waren und man einfach so runterladen konnte) getestet, allerdings hat 
mich nichts zufrieden gestellt. Entweder man hat eine normale HDL nur 
mit Klammern (z.B. Alchitry) oder man hat C auf den FPGA gezwängt. 
Außerdem finde ich es attraktiv, wenn man direkt eine IDE installieren 
kann und nicht erst alles einrichten muss.

Daher hier einmal das Konzept unserer Sprache:
1. Klammern. Zum Beispiel statt
ENTITY <Name> IS PORT (...); END <Name>;
ARCHITECTURE <Anderer Name> OF <Name> IS ... END <Anderer Name>;
einfach
Component <Name> (...) {...}
2. Datentypen, Operatoren ... aus VHDL und If/Case/For funktionieren wie 
bei VHDL, sodass man für FPGAs optimierten Code schreiben kann.
3. Wenn man keine Lust hat die Statemachines selbst zu machen: Thread { 
} drum schreiben und man kann mit Wait, While, For, Step, If, Case und 
Funktionen programmieren als hätte man mit Thread gerade einen 
Prozessorkern hinzugefügt.
4. Kompatibel mit VHDL: Wenn man VHDL{ } um einen Text schreibt wird 
dieser in der später generierten Datei eingefügt. Somit ist es möglich 
alte VHDL Dateien einfach zu VHDP Dateien zu machen (macht die VHDPlus 
IDE automatisch).

Und zu der IDE:
Wir haben die IDE mit Avalonia komplett (natürlich bis auf Avalonia, 
AvalonEdit oder das Docking System) selbst programmiert und dabei 
maximal auf unsere Anwendung zugeschnitten.

Hier eine Top 10 der Features:
1. Übersichtlichkeit
2. Vorschläge beim Programmieren
3. Live Fehlerliste
4. Autokorrektur (= wird zu <=, Integer i = 0; zu i : Integer := 0; oder 
i ++ zu i := i + 1)
5. Bibliotheken, die auch für mehr als nur einen Hersteller 
funktionieren
6. Informationen wenn man über ein Signal hovert
7. I/Os von Component Instanz automatisch erzeugen und verbinden
8. Kompilationsfenster welches FPGA auswählen und Pin verbinden als 
einzigen Schritt vereint (man kann immer noch auf den Quartus Button 
klicken und andere Einstellungen treffen)
9. Einfachere Simulation mit Vorschau (einfach Signale auswählen, sagen 
wie lang sie einen Wert einnehmen sollen und in ModelSim Simulation 
starten)
10. Eigentlich kein Feature, aber man kann auch nur die VHDL Dateien 
erstellen und dann seinen Xilinx oder Lattice FPGA damit programmieren

Starthilfe:
Wir erstellen unsere eigenen Tutorials, Bibliotheken und Beispiele, aber 
über GitHub ist es möglich auch einfach seine eigenen Bibliotheken und 
Beispiele hinzuzufügen, die dann zur IDE hinzugefügt werden. Mit den 
Tutorials versuchen wir die wichtigsten Sachen abzudecken und wir werden 
auch zeigen was für Beispielprojekte möglich sind.

Warum jetzt also das ganze?
Wir wollen nicht VHDL aus den Büros der vielen Firmen verdrängen. 
Sondern wir möchten den Leuten, die mit FPGAs anfangen wollen oder wie 
ich nicht mit dem aktuellen Angebot zufrieden sind, zeigen was mit FPGAs 
alles möglich ist.

Ich habe schon einigen Leuten die IDE gezeigt und diese damit für FPGAs 
interessiert. Daher würde ich mich sehr freuen, wenn ihr helfen würdet 
unser Programm besser zu machen und damit noch mehr Leute für 
Hardware-Programmierung zu begeistern.

Hier könnt ihr euch das Programm herunterladen:
https://vhdplus.com/docs/getstarted/#install-vhdp-ide
(Alles zur Hardware auf der Seite wird noch überarbeitet)

Vielen Dank an jeden der mithilft und viele Grüße
Hendrik Mennen und Leon Beier

:
Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Leon B. schrieb:
> Wir wollen nicht VHDL aus den Büros der vielen Firmen verdrängen.
> Sondern wir möchten den Leuten, die mit FPGAs anfangen wollen oder wie
> ich nicht mit dem aktuellen Angebot zufrieden sind, zeigen was mit FPGAs
> alles möglich ist.

Arduino für FPGAs ... why not^^

Viel Glück und Erfolg mit eurem Projekt!

Beitrag #5986729 wurde von einem Moderator gelöscht.
Beitrag #5986743 wurde von einem Moderator gelöscht.
Beitrag #5986750 wurde von einem Moderator gelöscht.
Autor: K. L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke, man sollte noch etwas besser verdeutlichen, wo die Vorteile 
sind / sein sollen. Beim ersten Durchsehen, komme ich noch nicht so 
recht dahinter. Die Doku könnte auch noch etwas strukturierter sein.

Sind aber schöne Animationen der PCBs!

Autor: Leon B. (leonbeier)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube zu der IDE hab ich schon genug Features aufgezählt, aber hier 
mal ein Beispiel um den Vorteil der Sprache zu zeigen. Bei VHDL wäre das 
ganze deutlich schwieriger umzusetzen.

Autor: Samuel C. (neoexacun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du auch den daraus generierten VHDL-Code zeigen? Es würde mich 
schon interessieren, was er daraus generiert.

Autor: Thomas W. (goaty)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ziemlich beeindruckend was da auf die Beine gestellt wurde. Mit Website 
und Videos, Platinen. Recht beeindruckend.
Ist das praktisch ein Crosscompiler in eine andere HDL die dann das 
Altera Programm weiterverarbeitet?
Prima, viel Erfolg !

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verrate uns halt einfach mal, was Ihr da gebaut habt! ...ohne dass wir 
uns hier durch 1000 Buzzwords durchkämpfen müssen um zu raten, was es 
ist.

Ein kleiner CPU-Kern, von dem viele zusammen gehängt werden?
Umsetzung in FSMs? Wie?
Ist das taktzyklengenau? Wo sind die Beispiele mit dem erzeugten 
VHDL-Code dazu?

Professionell wechselt niemand die Design-Methodik, weil die IDE als 
super toll beworben wird. Viele hier im Forum machen das professionell. 
Da habt Ihr hier mit der bisherigen Promotion tendenziell das falsche 
Publikum.

Geht mal davon aus, dass Ihr mit (nahezu) 100% Sicherheit  keine neue 
Idee habt und dass Eurer Ansatz wahrscheinlich bereits in irgend einer 
Implementierung mehr oder weniger existiert; nur nicht öffentlich. Dh, 
neu ist nicht Eure Idee, sondern bestenfalls, dass Ihr etwas zur 
Verfügung stellt, dass bisher so niemand zur Verfügung stellt. Und 
diesen Fakt/Umstand kann man Euch gar nicht "wegkopieren/klauen".

Autor: Leon B. (leonbeier)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Thomas W. schrieb:
> Ist das praktisch ein Crosscompiler in eine andere HDL die dann das
> Altera Programm weiterverarbeitet?
Korrekt. Der VHDP code wird dann zu 100% VHDL umgewandelt. Wir haben 
dabei zwei compiler arten, die entweder if oder case benutzen.

Hier mal das Ergebnis von meinem Beispiel da oben:
PROCESS (CLK)  
    VARIABLE i : INTEGER := 0;
    VARIABLE Thread9 : NATURAL range 0 to 5 := 0;
    VARIABLE Thread13 : NATURAL range 0 to 1200007 := 0;
  BEGIN
  IF RISING_EDGE(CLK) THEN
    CASE (Thread9) IS
      WHEN 0 =>
        IF (BTN = '0') THEN
        ELSE
          Thread9 := Thread9 + 1;
        END IF;
      WHEN 1 =>
        i := 0;
        Thread9 := Thread9 + 1;
      WHEN 2 =>
        IF ( i < 8) THEN 
          Thread9 := Thread9 + 1;
        ELSE
          Thread9 := Thread9 + 2;
        END IF;
      WHEN (2+1) =>
        CASE (Thread13) IS
          WHEN 0 =>
            IF (UART_TX_Busy = '1') THEN
            ELSE
              Thread13 := Thread13 + 1;
            END IF;
          WHEN 1 =>
            UART_TX_Data <= myString(i);
            UART_TX_Enable <= '1';
            Thread13 := Thread13 + 1;
          WHEN 2 =>
            IF (UART_TX_Busy = '0') THEN
            ELSE
              Thread13 := Thread13 + 1;
            END IF;
          WHEN 3 =>
            UART_TX_Enable <= '0';
            Thread13 := Thread13 + 1;
          WHEN 4 =>
            IF (UART_TX_Busy = '1') THEN
            ELSE
              Thread13 := Thread13 + 1;
            END IF;
          WHEN 5 to 1200005 =>
            Thread13 := Thread13 + 1;
          WHEN 1200006 =>
            i := i + 1;
            Thread13 := 0;
            Thread9 := 2;
          WHEN others => Thread13 := 0;
        END CASE;
      WHEN 4 =>
        IF (BTN = '1') THEN
        ELSE
          Thread9 := 0;
        END IF;
      WHEN others => Thread9 := 0;
    END CASE;
  END IF;
  END PROCESS;

(Im Moment gibt es mit der öffentlichen Version nen Problem bei "i := 
0;", weil ein fix nach hinten losgegangen ist. Wird aber heute Abend 
geupdated sein)

: Bearbeitet durch User
Autor: D. C. (gnd)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Was ist der Unterschied zu Project Icestorm?

Also meine Meinung dazu ist:
Ich würde es nicht nutzen wollen da der großartige Vorteil von VHDL ist 
ja, dass ich damit im Job punkten kann. Jede neue Syntax würde mich nur 
verwirren.

Autor: Leon B. (leonbeier)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Also ich hab die Erfahrung gemacht, dass Leute, die bisher nur mit 
Mikrocontrollern gearbeitet haben, mit VHDL zunächst nicht zurecht 
kommen und daher nicht umsteigen. Bei unserer Sprache konnten diese 
jedoch innerhalb von ner viertel Stunde ihre ersten Projekte realisieren 
und waren interessiert an mehr FPGA programmierung.
Da VHDP sehr nah an VHDL ist (bis auf die Sache mit Thread), wird es 
deutlich einfacher sein auf VHDL im Beruf umzusteigen. Also besser man 
programmiert mit VHDP als gar keine FPGAs.

Und zu Project Icestorm: Wir haben nicht den gesamten Kompiliervorgang 
nachgebaut für einen Hersteller sondern erzeugen VHDL Dateien, die dann 
mit den vorhandenen Compilern der unterschiedlichen Hersteller 
kompiliert werden.

: Bearbeitet durch User
Autor: Gerd E. (robberknight)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Leon B. schrieb:
> Korrekt. Der VHDP code wird dann zu 100% VHDL umgewandelt.

ok, sagen wir jetzt mal der Nutzer hat einen Fehler in seinem Code. Also 
nicht einen einfachen Syntaxfehler wie eine vergessene Klammer, sondern 
etwas deutlich komplexeres, bei dem auch das Quartus/Vivado/... erst 
nach einer Weile aussteigt.

Das Quartus/Vivado/... nennt Datei + Zeile in dem das Problem auftritt, 
aber natürlich Datei + Zeile von dem generierten VHDL, nicht Datei + 
Zeile von dem, was der Nutzer geschrieben hat.

Wie geht Ihr damit um?

Muss der Nutzer dann in dem generierten Code rumstochern und raten, an 
welcher Stelle in seinem VHDP das ist?

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Muss der Nutzer dann in dem generierten Code rumstochern und raten, an
> welcher Stelle in seinem VHDP das ist?

Also wir nehmen immer die Zeile aus der VHDL Datei und suchen nach dem 
Text in der VHDP Datei. In der meisten Fällen wird so die richtige VHDP 
Zeile gefunden.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
> Also wir nehmen immer die Zeile aus der VHDL Datei und suchen nach dem
> Text in der VHDP Datei. In der meisten Fällen wird so die richtige VHDP
> Zeile gefunden.

Und in den nicht meisten Fällen wird Eure Anfänger-Zielgruppe dann 
maximal verwirrt, vor allem wenn die falsche Zeile gefunden wurde...

Könntet Ihr Euch nicht beim Generieren des VHDL merken, zumindest aus 
welchem Zeilenbereich des VHDP eine generierte VHDL-Zeile stammt und 
dann das anzeigen?

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Könntet Ihr Euch nicht beim Generieren des VHDL merken, zumindest aus
> welchem Zeilenbereich des VHDP eine generierte VHDL-Zeile stammt und
> dann das anzeigen?

Ja das wäre gut. Kommt auf die To-Do-Liste. Es sollte kein Problem sein 
zu merken wo die einzelnen Abschnitte in die VHDL Datei eingefügt 
werden.

Autor: Gustl B. (-gb-)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Sieht schick aus, ja, aber ... je länger ich mich mit VHDL beschäftige, 
desto mehr bin ich der Meinung, dass das gut ist wie es ist. Das ist 
eben keine Prgrammiersprache, daher finde ich das völlig OK dass es für 
Programmierer erstmal schwer ist. Auch die "Geschwätzigkeit" finde ich 
gut. Wieviel % der Zeit schreibt man denn wirklich Code? Die meiste Zeit 
geht mit Denken drauf. Da stört es mir nicht ab und zu ein paar Worte 
mehr zu tippen.

Ich wünsche Dir viel Erfolg und finde es gut, dass das probiert wird, 
aber ich glaube, dass es schwierig. Und zwar weil es jetzt für den 
üblichen Programmierer einfach aussieht, aber dahinter trotzdem die 
ganze VHDL Komplexität steckt. Der Programmierer muss also weiterhin das 
wissen/lernen, was er für VHDL wissen/lernen müsste. Z. B. dass sich 
Signale und Variablen unterschiedlich verhalten. Sowas kann man dem 
Programmierer nicht abnehmen ausser man verzichtet in der neuen Sprache 
komplett auf einen Teil der in VHDL möglich ist, aber nicht leicht ist.

Ich bin mal gespannt und werde das hier weiter beobachten.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

zu 'yet another HDL IDE' muss man jetzt vielleicht nicht so viel sagen - 
es gibt einfach furchtbar viele Ansaetze. Ok, ich habe verstanden, es 
ist fuer Anfaenger gedacht und man soll damit nicht performen muessen.
Ich finde auch den Ansatz ueber eine (hoehere) Sprache legitim, die in 
eine Transfersprache (VHDL) uebersetzt, sofern man die von 'robbernight' 
geschilderte Backtrace-Problematik im Griff hat. Die erfordert dann im 
Eventuallfall doch detaillierte Kenntnisse der Interna.

Jetzt zum Performen: Wenn ich mich mal in den Studenten versetze, der 
die Anfangsphase ueberwunden hat, und ein komplexes Projekt umsetzen 
soll, ist fast bei jeder IDE mal der Punkt erreicht, wo er mit emacs 
oder vi(m) deutlich schneller ist. Dann gibt es hoechstens noch das 
Argument Navigation: ich moechte z.B. bei einem komplexen Projekt auf 
das fehlerhafte Signal in der Simulation klicken koennen und direkt zum 
betreffenden Prozess springen koennen. Sowas wuerde noch Zeit sparen, 
unter dem Aspekt dass irgendwann das Debugging mehr Zeit kostet als das 
Erstellen von Code. Koennt ihr sowas (angehen) ?

Was generell die Motivation angeht, HDL zu vereinfachen: das ist ansich 
eine prima Idee, wenn das Debuggen einfach vonstatten geht, also nicht 
nur die Backtrace von/in die Transfersprache, sondern auch die 
Fehlersuche in komplexen Projekten. Da habe ich bei dem Ansatz 'VHDP' 
aber noch etwas Angst :-)

Und was ihr definitiv mal machen solltet, ist euch MyHDL zur Gemuete zu 
fuehren. Da steckt sehr viel Hirnschmalz drin, was weitergehende 
Konzepte betrifft (inkl. Simulation und Co-Simulation).

Noch ein Tip: GHDL-Integration und die Co-Simulation damit. Modelsim VPI 
wollt ihr ja vermutlich nicht supporten.

Und ein letzter Tip: Papilio-Community mal anschauen. Die machen bereits 
'Arduino auf FPGA' seit Jahren, und haben echte Plug-on-Boards anstatt 
Renderings.

Das grosse Problem ist immer der Transfer: irgendwann kommt 'TDD' (test 
driven development) und kontinuierliche Integration ins Spiel. Dann 
kommt die Frage nach Wiederverwertbarkeit des geschriebenen 
Quell(!)-Code, sprich, ist die Konversion VHDP->VHDL so nutzbar 
(OpenSource?) dass man sie auf einem beliebigen Server ausfuehren kann ?

Autor: Mac G. (macgyver0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sowas in der Art gibts ja mit PSHDL:
http://pshdl.org

schon seit langem.
Hat aber kaum jemand genutzt soweit ich weiss.

Was etwas mehr genutzt wird ist MyHDL.
Gibts da abgesehen von der anderen Syntax irgendwelche nennenswerten 
Unterschiede?

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Wenn ich mich mal in den Studenten versetze, der
> die Anfangsphase ueberwunden hat, und ein komplexes Projekt umsetzen
> soll, ist fast bei jeder IDE mal der Punkt erreicht, wo er mit emacs
> oder vi(m) deutlich schneller ist.

Stimmt, aber da habe ich dann keine Fehlermeldungen (oder geht das?). 
Wenn ich im Vivado Editor editiere sehe ich die sofort. Aber ich 
verwende auch einen anderen Editor weil der in Vivado einfach extrem 
grausam schlimm ist.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Stimmt, aber da habe ich dann keine Fehlermeldungen (oder geht das?).

Kommt auf dein Simulations-Backend an, aber mit GHDL geht das, gibt 
Plugins fuer emacs und vim.
Die vim-Puristen, die Code eh nur noch mit 'Y', 'P' und 'cw'-Kommandos 
schreiben, hauen typischerweise ein ':make' rein, und steppen dann mit 
'*' durch den Code.
Aber wir waren ja bei der IDE. Da ist die Frage, was der Anfaenger 
macht, wenn das Simulations-Backend z.B. waehrend der Laufzeit ein 'out 
of bounds' schmeisst, wie es z.B. bei to_integer() passieren kann. Wie 
findet er die passende Zeile? Die laxe HDL-Verarbeitung der X-Tools 
lassen einem das teils durchgehen, synthetisieren auch korrekt, aber das 
ist leider kein 'Standard'.

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Der Programmierer muss also weiterhin das
> wissen/lernen, was er für VHDL wissen/lernen müsste. Z. B. dass sich
> Signale und Variablen unterschiedlich verhalten. Sowas kann man dem
> Programmierer nicht abnehmen ausser man verzichtet in der neuen Sprache
> komplett auf einen Teil der in VHDL möglich ist, aber nicht leicht ist.
Das nimmt zwar die Sprache dem Programmierer nicht ab, aber wir 
versuchen z.B. durch Autokorrektur von = zu <=/:= das Programmieren 
einfacher zu machen.
Dass z.B. Variablen sofort gesetzt werden und Signale erst zum neuen 
Zyklus, muss man halt trotzdem lernen.

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
> Autokorrektur

Das ist tatsächlich ein Punkt den ich schon echt lange in vielen IDEs 
vermisse. Wenn die IDE einen Syntaxfehler finden kann, dann soll sie den 
bitte auch gleich ausbessern. Gerne in einer anderen Farbe und mit einer 
fetten Meldung und auch gerne nicht als Default, aber ich möchte so ein 
Feature gerne nutzen können.

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Dann gibt es hoechstens noch das
> Argument Navigation: ich moechte z.B. bei einem komplexen Projekt auf
> das fehlerhafte Signal in der Simulation klicken koennen und direkt zum
> betreffenden Prozess springen koennen. Sowas wuerde noch Zeit sparen,
> unter dem Aspekt dass irgendwann das Debugging mehr Zeit kostet als das
> Erstellen von Code. Koennt ihr sowas (angehen) ?
Das wäre durchaus möglich. Das Simulationstool kann zwar noch nicht so 
viel, aber wenn man GHDL integriert ist das durchaus sinnvoll.

> Und was ihr definitiv mal machen solltet, ist euch MyHDL zur Gemuete zu
> fuehren. Da steckt sehr viel Hirnschmalz drin, was weitergehende
> Konzepte betrifft (inkl. Simulation und Co-Simulation).
Ich würde sagen bei MyHDL ist das Problem, dass Python ebenfalls keine 
Sprache für FPGAs ist und wenn man dann später VHDL programmieren muss 
bringt einem das auch nichts.
Sind bei MyHDL auch delays... möglich?

> Noch ein Tip: GHDL-Integration und die Co-Simulation damit. Modelsim VPI
> wollt ihr ja vermutlich nicht supporten.
Das ist wohl wahr, aber ModelSim war erstmal das einfachste.

> Und ein letzter Tip: Papilio-Community mal anschauen. Die machen bereits
> 'Arduino auf FPGA' seit Jahren, und haben echte Plug-on-Boards anstatt
> Renderings.
Bei den Boards sind wir gerade noch dran und da könnt ihr euch auch auf 
interessante neue Entwicklungsboards freuen.

> Das grosse Problem ist immer der Transfer: irgendwann kommt 'TDD' (test
> driven development) und kontinuierliche Integration ins Spiel. Dann
> kommt die Frage nach Wiederverwertbarkeit des geschriebenen
> Quell(!)-Code, sprich, ist die Konversion VHDP->VHDL so nutzbar
> (OpenSource?) dass man sie auf einem beliebigen Server ausfuehren kann ?
Wir haben vor den Compiler VHDP->VHDL Open Source zu machen.

: Bearbeitet durch User
Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
> Ich würde sagen bei MyHDL ist das Problem, dass Python ebenfalls keine
> Sprache für FPGAs ist und wenn man dann später VHDL programmieren muss
> bringt einem das auch nichts.

Das Problem hat generell jede Sprache, mit der man programmieren kann, 
vermutlich wird man auch mit Eurem Konstrukt etwas schreiben koennen, 
was nicht synthetisiert. Wie ja auch VHDL. Da muss man einfach durch, 
aber da gibt es ja auch Design-Rule-Checks.
Wichtig an der Geschichte ist, dass man das ereignis-getriebene Prinzip 
der Sprache als 'Beschreibungssprache' (das sorgt fuer endlose 
Diskussionen, also bitte hier nicht weiterfuehren :-) ) bewahrt, das 
aeussert sich spaetestens bei der Umsetzung einer Simulation. Das ist 
mir bei Euch noch nicht ganz klar, ich lese da 'Thread', das koennten 
einige HDL-Puristen schon als gefaehrliche Abstraktion sehen. (Ich als 
SW-getriebener weniger).

> Sind bei MyHDL auch delays... möglich?

Was meinst du fuer Delays? Fuer gate-level-Kram ist MyHDL nicht gedacht.
Aber natuerlich kannst du ein Signal-Delay modellieren und die 
VITAL-Libs bemuehen. Um die Handarbeit kommst du aber nicht herum.

Ich kann nur sagen, dass sich mit MyHDL sehr produktiv komplexe SoC 
entwickeln lassen. Was dann hinten rauskommt, muss halt erneut 
verifiziert werden (entweder Verilog oder VHDL), da muss man auch durch, 
aber wenn der Workflow kein Wirrwarr ist, ist alles gut. Das waere so 
meine Messlatte...

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich meine wenn man bei uns Wait(...) einfügt, dann wird dementsprechend 
(synthetisierbar) gewartet.

Sieht dann als VHDL so aus:
WHEN 5 to 1200005 =>
   Thread13 := Thread13 + 1;
WHEN 1200006 =>

Und unser Blink Programm ist dann:
LED <= '1';
Wait(1000000);
LED <= '0';
Wait(1000000);

Wie würde bei MyHDL ein Blinkprogramm aussehen?

: Bearbeitet durch User
Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine erster Eindruck: Pseudo-VHDL Gestammel für Tippfaule; das kein 
einziges Fpga-Implementierungs-Problem löst, weil die Beherrschung der 
HDL-Syntax nur die Spitze des Eisberges ist.

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fpga K. schrieb:
> Meine erster Eindruck: Pseudo-VHDL Gestammel für Tippfaule; das kein
> einziges Fpga-Implementierungs-Problem löst, weil die Beherrschung der
> HDL-Syntax nur die Spitze des Eisberges ist.
Welche Probleme hättest du denn gerne gelöst?

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
> Ich meine wenn man bei uns Wait(...) einfügt, dann wird
> dementsprechend
> (synthetisierbar) gewartet.
>
> Sieht dann als VHDL so aus:WHEN 5 to 1200005 =>
>    Thread13 := Thread13 + 1;
> WHEN 1200006 =>
>

Das impliziert einen Zaehler und eine Clock.
Du fuehrst also ein neues Paradigma ein, durchaus interessant vom 
SW-Standpunkt.

> Und unser Blink Programm ist dann:LED <= '1';
> Wait(1000000);
> LED <= '0';
> Wait(1000000);
>
> Wie würde bei MyHDL ein Blinkprogramm aussehen?

Aussehen koennte es so, wenn es dieses Paradigma unterstuetzen wuerde:
  @instance_new_paradigm(clk, counter)
  def blink():
    yield delay(100)
    led.next = 1
    yield delay(100)
    led.next = 0

Tut es aber von Haus aus nicht, man muss es explizit, wie in Verilog 
oder VHDL mit clk/counter-Sensitivitaet hinschreiben. Aber du kannst dir 
deinen Generator 'instance_new_paradigm' entsprechend definieren. Frage 
ist, ob es Sinn macht.

Es ist generell einfach recht schwer, eingefleischte Hardwerker von 
solchen Paradigmenwechseln zu ueberzeugen, und man sollte sicher auch 
damit aufpassen, die software-orientierten Einsteiger auf die falsche 
Faehrte zu schicken.

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Es ist generell einfach recht schwer, eingefleischte Hardwerker von
> solchen Paradigmenwechseln zu ueberzeugen,
Das ist wohl wahr.

> und man sollte sicher auch
> damit aufpassen, die software-orientierten Einsteiger auf die falsche
> Faehrte zu schicken.
Ich sehe kein Problem darin software-orientierten Einsteiger mit unserer 
Sprache programmieren zu lassen, solang sie damit klarkommen. So können 
diese ebenfalls von den Vorteilen eines FPGAs in ihren Projekten 
profitieren.

Autor: Gustl B. (-gb-)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Leon B. schrieb:
> solang sie damit klarkommen.

Es geht darum zu versprechen dass es für Programmierer einfach ist. Das 
impliziert quasi, dass man nicht in Hardware denken können muss. Aber in 
der Realität braucht man dann vermutlich (zumindest wenn man etwas 
komplexere Dinge beschreibt) doch die ganze Hardwaredenke die man auch 
mit VHDL braucht.

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
>
> Sind bei MyHDL auch delays... möglich?
>
Delays sind generell nicht synthetisierbar, also nur in der Simulation 
nutzbar.

> Wir haben vor den Compiler VHDP->VHDL Open Source zu machen.
Ich dachte, ihr habt auch eine IDE dazu gebastelt?

An der Sprache kann ich (auf den ersten Blick) nichts interessantes 
entdecken.
Schaut Euch mal Chisel an. Damit wird der RISC-V gemacht.

Wenn ein Design gross genug ist dann interssiert niemanden mehr ob man = 
statt := getippt hat. Es passiert eigentlich nicht mehr.

Wie siehts denn mit Constraints und Interfaces aus?

/regards

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Sieht schick aus, ja, aber ... je länger ich mich mit
> VHDL beschäftige, desto mehr bin ich der Meinung, dass
> das gut ist wie es ist.

Das hat zwei Gründe:

Einerseits steigt mit deiner Erfahrung auch dein Hintergrundwissen um 
gewisse Designentscheidungen und deren Vorteile und Beschränkungen. Wenn 
man ein bekanntes Konzept von Grund auf hochzieht, landet man oft genug 
bei bekannten Lösungen.

Andererseits hast du bereits so viel Zeit investiert, dass du einer 
Änderung grundsätzlich ablehnend gegenüberstehst - weil du bereits eine 
gebrauchbar funktionierende Lösung kennst. Das ist Psychologie, mit 
steigendem Alter kommt überlicherweise Konservativität. "Ham'wa schon 
imma so jemacht."

> Das ist eben keine Prgrammiersprache, daher finde ich
> das völlig OK dass es für Programmierer erstmal schwer ist.

Worin liegt die Schwierigkeit?
An der Beschreibungssprache oder der Beschreibungsdenkweise?

> Auch die "Geschwätzigkeit" finde ich gut.
> Wieviel % der Zeit schreibt man denn wirklich Code?

Je mehr man an Boilerplate schreiben muss, desto weniger experimentiert 
man, desto weniger probiert man aus, desto weniger optimiert man.

Das magst du jetzt sicherlich als Vorteil auslegen, aber es ist keiner. 
Wenn ich für "mal eben ein Konzept ausprobieren" einen Tag opfern muss, 
dann mache ich das eben nicht, wenn ich mir davon keinen immensen 
Vorteil verspreche.

> Die meiste Zeit geht mit Denken drauf.
> Da stört es mir nicht ab und zu ein paar Worte mehr zu tippen.

Das ist genau dann der Fall, wenn du zuverlässig fehlerarm arbeiten 
kannst. Das setzt viel Wissen, viel Erfahrung und vor allem ein gutes 
Verständnis des Problems voraus.

Wenn ich ein Problem wirklich verstanden habe, dann kann ich eine 
komplette OOP-Hierarchie in C/C++ hochziehen, ausprogrammieren und bis 
auf ein paar Tippfehler funktioniert das wunderbar im ersten Versuch.

Dummerweise sind die Probleme fast nie so perfekt wie die Modellierung, 
die Programmierung ist fast nie auf Anhieb fehlerfrei und obwohl man am 
Ende eine funktionierende Lösung hinbekommt, ist das Ergebnis 
suboptimal.

Und genau da sehe ich das Problem.

> Der Programmierer muss also weiterhin das wissen/lernen,
> was er für VHDL wissen/lernen müsste. Z. B. dass sich
> Signale und Variablen unterschiedlich verhalten.

Wozu muss ich das wissen? Ich muss die spezifischen Eigenheiten von 
Javascript nicht kennen, wenn ich C programmiere. Auch dann nicht, wenn 
ich einen C-nach-Javascript-Compiler benutze, um das Ergebnis im Browser 
auszuführen.

Warum soll ich nicht einfach eine prozedurale Funktion hinschreiben 
können, streng sequentiell mit if, for und while (optional mit 
Timing-Constraints), und das Tool synthetisiert mir daraus eine passende 
FSM?

> Sowas kann man dem Programmierer nicht abnehmen ausser man
> verzichtet in der neuen Sprache komplett auf einen Teil der
> in VHDL möglich ist, aber nicht leicht ist.

Über 70% von VHDL sind für die FPGA-Entwicklung ohnehin "möglich aber 
nutzlos", weil entweder nicht synthetisierbar oder praktisch 
unbrauchbar. Zum Beispiel hätte ich gerne die Möglichkeit, eine binäre 
Datei komplexen Formats einzulesen und im VHDL-Code direkt daraus ein 
passendes ROM zu generieren. Oder vernünftig Arithmetik zu beschreiben, 
gegen die man die Testsuite schmeißen könnte.

Mein ROM baue ich mit einem Perl-Script aus der Binärdatei, welches die 
VHDL-Datei erzeugt. Das ist wesentlich einfacher, als es in VHDL selbst 
zu machen (oder in Verilog - anderes Format und genauso unbrauchbar). 
Lässt sich außerdem nur schwierig automatisieren, wenn man im Rahmen der 
vorhandenen Tools bleiben will.

Also baut man Meta-Tools, um die Beschränkungen der Sprachen zu umgehen. 
Dann kann man die Features aber auch gleich aus der Sprache 
rausschmeißen und ein ordentliches Interface anbieten...

Nee, das vorhandene Tooling ist nicht schön. Man kann sich damit gut 
arrangieren, aber es macht keinen Spaß. Verilog ist auch nicht besser.

Ob eine IDE mit Autokorrektur die Lösung ist, bezweifle ich. Aber eine 
gebrauchbare Programmiersprache, die mich meine Lösungen so hinschreiben 
lässt, wie ich sie denke, das wäre mal schön. Und nein, ich meine damit 
nicht, dass mir VHDL vorher vorschreibt, wie ich sie zu denken habe.

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Delays sind generell nicht synthetisierbar, also nur in der Simulation
> nutzbar.
Bei uns schon

> An der Sprache kann ich (auf den ersten Blick) nichts interessantes
> entdecken.
Für mich ist das interessant

> Wie siehts denn mit Constraints und Interfaces aus?
Im Moment ist der Compiler noch in unsere IDE eingebettet. Interfaces 
würden folgen.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Delays sind generell nicht synthetisierbar,
> also nur in der Simulation nutzbar.

Delays lassen sich immer dann als FSM synthetisieren, wenn man eine 
Zeitbasis (Takt) hat.

Leon B. schrieb:
> Im Moment ist der Compiler noch in unsere IDE eingebettet.

Damit ist die Sprache aus meiner Sicht vollständig ungeeignet, denn sie 
lässt sich nicht sinnvoll unabhängig von der IDE benutzen. Das erschwert 
Automatisierung, Integration in eine CI/CD-Infrastruktur oder auch 
schlicht die Nutzung eines Build-Servers mit ordentlicher 
Versionskontrolle.

Ja, das kann man alles irgendwie in einer IDE hinbekommen. Praktisch 
will ich aber lieber etwas haben, wo man vorne "make" draufschmeißen 
kann und hinten ein Ergebnis rausfällt (auch, wenn das vermutlich nur 
ein ferngesteuertes Vivado ist).

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Es geht darum zu versprechen dass es für Programmierer einfach ist. Das
> impliziert quasi, dass man nicht in Hardware denken können muss. Aber in
> der Realität braucht man dann vermutlich (zumindest wenn man etwas
> komplexere Dinge beschreibt) doch die ganze Hardwaredenke die man auch
> mit VHDL braucht.
Richtig, aber die Hardwaredenke entwickelt man ehr, wenn man erstmal 
angefangen hat und dann versucht komplexere Dinge umzusetzen, als wenn 
man von VHDL abgeschreckt wird und bei C bleibt.

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Damit ist die Sprache aus meiner Sicht vollständig ungeeignet, denn sie
> lässt sich nicht sinnvoll unabhängig von der IDE benutzen. Das erschwert
> Automatisierung, Integration in eine CI/CD-Infrastruktur oder auch
> schlicht die Nutzung eines Build-Servers mit ordentlicher
> Versionskontrolle.
Die IDE ist erstmal dafür da, dass man anfangen kann mit unserer Sprache 
zu programmieren und bevor jemand auf die Idee kommt Build-Server 
einzurichten werden die Interfaces auch verfügbar sein. Wir haben ja 
gerade erst angefangen.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde, eine IDE sollte ein ordentlicher Editor mit Anpassungen für 
eine bestimmte Programmiersprache sein, nicht eine Voraussetzung dafür.

Anders gesagt: Beliebiger Texteditor und beliebiges Make sollten 
genügen, um damit arbeiten zu können. Die IDE ist dann dafür da, um 
gut damit arbeiten zu können.

Wenn ihr eure Sprache an eine IDE knotet, dazu noch mit einem eigenen 
"Interface", um die IDE fernzusteuern, dann macht ihr es für potentielle 
Nutzer schwierig, die Sprache sinnvoll in einen anderen Workflow 
einzubinden.

Mein Tipp: Baut das Interface lieber andersrum. Der Compiler ist ein 
Tool, welches eine Schnittstelle für eure IDE anbietet.

Und aus Sicht der Wirtschaft: Wenn ihr das verkaufen wolltet, was wäre 
dann das Produkt? Die IDE, die Programmiersprache, oder der Compiler?

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Mein Tipp: Baut das Interface lieber andersrum. Der Compiler ist ein
> Tool, welches eine Schnittstelle für eure IDE anbietet.
Ja das haben wir vor und wenn der Compiler funktioniert ist das dann 
auch kein großes Problem mehr. Letztendlich gibt unsere IDE 
grundsätzlich auch nur dem Compiler die VHDP Datei und der Spuckt VHDL 
Datei und Fehler aus.

> Und aus Sicht der Wirtschaft: Wenn ihr das verkaufen wolltet, was wäre
> dann das Produkt? Die IDE, die Programmiersprache, oder der Compiler?
Wir haben vor den Compiler Open Source zu machen.
Bei der IDE haben wir dann vor einmal die IDE mit Unterstützung unserer 
Hardware kostenlos anzubieten.
Möchte man uns unterstützen, haben wir vor noch eine IDE mit 
Unterstützung von anderen FPGAs (Intel, Xilinx oder Lattice) 
kostenpflichtig anzubieten.
Möchte man die IDE trotzdem kostenlos nutzen kann man natürlich auch die 
VHDL Dateien manuell kompilieren.

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
> Fpga K. schrieb:
>> Meine erster Eindruck: Pseudo-VHDL Gestammel für Tippfaule; das kein
>> einziges Fpga-Implementierungs-Problem löst, weil die Beherrschung der
>> HDL-Syntax nur die Spitze des Eisberges ist.
> Welche Probleme hättest du denn gerne gelöst?

Timing violations
Manuelles Setzen von false path constraints und multicycle paths
Dumm vom tool platzierte dcms
Überschiessendes Wegoptimieren bei chipscopeeinsatz
Direkten Zugriff auf die carry chain
Handling vom DCM locl lost im Betrieb
...
...

Autor: K. L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
> Ich glaube zu der IDE hab ich schon genug Features aufgezählt, aber hier
> mal ein Beispiel um den Vorteil der Sprache zu zeigen. Bei VHDL wäre das
> ganze deutlich schwieriger umzusetzen.

Die für mich wichtigte Frage wäre, was dabei am Ende raus kommt. Aus dem 
Konstrukt einen Ablauf zu machen, ist ja so umständlich nicht ...

Autor: Martin S. (strubi)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Schaut Euch mal Chisel an. Damit wird der RISC-V gemacht.

Schon mal mit Chisel wirklich produktiv gearbeitet?
Das mag eine akademisch 'schicke' Loesung sein, fuer die, die Scala 
erfunden haben. Von der Engineering-Seite her haette ich da leider nur 
vernichtende Kritik uebrig.

Leon B. schrieb:
> Ich sehe kein Problem darin software-orientierten Einsteiger mit unserer
> Sprache programmieren zu lassen, solang sie damit klarkommen. So können
> diese ebenfalls von den Vorteilen eines FPGAs in ihren Projekten
> profitieren.

Es wird dann allenfalls zum Problem, wenn sie in einem Industrie-Projekt 
mit verschiedenen Interfaces klarkommen muessen, Komponenten von anderen 
Teams integrieren muessen, gegentesten, usw.
Da muss die gleiche Sprache gesprochen werden, sonst wird die 
anfaengliche Zeitersparnis zu einer riesigen Bremse. Kennt man schon in 
der SW-Entwicklung beim Thema: Bringe einen Arduino-Prototypen zu einem 
fertigen Produkt.

So ich das richtig verstehe, ist euer Konzept ein kleines (abgegrenztes) 
Bastel-Oekosystem zu schaffen. Da muesst ihr nur gegen einige Anbieter 
anstinken, die mehr Resourcen draufschmeissen koennen, wenn sie riechen, 
dass euer Konzept greift.

S. R. schrieb:
> Anders gesagt: Beliebiger Texteditor und beliebiges Make sollten
> genügen, um damit arbeiten zu können. Die IDE ist dann dafür da, um
> gut damit arbeiten zu können.

Da muss man dann allerdings gegen Sigasi anstinken. Das ist noch mal ne 
andere Nummer..
Ansonsten bin ich von 'make all' nicht mehr abzubringen, wozu hat man 
denn einen Computer :-)
Naja, ich lasse mich mal ueberraschen, vielleicht zeigt sich ja mal ein 
in VHDP geschriebener Risc-V am Horizont. Wenn ihr damit das Konzept des 
"Instant SoC" (fpga-cores.com) in eurer Sprache umgesetzt bekommt, dann 
wird's auch fuer fortgeschrittene Entwicklung interessant.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Schaut Euch mal Chisel an. Damit wird der RISC-V gemacht.

der?

RISC-V ist eine Befehlssatz-Familie.

Es gibt verschiedene Kerne die RISC-V implementieren. Einige davon, wie 
z.B. BOOM und Rocket, verwenden Chisel. Es gibt aber mittlerweile 
ziemlich viele RISC-V-Kerne, und viele davon verwenden eine andere HDL.

: Bearbeitet durch User
Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Schon mal mit Chisel wirklich produktiv gearbeitet?
> Das mag eine akademisch 'schicke' Loesung sein, fuer die, die Scala
> erfunden haben. Von der Engineering-Seite her haette ich da leider nur
> vernichtende Kritik uebrig.

Du hast das Problem der Integration von Komponenten in anderen Sprachen 
zumindest im Zusammenhang mit dem VHDP genannt, bei Chisel dürfte das 
auch relevant sein.

Aber was für Kritik sonst?

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> So ich das richtig verstehe, ist euer Konzept ein kleines (abgegrenztes)
> Bastel-Oekosystem zu schaffen.
Also, da VHDP Dateien zu VHDL Dateien und VHDL Dateien zu VHDP Dateien 
konvertiert werden können, ist unser Ökosystem jedenfalls nicht komplett 
abgegrenzt

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Andererseits hast du bereits so viel Zeit investiert, dass du einer
> Änderung grundsätzlich ablehnend gegenüberstehst - weil du bereits eine
> gebrauchbar funktionierende Lösung kennst. Das ist Psychologie, mit
> steigendem Alter kommt überlicherweise Konservativität. "Ham'wa schon
> imma so jemacht."

Genau, hier in Bayern gibt es da die 3 klassischen Ausreden inklusive 
der von dir genannten:
1. Das haben wir schon immer so gemacht
2. Wo kommen wir denn da hin (wenn das jeder machen würde)?
3. Was sagen denn da die Leute?

Aber zu deiner Aussage, ja, das ist Psychologie und ich möchte an der 
Stelle das Buch "Judgment under Uncertainty: Heuristics and Biases" 
empfehlen. Das ist sogar völlig logisch, dass man mit zunehmender 
Erfahrung skeptischer gegenüber Neuem wird. Denn: Wie 
Wahrscheinlichkeit, dass da etwas ist was besser ist als das was man in 
der langen Zeit schon gesehen hat wird immer geringer. Das stimmt heute 
natürlich nicht mehr ganz, aber das ist noch in uns Menschen drinnen. 
Wenn man durch die Natur draussen geht Dinge anguckt dann stimmt das. 
Ich merke das auch bei mir mit der VHDL, dass ich oft ähnliche Dinge 
baue weil sie gut funktionieren.
Der Nachteil ist, dass man da in einem lokalen Minimum gefangen bleibt 
und das globale Minimum nicht mehr suchen geht. Ist eben eine Abwägung 
wie zufrieden man ist und wie groß der Aufwand wird.

S. R. schrieb:
> An der Beschreibungssprache oder der Beschreibungsdenkweise?

An der Denkweise.

S. R. schrieb:
> Je mehr man an Boilerplate schreiben muss, desto weniger experimentiert
> man, desto weniger probiert man aus, desto weniger optimiert man.

Stimmt. Aber so schlimm ist VHDL da auch nicht. Um neue Dinge 
auszuprobieren verwende ich nur dann VHDL wenn das wirklich leicht zu 
simulieren ist oder direkt mit der Hardware zu tun hat. Sonst verwende 
ich Python, da kann man sich Dinge schön plotten lassen und so.

S. R. schrieb:
> Das ist genau dann der Fall, wenn du zuverlässig fehlerarm arbeiten
> kannst. Das setzt viel Wissen, viel Erfahrung und vor allem ein gutes
> Verständnis des Problems voraus.

Ja, stimmt, aber auch wenn ich noch viele Fehler mache und viel ändern 
muss, dann ist der Schreibaufwand immer noch recht gering gegenüber dem 
Denkaufwnad oder der Zeit die man mit "Internetrecherche" verbringt.

S. R. schrieb:
> Wozu muss ich das wissen? Ich muss die spezifischen Eigenheiten von
> Javascript nicht kennen, wenn ich C programmiere. Auch dann nicht, wenn
> ich einen C-nach-Javascript-Compiler benutze, um das Ergebnis im Browser
> auszuführen.
>
> Warum soll ich nicht einfach eine prozedurale Funktion hinschreiben
> können, streng sequentiell mit if, for und while (optional mit
> Timing-Constraints), und das Tool synthetisiert mir daraus eine passende
> FSM?

Das Beispiel ist jetzt nicht wirklich toll weil beides 
Programmiersprachen sind.
Aber gut, wenn diese neue Sprache das wirklich kann dann passt alles.
Oft ist es eben so, dass eine Sprache die noch mehr wegabstrahiert zwar 
mehr fertige schicke Funktionen mitbringt, aber auf der niedrigeren 
Ebene Dinge weglässt. Wenn man auch einem uC in ASM schreibt kann man 
genau die CPU Zyklen zählen und recht genaue Timings schaffen. Wenn ich 
da jetzt etwas mit Micropython mache ist diese Möglichkeit schon weg. 
Klar gibt es oft die Option das trotzde zu bauen mit ASM in Python oder 
C, aber die Hochsprache selbst bietet es nicht an. Ja, vielleicht ist 
tatsächlich eine Kombination aus mehreren Sprachen sinnvoll weil keine 
alles kann von bequem bis zu jedes Bit einzeln kennen.

S. R. schrieb:
> Aber eine
> gebrauchbare Programmiersprache, die mich meine Lösungen so hinschreiben
> lässt, wie ich sie denke, das wäre mal schön.

In der Tat.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
>> Und aus Sicht der Wirtschaft: Wenn ihr das verkaufen wolltet, was wäre
>> dann das Produkt? Die IDE, die Programmiersprache, oder der Compiler?
> Wir haben vor den Compiler Open Source zu machen.
> Bei der IDE haben wir dann vor einmal die IDE mit Unterstützung unserer
> Hardware kostenlos anzubieten.
> Möchte man uns unterstützen, haben wir vor noch eine IDE mit
> Unterstützung von anderen FPGAs (Intel, Xilinx oder Lattice)
> kostenpflichtig anzubieten.
> Möchte man die IDE trotzdem kostenlos nutzen kann man natürlich auch die
> VHDL Dateien manuell kompilieren.

Mir ging es darum, dass ihr euch darüber klar werdet, was euer 
eigentliches Produkt ist und was nur schmuckes Beiwerk ist. Ich will 
euch nicht einreden, dass ihr irgendwas verkaufen sollt. ;-)

Ich lese da jetzt folgendes raus:
- Die Sprache ist nebensächlich und der Compiler ist frei verfügbar.
- Die IDE ist kommerziell, mit beschränkter Version für eigene Hardware.
- Man kann die IDE aber auch einfach so kostenlos nutzen.

Das heißt, ihr habt eigentlich kein Produkt und damit nichts, worauf ihr 
euch konzentrieren wollt. Für ein Hobbyprojekt spielt das keine Rolle, 
aber so wird niemand euer Projekt für mehr als Spielerei benutzen 
wollen.

Seid euch darüber im Klaren, wo eure Arbeitszeit sinnvoll investiert 
ist.

Die Trennung zwischen "Programmiersprache" und "Compiler" ist nicht 
immer offensichtlich. Perl 5 ist beispielsweise komplett durch den 
Interpreter definiert, während z.B. Python einen ordentlichen 
Sprachstandard hat. Für Python gibt es darum mehrere Interpreter, wovon 
die Sprache wiederum profitiert. Auf der anderen Seite gibt es genug 
gute IDEs, teilweise mit ordentlichen Schnittstellen.

Gustl B. schrieb:
> Genau, hier in Bayern gibt es da die 3 klassischen Ausreden inklusive
> der von dir genannten:
> 1. Das haben wir schon immer so gemacht
> 2. Wo kommen wir denn da hin (wenn das jeder machen würde)?
> 3. Was sagen denn da die Leute?

Und dein Beitrag war direkt die erste Ausrede, unbegründet. :-)

> Ich merke das auch bei mir mit der VHDL, dass ich oft
> ähnliche Dinge baue weil sie gut funktionieren.

Weil du inzwischen gelernt hast, dass eine bestimmte Variante gut genug 
für deine Bedürfnisse ist. Du explorierst nicht mehr.

Mein Punkt ist, dass VHDL das Explorieren sehr stark erschwert und daher 
alles andere als gut ist. Anders ausgedrückt, es gibt verdammt gute 
Gründe für alternative Sprachen jenseits von VHDL und Verilog - wie es 
auch verdammt gute Gründe für alternative Sprachen jenseits von 
Assembler gibt.

Da ist ein "je länger ich X mache, desto besser finde ich X" absolut 
nicht hilfreich, sondern ein psychologischer Fehlschluss.

> S. R. schrieb:
>> An der Beschreibungssprache oder der Beschreibungsdenkweise?
> An der Denkweise.

Die Denkweise ist anders, unstrittig.
Aber ich glaube, die Schwierigkeit kommt auch durch die Sprache selbst. 
Fängt schon damit an, dass man wesentlich mehr ausdrücken als nutzen 
(synthetisieren) kann.

> S. R. schrieb:
>> Je mehr man an Boilerplate schreiben muss, desto weniger experimentiert
>> man, desto weniger probiert man aus, desto weniger optimiert man.
>
> Stimmt. Aber so schlimm ist VHDL da auch nicht. Um neue Dinge
> auszuprobieren verwende ich nur dann VHDL wenn das wirklich leicht zu
> simulieren ist oder direkt mit der Hardware zu tun hat. Sonst verwende
> ich Python, da kann man sich Dinge schön plotten lassen und so.

"VHDL ist garnicht so schlimm."
"Wenn möglich, nutze ich Python."
Finde den Fehler. ;-)

> S. R. schrieb:
> Oft ist es eben so, dass eine Sprache die noch mehr
> wegabstrahiert zwar mehr fertige schicke Funktionen
> mitbringt, aber auf der niedrigeren Ebene Dinge weglässt.

Das ist ja gerade der Sinn von Hochsprachen. Man abstrahiert weg von den 
ekligen Details auf eine Ebene, mit der man das Problem sinnvoll und mit 
wenig Aufwand lösen kann.

> Wenn man auch einem uC in ASM schreibt kann man genau
> die CPU Zyklen zählen und recht genaue Timings schaffen.

Wenn ich eine FSM in Verilog beschreibe, dann ist die exakte Codierung 
festgelegt. In VHDL kann das der Synthesizer für mich tun, also muss ich 
das eigentlich garnicht selbst festlegen.

Warum sollte das für komplexere Konzepte anders sein?

Ich habe ein paar Sachen in VHDL gemacht und auch ein bisschen in 
Verilog, um das zu vergleichen. Beides ist aus meiner Sicht "so naja".

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
>> Wie siehts denn mit Constraints und Interfaces aus?
> Im Moment ist der Compiler noch in unsere IDE eingebettet. Interfaces
> würden folgen.

Ich meinte da eher nicht das Interfacing der Tools sondern ein 
Äquivalent zu sowas:

https://www.doulos.com/knowhow/sysverilog/tutorial/interfaces/

Leon B. schrieb:
> Andreas H. schrieb:
>> Delays sind generell nicht synthetisierbar, also nur in der Simulation
>> nutzbar.
> Bei uns schon

Cool. Endlich eine Lösung die signal_name <= expression after 1 ps;
Auf einem 10MHz Design implementiert.
Ich habe ja schon immer geahnt dass die Physiker keine Ahnung haben...

S. R. schrieb:
> Andreas H. schrieb:
>> Delays sind generell nicht synthetisierbar,
>> also nur in der Simulation nutzbar.
>
> Delays lassen sich immer dann als FSM synthetisieren, wenn man eine
> Zeitbasis (Takt) hat.

Das ist doch genau das was ich sagte: Generell kann man keine Delays 
synthetisieren.

Martin S. schrieb:
> Andreas H. schrieb:
>> Schaut Euch mal Chisel an. Damit wird der RISC-V gemacht.
>
> Schon mal mit Chisel wirklich produktiv gearbeitet?
> Das mag eine akademisch 'schicke' Loesung sein, fuer die, die Scala
> erfunden haben. Von der Engineering-Seite her haette ich da leider nur
> vernichtende Kritik uebrig.

Hmm, wann habe ich sowas schon mal gehört?
Vor gefühlten 100 Jahren als Designer meinten VHDL ist Müll und kann nie 
das Schematic ersetzen?

/regards

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Das heißt, ihr habt eigentlich kein Produkt und damit nichts, worauf ihr
> euch konzentrieren wollt. Für ein Hobbyprojekt spielt das keine Rolle,
> aber so wird niemand euer Projekt für mehr als Spielerei benutzen
> wollen.

Was wäre denn dein Vorschlag?

Unser Produkt sind unsere Entwicklungsboards, die Plug & Play zusammen 
mit unserer IDE funktionieren werden. Also die passenden Bibliotheken 
werden hinzugefügt, I/Os verbunden ...

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Ich meinte da eher nicht das Interfacing der Tools sondern ein
> Äquivalent zu sowas:
>
> https://www.doulos.com/knowhow/sysverilog/tutorial/interfaces/

Da hat sich zu VHDL nichts geändert. Man hat oben in den Klammern I/Os 
von einem Component und wenn man nicht so viele Signale haben will, kann 
man gerne noch einen Record Type benutzen. Man muss bei uns nur nicht 
überall das Package includen.

: Bearbeitet durch User
Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Da ist ein "je länger ich X mache, desto besser finde ich X" absolut
> nicht hilfreich, sondern ein psychologischer Fehlschluss.

Eben nicht. Wir Menschen haben diese psychologische Eigenart, weil sie 
ein Vorteil ist in der Natur. Es ist besser irgendwann einen 
Optimierungsprozess zu beenden und zufrieden zu sein als weiter Energie 
in die Suche nach etwas Besserem zu stecken das es vielleicht gar nicht 
gibt. Das ist in uns Menschen eingebaut weil es gut und sinnvoll ist.

Ja, es wäre gut wenn Sprachen das Erkunden einfacher machen, ja dann 
wird es einfacher, aber trotzdem hört man irgendwann damit auf, dann 
eben etwas später wenn man noch zufriedener ist und einem dann die noch 
geringere Energie schon zu viel Aufwand ist.

Autor: K. L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
> kann
> man gerne noch einen Record Type benutzen.

... um es hinterher wieder auseinanderzufummeln, wenn man Teile des 
Rcordes woanders verbinden möchte.

Wir haben PER DESIGN CODING STANDARD das Verwenden con Records veboten

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Andreas H. schrieb:
>> Delays lassen sich immer dann als FSM synthetisieren,
>> wenn man eine Zeitbasis (Takt) hat.
> Das ist doch genau das was ich sagte:
> Generell kann man keine Delays synthetisieren.

Missverständnis.
Du schriebst "generell" und meintest "im Allgemeinen".
Ich las "generall" und dachte "grundsätzlich".

Leon B. schrieb:
> Unser Produkt sind unsere Entwicklungsboards, die Plug & Play zusammen
> mit unserer IDE funktionieren werden. Also die passenden Bibliotheken
> werden hinzugefügt, I/Os verbunden ...

Das heißt, euer Produkt ist ein Gesamtsystem, bestehend aus Hardware, 
Entwicklungsumgebung, Programmiersprache und Bibliotheken.

Hardwareentwicklung ist wesentlich diverser als Softwareentwicklung, 
daher glaube ich nicht, dass dieses Konzept besonders gut funktioniert. 
In 20 Jahren mag das anders aussehen.

> Was wäre denn dein Vorschlag?

Fokussieren? :-)

Ich sehe keinen Bedarf an "noch einer" IDE. Es gibt bereits genug IDEs 
auf dieser Welt, und Vendor Lock-In nervt mit jeder zusätzlichen 
proprietären Lösung noch ein Stück mehr. Allerdings weiß ich auch, dass 
man ohne IDE keine Neuanfänger einfängt.

Ich sehe keinen Bedarf an "noch einem" Entwicklungsboard-Ökosystem. Es 
gibt bereits genug Boards verschiedener Preisklassen aus China, mit 
denen kann man allein weder in Vielfalt noch Preis konkurrieren. 
Außerdem ist Hardwareentwicklung divers, im Zweifelsfall will/muss man 
sein eigenes Board entwickeln.

Ich sehe ein bisschen Bedarf an Bibliotheken, bzw. IP-Blocks. Kann man 
als Produkt machen, konkurriert man entweder mit sowas wie OpenCores 
oder direkt mit den großen Firmen. Inwieweit man sich da durch Patente 
und anderes Kroppzeugs angreifbar macht, kann ich nicht einschätzen. 
Wäre cool.

Ich sehe Bedarf an einer guten Alternative zu VHDL und Verilog, am 
besten auf höherer Abstraktionsebene. Das heißt deutlich mehr als "wir 
machen Klammern statt begin/end", und man muss das ein paar 
Entwicklergenerationen durchhalten - grundlegender Fortschritt tritt 
erst mit dem Tod der früheren Entwicklergeneration ein (gibt's ein paar 
schöne Studien zu).

Das sind meine Gedanken, müssen nicht eure sein. Macht euch Gedanken, 
wo ihr hin wollt und wenn das der bisherige Plan ist, dann sei es so.

Meine Vorschläge:

(a) Fertige IDE nehmen und mit den eigenen Tools sinnvoll verbinden. 
Eclipse hat z.B. ein Interface, mit dem man externe Compiler für 
Syntaxprüfung und sowas anknoten kann. Aber bindet die Tools nicht an 
die IDE, lasst die Verwendung einer jeden IDE vollständig optional.

(b) Es gibt nur wenige FPGA-Hersteller und Toolchains. Bis auf Yosys 
sind die alle proprietär und sind schlicht nicht ersetzbar. Vivado, ISE 
und Quartus sind über Tcl scriptbar (Diamond kenne ich nicht). Bindet 
eure Tools lieber sinnvoll an diese Systeme an, so dass ich in eurem 
Tool auf "Run" klicken kann (bzw. "make all") und hinten ein Bitstream 
rausfällt. Unabhängig vom FPGA-Hersteller. Das wäre cool.

(c) Wenn ihr eine eigene Beschreibungssprache entwickeln wollt, dann 
macht das gründlich. Schreibt eure Bibliotheken damit, portiert fertige 
Codes bei Bedarf. Das ist viel Arbeit und genau das, was ich z.B. 
gerne hätte und so noch nicht in der Welt sehe.

Gustl B. schrieb:
>> Da ist ein "je länger ich X mache, desto besser finde ich X" absolut
>> nicht hilfreich, sondern ein psychologischer Fehlschluss.
> Eben nicht. Wir Menschen haben diese psychologische Eigenart,
> weil sie ein Vorteil ist in der Natur.

Ich sehe Programmieren oder FPGA-Entwicklung jetzt nicht gerade als 
etwas an, was dem "in der Natur" nahe kommt. :-)

> Es ist besser irgendwann einen Optimierungsprozess zu beenden [...]

Das ist prinzipiell richtig, verhindert aber Fortschritt. Insbesondere 
dann, wenn man direkt ansagt, dass alles "neue" schonmal per se 
schlechter ist. :-)

Du hast halt angesagt, dass du
(a) dich auf VHDL eingeschossen hast;
(b) damit zufrieden bist;
(c) keine Alternativen mehr berücksichtigst.

Das ist für dich sinnvoll.
Ist "Ham'wa schon imma so jemacht." aus deiner Sicht ein gutes Argument?

Man kann die großen, grundlegenden Fortschritte der Wissenschaft mit dem 
Tod der alten, festgefahrenen Wissenschaftler verbinden. Es gibt da ein 
gutes Paper zu, wo ich aber den Titel vergessen habe.

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Ich sehe keinen Bedarf an "noch einer" IDE. Es gibt bereits genug IDEs
> auf dieser Welt, und Vendor Lock-In nervt mit jeder zusätzlichen
> proprietären Lösung noch ein Stück mehr. Allerdings weiß ich auch, dass
> man ohne IDE keine Neuanfänger einfängt.
Richtig. Was z.B. Arduino so erfolgreich macht ist, dass man einfach die 
IDE installieren muss und loslegen kann. Wenn wir jetzt eine bestehende 
IDE nehmen, die man erst vorher einrichten muss und die 
unübersichtlicher ist, wäre das ganze für mich nicht mehr so attraktiv.

> Ich sehe keinen Bedarf an "noch einem" Entwicklungsboard-Ökosystem. Es
> gibt bereits genug Boards verschiedener Preisklassen aus China, mit
> denen kann man allein weder in Vielfalt noch Preis konkurrieren.
> Außerdem ist Hardwareentwicklung divers, im Zweifelsfall will/muss man
> sein eigenes Board entwickeln.
Also ich finde den MAX10 sehr interessant und da hab ich bis auf den 
MAX1000 (den wir im Moment zum Testen benutzen) keine vergleichbaren 
Entwicklungsboards gefunden.

> Ich sehe Bedarf an einer guten Alternative zu VHDL und Verilog, am
> besten auf höherer Abstraktionsebene. Das heißt deutlich mehr als "wir
> machen Klammern statt begin/end"
Ja also so wie bei VHDP?

> Das sind meine Gedanken, müssen nicht eure sein. Macht euch Gedanken,
> wo ihr hin wollt und wenn das der bisherige Plan ist, dann sei es so.
Wir freuen uns über alle Vorschläge

> Bindet
> eure Tools lieber sinnvoll an diese Systeme an, so dass ich in /eurem/
> Tool auf "Run" klicken kann (bzw. "make all") und hinten ein Bitstream
> rausfällt. Unabhängig vom FPGA-Hersteller. Das wäre cool.
Also es fehlt noch die Unterstützung für andere Hersteller, aber man 
muss bei uns nur auf "Run" drücken und hinten fällt der Bitstream raus.

> (c) Wenn ihr eine eigene Beschreibungssprache entwickeln wollt, dann
> macht das gründlich. Schreibt eure Bibliotheken damit, portiert fertige
> Codes bei Bedarf. Das ist viel Arbeit und genau das, was ich z.B.
> gerne hätte und so noch nicht in der Welt sehe.
https://github.com/search?utf8=%E2%9C%93&q=vhdplus

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
>> Allerdings weiß ich auch, dass
>> man ohne IDE keine Neuanfänger einfängt.
> Richtig. Was z.B. Arduino so erfolgreich macht ist, dass man
> einfach die IDE installieren muss und loslegen kann.

Was Arduino ebenfalls so erfolgreich macht, sind die Unmengen an Geld, 
die in Entwicklung und Vermarktung investiert wurden. Inzwischen ist das 
ein Selbstläufer, der auch in Firmen seine Verwendung findet - hat nur 
einige Jahre gedauert.

> Wenn wir jetzt eine bestehende IDE nehmen, die man erst
> vorher einrichten muss und die unübersichtlicher ist,
> wäre das ganze für mich nicht mehr so attraktiv.

Ich sehe jetzt keinen großen Unterschied zwischen einer 
selbstentwickelten VHDP-IDE und einem vorkonfiguriertem VHDP-Eclipse. 
"Nehmt eine vorhandene IDE" heißt ja nicht, dass das der Endnutzer auch 
machen muss.

>> Ich sehe Bedarf an einer guten Alternative zu VHDL und Verilog, am
>> besten auf höherer Abstraktionsebene. Das heißt deutlich mehr als "wir
>> machen Klammern statt begin/end"
> Ja also so wie bei VHDP?

Genau. Deswegen find ich die Idee spontan gut. Den ganzen "IDE und wir 
machen jetzt das Arduino für FPGAs"-Kram find ich unwichtig. ;-)

>> Das sind meine Gedanken, müssen nicht eure sein. Macht euch Gedanken,
>> wo ihr hin wollt und wenn das der bisherige Plan ist, dann sei es so.
> Wir freuen uns über alle Vorschläge

Das wiederum freut mich. ;-)

Viel Glück, Spaß und vor allem: einen sehr langen Atem.

Autor: K. L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> der auch in Firmen seine Verwendung findet - hat nur
> einige Jahre gedauert.

Als Prototyping-System ja, im Feld eher weniger, in 
Sicherheitsanwendungen (so gut wie) gar nicht.

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Ich sehe jetzt keinen großen Unterschied zwischen einer
> selbstentwickelten VHDP-IDE und einem vorkonfiguriertem VHDP-Eclipse.
> "Nehmt eine vorhandene IDE" heißt ja nicht, dass das der Endnutzer auch
> machen muss.
Hätten wir noch keine eigene IDE entwickelt durchaus richtig, aber mir 
gefällt jetzt jedenfalls unsere eigene IDE :D

> Viel Glück, Spaß und vor allem: einen sehr langen Atem.
Thx :D

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
K. E. schrieb:
> Als Prototyping-System ja, im Feld eher weniger, in
> Sicherheitsanwendungen (so gut wie) gar nicht.

Bei uns wird ein von der BBC entwickeltes Arduino-System zur 
Zertifizierung benutzt. Ich zähle die Laborumgebung mal unter "im Feld", 
weil Produktivumgebung.

Die Zahl der Schaltschränke mit einem Arduino (oder Raspberry Pi) im 
Produktivbetrieb nimmt ebenfalls zu.

Hat nur gute 10 Jahre gedauert. ¯\_(ツ)_/¯

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Was Arduino ebenfalls so erfolgreich macht, sind die Unmengen an Geld,
> die in Entwicklung und Vermarktung investiert wurden. Inzwischen ist das
> ein Selbstläufer, der auch in Firmen seine Verwendung findet - hat nur
> einige Jahre gedauert.

Dazu kommt, dass die Hardwarekosten fuer die Arduino Devices laecherlich 
klein sind, im Vergleich zu einem FPGA. Wenn in einem Produkt mal ein 
FPGA steckt der drei- bis vierstellig kostet, dann will man auf Teufel 
komm raus vermeiden, dass unnoetiger Overhead im Design landet. Eher 
will man aufs letzte optimieren um in die naechst guenstigere 
Preisklasse zukommen.

Von daher halte ich den Vergleich zwischen Arduino und dem hier 
vorgestellten im professionellen Bereich schwierig. :-/

Autor: Christoph M. (mchris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wenn in einem Produkt mal ein
>FPGA steckt der drei- bis vierstellig kostet, dann will man auf Teufel
>komm raus vermeiden, dass unnoetiger Overhead im Design landet.

Ein Gegenbeispiel wäre LabView-FPGA: Sau-teuer und mit Sicherheit viel 
Overhead.

Wenn es um kleine Stückzahlen geht, schlagen die Kosten für die 
Firmware-Entwicklung meistens die Hardwarekosten und dann ist der 
Software-Overhead ziemlich egal.

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph M. schrieb:
>>Wenn in einem Produkt mal ein
>>FPGA steckt der drei- bis vierstellig kostet, dann will man auf Teufel
>>komm raus vermeiden, dass unnoetiger Overhead im Design landet.
>
> Ein Gegenbeispiel wäre LabView-FPGA: Sau-teuer und mit Sicherheit viel
> Overhead.
>
> Wenn es um kleine Stückzahlen geht, schlagen die Kosten für die
> Firmware-Entwicklung meistens die Hardwarekosten und dann ist der
> Software-Overhead ziemlich egal.

Mit Labview FPGA baut man aber keine (Serien-)Produkte sondern 
Teststände, proof-concept-Produkte und Akademische Experiemente. Und bei 
VHDL führen VHDL-Konstrukte ohne Verständniss dessen was hinten 
rauskommt dazu, dass man zu schnelleren oder grösseren FPGAs  greifen 
muss, die schnell das doppelte des optimalen FPGA's kosten.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Hmm, wann habe ich sowas schon mal gehört?
> Vor gefühlten 100 Jahren als Designer meinten VHDL ist Müll und kann nie
> das Schematic ersetzen?

Grafik versus Sprache ? Sehr hinkender Vergleich.

Ich will nicht wieder den x-ten Krieg entfachen um die bessere Sprache - 
die spielt naemlich  - zumindest bei mir - keine Rolle. Sondern wie oft 
ich mich damit ins Knie schiesse. Chisel/Scala hat gegenueber Python ein 
paar gravierende Maengel, die das Debuggen schwierig machen, oder zu 
schludriger Programmierung verleiten, so dass fuer komplexe Projekte die 
Verifikation ein echter Albtraum wird.

VHDL hat einfach einen wahnsinnigen Vorteil in der Strenge - auch 
gegenueber Verilog - so dass sie als Transfersprache mit dem richtigen 
Simulator/Analyzer im Sinne einer robusten Entwicklung Gold wert ist. 
Insofern auch nie wegfallen wird.
Aber ich moechte keine CPU mehr in VHDL schreiben (muessen).

Vielleicht darf ich einen hoffentlich weniger hinkenden Vergleich 
anstellen:

VHDL <-> Assembler
'neue' HDL <-> C


Die neue HDL sollte man dann weniger als HDL, sondern als 
Modellierungssprache sehen. Wenn sie streng im Sinne einer 
Beschreibungssprache tickt, und ihre Paradigmen logisch darlegt, ist nix 
gegen ein Konstrukt oder eine Methodik einzuwenden, welche(s) man bisher 
noch nie angewendet hat.
Aber man wird so oder so nie umhinkommen, sich in die Interna 
einzufuchsen, d.h. die Transfersprache muss man schliesslich auch 
beherrschen. Und schliesslich das gefaehrliche Halbwissen darueber 
ansammeln, was der Transfer/die Synthese draus macht.

Wenn VHDP in der Sandbox fuer eine gewisse HW mit gut getesteten Cores 
einen Ersatz fuer grauslige PLC-Konzepte aus den 80ern bietet, warum 
nicht? Dann hat so ein arduinoides Oekosystem durchaus auch Chancen in 
der Industrie. Und hier waere es sogar verifizierbar.

Tools anzubieten/vermarkten ist nur eine sehr undankbare Aufgabe.

Tobias B. schrieb:
> Dazu kommt, dass die Hardwarekosten fuer die Arduino Devices laecherlich
> klein sind, im Vergleich zu einem FPGA. Wenn in einem Produkt mal ein
> FPGA steckt der drei- bis vierstellig kostet, dann will man auf Teufel
> komm raus vermeiden, dass unnoetiger Overhead im Design landet. Eher
> will man aufs letzte optimieren um in die naechst guenstigere
> Preisklasse zukommen.

Das Aequivalent zum Arduino waere vielleicht eher ein FPGA, was um die 
1-4 Dollar kostet, in 1000er-Stueckzahlen.
Auf einen Sp6-LX9 zB passt immerhin ein RiscV-SoC, der etwas mehr kann 
als ein AVR-8bitter. Ironisch ist, dass z.B. Vivado gerade darauf 
abzielt, mehr Overhead zu erzeugen als noetig.

Autor: Christoph M. (mchris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das Aequivalent zum Arduino waere vielleicht eher ein FPGA, was um die
>1-4 Dollar kostet, in 1000er-Stueckzahlen.

Es gibt ja schon ziemlich günstige Boards, welche in den 
Bastlerpreisbereich kommen ( und teilweise in ihrem Namen schon den 
avisierten Anwendungsbereich andeuten ):
Beitrag "Gnarly Grey low cost 5.3KLuts UltraPlus"

Mich würde mal direkt lauffähiges VhdlPlus-Beispiel für dieses Board 
interessieren:
Beitrag "XC6SLX16 Spartan 6 Entwicklungsboard"

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Andreas H. schrieb:
> Ironisch ist, dass z.B. Vivado gerade darauf
> abzielt, mehr Overhead zu erzeugen als noetig.

Auch Vivado erzeugt nur soviel Overhead wie der Nutzer zulässt.

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph M. schrieb:
> Mich würde mal direkt lauffähiges VhdlPlus-Beispiel für dieses Board
> interessieren:
> Beitrag "XC6SLX16 Spartan 6 Entwicklungsboard"

Wir werden uns bald damit auseinandersetzen auch Xilinx FPGAs zu 
unterstützen (ohne manuelles VHDL Datei kompilieren), aber da wir bis 
auf z.B. die PLL Bibliothek nicht auf herstellerspezifische Bibliotheken 
angewiesen sind, sollte das kein Problem sein.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Vielleicht darf ich einen hoffentlich
> weniger hinkenden Vergleich anstellen:
>
> VHDL <-> Assembler
> 'neue' HDL <-> C

Das behaupte ich ja schon länger.
Insofern: Vollste Zustimmung von mir.

Dass die Äquivalenz nicht so falsch ist, merkt man auch an Aussagen wie 
dieser:

Fpga K. schrieb:
> Auch Vivado erzeugt nur soviel Overhead wie der Nutzer zulässt.

Das gilt nämlich 1:1 auch für Assembler. :-)

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Martin S. schrieb:
> Andreas H. schrieb:
>> Schaut Euch mal Chisel an. Damit wird der RISC-V gemacht.
>
> Schon mal mit Chisel wirklich produktiv gearbeitet?
> Das mag eine akademisch 'schicke' Loesung sein, fuer die, die Scala
> erfunden haben. Von der Engineering-Seite her haette ich da leider nur
> vernichtende Kritik uebrig.

Lustig, dass das erwähnt wird ...

Hab den VexRiscV, der auf der Scala SpinalHDL Bibliothek aufbaut erst 
die letzten Tage ausgiebig getestet und das Konzept ist der Hammer!

Hatte eine Cortex-M1 Soft-CPU durch den RISC-V ersetzt und das Ding war 
dann schneller (in allen getesteten Disziplinen) ohne großartig mehr 
Resourcen zu brauchen.

Hat mich schon überzeugt.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Hab den VexRiscV, der auf der Scala SpinalHDL Bibliothek aufbaut erst
> die letzten Tage ausgiebig getestet und das Konzept ist der Hammer!
>
> Hatte eine Cortex-M1 Soft-CPU durch den RISC-V ersetzt und das Ding war
> dann schneller (in allen getesteten Disziplinen) ohne großartig mehr
> Resourcen zu brauchen.
>

Der RISC-V sollte eigentlich deutlich weniger Resourcen brauchen als ein 
M1, gesetzt den Fall, man implementiert den CSR nicht ganz nach 
Standard.
An der Architektur ist auch nichts auszusetzen, der Basis-Befehlssatz 
ist ja quasi der logische Attraktor, wenn man alle bisherigen Fehler in 
MIPS-Derivaten nicht nochmal machen will..

Man kann in jeder Murks-Sprache auch schoene HW machen. Frage ist nur, 
ob sich so effektiv arbeiten laesst. Ich will hier aber eigentlich nicht 
den Thread mit Kritik an Chisel/Scala vollmuellen, aber grundsaetzlich 
muss man sich bei neuen Ansaetzen der Frage stellen, ob man die 
Hardware-Denke, die Software-Denke, beides getrennt, oder irgend einen 
neuartigen (aber logischen) Paradigmenwechsel, vollziehen will (und ein 
ganzes Entwicklerteam oder Community davon ueberzeugt kriegt)
Wenn man das mit einer Sprache hinbekommt, sequentielle Beschreibung 
(ein "Programmm") und harte RTL (konkurrierende Statements) sauber zu 
trennen, oder per Designregel-Tool auf das jeweilige hinzuweisen, kriegt 
man Hwerker, Swerker, und Mwerker/Owerker (Matlab/Octave) in ein Boot.
Wenn das ganze im Workflow noch einigermassen overheadfreie Hardware 
generiert, oder wenigstens die Kontrolle des Transfers von sequentiellen 
Modellen in der nativen Sprache moeglich ist (ohne sowas wie Lisp-Listen 
koennen zu muessen), hat das Ding aus meiner Sicht gewonnen.

: Bearbeitet durch User
Autor: Tobias N. (technick2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fpga K. schrieb:
> bei VHDL führen Konstrukte ohne Verständnis dessen, was hinten
> rauskommt, dazu, dass man zu schnelleren oder grösseren FPGAs greifen
> muss, die schnell das doppelte des optimalen FPGA's kosten.

Können die neuen Programmiersprachen wie diese hier, helfen, das Problem 
zu mindern? Oder fördern sie es?

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias N. schrieb:
> Fpga K. schrieb:
>> bei VHDL führen Konstrukte ohne Verständnis dessen, was hinten
>> rauskommt, dazu, dass man zu schnelleren oder grösseren FPGAs greifen
>> muss, die schnell das doppelte des optimalen FPGA's kosten.
>
> Können die neuen Programmiersprachen wie diese hier, helfen, das Problem
> zu mindern? Oder fördern sie es?

VHDP basiert auf VHDL und wird daher nicht weniger overhead erzeugen. 
Wir haben uns darauf konzentriert VHDL Programmierung einfacher zu 
machen und dabei die Optimierungsmöglichkeiten von VHDL beizubehalten. 
Nicht wie bei vielen C zu HDL Projekten.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
> VHDP basiert auf VHDL und wird daher nicht weniger overhead erzeugen.
> Wir haben uns darauf konzentriert VHDL Programmierung einfacher zu
> machen und dabei die Optimierungsmöglichkeiten von VHDL beizubehalten.
> Nicht wie bei vielen C zu HDL Projekten.

Was ich etwas schwieriger finde ist, dass man - wenn man mal VHDL kann - 
genau weiß, welche Konstrukte wie synthetisiert werden und man über die 
Hardware-Beschreibung sehr genau steuern kann, was schlussendlich 
herauskommt.

Ich befürchte, dass diese neue Abstraktions-Schicht viel implizit macht 
und man die Steuerungsmöglichkeiten mehr oder weniger verliert.

Aber Anfänger können dadurch sicherlich profitieren.

So ein PoC, um die Leistungsfähigkeit von VHDP zu demonstrieren wäre 
echt interessant ...

Ein bereits oben genanntes Beispiel wäre ein RISC-V CPU-Core, der 
relativ einfach ist und die Vorzüge dann demonstrieren könnte.

Irgendwelche Blinklichter würde ich zu den Trivial-Beispielen zählen, 
die mich jetzt nicht so von den Socken hauen.

Insbesondere dürften dann noch Sachen auftauchen, die die 
VHDP-Programmierer bisher nicht bedacht hatten und was VHDP dann selbst 
noch verbessern dürfte.

: Bearbeitet durch User
Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Ich befürchte, dass diese neue Abstraktions-Schicht viel implizit macht
> und man die Steuerungsmöglichkeiten mehr oder weniger verliert.
Also solang man "Thread" nicht benutzt, wird der VHDP code 1:1 in VHDL 
umgewandelt. Nur halt, dass die syntax vereinfach ist.

> So ein PoC, um die Leistungsfähigkeit von VHDP zu demonstrieren wäre
> echt interessant ...
>
> Ein bereits oben genanntes Beispiel wäre ein RISC-V CPU-Core, der
> relativ einfach ist und die Vorzüge dann demonstrieren könnte.
Wir haben überlegt dieses Projekt hier https://github.com/f32c/f32c in 
VHDP umzuprogrammieren. Das wäre dann in Kombination mit FPGArduino auch 
für Anfänger interessant.
Leistungsverbesserungen kann man da zwar nicht erwarten, aber der code 
sollte deutlich übersichtlicher werden.

Vorteile sehe ich ehr darin, dass man bei weniger Anwendungen zu einem 
Soft Core greift.

: Bearbeitet durch User
Autor: Christoph M. (mchris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leon,

das Arduino-Framework ist deshalb so erfolgreich, weil es so leicht in 
Betrieb zu nehmen und relativ leicht zu verstehen ist.

Einen großen Anteil daran macht die TTB ( time to blink ), also die Zeit 
oder die Anzahl der Klicks, die man braucht bis die LED blinkt.

Bei der Arduino-IDE liegt die TTB bei

1. IDE starten
2. Board auswählen
3. Port auswählen ( meistens schon automatisch gefunden )
4. Compile and Flash drücken

Die TTB liegt also zwischen 3- und 4. Wie ist das bei eurem System?

Autor: J. S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph M. schrieb:
> Einen großen Anteil daran macht die TTB

Interessanter Ansatz und interessante Definition.

Jetzt ist es nur so, dass es im FPGA-Umfeld auch solche 
Baukasten-Effekte gibt. Vorgefertigte build-bare Projekte lassen auch 
direkt etwas blinken.

Ich bin nur nicht so sicher, ob das zielführend ist und nicht so manchem 
einen falschen Eindruck der wahren Komplexität solcher System 
vermittelt.

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph M. schrieb:
> Bei der Arduino-IDE liegt die TTB bei
>
> 1. IDE starten
> 2. Board auswählen
> 3. Port auswählen ( meistens schon automatisch gefunden )
> 4. Compile and Flash drücken
Also vorausgesetzt unsere IDE und Quartus sind installiert ist das:
1. IDE starten
2. Neues Projekt erstellen
3. Board auswählen
4. Compile drücken
5. Programmer auswählen
6. Datei auswählen
7. Programmieren starten
Also 7

Bei dem Programmiervorgang nehmen wir noch das Quartus eigene 
Programmierfenster. Wenn wir das integrieren kommen wir auf 4-5.

: Bearbeitet durch User
Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
> Wir haben überlegt dieses Projekt hier https://github.com/f32c/f32c in
> VHDP umzuprogrammieren. Das wäre dann in Kombination mit FPGArduino auch
> für Anfänger interessant.

Der f32c war leider mal sehr fern von RISC-V Compliance (wobei das 
selbst noch so etwas schwammig sein kann). Entweder hat sich das 
verbessert, oder ihr oeffnet eine weitere Baustelle, die allenfalls fuer 
wenig Akzeptanz sorgt. Wollt ihr das Anfaengern wirklich antun?

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Der f32c war leider mal sehr fern von RISC-V Compliance (wobei das
> selbst noch so etwas schwammig sein kann). Entweder hat sich das
> verbessert, oder ihr oeffnet eine weitere Baustelle, die allenfalls fuer
> wenig Akzeptanz sorgt. Wollt ihr das Anfaengern wirklich antun?
Danke für den Hinweis. Wir haben nur gesehen, dass das FPGArduino 
Projekt interessant aussah, aber wir haben noch nicht tiefer 
reingeguckt.
Kannst du vielleicht einen Projekt empfehlen? Am besten mit VHDL 
geschrieben.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
> Danke für den Hinweis. Wir haben nur gesehen, dass das FPGArduino
> Projekt interessant aussah, aber wir haben noch nicht tiefer
> reingeguckt.
> Kannst du vielleicht einen Projekt empfehlen? Am besten mit VHDL
> geschrieben.

Ich kenne sonst nur noch https://github.com/skordal/potato. Der rasselt 
immerhin mal mit der Standard-Toolchain los, allerdings hatte auch da 
wohl ein User Probleme mit AND/XOR, habe ich nicht mehr verifiziert.
Alle anderen mir bekannten robusten Implementierungen sind entweder in 
(System)Verilog oder Python (MyHDL) geschrieben. Ich habe sonst auch 
noch ein Design in der Schublade, was im Status 'works for me' ist. 
Davon koennte ich fuer ein Opensource-Dingen schon VHDL ausgeben, das 
ist allerdings bedingt lesbar, bei Interesse gerne PM schicken.
Die Verifizierung ist beim RISC-V allerdings so ein Thema, wo ich noch 
nicht komplett zufrieden bin, aber das hat SiFive offenbar selbst noch 
recht lax definiert.
Was das angeht, ist die ZPU-Architektur (siehe auch ZPUino) deutlich 
besser dran, dank ihres wirklich extrem reduzierten 8-bit-Opcode-Sets. 
Allerdings ist deren gcc-port nicht auf dem neuesten Stand, und der 
Unterhalt koennte irgendwann aufwendig werden. Ansonsten ist die 
Architektur sehr robust und frei von dreckigen Hazards, dazu kommt eine 
hohe Opcode-Dichte.
Da allerdings macht der RV32IC-Support inzwischen mit -Os Optimierung 
recht Boden wett. Auch muss man bei der ZPU wissen, dass die 
kleingekochten Varianten dank 'Emulation' einiger Befehle in manchen 
Implementierungen langsam sein koennen.
Den groessten Spass werdet ihr bei solchen Themen haben:
- Interrupt und Exceptions in komplexeren SoCs (funktioniert selten 
korrekt)
- Debugging (In Circuit Emulation, selten vorhanden)

Und dann kann ich nur 'TDD' empfehlen: wenn ihr in einer neuartigen 
Sprache gleich eine Portierung einer komplexeren CPU ansetzt, gibt's 
gleich von Anfang an eigentlich nur eins: Test-Cases/Regresstest und 
Design parallel entwickeln, so dass man bei jedem commit sehen kann, 
ob/was man grade kaputtgemacht hat.

Autor: Leon B. (leonbeier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die nützlichen Infos. Hab mich mit den CPUs noch nicht so 
auseinandergesetzt und immer auf NIOS zurückgegriffen. Gerade da wir 
aber auch andere Hersteller unterstützen wollen ist das nicht optimal.

Martin S. schrieb:
> Ich kenne sonst nur noch https://github.com/skordal/potato. Der rasselt
> immerhin mal mit der Standard-Toolchain los, allerdings hatte auch da
> wohl ein User Probleme mit AND/XOR, habe ich nicht mehr verifiziert.

> Was das angeht, ist die ZPU-Architektur (siehe auch ZPUino) deutlich
> besser dran, dank ihres wirklich extrem reduzierten 8-bit-Opcode-Sets.
Guck ich mir beides auf jeden Fall an. Würde aber ehr noch zu potato 
tendieren.

> Ich habe sonst auch
> noch ein Design in der Schublade, was im Status 'works for me' ist.
> Davon koennte ich fuer ein Opensource-Dingen schon VHDL ausgeben, das
> ist allerdings bedingt lesbar, bei Interesse gerne PM schicken.
Würde ich dann drauf zurückkommen, wenn ich bei den anderen beiden 
Projekten nicht fündig werde.

Dieser Beitrag kann nur von angemeldeten Benutzern beantwortet werden. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.