Autor Thema: FPGA & Prozessorprogrammierung  (Gelesen 20979 mal)

hannibal

  • Host
  • Beiträge: 400
    • Profil anzeigen
    • brainsware - the rock.
Gespeichert
« am: 12. April 2005, 12:25 »
hallo,

durch meinen extrem engagierten und sehr foerdernden projekt-engineering lehrer, hab ich mit einem mitschueler die moeglichkeit um guenstiges geld (5€ fuer den fpga-chip + kosten fuer entwicklungsplatine) einen prozessor zu entwerfen! total geile sache, und nebenbei auch matura-projekt-anwaerter :D .

jetzt mach ich mich dann daran VHDL zu lernen und dann wird gecoded was das zeug haellt!

was der grund ist warum ich euch das erzaehle? ich haette den vorschlag gehabt, das ganze dann im magazin zu veroeffentlichen und eine art tagebuch darueber zu schreiben - eine sachliche kolumne, wenn man so will ;) .

auch interessant waere von euch ein paar vorschlaege zu hoeren, was eurer meinung nach die cpu koennen soll, was drin sein soll, usw. .. kommt sicher was interessantes dabei raus! werde dann meine planungen hier ins forum stellen und auf kritik hoffen.

lg, hannibal
\\o
o//
\o/

joachim_neu

  • Beiträge: 1 228
    • Profil anzeigen
    • http://www.joachim-neu.de
Gespeichert
« Antwort #1 am: 12. April 2005, 13:42 »
was sollte ne CPU können? ich würd sagen register haben, rechnen können mit diesen und ports sowie speicher ansteuern. fertig.

ein paar tipps von mir, wie ich es machen würde, wenn ich könnte (sorry, wenn ich total maßloses verlange, aber ich hab kA, was möglich ist, und was nicht, deswegen spreche ich nur meine träume aus.) und muss man dafür nicht einen eigenen assembler schreiben?

1. register, die sich vollständig bis hin zu bytes oder gar bits aufteilen lassen (EAX ist normalerweise in AX und das in AL und AH aufteilen lassen). z.B. EAX = AX1 (= AL1 & AH1) & = AX2 (= AL1 & AH2). und ggf. auch adressieren von einzellnen bits: (AL1 = AL10 | AL11 | AL12 ... | AL17).

2. mehrparametrige verarbeitung wie bei "mul": "add eax,ebx,ecx" addiert ebx zu ecx und schreibt es in eax. würde vorallem das schreiben von compilern erleichtern ;)

3. die möglichkeit mehrere speicherzugriffe durch ein buffer-konzept zu machen, sodass auch "add byte [0x01],[0x02],[0x03]" gehen würde.

J!N
http://www.joachim-neu.de | http://www.orbitalpirates.de | http://www.middleageworld.de

System: 256 RAM, GeForce 2 MX 400, AMD Athlon XP 1600+, Windows XP, 1x Diskette, 1x DVD-ROM, 1x CD-R(W) Brenner,...

elfish_rider

  • Beiträge: 293
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 12. April 2005, 13:50 »
Mein Tip zu den Registern: alle gleich gross! nicht erschwert dem Programmierer die Sache mehr als die Abwärtskompatibilität von Intels x86 (z.B.). Punkt 2 von JN finde ich auch gut. Die Frage ist ausserdem, was man alles realisieren kann, man bedenke mal das Budget von Intel, ich glaube nicht, dass deine CPU noch mehr Sachen unterstützen wird...aber viel Spass trotzdem ;)

DarkThing

  • Beiträge: 652
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 12. April 2005, 14:11 »
Ich find so Sachen immer cool, auch wenn ich keine genaue Vorstellung hab wie ihr das macht. Also bei joachim schleimen und das Tagebuch ins Magazin schreiben.
Wenn man sich bei den Befehlen an Intel-Kompatible CPUs hält, muss man sich keinen eigenen Assembler schreiben (man muss ja nur die Grundbefehle einbauen und den Rest einfach nicht verwenden).

hannibal

  • Host
  • Beiträge: 400
    • Profil anzeigen
    • brainsware - the rock.
Gespeichert
« Antwort #4 am: 12. April 2005, 15:33 »
Zitat von: joachim_neu
was sollte ne CPU können? ich würd sagen register haben, rechnen können mit diesen und ports sowie speicher ansteuern. fertig.

