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
So, falls das noch jemand liest: Ich habe das damals nicht hinbekommen. Ein Microcontroller lädt die FPGAs nun nach und nach.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.