www.mikrocontroller.net

Forum: FPGA, VHDL & Co. FPGAs gemeinsam konfigurieren


Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte mehrere FPGAs, die alle (fast) dasselbe machen sollen, mit 
einem Programmfile laden. Kann man die faktisch parallel hängen, so das 
der Bitstrom nur einmal gesendet werden muss?

Worauf habe ich zu achten hinsichlich der Confi-Pins / Init_done?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Klaus Klausen (klausi5000)

>Ich möchte mehrere FPGAs, die alle (fast) dasselbe machen sollen, mit
>einem Programmfile laden. Kann man die faktisch parallel hängen, so das
>der Bitstrom nur einmal gesendet werden muss?

Ja.

>Worauf habe ich zu achten hinsichlich der Confi-Pins / Init_done?

Die DONE/INIT kann man parallel hängen, sind standardmässig OpenDrain. 
Wenn eins natürlich einen Fehler meldet, kann man allerdings nicht 
erkenn welches das ist. Im Normallfall einfach alle nochmal resetten und 
neu laden. Während der Entwiclkung können kleine Längswiderstände 
nützlich sein, da kann man messen, welches FPGA INIT auf LOW zieht.

MFG
Falk

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt drauf an, woher der Bitstrom kommen soll und über welchen Bus.
Wenn das ein SPI EEPROM ist, dann ist der FPGA der Master und damit 
funktioniert das Parallelschalten nicht.
Evtl. könnte da ein externer uC helfen, der als Master das in die FPGAs 
reinschiebt. Ich hab allerdings zu wenig mit den Teilen gemacht um da 
100% sicher zu sein. Wir haben hier einen FPGA der über einen Treiber im 
Linux sein Programm (Bitstrom) geladen bekommt. Weiß allerdings nicht 
über welche Schnittstelle das läuft.

Was sagt das Datenblatt dazu?

Autor: lkmiller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Kann man die faktisch parallel hängen, so das
> der Bitstrom nur einmal gesendet werden muss?
Gilt für Xilinx:
wenn du den Slave-Modus verwendest, dürfte das gehen. Nur brauchst du 
dann einen Controller (z.B. uC), der den Bitstrom aktiv lädt. Ich 
jedenfalls habe da eine "Bitstrom-Quelle" programmiert, die ein FPGA 
über einen uC aus einem CF lädt, irgendwelche Rückleitungen wurden nicht 
verwendet (INIT_DONE). Da könnten also ohne weiteres noch andere FPGAs 
mit parallelgeschaltet werden.

Theoretisch könnte es sogar funktionieren, ein FPGA als Master 
(Config-Takt) zu verwenden, und andere FPGAs als Slave an den Bitstrom 
mit dran zu hängen...
Allerdings hört sich das arg nach Murks an.

Die übliche Vorgehensweise ist, alle FPGAs in einer Kette hintereinander 
zu laden. Dazu muss das Prom allerdings mehrmals denselben Bitstrom 
ausgeben, und dieser (gleiche) Bitstrom also mehrmals hintereinander 
darin gespeichert sein  :(

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@lkmiller (Gast)

>Theoretisch könnte es sogar funktionieren, ein FPGA als Master
>(Config-Takt) zu verwenden, und andere FPGAs als Slave an den Bitstrom
>mit dran zu hängen...
>Allerdings hört sich das arg nach Murks an.

Nein, das passt. Die FPGAs synchronisieren auf ein Startmuster im 
Datenstrom. Dann ist es nur noch billiges Bitklimpern.

>ausgeben, und dieser (gleiche) Bitstrom also mehrmals hintereinander
>darin gespeichert sein  :(

Was realtiv sinnfrei ist.

MFg
Fakl

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
>>Theoretisch könnte es sogar funktionieren, ein FPGA als Master
>>(Config-Takt) zu verwenden, und andere FPGAs als Slave an den Bitstrom
>>mit dran zu hängen...
>>Allerdings hört sich das arg nach Murks an.
> Nein, das passt.
Hast du das real schon gemacht?


> Die FPGAs synchronisieren auf ein Startmuster im Datenstrom.
Das mit dem Startmuster kenne ich schon. Ich habe in die Bitstrom-Datei 
einfach eine Versionskennung und das Datum mit eingefügt (am Dateianfang 
als ASCII mit Ctrl-Z). Die wird einfach mitübertragen. Null Problem :-)


>>...dieser (gleiche) Bitstrom also mehrmals hintereinander
>>darin gespeichert sein.
> Was realtiv sinnfrei ist.
Bis mal eines der FPGAs ein klein wenig was anderes tun soll...


> Fakl
Echt?    ;-)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Lothar Miller (lkmiller)

