Optymalizacja projektu CPLD CoolRunner2 w VHDLu: jak unikać błędów sygnałów?

Wed Jan 28, 2009 10:44 pm   

Sludig wrote:

Bedzie opozniony (bo masz bramke), ale co mnie martwi: "Clock" w tel
linijce. Po chusteczke ten Clock do OR potrzebny? Zalatw to w 'if' -
IMHO bezpieczniej.

A w ogole to calosci jakims ifem nie da rady? Bedzie zdrowiej.
Na razie wszystkie przewidywania sprawdzone - hazardy, ktore widac tylko
w gate-level (btw: to moj ulubiony moment walki).


Smierdzi mi to troche pisaniem kodu od nowa, uzywajac innej koncepcji.
Np koncepcji nie mieszania CLK tam, gdzie nie trzeba!


Xilinx nie wiem, Altera ma 'virtual pin'.


Jak masz dffy na wejsciach, to na tym samym - po chu*** na innym?

--
Jerry1111

Wed Jan 28, 2009 10:46 pm   

Sludig wrote:

I ta logika kombinacyjna troche mnie martwi. Tam mozna namieszac.
Nie mozesz kodu gdzies powiesic na sieci? Bedzie latwiej sie bawic w
naprawianie.

--
Jerry1111

Thu Jan 29, 2009 12:07 pm   

pedzenie calej logiki jednym zboczem zegara,
a fsm drugim to prawie na pewno zly pomysl;


'if' tez stworzy te same bramki, to tylko inny sposob zapisu;


'virtual pin' to troszke cos innego;

zeby powstrzymac kompilator od optymalizacji lub zmiany
nazwy sygnalu trzeba dac dyrektywe synthesis;

verilog:
wire sygnal_xxx /* synthesis keep */; dla wire
reg reg_xxx /* synthesis preserve */; dla rejestru

vhdl:
signal sygnal_xxx: std_logic;
attribute keep: boolean;
attribute keep of sygnal_xxx: signal is true;

signal reg_xxx: stdlogic;
attribute preserve: boolean;
attribute preserve of reg_xxx: signal is true;

jezeli to jest SRAM [static ram] a nie SSRAM [Synch. static ram],
to adres do zapisu jest zapisywany na opadajacym zboczu write_enable,
dane na narastajacym, wiec zmiana adresu 'prawie rowno' czy wrecz
rowno z rosnacym zboczem sygnalu zapisujacego nie jest grozna;
podobnie z danymi - powinny byc stabilne wokol pos. zbocza write_enable,
przelaczanie przy zboczu opadajacym nie jest grozne;
przynajmniej tak bylo kilka lat temu, jak cos z tymi pamieciami
robilem, nie sadze, by sie to zmienilo;

akurat przy interface do sram praca na obu zboczach moze
ulatwic zapewnienie wlasciwego timingu, np.:
pos_edge zegara zapisuje adres do rejestrow WY,
neg_edge wyzwala write_enable i wpisuje dane do rejestrow WY
pos_edge gasi write_enable;

JA


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

Thu Jan 29, 2009 5:28 pm   

Nie, nie mogę. Poza tym, żebyś zrozumiał jak układ działa musiałbym
zamieścić opis działania całego urządzenia. To niestety nie wchodzi w grę. W
zasadzie projekt uważam za udany - byle nikt nigdy nie włączył kodowania FSM
typu Hot-One Przy robieniu kolejnego projektu już

pozdrawiam
Sludig

Thu Jan 29, 2009 5:33 pm   

Dzięki. To się przyda.


Ja mam tą pamięć
http://www.vlsi.ee.upatras.gr/~karagian/samsung_sram.pdf
i dziwnie to wygląda, bo o ile dobrze odczytuje to adres może się zmieniać
na obu zboczach nWR, bo
tAS=0 i tWR=0. Ale mam zrobione tak jak sugerowałeś.

pozdrawiam
Sludig

Thu Jan 29, 2009 5:33 pm   

Nie widze innej metody na zapisanie danych "w locie". Zbocze narastajace nWE
musi wystąpić raz na okres zegara przecież.
Piszesz, że to twój ulubiony moment walki ?!? A jak walczyć? Jeżeli już
wiem, który sygnał powoduje błąd to jak go wyeliminować?

pozdrawiam
Sludig

Thu Jan 29, 2009 8:32 pm   

Sludig wrote:


raczej adres NIE moze sie zmieniac na obu zboczach
musisz zapewnic stabilny adres co najmnie 0ns przed
opadajacym zboczem we i co najmniej 0ns po rosnacym zboczem;


optymista jestes;
one-hot jest zwykle szybszym kodowaniem, a to sugeruje,
ze poprawne dzialanie zalezy od jakis opoznien w fpga,
nieprzewidywalnych i co wazniejsze niepowtarzalnych;
moze sie zdarzyc, ze na 5 kosciach bedzie dzialac, na
szostej nie bedzie; albo odwrotnie;


ta szpilka swiadczy o zlym rozwiazaniu;
domyslam sie, ze nWriteEnable to nWR, czyli 'aktywny' jest
puls: H-L-H;
czyli bardziej pogladowo byloby:
!nWriteEnable <= !nWriteToMem AND !Clock AND nReadFromMem;
szpilka wynika prawdopodobnie z tego, ze nWriteToMem lub
nReadFromMem tez jest zapisywany opadajacym zboczem Clock,
a to jest pewnie efektem tego, ze fsm pedzisz odwroconym zegarem;
a ten xilinx ma pll w sobie ?
JA

Fri Jan 30, 2009 12:06 am   

Sludig wrote:

Chodzi o to, ze przy logice kombinatoryjnej generujesz opoznienia ktore
sa przenoszone 'dalej'. Zmniejsza to Fmax (nie ma duzego znaczenia dla
CPLD, ale w fpga to czasem jest 'killer' predkosci).


Jak musi, to o tym wiesz. Jak o tym wiesz, to zrob ladnego if coby dff
wygenerowal - 90% ze rozwiazesz sprawe (nawet bez wdawania sie w szczegoly).


Nie masz sygnalu ktory powoduje blad. Masz po prostu blad w projekcie
(cos jak memory leak przy pisaniu programow). Po prostu nie zawsze sie
objawia.

Nie da rady nic wiecej powiedziec nie widzac kodu - wiec proponuje EOT.

Aha: sprawdz to jeszcze raz zanim zrobisz tego 10.000 sztuk ;-)


--
Jerry1111