rafal2808

Oczywiście tego typu projekty są bardzo ciekawe, jednak tym razem chciałbym zaprojektować coś swojego. Nawet jeśli będzie to obarczone wieloma błędami, a bądźmy szczerzy będzie, to mimo wszystko dla mnie osobiście proces rozwiązywania tych problemów jest jak najbardziej przyjemny. Miałem tutaj na myśli iż układ posiadał będzie dedykowane bloki oraz rejestry odpowiedzialne za obsługę tych interfejsów. Przy okazji uświadomiłem sobie że trafniejszym określeniem mojego projektu będzie mikrokontroler, nie procesor. Tak prezentuje się poprawiona architektura projektowanego przeze mnie układu. Nie różni się ona znacząco od schematów udostępnianych wcześniej. Różnice są raczej kosmetyczne, według mnie najważniejszą z nich jest dodanie "obejścia ALU" umożliwiającego łatwiejsze przesyłanie danych. Dodatkowo muszę wspomnieć, że układ z założenia projektowany jest według architektury Harwardzkiej. Dlaczego nie von Neumanna, po prostu nie podoba mi się koncepcja przechowywania programu i danych w tej samej pamięci. Układ nie będzie posiadał jako takiej przestrzeni adresowej. Jedyne adresy występujące w układzie to te dla pamięci ROM generowane przez licznik adresów oraz dla RAM, które stają się adresami dopiero po wpisaniu do rejestru ARR, wcześniej jest to po po prostu zwykła zmienna.

Po otrzymaniu rad od @FlyingDutch oraz @marek1707 postanowiłem zmienić nieco założenia całego projektu. Project A będzie 8-bitowym procesorem zrealizowanym na układzie FPGA, początkowo planowałem umieścić go na płytce Elbert v2 jednak w międzyczasie udało mi się zdobyć płytkę Core3S500E na której umieszczono chip FPGA dysponujący zasobami większymi niż ten umieszczony na Elbert v2. Tak więc Project A będzie bazować Core3S500E. Modułowa budowa procesora w stylu podobnym jak np.Nios II na razie odpada, a bardziej przerasta moje możliwości. Architektura również uległa pewnym zmianą, postaram się udostępnić ją w najbliższym czasie. Planuję wprowadzić cztery tryby adresowania: natychmiastowy, rejestrowy, bezpośredni oraz pośredni. Ułatwią one znacznie programowanie procesora. Układ wspierać będzie interfejsy UART i I2C, oraz obsługa wyświetlaczy LCD i 7 segm. Na początek planuję zaprojektować bardzo prosty układ przerwań wspierający tylko jedno maskowalne przerwanie zewnętrzne. Po jego otrzymaniu procesor zapisywał będzie tylko adres powrotu. Stan innych rejestrów będzie w pełni zależny od programisty. Ich zawartość można będzie odłożyć na stosie, którego obsługa również zostanie dodana. Procesor posiadać będzie dodatkowe 8 rejestrów ogólnego przeznaczenia, nie będą one jednak osobną strukturą a wydzielonym obszarem pamięci RAM. Programowanie odbywać się będzie podobnie jak w moich wcześniejszych projektach poprzez określenie zawartości pamięci w pliku VHDL. Wiem że są to dość szczątkowe informacje na temat mojego procesora, ale chciałem dać znać że Project A nie został zapomniany.

Na ten moment komunikacja z rejestrami realizowana jest właśnie za pomocą osobnych instrukcji. Myślę że w przyszłych projektach wszystko realizowane będzie właśnie na zasadzie większych bloków a komunikacja zostanie ujednolicona. W mojej wizji rejestr A pełni funkcję czegoś na wzór rejestru wejściowego. Dane na początek zapisywane są tam dopiero później rozsyłane są dalej. W taki sam sposób przesyłany jest rozkaz dla ALU zapisywany docelowo w rejestrze C. Jako iż wszystko działa w sposób wspomniany wyżej nie mamy możliwości zmiany zawartości rejestru poprzez jeden rozkaz. Należy wprowadzić odpowiedni rozkaz dla ALU a następnie wynik zapisać w docelowym rejestrze. Procesor jest 8 bitowy. Pamięć ROM posiada strukturę 2048x16 natomiast RAM 256x8. Raczej kluczowa jest zajętość FPGA. Układ na płytce Elbert v2 nie dysponuje dużą ilością zasobów, a przy syntezie prostszego projektu tak wygląda ich zużycie. Co do układu przerwań to będę eksperymentował. Na początek myślę że zaprojektuje coś prostego na zasadzie wystąpi przerwanie->skok do podprogramu->powrót. Na razie świadomie rezygnuje z zabezpieczenia się przed sytuacjami typu w trakcie obsługi przerwania wystąpi kolejne. Adresowanie bezpośrednie, listę instrukcji umieszczę wkrótce. Na razie funkcji zatrzymania CPU nie planuję. BTW: Uwaga co do przerwań jak najbardziej słuszna.

