DCE 812 (8-bitowy mikroprocesor własnej roboty)

[rafal2808]

Niewątpliwie procesory, bądź mikroprocesory stanowią ogromną część elektroniki użytkowej. Prawie w każdym urządzeniu, poczynając od najprostszych, a kończąc na najbardziej zaawansowanych komputerach, najważniejsza jest jednostka centralna. Czasy największej świetności ośmiobitowe procesory mają już za sobą, ale nadal stanowią ważną część elektroniki. Wiele urządzeń nadal z nich korzysta.

Moją przygodę z elektroniką cyfrową rozpocząłem od programowania mikroprocesorów firmy Atmel były to dokładniej procesory Atmega8 oraz Atmega328. Mimo wielkich możliwości jakie dają mikrokontrolery bardziej interesowała mnie strona hardware’owa tych układów. Na ich podstawie oraz procesorów takich jak Intel 4004, 8080 stopniowo poznawałem budowę oraz działanie mikroprocesorów. W pewnym momencie stwierdziłem że nie jest to takie trudne i sam zbuduję własny procesor. Był to DCE 4 (D-digital, C-computer, E-electronic, 4 ponieważ była to jednostka czterobitowa). Następnie rozpocząłem prace nad ośmiobitowym procesorem DCE 84. Jednak i on z upływem czasu wydał mi się bardzo prosty. Prezentowany mikroprocesor DCE 812 zaprojektowałem korzystając z rozwiązań zastosowanych w DCE 84 bazując na pełnej architekturze harwardzkiej (gdzie pamięć dla programu i danych jest fizycznie rozdzielona). Schemat blokowy układu można znaleźć poniżej.

Do budowy zostały użyte podstawowe układy logiczne wykonane w technologii CMOS (przykładowo bramki AND) oraz gotowe układy pamięci RAM (UL6516 2k x 8bit) oraz ROM(dwa układy 28c64 8k x 8bit) , ponieważ budowa własnych pamięci nie była możliwa z powodu braku czasu i środków. Elementy takie jak ALU, układ sterowania, zegar, oraz obsługa pamięci i poszczególnych rejestrów roboczych została zaprojektowana przeze mnie od podstaw. Fizycznie układ powstał stosunkowo niedawno i nie obyło się bez komplikacji. Zmiana układu obsługującego pamięć RAM sprawiła, że układ działa zgodnie z założeniami. Pozwala on na wykonywanie podstawowych działań matematycznych oraz prostych programów stworzonych w języku C++ i przekonwertowanych na polecenia dla tego procesora. Najbardziej zaawansowanym programem, który udało mi się uruchomić było generowanie kolejnych liczb z ciągu Fibonacciego.

Praca mikroprocesora zostaje rozpoczęta od wciśnięcia fizycznego przycisku RESET, który ustawia stan "0" na wyjściach wszystkich wewnętrznych rejestrów. Uzyskujemy poprzez to adres zero na wyjściu licznika rozkazów co powoduje rozpoczęcie pracy od pierwszego wprowadzonego rozkazu (lista rozkazów widoczna na zdjęciu poniżej). Następnie układ zaczyna liczyć od 0 do 15 wewnątrz układu sterowania do każdej z tych mikrooperacji przypisane jest odpowiednie działanie zgodne z rozkazem wprowadzonym do pamięci ROM może to być np. zapis do rejestru B, reset licznika rozkazów. Po wykonaniu wszystkich mikrooperacji licznik rozkazów zwiększa swoją wartość o jeden co skutkuje przejściem do kolejnego rozkazu i cały cykl wykonywany jest ponownie.

Programowanie procesora realizowane jest poprzez odpowiednie przełączniki które umożliwiają przełączanie układu między stanem pracy a programowaniem. Wprowadzanie danych oraz wybieranie adresów również realizowane jest w ten sposób. Odpowiednie przełączniki służą również do sterowania zegarem procesora. Generowanie impulsów może odbywać się automatycznie z częstotliwością ok. 10Hz lub manualnie poprzez wciśnięcie przycisku.

