Autor Wątek: Procesor  (Przeczytany 7784 razy)

agent_J

  • Gość
# Kwiecień 16, 2006, 00:36:25
Ok, zabrałem się za projektowanie tego procesora jeszcze raz. Teraz sobie rozpisuję wszelkie formaty instrukcji, tryby adresowania, wyliczania adresów efektywnych, stany potoku wykonawczego, stany kontrolera pamięci, wyjątki, itp. bo bez tego przy takim projekcie ciężko :) Potrzebne mi jest to do rozpisania sobie wszelkich stanów generowanych przez układ sterowania i dekoder instrukcji (np. sterowanie multiplekserami w celu dynamicznego generowania odpowiednich ścieżek przepływu danych). Wzoruję się na procesorach motoroli m68k, bo mają fajny zestaw instrukcji  ;D



Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline SauRooN

  • Użytkownik

# Kwiecień 16, 2006, 00:42:42
SauRooN@ tak z ciekawości. Ile czasu sie już tym "bawisz" ?
Heh, tak jak już mówiłem, to nie jest moja działka :) Na studiach miałem architekturę komputerów i projektowaliśmy tam parę rzeczy i wtedy stwierdziłem że fajnie byłoby zaprojektować sobie prostego, ale kompletnego (w miarę) kompa. Zajmowałem się tym przez rok, ale jako hobby. Teraz miałbym ochotę zaprojektować sobie jakiś prosty układ graficzny, ale bardzo niewiele jest materiałów na ten temat.

// edit:
agent_J: hehe, bierzesz się za potokowy, nieźle :) Ja robiłem niepotokowego RISC'a, stwierdziliśmy że kompletnego potokowego by się 2 razy dłużej robiło, więc dałem sobie spokój :)
« Ostatnia zmiana: Kwiecień 16, 2006, 00:47:31 wysłana przez SauRooN »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Kwiecień 16, 2006, 01:21:18
Cytuj
Teraz miałbym ochotę zaprojektować sobie jakiś prosty układ graficzny, ale bardzo niewiele jest materiałów na ten temat.
Też mam taką ochotę, ale obecnie nie mam czasu, żeby wogóle zaczynać zabawę z FPGA. Co do materiałów, zależy, co chciałbyś zrobić, ale na pewno da się coś znaleźć, chociaż niekoniecznie bezpośrednio dotyczące projektowania takich układów. Jeżeli chodzi o rendering, to myślę, że można było by wyjść od renderowania przetworzonych trójkątów, a na ten temat można sporo znaleźć informacji, jak to się kiedyś software'owo odbywało. Można oczywiście zastosować prostsze podejście i na przykład ograniczyć się do generatora sygnału wizyjnego (sposób sterowania TV Out nie jest zbyt trudny), albo pójść w zupełnie inną stronę i pobawić się na przykład w raytrace'owanie. Tak, czy inaczej, podstawowa zasada pozostaje niezmienna - jak czegoś nie można znaleźć, to zawsze można kombinować samemu. :)

Oczywiście, jeżeli chodzi o zabawę z grafiką, to przydało by się do FPGA podłączyć jakiś mikrokontroler (8051, czy AVR), który by tym sterował. :)

Offline SauRooN

  • Użytkownik

# Kwiecień 16, 2006, 01:32:23
Jeżeli chodzi o rendering, to myślę, że można było by wyjść od renderowania przetworzonych trójkątów, a na ten temat można sporo znaleźć informacji, jak to się kiedyś software'owo odbywało.
Hehe to to ja dobrze wiem jak to się odbywało ;) Ale nawet do samego renderowania przetworzonych trójkątów to już by wyszedł nieźle skomplikowany układ. Poza tym ciężko byłoby to testować software'owo (chyba musiałbym napisać do tego jakiś symulatorek). Na znalezienie materiałów raczej nie liczę, poprostu miło byłoby zamienić kilka słów z kimś, kto już to robił.

Btw. gdyby kogoś to interesowało, to mogę udostępnić to co mi zostało z tamtego projektu, nie wiem czy mam wszystko, ale sporo układów jest rozpisanych. Procek (chyba 40 instrukcji), ALU, jednostka sterowania, kontroler pamięci, cache i jakieśtam drobiazgi. Niestety nie miałem czasu rozpisać wszystkiego w VHDL'u, ledwie zacząłem, ale dokumentacja jest raczej kompletna.

