Guten Abend,
ich hab ein 10Bit Zähler mit Übertrag. Ich komme mit diesem Design
gerade mal auf 129MHz maximum Frequenz. Ich hab vermutet das der 96Bit
: 8 Bit Mux das Problem ist. Aus diesem Grund hab ich den Mux in ein
extra Modul gepackt und synthesiert. Der Mux laueft mit einer maximal
Frequenz von 420MHz.
Könnte jemand sich mal den Code anschaun und Optimierungsvorschläge
äussern?
10Bit Zahler + 4Bit Carry + reload
1
ibraryIEEE;
2
useIEEE.STD_LOGIC_1164.ALL;
3
useIEEE.STD_LOGIC_ARITH.ALL;
4
useIEEE.STD_LOGIC_UNSIGNED.ALL;
5
6
---- Uncomment the following library declaration if instantiating
Ja, dann würd ich bis heut abend warten. ;-)
Eventuell könnte es was bringe, wenn der Reset asynchron ausgfeführt
wird, denn dann wird eine Kombinatorik für den Reset der FF generiert,
die separat zur Kombinatorik des eigentlichen Zählers ist.
Beim synchronen Reset, wird, so denk ich mal, die Kombinatorik des
Zählers einfach etwas komplexer, da eben auch genau dieser Fall in der
Wolek mit abgedekt werden muss.
Könnte also was bringen, aber nagel mich da bitte nicht fest
Meistens ist ein synchroner Reset schneller(meine Erfahrung).
Lass mal die Case-Anweisung weg. Das geht auch mit if - else.
Vielleicht bringt das was.
Daniel
bin gespannt wegen dem Reset... rein vom theoretischen Verständnis hätt
ich es gerade andersrum gesehen als du, Dirk. Aber weiss man, was das
synthesetool macht ;-)
Nimm den "adress_cnt <= "00000000000";" da raus und lass das den
Zähler mit erledigen. Macht der ja sowieso und ist hier doppelt.
Der kritische Pfad dürfte auf dem Zaehler liegen, also alles raus, was
den evtl. langsamer macht.
Also so:
if EN = '1' then -- enable
adress_cnt <= adress_cnt + 1; -- check adress_cnt
if adress_cnt = "11111111111" then -- overflow
if ram_cnt = "1011" then -- when oveflow
ram_cnt <= "0000"; -- rst ram_cnt
FULL <= '1'; -- set full flag
else -- no overflow
ram_cnt <= ram_cnt + 1; -- increase carry
FULL <= '0'; -- clear full flag
end if;
end if;
end if;
und Reset asynchron.
Oder so ähnlich.
Gruss
Axel
Hi,
ich wollte ein Bericht abgeben. Der Zaehler von Axel ist mit synchron
Reset 134MHz (meiner ist fast genauso schnell) und mit asynchronen
Reset ist der Zaehler maximal 184MHz.
Jetzt ist die Frage: Sollte man asycnhron Reset und sychron Reset in
dem ganzen Design mischen oder sich fuer eins entscheiden?
Ich würde ich nun fuer ein kompletten asynchronen Reset entscheiden.
Gruß,
Dirk
Hmm, 5 Mhz schneller. Naja, hätte mehr erwartet :-(
Asynchroner Reset ist unschön. Du musst dann sehr darauf achten, dass
das Freigeben des RESET Synchron läuft und alle FF den tatsächlich
released bekommen, bevor der erste Takt kommt.
Ich weiss jetzt nicht genau, wie das beim FPGA ist, aber so eine
Leitung, die quer über den Baustein an alle FF geht und max. eine
Periode Zeit hat, ist natürlich ein bischen kritisch.
Gruss
Axel
Schlumpf:
Im nachhinein ist das schon nachvollziehbar. In der ursprünglichen
Lösung gab es zwei Quellen für den synchronen Reset des Zähler, RST und
"adr_cnt = "11111111111".
Ich hatte den adr_cnt = "111111111" wegoptimiert, was nur ein bischen
gebracht hat, weil der Zähler immer noch einen synchronen Reset
brauchte. Erst das Wegoptimieren des synchronen Resets bringt wirklich
den Speed, weil jetzt ein reiner Zähler übrigbleibt und die Verzögerung
durch das "Clr" im Datenpfad wegfällt.
Gruss
Axel
PS: Was ich da zum asynchronen/synchronen Reste geschrieben hatte, ist
natürlich Quatsch. Aber ich würde mich dann doch für eins entscheiden.
@Axel:
Muss ja auch so sein.
letztendlich werden die Eingänge der FFs des Zählers kombinatiorisch
aus den Ausgängen und den Eingängen in das System gebildet und mit
jedem Takt übernommen.
Beim synchronen Reset wird das Reset-Signal in diese Kombinatorik
reingewurschtelt udn somit wird die Logik größer.
Beim asynchronen Reset geht die Reset-Leitung an dieser Logik vorbei
auf den dedicated Reset-Anschluss des FF.
Also ich verwende IMMER asynchrose Resets und hatte noch nie schlechte
Erfahrungen gemacht.
Naja, wenn man asynchrone Resets verwendet, dann brauch man sich auch
keine Gedanken um das "einclocken" von asynchronen Eingangssignalen
machen. Es kann aber dann doch zu nicht vorraussagbaren Zuständen
kommen, meinetwegen der Reset tritt gleichzeitig zur Taktflanke auf.
Oder die Setup- und Holdzeiten reichen nicht aus... Deshalb macht man
ja eigentlich alles synchron. Naja, jeder wie er will.
T.M.
=============================
http://editthis.info/freefpga
=============================
Auch ein "asynchroner" Reset muss natürlich synchron weggenommen
werden,
damit so ein Fall nicht auftaucht.
Ich beziehe die Aussage "asynchron" eher darauf, dass man den am
asynchronen "CLR" Eingang des FF anklemmt, was dann die Datenpfade
nicht verlangsamt.
Gruss
Axel
Hi,
Danke Joern ich hab es nun durch eine komplette Abaenderung meines
Designs hinbekommen.
Es lag nicht am sychronen / asychronen Reset, sondern an der 'else'
Verzweigung
1
ifram_cnt="1011"then-- when oveflow
2
ram_cnt<="0000";-- rst ram_cnt
3
FULL<='1';-- set full flag
4
else-- no overflow
5
ram_cnt<=ram_cnt+1;-- increase carry
6
FULL<='0';-- clear full flag
Die Elseanweisung kostet 70 MHz und wenn der Zaehler auf ein
Überlaufwert verglichen wird und reloaded kostet das nochmal 30MHz.
Ich hab es nun alles ein bischen besser gelöst. Statt zwei Counter hab
ich nur noch ein 12 Bit Counter mit Überlaufflag. Das letzte Bit wird
zur Bank Selection der Block Rams genutzt, also Bit12 = '1' ober Bank
mit 8 Block Rams sind aktiv und mit '0' ist die untere Bank aktiv.
So komme auf eine maximale Geschwindigkeit von 207MHz.
Gruß,
Dirk
PS: Falls jemand den Wunsch aeussert uploade ich die Top RTL mit Block
RAMs, Adresszaehler mit Überlauf und Ram Bank Selector (einfacer
Inverter) und 192Bit to 8 Bit demultiplexer.
Gruß,
Dirk
DAS haut mich jetzt vom Hocker.
Anscheinend hat die Synthese sich da vollkommen einen Wolf
synthetisiert.
Denn eigentlich ist die "Else" Verzweigung vollkommen unabhängig vom
11 Bit Zähler.
Kann aber sein, dass die Synthese das nicht mitbekommt und das
irgendwie versucht zu verwurschteln.
Gruss
Axel