Hallo zusammen,
bin beim Googeln auf folgende Seite gestoßen:
www.gaisler.com/doc/vhdl2proc.pdf
Hat jemand diese VHDL-Prozess-Variante schon mal verwendet ?
Wenn ja, was waren Eure Erfahrungen im Vergleich zur "gängigen"
Architektur mit mehreren Prozessen ?
Wenn nein, was ist Eure Meinung hierzu ? Unter welchen
(Design-)Umständen könnte sich eine solche Herangehenweise lohnen ?
VG,
Heinze
> Hat jemand diese VHDL-Prozess-Variante schon mal verwendet ?
Such mal in diesem Forum nach statemachine. Wenn immer sich jemand ins
Knie schiesst, dann weil er die Zwei-Prozess-Variante verwendet und sie
nicht versteht.
> Wenn nein, was ist Eure Meinung hierzu ?
Das count8 Beispiel zeigt sehr schoen wie man etwas simples
verkomplizieren kann.
Cheers, Roger
Was willst du mir mit deinem letzten Beitrag sagen ? Du musst mal
vollständige und verständliche Sätze schreiben, dann klappts vielleicht
auch ;O)
Du willst mir also sagen, dass das Zähler-Beispiel auf Seite 5 des
Papers
in Deinen Augen durch die Record-Verwendung zu kompliziert wird ?
Was genau ist deiner Meinung nach daran kompliziert ?
VG,
Heinze
Heinze78 schrieb:
> Was willst du mir mit deinem letzten Beitrag sagen ? Du musst mal> vollständige und verständliche Sätze schreiben, dann klappts vielleicht> auch ;O)
Perlen vor die Saeue.
Wenn man nur wirres Zeug von sicht gibt, das nicht auf die Eingangsfrage
eingeht, dann sollte man sich die Perlen tatsächlich sparen ;O)
Gibt es noch konstruktive Meinungen zum Thema ?
VG,
Heinze78
@Heinze78:
Die Methode hat m.E. mehr Vor- als Nachteile. Man kann Dank records z.B.
keine Signale beim Reset vergessen. Nach einer gewissen
Einarbeitungszeit kann man auch nachträglich gut verstehen, was da vom
Code gemacht wird (ist fast selbsterklärend).
Duke
The goals and means of the ’two-process’ design method
> Hat jemand diese VHDL-Prozess-Variante schon mal verwendet ?
Meine Meinung:
Da werden wieder mal ein paar Desginvarianten zusammengemostet und an
simplen Beispielen anschaulich dargestellt. Arg pauschal sind dann
solche Aussagen:
1
The above goals are reached with suprisingly simple means:
2
• Using record types in all port and signal declarations
3
• Only using two processes per entity
4
• Using high-level sequential statements to code the algorithm
Nur zwei Prozesse pro Entity? Na dann viel Spass bei größeren
Projekten...
1
combinational:process(load,count,d,r)
2
variabletmp:std_logic_vector(7downto0);
3
begin
4
ifload=’1’thentmp:=d;
5
elsifcount=’1’thentmp:=r+1;
6
elsetmp:=r;endif;
7
rin<=tmp;
8
q<=r;
9
endprocess;
Kombinatorik für einen ladbaren 8-Bit-Zähler...
Lesbar????
> Wenn ja, was waren Eure Erfahrungen im Vergleich zur "gängigen"> Architektur mit mehreren Prozessen ?
Ich mache keine Zwei- und Mehr-Prozess-Beschreibungen mehr. Gründe siehe
dort:
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html
BTW:
Ich gebe nichts auf Dokumente, in denen nicht einmal das
Erstellungsdatum festgehalten wurde. Evtl. wird dort Designpraxis von
1997 als "neu" verkauft :-o
Hi,
ich hab's mir auch mal durchgelesen. Haengen geblieben ist der Vorsatz,
in Zukunft ernsthafter ueber Records nachzudenken. Aber wie oben schon
erwaehnt wurde, der Counter ist m.E. in der Form eine Katastrophe. Das
kann man mit weniger Code, evtl. einer Kommentarzeile dazu, viel
einfacher und uebersichtlicher machen.
Schliesse mich also der Kritik der Vorposter an. Und die Sache mit den
Records sorgt eigentlich auch nur dafuer, dass ich an ein oder zwei
Stellen nicht aendern muss. Aber das Dokument geht ueberhaupt nicht
darauf ein, was mit neu hinzu gekommenen Signalen irgendwo gemacht wird.
Und wenn ich in eine Komponente einen Record mit Signalen route, die
dann dort ueberhaupt nicht gebraucht/benutzt werden, dann ist's mit der
Lesbarkeit und dem Verstaendnis auch schnell vorbei. Also mein Fazit:
Cool bleiben!
@berndl:
> Und wenn ich in eine Komponente einen Record mit Signalen route, die> dann dort ueberhaupt nicht gebraucht/benutzt werden, dann ist's mit der> Lesbarkeit und dem Verstaendnis auch schnell vorbei.
Das mit den records ist schon eine coole Sache, die m.E. wirklich was
bringt. In der Synthese werden nicht benötigte record-Elemente,
wegoptimiert. Und wenn ich irgendwo ein record-Element drinhabe und
nicht brauche, dann schreibe ich es auch nicht hin.
Also an der Stelle leiden dann weder Lesbarkeit, noch das Verständnis.
@Lothar:
> Nur zwei Prozesse pro Entity? Na dann viel Spass bei größeren> Projekten...
Ich würde das woran ich hier arbeite schon als größeres Projekt
bezeichnen. Wir setzen auch so ziemlich jeden Designstil, den man sich
ausdenken kann (aus jedem Dorf ein Hund...)
Meiner Erfahrung nach läßt sich der Teil, der mit der
Zwei-Prozess-Methode (seq, comb) realisiert ist, wesentlich besser
warten und erweitern als die anderen Projektteile.
> Arg pauschal sind dann> solche Aussagen:
1
The above goals are reached with suprisingly simple means:
2
• Using record types in all port and signal declarations
3
• Only using two processes per entity
4
• Using high-level sequential statements to code the algorithm
Hast Du es schonmal praktiziert? Ich kann das, was da steht genau so
unterschreiben.
Duke
Duke Scarring schrieb:
>> Arg pauschal sind dann solche Aussagen:>
1
> The above goals are reached with suprisingly simple means:
2
> • Using record types in all port and signal declarations
3
> • Only using two processes per entity
4
> • Using high-level sequential statements to code the algorithm
5
>
> Hast Du es schonmal praktiziert?> Ich kann das, was da steht genau so unterschreiben.
Wenn ich das mal zerpflücke:
> • Using record types in all port and signal declarations
Das ist einen genaueren Blick wert.
Im Text werden allerdings genau diese Records als Allheilmittel gegen
unvollständige Sensitiv-Listen angepriesen. Und solche unvollständige
Sensitiv-Listen kann es nur geben, wenn ich einen kombinatorischen
Prozess habe und somit die Listen brauche.
Für eine sinnvolle Umsetzung der Record-Strategie wäre ein
"Auto-Vervollständigen" wie z.B. bei Structs im Visual-Studio zwingend
notwendig. Denn sonst müsste ich immmer parallel die Package-Definition
offen halten, um zu sehen, welche Elemente der Record beinhaltet.
> • Only using two processes per entity
Das wäre für mich eine unnötige Einschränkung, weil sich dadurch einfach
(zwingend) mehr Entities ergeben. Und was soll daran dann besser les-
und wartbar sein?
> • Using high-level sequential statements to code the algorithm
Das ist etwas, das einen meiner Prozesse direkt beschreibt. Und die
angegebenen Beispiele lassen sich auch in der 1-Prozess-Schreibweise
vortrefflich einsetzen.
In der Summe ist m.E. in diesen 3 "suprisingly simple means" nichts zum
eigentlichen Designstil festgehalten. Und als Fazit dürfte gelten:
1
By defining a common coding style, the algorithm can be easily identified and
2
the code analysed and maintained also by other engineers than the
@ Duke
>Man kann Dank records z.B >keine Signale beim Reset vergessen.
Ist dies so ? Man muss doch jedes Record-Element einzeln resetten,
durchaus
mit unterschiedlichen Reset-Werten. Da könnte es doch passieren, dass
man Record-Elemente vergisst ?
Könntest du deine Aussage noch etwas weiter ausführen ?
Ein weiterer Punkt, der mir noch unklar erscheint, ist der, dass man
bei der "klassischen" Verwendung von mehreren Prozessen pro ARCHITECTURE
Pipeline-Stufen überschaubar einfügen kann. Wie verhält es sich bei
der im Paper beschriebenen Zwei-Prozess-Variante ? Wie ist hier die
Vorgehensweise, um nachträglich Pipelines einzufügen ?
VG,
Heinze
Ich habe mal das Beispiel des 8-Bit-Counters auf der Seite 45
synthetisiert.
Erst mal waren in dem Code-Beispiel gute 8 Syntaxfehler drin: vom
fehlenden end record; über falsch geschriebene d.data und r.val + 1, bis
zur fehlenden use ieee.std_logic_unsigned.all; für ebendiese Addition.
Das stimmt mich bei einem publizierten Codeabschnitt nachdenklich...
Und dann fiel mir auf, dass in diesem Beispiel
so viel implizites Wissen drinsteckt (korrekte Reihenfolge der
Zuweisungen unbedingt einhalten), dass ein Fortschritt in Richtung
bessere Verständlichkeit und Wartbarkeit des Codes für mich nicht
erkennbar ist.
Der einzige Vorteil gegenüber der "traditionellen" 2-Prozess-Methode
ist, dass alle Ausgänge registriert sind. Es kann also keine Glitches
geben. Allerdings könnte man sich im ersten Augenblick fragen, wozu ein
ladbarer 8-Bit Counter 11 FFs braucht :-o
Beim Reset wird der default zugewiesen. Wenn man den record erweitert,
gibt es schon eine Fehlermeldung wenn man die default_*_c nicht mit
erweitert.
Pipelines sind in der Tat etwas ungewohnt. Da man im Kombinatorischen
Prozess nur mit Variablen arbeitet, muß man die letzte Pipelinestufe
zuerst beschreiben. Ungefähr so:
• Using high-level sequential statements to code the algorithm
:-) Damit wird VHDL zur sequenziellen Programmiersprache. Man darf
trotzdem nicht vergessen, das da Hardware draus gebaut wird und das das
im Prinzip alles in einem Takt realisiert werden muss. (Außer man
verwendet Pipelines und FSMs.)
Happy coding
Duke
> Damit wird VHDL zur sequenziellen Programmiersprache.
Ok, das habe ich bisher implizit in Schleifen und Unterprgrammen auch
schon gemacht...
Die Verwendung von Variablen war schon immer sequenziell. Durch das
Verwaltungs-Korsett, das um den Prozess geschnallt wird, wird dann der
ganze Prozess quasi-sequenziell.
Allerdings ist da auch eine Art "Pseudo-Sequenz" versteckt:
Die "Ausgabezeile" könnte überall im Prozess stehen, ohne dass sich an
der Funktion irgenwas ändert.
Ich würde die "sogar" concurrent beschreiben. Denn ich gebe/gäbe für
einen neuartigen Beschreibungsstil nicht die Hälfte der Syntaxelemente
von VHDL auf.
> Man darf nicht vergessen, das da Hardware draus gebaut wird
Fullstes ACK ;-)