Procesor wejscia-wyjscia w FPGA

Marcin E Hamerla wrote on Mon, 03 Jan 2005 13:07:28 +0100:

Tak, ale mowa jest o rysowaniu schematu urządzenia z wykorzystaniem biblioteki elementów emulujących standartowe kości TTL/CMOS.

Regards, /J.D.

Jan Dubiec napisal(a):

I mowa jest tez o symetrycznym opisie HDL przy uzyciu makrofunkcji TTL?

Nie, no bo i po co?

Regards, /J.D.

Jan Dubiec napisal(a):

Nie rozumiem o co Ci chodzi zatem. Znaczy, rozumiem, ze taki sposob porownania to ustawianie sobie chlopca do bicia.

Marcin E Hamerla wrote on Tue, 04 Jan 2005 09:19:36 +0100:

Nic z tych rzeczy. Dotykamy tutaj problemu projektowanie/synteza behawioralna czy RT/gate level. Stosując graficzny opis projektu jesteś skazany na RTL/gate level: składasz projekt z funktorów, przerzutników i/lub bardziej złożonych elementów (multipleksery, sumatory itp). Stosując opis tekstowy masz wybór: możesz stosować podejście behawioralne (zwięzły i przejrzysty opis tekstowy, oddający funkcjonalność projektu bez wniakania w szczegóły) lub RT/gate level (opis rozwlekły, w zasadzie taki schemat zapisany w formie tekstowej). Jak dotąd wystarcza mi podejście behawioralne. Oczywiście nic nie jest za darmo, i na podstawie opisu behawioralnego syntezer wygeneruje gorszy "kod", tzn. taki który wymaga więcej zasobów w PLD. Jest to sytuacja analogiczna do problemu assembler czy jezyk wysokiego poziomu w przypadku programowania uC.

Regards, /J.D.

No ale w przypadku wielu problemow mozna wyroznic mniejsze podproblemy, a w nich jeszcze mniejsze itd. Wowczas podejscie diagramatyczne moze byc bardzo owocne i czytelne -- przeciez nikt nie wprowadza ograniczenia "blok = bramka albo uklad MSI". Bloki z kolei mozna skladac z jeszcze mniejszych blokow, albo w przypadku napotkania problemu podac jego opis funkcjonalny lub strukuralny. Ja tego rodzaju narzedziom wroze sukces, zarowno w przypadku tworzenia hardware, jak i software (no, tu juz jest UML...). :-)

Pozdrawiam Piotr Wyderski

Jan Dubiec napisal(a):

Ja nie jestem mocny z teorii i nie rozumiem roznicy. I w jednym i w drugim podejsciu tworzysz rownania korzystajac z negatorow / ANDow / ORow / XORow / itd. Czy wezmiesz ANDa z biblioteki czy wstawisz & wyjdzie na to samo. Rysujac schemat robisz strukture hierarchiczna taka jak w HDL. Spotkalem sie z opiniami, ze najlepsza metoda projektowania PLD jest robienie blokow niskiego poziomu w HDL, a top_level jako schemat. Wtedy masz samodokumnetujacy sie projekt. Ale u mnie robimy wszystko w HDL - wieksza wygoda.

Chodzi o to że stosując opis tekstowy w HDL możesz używać podejścia behawioralnego, czego nie możesz zrobić przy rysując schemat. Poniżej masz przykład 11 bitowego rejestru przesuwającego w VHDL-u. Nie musisz męczyć się malowaniem 11 przerzutników w schematorze albo opisem tekstowym przy podejściu "gate level synthesis" ponieważ syntezer wygeneruje za Ciebie 11 odpowiednio połączonych przerzutników. W sam raz shiftery są w bibliotekach schematorów chyba wszystkich narzędzi do projektowania PLD, ale można sobie przecież wyobrazić jakiś mniej standartowy element. Ponadto poniższy opis jest niezależny od narzędzia/docelowego układu.

entity shift_reg is port( I: in std_logic; clock: in std_logic; shift: in std_logic; Q: out std_logic ); end shift_reg;

architecture shift_reg_arch of shift_reg is

-- initialize the declared signal signal S: std_logic_vector(10 downto 0):="11111111111";

begin process(I, clock, shift, S) begin

-- everything happens upon the clock changing if clock'event and clock='1' then if shift = '1' then S <= I & S(10 downto 1); end if; end if;

end process; -- concurrent assignment Q <= S(0);

end shift_reg_arch;

To ma swoje zalety, ale szczerze mówiąc nie jestem w pełni przekonany czy jako top level lepszy jest schemat czy plik tekstowy. Mam jeszcze za mało doświadczenia.

No i macie przynajmniej spójne źródła. Tzn. wszystko zapisane w ten sam sposób w plikach tego samego typu. I to jest IMO duży plus. Problem w tym że stworzenie pliku "top level" jest IMO bardzie upierdliwe niż namalowanie kilku(nastu/dziesięciu) odpowiednio połączonych prostokątów. Prznajmniej w VHDL-u.

Regards, /J.D.