Obecnie projektuje kolejną wersje własnego procesora tym razem staram się wszystko umieścić w jednym układzie FPGA (Korzystam z tej płytki). Postępy w pracach można obserwować na moim blogu https://rafal-bartoszak.blogspot.com/

Dodatkowo wstawiam też link do filmu gdzie można zobaczyć działanie układu.

Edytowano Styczeń 13, 2019 przez rafal2808
Poprawiłem formatowanie.

[Treker (Damian Szymański)]

@rafal2808, właśnie zaakceptowałem opis. Dziękuję za przedstawienie ciekawego projektu, zachęcam do prezentowania kolejnych DIY oraz aktywności na naszym forum 😉

[FlyingDutch]

Cześć,

świetny projekt - podziwiam, że chciało Ci się realizować to na układach małej/średniej skali integracji. Życzę dużo powodzenia w realizacji twoich projektów na układach FPGA.

Pozdrawiam

[rafal2808]

@FlyingDutch Dziękuję  i również pozdrawiam 😀

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[marek1707]

Takie układy muszą być z konieczności proste, bo dodanie każdej kolejnej funkcjonalności to przyrost scalaków, miejsca na płytce i liczby połączeń, ale nie wiem czy tu nie posunąłeś się za daleko w tej prostocie. Oczywiście jest to duża praca i chwała za zaprojektowanie układu umiejącego pobierać i wykonywać instrukcje. Mam jednak wątpliwość dotyczącą założeń, może mógłbyś to wyjaśnić. Skoro jest to już Twój trzeci projekt to na pewno już widzisz istotne wady braku możliwości podejmowania przez program jakiejkolwiek decyzji. Twój procesor nie ma ani jednego skoku warunkowego lub choćby warunkowego rozkazu "Pomiń (wykonaj jako NOP) następną instrukcję" co powoduje, że cały przebieg pracy musi być liniowy aż do napotkania kodu 1000 lub końca pamięci i restartu od początku. Jak w takiej sytuacji możesz obsłużyć jakiekolwiek I/O gdzie musisz poczekać na dane, jak chcesz wykonać najprostszą pętlę czy rozgałęzienie. A przecież są to podstawowe bloki algorytmów. Czy program liczenia Fibonacciego polagał na powtarzaniu w kodzie wciąż tej samej sekwencji i jeśli wpisałeś ją 7 razy to liczył 7 pierwszych wyrazów? Trochę słabe.

Czy nie myślałeś by nawet kosztem niektórych instrukcji zrobić jednak logikę skoków a już na pewno testowania jakiegoś warunku? Niechby to było A=0, cokolwiek. Jak rozumiem ROM w organizacji 16-bitowej służy wprost do generowania sygnałów sterujących poszczególne bloki, ale 2K RAMu w momencie gdy wpisujesz to ręcznie z przełączników (a może inaczej?) i w zasadzie nie możesz zrobić żadnego sensownego programu, wydaje się sporym nadmiarem. Choć pewnie trudno dziś kupić mniejszą kostkę. To nie  są zarzuty, chciałbym tylko zrozumieć założenia jakimi się kierowałeś i czy masz zakusy na kolejną, jeszcze lepszą konstrukcję? Bo taki procesor może dać niesamowitą frajdę z puszczenia na nim np. pierwszej gry (a niechby i losowania kostki 6-ściennej) lub rozbudowania systemu  przez podłączanie jakichś peryferiów - ale musi to umożliwiać..

Przejście na FPGA to już zupełnie inna dziedzina. Tam zrobienie własnego procesora CISC z pełną listą instrukcji, systemem przerwań, kolejką dekodowania i wykonywania, predykcją skoków a nawet spekulatrywnym wykonywaniem kodu zależy tylko od ilości czasu spędzonego przed ekranem i nie wygląda tak fajnie 🙂 A moim osobistym zdaniem nie daje takiej radochy jak 100 TTLi robiących procesor grający z Tobą w kólko i krzyżyk.