agent_J

  • Gość
# Kwiecień 16, 2006, 01:35:50
Heh, tak jak już mówiłem, to nie jest moja działka :) Na studiach miałem architekturę komputerów i projektowaliśmy tam parę rzeczy i wtedy stwierdziłem że fajnie byłoby zaprojektować sobie prostego, ale kompletnego (w miarę) kompa. Zajmowałem się tym przez rok, ale jako hobby. Teraz miałbym ochotę zaprojektować sobie jakiś prosty układ graficzny, ale bardzo niewiele jest materiałów na ten temat.

// edit:
agent_J: hehe, bierzesz się za potokowy, nieźle :) Ja robiłem niepotokowego RISC'a, stwierdziliśmy że kompletnego potokowego by się 2 razy dłużej robiło, więc dałem sobie spokój :)

Potokowy się będzie różnił tylko  ::) zrobieniem kolejki sygnałów sterujących, zmienionym dekoderem rozkazów trochę (żeby pakował dane do tej kolejki i robił wstępne dekodowanie i żeby w ostatnim bloku dekodowanie dokańczał) oraz blokiem sprawdzającym zależność od siebie wstępnie zdekodowanych instrukcji. Dodatkowo trzeba by obsługiwać zmianę przepływu sterowania (wszelkie zmiany licznika rozkazów),  żeby "czyściło" potoki 8) - czyli dużo pracy.

Z układem graficznym nie będzie wiele problemów. Bardzo ważna jest 2 portowa pamięć RAM, bo bez tego trzeba by było blokować generację sygnałów sterujących monitora i by się timingi mogły rozjechać :P
Wysyłanie obrazu do monitora samo w sobie jest proste.

Ja bym sobie podzielił taki układ na następujące bloki:

- dwuportowa pamięć obrazu
- generator sygnału obrazu - najlepiej, żeby robił transfer blokowy danych np. całą linię na raz - FIFO
- jednostka rastrowa (pixele, linie, wypełniane prostokąty, clipping, itp.)
- blok interfejsu do świata zewnętrznego

Na początku najlepiej by było poimplementować wszelkie algorytmy rysowania w C i potem przerabiać pod VHDL.
Też się kiedyś zabierałem za robienie karty graficznej, ale mi się odechciało właśnie przez 2 portową pamięć RAM, a konkretnie konieczność napisania kontrolera :)

agent_J

  • Gość
# Kwiecień 16, 2006, 02:00:39
Oczywiście, jeżeli chodzi o zabawę z grafiką, to przydało by się do FPGA podłączyć jakiś mikrokontroler (8051, czy AVR), który by tym sterował. :)
Podlaczanie AVR (o 51 nie wspomne) to kompletne nieporozumienie :). Te 8-bitowce nie posiadajace duzej mocy obliczeniowej (robilem na AVR-ku DSP do radia - pierwszy entuzjazm ustapil jak zaczynalo brakowac mocy i trzeba bylo ostro ciac po "efektach" :)). Natomiast zupelnie ciekawie by moglo wygladac podlaczenie ARM-a - full 32 bit procki, najlepszy dostepny na seguro wyciaga 200 MIPS-ow. Na takim sprzecie mozna juz niezle szalec :]

agent_J

  • Gość
# Kwiecień 16, 2006, 02:06:22
Cytuj
Też się kiedyś zabierałem za robienie karty graficznej, ale mi się odechciało właśnie przez 2 portową pamięć RAM, a konkretnie konieczność napisania kontrolera
Taka dynamiczna ze starego PC może być, czy musi być jakaś specjal ?

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Kwiecień 16, 2006, 02:23:27
Cytuj
Ale nawet do samego renderowania przetworzonych trójkątów to już by wyszedł nieźle skomplikowany układ.
No to minimalistycznie: wypełnianie scanline'ów gradientem i generacja sygnału wizyjnego. :) Dodanie do tego Z-bufora nie powinno być trudnym zadaniem. Nieco gorzej z teksturowaniem, bo wymaga to wykonania dzielenia per-pixel, a to raczej ciężka operacja.

Swoją drogą, zna ktoś może efektywne metody wykonywania mnożenia i dzielenia sprzętowo? :)

Cytuj
- jednostka rastrowa (pixele, linie, wypełniane prostokąty, clipping, itp.)
Clipping odbywa się na wcześniejszym etapie i rasterizer nie ma z nim wiele wspólnego. :)