>> Nein, das passt.
>Hast du das real schon gemacht?

Nein.

>Bis mal eines der FPGAs ein klein wenig was anderes tun soll...

Das ist dann nicht mein Problem ;-)

MFG
Falk, diesmal ohne Wechstabenverbuchselung

Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, falls das noch jemand liest: Ich habe das damals nicht hinbekommen. 
Ein Microcontroller lädt die FPGAs nun nach und nach.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, woran lags denn? Ich hab sowas in der Art demnächst auch vor:
16 Artix 7 sollen den gleichen Bitstream erhalten. Ich dachte, ich 
verwende den Slave Serial Modus, und konfiguriere die von einem Master 
aus (ein 17. FPGA, der auch drauf ist und aus einem Parallel Flash wegen 
Multiboot/Fallback gebootet wird) alle in einer Kette, denn laut den 
Datenblättern kann man den Slave Serial Modus nehmen um Daisy Chains 
aufzubauen, an DOUT kommt angeblich der Bitstream nach 64 CCLK Zyklen 
wieder raus. Hat das mal jemand probiert? Was macht eigentlich das FPGA, 
wenn die Konfig durch ist, aber trotzdem noch Daten durschgeschoben 
werden?  Oder doch lieber 16 mal das DIN parallel schalten?

Autor: hunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im UG191 ist das Serial Daisy Chaning für Virtex-5 mit Beispiel auf 
Seite 41 beschrieben. Ich nehme an für Artix gibts auch einen 
Configuration UG mit entsprechenden Beispielen.
Die 2. Variante ist Ganged Serial mit einem Master. Die DINs der slaves 
hängen dann alle parallel.
Dabei wird der fanout dann aber relevant, insbesondere bei 16 Stück. 
D.h. dann werden wohl Buffer für Takt+Daten nötig und evtl. Terminierung 
am Ende. Bei daisy-chained slave serial ist das auch für den Takt zu 
berücksichtigen.

Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> Was macht eigentlich das FPGA,
> wenn die Konfig durch ist, aber trotzdem noch Daten durschgeschoben
> werden?  Oder doch lieber 16 mal das DIN parallel schalten?

Wenn man die Configleitungen richtig beschaltet, müsste der da passiv 
bleiben, d.h weitere Daten ignorieren. Eigentlich sollte das aber nicht 
vorkommen, wenn sie richtig verkoppelt sind.

Wie hunz schreibt, sind buffer bei den Taktleitungen Pflicht. Und nicht 
erst ab 16, besonders, bei hohen Datenraten.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist ja schon seit über 3 Jahren geklärt, läuft auch seit 
einiger Zeit prima. Im Moment mit 16MHz fehlerfrei, immer 4 Slaves an 
einem Buffer für Takt und Daten. Mit einem richtigen 16er Clock Buffer 
ist sicher noch mehr drin. Aus Kostengründen haben wir es zunächst dabei 
belassen.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Bis mal eines der FPGAs ein klein wenig was anderes tun soll...
Dann kann man ein paar Pins mit bzw. ohne Jumpern belegen und diese in 
der Logik auswerten. BTDT :)

Duke

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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