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.
Angehängte Dateien:
-
VIRTEX.JPG
130 KB
> 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?
:
Bearbeitet durch User
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?
Da ne ref-Card zum selber nachschauen wieviel kilo-bit an Speicher drin stecken: https://www.xilinx.com/support/documentation/selection-guides/7-series-product-selection-guide.pdf und nicht vergessen, für 1 Gbyte braucht es 8*1024*1024 kbit. Bei intel könnte man auch mal schauen ob's da mehr internen Speicher hat: https://www.intel.com/content/www/us/en/products/details/fpga/cyclone/10.html
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.
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.