Alternative Prozess-Beschreibung

[Heinze78 (Gast)]

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

[Roger S. (edge)]

> 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

[Heinze78 (Gast)]

Hi Roger,

kann den von dir angesprochenen Beitrag nicht finden.
Wie hieß denn der Beitrag ?

Heinze

[Roger S. (edge)]

http://www.mikrocontroller.net/forum/fpga-vhdl-cpld?filter=state+machine

[Heinze78 (Gast)]

Roger,

hast du dir den Paper-Link überhaupt mal angeschaut ? Die Beiträge, die
du nennst, haben aber auch rein gar nix damit zu tun :o(

VG,
Heinze

[Roger S. (edge)]

Tja da verstanden wir uns wohl Miss.
Wenns dir um das angesprochene count8 Beispiel geht, auf Seite 5 (45).

Cheers, Roger

[Heinze78 (Gast)]

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

[Roger S. (edge)]

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.

[Heinze78 (Gast)]

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

[Duke Scarring (Gast)]

@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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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:

The above goals are reached with suprisingly simple means:
• Using record types in all port and signal declarations
• Only using two processes per entity
• Using high-level sequential statements to code the algorithm

Nur zwei Prozesse pro Entity? Na dann viel Spass bei größeren 
Projekten...

combinational : process(load, count, d, r)
variable tmp : std_logic_vector(7 downto 0);
begin
  if load = ’1’ then tmp := d;
  elsif count = ’1’ then tmp := r + 1;
  else tmp := r; end if;
  rin <= tmp;
  q <= r;
end process;

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

[berndl (Gast)]

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!

[Duke Scarring (Gast)]

@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:

The above goals are reached with suprisingly simple means:
• Using record types in all port and signal declarations
• Only using two processes per entity
• Using high-level sequential statements to code the algorithm

Hast Du es schonmal praktiziert? Ich kann das, was da steht genau so 
unterschreiben.

Duke

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Duke Scarring schrieb:
>> Arg pauschal sind dann solche Aussagen:
>

> The above goals are reached with suprisingly simple means:
> • Using record types in all port and signal declarations
> • Only using two processes per entity
> • Using high-level sequential statements to code the algorithm
>

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

By defining a common coding style, the algorithm can be easily identified and 
the code analysed and maintained also by other engineers than the 
main designer.

[Heinze78 (Gast)]

@ 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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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

   comb : process(d, r) -- combinational process
      variable v : reg_type;
   begin
      v := r; -- default assignment
      v.load := d.load; v.count := d.count; -- overriding assignments
      v.zero := '0';
      if r.count = '1' then v.cval := r.cval + 1; end if; -- module algorithm
      if r.load = '1' then v.cval := d.din; end if;
      if v.cval = "00000000" then v.zero := '1'; end if;
      rin <= v; -- drive register inputs
      q.dout <= r.cval; q.zero <= r.zero; -- drive module outputs
   end process;

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

[Duke Scarring (Gast)]

@Heinze78:
Hier mal ein Codebeispiel:

  type matrix_t is record
    en    : std_logic;
    fd    : std_logic; -- first data
    h11   : complex_t;
    h12   : complex_t;
    h21   : complex_t;
    h22   : complex_t;
  end record matrix_t;
  constant default_matrix_c : matrix_t := (en => '0', fd => '0', others => (others => (others => '0'))); 

  type reg_t is record
    p_toggle     : std_logic;
    d_toggle     : std_logic;
    odd          : std_logic;
    cdd_type     : cdd_type_t;
    add_matrix   : matrix_t;
    mul_matrix   : matrix_t;
    d_i          : cdd_data_t;
    d_o          : cdd_data_t;
  end record reg_t;
  constant default_reg_c : reg_t :=(
    p_toggle     => '0',
    d_toggle     => '0',
    odd          => '0',
    cdd_type     => direct,
    add_matrix   => default_matrix_c,
    mul_matrix   => default_matrix_c,
    d_i          => default_cdd_data_c,
    d_o          => default_cdd_data_c
  );

[...]

  seq: process (clk, rst_n)
  begin
    if rst_n = '0' then
      r <= default_reg_c;
    elsif rising_edge(clk) then
      r <= rin;
    end if;
  end process seq;

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:

  comb: process (r, d_i) is
    variable v: reg_t;
  begin
    v   := r;
    d_o <= v.d_o;

    v.d_o.matrix := v.mul_matrix;
    v.mul_matrix := v.add_matrix;
    v.add_matrix := v.d_i.matrix;
    v.d_i        := d_i;

    rin <= v;
  end process comb;

@Lothar:
Deine Aussage
> (korrekte Reihenfolge der Zuweisungen unbedingt einhalten)
entspricht

• 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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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

   comb : process(d, r) -- combinational process
      variable v : reg_type;
   begin
      v := r; -- default assignment
      v.load := d.load; v.count := d.count; -- overriding assignments
      v.zero := '0';
      if r.count = '1' then v.cval := r.cval + 1; end if; -- module algorithm
      if r.load = '1' then v.cval := d.din; end if;
      if v.cval = "00000000" then v.zero := '1'; end if;
      rin <= v; -- drive register inputs
      q.dout <= r.cval; q.zero <= r.zero; -- #### Ausgabezeile #### -- drive module outputs

   end process;

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