Hallo zusammen! Ich bin durch dieses Forum auf die selbstgebaute CPU von Dennis Kuschel gestoßen und würde nun auch gerne so eine CPU bauen. Mit einem FPGA habe ich schon ein CPU Projekt nachgebaut (mit leichten Veränderungen) und die Idee mit TTL Bausteinen gefällt mir ziemlich gut! Jedoch würde ich die CPU als RISC aufbauen, mit einer 5-Stufigen Pipeline á la DLX. Ich habe hier im Forum schon viele Threads zu diesem Thema gesehen, doch keine hatte die RISC Architektur als Grundlage. Ich würde die CPU gerne als 16bit Architektur auslegen. Auserdem würde ich die Register und Stack gerne in der CPU mit SRAM´s realisieren, da man dadurch zum Beispiel eine Art Registerbank realisieren könnte. Also z.B. eine Bank enthält 32 Register und es sind 64 Bänke vorhanden. So könnte für jeden Prozess eine Bank reserviert werden und der taskwechsel würde schnell von dannen gehen! Wäre so ein aufbau möglich? Vor allem, könnte man eine Taktrate von 4 Mhz erreichen? Freue mich immer über Anregungen! MfG Tobias
Hey, da hat schonmal ein Tobias dran rumgebastelt: http://www.mikrocontroller.net/forum/read-1-176063.html#176063
Hab ich auch bemerkt, nur der ist um einiges jünger als ich ;-) Ich habe mich mit ihm in Verbindung gesetzt und von ihm kommt die Idee mit den SRAM Registern, nur hat er bei seiner CPU keine Registerbänke vorgesehen. Seine CPU läuft nun zwar, aber nur mit ca. 1,5 MIPS, was mir zu wenig ist, wenn ich schon so einen großen Aufwand habe. Könnte ich meine CPU so verwirklichen würde diese bei nur 4Mhz ganze 4MIPS schaffen und sogar 4 Millionen Multiplikationen pro Sekunde. Meine eigentliche Frage ist aber, ob der Aufbau so möglich wäre? PS: Wäre hier interesse an Bildern von Tobias CPU? Ich hätte glaub noch welche auf der Platte. MfG Tobias
"4 Millionen Multiplikationen pro Sekunde" Wie bitte? 4 Mio 16x16-Bit Multiplikationen mit TTLs? "interesse an Bildern von Tobias CPU" Aber ja doch - hatte er versprochen aber nicht geliefert. Zum internen Stack: Eine RISC-CPU hat i.d.R. überhaupt keinen dedizierten Stack, üblich ist Branch-and-Link. Und wenn der auch für's activation record (Parameter, lokale Variablen und Register-Save-Area) gedacht ist, stellt sich die Frage nach dessen Adressierbarkeit. Andererseits: Welcher Adressraum? Eine 16-Bit CPU adressiert auf natürlichem Weg nur 64KB oder 64KW. Und das passt sowieso locker mit drauf.
Hallo, der Stack sollte eigentlich in einen 2. SRAM kommen mit samt mehreren Stackpointer für schnellen Prozesswechsel. Die 4 Millionen Multiplikationen werden mit 4 SRAM´s á 64k*16bit und 3x24bit addierern verwirklicht! Bei 4Mhz müsste die CPU das in 250ns schaffen, da ich aber die Memory Acces Phase bei mul nicht brauche, wird diese als 2. Executionsphase benutzt. So dauert eine multiplikation 500ns bei 4Mhz, was eigentlich ausreichen sollte. Der Adressbus ist 24bit breit, jedoch ist jede Adresse eine 32bit Speicherzelle, da ein Befehl 32bit breit ist. Da jedoch auf jedes Byte einzeln zugegriffen werden kann, stehen theoretisch 64Mbyte bereit. Hab grad geschaut und nurnoch paar Bilder gefunden, auf denen die CPU noch nicht fertig ist. Hab ihm ne Email geschickt, entweder er stellt hier die Bilder rein, oder er schickt se mir! MfG Tobias
Was ich bei beiden Tobias-Projekten nicht so ganz verstehe: Was ist in diesem Zusammenhang der Unterschied zwischen Speicherbausteinen und programmierbarer Logik? Wenn man also schon aus einem selbstgestellten Anspruch heraus auf PLDs verzichtet - belügt man sich bei der Verwendung von RAMs als Ersatz kombinatorischer Logik nicht selbst?
"der Stack sollte eigentlich in einen 2. SRAM kommen mit samt mehreren Stackpointer für schnellen Prozesswechsel." Den Anspruch habe ich schon verstanden, nicht jedoch was genau der Stack eigentlich stapeln soll.
Gewissermaßen belügt man sich schon, nur würde das ganze sonst total unmöglich werden, aber trotzdem ist es glaube ich immer noch ein Unterschied, ob FPGA usw. oder TTL+RAM, da die CPU ja nicht nur aus den Tabellen besteht. Und selsbt die CPU von Dennis Kuschel besteht aus solchen Tabellen! Der Stack soll wie gewöhnlich die Rücksprungadresse speichern, wie er z.B. auch bei AVR´s benutzt wird. Oder gibt es bei RISC Prozessoren noch eine andere möglichkeit? MfG Tobias
"Oder gibt es bei RISC Prozessoren noch eine andere möglichkeit?" Welche Vorstellung hast Du von RISC? Übersicht über CPU-Architekturen hast Du scheinbar keine. Schlechte Ausgangsbasis. Zur klassischen RISC-Philosophie zählt die Trennung in Load/Store-Befehle einerseits, und Befehle die auf Registern arbeiten andererseits. Der übliche Weg nennt sich folglich "branch and link". Die Rücksprungadresse in einem Register speichern. Einen Stack gibt es dann nur als Konstrukt von Compilern, nicht in der Hardware (Pinzipbetrachtung).
Ok, "branch & link" kenn ich schon, aber wie wird es erledigt, wenn ich mehrere Rücksprungadressen behalten muss? Werden die Register dann in den Arbeitsspeicher geschrieben? Außerdem meine ich, das ich gelesen habe, dass ein AVR auch mit Stack arbeitet (normalerweise arbeite ich nicht mit denen!)? Oder lieg ich da falsch? MfG Tobias
Einen Stack als solchen gibt es schon - nur wird der per Software gemanaged. Man definiere sich ein beliebiges Register als Stack-Pointer. Sieht dann ungefähr so aus (Pseudo-Code ohne konkreten Maschinenbezug):
1 | brl r30,function ;branch and save return address in r30 |
2 | ... |
3 | |
4 | function: |
5 | sub r31=r31,#12 ;stack pointer |
6 | store r8,@r31+0 |
7 | store r9,@r31+4 |
8 | store r30,@r31+8 ;return address (link register) |
9 | ... |
10 | load r8,@r31+0 |
11 | load r9,@r31+4 |
12 | load r30,@r31+8 |
13 | branch @r30 ;return |
Freilich gibt's da Konventionen und zwecks Beschleunigung kann es sein, dass Hardware existiert, die nur bei korrekter Einhaltung dieser Konvention eine korrekte Vorhersage realisiert, insofern in diesem Beispiel R31 dann doch irgendwie per Hardware zu Stack-Pointer wird. AVR orientiert sich zwar an RISC, hält sich aber nicht ernsthaft daran. So sind im RISC-Modell load-operate-store Befehle tabu. CBI/SBI und dergleichen sind jedoch genau das. Für einen Controller freilich verständlich. Ebenso macht CALL gleich mehrere Dinge in einem Befehle (branch, store). Andere Eigenschaften wie ein singuläre Statusregister kennzeichnen RISCs mit embeddes systems als Zielmarkt (z.B. ARM). Als RISC entstand, war eher Performance adressiert, da steht ein Statusregister eher im Weg. AVR sollte also nicht als Modell für RISC betrachtet werden. Weitaus lehrreicher: MIPS R2000/R3000 kann als Prototyp der RISC-Philosphie verstanden werden.
Zum Thema Stack und Registerbänke solltest Du zur Orientierung auch mal bei Sun SPARC und AMD 29000 reinschauen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.