ein paar tipps von mir, wie ich es machen würde, wenn ich könnte (sorry, wenn ich total maßloses verlange, aber ich hab kA, was möglich ist, und was nicht, deswegen spreche ich nur meine träume aus.) und muss man dafür nicht einen eigenen assembler schreiben?

1. register, die sich vollständig bis hin zu bytes oder gar bits aufteilen lassen (EAX ist normalerweise in AX und das in AL und AH aufteilen lassen). z.B. EAX = AX1 (= AL1 & AH1) & = AX2 (= AL1 & AH2). und ggf. auch adressieren von einzellnen bits: (AL1 = AL10 | AL11 | AL12 ... | AL17).

2. mehrparametrige verarbeitung wie bei "mul": "add eax,ebx,ecx" addiert ebx zu ecx und schreibt es in eax. würde vorallem das schreiben von compilern erleichtern ;)

3. die möglichkeit mehrere speicherzugriffe durch ein buffer-konzept zu machen, sodass auch "add byte [0x01],[0x02],[0x03]" gehen würde.

J!N


ad 1: sollte eigentlich kein problem sein..man muss eigentlich nur die adressleitungen durch einen multiplexer jagen..kommt auf meine todo-liste ;)

ad 2: das wird dann vielleicht ueber den assembler gemacht, aber ich denke nicht, dass wir das direkt als opcode zur verfuegung stellen..oder vielleicht doch, ich weiss noch nicht - so weit sind wir ja noch gar nicht :)

ad 3: was ja eigentlich das selbe sein sollte, wie mehrere add-zeilen mit je einem parameter, oder? (siehe ad 2)

danke fuer eure kommentare..und nicht schuechtern sein, ich will das ding so gut, wie das meine kenntnisse erlauben, machen!

lg, hannibal
\\o
o//
\o/

joachim_neu

  • Beiträge: 1 228
    • Profil anzeigen
    • http://www.joachim-neu.de
Gespeichert
« Antwort #5 am: 12. April 2005, 15:58 »
Zitat von: DarkThing
Ich find so Sachen immer cool, auch wenn ich keine genaue Vorstellung hab wie ihr das macht. Also bei joachim schleimen und das Tagebuch ins Magazin schreiben.
Wenn man sich bei den Befehlen an Intel-Kompatible CPUs hält, muss man sich keinen eigenen Assembler schreiben (man muss ja nur die Grundbefehle einbauen und den Rest einfach nicht verwenden).


1. wieso schleimen? ;)
2. dann bräuchte man auch keinen neuen, weil man die Opcodes so lassen muss, dann kann man auch nix neues machen.

J!N
http://www.joachim-neu.de | http://www.orbitalpirates.de | http://www.middleageworld.de

System: 256 RAM, GeForce 2 MX 400, AMD Athlon XP 1600+, Windows XP, 1x Diskette, 1x DVD-ROM, 1x CD-R(W) Brenner,...

DarkThing

  • Beiträge: 652
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 12. April 2005, 17:20 »
Irgendwie schon richtig aber man könnte sich etwas Arbeit sparen.
Machen wir mal ne Pro & Contra Liste: ^^
Pro ist für Intel-Kompatible Befehle und Contra dagegen

Pro:
o Kein neuer Assembler
o Hört sich professionell an ;)

Contra:
o Man lernt weniger dabei
o Ist fast komplizierter als nen eigenen Befehlssatz

Wenn ich mir das so ansehe: Mach nen eigenen Beehlsatz  :D

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 12. April 2005, 17:30 »
Tu mir einfach einen gefallen ... schau dir auch die mac prozi's an. Jaja ich höre schon von überall das Buhen ...  :cry: Aber mac is einfach 1000 fach besser als win und die Hardware auch  :twisted: Vorallem (so wie ich das gehört hat) haben die mac prozis (Die G reihen) ziemlich komplexe und grosse "pipes" um alles aus der Hardware heraus zu kriegen. Hört sich doch kopierbar an  :wink:

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 12. April 2005, 18:27 »
Ein paar Sachen auch von mir.
1. Versuche, jeden Befehl so schnell wie möglich ausfuehren zu lassen (1 Tick wird schwerlich möglich sein, aber vielleicht...)
2. Mache nur einen Mindestsatz an Befehlen (Registerbefehle, Speicherbefehle, Rechenbefehle reicht aus, oder vergess ich was?) Der Mac 6800 soll nur 35 oder so gehabt haben.
3. Mache den Prozessor nach aussen hin so einfach wie möglich (s.3), damit er nichts einfacher und nichts schwieriger macht.
4. Wie gross sollen die Register denn werden? 8 Bit ist fuer ne Selbstbau-CPU gut, 16 oder 32 Bit prima. 64 wäre dann ein guter Scherz :)
5. ist ein Link: http://mycpu.mikrocontroller.net/index2.htm