BTW: Czy słyszałeś kiedyś o kostce MC14500B? To proste CPU (1-bitowy arytmometr, 4-bitowy kod instrukcji) przeznaczone w zamyśle do programowej realizacji sterowników przemysłowych budowanych w innym przypadku ze "sprzętowej"  logiki cyfrowej, które trzeba obudować wieloma scalakami by dało się użyć - ale nawet to ma instrukcję warunkową i skok (który trzeba sprzętowo zrobić samemu, ale taka instrukcja jest dekodowana i sygnalizowana przez 14500):

https://en.wikipedia.org/wiki/Motorola_MC14500B

http://old-computers.com/museum/computer.asp?st=1&c=834

http://www.brouhaha.com/~eric/retrocomputing/motorola/mc14500b/mc14500b_icu_handbook.pdf

W swoim czasie było do tego produkowanych kilka egzotycznych scalaków typu licznik instrukcji czy nawet (o ile pamiętam) sprzętowy stos(!) wywołań i powrotów z podprogramów co znakomicie ułatwiało budowę sterowników, ale nawet z prostych TTLi można dziś na tym zbudować już sensownie działający komputerek. Pomyśl o tym 🙂 

Edytowano Styczeń 13, 2019 przez marek1707
literówki..

[rafal2808]

@marek1707 Z perspektywy czasu muszę powiedzieć, że owszem brak jakichkolwiek rozkazów skoków to nie był najlepszy pomysł. Jednak na tamten moment wydawało mi się, że będzie to dobre rozwiązanie. Nie chciałem rozbudowywać licznika programu oraz układu sterującego do monstrualnych rozmiarów. I tak program odpowiedzialny za generowanie liczb z ciągu Fibonacciego składał się z kilkudziesięciu instrukcji. Gdyby układ obsługiwał jakiekolwiek skoki to można by to zrealizować na kilku instrukcjach. Był to pierwszy, że tak powiem pierwszy większy projekt, jaki realizowałem (poprzednie dwa to bardzo proste procesory, chociaż słowo procesor jest nadużyciem) ale mimo wszystko nie zakładałem możliwości podłączenia zewnętrznych urządzeń układ miał tylko i wyłącznie obsługiwać kilka prostych instrukcji oraz diody LED. Jeżeli chodzi o pamięć ROM to pierwsze 8 bitów był to adres dla pamięci RAM natomiast następne 4 bity były rozkazem. Trafiał on do części logicznej, która to generowała sygnały sterujące. Czy 8K RAM było nadużyciem możliwe jednak akurat taki układ miałem pod ręką, ale mimo wszystko procesor mógł zapisywać tam dane więc RAM nie był obsługiwany tylko za pomocą przycisków.

Obecnie przeniosłem się na FPGA bo projektowanie w taki sposób jest prostsze i nie mamy ograniczeń, jakie stwarzają nam układy małej skali integracji, ale projektowanie układów cyfrowych w tej czy innej formie zawsze sprawiało mi wiele radości.

Przyznam się szczerze, że nie wiem jakim cudem, ale nie słyszałem o tym układzie, chociaż w cyfrówce siedzę już od dłuższego czasu. Będę musiał poczytać sobie na ten temat więcej.

 

[marek1707]

Dzięki. Jescze jedno pytanie: zaintrygowałeś mnie tą konwersją z C++ na instrukcje tego procesora. Czy mógłbyś to rozwinąć, a konkretnie: czy zajmowałeś się przy okazji tego tematu kompilatorami i automatyczną generacją kodu wynikowego, czy dopasowałeś do binariów tej kontrukcji któryś z dostępnych np. meta-asemblerów albo czy masz na myśli tłumaczenie przy użyciu.. kartki i ołówka?

No i napisz przy jakiejś okazji co tam w FPGA wydłubałeś albo chcociaż czy przewidziałeś skoki warunkowe 😉 I jak - jeśli robisz zupełnie własny procesor - zamierzasz go programować inaczej niż wpisując HEXy do RAMu.

[rafal2808]

No akurat w przypadku tego układu tłumaczenie programu było dość czasochłonne, bo każdy rozkaz starałem się przekonwertować na polecenia dla procesora ręcznie za pomocą właśnie kartki i ołówka.

