Sludig wrote:
> Witam
>
> Po przeczytaniu waszych uwag zrobiłem co następuje:

[cut]

> Na wykonanie symulacji post-fix nie
> miałem czasu niestety.

Dlatego nie wiadomo co sie dzieje.

--
Jerry1111

do góry

Sludig pisze:
> Witam
>
> Po przeczytaniu waszych uwag zrobiłem co następuje:
> - Zamiast dzielić clocka dla UARTu użyłem w jego strukturze ClkEnable
> - Wszystkie sygnały wejściowe przechodzą przez rejestry wejściowe DFF (w
> celach testowych)
> - dodałem stan w FSM, w którym układ się zatnie jeżeli przejdzie do
> others =>
>
> Jednak nadal jest tak, że po zmianie numeracji stanów na Hot-one układ
> przestaje działać, ale najwyraźniej nie wchodzi do others (albo
> kompilator zoptymalizował ten stan). Na wykonanie symulacji post-fix nie
> miałem czasu niestety.
>
> pozdrawiam
> sludig

Witam,

Ja tam bym chciał zobaczyć ten automat :)

Adam

do góry

> Ja tam bym chciał zobaczyć ten automat :)

Automat jak automat: Mealy'ego składający się z około 16 stanów. Poza tym
kilka liczników o "wyszukamy" działaniu, rejestr przesuwny, UART, logika
kombinacyjna, itp.

Pozdrawiam
Sludig

do góry

>> Na wykonanie symulacji post-fix nie
>> miałem czasu niestety.
>
> Dlatego nie wiadomo co sie dzieje.

Udało mi się uruchomić tą symulację (errory jakoś same znikęły niewiedzieć
czemu) i wygląda na to że źródłem problemów są hazardy.
Patrzałem narazie tylko na symulacje wariantu działającego, a i tak wygląda
nieciekawie. Całego przebiegu jeszcze nie obejrzałem.
Niestety niektóre sygnały zostały zoptymalizowaneb co utrudnia interpretacje
wykresów - nie ma na przykład state_present i
state_next. Problemem może być sygnał nWriteEnable pamięci SRAM. Wartość
jest zapisywana na zboczu narastającym tego sygnału, jednak
jego w jego przebiegu jest szpika zera przed właściwym zezwoleniem na zapis.
Sygnał ten zależy jest od trzech sygnałów:
nWriteEnable <= nWriteToMem or Clock or (not nReadFromMem);
a mimo tego wygląda na sporo opóźniony względem clocka.

Poza tym wygląda na to, że adres komórki za szybko się zmienia po
narastającym zboczu nWriteEnable. Jutro to wszystko dokładniej
przebadam.

Czy da się zmusić kompilator żeby nie optymalizował wybranych sygnałów?

Teraz mam tak zrobione, że stan automatu zmienia się na innym zoboczu zegara
niż dane wejściowe, żeby podczas zmiany stanu ich wartość była stała. Dobrze
robie czy może z jakiegoś powodu stan powinien zmieniać się na tym samym
zboczu co sygnały sterujące?

pozdrawiam
Sludig

do góry

> Teraz mam tak zrobione, że stan automatu zmienia się na innym zoboczu
> zegara niż dane wejściowe, żeby podczas zmiany stanu ich wartość była
> stała. Dobrze robie czy może z jakiegoś powodu stan powinien zmieniać
> się na tym samym zboczu co sygnały sterujące?

Jak będziesz zmieniał na tym samym, to pamiętaj, że automat będzie
widział "poprzedni" stan wejść... z reguł nie jest to problem, bo w
praktyce rzadko kiedy się liczy KTÓRY to jest cykl zegara, raczej czas
pomiędzy jest ważny... a z tym nie ma problemu - WSZYSTKO jest
przesunięte ;).. no ale niestety, sama zamiana może nic nie dać, pewnie
będziesz musiał przerobić symulację ;P...
Jednak takie wyjście jest trochę lepsze!! Zauważ - jak masz zegar 50MHz
(taki chyba masz, nie??), to okres zegara to 20ns. Jeśli wejścia są
zapamiętywane na tym samym zboczu co stan automatu, to po zapamiętaniu
układ ma 20ns na ustalenie się funkcji wzbudzeń przerzutników (czyli na
przepropagowanie się sygnałów przez bramki). Jeśli masz na różnych
zboczach - to układ ma na to tylko 10ns (połowa okresu)... a jeśli
miałbyś zegar niesymetryczny, to jeszcze mniej ;). jeśli NA PEWNO winne
są hazardy - warto może byłoby zacząć pracować na jednym zboczu??
A swoją drogą - na jakim układzie pracujesz?

Pozdrawiam!
Konop

do góry

Sludig wrote:
> Problemem może być sygnał nWriteEnable pamięci SRAM. Wartość
> jest zapisywana na zboczu narastającym tego sygnału, jednak
> jego w jego przebiegu jest szpika zera przed właściwym zezwoleniem na
> zapis.
> Sygnał ten zależy jest od trzech sygnałów:
> nWriteEnable <= nWriteToMem or Clock or (not nReadFromMem);
> a mimo tego wygląda na sporo opóźniony względem clocka.

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).

>
> Poza tym wygląda na to, że adres komórki za szybko się zmienia po
> narastającym zboczu nWriteEnable. Jutro to wszystko dokładniej
> przebadam.

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

> Czy da się zmusić kompilator żeby nie optymalizował wybranych sygnałów?

Xilinx nie wiem, Altera ma 'virtual pin'.

> Teraz mam tak zrobione, że stan automatu zmienia się na innym zoboczu
> zegara niż dane wejściowe, żeby podczas zmiany stanu ich wartość była
> stała. Dobrze robie czy może z jakiegoś powodu stan powinien zmieniać
> się na tym samym zboczu co sygnały sterujące?

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

--
Jerry1111

do góry

Sludig wrote:
>
>> Ja tam bym chciał zobaczyć ten automat :)
>
> Automat jak automat: Mealy'ego składający się z około 16 stanów. Poza tym
> kilka liczników o "wyszukamy" działaniu, rejestr przesuwny, UART, logika
> kombinacyjna, itp.

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

--
Jerry1111

do góry

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

> 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.

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

> > Czy da się zmusić kompilator żeby nie optymalizował wybranych sygnałów?
> Xilinx nie wiem, Altera ma 'virtual pin'.

'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

do góry

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

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

do góry

> 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;

Dzięki. To się przyda.

> 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;

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

do góry