Porządki w projekcie, ciąg dalszy Można powiedzieć że, zaczynam od początku. Projekt zyskał całkowicie nową architekturę, jest to ulepszona wersja pierwotnego pomysłu. Najważniejszym elementem jest dodanie obsługi przerwań zewnętrznych jak i wewnętrznych. Do tej pory żaden realizowany przeze mnie projekt procesora nie posiadał tej funkcji. Sama forma pracy nad projektem również ulegnie pewnej zmianie. Z czasem pojawiać się będą wpisy (facebook+blog+forbot) informujące o zakończeniu etapu projektowania poszczególnych elementów. Dotychczas informowałem raczej o ukończeniu, czy zaktualizowaniu całego projektu, nie jego konkretnych elementów. Dodatkowo nazwa procesora również ulega zmianie od teraz będzie to "Project A". Tak prezentuje się architektura procesora. Każdy z bloków możemy przypisać do jednej z czterech kategorii. Kolorem żółtym zaznaczone zostały wszystkie rejestry, czerwonym bloki pamięci (RAM, ROM), niebieskim multipleksery. Na zielono zaznaczone zostały bloki, które możemy określić jako te najbardziej zaawansowane takie jak ALU, dekoder instrukcji czy kontroler wyświetlaczy 7 segmentowych. Blok kryjący się pod tajemniczą nazwą "LOGIC" jest najprościej mówiąc głównym elementem układu sterowania. To tutaj na podstawie instrukcji, zegara oraz kilku pomniejszych sygnałów określających stan procesora generowane są wszystkie sygnały sterujące dla innych bloków. Najważniejszą z nowości jest dodanie układu przerwań. Na początek obsługiwane będą trzy typy przerwań. Dwa z nich będą aktywowane w momencie wysłania lub odbioru znaku poprzez interfejs UART, trzecim natomiast będzie sygnał zewnętrzny (np. przycisk). Oczywiście dzięki rejestrowi ICR (interrupt control register) możliwe będzie wyłączenie dowolnego z przerwań. Fizycznie projekt zrealizowany zostanie na dobrze już znanej płytce Elbert v2. Oczywiście założenie iż wszystko zrealizowane ma być tylko na tej płytce pozostaje nadal aktualne. Ciąg dalszy nastąpi... Jeśli ktoś zainteresowany jest tym czy innym z moich projektów zapraszam na prowadzoną przeze mnie stronę na facebooku, gdyż to właśnie tam w pierwszej kolejności pojawiają się najnowsze informację.

Po dość sporej przerwie wracam do projektu, miała ona również swoje plusy, ponieważ udało mi się spojrzeć na całość z nieco innej perspektywy. Wracając do poprzednich wpisów, plany implementacji obsługi kolejnych interfejsów oraz obsługi wyświetlaczy 7 segmentowych zostają. Jednak rezygnuję z wyświetlacza LCD oraz zewnętrznej pamięci RAM. Powodem tego jest początkowe założenie projektu, w czasie jego trwania nieco zapomniane. Cały system ma być ograniczony tylko do płytki Elbert v2. Ewentualne zewnętrzne dodatki nie powinny być wymagane do poprawnego uruchomienia projektu. Jak sama nazwa wskazuje mają to być tylko dodatki. Pojawiła się kolejna wersja projektu DCEQ818 z nieco zoptymalizowanym kodem procesora, dodatkowo sam opis również został zaktualizowany.

@Treker W przyszłości na pewno pojawi się obsługa kolejnych interfejsów takich jak SPI, I2C itd. Dodatkowo planuję też wprowadzenie obsługi wyświetlacza LCD oraz 7-segmentowego. Poważnie też myślę nad dodaniem zewnętrznej pamięci RAM. Można by wówczas zrezygnować z implementowania jej na strukturze FPGA i zwiększyć pojemność pamięci ROM, ale to temat na dalszą przyszłość. Oczywiście cały czas staram się pracować nad projektem i metodą małych kroków zwiększać jego funkcjonalność.

Zapraszam do zapoznania się z zaktualizowaną wersją opisu procesora Q818. Pojawiła się już dość spora sekcja poświęcona architekturze układu oraz blokom tworzącym procesor.

Kolejna wersja procesora jest już gotowa. Tym razem dodana została obsługa rozkazu powrotu. Dzięki temu nie musimy znać dokładnego miejsca, w którym przerwany został program główny. Od teraz procesor przechowuje adres w odpowiednim rejestrze. Więcej na temat mojego projektu można przeczytać tutaj.

Dostępna jest już kolejna wersja układu wyposażona w pełni funkcjonalny interfejs UART. Poza tym dodane zostały nowe rozkazy dla ALU oraz sam kod procesora został zaktualizowany. Na moim blogu można dowiedzieć się więcej na temat budowy układu oraz pobrać projekt.

