Clock-Signallaufzeit

Naja, das weiß die Toolchain nach dem Place and Route. Du gibst im 
einfachsten Fall für ein komplett synchrones Design mit nur einem Takt 
ein Constraint vor, wie hoch die Periodendauer des Taktes ist. Und wenn 
alles durchgelaufen ist, sagt dir die Toolchain, ob das Timing passt, 
oder ob du Setup- bzw. Hold-Verletzungen hast. Normalerweise ist der 
Clock Skew auf den dedizierten Clock-Routing Pfaden so optimiert, dass 
alle FlipFlops auf dem gesamten FPGA nahezu gleichzeitig erreicht 
werden. Bei mehreren Takten und deren Takt-Übergängen oder asynchronen 
Schweinereien wirds natürlich dann etwas aufwendiger. Aber innerhalb des 
FPGA sollte man tunlichst alles sychron halten.

Daniel R. schrieb:
> Wie erreicht man, dass die Signalzuweisungen in einem
> aktaktenden-Register-Prozess alle gleichzeitig passieren, sodass race
> conditions nicht auftreten können?
Das ist die Aufgabe des FPGA-Designers. Dass das nicht passiert, dass 
die Taktverteilung symmetrisch ist, dass du dir keine Gedanken darum 
machen musst, dafür bezahlst du deinem FPGA-Lieferanten Geld. Und dann 
musst du selber nur noch dafür sorgen,

Aber wenn du ein ASIC machst, dann bist du selber dafür 
verantwortlich, wie der Takt durch dein Design läuft. Du hast dann 
Hilfmittel und musst selber das Taktnetz auf solche Zustände hin 
untersuchen.

Daniel R. schrieb:
> allein die Länge der Signallaufzeit im Berechnungsprozess
Ein Prozess hat keine Laufzeit! (da sollten viele Ausrufezeichen hin!)
Du hast hier die falsche Denkweise! Ein Prozess wird einfach in 
Kombinatorik und Flipflops umgesetzt. Und natürlich hat diese 
Kombinatorik Durchlaufzeiten, die korrelieren aber in keinster Weise 
mit der Reihenfolge der Zuweisungen im Prozess. Nehmen wir mal den hier:

1

  process (a,b,c,d) begin

2

     z <= a+b*c;

3

     y <= d;

4

  end process;

Natürlich wird hier die Zuweisung an y viel schneller fertig sein (das 
sind ja nur Verbindungen) als die Berechnung von z.

Lothar Miller schrieb:
> Ein Prozess hat keine Laufzeit! (da sollten viele Ausrufezeichen hin!)
> Du hast hier die falsche Denkweise! Ein Prozess wird einfach in
> Kombinatorik und Flipflops umgesetzt. Und natürlich hat diese
> Kombinatorik Durchlaufzeiten, die korrelieren aber in keinster Weise
> mit der Reihenfolge der Zuweisungen im Prozess. Nehmen wir mal den hier:
> process (a,b,c,d) begin
>      z <= a+b*c;
>      y <= d;
>   end process;
> Natürlich wird hier die Zuweisung an y viel schneller fertig sein (das
> sind ja nur Verbindungen) als die Berechnung von z.

Lothar Miller schrieb:
> Daniel R. schrieb:process (TRIGGER, CLK)
> variable vCLK:bit;
> begin
>   vCLK := CLK;
>   ... einige Anweisungen   <--- Diese Annahme ist GRUNDLEGEND falsch!
>   ... zur Verzögerung
>   CLK <= vCLK;
> end process
> Denn die Anweisungen in einem Prozess haben in der Hardware keine
> "Ausführungsreihenfolge".
> Das hier:process (a,b,c,d,e)
> variable v:bit;
> begin
>   v := a;
>   w <= a or b and c or d or e;
>   x <= v and c or d xor e;
>   y <= v or a and b or c;
>   z <= v;
> end process
> Ergibt exakt die selbe Hardware wie das hier:process (a,b,c,d,e)
> variable v:bit;
> begin
>   v := a;
>   z <= v;
>   y <= v or a and b or c;
>   x <= v and c or d xor e;
>   w <= a or b and c or d or e;
> end process

