ich möchte eine private Applikation mit einem UC, welcher ein altes
DDR-RAM verwendet auf einen FPGA umsetzen, der kein DDR-RAM verwenden
soll.
Es existiert eine Zwischenstufe einer Core-Netzliste, die den UC und den
DDR-Controller sowie weitere Peripherie wrapped. Diese Netzliste habe
ich als IP, darf sie privat kostenlos einsetzen, kriege aber keine
Sourcen.
Ich möchte daher ein BRAM wrappen und es als DDR2-Controller zur
Verfügung stellen. Das DDR-RAM arbeitet auf 133MHz, der FPGA kann
300MHz, sollte meines Wissens also gehen.
Jemand eine Idee, wie man das hinbekommt? Könnte man Modelle
synthesefähig bekommen (oder machen)?
Baschtler schrieb:> Könnte man Modelle> synthesefähig bekommen (oder machen)?
Die Modelle, die ich kenne (frei verfügbar) eher nicht, da dort viel
Timing-Kram drinsteht und nur die geschriebenen Speicherzellen simuliert
werden.
Aber prinzipiell kann das gehen, wird aber Arbeit.
Alternativ kannst Du evtl. einen echten DRAM an das FPGA dranhängen.
Dann ist zumindest die Speichergröße kein Punkt mehr.
Duke
Echtes DRAM wird nicht gehen, da HW bereits vorliegt. Es ist ein
SOPC-System mit SoftCORE. Ich habe nur Block-RAM.
Soweit ich mich mit dem Speicher auskenne, müsste man die DQS decodieren
und eine der ADR-Leitungen um die ADR zu generieren. (habe das nie
richtig kapiert, wie das geht).
Ausserdem muss ich eine Art done für das Eintrainieren der Leitungen
liefern.
Immerhin brauche ich keinen refresh :-)
Sieht jemand andere Falstricke?
Baschtler schrieb:> Jemand eine Idee, wie man das hinbekommt? Könnte man Modelle> synthesefähig bekommen (oder machen)?
Mit den offen rumliegenden ueblichen Verdaechtigen nur so: von Hand
emulieren. Das wird aufwendig, aber mit DDR2 ev. grade noch knapp
machbar, haengt von deinem FPGA ab. Eine Aussage zu den Frequenzen
laesst sich so nicht einfach machen.
Riecht aber nach spassiger Fehlersuche, wenn es Timing-Probleme gibt
(die Chancen stehen hoch). Und (Co-)Simulation von closed-source gegen
ein Emulations-Modell hat bei manchen Herstellern auch Tuecken.
Mehr Sinn ('wirtschaftlich') wuerde es machen, unliebsame Komponenten
aus der Netzliste zu entfernen, wenn unverschluesselt.
> Ich habe nur Block-RAM.> Sieht jemand andere Falstricke?
Ja wieviel hast du denn davon?
Vielleicht solltest du mal die Preisliste konsultieren,
die die BRAM-Groesse den $$$ gegenueberstellt.
Wenn du nicht gerade ein Board bei E.ay "geschossen" hast,
wo z.B. einer oder mehrere XC4VLX200 drauf sitzen,
wird das hinten und vorne nicht reichen.
Von wieviel DDR2 RAM reden wir eigentlich? Eine mickrige APP braucht
u.U. nicht viel, das kann schon passen (habe schon
Microblaze-Anwendungen komplett im RAM laufen lassen). Ich nehme aber
an, du hast das gecheckt?
Es gibt einen Emulator, der DDR-RAM in SRAM Zugriffe übersetzt. Da
hängen BRAM als Caches / Command-FIFO davor. Sowas würde ich hernehmen.
S.B.Z.ettler schrieb:> Wenn du nicht gerade ein Board bei E.ay "geschossen" hast,> wo z.B. einer oder mehrere XC4VLX200 drauf sitzen,> wird das hinten und vorne nicht reichen.
Ich würde mal behaupten, solche Virtix Boards haben stehts etliche 100MB
an RAM, die man dann gleich nutzen könnte.
Wie soll man den DDR FPGA intern emulieren? Sitzen die DDR-fähigen
Register nicht nur in den I/Os?
Nachfrage:
Du hast also Netzlisten und keinen Code. Hast du getrennt
UC und DDR Controller?
Oder anders gefragt:
Kommst du an das Interface zwischen uC und DDR Controller ran?
Dann müsstest du nämlich keinen DDR RAM emulieren, sondern es würde
reichen einen RAM Controller für oder mit BRAM zu schreiben der das
gleiche Interface hat wie aktuell der DDR Controller.
Das stelle ich mir deutlich einfacher vor.
Mampf F. schrieb:> Wie soll man den DDR FPGA intern emulieren? Sitzen die DDR-fähigen> Register nicht nur in den I/Os?
DDR braucht man nur, wenn man den doppelten Takt nicht selber hinbekommt
und genau das will der TE ja tun.
Die Frage ist, wie die DDR-Funktion real ausgeführt ist. Man darf
annehmen, dass es einfach ein entsprechend hoher Takt auf den
Datenleitungen ist. Es ist ja nur ein DDR2. Das gleiche hat man im
Übrigen bei GDDRx in Grafik-Chips. Alles Faktor 2!
> solche Virtix Boards haben stehts etliche 100MB an RAM
Aber:
> Ich möchte daher ein BRAM wrappen
XC4VLX200
Block-RAM: 6048 Kilobit + 1392 Kilobit Distributed RAM
Dann schau auch mal nach den Preisen. Aber vorher hinsetzen.
Klingt fuer mich insgesamt eher nach Hirnfurz.
S.B.Z.ettler schrieb:> Klingt fuer mich insgesamt eher nach Hirnfurz.
Exakt. Da hat mittlerweile selbst das obere Ende der Einsteigerklasse
(Artix7) mehr BRAM.
Dickster Spartan7 (92 € bei Mouser):
4320 + 1100 kBit
Dickster Artix7 (164 € bei Mouser):
13140 + 2888 kBit
Außerdem ist Baustein ist schon etwas alt und bietet dadurch weniger
andere nette Features. Bei dem DSPs sind das 96 XC4VLX200, 160 XC7S100,
740 XC7A200. Und von der aktuellen Entwicklungsumgebung Vivado wird der
auch nicht unterstützt.
Gustl B. schrieb:> S.B.Z.ettler schrieb:>> Klingt fuer mich insgesamt eher nach Hirnfurz.>> Exakt. Da hat mittlerweile selbst das obere Ende der Einsteigerklasse> (Artix7) mehr BRAM.
Mehr, als ein DDR-Baustein? Die haben GB. FPGAs kaum einige MB. Faktor
1000 übersehen?
Tja man sollte nicht nur den letzten Post lesen. Der bezog sich auf den
Virtex4 der hier empfohlen wurde. Hoher Preis, nicht von Vivado
unterstützt und relativ wenig BRAM im Vergleich zu neueren günstigeren
FPGAs.
Es wurde natürlich nicht behauptet, ein FPGA hätte so viel BRAM wie ein
DRAM Baustein.
Baschtler schrieb:> Ausserdem muss ich eine Art done für das Eintrainieren der Leitungen> liefern.
Bei DDR wird nichts groß trainiert, bei BRAM garnicht. Hauptaufgabe ist
CAS und RAS zu einer linearen BRAM Adresse zusammenzusetzen und bei
Burst Zugriffen, brav zu unkrementieren.
Die 2-Flankensteuerung bei DDR musste wohl mit doppelten BRAM-Takt oder
mit 2-BRAM-Hälften in unterschiedlichen Taktdomainen mit 180°
Phasenversatz emulieren. Wobei die Frage ist, ob in der ominösen, nicht
änderbaren, Netzliste IO-FF oder Fab-FF Prims instanziert sind.
Aber vorher solltest du klar ansagen, wieviel DDR-RAM du minimal
emulieren musst. Wenn es mehr als die paar Mbyte an BRAM sind, die ein
FPGA mitbringt, kannst du gleich aufhören.
Wieviel Speicher braucht den 'dein' Mikrocontroller minimal? Was soll da
drauf laufen? Nur ein bisserl Endloschleife oder ein gut mit sich selbst
beschäftigtes OS?
Und isses nun DDR oder DDR2?
Baschtler schrieb:> Soweit ich mich mit dem Speicher auskenne, müsste man die DQS decodieren> und eine der ADR-Leitungen um die ADR zu generieren. (habe das nie> richtig kapiert, wie das geht).
Die Frage ist doch, an welcher Stelle das Block-RAM ins Spiel kommen
soll- vor oder nach dem DDR-Controller?
Baschtler schrieb:> Es existiert eine Zwischenstufe einer Core-Netzliste, die den UC und den> DDR-Controller sowie weitere Peripherie wrapped.
Wenn aus dieser Netzliste ein low-level DDR-RAM-Timing heraus kommt,
muss der konkrete Baustein nachgebildet werden, zumindest, was dessen
RAS/CAS Verhalten angeht.
Fpgakuechle K. schrieb:> Hauptaufgabe ist> CAS und RAS zu einer linearen BRAM Adresse zusammenzusetzen
Das sollte noch hinzubekommen sein, aber wenn eine Anwendung ein
externes RAM benutzt, ist das meist ein Großes. Das gibt garantiert ein
Platzproblem. Vom reinen Timing her sind Block-RAMs super schnell.
Jürgen S. schrieb:> Baschtler schrieb:>> Soweit ich mich mit dem Speicher auskenne, müsste man die DQS decodieren>> und eine der ADR-Leitungen um die ADR zu generieren. (habe das nie>> richtig kapiert, wie das geht).> Die Frage ist doch, an welcher Stelle das Block-RAM ins Spiel kommen> soll- vor oder nach dem DDR-Controller?
Ich geh davon aus, das der TO den DDR-Speicher nach dem Controller
ersetzen will und deshalh eine Art Bridge DDR-IO - BRAM einschiebt. Die
anderen Stellen sind ihm wohl verwehrt, weil der CPU-Core und
DDR-Speicher-controller nur als feste Netzliste vorliegt.
Bei den DQS (Data-Strobe) sollte er mal nachforschen, ob er diese
überhaupt braucht und vorliegen hat.
Das ist ein Feature der IO-Pads des FPGA das nicht bei allen DDR
Revisionen vorkommt und nicht bei jeder Betriebsart (read oder write)
oder Geschwindigkeitsklasse nötig ist. Man kann den DDR-Datenbus auch
komplett über den Takt CLK 'timen', DQS ist gut um Schwankungen auf den
PCB-Tracks zu kompensieren. wird also unnötig , wenn das Interface
komplett intern ist. DQS (mit einstellbaren IO-delay) ist wie DDR-FF ein
feature der IO-Pads, das bei internen FF nachgestellt werden müßte.
