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.
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.
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.
