BRAMs packen (lassen) - wie konfigurieren / instaziieren?

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

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.

Gut, je nach Entfernung könnte man da ja auch LVDS verwenden und das 
dann nahe am jeweiligen Ziel wieder nach CMOS übersetzen.