Ich habe zwecks DDR-Anbindung 2 Optionen:
1) Anbindung mit 166MHz (halbe maximale Systemfrequenz im FPGA) und
damit sehr bequemen Taktverhältnissen einerseits, und ...
2) Anbindung von vollen 200 MHz, wie in der Systemspec, allerdings dann
mit clockbridges.
Ich habe mir überlegt, dass ich infolge des clock domain crossings und
der Eintakterei immer Verluste bekomme und ohnehin nicht die volle
Bandbreite von 200 MHz werde nutzen können - damit also kaum besser
fahre, als wenn ich auf die 33/200 verzichte.
Frage 1: Ist das so? Oder bekommt man da mit Gefummel noch mehr hin?
Frage 2: Spricht etwas gegen das Untertakten des Speichers?
Müsste ich das bei der Synthese / Core Gen (MIG) berücksichtigen oder
läuft die Anordnung physikalisch auch, wenn ich einfach mit 200MHz baue
und dann die FRequenz nicht so hoch einstelle?
Hast du jemals DDR Ram in Betrieb genommen?
Wenn es nicht gerade ein Evalboard ist bei dem alles von vornherein
funktioniert wäre ich vorsichtig bei dieser Geschichte, trivial ist das
auf custom boards mitnichten. Den MIG würde ich deshalb immer so bauen
wie auch die hardware arbeiten soll. Man kann schon froh sein wenn das
überhaupt funktioniert.
Verstehe auch die Begründung nicht:
JBB schrieb:> 1) Anbindung mit 166MHz (halbe maximale Systemfrequenz im FPGA) und> damit sehr bequemen Taktverhältnissen einerseits, und ...>> 2) Anbindung von vollen 200 MHz, wie in der Systemspec, allerdings dann> mit clockbridges.>> Ich habe mir überlegt, dass ich infolge des clock domain crossings und> der Eintakterei immer Verluste bekomme und ohnehin nicht die volle> Bandbreite von 200 MHz werde nutzen können - damit also kaum besser> fahre, als wenn ich auf die 33/200 verzichte.
Genau das Gegenteil ist der Fall: eben dadurch das ein bestimmter Teil
der Bruttodatenrate entfällt (refresh!), lohnt es sich über der
angepeilten Datenrate zu arbeiten.
Das kommt aber auch auf die Anforderungen an.
clock domain crossings oder eintakten (macht doch eh der MIG core...)
kosten übrigens keine Bandbreite sondern sorgen lediglich für Latenz.
Mit der Datenrate habe ich eigentlich keine Probleme, weil ich nur etwa
30%-50% auslasten muss, um meine APP zu schaffen. Mit Standard SRAM wird
es ein wenig happig. Ich frage mich nur, ob ich unbedingt für das RAM
noch einen Takt bauen muss.
> clock domain crossings oder eintakten kosten übrigens keine Bandbreite
Ok, "Durchsatz" war gfs nicht richtig formuliert. Ich meinte, wenn ich
mit 2 verschiedenen Takten arbeite kommt es doch zwangläufig zu
Aussetzen bei der Annahme der Daten, ergo braucht man ein asynch-FIFO,
ergo deutlich mehr Latenz. Wenn ich Daten rein und wieder rausbekommen
will, kostet es mehr Zeit.
Du brauchst eh nen extra Takt(bzw sogar zwei) für den MIG Core, der
eigens von diesem "verwaltet" wird mittels MMCMs.
(gehe mal davon aus du willst Xilinx nutzen, da du von MIG sprichst)
Da ist dann so oder so nix mit synchron, selbst wenn du beide mit der
gleichen Taktrate betreibst.
Probiers mal aus einen Takt in einen MIG core zu füttern und
gleichzeitig für andere Logik zu verwendet -> geht nicht, weil der MIG
clockbuffer im inneren hat.
Kann man zwar entfernen, geht aber regelmäßig in die Hose. Xilinx sagt
dazu in etwa "It can work, but it is not intended or recommended"
(Webcase Antwort)
Andersrum gehts schon, also den DDR clock hinterher weiterzuverwenden,
dann aber nur genau den Takt, durch ne MMCM kann der nicht mehr.
Wenn dein System vollsynchron läuft wäre das denkbar.
Ich halte es jedoch für keine gute Designpraxis sich das gesamte FPGA
vom angeschlossenen Speicher diktieren zu lassen.
JBB schrieb:> Mit der Datenrate habe ich eigentlich keine Probleme, weil ich nur etwa> 30%-50% auslasten muss, um meine APP zu schaffen. Mit Standard SRAM wird> es ein wenig happig
DDR Ram würde ich nur nehmen wenn es die Kosten erzwingen oder man die
Größe braucht. Ein breites Sram ist in den meisten anderen Punkten
überlegen. Besonders wo es dir um Latenz geht.
SRAM gibts z.b. auch als 72Bit * 250 MHz, eventuell noch schneller.
...ausserdem muss man beim Einsatz von SDRAM berücksichtigen, wie die
Daten gebraucht werden: Schnell wird es nur, wenn man Bursts verwenden
kann. Sonst killt der Overhead zum Aufsetzten der Zugriffe schnell die
Performance. Denkt man nicht zwingend daran, v.a. wenn vorher ein SRAM
im Design war, wo's derlei "Strafzeiten" (CAS latency...) nicht gibt.
Stefan Wimmer schrieb:> Strafzeiten
Strafzeiten klingt gut. Das DDR-gedöhns ist nur wegen der
Computertechnik eingeführt worden, weil man's billig braucht. Mit FPGAs
kann man solche high speed Anforderungen anders lösen.
>der MIG braucht den Takt
Ich weiss jetzt nicht genau, was der Xilinx Core kann, weil ich selber
kein Xilinx mehr verwenden möchte und glücklicherweise, Dank
Chefenscheid von ganz oben, auch nicht mehr verwenden darf / muss.
Aber ich denke, der MIG-Core braucht den Takt deshalb, weil er die
Delays passend einstellen muss -> Eye Pattern Optimization. Oder muss
man das beim Xilinx auch per Hand machen?
Genau das meine ich, dafür braucht er 2 Takte. Einen für die Delays und
einen für die interne Logik.
Letzteren kann man weiterverwenden hinterher, aber ob das so sinnvoll
ist...
Dagobert schrieb:> Wie hoch ist der maximale Datendurchsatz bei wahlfreiem> Zugriff?
Definiere "wahlfrei".
DDR RAM ist auf modernen PCs nur deswegen halbwegs flott, weil der
Zugriff eben nicht "wahlfrei" erfolgt. Durch die (teilweise riesigen)
Prozessorcaches wird immer (mindestens) eine komplette Cacheline auf
einmal gelesen oder geschrieben, auf die RAMs kann im Burst zugegriffen
werden.
Wenn "wahlfrei" im worst case bedeutet, dass Du von den 8x64 Bit, die
vom RAM auf einen Hieb kommen, immer nur ein Byte brauchst und Du danach
jedes Mal (z.B.) 4-4-4 warten mußt, bis Du das nächste Byte holen
kannst, weil es auf einer anderen Bank liegt und vielleicht auch noch
ein Precharge Zyklus dazwischen kommt, wird's richtig langsam und von
den nominell 25 GB/s bleibt nur ein minimaler Bruchteil.
