FPGA Altery bootujące się z szeregowego EPROM/FLASH

"Pszemol"

szkoda, to prawie tak pasjonujace, jak kryminal ;)

mamy podstawki pod Stratix, 1508 pin FBGA; jak sa klopoty, to najpierw podklada sie kawalek papieru pod pokrywke dociskajaca Altere do podstawki; dosc czesto problemy znikaja, w kazdym razie wiekszosc z nich :) po jakims czasie trzeba dodac jeszcze jeden papierek ...

kiedys prototyp zaczal dzialac 'w kratke', kilka dni zajelo znalezienie przyczyny, jeden z trzech opornikow ustalajacy sposob bootowania byl 'zimny', ktos ruszyl plyte, przestawal stykac, nastepne tracenie i znow byl kontakt;

w jednym z poprzednich postow bylo pytanie o tryger w Sig. Tap; ja bym dodal jakis licznik, ktory zlicza czas braku aktywnosci na interesujacej linii [czyli jest zerowany zmiana poziomu na tej linii] - i Sig. Tap mozna trygerowac na wartosc tego licznika, czyli osiagnac wlasnie to: "RXINT nie sygnalizuje przez N milisekund" dodanie kawalka kodu sluzacego wylacznie do debuggowania zwykle ulatwia zycie; jeszcze o Signal Tap - dobra praktyka jest back annotate golego projektu, i dopiero potem dodanie ST, timing nie bedzie sie zmienial od kompilacji do kompilacji;

JA

Zak³adam, ze skoro zaprogramowalem tym kodem 3 nastepne plyty i wszystkie dzia³aj± bezb³ednie to pewnie jednak poszed³ siê kochaæ ten FPGA "elektrostatycznie". Ale to naprawdê dziwne, bo "w miarê" dzia³a³.

:-))) Acha... to ja ju¿ jednak wolê porz±dnie sobie polutowaæ :-)

No takie co¶ to jest cholerstwo... ciekawe ilu in¿ynierów zesz³o na zawa³ zdenerwowanych niew³a¶ciw± prac± swej p³yty prototypowej uszkodzonej w taki wredny sposób ;-)

Bardzo dobry pomys³. Bo sam kod procesora czu³y jest na INT a nie na jak±¶ zmienn± stanu któr± mogê sobie obczaiæ licznikiem. Dziêki.

Jasne. Ale w moim przypadku jakakolwiek zmiana kodu w FPGA powodowa³a, ¿e uk³ad ju¿ dzia³a³ bez b³edu, wiêc...

No nic, jak ju¿ wytestuje te 3 nowe p³yty do koñca to wrócê mo¿e do tej jednej trefnej - zanim wymieniê FPGA to zaprogramujê EEPROMa nowym kodem - zobaczê co bêdzie.

Hm... A jak to nale¿y zrobiæ w Quartusie II ? Mam wersjê 4,1.

"Pszemol":

tez wole :) ale i z przylutowana mialem 'przygode', jeden pin zasilajacy I/O byl przylutowany troche, wiec caly bank I/O dzialal 'troche';

wiec moze jednak uszkodzona jedna czy kilka cel w srodku ? choc nie slyszalem jeszcze o takim przypadku w praktyce; moznaby zapytac Altere, czy to w ogole jest do sprawdzenia w 'domowych' warunkach; a moze ta felerna FPGA ma inny speed grade niz inne ?

"critical update" tez ? Altera znalazla buga w tej wersji;

skompilowac [i zrutowac oczywiscie], jesli timing analizer pokazuje, ze wszystko jest ok: assignments back-annotate assignments nie mam w domu quartusa, wiec nie pamietam ktore pola trzeba 'odfajkowac', ale to chyba jest w miare proste; chodzi o to, by narzedzie zapisalo polozenia logiki w konkretnych LAB'ach i w nastepnych kompilacjach umieszczalo te sama togike w tym samym miejscu;

rzecz jasna ma to sens, jesli uklad pracuje z czestotliwoscia wyzsza niz kilkanascie MHz, bo inaczej o klopoty z timingiem trzeba sie specjalnie postarac, i jesli projekt zajmuje wiecej niz 50% zasobow kosci;

JA