Frage zur Lernkurve VHDL vs. Verilog

[Micha (Gast)]

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?

[berndl (Gast)]

<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...

[Micha (Gast)]

ä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 ;)

[M. W. (elektrowagi78)]

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.

[berndl (Gast)]

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...).

[Lothar M. (lkmiller) (Moderator)]

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

[Dogbert (Gast)]

Systemverilog ist besser.
54 Zeilen und übersichtlich, man muss es halt nur beherrschen.

module stopwatch ( input clk, input reset, input _start, output logic[6:0] segments, output logic dp, output logic[3:0] an ); parameter[6:0] ss_table[9]= // seven segment table '{7'b1000000, 7'b1111001, 7'b0100100, 7'b0110000, 7'b0011001, 7'b0010010, 7'b0000010, 7'b1111000, 7'b0000000, 7'b0010000}; logic[32:0] prescaler, muxcnt; logic[3:0] m, s10, s1, st; logic[3:0] carry; function automatic [3:0] mux; input[3:0] d0, d1, d2, d3; input[1:0] which; logic[3:0] array[4]; begin array='{d0,d1,d2,d3}; mux=array[which]; end endfunction always @(posedge clk or posedge reset) begin if (reset) begin muxcnt=0; prescaler=0; {m,s10,s1,st}<={4'd0,4'd0,4'd0,4'd0}; an=~4'd0; end else begin segments=ss_table[mux(muxcnt[17:16], m, s10, s1, st)]; dp=mux(muxcnt[17:16], 1, 0, 1, 0 ); an=~(4'b1<<muxcnt[17:16]); muxcnt++; if (_start) if (prescaler==4999999) begin prescaler=0; carry={m==9,s10==5,s1==9,st==9}; {m,s10,s1,st}<={(m+carry[2])*~carry[3],(s10+carry[1])*~carry[2],(s1+carry[0])*~carry[1],(st+1)*~carry[0]}; end else prescaler++; end end endmodule

[josef f. (Gast)]

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!

[Fitzebutze (Gast)]

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.)

[Lothar M. (lkmiller) (Moderator)]

Dogbert schrieb:
> übersichtlich
Ja, so ist es:

carry={m==9,s10==5,s1==9,st==9}; {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...

[Micha (Gast)]

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 ;)

[Dogbert (Gast)]

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.

[high tec ing (Gast)]

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?

[Karl Könner (Gast)]

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ß,

[Lothar M. (lkmiller) (Moderator)]

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...

[Karl Könner (Gast)]

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).

[Lothar M. (lkmiller) (Moderator)]

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:

always @ (posedge clock or posedge reset) begin // pegelsensitiver Reset, obwohl oben "posedge" steht... if(reset) ticker <= 0; // ab hier: impliziter Takt... else if(ticker == 5000000) ticker <= 0; else if(start) ticker <= ticker + 1; end

Und ein Anfänger könnte da schnell mal auf die Idee kommen und sowas 
schreiben:

always @ (posedge clock or posedge reset) begin if(reset) ticker <= resetwert; // Pech, das geht so nicht. Simulation passt nicht zur Hardware... else if(ticker == 5000000) ticker <= 0; else if(start) ticker <= ticker + 1; end

[Marcus H. (mharnisch)]

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

[Dogbert (Gast)]

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?

[Lothar M. (lkmiller) (Moderator)]

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.

[Marcus H. (mharnisch)]

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

[Lothar M. (lkmiller) (Moderator)]

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?

signal a,b,c,r : std_logic; : process (b,c,r) begin if r='1' then a <= b; elsif rising_edge(c) then a <= a+1; end if; end process;

[berndl (Gast)]

always @ (posedge c or b or r)
(wuerde ich mal behaupten)

[Micha (Gast)]

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?

always @ (posedge c) if (r) a <= b; else if (c) a <= a + 1;

...und man braucht nicht mal unbedingt begin und end drumherum ;)

[Lothar M. (lkmiller) (Moderator)]

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...

[Dogbert (Gast)]

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

always @(posedge clk or posedge reset) if (reset) // priorität auf reset //reset else //normal

eigentlich eine exakte Beschreibung. Ohne simulation mismatches.

Die Problematik liegt in der Timinganalyse und der asynchronen natur von 
2 Takten.

[Marcus H. (mharnisch)]

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?

[auch Hans (Gast)]

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

[René D. (Firma: www.dossmatik.de) (dose)]

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.

[Micha (Gast)]

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.

[Lothar M. (lkmiller) (Moderator)]

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.

[Marcus H. (mharnisch)]

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

[P. K. (pek)]

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!

[Marcus H. (mharnisch)]

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

[René D. (Firma: www.dossmatik.de) (dose)]

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.

[Micha (Gast)]

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.

[M. W. (elektrowagi78)]

Dogbert schrieb:
> Systemverilog ist besser.
Sieht mir aber auch sehr krypisch und hardwarenah aus. Als 
systembeschreibende Sprache stelle ich mir was anderes vor.

[Marcus H. (mharnisch)]

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?

[M. W. (elektrowagi78)]

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.

[high tec ing (Gast)]

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?

[Lothar M. (lkmiller) (Moderator)]

high tec ing schrieb:
> Wie versetzt du den FPGA wieder in einen Urzustand, wenn das nötig ist?
Du initialisierst ein Neuladen des FPGAs...

[M. W. (elektrowagi78)]

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.

[Lothar M. (lkmiller) (Moderator)]

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...

[Stefan (Gast)]

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 .)

[Master MINT (Gast)]

Eine flache Lernkurve, denn der hat ja schon ausgelernt :-)

[W.S. (Gast)]

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.

[M. W. (elektrowagi78)]

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!

[Lothar M. (lkmiller) (Moderator)]

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...

[René D. (Firma: www.dossmatik.de) (dose)]

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.

[M. W. (elektrowagi78)]

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?

[W.S. (Gast)]

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.

[Lothar M. (lkmiller) (Moderator)]

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.

[René D. (Firma: www.dossmatik.de) (dose)]

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.

[berndl (Gast)]

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.

[Lothar M. (lkmiller) (Moderator)]

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.

[Georg A. (georga)]

> 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.).

[abcd (Gast)]

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.

[Lothar M. (lkmiller) (Moderator)]

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".

[Duke Scarring (Gast)]

Lothar Miller schrieb:
> Den Prozess nennt man "Lernen".

learn: process( all) begin -- SCNR

Duke