Witam,
nie jestem pewien czy ide z rozumowaniem w dobra strone. Sytuacja wyglada nastepujaco: mam komponent obslugujacy SRAM. No i do testow stworzylem automat, ktory steruje komponentem.
Mecze sie juz dlugo.. Odnosze wrazenie, ze uklad "czasem" dziala. Byc moze to przypadek ale czy to mozliwe, aby pomogla zamiana kolejnosci instrukcji sekwencyjnych?
Kod automatu do testu wyglada mniej wiecej tak (fragment):
Przeniosel sygnal SIG_STROBE_N z poczatku kazdego "whena" na koniec i na 3 wyslane do zapisu slowa, 2 udalo mi sie odczytac. Dalej mnie to nie zadowala ale troche przykra jest to sytuacja gdy takich rzeczy trzeba sie doszukiwac. Byc moze jutro tych dwoch slow juz nie odczytam
no bo jak to mozliwe?
mam narastajace zbocza zegara wautomacie sterujacym. tuz po nim ustawiaja sie sygnaly sterujace... ale tych sygnalow sterujacych nie widac jeszcze w komponenecie obslugujacym sram... dopiero kolejne narastanie powoduje ze sa one tam w srodku WSZYSTKIE chwytane... no i to chwytanie juz w komponencie tez sie odbywa sekwencyjnie (proces clockowany)... konkretnie to taki:
to moze bardziej na tym poziomie ma znaczenie kolejnosc?
gdzie tu w ogole miejsce na jakas asynchronicznosc?
nie chce wchodzic w mechanizmy, ktore byc moze tu nie zachodza. Moze ktos ma jakas zlota porade?
Dzieki
Dodano po 6 [minuty]:
sciagnalem ze strony producenta model sramu (taki niesyntezowalny) bliski temu ktorego uzywam. No i pojawil sie tam komunikat: "iADDR - Cyp_tAH violation"
W kodzie sprawdzilem ze wywoluje sie on gdy:
Cyp_tAH to czas hold after clk rise. jakies 0.5 ns w zaleznosci od czestotliwosci.
Dodano po 59 [minuty]:
no i skoro we wszystkich stanach adres jest caly czas podany ten sam, nie ma zadnego momentu jego zmiany, to skad komunikat:
Error: iADDR - Cyp_tAH violation
Czy to o czyms swiadczy?
Dodano po 37 [minuty]:
jak to sprawdzic, zniwelowac...?
nie jestem pewien czy ide z rozumowaniem w dobra strone. Sytuacja wyglada nastepujaco: mam komponent obslugujacy SRAM. No i do testow stworzylem automat, ktory steruje komponentem.
Mecze sie juz dlugo.. Odnosze wrazenie, ze uklad "czasem" dziala. Byc moze to przypadek ale czy to mozliwe, aby pomogla zamiana kolejnosci instrukcji sekwencyjnych?
Kod automatu do testu wyglada mniej wiecej tak (fragment):
process( sig_zegar_nowy,P_I_RESET_N )
variable v_state : natural := 0;
variable v_cnt : natural ;
begin
if P_I_RESET_N = '0' then
v_state := 0 ;
elsif sig_zegar_nowy'event and sig_zegar_nowy = '0' then
case v_state is
when 0 => -- idle state
SIG_COUNTER_SET <= '1';
SIG_WR_N <= '0' ;
SIG_BENA_N <= '1' ;
SIG_ADDR <= "0000000000000111100" ; --SIG_ADDR <= ( others => '0' ) ;
SIG_I_DATA0 <= ( others => '0' ) ;
SIG_I_DATA1 <= ( others => '0' ) ;
SIG_I_DATA2 <= ( others => '0' ) ;
SIG_I_DATA3 <= ( others => '0' ) ;
SIG_STROBE_N <= '1' ;
v_state := 1 ;
when 1 =>
SIG_COUNTER_SET <= '1';
SIG_WR_N <= '1' ;
SIG_BENA_N <= '1' ;
SIG_ADDR <= "0000000000000111100" ;
SIG_I_DATA0 <= ( others => '0' ) ;
SIG_I_DATA1 <= ( others => '0' ) ;
SIG_I_DATA2 <= ( others => '0' ) ;
SIG_I_DATA3 <= ( others => '0' ) ;
SIG_STROBE_N <= '0' ;
v_state := 2 ;
when 2 =>
SIG_COUNTER_SET <= '1';
SIG_WR_N <= '1' ;
SIG_BENA_N <= '1' ;
SIG_ADDR <= "0000000000000111100" ;
SIG_I_DATA0 <= ( others => '0' ) ;
SIG_I_DATA1 <= ( others => '0' ) ;
SIG_I_DATA2 <= ( others => '0' ) ;
SIG_I_DATA3 <= ( others => '0' ) ;
SIG_STROBE_N <= '1' ;
if SIG_ACK = '1' then
v_state := 0 ;--6
end if ;
Przeniosel sygnal SIG_STROBE_N z poczatku kazdego "whena" na koniec i na 3 wyslane do zapisu slowa, 2 udalo mi sie odczytac. Dalej mnie to nie zadowala ale troche przykra jest to sytuacja gdy takich rzeczy trzeba sie doszukiwac. Byc moze jutro tych dwoch slow juz nie odczytam
no bo jak to mozliwe?
mam narastajace zbocza zegara wautomacie sterujacym. tuz po nim ustawiaja sie sygnaly sterujace... ale tych sygnalow sterujacych nie widac jeszcze w komponenecie obslugujacym sram... dopiero kolejne narastanie powoduje ze sa one tam w srodku WSZYSTKIE chwytane... no i to chwytanie juz w komponencie tez sie odbywa sekwencyjnie (proces clockowany)... konkretnie to taki:
elsif P_I_CLK'event and P_I_CLK = '1' then
REG_STROBE_N <= P_I_STROBE_N ;
REG_WR_N <= P_I_WR_N ;
REG_BENA_N <= P_I_BENA_N;
REG_ADDR <= P_I_ADDR ;
REG_DATA0 <= P_I_DATA0 ;
REG_DATA1 <= P_I_DATA1 ;
REG_DATA2 <= P_I_DATA2 ;
REG_DATA3 <= P_I_DATA3 ;
P_O_DATA0 <= REG_O_DATA0 ;
P_O_DATA1 <= REG_O_DATA1 ;
P_O_DATA2 <= REG_O_DATA2 ;
P_O_DATA3 <= REG_O_DATA3 ;
P_O_ACK <= REG_ACK ;
end if ;
end process ;
to moze bardziej na tym poziomie ma znaczenie kolejnosc?
gdzie tu w ogole miejsce na jakas asynchronicznosc?
nie chce wchodzic w mechanizmy, ktore byc moze tu nie zachodza. Moze ktos ma jakas zlota porade?
Dzieki
Dodano po 6 [minuty]:
sciagnalem ze strony producenta model sramu (taki niesyntezowalny) bliski temu ktorego uzywam. No i pojawil sie tam komunikat: "iADDR - Cyp_tAH violation"
W kodzie sprawdzilem ze wywoluje sie on gdy:
IF iCLK'DELAYED(Cyp_tAH) = '1' THEN
ASSERT (iADDR'LAST_EVENT > Cyp_tAH)
REPORT "iADDR - Cyp_tAH violation"
SEVERITY ERROR; Cyp_tAH to czas hold after clk rise. jakies 0.5 ns w zaleznosci od czestotliwosci.
Dodano po 59 [minuty]:
no i skoro we wszystkich stanach adres jest caly czas podany ten sam, nie ma zadnego momentu jego zmiany, to skad komunikat:
Error: iADDR - Cyp_tAH violation
Czy to o czyms swiadczy?
Dodano po 37 [minuty]:
jak to sprawdzic, zniwelowac...?
