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...).
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.)
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:
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?
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@(posedgeclkorposedgereset)
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:> 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 .)
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 imFPGA.
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.
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.
> 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".
Thread beobachten
Seitenaufteilung abschalten