Zjawisko zacinania UART w FPGA Altera Cyclone C6 przy bootowaniu z Flash

Mon Sep 27, 2004 2:51 pm   

"Pszemol" <Pszemol@PolBox.com> wrote in message news:cj8ke7.1nc.1@poczta.onet.pl...

Cytat z dokumentacji do FPGA:
"The logic, circuitry, and interconnects in the Cyclone architecture
are configured with CMOS SRAM elements. Cyclone devices are
reconfigurable and are 100% tested prior to shipment. As a result,
the designer does not have to generate test vectors for fault coverage
purposes, and can instead focus on simulation and design verification."

Ciekawe na czym polega proces tego testowania w 100% i czy można go
powtórzyć już u użytkownika, w jego płytce... Może z użyciem JTAGa?

Mon Sep 27, 2004 2:56 pm   

On Mon, 27 Sep 2004 08:51:29 -0500, Pszemol wrote:

propagacja troche trwa. W dodatku producenci sie skupiaja na podawaniu
maksymalnych czasow propagacji .. a minimalnych nie podaja.


No wlasnie, tez mnie to dziwi :-)

CHyba ze problem taki jak kiedys z Z80 - reset nie w pore powodowal
puszczenie roznych glitchy na magistrale ..

J.

Mon Sep 27, 2004 2:56 pm   

On Mon, 27 Sep 2004 08:49:06 -0500, Pszemol wrote:

Zasadniczo przyzanlbym ci racje .. ale czemu po zaladowaniu przez
Jtaga projekt dziala ?

J.

Mon Sep 27, 2004 4:06 pm   

"J.F." <jfox_nospam@poczta.onet.pl> wrote in message news:vvbgl0levnsm5a5bm5eoomuf3qkchkl3ap@4ax.com...

Weź pod uwagę, że każda kompilacja to faktycznie inny układ elektroniczny.
Niestety nie mam już projektu który trafił do flasha - znaczy się projekt
jest bez zmian, ale zmieniłem ustawienia signal-tapII więc wymusiłem
rekompilację i już nie jest z pewnością to samo...
Wystarczy że mam jakiś błąd w projekcie, gdzieś jakieś opóźnienia na
zegarach, hazardy czy ki-pieron i już się to może zegzić gdzie tylko chce.

Mon Sep 27, 2004 4:11 pm   

"J.F." <jfox_nospam@poczta.onet.pl> wrote in message news:6rbgl09hb43io603nlldu2gddlmi6sfalg@4ax.com...

No ale reset trwa "trochę"... U mnie jakieś 6 ms. Jak się zacznie
1ns przed zboczem aktywnym zegara to przecież nawet jak to zbocze
się zgubi to zdązy się zresetować jeszcze 100 razy po zboczu, nie?


Nie mam pojęcia, niestety...
Zrobiłem analizę "timing analyzer" (nie wiem czy to ten post-routing
co mi Mister zaproponował) i mam 107 ostrzeżeń, ale większość dotyczy
o dziwo, modułów bibliotecznych, np. "combinational loop of 2 nodes"
w elemencie fifo, jaki wstawiłem z biblioteki... Powtórzony tyle samo
razy ile razy mam ten moduł... Albo "found one or more latches implemented
as combinational loops" - te są w moim kodzie VHLD w którym mam rzeczywiście
zatrzask napisany tak: if (c_enable = '1') then int_data_out <= data_in;
Muszę się tym ostrzezeniom przyjrzeć bliżej, ale na razie mnie to nieco
przerasta... No bo jak mam napisać inaczej niż to, zatrzask w VHDL??? )

Mon Sep 27, 2004 6:21 pm   

On Mon, 27 Sep 2004 17:56:37 +0200, J.F. <jfox_nospam@poczta.onet.pl>
wrote:


Dokladnie - i wtedy czesc DFFow (do ktorych reset ma szybsza droge)
zresetuje sie w cyklu zegara n, natomiast ta czesc do ktorej reset ma
droge dluzsza - zresetuje sie w cyklu n+1 :-)

Generalne zalecenie - jesli nie jestes w 100% pewny co robisz, to
wstaw uklad do synchronizacji resetu z zegarkiem.


Nie - tutaj tylko czesc DFFow bedzie o 1 zegar opozniona w stosunku do
reszty :-)


--
Jerry

Mon Sep 27, 2004 6:22 pm   

On Mon, 27 Sep 2004 12:11:42 -0500, "Pszemol" <Pszemol@PolBox.com>
wrote:


Nie chodzi o moment ZALACZENIA resetu, tylko o moment "ODPUSZCZENIA"
resetu.


if(rising_edge(clk)) then
if(c_enable='1') then
int_data_out<=data_in;
end if;
end if;

Masz wtedy synchronicznie z zegarkiem.
Zasada: jesli nie wiesz co robisz, to nie uzywaj asynchronicznych
konstrukcji :-)


--
Jerry

