warum wird hier korrekt synthetisiert?

[Sina A. (sinapse)]

Hallo,

hier
http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA_rev1_2.pdf

ist auf seite 9 folgendes beispiel mit race condition gegeben:

module pipeb3 (q3, d, clk);
 output [7:0] q3;
 input [7:0] d;
 input clk;
 reg [7:0] q3, q2, q1;
 always @(posedge clk) q1=d;
 always @(posedge clk) q2=q1;
 always @(posedge clk) q3=q2;
endmodule

auch wenn man die reihenfolge der always zeilen verändert wird wohl 
richtig synthetisiert und es kommt wie gewuenscht eine pipeline heraus 
(reihenschaltung von flipflops).

aber warum ist das so? muesste nicht immer etwas anderes synthetisiert 
werden, je nach dem was das ergebnis mit unterschiedlichen race 
conditions ist?

[Gustl B. (-gb-)]

Nun, das ist keine Software. Du beschreibst Hardware. Und die 
funktioniert immer gleichzeitig.

Hier die drei FFs übernehmen jeweils mit der steigenden Taktflanke das 
was an deren Eingang zu genau diesem Zeitpunkt der Taktflanke anliegt.

Du könntest auch schreiben:

always @(posedge clk)
   begin
      q1=d;
      q2=q1;
      q3=q2;
   end

Da gibt es keinen Unterschied weil sichergestellt wird, dass der Takt 
die FFs zeitgleich erreicht.

[Sina A. (sinapse)]

ich glaub du irrst dich... in deinem beispiel werden ja blocking 
assignments verwendet. damit wird

      q1=d;
      q2=q1;
      q3=q2;

hintereinander im simulator ausgeführt und damit wird q3 direkt d 
zugewiesen. das beschreibt somit nicht das verhalten einer pipeline und 
es wird keine pipeline synthetisiert.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Ihr habt beide sowohl recht als auch unrecht.

Gustl hat zwar zu recht auf die gleichzeitige Ausführung in Hardware 
hingewiesen, aber dummerweise genau den falschen Beispielcode 
aufgeführt, siehe:

https://www.nandland.com/articles/blocking-nonblocking-verilog.html

Somit ist Sinas Hinweis auf blocking assignments durchaus korrekt.

Bei synchroner Logik in einem FPGA o.ä. werden innerhalb einer clock 
domain alle getakteten Zuweisungen gleichzeitig ausgeführt, da 
sichergestellt ist, dass die Taktflanken der jeweiligen Register 
hinreichend dicht beieinander liegen. Damit werden die befürchteten race 
conditions vermieden.

Würde man jedoch solch eine Schaltung mit diskreter Logik ("TTL-Grab") 
aufbauen, gäbe es diese race conditions, da so manches 
Register/Flip-Flop durch eine erstaunlich große Setup-Zeit besitzt. 
Daher würde man in solch einem Aufbau einen mehrphasigen Takt verwenden.

Ähnlich sieht es bei sehr großen, mehrlagigen FPGA (Xilinx 3D mit SSI) 
aus, bei denen die Taktflanken zwischen verschiedenen Lagen nicht 
hinreichend synchron sind bzw. auch Datensignale erhebliche Laufzeiten 
besitzen können.

[Gustl (Gast)]

Andreas S. schrieb:
> Ihr habt beide sowohl recht als auch unrecht.
> Gustl hat zwar zu recht auf die gleichzeitige Ausführung in Hardware
> hingewiesen, aber dummerweise genau den falschen Beispielcode
> aufgeführt, siehe:
> https://www.nandland.com/articles/blocking-nonblocking-verilog.html
> Somit ist Sinas Hinweis auf blocking assignments durchaus korrekt.
> Bei synchroner Logik in einem FPGA o.ä. werden innerhalb einer clock
> domain alle getakteten Zuweisungen gleichzeitig ausgeführt, da
> sichergestellt ist, dass die Taktflanken der jeweiligen Register
> hinreichend dicht beieinander liegen. Damit werden die befürchteten race
> conditions vermieden.
> Würde man jedoch solch eine Schaltung mit diskreter Logik ("TTL-Grab")
> aufbauen, gäbe es diese race conditions, da so manches
> Register/Flip-Flop durch eine erstaunlich große Setup-Zeit besitzt.
> Daher würde man in solch einem Aufbau einen mehrphasigen Takt verwenden.
> Ähnlich sieht es bei sehr großen, mehrlagigen FPGA (Xilinx 3D mit SSI)
> aus, bei denen die Taktflanken zwischen verschiedenen Lagen nicht
> hinreichend synchron sind bzw. auch Datensignale erhebliche Laufzeiten
> besitzen können.

Tatsache. Sorry.

Ist das etwas dass es nur bei Verilog gibt? Bei VHDL das ich meistens 
verwende kenne ich das nicht.

[Bernhard K. (bkom)]

Ich meine: non-blocking verhält sichs in etwa wie eine VHDL variable:

 reg [7:0] q3, q2, q1;
always @(posedge clk) q1=d; // non blocking

Und blocking verhält sichs in etwa wie ein VHDL Signal:

reg [7:0] q3, q2, q1;
always @(posedge clk) q1<=d; // blocking

Mal sehen was ISE 14.7 so dazu sagt:
Version 1 nonblocking

always @(posedge clk)
    begin
    q1=d; 
    q2=q1;
    q3=q2;
    end

Wird im ISE-RTL-schematic eine Stufe (Bild pipeb3_version1)

Und aus diesem macht ISE drei FF-Stufen: (pipeb3_version2)

 always @(posedge clk) q1=d;
 always @(posedge clk) q2=q1;
 always @(posedge clk) q3=q2;

Und so werden es auch drei Stufen:

always @(posedge clk)
    begin
    q1<=d;
    q2<=q1;
    q3<=q2;
    end

[Gustl B. (-gb-)]

OK, aber

always @(posedge clk)
   begin
      q1 <= d;
      q2 <= q1;
      q3 <= q2;
   end

führt wieder zu dem gleichen Ergebnis.

Bernhard K. schrieb:
> Ich meine: non-blocking verhält sichs in etwa wie eine VHDL variable:

Ja sehe ich auch gerade.

Edith dankt Bernhard K. der schneller war (-:

Seltsam dieses Verilog:
Jetzt habe ich zwei Eingänge d1 und d2.

always @(posedge clk)
  begin
    q1 = d1;
    q2 = d2;
    q3 = d1 ^ d2;
  end

Und was kommt dabei raus? Nur q3 ist ein getaktetes FF, der Rest ist 
Kombinatorik. Das bedeutet, dass dieser always @(posedge clk) Teil immer 
und völlig unabhängig von dem Takt "läuft" und nur der Ausgang dann 
getaktet ist. Also sehr ähnlich wie Variablen in VHDL. Aber die ersten 
beiden Blocking Statements blockieren hier genau nichts, da wird 
Kombinatorik draus. Und weil das so ist, macht es bei diesem Beispiel 
auch keinen Unterschied ob man = oder <= verwendet.

Und Beides, also Blocking in Verilog und Variablen in VHDL bräuchte man 
nicht. Man kann das immer auch anders beschreiben. Der Mehrwert ist 
Bequemlichkeit. (Finde ich schon auch nützlich)

[Sina A. (sinapse)]

vielen dank für die antworten.

jetzt ist es klar.