Nachdem wir ein Semester lang einen Teil des ARM9 in VHDL gebaut hatten, hatte ich mir gedacht, daß ich einen ARM (eventuell nur einen Teil davon) als VHDL-Entity programmieren könnte und einen Spartan3 statt eines NXP-ARMs (LPC2101 und ähnliche) einsetzen könnte: In der Theorie hätte man damit eine Geschwindigkeitssteigerung von ca. 50 MHz (LPC2101) auf 250 MHz (Spartan3). Nun habe ich eben gerade zum ersten Mal den ISE-Synthesizer ausprobiert und für einen einfachen 4-auf-1-Multiplexer eine Verzögerungszeit von 7 ns bekommen, also Maximalfrequenz 140 MHz. Der ARM hat eine 32-Bit-ALU und wird an Komplexität mit einem Multiplexer nicht vergleichbar sein. Bevor ich ein bis zwei Monate Arbeit investiere: Bekäme ich denn am Ende für den ARM eine Maximalfrequenz von 10 MHz ??? Wie gesagt, ich habe den Synthesizer heute zum ersten Mal benutzt (ohne Einweisung), vielleicht liegt es an mir ...
Ja den Fehler hab ich auch gemacht! Das "Problem" ist, das die Synthese das auf die Eingangs/Ausgangspads legt, und da hast du dann ein zusätzliches Delay. Siehe: Beitrag "1-Bit ALU -- geht es besser?" Ne 32Bit ALU wirst du ohne weiteres (Pipelining z.B.) aber nicht mal ebenso auf 250Mhz bringen. Ich bin so auf etwa 110 Mhz gekommen bei simplen Operationen... Es gibt auch komerzielle ARM Soft Cores also könntest du dich da mal umschauen was die so können, dadrüber wird man als Anfänger nicht mal so eben drüber kommen.
Hey, da hast du ja das gleiche vorgehabt wie ich (CPU bauen). Nach http://www.eetasia.com/ART_8800457791_499485_NP_5ee407b2.HTM sind 72 MHz das Maximum, lohnt sich also praktisch nicht, noch selber in VHDL zu programmieren. Die phantastischen 300 MHz, von denen man im Zusammenhang mit FPGAs immer liest, beziehen sich also leider nur auf einstufige UND-Gatter und Bustreiber ?
Naja ich sag mal so: Für richtig Geld kriegste auch FPGAs die schneller sind... nur die Kosten dann auch wenn es doof kommt mal soviel wie ein Kleinwagen ;) Es gibt auch Desins die mehr enthalten und auf mehrere 100 Mhz kommen das ist nicht das Problem, aber du kannst dir ja mal überlegen warum der Hersteller eines ARM den 'nur' für 50Mhz produzierst... bestimmt nicht weil er denkt: Mehr braucht man nicht. So eine CPU enthält schon recht komplexe Logik und man braucht viel Erfahrung. Wenn es dir aber nur um den Spaßfaktor geht sollte dich das nicht abhalten, selbst wenn dein Core nur die 50Mhz schafft, es ist halt die Frage was man will: - Willst du binär/HW kompatibel sein dann wirst du sehen das du häufig Sachen 'schlechter' bauen mußt als eigentlich möglich wäre damit es halt wie das Orginal funktioniert - Willst du sowas ähnliches machen - Oder willst du einfach nur selbst ne CPU mal entwerfen, dann würd ich nicht mit 32 bit und ARM als Vorlage anfangen ;)
Was ich machen möchte, ist: ich hoffe, daß ich im nächsten Semester meine Bachelorarbeit machen kann. In Technischer Informatik soll man haben ein Stück Software auf einem Stück Hardware, wobei Hardware sich seit ein paar Jahren noch weiter aufteilen läßt in Prozessorschaltung und FPGA-Programmierung - sodaß man also schon drei Vorgaben hat, die es zu erfüllen gilt: 1. Software-Programm, 2. VHDL-FPGA-Programm, 3. Prozessor-/Controler-Schaltung. Falls ich kein Thema in einem Unternehmen finde, habe ich den Vorteil, daß ich mir das Thema selber aussuchen kann: ich hatte mir gedacht, vielleicht eine kleine 3D-Graphikkarte als FPGA zu programmieren, um damit flache Polygone mit Texturen darzustellen. Dabei braucht man eine Matrix-Multiplikation, die aus ca. 64 einzelnen Multiplikationen besteht, die voneinander unabhängig sind, sodaß man eine einfache parallele Pipeline hat. Aber was ist nun mit den 300 MHz ? Gelten die nur für einen internen Oszillator ? Mein Beispiel "Bustreiber" (siehe oben) war Unsinn, weil man da auch die Anschlüsse mit drin hat, aber als Gast hat man keine Edit-Funktion.
@ OliverKroll (Gast) >vielleicht eine kleine 3D-Graphikkarte als FPGA zu programmieren, um >damit flache Polygone mit Texturen darzustellen. Dabei braucht man eine >Matrix-Multiplikation, die aus ca. 64 einzelnen Multiplikationen >besteht, die voneinander unabhängig sind, sodaß man eine einfache >parallele Pipeline hat. Sonst hast du nix vor? Kann es sein, dass du den Aufwand, welcher hinter so einer Sache steckt "etwas" unterschätzt? >Aber was ist nun mit den 300 MHz ? Gelten die nur für einen internen >Oszillator ? Nöö, das schafft man mit einer Logikebene. Sprich, Daten aus einem FlipFlop raus, eine LUT durch, ins nächste FlipFlop rein. Wenn du es schaffst, deine Logikoperationen auf eine Logikebene zu beschränken, dann schaffst du 300 MHz. Ist aber bei einer CPU praktisch nicht machbar. Schau dir den Microblaze an, der ist auf das FPGA hin optimiert. Der läuft AFAIK mit bis zu ~100 MHz oder so auf den schnellsten FPGAs. Den ARM wird nicht schneller hin bekommen, eher langsamer. Rechne mal für den 1. Schuss mit 30 MHz, wenn du irgendwann in ein, zwei Jahren wirklich FIT bist in der Materie bekommst du den vielleicht auf das Doppelte. MFG Falk
Schade, das macht mir meine ganzen Pläne kaputt. Sind die 300 MHz wohl nur ein Marketing-Versprechen - ist bei Kleinsignal-Transistoren das gleiche: von der Transitfrequenz von 170 MHz bleiben bei einer normalen Schaltung nur 5 MHz. Schade, wirklich schade.
> Die phantastischen 300 MHz, von denen man im Zusammenhang mit FPGAs > immer liest, beziehen sich also leider nur auf einstufige UND-Gatter und > Bustreiber ? Nein, das ist wie mit den "Seiten pro Minute" beim Drucker. Wenn du alles optimal einstellt, bekommst du das heraus. In der Realität heißt das: >>> Flipflop -> kürzestmögliche Verdrahtung -> 1 LUT -> Flipflop <<<< Und in 1 LUT passt nicht allzuviel Logik :-( (beim Spartan 6 wird das mit den 6-Input-LUTs besser) Man schaffts es also einzelne, klein abgegrenzte Teile eines FPGAs mit dieser Maximalgeschwindigkeit laufen zu lassen, aber das braucht manuelles Tunig des Codes auf den Synthesizer ;-)
Mal langsam, die erreichbare Taktfrequenz liegt immer noch bei dir ! Selbst wenn du einen bestehenden Arm nachbilden solltest, dann ja nicht so wie das original aussieht, sondern nur identisch von außen, also bezüglich der opcodes, register usw. Du kannst letztendlich problemlos auf vergleichsweise hohe Taktraten(50-100mhz) kommen wenn du entsprechend aufpasst beim Entwurf und das ganze mit so wenig Stufen wie möglich erledigst. Das beinhaltet aber ggf eine andere Verarbeitung, z.b. das bestimmte Befehle 2 Takte benötigen bei deiner entworfenen cpu und im original nur einen. MMn ein sehr gutes Thema da man extrem viel lernt : - timing beobachten und optimieren - alle möglichen Arten/Varianten von Befehlen - die Anbindung von Schnittstellen (Ram, Kommunikation, I/O) - Softwarepart dazu - überlegung wie man bestimmte Techniken in der Hardware realisiert (fetch, decode, writeback, etc)
Ich bastle keine CPUs ;-) Mir macht die Hardware drumrum viel mehr Spass. Und da kann man auch lernen, wie man z.B. eine Kamera, ein Display, einen Schrittmotor, irgendwelche IO.... anschliesst. Und vor allem passen diese Module an alle anderen CPUs von AVR, 8051 über MSP430 und 68k bis zum Picoblaze. Und wenn der Rechner zu langsam ist, dann nehm ich einen anderen wie z.B. ARM, Coldfire.
Hi, naja, mit einem 'normalen' FPGA (also z.B. ein Spartan3, also durchaus moderne Technik) kannst du Designs machen, die mit 100MHz laufen. Aber auch da wirst du schon mal beim implementieren im Timing-Report boese Ueberraschungen erleben, die dich zwingen, deinen Design umzubauen (z.B. von 1 cycle Latenz auf 2). Und je voller der FPGA wird, desto schlimmer wird das, da dann natuerlich irgendwann zusaetzliches Routing-Delay dazu kommt... Du kannst ja mal die Angaben von Xilinx oder Altera zu ihren (sorgsam handgestreichelten Softcores) als Mass nehmen, schneller wirst du es auch nicht hin bekommen, eher deutlich langsamer. Waer' ja auch noch schoener, wenn die Geier der Syntheseprogrammierung besser waeren als 'echte' HW-Entwickler! Eine Implementierung eines ARMs als Standard-Cell Design kann Sachen machen, die mit einem FPGA einfach nicht gehen, z.B. cycle-steal bei mehrzyklischen Pfaden. Und da arbeitet eine ganze Armada an Entwicklern am Placement der einzelnen Module. Die Tools haben in den letzten 20 Jahren enorme Fortschritte gemacht, keine Frage. Aber von den spezialisierten Loesungen sind sie (gottseidank) meilenweit entfernt... just my 2 cents...
@Iulius (Gast) >Du kannst letztendlich problemlos auf vergleichsweise hohe >Taktraten(50-100mhz) kommen wenn du entsprechend aufpasst beim Entwurf >und das ganze mit so wenig Stufen wie möglich erledigst. Mein junger, stürmischer Freund. Du solltest das Wort "problemlos" etwas sparsamer verwenden . . . >Das beinhaltet aber ggf eine andere Verarbeitung, z.b. das bestimmte >Befehle 2 Takte benötigen bei deiner entworfenen cpu und im original nur >einen. Was ja auch bei einer CPU völlig problemlos geht . . . @ berndl (Gast) >als Standard-Cell Design kann Sachen machen, die mit einem FPGA einfach >nicht gehen, z.B. cycle-steal bei mehrzyklischen Pfaden. Das kann ein FPGA auch. Der Vorteil von ASICs in gleicher IC-Technologie ist die festverdrahtete Logik. Die ist dadurch, dass es nur Kupferbahnen statt schaltbaren Transistoren sind, um Faktor 2..3 schneller. Dafür kosten ASICS "ein wenig" mehr in der Entwicklung ;-) MfG Falk
Kaum kennt man 10 Zeilen VHDL, denke man eine FPU ist in Reichweite ... VHDL ist ein Abstraktionssprache. Um aber das letzte Qentchen Geschwindigkeit aus einem FPGA zu pressen braucht man einiges mehr an Wissen. Ein Faktor 2, 3, 4 ist schnell mal verschenkt. Programmier erst mal ein paar Monate VHDL mit einem Hardwarebezug.
>> Du solltest das Wort "problemlos" etwas sparsamer verwenden . . . warum ? 60mhz habe ich selbst mit einem langsameren fpga(cyclone 2) und 3 Operand Risc bei gleichzeitigem operand decode + execute in einem Takt erzielt. Das ganze wohlbemerkt ohne wirklich zu optimieren. Daher bin ich durchaus der Meinung 50mhz sind bei einem schnelleren Chip problemlos drinne, wohl auch mehr wenn man extra darauf hin arbeitet. zum vergleich : ein nios 2 erreicht auf dem gleichen chip etwa 140mhz bei 1 befehl pro takt : http://www.altera.com/literature/ds/ds_nios2_perf.pdf keine ahnung wie du auf 100mhz für den microblaze auf den schnellsten fpgas kommst : http://www.xilinx.com/publications/magazines/emb_04/xc_pdf/p18-21_4emb-archide.pdf Hier ist z.b. die Rede von 200/220mhz auf einem virtex 5. Wie man sieht ist durchaus mehr erreichtbar. Das heißt natürlich nicht das man dies problemlos selbst erreicht. Werte die bei 25-50% der "optimallösung" liegen halte ich aber für sehr gut machbar bei gleichem Prozessorkonzept. >> Was ja auch bei einer CPU völlig problemlos geht . . . Wo ist das problem ? Der Programcounter wird erst erhöht wenn der Befehl fertig ist und gut. Wüsste echt gerne wo dabei das Problem liegt.
@ Iulius (Gast) >60mhz habe ich selbst mit einem langsameren fpga(cyclone 2) und 3 >Operand Risc bei gleichzeitigem operand decode + execute in einem Takt >erzielt. >Das ganze wohlbemerkt ohne wirklich zu optimieren. Ja und? Du kennst den explkiziten AUfbau der diversen ARMs, welche dem OP vorschweben? >Daher bin ich durchaus der Meinung 50mhz sind bei einem schnelleren Chip >problemlos drinne, wohl auch mehr wenn man extra darauf hin arbeitet. Die Aussage ist ohne explizite Kenntnis der Logik schlicht Unsinn. >keine ahnung wie du auf 100mhz für den microblaze auf den schnellsten >fpgas kommst : War aus dem Gedächtnis von vor längerer Zeit auf Virtex-II. >http://www.xilinx.com/publications/magazines/emb_0... >Hier ist z.b. die Rede von 200/220mhz auf einem virtex 5. Wobei man bei solchen Marketingaussagen immer SEHR vorsichtig sein muss. Bei genauerem Nachhaken kommt dann meist raus, dass siese Zahl nur für den schnellsten Speed Grade, bei minimaler Aussenbeschaltung des Kerns läuft. Kommen diverse Busanbindungen etc. dazu und will man das auf einem "normalen", bezahlbaren FPGA laufen lassen, ist man mal fix bei der Hälfte. >Wie man sieht ist durchaus mehr erreichtbar. Hat niemand bestritten. > Das heißt natürlich nicht >das man dies problemlos selbst erreicht. Meine Rede. >Werte die bei 25-50% der "optimallösung" liegen halte ich aber für sehr >gut machbar bei gleichem Prozessorkonzept. Hatte ich das nicht geschrieben? >Der Programcounter wird erst erhöht wenn der Befehl fertig ist und gut. >Wüsste echt gerne wo dabei das Problem liegt. Klar, weil man so ne CPU mit bestehndem Design, Opcodes und Ablaufstruktur mal fix bissel umstricken kann. Jaja. MfG Falk
>> Ja und? Du kennst den explkiziten AUfbau der diversen ARMs, welche dem >> OP vorschweben? nö, ich gehe einfach vom standard 3 operand Risc aus, denn das ist der ARM nun mal. Das Ziel ist in dem Fall doch nur eine cpu die sich nach außen gleich verhält, also z.b. die gleichen opcodes, register usw aufweist. Natürlich hast du recht wenn man einen 1:1 Nachbau möchte, also genau die gleichen Konzepte z.b. für Sprungvorhersagen nutzt, genau die gleichen Taktdauern für die diversen befehle hat usw. Hier hat man keine Wahl und muss dann nehmen was man bekommt. Es stellt sich nur die Frage : warum will man sich selbst Steine in den Weg schmeißen ? deshalb auch : >> Klar, weil man so ne CPU mit bestehndem Design, Opcodes und >> Ablaufstruktur mal fix bissel umstricken kann in meiner Idee gibt es kein bestehendes Design, sondern nur eine bestehende Schnittstelle nach außen die vorgegeben ist. >> Wobei man bei solchen Marketingaussagen immer SEHR vorsichtig sein muss Ja, das sind maximalwerte, steht ja auch da. Aber darum ging es doch hier auch von Anfang an.
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.