In einer speziellen Anwendung schreibt ein Controller sehr viele Daten an unterschiedliche Empfänger heraus. Um die zu speichern und das langsame das Senden / Empfangen sicherzustellen, wird ein FPGA genutzt, der alle Daten im Block-RAM spiegelt und puffert. Rein kommen z.B. Daten mit 200MHz x 16Bit bei 5 wait states, heraus 100kHz I2C. Es werden also viele buffer vollgeschrieben, werden der erste Satz noch am Senden ist. (Würde der Controller das machen, müsste er warten) Es sind insgesamt 128 Empfänger, die mit momentan 50-80 Werten parametriert werden, also habe ich 96 Plätze vorgesehen. Jeder Platz hat 16 .. 32 Bit. Die RAM-Bits belaufen sich auf 300.000 und sollten bei BRAM16 etwa 18 RAMs belegen. Leider kriegt der das nicht zusammengepackt. Schon bei 70 Werten werden über 20 RAMs verbraten, obwohl die meisten nur 16 Bit haben. Wie organisiert man das, dass es es besser hinbekommt? Muss ich die per Hand zu 16k - Paketen zusammenflechten?
Die Frage lässt alle Details vermissen. Z.B. den FPGA. > Jeder Platz hat 16 .. 32 Bit. Was denn nun? So werden es wohl immer 32(36) Bit. Das steht doch alles im Synthesereport! Wenn die Werte unterschiedliche Wortbreiten haben, wirst du das wohl pfiffiger angehen müssen.
Ich würde mir angucken wie oft gleichzeitig, also in genau einen Takt, von verschiedenen Adressen gelesen oder in diese geschrieben werden muss. Ein BRAM hat maximal zwei Anschlüsse. Wenn du also in einem Takt 70 mal liest, dann braucht es dafür mindestens 35 BRAMs. Aber so ganz verstanden habe ich nicht was du vor hast. Was sind das für Empfänger? 128 mal 100kHz I2C? Das ist keine hohe Datenrate und vielleicht kann man das mit einem Leseport schaffen.
:
Bearbeitet durch User
Markus W. schrieb: > Wie organisiert man das, dass es es besser hinbekommt? FIFO, sowas generiert dir der Core-generator mit links und entscheidet selber ob er Block-RAM, distributed ram oder SRL-32 Makros dafür benutzt.
Gustl B. schrieb: > Was sind das für > Empfänger? Sensoren, I2C-EEPROM, EEPROM in den Sensoren und Aktoren die über I2C-Schieberegister geführt sind. Aus EMV-Gründen alles mit langsamem Takt. > 128 mal 100kHz I2C? 32 Platinen mit je 4 Bausteinen. Die sind von einander unabhängig und sollen auch parallel beschrieben werden können. >velleicht kann man das mit einem Leseport schaffen. Geht nicht, da sonst alles sequentiell liefe. Der FPGA soll das selber tun und puffern. Er muss z.B. lesen und auch Daten bereitstellen, um sicherzustellen, dass sie auch drin stehen. Das ist nämlich das Problem bei dieser Anwendung. Störungen machen mitunter die Daten kaputt. Aus Sicherheitsgründen hat jeder I2C-Teilnehmer einen eigenen Bus. Offen ist noch, ob es einen 4:1 MUX geben wird, sodass der FPGA nur 32 Master braucht. Trotzdem braucht er für alle seine Speicherplätze. FIFO reicht nicht.
Markus W. schrieb: > Geht nicht, da sonst alles sequentiell liefe. Ja? Wo ist das Problem? Die einzelnen I2C Geräte bekommen schön der Reihe nach Daten. Also eher die vielen I2S Komponenten im FPGA. Wenn einer wieder alles übertragen hat meldet er sich und bekommt neue Daten aus dem BRAM. Und während der die rausschiebt werden die anderen bedient, Markus W. schrieb: > Die sind von einander unabhängig und > sollen auch parallel beschrieben werden können. Was bedeutet parallel? Genau zeitgleich? Oder reicht es in einem Takt dem einen I2S Modul einen neuen Wert zu geben und im nächsten Takt dem nächsten Modul. Das wären dann wenige ns Verzögerung. Du könntest auch zwischen den großen BRAM und die vielen I2C Komponenten jeweils einen klenen FIFO stecken. Daraus lesen die I2S Komponenten und auf der anderen Seite werden Daten reingekippt.
Klingt viel zu verkompliziert. Bei so lahmen Speeds wuerde ich das einen Softcore machen lassen anstatt zig kleine Ram-Blöcke zu instanzieren. Den Rest der Datenverteilung macht man per DMA-Queue. Zuviele fragmentierte RAMs an einen Bus anzubinden sorgt schnell mal für Logikverstopfung.
Markus W. schrieb: > Er muss z.B. lesen und auch Daten bereitstellen, um > sicherzustellen, dass sie auch drin stehen. Das ist nämlich das Problem > bei dieser Anwendung. Störungen machen mitunter die Daten kaputt. Dann würde ich mal ein paar Schritte zurück und in Frage stellen, ob I2C für diese Anwendung richtig ist. SPI ist z. B. viel robuster als I2C weil es Push-pull Treiber einsetzt anstatt Open-Drain. Wenn es noch robuster sein muss, kommt man nicht um differenzielle Systeme wie LVDS oder RS485 drum herum. In custom Lösungen lässt sich z. B. SPI auch über LVDS oder RS485 Leituntstreiber betreiben (Habe gerade solche Motorencoder auf dem Tisch). Je nach dem was diese 4 I2C Chips so tun, könnte das auch ein einzelner Mikrocontroller übernehmen, der dann per UART und RS485 Treiber mit deinem FPGA (Dein Datenkonzentrator) redet) ohne dass das teurer wird.
Es sind nicht nur 4 i2c chips, hatte er doch geschrieben ...
Gustl B. schrieb: > Es sind nicht nur 4 i2c chips, hatte er doch geschrieben ... Markus W. schrieb: >> 128 mal 100kHz I2C? > 32 Platinen mit je 4 Bausteinen. Die sind von einander unabhängig und > sollen auch parallel beschrieben werden können. Was ich eigentlich gemeint habe ist, dass System mal durchzurechnen, wenn auf jeder der 32 Platinen ein Mikrocontroller sitzt.
Christoph Z. schrieb: >> 32 Platinen mit je 4 Bausteinen. Die sind von einander unabhängig und >> sollen auch parallel beschrieben werden können. > > Was ich eigentlich gemeint habe ist, dass System mal durchzurechnen, > wenn auf jeder der 32 Platinen ein Mikrocontroller sitzt. Nein, dort sitzen nur die Empfänger. Christoph Z. schrieb: > Dann würde ich mal ein paar Schritte zurück und in Frage stellen, ob I2C > für diese Anwendung richtig ist Gute Frage! Leider nicht mehr änderbar. Die meisten Sensoren können auch nur I2C.
Gut, je nach Entfernung könnte man da ja auch LVDS verwenden und das dann nahe am jeweiligen Ziel wieder nach CMOS übersetzen.
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.