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?
@ 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
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?
> 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 :(
@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
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? ;-)
@ 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
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?
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.
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.
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.
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