Die folgende Frage richtet sich spezifisch an diejenigen, die sich die Mühe gemacht haben beide Sprachen zu erlernen. Ich hab mehr so aus einer spontanen Entscheidung "aus dem Bauch heraus" angefangen Verilog zu lernen. Inzwischen bekomme ich zumindest schon mittelmäßig komplexe Dinge auf die Reihe. Allerdings finde ich eben immer mal wieder interessante Projekte (z.B. auf opencores) sowie Beispiele, Problemlösungen, die eben in VHDL sind. "So ungefähr" kann ich die mit etwas gutem Willen meistens auch lesen und verstehen. Trotzdem denke ich drüber nach, eventuell zumindest die Urgründe von VHDL auch systematisch zu erlernen. Da gibt es allerdings die (für mich nicht überprüfbaren) Ansagen dass VHDL viel sperriger und schwerer zu erlernen sei. Kann eventuell jemand, der beide Sprachen gelernt hat mal was dazu sagen wie die Lernkurven im Vergleich sind?
<trollmode_on> Verilog kannst du einfach lostippen, verstehst allerdings nach 4 Wochen Urlaub deinen eigenen Code nicht mehr. VHDL kannst du nach 4 Wochen Urlaub noch lesen und verstehen, du kriegst allerdings nichts syntaktisch richtiges mehr geschrieben. </trollmode_on> Oder so aehnlich... Mit beiden kann man gleiche Resultate erzielen, VHDL ist einfach geschwaetziger als Verilog, dafuer aber noch einen Tick maechtiger. Ist von Vorteil, wenn man beide wenigstens lesen und verstehen kann...
ähm, das sind genau die Klischees die man überall im Web zu dem Thema findet. Hatte aber eigentlich nach der Lernkurve gefragt - wiviel mehr Mühe und Zeit muss man investieren um VHDL auf vergleichbarem Level zu erlernen wie Verilog ;)
Die Lernkurve hängt eher von den Aufgaben und der Komplexität der Fragestellungen ab, als von der Sprache. Die Formulierungen sind ja schnell gelernt, aber die Funktion hinter der Schaltung ist das Wesentliche.
Micha schrieb: > wiviel mehr > Mühe und Zeit muss man investieren um VHDL auf vergleichbarem Level zu > erlernen wie Verilog ;) Ich sag's mal so: Einen Verilog Desgin nach VHDL zu portieren ist imho einfacher als umgekehrt. Liegt daran, dass VHDL mehr Moeglichkeiten bietet (z.B. Integer mit range, signed/unsigned Datentypen, frueher gab es in Verilog kein 'generate', was muss ein 'wire' sein und was ein 'reg', ...). Aber: Mein Verilog-Wissen ist jetzt auch schon ~10 Jahre alt, also vorsicht mit meinen Aussagen... Ich denke mal, VHDL hat mehr 'statements' und um die zu Nutzen braucht's halt auch mehr Zeit (schon die unterschiedlichen statements fuer concurrent und sequential z.B., obwohl die jeweils das gleiche machen...).
Micha schrieb: > wiviel mehr Mühe und Zeit muss man investieren um VHDL > auf vergleichbarem Level zu erlernen wie Verilog ;) Da war vor kurzem hier mal eine Diskussion zum Thema VHDL vs. Verilog: http://www.lothar-miller.de/s9y/archives/88-VHDL-vs.-Verilog-am-Beispiel-einer-Stoppuhr.html
Systemverilog ist besser. 54 Zeilen und übersichtlich, man muss es halt nur beherrschen.
1 | module stopwatch |
2 | (
|
3 | input clk, |
4 | input reset, |
5 | input _start, |
6 | output logic[6:0] segments, |
7 | output logic dp, |
8 | output logic[3:0] an |
9 | );
|
10 | parameter[6:0] ss_table[9]= // seven segment table |
11 | '{7'b1000000, 7'b1111001, 7'b0100100, 7'b0110000, 7'b0011001, |
12 | 7'b0010010, 7'b0000010, 7'b1111000, 7'b0000000, 7'b0010000}; |
13 | |
14 | logic[32:0] prescaler, muxcnt; |
15 | logic[3:0] m, s10, s1, st; |
16 | logic[3:0] carry; |
17 | |
18 | function automatic [3:0] mux; |
19 | input[3:0] d0, d1, d2, d3; |
20 | input[1:0] which; |
21 | logic[3:0] array[4]; |
22 | begin
|
23 | array='{d0,d1,d2,d3}; |
24 | mux=array[which]; |
25 | end
|
26 | endfunction
|
27 | |
28 | always @(posedge clk or posedge reset) |
29 | begin
|
30 | if (reset) |
31 | begin
|
32 | muxcnt=0; |
33 | prescaler=0; |
34 | {m,s10,s1,st}<={4'd0,4'd0,4'd0,4'd0}; |
35 | an=~4'd0; |
36 | end
|
37 | else
|
38 | begin
|
39 | segments=ss_table[mux(muxcnt[17:16], m, s10, s1, st)]; |
40 | dp=mux(muxcnt[17:16], 1, 0, 1, 0 ); |
41 | an=~(4'b1<<muxcnt[17:16]); |
42 | muxcnt++; |
43 | if (_start) |
44 | if (prescaler==4999999) |
45 | begin
|
46 | prescaler=0; |
47 | carry={m==9,s10==5,s1==9,st==9}; |
48 | {m,s10,s1,st}<={(m+carry[2])*~carry[3],(s10+carry[1])*~carry[2],(s1+carry[0])*~carry[1],(st+1)*~carry[0]}; |
49 | end
|
50 | else
|
51 | prescaler++; |
52 | end
|
53 | end
|
54 | endmodule
|
Wenn du mit z.b. mit altera fpgas und quartus arbeitest und ip cores generieren willst wirst du sowieso beides können oder zumindest verstehen müssen!
Als Alternative gäb's noch MyHDL...siehe separater Thread hier irgendwo. Faktisch ist das einfach nur Python. Das hat die bekannten Vorteile: - Code gut lesbar - Code gut wiederverwertbar - Weniger Geschwätzigkeits-Overhead wie bei VHDL - Folgt "keep it simple"-Prinzipien Der Simulator ist quasi Teil des Programms. Zusätzlich kann man alles in VHDL oder Verilog für die Synthese ausgeben und hat recht gute Kontrolle über den erzeugten Code. Mich hats zumindest überzeugt (SystemC nicht.)
Dogbert schrieb: > übersichtlich Ja, so ist es:
1 | carry={m==9,s10==5,s1==9,st==9}; |
2 | {m,s10,s1,st}<={(m+carry[2])*~carry[3],(s10+carry[1])*~carry[2],(s1+carry[0])*~carry[1],(st+1)*~carry[0]}; |
Da wird jedem (auch jedem Anfänger) auf den allerersten Blick klar,
was da gemacht wird.
Kurz: es ist nicht signifikant übersichtlicher, nur weil alles in eine
Zeile oder auf eine Bildschirmseite passt.
> man muss es halt nur beherrschen.
Das ist für jede Beschreibungssprache gut...
na ich wage mal die Behauptung dass das meiste Zeugs was man im Web an Beispielcode findet, oder eben auch die Sachen auf opencores entweder in VHDL oder Verilog geschrieben ist, die anderen Sprachen sind alle mehr oder weniger Exoten, was keine Wertung bzgl deren Potenzial darstellen soll. Inzwischen bin ich ziemlich sicher, dass es ein Vorteil ist, wenn man beide Sprachen zu einem gewissen Grad beherrscht - um z.B. mit Projekten die einen interessieren experimentieren zu können oder diese auf sein Board anzupassen. Werd mir die Tage mal das VHDL Tutorial hier auf mikrocontroller.net reinziehen ;)
Lothar Miller schrieb: > Kurz: es ist nicht signifikant übersichtlicher, nur weil alles in eine > Zeile oder auf eine Bildschirmseite passt. Denke ich schon. Der Erfahrene zieht die kürzere Formulierung vor. Er muss weniger Code sichten um zu verstehen. Ich finde es ein wesentlich klareres und symmetrischeres Bild als das der verschachtelten "if then else" Struktur. Es zeigen sich Gemeinsamkeiten deutlicher. Addierer Überlauf Carry x 4. Symmetrien und sich wiederholende Strukturen erleichtern Verständnis und Fehlersuche. Aber es stimmt schon, ist natürlich kein HDL-Babytalk.
josef f. schrieb: > Wenn du mit z.b. mit altera fpgas und quartus arbeitest und ip cores > generieren willst wirst du sowieso beides können oder zumindest > verstehen müssen! warum dies?
Micha schrieb: > Da gibt es allerdings die (für mich > nicht überprüfbaren) Ansagen dass VHDL viel sperriger und schwerer zu > erlernen sei. Kann eventuell jemand, der beide Sprachen gelernt hat mal > was dazu sagen wie die Lernkurven im Vergleich sind? IMHO hängt das vom Vorwissen ab. Kannst Du C und kennst Hardware nur vom Schaufenster des PC-Händlers dann lernt sich verilog schneller als VHDL, da du die ganzen sackgassen (das kann man ja wie in C schreiben!) auslässt. Wenn du dagegen genau weist das du ein FF, eine sync-Stufe, eine FSM, ein Mux mit Pipilinestufe zu beschreiben hast und kennst was die synthese mag und was nicht dann lernt sich VHDL recht schnell. Wichtig ist das man das lernziel richtig formuliert und nicht aus den Augen verliert: Es gilt nicht Verilog und VHDL als Sprache zu lernen sondern als Werkzeug um damit a) (FPGA)-Designs zu basteln b) Testbenches zu bauen um Spec-konformität nachzuweisen behält man den Werkzeug-gedanken immer fest im Kopf verirrt man sich auch nicht in den Fallgruben des geschwätzigen VHDL. Lerne zuerst das was du brauchst, später das was das Werkzeug noch so bietet. Gruß,
Karl Könner schrieb: > Kannst Du C und kennst Hardware nur vom Schaufenster des PC-Händlers > dann lernt sich verilog schneller als VHDL, da du die ganzen sackgassen > auslässt. Oder genau deshalb reinfällst, weil du wegen zufälliger Ähnlichkeiten annimmst "Softwareprogramm = Hardwarebeschreibung": > das kann man ja wie in C schreiben! Wobei dieses "Verilog ist einfacher, weil es sich wie C schreibt" Argument eines der blödesten ist, die es gibt, denn wenn jemand unbefangen eine Verilog-Beschreibung mit einem C-Programm vergleicht, dann kann er auf Anhieb die (mindestens) 10 Unterschiede nennen... > behält man den Werkzeug-gedanken immer fest im Kopf verirrt man sich > auch nicht in den Fallgruben des geschwätzigen VHDL. Macht man sich zudem bewusst, dass man 90% (eher mehr) von VHDL nur für die Simulation nehmen kann, wird VHDL für FPGAs ganz schnell ganz übersichtlich...
Lothar Miller schrieb: > Karl Könner schrieb: >> Kannst Du C und kennst Hardware nur vom Schaufenster des PC-Händlers >> dann lernt sich verilog schneller als VHDL, da du die ganzen sackgassen >> auslässt. > Oder genau deshalb reinfällst, weil du wegen zufälliger Ähnlichkeiten > annimmst "Softwareprogramm = Hardwarebeschreibung": >> das kann man ja wie in C schreiben! > Wobei dieses "Verilog ist einfacher, weil es sich wie C schreibt" > Argument eines der blödesten ist, die es gibt, denn wenn jemand > unbefangen eine Verilog-Beschreibung mit einem C-Programm > vergleicht, dann kann er auf Anhieb die (mindestens) 10 Unterschiede > nennen... Da bin ich wohl missverstanden worden. Die Aussage ist: "VHDL ist für einen bestimmen Kreis von lernenden schwieriger weil VHDL Konstrukte wie in C (Pascal, etc) gestattet. Konkret: -nicht oder schwer synthetisierbare Dtaentypen verwendbar (records) -für edge detection die Funktion rising_edge verwenden -für schleifen loop verwenden -generics wie Precompiler directiven verwenden -vhdl-variable wie variable in C verwenden -rekursive Aufrufe -und anderer Quatsch den ich mir abgewöhnt habe In verilog ist die Hardware struktur besser erkennbar, weil die m.E. Verhaltensbeschreibung restriktiver ist. Der Anteil an synthesefähigen Codekonstruktion ist mei Verilog höher als in VHDL. Das Verilog als C-like gilt und VHDL nicht, ist nicht Teil meiner Argumentation und ich teile diese Auffassung auch nicht. Ob c oder pascal oder was auch immer ist auch wurscht, Kern ist das VHDL einen erfahrenen Programmierer mit geringer Erfahrung in digitalen schaltungsdesign leichter in (nicht-synthetisierbare) Abgründe führt als VHDL. Leichter hat es da ein völlig unbedarfter (meiner meinung nach).
Karl Könner schrieb: > Der Anteil an synthesefähigen > Codekonstruktion ist mei Verilog höher als in VHDL. Weil sehr viel implizit angenommen wird. So verwendet z.B. eine Beschreibung wie die hier mehrere implizite Mechanismen:
1 | always @ (posedge clock or posedge reset) |
2 | begin
|
3 | // pegelsensitiver Reset, obwohl oben "posedge" steht...
|
4 | if(reset) |
5 | ticker <= 0; |
6 | // ab hier: impliziter Takt...
|
7 | else if(ticker == 5000000) |
8 | ticker <= 0; |
9 | else if(start) |
10 | ticker <= ticker + 1; |
11 | end
|
Und ein Anfänger könnte da schnell mal auf die Idee kommen und sowas schreiben:
1 | always @ (posedge clock or posedge reset) |
2 | begin
|
3 | if(reset) |
4 | ticker <= resetwert; // Pech, das geht so nicht. Simulation passt nicht zur Hardware... |
5 | else if(ticker == 5000000) |
6 | ticker <= 0; |
7 | else if(start) |
8 | ticker <= ticker + 1; |
9 | end
|
Lothar Miller schrieb: > Weil sehr viel implizit angenommen wird. So verwendet z.B. eine > Beschreibung wie die hier mehrere implizite Mechanismen: > [c] > always @ (posedge clock or posedge reset) > begin > // pegelsensitiver Reset, obwohl oben "posedge" steht... > if(reset) Die sensitivity list eines VHDL prozesses enthält ja auch die Signale auf deren Änderung reagiert werden soll. Ich sehe da keinen Unterschied. > always @ (posedge clock or posedge reset) > begin > if(reset) > ticker <= resetwert; // Pech, das geht so nicht. Simulation passt Bin ich blind, oder warum sehe ich nicht das Problem? -- Marcus
Asynchrone Reset-Konstruktionen sehen bäh aus und sind zu vermeiden, außer sie sind unbedingt nötig. Dann muss man sich halt mit der "sperrigen" Formulierung die wohl die ersten Synthesewerkzeuge bei Verilog eingebürgert haben abfinden. Gab es nicht schon viele Diskussionen um die metastabile Problematik durch asynchrone Resets? In der Regel will man doch meist synchrone resets?
Marcus Harnisch schrieb: > Die sensitivity list eines VHDL prozesses enthält ja auch die Signale > auf deren Änderung reagiert werden soll. Ich sehe da keinen Unterschied. In VHDL wird nicht explizit auf eine "positive Flanke" eines statischen Signals reagiert, sondern auf jede Änderung. Die "unintuitive" Takterei in der Sensitivliste und Nichttakterei im getakteten Prozess ist zumindest befremdlich. Man kann erst anhand der Sensitivliste entscheiden, ob das jetzt ein kombinatorischer oder ein getakteter Prozess ist. Klar findet man das nach kurzer Zeit raus, aber es ist eigentlich verwirrend... > Bin ich blind, oder warum sehe ich nicht das Problem? Was, wenn sich bei aktivem Reset der resetwert ändert (z.B. DIP-Schalter)? Muss ich dann noch "or posedge resetwert or negedge resetwert" mit aufnehmen? Was passiert dann aber, wenn sich der resetwert ändert, während der reset inaktiv ist? Wird dann der Prozess "getaktet"? > Bin ich blind Nein, du machst nur schon lange Verilog, hast dich an diese seltsamen Eigenheiten gewöhnt und wirst deshalb solche Fragen nicht mehr stellen und damit verbundene Fehler nie wieder machen... Dogbert schrieb: > In der Regel will man doch meist synchrone resets? Das ist plattformabhängig. Aber man will auf jeden Fall einen Reset, der synchron inaktiv wird.
Lothar Miller schrieb: >> Bin ich blind, oder warum sehe ich nicht das Problem? > Was, wenn sich bei aktivem Reset der resetwert ändert (z.B. > DIP-Schalter)? Genau wie in einer entsprechenden VHDL Beschreibung wird der Prozess nur dann aktiviert, wenn sich clock oder reset ändern, bzw. eine steigende Flanke haben. Der geränderte resetwert wird daher in der Simulation mit der nächsten steigenden clock Flanke übernommen. -- Marcus
Marcus Harnisch schrieb: > Der geränderte resetwert ;-) > Der geränderte resetwert wird daher in der Simulation mit > der nächsten steigenden clock Flanke übernommen. Der Wert wird also bei aktivem Reset nur mit einer Taktflanke übernommen? Der resetwert sollte aber doch eher mit einer Änderung seiner selbst übernommen werden. So wird es die Hardware schließlich auch machen... Oder andersrum: wie wird diese VHDL-Beschreibung in Verilog aussehen?
1 | signal a,b,c,r : std_logic; |
2 | :
|
3 | process (b,c,r) begin |
4 | if r='1' then |
5 | a <= b; |
6 | elsif rising_edge(c) then |
7 | a <= a+1; |
8 | end if; |
9 | end process; |
wenn c eine Clock ist, sehr schnell im Vergleich zum menschlichen Vermögen, Schalter zu betätigen, würde ich mit dem hier keine Probleme erwarten?
1 | always @ (posedge c) |
2 | if (r) a <= b; |
3 | else if (c) a <= a + 1; |
...und man braucht nicht mal unbedingt begin und end drumherum ;)
Micha schrieb: > wenn c eine Clock ist, sehr schnell im Vergleich zum menschlichen > Vermögen Hört sich nach impliziter Annahme an... Könnte ja sein, dass der Takt abgeschaltet werden könnte, und dann bei aktivem reset keine Taktflanke mehr kommt? berndl schrieb: > always @ (posedge c or b or r) > (wuerde ich mal behaupten) Warum schreibt man dann für einen simplen asynchronen Reset eine Flanke hin, wenn für einen asynchronen Reset mit zusätzlichem Signal diese Flanke dann wegfällt? Simulationszeitaufwand sollte da nicht das Argument sein dürfen...
berndl schrieb: > always @ (posedge c or b or r) > (wuerde ich mal behaupten) Das bildet nicht das Verhalten eines typischen D-FF mit async reset ab. Die sensitivity list sagt dass auch bei einer fallenden Flanke von b or r etwas passiert. So ist das
1 | always @(posedge clk or posedge reset) |
2 | if (reset) // priorität auf reset |
3 | //reset
|
4 | else
|
5 | //normal
|
eigentlich eine exakte Beschreibung. Ohne simulation mismatches. Die Problematik liegt in der Timinganalyse und der asynchronen natur von 2 Takten.
berndl schrieb: > always @ (posedge c or b or r) > (wuerde ich mal behaupten) Geht nicht. Wenn sich resetwert ändert während reset inaktiv ist, wird der clock Zweig ausgeführt... :^) Das gewünschte Verhalten kann man natürlich auch in Verilog beschreiben. Aber im Ernst, das ist doch eigentlich ein akademisches Problem oder?
berndl schrieb: > always @ (posedge c or b or r) > (wuerde ich mal behaupten) Wenn ich mich richtig erinnere geht das nicht. Die Quartus Hilfe sagt dazu jedenfalls folgendes: "In an Event Control at the specified location in a Verilog Design File (.v), you specified an Event Control that contains both double-edge events and single-edge events. A double-edge event is a signal that is sensitive to both positive and negative edges, for example, always @(A), and usually represents combinational logic. A single-edge event is a signal that is sensitive to just one edge, for example always @(posedge B), and usually represents sequential logic (logic with clocked registers). You cannot include both event types in one Event Control." http://quartushelp.altera.com/12.0/mergedProjects/msgs/msgs/evrfx_veri_unsupported_mixed_edge_event_expression.htm
Wie deine Lernkurve verlaufen wird, hängt sehr stark von deinem Simulator ab. Du musst wissen was im Inneren abgeht. Die Zeit fürs Fitten steigt auch sehr schnell und du willst ja effektiv sein. VHDL ist mit den Typprüfungen mit unter sehr pingelig. Doch bei größeren Designs ist das der Rettung. Das muss man nur mal verstanden haben. Da wichtigste ist du musst die Sache an sich verstehen. auf allen Signalen/wire ist eine Information und diese muss auch zu einem Zeitpunkt gültig sein. Bei einem C Programm und man kann genau in der betrachten Zeile den Zustand der CPU diskutieren und auch den nächsten Wert ableiten. Dagegen beim FPGA läuft der ganze Code parallel. Du beschreibtst mit HDL eine Verdrahtung und baust eine Schaltung.
René D. schrieb: > Wie deine Lernkurve verlaufen wird, hängt sehr stark von deinem > Simulator ab. Das is wohl ein guter Punkt. Als Hobbyist/Neueinsteiger in das Thema FPGA hab ich zunächst mal angefangen, ein Grundlagenbuch zum Thema zu lesen, paar Tutorials auf der Altera Website durchzuarbeiten und mit einem Evaluation Board (Cyclon II) einfache Projekte zu realisieren. Bzgl. "Synthese" MUSS man einfach ins kalte Wasser springen wenn man überhaupt was erreichen will. Dagegen kann man das Thema "Simulation" notfalls erst mal auf die lange Bank schieben... später, irgendwann oder "manana" wie der Spanier sagt. Bin ich der einzige der so angefangen hat??? Gestern hab ich auf meinem Board eine Implementation der MCPU (minimalistische CPU, Lehrbeispiel von opencores) mit einem einfachen Speicher-Editor sowie einem Display, das diverse Registerinhalte anzeigt zum laufen gebracht. Alles ganz ohne Simulation. Funktioniert trotzdem. Einfach nur durch Hineindenken in die Logik und gründliche Vorbereitung. Hab mich bisher um das Thema Simulation gedrückt - genauso wie ich mich privat manchmal um den Zahnarztbesuch drücke - vermutlich ist beides irgendwann doch zwingend fällig ;) Obwohl ich denke das es ganz gut ist, lieber vorher gründlich über die Logik nachzudenken, als in Gewissheit der verfügbaren Simuliererei irgendwelchen "Scheiss" halbherzig zusammenzufrumsen und dann ewig dran rumzusimulieren und zu flicken. Ich bin auch bei konventioneller Programmierung eigentlich kein Freund von Debuggern. Die verleiten zu oberflächlicher Projektvorbereitung.
Marcus Harnisch schrieb: > Aber im Ernst, das ist doch eigentlich ein akademisches Problem oder? Ja, an sich schon, aber dank der DIP-Schalter zum Einstellen eines Resetwertes (z.B. Konfiguration oder sowas) gar nicht mal so abwegig... Ich würde sagen, der Einstieg von nichts bis zum Blinklicht ist bei Verilog einfach, die gleich danach folgende Lernkurve aber steiler (schwieriger), weil man sich dann erst mal die impliziten Vorgaben erarbeiten muss. In VHDL ist der Anfang gefühlt schwerer (oder eher umständlicher), weil vor dem ersten Blinklicht der Synthesizer schon ein paar mal an irgendwelchen "Kleinigkeiten" wie unpassenden Typen herummäkelt. Allerdings hat man damit die meisten Probleme kennengelernt und kann mit gleicher Steigung weitermachen.
Lothar Miller schrieb: > Marcus Harnisch schrieb: >> Aber im Ernst, das ist doch eigentlich ein akademisches Problem oder? > Ja, an sich schon, aber dank der DIP-Schalter zum Einstellen eines > Resetwertes (z.B. Konfiguration oder sowas) gar nicht mal so abwegig... Aber wegen sowas würde man doch keine Register einbauen, die sich im Reset wie Latches verhalten. Da wird im ersten aktiven Takt abgetastet und gut is'. > Ich würde sagen, [...] </nick> Der wesentliche Grund, dafür (System)Verilog zu lernen ist, dass man daran in der Industrie nicht vorbeikommt. Heute leistet sich kaum ein IP Hersteller beide Sprachen, und wenn's denn eine sein muss... Alle "VHDL Designs" die mir in den letzten Jahren untergekommen sind, sind eigentlich mixed language. Bei großen FPGA Designs werden immer häufiger tools aus dem ASIC Bereich eingesetzt, die traditionell Verilog unterstützen, während die VHDL Fähigkeiten oft hinterherhinken. Gruß Marcus
Micha schrieb: > Alles ganz ohne Simulation. Funktioniert trotzdem. > Einfach nur durch Hineindenken in die Logik und gründliche Vorbereitung. Ich wage mal zu behaupten, dass diese Methode gerade mal für Minimaldesigns gilt. Sobald Du beginnst, wirklich zu entwickeln, ist der Simulator unabdingbar, weil Du einfach schneller weist ob's tut. Du weist bei der Simulation einer Situation in 2' was der geänderte Block macht und ob die angestammte Funktion noch tut und hast alle Signale beobachtbar. Oder aber Du gehst 20' durch die Synthese, das Zeugs funktioniert nicht und Du hast auch nicht die richtigen Signale auf dem SignalTap/ChipScope, also nochmals 20'. Noch Fragen? Man gewinnt immer, wenn man den Iterationsloop klein hält!
Micha schrieb: > Obwohl ich denke das es ganz gut ist, lieber vorher gründlich über die > Logik nachzudenken, als in Gewissheit der verfügbaren Simuliererei > irgendwelchen "Scheiss" halbherzig zusammenzufrumsen und dann ewig dran > rumzusimulieren und zu flicken. Ich bin auch bei konventioneller > Programmierung eigentlich kein Freund von Debuggern. Die verleiten zu > oberflächlicher Projektvorbereitung. Wobei Simulation zunächst nichts mit einem Debugger zu tun hat. Die korrekte Analogie wären unit tests. Simulation hilft dabei nachzuweisen, dass Dein Design fehlerarm ist. Du musst das ja auch anderen demonstrieren können, und kannst den Kollegen nicht sagen: "Hier ist der Quellcode. Denkt mal gründlich drüber nach, dann wisst Ihr dass keine Fehler drin sind." -- Marcus
Micha schrieb: > René D. schrieb: >> Wie deine Lernkurve verlaufen wird, hängt sehr stark von deinem >> Simulator ab. > > Bzgl. "Synthese" MUSS man einfach ins kalte Wasser springen wenn man > überhaupt was erreichen will. Dagegen kann man das Thema "Simulation" > notfalls erst mal auf die lange Bank schieben... später, irgendwann oder So habe ich es auch gemacht. > Gestern hab ich auf meinem Board eine Implementation der MCPU ....... > zum laufen gebracht. Alles ganz ohne Simulation. Funktioniert trotzdem. Wenn da nicht jemand den Code vorher simuliert hat. > Obwohl ich denke das es ganz gut ist, lieber vorher gründlich über die > Logik nachzudenken, als in Gewissheit der verfügbaren Simuliererei Das Denken für die Logic musst du bekommen, der Simulator kann es nicht vermitteln. Der Simulator ist nicht in der Lernkurve wegzudiskutieren. Lieber einpaar Testfälle in die Testbench und nach jeder Änderung muss die Testbench laufen. Da kommt schon eine Menge zu Tage. Gutes Beispiel, wenn die Daten einen Takt zu spät gültig sind. Passiert schnell.
René D. schrieb: > Wenn da nicht jemand den Code vorher simuliert hat. Nee, den code hab ich aus der funktionalen Spezifikation der MCPU, wie sie der Autor beschrieben hat, komplett neu geschrieben. Der originale Code ist mit paar Tricks so auf Kürze getrimmt dass ich ihn streckenweise nicht mal verstehe. Aber Du (bzw. auch alle anderen die das Argument gebracht haben) hast Recht: irgendwann wirds dringend Zeit, sich dem Thema Simulation zu stellen. Mal schauen obs da bei Altera ein brauchbares Video-Training dazu gibt.
Dogbert schrieb: > Systemverilog ist besser. Sieht mir aber auch sehr krypisch und hardwarenah aus. Als systembeschreibende Sprache stelle ich mir was anderes vor.
Markus Wagner schrieb: > Dogbert schrieb: >> Systemverilog ist besser. > Sieht mir aber auch sehr krypisch und hardwarenah aus. Nun ja, SV ist eigentlich eine Kombination verschiedener Sprachen. Ein Teil von SV erlaubt OOP und ist damit so ziemlich das Gegenteil von "hardwarenah". Das "kryptisch" lasse ich mal stehen :) > Als systembeschreibende Sprache stelle ich mir was anderes vor. Und was?
Dogbert schrieb: > Gab es nicht schon viele Diskussionen um die metastabile Problematik > durch asynchrone Resets? In der Regel will man gar keine Resets und die sind auch technisch nicht nötig, weil es ja das init gibt.
Markus Wagner schrieb: > In der Regel will man gar keine Resets und die sind auch technisch nicht > nötig, weil es ja das init gibt. Wie versetzt du den FPGA wieder in einen Urzustand, wenn das nötig ist?
high tec ing schrieb: > Wie versetzt du den FPGA wieder in einen Urzustand, wenn das nötig ist? Du initialisierst ein Neuladen des FPGAs...
high tec ing schrieb: > Markus Wagner schrieb: >> In der Regel will man gar keine Resets und die sind auch technisch nicht >> nötig, weil es ja das init gibt. > Wie versetzt du den FPGA wieder in einen Urzustand, wenn das nötig ist? Das ist in der Regel nicht nötig. Weite Teile der Hardware können auch nicht resettet werden. Wenn, reicht ein HW-Reset. Warum sollte man HW resetten können müssen? Lothar Miller schrieb: > high tec ing schrieb: >> Wie versetzt du den FPGA wieder in einen Urzustand, wenn das nötig ist? > Du initialisierst ein Neuladen des FPGAs... Eben! Z.B. mit einem Mikrocontroller.
Markus Wagner schrieb: >> Du initialisierst ein Neuladen des FPGAs... > Eben! Z.B. mit einem Mikrocontroller. Oder mit einem Taster. Der den landläufigen Reset-Taster ersetzt und im endgültigen Design weggelassen werden kann, ohne irgendwelchen Overhead zu hinterlassen...
Lothar Miller schrieb: > Lothar Miller Sag mal Lothar, was meinen die Leute eigentlich genau, wenn sie nach der Steilheit der Lernkurve fragen? Mich hatte kürzlich auch jemand auf Englisch gefragt: "How steep is the learning curve to help with it?" (gEDA mailing list) Ich habe mich um die konkrete Antwort herungedrückt,bevor ich was falsches sage. Was wollen die Leute eigentlich, eine steile oder flache Kurve? (Den Wikipedia-Artikel kenne ich .)
Eine flache Lernkurve, denn der hat ja schon ausgelernt :-)
Lothar Miller schrieb: > Dogbert schrieb: >> In der Regel will man doch meist synchrone resets? > Das ist plattformabhängig. > Aber man will auf jeden Fall einen Reset, der synchron inaktiv wird. Ähemm.. da liest man mal wieder in diesem Forum und stolpert über so eine Formulierung. ts.. ts.. ts.. Also, ein echter Reset kommt und geht asynchron und er räumt auf mit allem, was da in der chipinternen Schaltung kreucht und fleucht - und er setzt (hoffentlich) alle Teile in ihren Ausgangszustand. Da ist kein Platz für "einen Reset, der synchron inaktiv wird". Wenn der Reset logischermaßen asynchron geht, dann steht das gesamte System eben so herum, wie der Reset es hinterlassen hat, bis daß endlich die erste Taktflanke kommt. Was dann passiert, ist ne andere Sache.. Also ICH will niemals einen synchronen Reset, sondern immer nur einen, der auch dann funktioniert, wenn der/die chipinternen Takte gestört sein sollten. Das ist nämlich was anderes, als irgendeinen Automaten in den idle-Zustand zu überführen. Gelle? W.S.
W.S. schrieb: > Also ICH will niemals einen synchronen Reset, sondern immer nur einen, > der auch dann funktioniert, wenn der/die chipinternen Takte gestört sein > sollten. Das ist nämlich was anderes, als irgendeinen Automaten in den > idle-Zustand zu überführen. Gelle? Da ist was dran!
W.S. schrieb: > Lothar Miller schrieb: >> Dogbert schrieb: >>> In der Regel will man doch meist synchrone resets? >> Das ist plattformabhängig. >> Aber man will auf jeden Fall einen Reset, der synchron inaktiv wird. > Ähemm.. da liest man mal wieder in diesem Forum und stolpert über so > eine Formulierung. ts.. ts.. ts.. Du hast m.E. das eigentliche Problem nicht verstanden. > Also, ein echter Reset kommt und geht asynchron Der Reset als Pegel am Pin schon. Aber nicht das Reset-Signal im FPGA. Da darf er (wenn es shon unbedingt sien muss) gern asynchron kommen, er muss aber auf jeden Fall synchron deaktiviert werden. Denn sonst passiert dir das hier täglich: http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren Weil ein Reset eben nicht "global" ist, sondern als Signal an jedes FF geroutet wird. Und selbst ein "globaler Reset" müsste erst mal mit dem Takt synchronisiert werden, denn sonst hast du evtl. gleich bei der ersten Taktflanke eine Setup/Hold Zeiten Verletzung. > Also ICH will niemals einen synchronen Reset, sondern immer nur einen, > der auch dann funktioniert, wenn der/die chipinternen Takte gestört sein > sollten. Das ist nämlich was anderes, als irgendeinen Automaten in den > idle-Zustand zu überführen. Gelle? Das wäre also das "Aktiv werden" des Resets. > Da ist kein Platz für "einen Reset, der synchron inaktiv wird" "Inaktiv werden" ist die andere Seite des Resets, nämlich die, wo anschliessend das Design loslaufen soll. Ein Reset darf selbstverständlich asynchron aktiv werden. Er muss aber synchron inaktiv werden. Sonst hast du ein System, das "ab und zu nicht richtig anläuft". Wenn es aber anläuft, dann läuft es tagelang stabil. Such einfach mal hier im Forum, dieser Fall taucht immer wiedermal auf. > Also ICH will niemals einen synchronen Reset, sondern immer nur einen, > der auch dann funktioniert, wenn der/die chipinternen Takte gestört sein > sollten. Warum? Wenn das FPGA nicht mehr richtig funktioniert, dann hilft auch ein Reset nichts mehr. Oder soll da "Sicherheitstechnik" ins FPGA implementiert werden? Die müsste aber auf einer anderen Ebene angreifen... Markus Wagner schrieb: > W.S. schrieb: >> Also ICH will niemals einen synchronen Reset, sondern immer nur einen, >> der auch dann funktioniert, wenn der/die chipinternen Takte gestört sein >> sollten. Das ist nämlich was anderes, als irgendeinen Automaten in den >> idle-Zustand zu überführen. Gelle? > Da ist was dran! Was denn? Wenn ich ein FPGA in einen "sicheren" Zustand versetzen will, dann halte ich den Config-Pin (oder Lade-Pin oder sonstwas, was die Initialisierung auslöst) auf einem passenden Pegel. Dann nimmt das FPGA den Zustand ein, der in den ersten paar Millisekunden auch eingenommen wird. Und dieser Zustand muss ja eigentlich auch "sicher" sein...
Markus Wagner schrieb: > W.S. schrieb: >> Also ICH will niemals einen synchronen Reset, sondern immer nur einen, >> der auch dann funktioniert, wenn der/die chipinternen Takte gestört sein >> sollten. Das ist nämlich was anderes, als irgendeinen Automaten in den >> idle-Zustand zu überführen. Gelle? > Da ist was dran! Dann hast du ein Design was in nicht in den FPGA gehört. Die Taktdomain sind mitunter auf verschiede Taktquellen umschaltbar. Auf dieses Level musst du erstmal kommen. Passt nicht zum Thema Lernkurve. Am Anfang steht ein Takt, der sich durchs ganze Design zieht.
René D. schrieb: > Am Anfang steht ein Takt, der sich durchs ganze Design zieht. ok, da ist auch was dran. Wie passen die beiden konträren Anforderungen zusammen?
René D. schrieb: > Dann hast du ein Design was in nicht in den FPGA gehört. Ah ja. Und wohin gehört es dann? Ich mach dir mal nen Vorschlag: Definiere einfach mal, was das für ein Design ist, das in ein FPGA gehört - das ist vermutlich einfacher, als alle anderen Designs davon auszuschließen.. Nochmal zum Reset: Ein Reset-Signal hat die Aufgabe, die gesamte Schaltung UNBEDINGT in ihren Grundzustand zu versetzen und dort auch zu halten, solange es ansteht - und was der Grundzustand ist, legt der Entwickler fest. Jede Logik und jeder Schaltkreis (wenn wir mal den 7400 und seine Brüder sowie schlampig entwickeltes Zeugs außen vorlassen) kommt erstmal in diesen Grundzustand, sobald die Versorgungsspannung hoch genug ansteht. Der System-Anlauf ist jedoch ne andere Sache. Wer beispielsweise chipinterne PLL's benutzt, wird vermutlich erst ein PLL_OK-Signal brauchen, ehe der so ezeugte Takt auf die Gatter losgelassen wird. Und so weiter. Aber das alles findet erst statt, wenn das Resetsignal shon längst vorbei ist. W.S.
W.S. schrieb: > Jede Logik und jeder Schaltkreis (wenn wir mal den 7400 und seine > Brüder sowie schlampig entwickeltes Zeugs außen vorlassen) kommt erstmal > in diesen Grundzustand, Das tut ein FPGA nach dem Einschalten doch auch. Garantiert. Denn es muss zuerst initialisiert werden. Ein zusätzliches Resetsignal ist für diesen Vorgang nicht nötig. > Wer beispielsweise chipinterne PLL's benutzt, wird vermutlich erst ein > PLL_OK-Signal brauchen, ehe der so ezeugte Takt auf die Gatter > losgelassen wird. Und so weiter. Das macht ein FPGA selber, wenn es korrekt konfigiruiert ist. Mehr dazu im Datenblatt. Solche Allerweltsprobleme sind den FPGA Designern auch bekannt. Und deshalb bieten sie entsprechende chipinterne Komponenten zur Abhilfe an... > Definiere einfach mal, was das für ein Design ist, das in ein FPGA > gehört Ich bin zwar nicht direkt angesprochen, aber ich würde sagen: eines, dessen Aufgabe ohne FPGA nicht mit vertretbarem Aufwand gelöst werden könnte. Sinnlos und eine Schönrechnerei sind z.B. locker 90% der Designs, wo ein Softcore eingesetzt wird. Ein FPGA wird ehrlich gesagt niemals eine Chance gegen ein ASIC (aka. Mikrocontroller) haben, wenn die vom FPGA zu erledigende Aufgabe auch von diesem ASIC/uC erledigt werden könnte. So bekommt man z.B. mit dem Freescale i.MX6 für kleines Geld einen Prozessor, der (wenn überhaupt) niemals so leistungsfähig in ein FPGA gepackt werden könnte. Bestenfalls eben als fertigen Hard-Core, wie es die FPGA-HErsteller mit ihren ARM-Lizenzen jetzt machen. Stefan schrieb: > Lothar Miller schrieb: > Sag mal Lothar, > was meinen die Leute eigentlich genau, wenn sie nach der Steilheit der > Lernkurve fragen? Naja, da du explizit mich frägst, werde ich meine Sicht der Dinge erläutern: eine steile Lernkurve bedeutet, dass die ersten Schritte schwer sind. Ob die Lernkurve danach flacher wird steht auf einem anderen Blatt. Eine flache Lernkurve bedeutet umgangssprachlich, dass man mit wenig Aufwand viel erreicht. Ideal wäre es, wenn es so weiterginge. So kann z.B. ein Hardwareentwickler, der seine Lebtage lang Schaltpläne gezeichnet hat, mit einer Schematic-Toolchain erst mal eine flache Lernkurve erleben. Interessant wird es dann, wenn komplexere Dinge gemacht werden sollen. Dann wird die (niemals endende) Lernkurve urplötzlich steil und er muss evtl. sogar lernen, dass ein größeres Design so nicht möglich ist. > Was wollen die Leute eigentlich, eine steile oder flache Kurve? Sie wollen umgangssprachlich eine flache Lernkurve, der Erfolg taucht in dieser Formulierung erst mal gar nicht auf. > (Den Wikipedia-Artikel kenne ich .) Ich nicht. Für den umgangssprachlichen Gebrauch des Begriffs "steile Lernkurve" ist m.E. der Artikel falsch. Denn sonst wäre eine steile Lernkurve gut, weil man sich mit wenig Aufwand/Zeit viel Wissen aneignen könnte.
:
Bearbeitet durch Moderator
W.S. schrieb: > René D. schrieb: >> Dann hast du ein Design was in nicht in den FPGA gehört. > > Ah ja. Und wohin gehört es dann? Ich mach dir mal nen Vorschlag: > Definiere einfach mal, was das für ein Design ist, das in ein FPGA > gehört - das ist vermutlich einfacher, als alle anderen Designs davon > auszuschließen.. Wenn du so auf Kriegsfuß gegen diese Technologie stehst, dann baue mit CMOS und TTL Gatter deinen Logicgräber weiter. Lothar hat noch einen interessanten Aspekt gebracht. Softcores können nicht mit den Mikrocontrollern mit halten. Ich habe auch nie verstanden, warum als Referenzsystem Linux in dem FPGA genutzt werden sollte. Es gibt auch schlankere Betriebssysteme. Die Hinzunahme eines Softcores kann aber die Entwicklungszeit in einem FPGA zuverkürzen. Da es Aufgaben geben kann, wie exterene Sensoren mit einem Datenprotokoll oder Kalibierdaten einlesen, diese Aufgaben können sich während der Entwicklung auch schnell ändern und dafür jedesmal des HDL Design anfassen ist auf Dauer uneffektiv. Hierfür ist ein Softcore ein interessante ergänzend Möglichkeit.
wenn ich diese Resetdiskussion richtig deute, dann stehen doch 2 sich eigentlich widersprechende Aussagen: 1.) W.S. will unbedingt einen asynchronen Reset, damit bekommt man ein FPGA ruhig auch wenn z.B. der externe Oszillator ausgefallen ist 2.) Eigentlich alle anderen wollen einen synchronen Reset (wenn ueberhaupt einen Reset), damit gewaehrleistet ist, dass die Schaltung nach weggehen des Reset sauber einsteigt. Und das geht eben nur synchron aus einem getakteten FlipFlop Man kann aber 1. und 2. 'gleichzeitig' haben: * Der externe Reset geht auf ein paar Synchronisierungs-FFs * Jetzt kann man alle Signale (Reset-in und z.B. 3 FFs) zusammen ODERn (wenn Reset positiv aktiv) und im FPGA verwenden * Noch ein Timing-Ignore auf den Reset-in (aber nicht auf die FFs!) * Am jeweiligen FF diesen effektiven Reset als asynchronen Reset verwenden So macht man das z.B. bei ASICs, die aus dem POn-Reset sauber anlaufen muessen.
berndl schrieb: > Man kann aber 1. und 2. 'gleichzeitig' haben: Wenn man das passende FPGA hat. Wenn man das falsche FPGA hat, dann kostet allein die asynchrone Beschreibung des so einsynchronisierten Resets Ressourcen. Wie schon im 5 Jahre alten Beitrag "Re: Hardware mit VHDL "richtig" beschreiben." ausgeführt. Aber wie gesagt: für einen "Generalreset" zerre man einfach kurz am Konfig-Pin... BTW: was an einem wirklich asynchronen Reset äusserst lästig und zeitaufwendig in der Fehlersuche ist, ist ein kurzer EMV-Spike, der dir nur das halbe FPGA zurücksetzt, die andere Hälfte aber nicht... BTDT.
:
Bearbeitet durch Moderator
> Ich habe auch nie verstanden, warum als Referenzsystem Linux in dem FPGA > genutzt werden sollte. Es gibt auch schlankere Betriebssysteme. Linux hat ein paar Voteile: - Es gibt notfalls eine interaktive Shell (minimal busybox), mit der man in-system rumstochern kann und die auch per UART geht. - Man kann Programme (bis auf die HW-Spezialitäten) 1:1 erstmal auf dem PC entwickeln und testen. Man muss sich nicht um verkrüppelte Libraries, oder verbuggte/prprietäre C-only Compiler kümmern. Selbst die uLibc ist für fast alle Anwendungen ausreichend. - Es gibts nichts anderes, was bei Netzwerk- und Filesystemunterstützung an Linux rankommt. - Wenn man uCLinux nimmt, muss man für die HW nichtmal Treiber schreiben, sondern kann alles aus dem Userspace machen ;) Es gibt natürlich auch Anwendungen, wo es nicht taugt (Bootzeit, zu wenig RAM, etc.).
berndl schrieb: > 1.) W.S. will unbedingt einen asynchronen Reset, damit bekommt man ein > 2.) Eigentlich alle anderen wollen einen synchronen Reset (wenn Viel wichtiger wäre zu schauen, was für einen Reset die Zielplattform will. Für Quartus habe ich Testcases wo für synchrone Resets extra logik eingebaut wird; asynchrone Resets möchte Quartus gerne (zentral) einsynchronisiert haben um dann asynchron zu den Registern weiter zu gehen. Wer das nicht glaubt möge selbst ein paar Testcases schreiben und synthetisieren. ->Lektüre: "Quartus II Handbook: Recommended HDL Coding Styles" Die Diskussion ist absolut akademisch, natürlich geht beides, ob das sinnvoll ist bestimmt in erster Linie die Zielplattform. Wenn der Designer die Einschränkungen nicht berücksichtigen kann macht er was falsch. Zurück zum Thema: Mir ist immer das Verständnis von Verilog viel einfacher gefallen, VHDL hat für meinen Geschmack zuviel von der eigentlichen Logik ablenkende Konventionen drumrum. Ich halte Verilog für schlanker und zielgerichteter und somit auch für eleganter.
abcd schrieb: > Ich halte Verilog für schlanker Das muss nicht sein. Man darf VHDL nur nicht so schreiben, wie es in den Lehrbüchern aus dem letzten Jahrtausend gemacht wird. Siehe dort: http://www.lothar-miller.de/s9y/archives/88-VHDL-vs.-Verilog-am-Beispiel-einer-Stoppuhr.html > und zielgerichteter Das kommt auf das Ziel an. Verilog ist mir zu implizit. Man muss zuviel Hintergrund wissen, bis man das Verhalten einer Beschreibung versteht. In VHDL steht alles da wie es gemeint ist und funktionieren soll... > und somit auch für eleganter. Diesen logischen Schluss aus "schlank und zielgerichtet" kann ich nicht so ohne Weiteres nachvollziehen. Aber da geht es um die Frage "Was ist Eleganz?" Und gerade über Schönheit ließe sich trefflich diskutieren. Obwohl... irgendwie fehlt mir der Fragezeichenoperator in VHDL. Siehe den Beitrag "Re: SPLD (GAL) - welche Software" > asynchrone Resets möchte Quartus gerne (zentral) einsynchronisiert haben > um dann asynchron zu den Registern weiter zu gehen. Und dabei geht es nicht vorrangig um Quartus, sondern um dieses eine spezielle FPGA, das seine spezielle Eigenheit eingebaut hat. Bei der nächsten Generation kann das schon ganz anders aussehen... > Wer das nicht glaubt möge selbst ein paar Testcases schreiben und > synthetisieren. Das ist immer der beste Weg, sich in eine neue Architektur einzuarbeiten. Den Prozess nennt man "Lernen".
:
Bearbeitet durch Moderator
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.