Mon Sep 27, 2004 6:34 pm   

"jerry1111" <stop_this_spam_jerry1111_remove@remove.wp.pl> wrote in message news:i0qgl05ivah9fi791k1t29r35vbhos4d40@4ax.com...

Ok, przekonałeś mnie niech Ci będzie. Dołożę przerzutnik do resetu. ))

Co ciekawe, używam w niektórych miejscach sygnałów z CPU Motoroli 68k
do sterowania swoimi zatrzaskami czy przerzutnikami i mi kompilator
wyrzuca ostrzeżenia, że używam np. sygnału CPU_AS (address strobe)
lub CPU_RW (read/write) jako "undefined clock"... powaliło go?
Czemu miałbym nie użyć sygnału informującego o poprawnym adresie na
magistrali procesora właśnie do tego, aby ten adres sobie zatrzasnąć?
Nie rozumiem...

A już całkiem zbijają mnie z tropu te ostrzeżenia wygenerowane
wnętrzem modułów bibliotecznych... tego jest ponad setka, nie
licząc powtórzonych użyć tych modułów... Paranoja.


A... o to im chodzi... to tak mogę zrobić - oczywiście... tylko u mnie
będzie trochę inaczej:

IF (sysclk'EVENT and sysclk = '1') THEN
....

Nie mam u siebie rising_edge() :-)


ok... będę pamiętał...

Mon Sep 27, 2004 7:52 pm   

On Mon, 27 Sep 2004 14:34:23 -0500, "Pszemol" <Pszemol@PolBox.com>
wrote:


W symulacji upewnij sie ze oba zbocza daje synchronicznie z CLK - tak
na wszelki wypadek, jakbys pomieszal poziomy :-)


Bo programista, znaczy VHDLista p*$&#(*&$ )))
Napisales siakis komponent tak, ze wychodzi taktowanie przez tamte
sygnaly - to sie kokmpiluje dla zegara 1MHz????


j/w - bo sie sygnal do zegara przeksztalca :-)


Mi sie nie podoba, ale na czuja to moze byc efekt uboczny zamiany
sygnalow sterujacych na zegar i odwrotnie.


Nie tyle "moge tak zrobic", tylko KONIECZNIE tak robic.


Napewno????


Spoko - jeszcze ze 2 tygodnie, to Twoja firma moze da zarobic troche
zielonego?

NMSP :-)


--
Jerry

Mon Sep 27, 2004 8:12 pm   

"jerry1111" <stop_this_spam_jerry1111_remove@remove.wp.pl> wrote in message news:u5vgl09c1fa0in9jred78fuamnsmfadrj0@4ax.com...

OK.


Co to znaczy "wychodzi taktowanie przez sygnały"? )
Czy jeśli używam strobu adresowego generowanego przez procesor
i podaję go na wejście "enable" zatrzasku to już jest źle, kuźwa?
Bez jaj... w końcu do tego właśnie sygnał CPU_AS służy w Motoroli
aby powiedzieć urządzeniom peryferyjnym, że teraz można sobie
zczytać z magistrali stabilny adres... Podobnie z CPU_RW...


Spoko, mam "default required fmax" ustawione na 25MHz w "Clock settings".
Mimo 107 ostrzeżeń w "timing analysis" wciąż mam na koniec zielone
"Info: All timing requirements were met. See Report window for more details."
Pytanie tylko czy wszystkie "requirements" ustawiłem prawidłowo...
Ale moja motorolka pracuje z zegarkiem 18MHz więc wydaje mi się, że
jak mam ustawione w wymaganiach do 25MHz max to powinno być wsio ok.


Siem przekształca - kiedy się może przekształcić? Jakie zachowanie
"VHDLsty" ten kompilator FPGA traktuje jako przekształcenie do zegara?


E tam, marudzisz... wszystko chcesz zwalić że to moja wina
Jestes paskuda! ))


Ok, ok, nie krzycz )


Powiem tak - nigdy tego nie używałem... czy to ma jakieś zalety
w stosunku do sysclk'EVENT? Czy to jakaś funkcja biblioteczna?


Nic mi o tym nie wiadomo, ale zawsze możesz negocjować konsulting
Od paru miesięcy wchodzimy z VHDL i FPGA i jest to dla nas wszystkich
tutaj całkowita nowość... Mój szef jest na etapie jeszcze wcześniejszym
niż ja, bo ja już próbuję pisać i czytać VHDL chociaż - on musi sobie
wszystko na bramki i przerzutniki rozrysować aby cokolwiek zrozumieć ))
Dobrze że nowy Quartus II ma właśnie wizualizację kodu VHDL na bramkach
bo nie byłoby zabawy... ))

Mon Sep 27, 2004 9:06 pm   

On Mon, 27 Sep 2004 16:12:33 -0500, "Pszemol" <Pszemol@PolBox.com>
wrote:


Kompilator i optymalizator stwierdzaja, ze "programista mial na mysli"
taktowanie, a nie strob - znaczy ze tak uklad napisales.