Jakiś czas temu na forum zaprezentowałem projekt procesora zrealizowanego na układzie FPGA. Był to układ zrealizowany na dwóch płytkach Elbert v2. Aby go uruchomić należało wykonać dość sporo pracy. Dzisiaj prezentuję pierwszą wersję układu DCE Q816, czyli bezpośredniej kontynuacji poprzedniego projektu. Można powiedzieć, że pierwsza wersja Q818 to tak naprawdę Q816 zrealizowany tylko na jednej płytce Elbert v2. Układ jest w pełni kompatybilny z poprzednim projektem oraz posiada identyczną listę rozkazów. Na ten moment nie będę skupiał się na budowie procesora, ponieważ jest ona praktycznie identyczna jak w układzie Q816. Jedyną różnicą jest to, że pamięć ROM oraz procesor zaimplementowane została na tym samym układzie FPGA. W związku z tym każdy, kto posiada płytkę Elbert v2 może pobrać projekt, który dostępny jest tutaj, a następnie uruchomić procesor Q818 w swoim domu. Po implementacji projektu na płytce FPGA powinniśmy zobaczyć następujący efekt świetlny. Należy również wspomnieć, że porty procesora skonfigurowane zostały w następujący sposób. przełączniki DIP Switch - wejście IN procesora (logika odwrotna) przycisk SW1 - RESET port P1 - wyjście OUT1 procesora diody LED - wyjście OUT2 procesora Programowanie procesora odbywa się poprzez zmianę zawartości pamięci ROM procesora. Aby tego dokonać musimy otworzyć plik ROM.vhd i następnie wpisać binarną zawartość kolejnych komórek pamięci. Najmłodsze 5-bitów to rozkaz dla procesora. Kolejne 8 to tzw. dana bezpośrednia, którą możemy przesłać do innych rejestrów. Poniżej umieszczam spis dostępnych rozkazów procesora oraz instrukcje dla ALU zapisywane w rejestrze C. Na ten moment jest to pierwsza wersja układu Q816 w przyszłości postaram się o uporządkowanie samego kodu, jak i dodanie kolejnych funkcji. O zmianach i kolejnych wersjach postaram się informować w komentarzach do tego posta.

@aerograf7 Po krótkim researchu wydaje mi się że w edytorze online nie ma możliwości dodania płytek.

Dzięki @FlyingDutch, sam też ostatnio szukałem trochę informacji na temat przejścia z Spartana3 na Spartana6. Podrzucam tutaj kilka linków związanych z tym tematem dla osób które, tak jak ja napotkały pewne problemy z przejściem na układ Spartan6. https://www.xilinx.com/support/answers/33210.html https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_5/spartan6_hdl.pdf https://forums.xilinx.com/t5/Welcome-Join/Asynchronous-Set-or-Reset-for-Registers-of-Spartan-6-FPGA/td-p/478370 https://forums.xilinx.com/t5/Spartan-Family-FPGAs-Archived/migration-spartan-6-from-spartan-3/td-p/543651

Podobnie jak @ethanak korzystam z pakietów płytek MCUdude. Ogólnie to na ten temat pisałem już nieco na moim blogu. https://rafal-bartoszak.blogspot.com/2019/05/programowanie-mikrokontrolerow-atmega.html

Cześć, Jak może pamiętacie jakiś czas temu udostępniłem na forum projekt mojego własnego procesora na FPGA (Spartan 3E). Dzisiaj starałem się tak przerobić projekt, aby jego implementacja możliwa była na układzie Spartan 6. Jednak podczas syntezy otrzymuję takie oto ostrzeżenie. Poczytałem sobie nieco o tym i mniej więcej orientuję się już o co dokładnie chodzi. Chciałbym jednak zapytać bardziej doświadczonych kolegów czy może znacie lub posiadacie materiały odnośnie różnic w architekturze Spartan 3E a Spartan 6. Oraz czy są jeszcze jakieś można powiedzieć elementy które na Spartanie 3E syntezują się bez problemu a na Spartanie 6 odmawiają współpracy.

Jeżeli chodzi o sygnalizowanie przepełnienia to istnieje już odpowiedni bit, u mnie nazwany Cout. Dodatkowo istnieją dwa rozkazy skoków warunkowych biorących go pod uwagę (skocz jeżeli 0 oraz skocz jeżeli 1). Natomiast flagi ZERO układ na razie nie posiada. Chociaż w przyszłości na pewno się pojawi. Jak na razie skupiłem się na programach, w których to zmienne nie przekraczają 8 bitów. Wiemy jednak, że taka sytuacja w rzeczywistości nie jest zbyt częsta, ale mając już podstawy prostsze będzie przystosowanie układu do wykonywania operacji na zmiennych większych niż podstawowe 8 bitów.