Und kuemmere dich nicht um irgendwelche Kompatiblität, da du die ja eh in die Tonne treten darfst :) :) :)

Aber der FPGA ist ein programmierbarer Chip, oder? Wenn die CPU komplett läuft, kannst du alles ja festverdrahten und es noch schneller machen :) Je kleiner die CPU ist, umso höheren Takt kannst du reinjagen (s.5 ^^)

Viel Spaß & Erfolg!
Svenska

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 12. April 2005, 18:55 »
Takt frequenz is ned alles! Deine Buse und CO müssen auch das standhalten ... sonst kannst du dir das in die haare schmieren :P


PS: Der G5 von Apple is nen 64 bit Prozi... dazu besitz er noch ne methode die dazu sorgt das er IMMER gebraucht wird. Sprich er verscuht vorauszurechnen und kann damit schon zeit sparen ... was wiederrum wenig mit dem Prozi zu tun hat  :P

joachim_neu

  • Beiträge: 1 228
    • Profil anzeigen
    • http://www.joachim-neu.de
Gespeichert
« Antwort #10 am: 12. April 2005, 19:35 »
Zitat von: matthieuriolo
Tu mir einfach einen gefallen ... schau dir auch die mac prozi's an. Jaja ich höre schon von überall das Buhen ...  :cry: Aber mac is einfach 1000 fach besser als win und die Hardware auch  :twisted: Vorallem (so wie ich das gehört hat) haben die mac prozis (Die G reihen) ziemlich komplexe und grosse "pipes" um alles aus der Hardware heraus zu kriegen. Hört sich doch kopierbar an  :wink:


ach, schön, nur soweit ich weiß ist Mac-OS ein betriebssystem und hat rein garnix zu tun und die hardware hat rein garnix mit win zu tun. ist das normal unter macern, dass sie immer alles vermischen, oder liegt es daran, dass man diese rechner, die gerne in sachen standarts aus der reihe tanzen, so ziemlich nur in komplettsystemen bekommt, weil sie größtenteils inkompatibel sind?
http://www.joachim-neu.de | http://www.orbitalpirates.de | http://www.middleageworld.de

System: 256 RAM, GeForce 2 MX 400, AMD Athlon XP 1600+, Windows XP, 1x Diskette, 1x DVD-ROM, 1x CD-R(W) Brenner,...

mastermesh

  • Beiträge: 341
    • Profil anzeigen
    • http://www.kostenloser-laptop.de/
Gespeichert
« Antwort #11 am: 12. April 2005, 19:46 »
Zitat von: joachim_neu
dass man diese rechner, die gerne in sachen standarts aus der reihe tanzen, so ziemlich nur in komplettsystemen bekommt, weil sie größtenteils inkompatibel sind?


Deine Sichtweise ist ein wenig einseitig... der Apple Macintosh ist eine andere Plattform, da ist es wohl normal, dass da eigene Standarts gemacht werden...

Versteh mich nicht falsch, ich bin selber ein x86er, aber deine Sicht ist nicht ganz richtig.

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 12. April 2005, 20:09 »
Wie hast du heraus gefunden das ich ne macianer bin  :lol:

Ein "Mac" kernel braucht auch nen Mac prozi is doch klar. Sonst würde ja xp auf meinem iMac gehen  :wink: Also is es DOCH hardware bestimmt. Oder wenigstens stückweise ^^ nun mac is nicht inkompatibel weil ich bezweifle das dein IBM rechner mit meinem G4 zockt  :roll: das is so wie wenn man versucht ein auto mit einem Velo dinamo zu speisen...

