Anwendungâš“
Volle Ausgabegeschwindigkeit (Xilinx-FPGA konfigurieren)âš“
Das GPIF wird zum Großteil zur Kommunikation mit CPLD oder FPGA gebraucht. Clever ist es dabei, die Busverdrahtung so zu gestalten, dass die Konfiguration großer RAM-basierter FPGA ebenfalls über dieselbe Verbindung läuft. Damit spart man sich den Konfigurations-PROM und erleichtert sich das Configware-Update, weil dazu einfach nur eine Treiberdatei ausgetauscht werden muss.Das folgende Bild zeigt außerdem die Möglichkeit, auch die 8051-Firmware per USB laden zu lassen. Packt man alles in eine Treiberdatei (.SYS), ist ein komplettes Software-Update sehr einfach. Ein derartiges Gerät startet in mehreren Phasen:
- Anstecken: Windows lädt Treiber anhand VID und PID
- Treiber schiebt Firmware in den Mikrocontroller
- Mikrocontroller-Firmware startet, re-numeriert (nur bei Änderung der Default-Konfiguration erforderlich, Windows lädt Treiber noch einmal)
- Treiber schiebt Configware via Mikrocontroller in den FPGA und startet diese
- Normaler Betrieb
![[Ăśbersichtsschaltplan]](gpif.gif)
Ein RAM-Pufferspeicher wird fast immer benötigt, wenn bei hoher USB-Datenrate Unterbrechungen im 100-ms-Bereich überbrückt werden sollen; der FPGA-interne RAM ist dafür viel zu klein oder zu teuer. Für den Mikrocontroller genügt fast immer der kleine 56-polige Gehäusetyp.
Zur Konfiguration eines Virtex-FPGA mit der Methode Slave SelectMAP benötigt man folgende Verbindungen, die man auch im nachhinein (also wenn FPGA im regulären Betrieb) als schnelle Übertragungsstrecke nutzen kann:
| Cypress CY7C68013A | Xilinx Virtex II |
|---|---|
| IFCLK | CCLK Dedizierter Konfigurationsanschluss |
| PB0..7 | D7..0 Bits stĂĽrzen! Wirklich! Bei Virtex ist D0 das MSB! Wird oft ĂĽberlesen. |
| CTL0 | CS_B |
| CTL1 | RDWR_B |
| RDY0 | BUSY Wird nur bei komprimierten oder verschlĂĽsselten Konfigurationsdaten gebraucht. Beim Virtex4 ausschlieĂźlich zum RĂĽcklesen |
| PA2 oder irgendein Ausgabepin | PROG_B Dedizierter Konfigurationsanschluss |
| PA3 oder irgendein Ein/Ausgabepin | DONE Dedizierter Konfigurationsanschluss |
| PA4 oder irgendein Eingabepin | INIT_B Nicht unbedingt nötig, siehe Text |
Hintergrund: Der Konfigurationsdatenstrom *.RBT, *.BIT enthält am Ende einige überflüssige Bits bzw. Bytes, um den Startup auszulösen. Diese könnten, wenn der FPGA das DONE-Pin freigibt, »in den falschen Hals« gelangen.
INIT_B wird nur benötigt, um:
- das FPGA-Löschen definiert abzuwarten,
- einen CRC-Fehler beim Konfigurieren zu detektieren.
GPIF-Designer:
Für „volles Rohr“ benötigt man im GPIF-Designer tatsächlich drei Zustände:// GPIF Waveform 1: FIFOWr // // Interval 0 1 2 ... Idle (7) // _________ _________ _________ _________ _________ // // AddrMode Same Val Same Val Same Val // DataMode Activate Activate NO Data // NextData SameData NextData NextData // Int Trig No Int No Int No Int // IF/Wait IF IF IF // Term A EF+1 EF+1 (egal) // LFunc AND AND AND // Term B EF+1 EF+1 (egal) // Branch1 Then 2 Then 2 ThenIdle // Branch0 Else 1 Else 1 ElseIdle // Re-Exec No Yes No // Sngl/CRC Default Default Default // CS_B 0 0 1 // RDWR_B 0 0 1Die Einstellung „NextData“ führt zu Beginn des Zustandes zum Lese-Takt und damit zum Datenwechsel. Mit geringer GPIF-Taktverzögerung, sofern der FX2 die Taktquelle ist.
C-Programm:
Wichtig ist, dass man das Empty-Flag 1 Byte frĂĽher braucht!Man braucht kein SyncDelay bei 48 MHz, weil nur 3 Takte Wartezeit erforderlich sind und der C-Compiler genĂĽgend (unsinnige) Befehle einstreut.EPxGpifFlgSel= 1 // Anhalten bei Empty-Flag, nicht bei TerminalCountEPxFifoCfg= 0x20 // Handarbeit, 8 bit, OEP1 (Empty-Flag 1 Byte frĂĽher)
Wichtig (Die verflixte Null): Das GPIF darf nicht aktiviert werden, wenn Null Bytes in den Ausgabepuffern stehen! Die Zustandsmaschine würde ein ungültiges Byte zum FPGA schaffen.Im Experiment war es egal, ob IFCLK (Interface-Takt) negiert oder nicht-negiert betrieben wurde (Virtex-II, 48 MHz).Bei nur einem Byte läuft die Zustandsmaschine direkt von Zustand 0 (= Fall-Through-Byte zum FPGA schicken) zum Zustand 2 (= FIFO leer lesen, aber FPGA laden beenden [CS_B=1]). Notfalls kann man sich darauf verlassen, dass der (Windows-)Host kein Null-Byte-Paket schickt.
Ob Bytes im Puffer vorhanden sind, kann nicht mittels EPxCS, EPxFifoFlags oder EPxFifoFlgs abgefragt werden, sobald das EF+1-Feature aktiviert ist. Vermutlich ist EPxFifoBc zu benutzen.
Eine in dieser Hinsicht „eigensichere“ Zustandsmaschine zu konstruieren ist nicht möglich, wenn man das EF+1-Feature benutzt.
Wie man sich vorstellen kann, sind auch größere FPGAs mit einem Fingerschnipp konfiguriert. Man kann von einer Datenrate von 30 MByte/s (halbe High-Speed-USB-Bandbreite) ausgehen. Serielle Schneckentempo-Konfiguration war gestern.