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

W to nie wierze... bardziej stawiam na niedoskonaly opis timingow w srodku struktury - dlatego dla kompilatora wydaje sie, ze jest dobrze...

Policz sobie ile taki tester musialby chodzic zeby sprawdzic 100% FPGA....

Powiedz coś więcej na ten temat...

Akurat problem opisywany w tym wątku to inny projekt, bez niosa. Te akurat projekt wykorzystuje procek motoroli MC68SEC000.

W przykladowych designach z Niosem2 masz pin resetu podlaczony do procka przez taki uklad 'reset delay' czy podobnie sie nazywajacy. Glownie chodzi o to, ze przychodzacy impuls resetu jest asynchroniczny

- czyli jak mamy uklad reagujacy na narastajace zbocze i reset przyjdzie np: 1ns przed tym zboczem to czesc DFFow sie zresetuje, a czesc ma prawo nie zdazyc :-) Dlatego trza ten reset przeformowac na synchroniczny z naszym zegarkiem.

To nic - masz tam reset?

W praktyce kup cyne, albo lepiej zestaw (cyna+topnik) "ChipQuick". To jest cyna o temperaturze topnienia 60 st. C - zalutowujesz caly scalak i przez 5...10s cyna jest plynna, wiec po prostu zdejmujesz scalak przy pomocy zwyklej pincety :-)

Aha - po "tamtej stronie" moze sie te cudo inaczej nazywac...

Bawiłem się tym czymś przy innej okazji i jakoś mi to nie podeszło... Ale może spróbuję jeszcze raz.

Obawiam się, że nie robiłem :-)

Tu się dokładnie zgadzamy... też nie wierzę, że upaliła się jakaś bramka wewnątrz... Podejrzewam niedoskonałości swojego projektu najbardziej.

hm... W moim układzie scalonym jest niewiele tych bloczków... Przetestowanie każdego z osobna a potem kombinacji połączeń między nimi nie powinno być chyba ogromnym problemem dla peceta.

Ciekawe, ciekawe... dlaczego ma prawo nie zdążyć? Nie wiedziałem, że są takie ograniczenia dla asynchronicznego "clear". Musiałem nieuważać kiedyś na lekcjach z cyfrówki ;-)

No reset wchodzi do układu i resetuje wiele przerzutników, fakt...

Mówisz może o jakimś driverze do niosa2?

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?

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

J.

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.

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.

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

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

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

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

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

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.

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.