hannibal

  • Host
  • Beiträge: 400
    • Profil anzeigen
    • brainsware - the rock.
Gespeichert
« Antwort #13 am: 12. April 2005, 22:03 »
kinder kinder, ich will jetzt nicht, dass das in einen mac-linux-windows-hard-und-betriebssystem-undsoftware-krieg ausartet .. ;)

vorerst wird es mal ein 8bit prozessor mit einem kleinen befehlssatz, der nicht ueber mov, add, sub, shl, shr, mul hinausgeht. vielleicht noch out und in fuer die aussenwelt. wenn das funktioniert, dann werd ich ueber weitere dinge, wie zb. 16/32 bit,  nachdenken ;) .

lg, hannibal
\\o
o//
\o/

DarkThing

  • Beiträge: 652
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 13. April 2005, 13:58 »
Wirklich wichtg sind Sprungbefehle. Vor allem beim cmp Befehl braucht man die. Ich glaube das 2/3 aller Befehle von 486er Sprungbefehle sind, aber 2-3 sollten reichen.

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #15 am: 13. April 2005, 14:00 »
Und vergiss nicht Register und Speicheraddressierung! :D
Ach ja, wieviele Register willst du denn machen?

Zitat
Takt frequenz is ned alles! Deine Buse und CO müssen auch das
standhalten ... sonst kannst du dir das in die haare schmieren :p
Wenn jeder Prozessorbefehl in einem Takt ausgefuehrt wird, ist es schon
abhängig von der Taktfrequenz. Ausserdem schrieb ich kann... du
kannst in nen 8-Mhz-Rechner keine 2 Ghz-CPU reinstopfen. :p
Aber es bleibt bei sowas immernoch "Luft" zum Optimieren, wenn du zu
knapp kalkulierst, ist er nach paar Mhz am Ende. Vergleiche Punkt 5 :p

Fuer Macianer sind Hard- und Software identisch, da fuer den nicht zu
trennen :p :p Auch wenn man da mit Mueh und Not Linux raufkriegt.

Svenska

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #16 am: 13. April 2005, 14:12 »
Zitat von: Svenska
Fuer Macianer sind Hard- und Software identisch, da fuer den nicht zu
trennen :p :p Auch wenn man da mit Mueh und Not Linux raufkriegt.


doch schon nur is es ziemlich egal was für ne garfik karte drin hast. Laufen tuts so oder so sehr gut :P und wegen linux *hust* ich hatte mal win200 und 9.1 drauf und Yellow Dog is soviel ich weiss noch jetzt installiert. Wenn man weiss wie is alles einfach ;)

PS: Sorry bin schon wieder vom thema ....

Another Stupid Coder

  • Beiträge: 749
    • Profil anzeigen
Gespeichert
« Antwort #17 am: 13. April 2005, 15:14 »
Also, ich wünsche euch viel Glück bei dem Projekt, alles was ich vorgeschlagen hätte, wurde schon gesagt :)

bzg. Mac: Es gibt keine Mac-Prozessoren, in einem Mac sind ganz normale PowerPCs soweit ich informiert bin. Achja zu Standards sollten wir x86er doch eigentlich überhaupt nichts sagen :D

matthieuriolo

  • Beiträge: 226
    • Profil anzeigen
Gespeichert
« Antwort #18 am: 13. April 2005, 20:34 »
jo stimmt, weitere infos hier http://www.apple.com/de/g5processor/

Netmaster

  • Beiträge: 41
    • Profil anzeigen
Gespeichert
« Antwort #19 am: 18. April 2005, 10:52 »
Habt ihr euch schon über die Grundarchitektur geeinigt?
RISC oder CISC? Ich wüde RISC empfehlen, kein Overhead mit Microcode. Ein gutes, aber sehr altes Buch zum Thema ist Mikroprozessorlehre oder auch so ein von MITP, hab vbergessen wie es heißt. Man müsste sich auch überlegen, wie viele Register die CPU haben soll und ob solche Mechanismen wie caching oder virtuelle Adressierung (vorausgesetzt Multitasking) eingesetzt werden, aber davon kann ich nur abraten......
Chaos ist die höchste Form der Ordnung ;)

 

Einloggen