Znow troche za szybko

Trochę poprawiłem wskazaną ścieżkę krytyczną i dostałem:

"Info: Clock "clk" Internal fmax is restricted to 405.19 MHz between source register "SBOX_Generator:inst|d_latch:X11|r[1]" and destination register "SBOX_Generator:inst|gf24_multiply:X21|a2[1]" Info: fmax restricted to Clock High delay (1.234 ns) plus Clock Low delay (1.234 ns) : restricted to 2.468 ns. Expand message to see actual delay path. Info: + Longest register to register delay is 2.052 ns"

Hmm, przecież to o 2,2MHz szybciej, niż tak kość ma fmax w datasheecie... :-/ Ale działa... Co tu jest grane? :-)

Temperature ustaw inna :-)

W zasadzie co sie dziwic ze proste operacje w pipeline daja taki szybki szyfrator ? I tak nie podasz danych wystarczajaco szybko :-)

J.

"Piotr Wyderski":

[...]

timing analizer po prostu liczy opoznienia, czy tez propagacje sygnalu miedzy wyjsciem Q FF, a wejsciem D nastepnego FF i na podstawie maksymalnego czasu podaje maksymalna czestotliwosc zegara; to, ze fpga 'sama z siebie' ma inna max. zegara to zupelnie inna sprawa :) nadal uwazam, ze analizator czasowy quartusa jest godny zaufania, i jesli uklad dziala w symulatorze, to bedzie dzialal w rzeczywistosci, pod warunkiem nie przekroczenia maksymalnej czestotliwosci zegara dla danej rodziny fpga;

JA

I chyba masz rację: przeniosłem ten kod na ProASIC+ Actela i analizator z pakietu Libero daje mu 178MHz, rónież prawie na styk z teoretyczną wydajnością kości APA075. Widać rzeczywiście grunt to dobry algorytm, a ja chyba zaczynam być dobry w te klocki. ;->

Pozdrawiam Piotr Wyderski

"Piotr Wyderski":

[,,,]

nie watpie :) jedna z oznak 'bycia dobrym' jest zauwazenie, ze ' if else' jest bardzo niewydajne w hardware, a zagniezdzonie 'if - else if' to juz tragedia; 'case' sobie radzi znacznie lepiej w takich przypadkach;

JA

Wszystko prawda. Tylko ze Twoj uklad jest teraz bezuzyteczny... Dolozysz mu wejscia/wyjscia, cos tam jeszcze, w rezultacie do tego neta CLK od szyfratora podlaczysz 10x wieksze obciazenie i Fmax spadnie o polowe. Potem cos jeszcze dodasz, zacznie byc ciasno w kosci, brakowac interconnectow i nagle zacznie Fmax leciec na pysk (jak duzo zajetego miejsca w FPGA, tak >85% to zauwazylem ze Fmax zmienia sie szybko tylko w jedna strone... zabawa z kilkoma kompilacjami troszke to poprawia, ale naprawde tylko troszke).

Sprobuj tak z ciekawosci do tego dolozyc cos duzego (50% kosci) - nawet na innym zegarze. Pewnie bedzie wolniej.

To jest testbed, on z założenia jest bezużyteczny, choćby z tego powodu, że kostka nie jest zabezpieczona. :-) Napisałem to w Quartusie, bo po prostu już się go nauczyłem. ;-)

Ten moduł w docelowym układzie miałby osobnego neta, 4x szybszego niż reszta kostki, dzieliłby go tylko z FIFO.

Biorąc pod uwagę, że celem było osiągnięcie 132MHz (4x33), to i tak byłoby 70MHz zapasu. :-) Po prostu widząc nierealne w moim pojęciu wyniki analizatora timingów (jakieś 330MHz) postanowiłem się poznęcać nad układem i poprawić wskazane ścieżki, co w końcu doprowadziło mnie do tego 405,2MHz. :->>>

Ustaw maksymalny odpowiedni poziom optymalizacji. Co prawda układ (mieszacz kwadratuowy) kompiluje się wtedy 15 minut zamiast

3,5, ale fmax mu wzrosło z 218 na 256MHz (zaczął limitować dostęp do RAMu). Biorąc pod uwagę to, że i tak będzie chodził na 130MHz, to ta różnica nie ma technicznego znaczenia, ale za to można się bardziej chwalić -- IMVHO to całkiem niezły wynik jak na amatora. :-)

Trudno się z tym nie zgodzić -- szybciej niż 405MHz już raczej nie będzie. ;-)))

Pozdrawiam Piotr Wyderski