Cytuj
Też się kiedyś zabierałem za robienie karty graficznej, ale mi się odechciało właśnie przez 2 portową pamięć RAM, a konkretnie konieczność napisania kontrolera :)
A nie można po prostu odpowiednio zaprojektować cyklu pracy takiego układu? Na przykład, gdy układ wyświetlający pobiera kolejny pixel, część renderująca jest wstrzymywana (np. przez zabramkowanie jednego cyklu zegara).  Jeżeli układ byłby taktowany 50MHz, to strata mocy obliczeniowej części renderującej nie była by aż taka wielka. Dostęp z częstotliwością 8MHz powinien wystarczyć do wyświetlenia obrazu, a biorąc pod uwagę, że można pobierać kilka pikseli na raz (np. 8 bitów na piksel przy 32-bitowej szynie danych), oraz to, że nie zawsze nowe piksele są potrzebne (wygaszanie poziome i pionowe), stratę mocy obliczeniowej można sprowadzić do pojedynczych procentów. :)

Alternatywnym rozwiązaniem może być także zastosowanie dwóch osobnych pamięci i przełączanie się pomiędzy nimi. W końcu backbuffer też jest rzeczą pożyteczną. :)

Cytuj
Podlaczanie AVR (o 51 nie wspomne) to kompletne nieporozumienie
Oczywiście, że im więcej mocy, tym lepiej (i drożej :P), ale chodzi tu o samo sterowanie, więc nawet dobrze zaprogramowany 8051 powinien być w stanie generować scanline'y we w miarę znośnym tempie. :)

Cytuj
Taka dynamiczna ze starego PC może być, czy musi być jakaś specjal ?
PC'towe pamięci są, chyba jednoportowe. :)

Przy okazji: bawił się ktoś może w podłączanie PC'towych pamięci do swoich układów? :)

agent_J

  • Gość
# Kwiecień 16, 2006, 10:59:01
Cytuj
Ale nawet do samego renderowania przetworzonych trójkątów to już by wyszedł nieźle skomplikowany układ.
No to minimalistycznie: wypełnianie scanline'ów gradientem i generacja sygnału wizyjnego. :) Dodanie do tego Z-bufora nie powinno być trudnym zadaniem. Nieco gorzej z teksturowaniem, bo wymaga to wykonania dzielenia per-pixel, a to raczej ciężka operacja.

Swoją drogą, zna ktoś może efektywne metody wykonywania mnożenia i dzielenia sprzętowo? :)

Wpisz w google FPGA+multiplication+algorithm :)

Cytuj
Cytuj
- jednostka rastrowa (pixele, linie, wypełniane prostokąty, clipping, itp.)
Clipping odbywa się na wcześniejszym etapie i rasterizer nie ma z nim wiele wspólnego. :)

No to clip może się obdywać przed rysowaniem ;p

Cytuj
Cytuj
Też się kiedyś zabierałem za robienie karty graficznej, ale mi się odechciało właśnie przez 2 portową pamięć RAM, a konkretnie konieczność napisania kontrolera :)
A nie można po prostu odpowiednio zaprojektować cyklu pracy takiego układu? Na przykład, gdy układ wyświetlający pobiera kolejny pixel, część renderująca jest wstrzymywana (np. przez zabramkowanie jednego cyklu zegara).  Jeżeli układ byłby taktowany 50MHz, to strata mocy obliczeniowej części renderującej nie była by aż taka wielka. Dostęp z częstotliwością 8MHz powinien wystarczyć do wyświetlenia obrazu, a biorąc pod uwagę, że można pobierać kilka pikseli na raz (np. 8 bitów na piksel przy 32-bitowej szynie danych), oraz to, że nie zawsze nowe piksele są potrzebne (wygaszanie poziome i pionowe), stratę mocy obliczeniowej można sprowadzić do pojedynczych procentów. :)

Alternatywnym rozwiązaniem może być także zastosowanie dwóch osobnych pamięci i przełączanie się pomiędzy nimi. W końcu backbuffer też jest rzeczą pożyteczną. :)

No nie wiem czy było by takim dobrym rozwiązaniem, bo przecież i tak musiałbyś albo kopiować między pamięciami albo rysować w każdej osobno jeszcze raz. 2-portowe pamięci można kupić oczywiście, ale ja mówiłem o tej, co mam na Spartan 3 Development Board.

