> wieso ist es dann schneller?
Sieh dir mal dieses einfache Beispiel an:
Du hast zwei FFs und dazwischen eine Kobinatorische Funktion aus zwei
Teilen F1 und F2. Wenn F1 z.B. 10ns braucht und F2 ebenfalss 10ns, dann
darfst du (unter Vernachlässigung von tco und tsu) diese Schaltung mit
maximal 1/20ns = 50MHz takten.
1 | 20ns
|
2 | ______ 10ns 10ns ______
|
3 | A ---| D Q |---(F1)------(F2)------| D Q |-- B
|
4 | C-|> | C-|> |
|
5 | |______| |______|
|
6 | FFa FFb
|
Wenn du jetzt aber zwischen die beiden Funktionen nochmal ein FF setzt,
dann kannst du den Takt (wieder unter Vernachlässigung von tco und tsu)
auf 100MHz erhöhen.
1 | ______ 10ns ______ 10ns ______
|
2 | A ---| D Q |---(F1)------| D Q |---(F2)------| D Q |-- B
|
3 | C-|> | C-|> | C-|> |
|
4 | |______| |______| |______|
|
5 | FFa FFx FFb
|
Aber: auch hier wird dein eigentliches Ergebins B erst nach 20ns
berechnet sein!! Du hast dann zwar einen doppelt so hohen Takt, aber
dafür einen Takt Latency (Verzögerung).
Warum also der ganze Aufwand?
Was wäre, wenn dein restliches FPGA-Design durchaus die 100MHz könnte,
und nur durch diese F1+F2 Logik ausgebremst würde? Dann könntest du dir
hier mit deieser zusätzlichen Registerebene den Hals aus der Schlinge
ziehen, aber dabei immer im Hinterkopf behalten, dass das Ergebnis B um
einen Takt zu spät ankommt.
> wieso ist es dann schneller?
Die Multiplikation selber wird nicht schneller, aber du könntest den
Takt erhöhen und damit evtl. den Rest deines FPGAs (der ja idealerweise
am selben Takt hängt) schneller machen.
Das ist der Tip, den dir der HDL-Tipgeber hier offenbart.