No można, ale czy taka wielopoziomowa dekompozycja pozwoli szybciej osiągnąć założony cel? IMO, póki co, nie. A stosowanie opisu behawioralnego pozwala ograniczyć do minimum grzebanie się w szczegółach implementacji, a więc szybsze efektu końcowego.

No właśnie, gdy takowe powstaną. :-) Ja przynajmniej o takich narzędziach jeszcze nie słyszałem. Chociaż początki już są - diagramy stanów można już sobie malować - vide StateCAD w Webpacku.

Regards, /J.D.

Piotr Wyderski napisal(a):

Duze maszyny stanow. Zwroc uwage na ilosc wejsciowej komorki w CPLD i w FPGA. Male CPLD zajmuja z kolei mniej miejsca niz FPGA i mniej kosztuja.

Tego nie wiem, ale nie tylko szybkosc sie liczy. Reprezentacja graficzna powinna byc znacznie czytelniejsza od tekstowej, co powinno korzystnie wplynac na poprawnosc projektu. Skoro wlasciwie jedyna dostepna dzis na szersza skale metoda weryfikacji projektu jest jego symulacja, to skad wiadomo, ze napisales wlasnie to, co powinienes byl napisac? W pelni formalne, automatyczne dowodzenie poprawnosci specyfikacji sie intensywnie rozwija, ale sa dwa zasadnicze problemy:

a) mozliwosci sa jeszcze zbyt male w porownaniu do zapotrzebowania.

b) przecietny uzytkownik takiego systemu nie bedzie potrafil sformulowac pytania, ktore chce zadac. O ile w HDL pisac moze zasadniczo kazdy, to do weryfikacji napisanych specyfikacji potrzeba sporych umiejetnosci.... :-(

Pocieszajace chociaz, ze z weryfikacja oprogramowania jest jeszcze gorzej -- rekurencyjny hardware nie jest realizowalne technologicznie. :-)

Dlatego wlasnie bronie diagramow -- jesli nie ma rozwiazania doskonalego, to trzeba sie ratowac tym, co jest pod reka.

Niestety opis behawioralny (funkcjonalny) przestaje byc czytelny, gdy realizowana funkcja zalezy od wielu czynnikow, globalnego stanu itd. Dla malych systemow o prostej podstrukturze jest bardzo dobry, ale gdy wszystko zaczyna zalezec od wszystkiego, zaczyna sie horror...

Tak, ale diagram przejscia stanow to jest tylko niewielki fragment specyfikacji systemu. Mnie by sie znacznie bardziej przydala mozliwosc zadawania pytan o sciezki na tym diagramie (np. czy istnieje taki ciag przejsc stanow, ktory prowadzi np. do wybuchu nadzorowanego kotla parowego).

Pozdrawiam Piotr Wyderski

Czasem jest, a czasem nie jest.

A juz zupelnie nie widze sensu rysowania zlozonej funkcji kombinacyjnej za pomoca bramek, i to w dodatku koniecznie zestawu kiedys zrobionego w TTL ..

J.

Zgadza sie, dlatego zaproponowalem podejscie hybrydowe:

Pozdrawiam Piotr Wyderski

J.F. napisal(a):

I dlatego w schematorach sa biblioteki elementow typu dekodery, sumatory, itd.

Jan Dubiec napisal(a):

Wydaje mi sie, ze to moze miec znaczenie w duzych firmach, gdzie wiecej niz jedna osoba musi sie zajmowac danym projektem. W malej firmie to nie musi byc az tak istotne. Ja sie staram wszystko w mojej firmie, malej przeciez, dobrze dokumentowac (elektronicznie), ale ten top level w postac sch nie uznaje za wazna sprawe. Wazniejsza dla mnie jest latwosc modyfikowania plikow tekstowych.

Prawdziwe, prawdziwe :-) do EP1C6 pakuje 2 sztuki 16bit Niosa i jest jeszcze troche luzu, albo

jerry1111 wrote on Wed, 12 Jan 2005 18:46:48 +0100: [.....]

A jakiego toolchain-a używa się do tworzenia softu pod NIOS(II)? Chodzi mi o kompilator, linker, itp. Czy jakieś narzędzia są dostarczane razem z NIOSem czy trzeba za nie zapłacić dodatkowo? A jakiego evalboard-a byś polecił? Chodzi mi o coś do $200 (wliczając koszty przesyłki, VAT i inne opłaty). Chciałem sobie kupić

BTW. Myślałem że nieżyjesz. ;-)

Regards, /J.D.

Jan Dubiec napisał(a):

najtańsze co znalazłem to

a jakie podają powody oficjalnej nieobecności???

Tawez wrote on Thu, 13 Jan 2005 11:48:40 +0100: [.....]

na swoim WWW. ;-)

Ponieważ w Polsce (i chyba w całej Europie) Alterę sprzedaje EBV i trochę Arrow. Ameryka Pólnocna jest z kolei podzielona pomiędzy Future i Arrow. Logika marketingowców i handlarzy jest jednak zdecydowanie inna niż logika ludzi technicznych. ;-)

Regards, /J.D.