www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Maximalfrequenz eines Spartan 3


Autor: OliverKroll (Gast)
Datum:

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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

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

Autor: OliverKroll (Gast)
Datum:

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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

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

Autor: OliverKroll (Gast)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: OliverKroll (Gast)
Datum:

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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: Iulius (Gast)
Datum:

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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: berndl (Gast)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: ?? (Gast)
Datum:

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

Autor: Iulius (Gast)
Datum:

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

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.

Autor: Falk Brunner (falk)
Datum:

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

Autor: Iulius (Gast)
Datum:

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

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.