Jeżeli chodzi o mój obecny projekt na FPGA to wszystkie postępy w pracach opisuje na moim blogu. Tym razem już z góry założyłem sobie, że układ ma obsługiwać skoki bezwarunkowe oraz warunkowe. Jutro bądź najpóźniej pojutrze skończę projektować licznik programu oraz sam blok pamięci ROM i przy okazji tego pojawi się pełna lista rozkazów obsługiwanych przez mój nowy projekt. Kwestia programowania nie została jeszcze do końca rozwiązana, ale na pewno nie będzie to ręczne programowanie za pomocą przycisków. Obecnie wymyśliłem sobie, że pamięć będzie można programować za pomocą mikrokontrolera a dokładniej postaram się stworzyć listę poleceń w języku C odpowiadających rozkazom procesora. Każde takie polecenie będzie wywoływać podprogram, który to będzie już zapisywał do pamięci odpowiednie wartości binarne. Można powiedzieć, że stworzę coś podobnego do asemblera. 

[marek1707]

1 godzinę temu, rafal2808 napisał:

postaram się stworzyć listę poleceń w języku C odpowiadających rozkazom procesora. Każde takie polecenie będzie wywoływać podprogram, który to będzie już zapisywał do pamięci odpowiednie wartości binarne. Można powiedzieć, że stworzę coś podobnego do asemblera

Hm, to pewnie nie jest miejsce na taką dyskusję - w końcu to wątek o Twoim komputerze DCE, ale chyba powinieneś poczytać coś o językach programowania bo mam wrażenie, że mylisz dwie zupełnie odrębne rzeczy. Asemblery to języki programowania w których jedna linia programu źródłowego przekłada się na jedną instrukcję procesora (dla purystów: dla prostoty nie myślę tu o makroasemblerach). Po prostu zamiast wpisywać binarne kody operacyjne korzystamy z tablicy mnemoników i pewnych dodatkowych zasad (np. dot. dozwolonych argumentów danej instrukcji) wbudowanych w program tłumaczący. Natomiast języki wysokiego poziomu, takie jak C, tak nie działają. Nie ma tam bezpośredniego odniesienia programu źródłowego do instrukcji procesora i nie możesz - nie budując kompilatora - zrobić tłumaczenia metodą "wywoływania pod programów". Przykładowo jedna instrukcja w C, np. switch może zamienić się na wieledziesiąt rozkazów procesora rozstrzelonych między inne rozkazy, wykonujące inne linie programu.To samo z pętlami: w jednym miejscu trzeba je zacząć, w innym skończyć a po drodze będzie wiele instrukcji wykonujących to w co w pętli zawarłeś. Do tego dochodzi gospodarka rejestrami i pamięcią, zmienne na stosie, analiza wyrażeń arytmetycznych, system typów i ich konwersji, jakaś spójna konwencja przekazywania argumentów do funkcji i odbierania z nich wyników itd.. Kompilator musi rozumieć strukturę całego programu i nie może patrzeć tylko na tę jedną linię kodu źródłowego jak asembler - to są zupełnie różne światy. W sposób w jaki opisałeś możesz natomiast zrobić interpreter, choć akurat C słabo się do tego nadaje. Wcześniej zaś - żeby w ogóle zacząć pisać programy dla nowego procesora - możesz skorzystać z gotowych asemblerów skrośnych sterowanych tablicami, które to tablice po stworzeniu (to są pliki tekstowe) opisują mnemoniki instrukcji Twojego procesora, ich argumenty itd. Piszesz wtedy kod jakbyś pisał dla Z80 czy 6502 tylko z wymyślonymi przez siebie instrukcjami, używasz etykiet, wyrażeń arytmetycznych w polach argumentów i tego wszystkiego do czego przywykliśmy w językach asemblera i dostajesz poprawny kod binarny wprost dla Twojego procesora.

[rafal2808]

No cóż możliwe, że właśnie nieświadomie mylę te dwa pojęcia. Jeszcze sporo nauki przedemną, ale dziękuje za nakreślenie drogi.😀