Cytuj
Cytuj
Podlaczanie AVR (o 51 nie wspomne) to kompletne nieporozumienie
Oczywiście, że im więcej mocy, tym lepiej (i drożej :P), ale chodzi tu o samo sterowanie, więc nawet dobrze zaprogramowany 8051 powinien być w stanie generować scanline'y we w miarę znośnym tempie. :)

O 8051 można zapomnieć, bo czas świetności tych układów już minął. AVR9 są super, ale po co kupować osobne układy, skoro można kupić lepszy układ FPGA albo nawet ze 4 FPGA wsadzić do karty, podłączyć JTAGiem i programować :)

Cytuj
Taka dynamiczna ze starego PC może być, czy musi być jakaś specjal ?
PC'towe pamięci są, chyba jednoportowe. :)

Przy okazji: bawił się ktoś może w podłączanie PC'towych pamięci do swoich układów? :)
Cytuj

Z PC-towymi pamięciami jest problem, bo to są DRAMy. Trzeba by wsadzić kontroler DRAM do układu FPGA, a to żre trochę zasobów układu (są chyba nawet gotowe bloki do tego od Xilinixa na płytkach z zestawem).
W DRAMach trzeba tracić cykle na odświerzanie pamięci, więc wymagało by to innego designu układu - można by robić od razu transfery blokowe do/z cache - przynajmniej jedną linię by wystarczyło na raz. W czasie gdy jeden układ generuje kopiuje dane na port VGA, to drugi może z powodzeniem rysować w tym samym czasie, oczywiście jeśli pamięć jest wolna, albo dana linia już jest w cache.
Sygnał zegarowy dla części rysującej można by bramkować właśnie jakąś flagą zajętości, np. gdy układ rysujący robi transfer blokowy, to układ rysujący ma wstrzymany zegar.


Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Kwiecień 16, 2006, 14:44:40
Cytuj
No to clip może się obdywać przed rysowaniem ;p
Musisz podjąć decyzję, co w zasadzie chcesz mieć na FPGA, a co na zewnątrz. Jeżeli nie chcesz pakować transformacji geometrii do FPGA, to clipping można równie dobrze zostawić poza.

Cytuj
No nie wiem czy było by takim dobrym rozwiązaniem, bo przecież i tak musiałbyś albo kopiować między pamięciami albo rysować w każdej osobno jeszcze raz.
Żadne kopiowanie nie jest potrzebne. Wystarczy dodać prosty układ przełączający pamięci ze sobą i zamieniający je logicznie funkcjami. :)

Cytuj
po co kupować osobne układy, skoro można kupić lepszy układ FPGA albo nawet ze 4 FPGA wsadzić do karty, podłączyć JTAGiem i programować
Myslę, że to by wyszło trochę sporo cenowo. :)

agent_J

  • Gość
# Kwiecień 16, 2006, 15:02:22
Cytuj
No to clip może się obdywać przed rysowaniem ;p
Musisz podjąć decyzję, co w zasadzie chcesz mieć na FPGA, a co na zewnątrz. Jeżeli nie chcesz pakować transformacji geometrii do FPGA, to clipping można równie dobrze zostawić poza.

No to teraz wychodzi tak:
- jedna część odpowiada za framebuffer
- druga to akcelerator odpowiedzialny za blitowanie, i inne operacje rastrowe
- trzecia to jakiś silny RISC z jednostkami do operacji na macierzach, który robi wstępne obliczenia, transformacje, itp. (macierze praktycznie tylko do 3D)
- czwarta to interface pomiędzy PCI/AGP a RISCiem

Cytuj
Cytuj
No nie wiem czy było by takim dobrym rozwiązaniem, bo przecież i tak musiałbyś albo kopiować między pamięciami albo rysować w każdej osobno jeszcze raz.
Żadne kopiowanie nie jest potrzebne. Wystarczy dodać prosty układ przełączający pamięci ze sobą i zamieniający je logicznie funkcjami. :)

Niby jak. Układ rysujący używa pamięci A, ty rysujesz w pamięci B, i przełączasz się na pamięć A po skończeniu rysowania klatki, ale w pamięci A są stare dane, i jak ty widzisz update'owanie stanu.

Cytuj
Cytuj
po co kupować osobne układy, skoro można kupić lepszy układ FPGA albo nawet ze 4 FPGA wsadzić do karty, podłączyć JTAGiem i programować
Myslę, że to by wyszło trochę sporo cenowo. :)