Podales jeden przyklad - bylo _a_synchroniczne przepisanie i
kompilator to pewnie zmienil.
Po prostu sprawdz caly kod pod katem tego, czy nie ma tam jakichs
"asynchronizmow".


Prawidlowo bedzie juz przy 18MHz. Generalnie mozesz miec duze
zwolnienie w momencie gdy sygnaly zegara sa poroutowane w srodku ze
zwyklego pina do dedykowanych sciezek zegarowych. Wystepuje cos
takiego wlasnie w momencie uzywania zwyklego sygnalu jako zegara.


process(clk,enable)
begin
if(enable='1') then
wy<=we;
end if;
end;

wlasnie tutaj.


90% daje :-)


Dla mnie prosciej napisac
Innych efektow ubocznych brak.


Z rok czasu to _minimum_ jeszcze potrwa ta nowosc.


Nie chodzi o to zeby zrozumiec, tylko o to zeby nabrac swoistego
'wyczucia' i zrozumiec jak to wszystko dziala i co do czego sie
kompiluje. Przeciez kilka(nascie) linijek potrafi sie skompilowac do
jednego DFFa. Tutaj trza sobie wyobrazac jak uklad ma _dzialac_ i
dopiero wtedy pisac kod. Cholera - nie mam pomyslu jak to napisac, ale
to jest takie odwrotne myslenie niz w trakcie pisania zwyklego
programu.


Ma??
Ale bedzie fajnie... bedzie durnoty pewnie pokazywac :-)

Na serio - 90% stawiam na to ze problem wynika z pomieszania tych
zegarow. 1% to uszkodzenie fpga, a reszta... to reszta
To ze nie dziala na jednej kosci a dziala na drugiej kosci tez pasuje
do mojej teorii - po prostu kosc dzialajaca jest widac minimalnie
szybsza (szybsza propagacja) niz kosc nie dzialajaca.


--
Jerry

Mon Sep 27, 2004 11:46 pm   

On Mon, 27 Sep 2004 12:06:40 -0500, Pszemol wrote:

I od tego trzeba bylo zaczac. A pytalem czy jestes pewny ze wersje sa
te same ?
A .. przepraszam, w koncu flash z podejrzanej plyty dobrze dziala w
drugiej, a flash z drugiej zle dziala w pierwszej ..


No to wpisz to do flasha i zobacz co sie bedzie dzialo.

J.

Tue Sep 28, 2004 2:36 am   

"J.F." <jfox_nospam@poczta.onet.pl> wrote in message news:4bahl01ghj1uludjjonj51iu4b91odj6u1@4ax.com...

No właśnie - ten flash to jedyna kopia tego oryginalnego kodu,
który robi fochy.


Tak zrobię.

Tue Sep 28, 2004 2:45 am   

"jerry1111" <stop_this_spam_jerry1111_remove@remove.wp.pl> wrote in message news:1t2hl0lu9n71g1i9t1e24t3f8iq6dvid8f@4ax.com...

No dobra... a jak w takim razie napisać prawidłowo normalny zatrzask
bez sygnału zegara?


Zmienił na synchroniczne?? 8-)


No to czemu nie działa? I czemu dajesz 90% szans na błąd?


Te "undefined clocks" o tym świadczą, ale ki pieron wie dlaczego jakiś
sygnał, np. CPU_RW potraktował jako clock??? Tego jeszcze nie wiem.


A inne przykłady?


Paskuda :-)


Łojejku...
Aż rok się trzeba tego uczyć? A jak ktoś nieco mniej zdolny? ;-)


ok, ok...


No czasami pokazuje taką sieczkę, że rzeczywiście tylko w VHDL
da się to przeczytać... Mam tam w UARTcie maszynę stanów nadajnika,
to ten wizualizator wysmolił dwie strony bramek i przerzutników...
Konia z rzędem temu, kto bez kodu VHDL skapnie się co "autor miał
na myśli" i jak ten układ działa...


Sprawdzę czy są z tej samej serii produkcyjnej... Układy mają
wymalowany tydzień w roku w którym zostały wyprodukowane...
Ciekawe to wszystko jest - szkoda że tyle niewiadomych...
I najbardziej niepokojące te "warningi" których nie ma jak
za bardzo ugryźć bo większość wskazuje na moduły biblioteczne

Tue Sep 28, 2004 7:26 am   

Użytkownik "Pszemol" <Pszemol@PolBox.com> napisał w wiadomości
news:cj8ke6.1nc.0@poczta.onet.pl...

Jeżeli chodzi o wylutowywanie to możesz użyć bardzo sztywnego i cienkiego
drucika ( np. wolframowy (?) ) zakładając go "od środka" i w miarę
nagrzewania cyny pod nóżkami delikatnie go wysówać podważając nóżki.
Zdejmowałem tak TQFP100 - i działa :)

Pozdrawiam,
Grzegorz Kepiński