mikrocontroller.net

Forum: FPGA, VHDL & Co. BRAMs packen (lassen) - wie konfigurieren / instaziieren?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Markus W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von pumuggl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gustl B. (gustl_b)


Bewertung
0 lesenswert
nicht lesenswert
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
von Volker U. (Firma: Ingenieurbüro Volker Urban) (ib-volker-urban)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gustl B. (gustl_b)


Bewertung
0 lesenswert
nicht lesenswert
Es sind nicht nur 4 i2c chips, hatte er doch geschrieben ...

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gustl B. (-gb-)


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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.