Niekoniecznie. Układy FPGA są relatywnie tanie. Oczywiście, że w warunkach domowych ciężko będzie wykonać kartę 3D, ale 2D można zrobić spokojnie - wystarczy kupić jakiegoś średniego FPGA (do 200zł) i dołączyć np. tego ARM9. Wiadomo, że prototypy są droższe :) W fabryce pewnie już by się dało te 4 układy wpakować do jednego.

Część obliczeń do 2D można wspomagać sprzętowo, np. ten nieszczęsny clipping 2D :)

agent_J

  • Gość
# Kwiecień 16, 2006, 15:21:58
"Konkretny" plan wymyśliłem :)



agent_J

  • Gość
# Kwiecień 16, 2006, 15:56:24
BTW: z tymi 50MHz to trochę przesadziłem, bo układ może pracować nawet na 200MHz - mocniejsze wersje.

Małe porównanie cen układów:

Xilinx:
Za najtańszego Virtex 4 (24192 bloki) trzeba by było dać ~350$, więc bez
dodatkowej kasy nie przejdzie. Wersje po ponad 100000 bloków, to już
wydatek rzędu 1800$.

Mocne Virtexy II PRO kosztują 1500$, średnie są po 1000$.

Spartan 3E z 33192 blokami jest jako próbka inżynierska - kosztuje 64$.

Spartan 3 z 29952 bloki kosztuje 85$.

Układy Altery są wiele droższe, wystarczy popatrzeć na ceny :)
http://www.buyaltera.com/scripts/partsearch.dll/showfilter?lookup=1,30,3062

Przykładowo biorąc tego Spartana 3 z XC3S1500 blokami dostajemy:
- 1500000 bramek
- 32 układy monżące
- 576KBit block RAM
- 208KBit distributed RAM

czyli nie tak mało :) S3, którego ja mam ma tylko 4320 bloków, czyli mało :)




Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Kwiecień 16, 2006, 16:08:47
Cytuj
Niby jak. Układ rysujący używa pamięci A, ty rysujesz w pamięci B, i przełączasz się na pamięć A po skończeniu rysowania klatki, ale w pamięci A są stare dane, i jak ty widzisz update'owanie stanu.
Przed renderowaniem nowej sceny musisz wyczyścić starą. :)

Cytuj
Przykładowo biorąc tego Spartana 3 z XC3S1500 blokami dostajemy:
- 1500000 bramek
- 32 układy monżące
- 576KBit block RAM
- 208KBit distributed RAM
Ano bajer. :) Problem tylko w tym, że, z tego, co pamiętam, układy od XC3S1500 w górę są dostępne jedynie w obudowach prawie uniemozliwiających ich uzycie w warunkach amatorskich. :)

agent_J

  • Gość
# Kwiecień 16, 2006, 16:13:43
Cytuj
Niby jak. Układ rysujący używa pamięci A, ty rysujesz w pamięci B, i przełączasz się na pamięć A po skończeniu rysowania klatki, ale w pamięci A są stare dane, i jak ty widzisz update'owanie stanu.
Przed renderowaniem nowej sceny musisz wyczyścić starą. :)

Właśnie nie, bo jeśli nie modyfikujesz obrazu to niby jak chcesz robić ? Dodać trzecią pamięć ? Pamięć 2 portowa to IMO najlepsze rozwiązanie.

Cytuj
Ano bajer. :) Problem tylko w tym, że, z tego, co pamiętam, układy od XC3S1500 w górę są dostępne jedynie w obudowach prawie uniemozliwiających ich uzycie w warunkach amatorskich. :)

Jak się uprzesz to i BGA zlutujesz gorącym powietrzem :) Tylko, że to już są za drogie zabawki na takie eksperymenty. Trzeba by dać schemat i projekt do jakiegoś zakładu, żeby oni zrobili płytkę i ją maszyna zlutowała. Wtedy można już wsadzić ze 2 takie układy i połączyć je ze sobą.

BTW: stosując pamięć ram 2-portową, można dać tylko 1 FPGA mocniejszy, a generację obrazu zrobić na jakimś tanim CPLD albo nawet na najtańszych wersjach Spartana :)
« Ostatnia zmiana: Kwiecień 16, 2006, 16:17:30 wysłana przez agent_J »