mikrocontroller.net

Forum: FPGA, VHDL & Co. ExtremeDSP


Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: nimbus4 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: nimbus4 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.?

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.