Ok, Signalzuweisungen in einem Prozess werden vom Synthesetool als 
nebenläufige Verdrahtungen mit oder ohne kombi. Logik umgesetzt (davon 
hängt dann ab in welcher Reihenfolge die Zuweisungen tatsächlich 
passieren). Also von den Zuweisungen
y <= v or a and b or c;
z <= v;
wird die zweite sicherlich zuerst abgeschlossen sein, da hier nur ein 
Draht notwendig ist und keine Logikzellen, wie bei der ersten Zuweisung.

Aber anders verhält es sich doch wenn man Variablen verwendet. Die 
Zuweisungen an Variablen laufen in der Reihenfolge ab, wie sie angegeben 
wurden. Deshalb ist es möglich:

1

process (SIG1)

2

variable var1:bit;

3

begin

4

  var1 := SIG1;

5

  if var1='1' then

6

    OUT <= '1';

7

  else

8

    OUT <= '0';

9

  end if

10

end process

zu schreiben, aber nicht:

1

process (SIG1)

2

signal tmp1:bit;

3

begin

4

  tmp <= SIG1;

5

  if tmp='1' then

6

    OUT <= '1';

7

  else

8

    OUT <= '0';

9

  end if

10

end process

denn hier passiert die Zuweisung an tmp nebenläufig oder anders gesehen 
am "Ende" des Prozesses. Ist SIG1 ein abgetaktetes Signal, verschiebt 
sich die kombi. Logik um einen Takt, da erst beim nächsten ausführen des 
unteren Prozesses der an tmp übergebene Wert in der if-Abfrage verwendet 
werden kann.

Schreibt man also einen langen Block von Anweisungen, die auf Variablen 
rumrechnen, werden die vom Synthesetool erzeugten Logikblöcke in die 
Tiefe gestapelt sein und nicht als parallele Zuweisungen realisiert 
werden.
Signalzuweisungen erzeugen jew. parallel ausgeführte (relativ kurze) 
kombi. Blöcke.
Variablenberechnungen erzeugen längere Verkettungen von Logikblöcken mit 
längerer Signallaufzeit.
Richtig?
Dass die Ausgänge solcher langen Verkettungen während der Berechnung vor 
sich hin glitchen kann ich mir auch gut vorstellen;)

Daniel R. schrieb:
> zu schreiben, aber nicht:
Ja klar: hier ist die Sensitivliste falsch, weil unvollständig.
Wir hatten das schon im 
Beitrag "Re: Variable vs Signal"

> denn hier passiert die Zuweisung an tmp nebenläufig oder anders gesehen
> am "Ende" des Prozesses.
Genau deswegen muss der Prozess noch einmal durchlaufen werden. Das 
sagt die Sensitivliste dem Simulator. Die Synthese macht es eh' schon 
"richtig"...

> Schreibt man also einen langen Block von Anweisungen, die auf Variablen
> rumrechnen, werden die vom Synthesetool erzeugten Logikblöcke in die
> Tiefe gestapelt sein und nicht als parallele Zuweisungen realisiert
> werden.
Keine sorge: die Synthese klopft diese Struktur schon flach. Ein 
"komplizierter" Prozess mit Variabeln wird mit Signalen genauso 
aufwendig umgesetzt...

> Signalzuweisungen erzeugen jew. parallel ausgeführte (relativ kurze)
> kombi. Blöcke.
> Variablenberechnungen erzeugen längere Verkettungen von Logikblöcken mit
> längerer Signallaufzeit.
> Richtig?
Nein.
Es ist eher so: weil mit der "sofortigen" Änderung von Variablen ein 
Beschreibungsstil ermöglicht wird, der viele Ebenen beinhaltet, werden 
solche Prozesse in der realen Hardware oft aufwendig. Nehmen wir mal das 
da:

1

process (clk)

2

signal tmp: integer;

3

begin

4

  if rising_edge(clk);

5

     if init='1' then

6

       tmp := startwert;

7

     end if;

8

     if tmp=3 then

9

       tmp := tmp+offset;  

10

     end if;

11

     if jump='1' then

12

       tmp := addr-8;

13

       speicher[tmp]<=wert;

14

     elsif reduce='1' then

15

       tmp := tmp+1;

16

     end if;

17

  end if;

18

end process

Hier kann man tmp sofort beliebig manipulieren und "gleich" wieder 
darauf zugreifen. In der Realität muss der Synthesizer aber diese 
Berechungen alle parallel ausführen und gleichzeitig machen.

Weil diese "sofortige" Manipulation mit Signalen nicht erfolgt, muss man 
sich vorher ein paar Gedanken zur Strucktur machen. Und das schadet 
meist nicht!