Zum Artikel in Sachen Taktung von FPGAs.

Was willst du uns damit jetzt sagen?

Ich habe den Artikel nur kurz überflogen, wirkte in sich schlüssig. Die 
Takterei bei FPGAs ist nicht ganz ohne, aber ohne sich da tief 
reinzusteigern, scheitert man ohnehin schon lange vorher. BTDT.

Achso. Ich war mir nicht sicher, ob ich in deinem Text eher Ernst oder 
Ironie interpretieren sollte. :-)

Aber ja, hier ist's recht schön. Ruppig, aber meist kompetent.

S. R. schrieb:
> Die Takterei bei FPGAs ist nicht ganz ohne
Allerdings hat die feste Struktur der Taktverteilung einen Vorteil, den 
der Hersteller über alle Flipflops im FPGA hinweg garantiert: man muss 
sich keine Gedanken um eine Race-Condition machen. Ein Bit kann da nicht 
einfach durch eine (Schiebe-)Registerkette "durchfallen", wie es z.B. 
bei diesem Aufbau in einem ASIC sein könnte:

1

        _               tp          tp          tp

2

  Clk _|   --------o----->-----o----->-----o----->-----.

3

                   |           |           |           |     

4

                 -----       -----       -----       -----

5

                | Clk |     |     |     |     |     |     |    

6

     In    -----|D   Q|-->--|D   Q|-->--|D   Q|-->--|D   Q|---  Out

7

                |     | tp  |     | tp  |     | tp  |     |    

8

                 -----       -----       -----       -----

9

                 FF1          FF2         FF3         FF4

Wenn hier z.B. alle Flipflops '0' sind und der In '1', dann könnte es 
sein, dass mit der steigenden Flanke das FF1 "sofort" den Pegel '1' am 
Ausgang annimmt, und dieser Pegel zusammen mit der steigenden Flanke 
nach der Laufzeit tp am FF2 ankommt, und dieses dann gleich die '1' 
übernimmt, und das auch das FF2 und das FF3 macht. Dann ist die '1' mit 
einem einzigen Taktimpuls durch die Registerkette "durchgefallen".
Besser wäre es dann, den Takt am FF3 einzuspeisen:

1

                        tp          tp          tp           _

2

                   .----<------o----<------o----<------o-- _|   Clk

3

                   |           |           |           |     

4

                 -----       -----       -----       -----

5

                | Clk |     |     |     |     |     |     |    

6

     In    -----|D   Q|-->--|D   Q|-->--|D   Q|-->--|D   Q|---  Out

7

                |     | tp  |     | tp  |     | tp  |     |    

8

                 -----       -----       -----       -----

9

                 FF1          FF2         FF3         FF4

Dann kann dieses "Durchfallen" nicht passieren, weil ja erst das FF4 den 
Zustand vom FF3 übernimmt, usf bis zum Schluss das FF1 den Pegel vom In 
einliest.
Wird die Taktverteilung in einem "Baum" gemacht, hat von der "Wurzel", 
(dem Takteingang) bis zu den "Blättern" (den Flipflops) das Taktsignal 
die gleiche Laufzeit.

1

                                   CLk_ 

2

                                    _|

3

4

                                     |

5

                         .-----------o-----------.

6

                         |                       |  

7

                   .-----o-----.           .-----o-----. 

8

                   |           |           |           |     

9

                 -----       -----       -----       -----

10

                | Clk |     |     |     |     |     |     |    

11

     In    -----|D   Q|-----|D   Q|-----|D   Q|-----|D   Q|---  Out

12

                |     | tp  |     | tp  |     | tp  |     |    

13

                 -----       -----       -----       -----

14

                 FF1          FF2         FF3         FF4

Weil der FPGA-Hersteller durch den balancierten Taktbaum garantiert, 
dass eine Race-Condition", also ein "Durchfallen" im FPGA nicht 
vorkommen kann, macht es einfach, synchrone Designs zu realisieren.

Dass darüber hinaus die Taktgenerierung, die Taktmodifizierung und die 
Taktverteilung ein eigenes Kapitel im Handbuch haben, zeigt aber, dass 
das Taktmanagement weit über solche "Selbstverständlichkeiten" 
hinausgeht.

Lothar M. schrieb:
> Weil der FPGA-Hersteller durch den balancierten Taktbaum garantiert,
> dass eine Race-Condition", also ein "Durchfallen" im FPGA nicht
> vorkommen kann, macht es einfach, synchrone Designs zu realisieren.

Ich würde das etwas weicher formulieren, weil auch ein Taktbaum keine 
perfekte Verteilung garantiert.

Der Baum ermöglicht eine geringere Diskrepanz zwischen frühester und 
spätester Flanke, als eine Kette und damit mehr budget für die 
Laufzeiten der Kombinatorik -> höhere Taktfrequenzen für das synchrone 
Schalten.

Allerdings lassen sich genau durch solche Schaltungen innerhalb eines 
synchronen Taktes in ASIC besonders hohe Schaltgeschwindigkeiten 
erzielen, indem man solche Ketten lokal gezielt aufbaut und den später 
kommenden Takt am Ende der Kette nutzt.

Heisst: Höhere Taktfrequenzen für das "asynchrone" Schalten. Dazu muss 
man allerdings speziell bauen und simulieren.

Will man das bei speziellen Anwendungen in FPGAs nutzen wird das 
besonders anspruchsvoll, da mit den mikroskopischen Verzögerungen der 
LUTs und gegateten Takten gearbeitet werden muss.

Eine Mischung der Techniken ist möglich, wenn man mit mehreren Takten 
arbeitet, die aus derselben PLL kommen und einen festen Bezug haben. 
Z.B: 0,90,180,270 Grad.