Hallo zusammen, ich lese gerade das Datenblatt der Virtex4 Familie, da ich mit einem Kumpel zur Zeit eine CPU in VHDL entwickle und wir diese gerne mit einem FPGA verwirklichen würden. Die Virtex4 Familien (vor allem die SX-Typen) sehen hierfür recht gut geeignet aus, da sie viele DSP-Slices beinhalten. Nun meine Frage: Kann man den Operationsmodus in dem ein DSP-Slice (oder DSP48-Slice) arbeitet auch während dem betrieb des FPGA´s ändern, oder wird dieser beim Konfigurieren des FPGA´s einmal fest eingestellt und kann dann erst beim nächsten start wieder verändert werden? In dem zugehörigen Datenblatt des DSP Blocks sind die Eingangsleitungen des Blocks gezeigt worunter auch 7 für den OP-Modus sind. Theoretisch müsste man dann ja auch de OP-Modus ändern können, aber ich bin mir halt nicht sicher, deswegen frag ich euch lieber mal. MfG Markus
Die OPMODE, SUBSTRACT und CARRYINSEL Eingänge können "ständig" bzw in einem synchronen Design mit jedem Takt angepaßt werden. Es gibt sogar optional eine Registerstufe für diese Eingänge, um sie den Datenpfaden anzupassen. Xilinx XtremeDSP Design Considerations ug073.pdf Seite 26 Allgemein können alle Signale die in der "port map" drinstehen aus der Logic im FPGA beeinflußt werden. An was für einer CPU arbeitet ihr? Was eigenes oder etwas zu bestehendem kompatibles
Danke für deine Hilfe! Das pdf hab ich sogar auf der Festplatte, aber habs irgendwie übersehen, sorry! Die CPU wird etwas Eigenes, da wir zuerst die Idee hatten ein eigenes Betriebssystem zu programmieren, was wir dann auch teils taten, bis wir auf die Idee kamen, dass es doch noch eine größere Herausforderung wäre auch noch die CPU dazu selbst zu entwickeln. Da wir in VHDL einigermaßen gut sind, haben wir jetzt auch schon mit der CPU begonnen und einige Teile funktionieren auch schon (laut simulation zumindest^^). Um eine möglichst hohe Performance zu erreichen haben wir uns überlegt die CPU aus einer Kontrolleinheit und 8 ALU´s aufzubauen. Die ISA ist VLIW ähnlich, so dass in der CPU nicht ewig viel Hardware für die Optimierung auf Parallelität drauf geht. Außerdem ist die CPU SMT fähig (max. 4 Threads gleichzeitig), wodurch immer ein Großteil der 8 ALU´s ausgelastet sein sollte. Jede ALU besteht jetzt aus 2 bis 8 DSP48-Slices (sind uns noch nicht sicher, ob wir Unterstützung für 64bit Variablen mit einbauen sollen) und etwas zusätzlicher Logik. Die Kontrolleiheit ist am kompliziertesten, da sie den "Verteiler", den Interruptcontroller, den Cache Controller, die MMU usw. beinhaltet. Außerdem wollen wir noch ein Businterface für DDR2 Ram (sollte mit Virtex4) doch möglic sein mit einbauen, damit wir dann auch mit hohen Taktraten arbeiten können. So, dass sollte erstmal reichen, aber wenns jemanden interessiert kann ich noch weitere Infos geben! MfG Maxe
Das ganze klingt definitiv sehr ambitioniert. - OS - 32/64bit CPU - Assembler usw. wird ne ganze Menge Zeit und Mühe mit sich bringen. Auf der anderen Seite lernt man viel dabei. Ich hoffe nur ihr seht das ganze eher als akademische Herausforderung. Wenn ihr nicht Hardcore-Pipelining betreibt werden wohl, naive geschätzt, nicht mehr als 200Mhz Taktfrequenz drin sein. Bei den Preisen von Virtex4-Systemen wird jede Realisierung auch ein gehöriges Loch ins Studentenbudget? reißen. DDR2 ist vom FPGA her kein Thema. Übrigens für eine vollständige 32x32 Multiplikation in einem Schritt sind 4 18x18 respektive DSP-Slices notwendig, für 64x64 dann 16 (skaliert mit n^2)
>Da wir in VHDL einigermaßen gut sind...
Euer Projekt hört sich ja sehr nett an, aber ich zweifle daran, dass
Ihr das packt.
@Daniel Mit "einigermaßen gut" meinte ich, dass wir keine Anfänger mehr sind und schon einige Erfährungen mit CPU´s in VHDL gemacht haben, wenn auch noch keine selbstentwickelte dabei war. Bis jetzt sind wir auch nur am VHDL Code und der FPGA wir erst gekauft, wenn die simulation läuft^^ Wir müssen uns jetzt halt erstmal für einen FPGA entscheiden, damit wir wissen, welche Ressourcen uns zur Verfügung stehen.... @Nimbus Das wird schon ein großer Brocken, aber wenns einigermaßen läuft, hat man was worüber man sich freuen kann^^ Lohnt sich also in jedem Fall. Außerdem lernt man da, wie du schon sagtest, bestimmt eine ganze Menge dazu! Die einzelnen ALU´s sind alle als Pipeline aufgebaut, werden aber trotzdem nicht schneller als 200Mhz laufen, da wir sonst die Daten garnicht schnell genug zu den ALU´s bekommen. Jede ALU besteht nun aus 4 DSP-Slices, die mit 400Mhz laufen. Mit etwas zusätzlicher Logik sollte es möglich sein, damit 2 32bit Operationen pro 200Mhz Takt zu erzielen. Für 64bit Operationen bräuchten wir dann allerdings zwei 200MHZ Takte, was aber erstmal nicht ins Gewicht fällt, da man diese eh sehr selten braucht..... Mit den DSP-Slice Ressourcen, die z.B. ein SX35 bietet, kann man locker 2 CPU mit jeweils 12 ALU´s (anstatt oben erwähnten 8) realisieren, was 24 ALU´s entspräche. Wären nun alle ALU´s voll mit 32bit Operationen ausgelastet, würden diese zusammen 24*2*200 MIPS schaffen, was 9800 MIPS entspräche. Durch die SMT Fähigkeit, dürften die ALU´s auch immer recht gut ausgelastet sein. Ob dass nun so möglich ist müssen wir aber noch schauen, oder besser gesagt die Datenblätter durcharbeiten! MFG Maxe
also, angenommen, die Simulation/Integration dieser neuen CPU läuft ohne Probleme, wie soll sie dann programmiert werden? Habt ihr einen eigenen Assembler/Compiler für diese CPU geschrieben?
Hallo zusammen, also ich finde euer Projekt durchaus interessant. Man lernt bestimmt viel dabei. Das mit SMT und so stelle ich mir zwar ziemlich komplex vor, aber wenn ihr euch dran versuchen wollt, bestimmt interessant. Als günstige Alternative zu den Virtex4s könntet ihr eventuell mal die Lattice ECP2 Familie anschauen (http://www.latticesemi.com/products/fpga/ecp2/index.cfm ). Die haben auch DSP ähnlich den Virtex4, und nicht nur pure Hardwaremultiplizierer. Habe jetz aber leider keine Anhaltspunkte gefunden welche Geschwindigkeit die erreichen können und wieviel da ein Evaluation Board kostet. viel Spaß beim weiterbasteln!
Ich glaube Euch immer noch nicht, dass Ihr sowas hinkriegt. Ein guter Hardwareentwickler hat im Normalfall schon 10 bis 20 Jahre Berufserfahrung auf dem Buckel. Der kann sowas. Nur "keine Anfänger in VHDL mehr zu sein" reicht da nicht. Wenn Ihr es schafft könnt Ihr ja mal vom Ergebnis berichten. Dann schenke ich Euch auch meinen vollen Respekt. Daniel
ich denke, die Aufgabe ist sehr anspruchsvoll, aber wenn man die ernst anpackt, könnte man sie mit der Zeit hinkriegen. Mich interessiert vor allem, wenn man eine neue CPU selbst entwickelt hat, eine CPU mit vielen Pipelines, ALUs, SMT usw., mit welchen Werkzeugen programmiert man sie? Wird diese ExremeDSP-CPU kompatibel zu irgendwelchen anderen (kommerziellen) CPUs sein, so dass man auf die bestehenden Compiler/Assembler zurückgreifen kann? Und werden diese Compiler die Möglichkeiten der neuen CPU voll ausnutzen können, die vielen Pipelines, ALUs usw.?
Habe ich euch da richtig verstanden: Im Idealfall 9800MIPS zu je 32Bit? Das sind dann etwa 40GByte/s nur für die ALUs. Dazu kommen natürlich noch Load+Store, Schleifen usw. usf., d.h. euer Speicherinterface müsste mindestens 100GByte/s machen. Ich habe zwar keine Erfahrung mit DSPs, aber beim Pentium4 hieß es, das SMT bringe etwa 20% Performance. Aber selbst damit ist er nicht annähernd voll ausgelastet.
Hät nicht gedacht, dass das so viele interessiert, hammer! Die CPU arbeitet mit VLIW. Jedes Befehlpacket ist 128bit breit, kann aber in mehrere Takte zerlegt werden. Das Businterface ist ebenfalls 128bit breit und hat eine DDR2 Schnittstelle, die wir schon fertig im Netz gefunden haben und nur geringfügig ändern müssen. Außerdem handelt es sich bei den im Befehlpacket enthaltenen Befehlen meist um SIMD Befehle, weswegen keine sehr hohe "Befehlsbandbreite" erforderlich ist. Ausgelastet kann die CPU nur werden, wenn sie mit SIMD Befehlen gefüttert wird, da sonst, wie du schon sagtest irrsinnig hohe Speicherbandbreiten zur Verfügung stehen müssten.... Aber es gibt ja auchnoch internen Blockram der höhere Bandbreiten zulässt. Wir haben bis jetzt noch keinen wirklich passenden Befehlssatz gefunden, der einigermaßen zu unsrer CPU passen würde, aber fals wir einen passenden finden, werden wir unsere CPU auf diesem Aufbauen lassen. Nac dem Compiliern müsste natürlich noch ein anderes Prgramm drüber gehen, was daraus die VLIW Befehlspackete usw. herstellt, aber das wäre dann ja kein großes Problem mehr. Aber bis jetzt siehts eher schlecht aus^^ MfG Maxe
Wollt Ihr die 128Bit nach außen führen? DDR2-Module haben doch nur 64Bit, d.h. da wären dann 2 Module parallel nötig. Fünf Sekunden googeln hat keine Virtex4-Boards mit 128MBit DDR2 zutage gefördert, aber ich bin dem nicht weiter nachgegangen. Die typischen Befehle (Addition, Multikplikation usw.) brauchen 2 Parameter und haben ein Ergebnis. Bei 10 Milliarden ALU-Befehlen/s sind das 30Mia Speicher-/Registerzugriffe, d.h. bei 32 Bit eben 120GByte/s. Bei 400MHz sind das 2400Bit parallel (=75 32Bit-Register). Im Prinzip ja nur auf die Register, aber irgendwie müssen die Daten auch vom internen Speicher in die Register kommen, wodurch der Druck auf die Register weiter steigt.
Ich verfolge die Diskussion von Anfang an. Einerseits finde ich es spannend, Leuten zuzusehen, die irgendwas "Großes" vor haben, andererseits möchte ich euch meine Meinung nicht vorenthalten. Und die wäre: Sinnlos, wird nie fertig, wird nie gebraucht, nicht mal zum Lernen zu gebrauchen, denn solange keine Werkzeuge dafür da sind, kann man ja viel machen, und in Hardware wird es nie laufen. Somit werdet ihr nie das erreichen, was ihr vor hat. Allein DDR2 wird euch den letzten Nerv rauben, bis ihr Cache hinbekommen habt, vergehen mindestens noch ein Paar Monate, dann habt ihr keinen Speicher mehr im FPGA, das FPGA ist zu klein, größere sind sehr teuer und normale Desktops schaffen eh mehr, als eure Simulation, nach einerweile kommt ihr dann gar nicht voran, weil ihr damit beschäftigt sein werdet die Bugs zu suchen. Abgesehen von der ganzen VHDL-Kram. Und Lernen als "Grund" dafür anzugeben ist, sorry, dumm. Ich lerne nicht ein A380 fliegen, bevor ich nicht eine Cessna oder wie die Dinge heißen fliegen kann. Und das Thema Werkzeiug, bzw. die ganzen Compiler, Assembler, Debugger und und und schafft ihr einfach nicht, punkt. Abgesehen von den kostenpflichtigen Tools, die z.B. für so ein Virtex notwendig sind. Ich glaube, euch ist nicht bewusst, was ihr da geplant habt :-o Es gab mal Zeit, wo ich am laufendem Band CPUs, die viiiieel besser sind, als die üblichen ausgedacht habe. Aber mehr als Papier ist nichts rausgekommen... Was meint ihr, wieso nicht jemand schon vor euch auf die Idee gekommen ist? Ist jetzt nicht böse gemeint. Ich wollte euch nur auf den Boden der Tatsachen holen. Wenn ihr schon so versessen darauf seid, eigene CPU zu entwickeln, fang doch mal bei Picoblaze/Microblaze/Nios/PowerPC/Z80 und so weiter fort. Die könnt ihr dann erweitern. Nicht destotrotz, stellt ruhig hier im Forum Fragen, die werden sicherlich gerne beantwortet :-) Ihr könnt ja einen Wiki-Artikel starten - wie sieht eine idealle CPU aus, da werdet ihr sehen, was wieviel wert ist, auf was verzichtet werden kann und was nicht zu umgehen ist. Ich wollte euch nicht den Mut nehmen ;-) Gruß Kest
Nur so nebenbei es kommt bald der Virtex 5 raus. Dieser FPGA wurde noch mal deutlich verbessert. Falls ihr schon mal nach einen Virtex 4 geschaut habt, der kostet in Eurer Ausführung weit über 500. Ich würde versuchen lieber 2 bis 4 Spartan 3 parallel zu schalten. Dadurch hat man sicherlich eine bessere Performance. Ein Spartan3 mit 400k Gates kostet ca. 25. Man müste allerdings das Board selber machen. Dies ist aber nicht ganz so schwer. Nur leider haben die Spartan 3 keine Extrem DSP Einheiten. Durch die 4 Spartan 3 können dann mal eben 8 DDR2 Speicher angesprochen werden. :-) Grüsse JoeDoe1979
@Michael: "Man müste allerdings das Board selber machen. Dies ist aber nicht ganz so schwer" Ich würde sagen, dafür braucht man mindestens eine 4-lagige Platine. Die macht man ohne Erfahrung nicht mal so eben.
Hallo, keine Sorge, den Mut haste uns noch nich genommen^^ Ich muss ehrlich zugeben, dass ich mich noch nicht über Virtex4 Boards informiet habe, sondern einfach davon ausgegangen bin, dass es welche mit 128bit DDR2 Ram gibt, da ein ein FPGA wie der Virtex4 ja auf sehr hohen "Datendurchsatz" ausgelegt ist.... Die Register gestalten sich nicht als sehr schwierig, da sie aus BRam Blöcken aufgebaut werden. Es werden dafür aber pro CPU mit 12 ALU´s 24 BRam Blöcke benötigt. Da wir aber einen SX35 benutzen wollen, stellt dass kein wirkliches Problem dar, da wir dann immernoch ca. 320 Kbyte BRam für Cache Zweck übrig hätten. Der Cache würde einen mindestens 512bit breiten Datenbus bekommen, der dann in einzelenen VLIW Datenworten in 128bit breiten Registern abgelegt wird. Pro BRam Seite wäre damit ein maximaler Datendurchsatz von 500Mhz*512bit=32Gbyte. Mit dieser Geschwindigkeit könnte aber auf den Speicher geschrieben und aus dem Speicher gelesen werden (sofern es sich um andere Adressen handelt), da es sich um Dual-Port Ram handelt. Ich versuche schon seit 2 Jahren eine CPU zu entwickeln und mir fallen alle paar Tage neue Lösungen ein, wie man sie verbessern könnte, wie du ja schon sagtest^^. Mit C++ simuliert habe ich auch schon einiges und zumindest dort funktionierte es, was ja nicht bedeutet, dass es auch in VHDL funktioniert. Deswegen wollten wir es einfach mal versuchen. Ich schrieb ja auch, dass wir das Bord erst dann kaufen würden, wenn die Simulation funktioniert und einigermaßen unseren Wünschen entspricht. Wenn es nicht wird, dann ist es auch nicht wirklich schlimm, dann haben wir es wenigstens versucht. Die Idee mit dem Wiki-Artikel finde ich auch verdammt gut, mal schauen..... Die Idee mit der "Parallelschaltung" von mehreren Spartan3 FPGA´s finde ich auch ganz lustig. Aber leider würden dort bei weitem keine 4 Spartan 3 reichen und deshalb würde wir mit der Platiene zusamen auch nicht mehr wirklich viel Geld sparen. Die Spartan5 hab ich mir auch schon angeschaut, aber ich glaube kaum, dass die billiger werden, als ihre Vorgänger und wann diese Verfügbar sein werden, sei auch mal dahin gestellt. Aber vielleicht fallen dann ja die Preise für die Virtex4 endlich mal, die meiner Meinung schon deulich überteuert sind, oder meint ihr nicht? MfG Maxe
Nicht nur die Preise sind hoch, sondern auch die Lieferzeiten ;-) Mehrere FPGAs "parallel" zu schalten halte ich auch für keine gute Idee, da müsste man sich einige Gedanken über geeignete Partitionierung des Systems machen und ausserdem begrenzen die I/Os der FPGAs ja dann auch die Interconnection-Busse. Ganz zu schweigen von der höchstmöglichen Taktfrequenz... Ein ähnliches Problem bearbeitet im Moment ein Komilitone von mir in seiner Masterarbeit. Dabei soll versucht werden, beliebige ASIC-Designs, die zu gross für ein einziges FPGA sind, durch dynamische Rekonfiguration "nacheinander" in einem FPGA zu emulieren. Die Gedanken mehrere FPGAs zu verwenden, wurden bereits am Anfang verworfen, weil nicht praktikabel. Ich halte euer Projekt für sehr interessant, obgleich auch für sehr anspruchsvoll. Wenn man genug Zeit und Durchhaltevermögen hat, mag da was gehen :-)
Also wegen Blockram und 500 MHz möchte ich erstmal sehen. Wenn da dazwischen etwas Logik ist, wie Alu und so weiter, dann ist die maximale Frequenz schneller unten, als es einem lieb ist. Ein Board selber zu bauen, braucht ihr gar nicht nachzudenken -- mit 4 Lagen wird da nichts. Eher 10-12, wenn nicht mehr. Die eine Leiterplatte ist dann teuerer als das FPGA. Ein FPGA draufzusetzen sind auch nicht zu verachten -- wenn es schief geht, dann wird es richtig teuer. Und die Tausende von Abschlußwiderstände für DDR2 könnt ihr gleich vergessen - selber bestücken wird da nichts. Also kommt nur ein fertiges Board in Frage. Blos wo nimmt man so eins? Die, die verfügbar sind, sind zu schwach auf der Brust. Alle anderen sind nicht lieferbar (genauso wie bei Virtex 5 -- den kann man eigentlich auch gleich vergessen: jemand, der ein Design mit diesem Chip anfängt ist entweder verrückt, oder hat 1-2 Jahre Vorlaufzeit, bis die Muster da sind... und dann sind es noch Engeneering-Samples, die "im Prinzip" funktionieren, aber auch nicht mehr) Aufteilen in mehrere FPGAs ist auch blöd. An eurer Stelle, würde ich mit etwas anfangen, wo die ersten Erfolge sich schnell einstellen, dann hat man was zum spielen. z.b. wirklich eine simple RISC-Maschine, die Tools kann man schnell portieren. Wenn aber die erste Simulation läuft (und wenn nur so la la), poste hier mal alles :-) Bin gespannt, wie das aussieht Gruß Kest
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.