Announcement: there is an English version of this forum on 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
:
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.
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!
Angehängte Dateien:
-
VHDP_example.png
17 KB
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.
Kannst du auch den daraus generierten VHDL-Code zeigen? Es würde mich schon interessieren, was er daraus generiert.
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 !
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".
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:
1 | PROCESS (CLK) |
2 | VARIABLE i : INTEGER := 0; |
3 | VARIABLE Thread9 : NATURAL range 0 to 5 := 0; |
4 | VARIABLE Thread13 : NATURAL range 0 to 1200007 := 0; |
5 | BEGIN |
6 | IF RISING_EDGE(CLK) THEN |
7 | CASE (Thread9) IS |
8 | WHEN 0 => |
9 | IF (BTN = '0') THEN |
10 | ELSE |
11 | Thread9 := Thread9 + 1; |
12 | END IF; |
13 | WHEN 1 => |
14 | i := 0; |
15 | Thread9 := Thread9 + 1; |
16 | WHEN 2 => |
17 | IF ( i < 8) THEN |
18 | Thread9 := Thread9 + 1; |
19 | ELSE |
20 | Thread9 := Thread9 + 2; |
21 | END IF; |
22 | WHEN (2+1) => |
23 | CASE (Thread13) IS |
24 | WHEN 0 => |
25 | IF (UART_TX_Busy = '1') THEN |
26 | ELSE |
27 | Thread13 := Thread13 + 1; |
28 | END IF; |
29 | WHEN 1 => |
30 | UART_TX_Data <= myString(i); |
31 | UART_TX_Enable <= '1'; |
32 | Thread13 := Thread13 + 1; |
33 | WHEN 2 => |
34 | IF (UART_TX_Busy = '0') THEN |
35 | ELSE |
36 | Thread13 := Thread13 + 1; |
37 | END IF; |
38 | WHEN 3 => |
39 | UART_TX_Enable <= '0'; |
40 | Thread13 := Thread13 + 1; |
41 | WHEN 4 => |
42 | IF (UART_TX_Busy = '1') THEN |
43 | ELSE |
44 | Thread13 := Thread13 + 1; |
45 | END IF; |
46 | WHEN 5 to 1200005 => |
47 | Thread13 := Thread13 + 1; |
48 | WHEN 1200006 => |
49 | i := i + 1; |
50 | Thread13 := 0; |
51 | Thread9 := 2; |
52 | WHEN others => Thread13 := 0; |
53 | END CASE; |
54 | WHEN 4 => |
55 | IF (BTN = '1') THEN |
56 | ELSE |
57 | Thread9 := 0; |
58 | END IF; |
59 | WHEN others => Thread9 := 0; |
60 | END CASE; |
61 | END IF; |
62 | 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
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.
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
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?
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.
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?
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.
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.
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 ?
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?
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.
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'.
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.
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.
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
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...
Ich meine wenn man bei uns Wait(...) einfügt, dann wird dementsprechend (synthetisierbar) gewartet. Sieht dann als VHDL so aus:
1 | WHEN 5 to 1200005 => |
2 | Thread13 := Thread13 + 1; |
3 | WHEN 1200006 => |
Und unser Blink Programm ist dann:
1 | LED <= '1'; |
2 | Wait(1000000); |
3 | LED <= '0'; |
4 | Wait(1000000); |
Wie würde bei MyHDL ein Blinkprogramm aussehen?
:
Bearbeitet durch User
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.
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?
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:
1 | @instance_new_paradigm(clk, counter) |
2 | def blink(): |
3 | yield delay(100) |
4 | led.next = 1 |
5 | yield delay(100) |
6 | 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.
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.
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.
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
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.
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.
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).
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.
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.
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?
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.
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 ... ...
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 ...
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.
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
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?
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
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.
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".
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
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 ...
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
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.
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
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.
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
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.
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.
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
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. ¯\_(ツ)_/¯
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. :-/
>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.
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.
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.
>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"
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.
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.
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. :-)
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.
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
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?
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.
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
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
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?
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.
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
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?
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.
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.
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.
@LEAON: Mich würde eine Einschätzung das zu interessieren.
Hey Leute, die existierenden HDLs sind wirklich schrecklich - jede von den 2 großen hat ein paar sauhässliche Warzen. Gute Idee, das zu optimieren! Ich habe gesehen, dass die IDE bisher nur die proprietären Werkzeuge unterstützt. Schaut doch mal, ob ihr nicht mittels Yosys/GHDL/ghdl-yosys-plugin* und icestorm die Lattice ICE40 FPGAs unterstützen könnt. Diese Variante hätte den Charme, dass alle benötigten Tools in der IDE geliefert werden können und man keine separate Toolchain braucht, die womöglich Registrierungszwang etc pp. hat. Außerdem gibts die Lattice FPGAs Evalboards für 25-50 €. *nennt sich ghdslsynth-beta ist aber im Prinzip ein Plugin für Yosys und erlaubt, dass man VHDL über Yosys verarbeiten kann -> https//github.com/tgingold/ghdlsynth-beta.git
Steht auf jeden Fall bei den großen Verbesserungen ganz oben auf der Liste, aber im Moment konzentrieren wir uns darauf, dass die IDE und der Compiler insgesamt laufen und dass es schon ein paar Bibliotheken gibt. Da wir uns als Hardware den MAX10 ausgeguckt haben (genug Logik Elemente, interner Flash + ADC und günstig), entwickeln wir erst für Quartus alles. Wir achten aber darauf, dass wir möglichst keine herstellerabhängigen Bibliotheken benutzen. Aber natürlich kann man trotzdem Lattice und Xilinx FPGAs schon programmieren indem man die generierten VHDL Dateien benutzt.
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? Es wird auch 2050 noch Menschen geben, die das behaupten ... :-)
Die ersten Entwicklungsboards und Erweiterungen stehen nun übrigens zum Verkauf (shop.vhdplus.com). Wer jetzt möchte kann das ganze gerne mal ausprobieren und selbst wenn euch die IDE nicht gefallen sollte habt ihr dennoch dann meiner Meinung nach das beste Entwicklungsboard in diesem Preisbereich. Es bietet Programmer, RAM, Flash, High Speed Stecker (für HDMI, CSI Kamera ...) und mehr. Ein Blick auf die neue IDE mit Simulator, integrierter Software Programmierung etc. kann ich übrigens auch empfehlen :)
Leon B. schrieb: > Die ersten Entwicklungsboards und Erweiterungen stehen nun übrigens zum > Verkauf (shop.vhdplus.com). > dennoch dann meiner Meinung nach das beste Entwicklungsboard in diesem > Preisbereich. Die Leistungsbeschreibung ist in Teilen grob fehlerhaft, ein MAX10 hat nicht acht ADC onboard sondern hier einen mit bis zu 8? Kanälen auf die sich die Samplerate aufteilt. MfG,
Die sehen recht nett aus. Was ich schade finde ist, dass die Anschlüsse nicht die sind die sonst üblich sind. Also leider kein PMOD drauf und für den HS Anschluss wurde auch kein SYZYGY oder so verwendet. Ein Datenblatt wäre noch nett in dem drinnen steht wie viele IOs verfügbar sind und auch was für Taktgeber und sonstige Bausteine verbaut sind. Braucht man noch einen USB Blaster oder ist der schon mit dabei?
Fpgakuechle K. schrieb: > Die Leistungsbeschreibung ist in Teilen grob fehlerhaft, ein MAX10 hat > nicht acht ADC onboard sondern hier einen mit bis zu 8? Kanälen auf die > sich die Samplerate aufteilt. Danke für den Hinweis, ich werde 8 Kanäle schreiben
Gustl B. schrieb: > Die sehen recht nett aus. Was ich schade finde ist, dass die Anschlüsse > nicht die sind die sonst üblich sind. Also leider kein PMOD drauf und > für den HS Anschluss wurde auch kein SYZYGY oder so verwendet. > Ein Datenblatt wäre noch nett in dem drinnen steht wie viele IOs > verfügbar sind und auch was für Taktgeber und sonstige Bausteine verbaut > sind. Braucht man noch einen USB Blaster oder ist der schon mit dabei? Zu den Anschlüssen: Wir haben den von Trenz-Electronics und in Kooperation mit anderen Firmen entwickelten CRUVI Anschluss benutzt. Dieses hat den Vorteil, dass man keine 2 lose zusammengesteckte Platinen haben, sondern eine Einheit die man so einbauen kann. In Zukunft werden also auch andere Hersteller diesen Standard verwenden. Wir sind nur die Ersten damit. Der Programmer ist onboard und hier sind noch ein paar Informationen: https://vhdplus.com/docs/components/vhdpcore_max10 Wir können noch den Schaltplan als Datei hinzufügen, aber haben versucht es mit den Grafiken möglichst einfach zu halten
Leon B. schrieb: > Fpgakuechle K. schrieb: >> Die Leistungsbeschreibung ist in Teilen grob fehlerhaft, ein MAX10 hat >> nicht acht ADC onboard sondern hier einen mit bis zu 8? Kanälen auf die >> sich die Samplerate aufteilt. > > Danke für den Hinweis, ich werde 8 Kanäle schreiben Schreib lieber die Anzahl der Pins die an diesem Board zum ADC gehen, lt. datenblatt kann ein max10 bis zu 17/18 externe Kanäle.
Fpgakuechle K. schrieb: > Schreib lieber die Anzahl der Pins die an diesem Board zum ADC gehen, > lt. datenblatt kann ein max10 bis zu 17/18 externe Kanäle. Ja also der verbaute FPGA hat 9 Inputs, aber nur 8 sind mit Pins verbunden
Leon B. schrieb: > Wir haben den von Trenz-Electronics und in > Kooperation mit anderen Firmen entwickelten CRUVI Anschluss benutzt. Das ist shon mal positiv. Leon B. schrieb: > Habe den Schaltplan jetzt auch hinzugefügt: > http://cdn.vhdplus.com/shop/SCH-CR00010-02-C.PDF Wunderbar, der sieht tatsächlich sehr nach Trenz aus. Was mich etwas wundert: Da wurden differentielle Paare z. B. A0_P und A0_N mit zwei Verbindern verbunden, J1 und J3. Ich habe hier schon gelesen, dass man so Stubs an Leitungen für HF vermeiden sollte. Aber gut möglich, dass das für die meisten Anwendungen trotzdem funktioniert. Es bleibt also spannend. Auch wenn ich das mit dem VHDPlus nicht so wirklich sinnvoll finde wünsche ich Euch viel Erfolg bei der Hardware, die ist ja auch ohne VHDPlus benutzbar.
Gustl B. schrieb: > Was mich etwas wundert: > Da wurden differentielle Paare z. B. A0_P und A0_N mit zwei Verbindern > verbunden, J1 und J3. Ich habe hier schon gelesen, dass man so Stubs an > Leitungen für HF vermeiden sollte. Aber gut möglich, dass das für die > meisten Anwendungen trotzdem funktioniert. Also mit CSI Kamera und HDMI war das jedenfalls kein Problem. Da haben wir die differentiellen leitungen auch schon auf maximaler Frequenz betrieben > Es bleibt also spannend. Auch wenn ich das mit dem VHDPlus nicht so > wirklich sinnvoll finde wünsche ich Euch viel Erfolg bei der Hardware, > die ist ja auch ohne VHDPlus benutzbar. Ich meine man muss ja nicht VHDP benutzen, sondern VHDL und Verilog gehen ebenfalls. Das Verbinden der Pins ist deutlich einfacher und viele Features wie die Vervollständigung sind auch besser (auch für VHDL). Die IDE wird übrigens auch schon für VHDL an Hochschulen benutzt
:
Bearbeitet durch User
Leon B. schrieb: > Also mit CSI Kamera und HDMI war das jedenfalls kein Problem. Das klingt gut! Leon B. schrieb: > Das Verbinden der Pins ist deutlich einfacher und viele > Features wie die Vervollständigung sind auch besser (auch für VHDL). > > Die IDE wird übrigens auch schon für VHDL an Hochschulen benutzt Die IDE sieht tatsächlich schön schlank aus, werde ich mir mal angucken.
https://www.youtube.com/watch?v=maYOYYNtw2U&ab_channel=VHDPlusLearning Hier ist noch eine Anleitung für VHDL. Für Verilog gibt es leider noch keine so tiefe Integration
:
Bearbeitet durch User
Beitrag #6490012 wurde vom Autor gelöscht.
Wer interesse hat kann zu dem Thema übrigens auch bald unser Seminar bei Arrow besuchen https://register.gotowebinar.com/register/7494872000681768720?source=VHDPlus
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.