Hallo Gemeinde,
folgende Frage: Ich möchte mir eine PCI Karte bauen. Darauf soll der
XC3S500E + XCF04S im Master Serial Mode verbaut sein. Der FPGA kümmert
sich um das PCI Protokoll und I/O Geschichten die später dazu kommen
(vorerst LED auf Platine schalten etc.). Nun mach ich mir Gedanken ob es
möglich ist mit dem PCI JTAG dem XCF04S einen neuen Bitstream
mitzuteilen. PC Neustart und der FPGA wird mit dem neuen Bitstream
konfiguriert und kann nun andere Funktionen ausführen. Ist das
grundsätzlich möglich?
Hi, ja das ist ohne Probleme möglich.
Es ist auch möglich eine PCI Karte ohne Neustart eines PCs upzudaten
sofern sich die Größe des Adressraums nicht ändert. Man muss davor nur
die Adresseinstellungen (base address etc.) von der Karte
zwischenspeichern - updaten - und die Einstellungen wieder
zurückschreiben.
Du musst natürlich gewährleisten, dass der FPGA schnell genug geladen
wird, so dass er im System erkannt wird. Die Zeit liegt so bei 1 sec,
bei einem 33MHz Busclock, und 0,5sec bei einem 66 MHz Busclock
Der Spartan 3e hat ja den großen Vorteil, dass man SPI Flash dran
schließen kann. Den kannst du quasi über den normales FPGA Design
updaten. Erstmalig über JTAG (indirekte Programmierung über impact) und
dann musst du lediglich in deinem FPGA Design einen simplen SPI Master
bauen. Somit kannst du den immer wieder aktualisieren. Booten geht auch
fix, wenn man die CCLK Geschwindigkeit hoch setzt. Den Platform Flash
könntest du ausschließlich über JTAG programmieren, dazu musst entweder
im FPGA einen JTAG Master bauen (ähnlich wie die SPI Lösung, zum
Beispiel der embedded JTAG ACE Player von Xilinx) oder irgendwie extern
von PCI auf JTAG kommen. Ich würde auf jeden Fall den SPI Flash nehmen,
wenn das Design nicht so ultrageheim ist, dass man Auslesen unterbinden
müsste.
Also kann ich mir praktisch über nen Linux Device PCI driver das neue
*.bit file auf meinen FPGA schieben, auf dem FPGA implementiere ich
einen SPI Master mit dem ich das file in den SPI Flash an die Stelle
schreibe, aus der der FPAG bootet. Danach PROG_B ziehen und neue
konfiguration starten. Das Problem könnte dabei nun sein wenn ich
versehentlich Daten schreibe, und ich keine weitere JTAG Schnittstelle
auf der Platine vorsehe habe ich mich ausm FPGA ausgesperrt, richtig?
So in etwa. Die JTAG Schnittstelle ist obligatorisch, denn das
allererste Mal muss das Bitfile ja auch in den SPI Flash. Ansonsten
klappt das so. Achja, das Bit-File muss entweder in ein bin oder mcs
File (intel hex) umgewandelt werden, im Flash landet etwas weniger als
im BitFile steht. Macht aber die Xilinx Software für dich.
Ok, danke soweit. Dabei ist jetzt also noch das Problem des aussperrens.
Ich hätte noch einen Ansatz bei dem ich den BPI MultiBoot Modus
verwende. Mir ist aber dabei noch unklar wie ich den BPI Speicher mit
dem Bitstream fülle?
Im "Spartan-3 Generation Configuration User Guide"
http://www.xilinx.com/support/documentation/user_guides/ug332.pdf ist
auf Seite 144 eine Beispielschaltung die ich so gerne verwenden würde?
Multiboot kann der S3E meines Wissens nicht, jedenfalls nicht mit
Fallback bei ungültiger Konfig im Flash. Das kann nur der extended S3A
(und dann nur bei Parallel-Flash, frisst massog I/Os). SPI Multiboot mit
Fallback kann der S6 dann. Wieso nimmst du eigentlich nicht gleich den
Spartan 6, der ist doch aktueller und man bekommt meist mehr fürs Geld.
Nein Fallback hat er wirklich nicht aber er kann laut der UG332 S.146
den BPI Up und den BPI Down Mode. Sprich ich könnte mir einen Bitstream
der die PCI Verbindung abhandelt in den unteren Speicherbereich packen,
sodass ich auf jeden Fall mit dem FPGA über PCI kommunizieren kann.
Sollten nun Bitstream updates oder Änderungen nötig sein kann ich per
PCI den oberen Bereich des Speichers beschreiben und dementsprechend
diesen Bereich booten. Somit könnte ich manuell fallbacken und dadurch
mal zumindest die PCI Verbindung garantieren (im unteren
Speicherbereich).
Soweit der Plan. Es bleibt die Frage wie ich den BPI Speicher fülle? Da
fehlt mir noch der aha Effekt.
Zusammengefasst sagt die Zeichnung auf S.144:
JTAG ---> FPGA ---> NOR Flash
Hm, na wenn du es irgendwie bewerkstelligt bekommst, während des Reboot
von BPI Up auf BPI Down an den Mode Pins umzustellen, geht das auch.
Aber das muss dann extern gesteuert werden, von einem FPGA IO aus klappt
das natürlich nicht. Aber ich denke, das Fallback wird überbewertet, vor
allem in solchen "Spielerei" Systemen, wo man an di Hardware rankommt.
Außerdem gibts ja sowas wie ein Verify, du kannst doch den Flash nach
dem Beschreiben überprüfen. Wenn die Hardware völlig unzugänglich wäre,
OK, aber per JTAG kommst du doch bei einer PCI Karte immer ran. Oder
planst du den Rechner irgendwo zu vergraben?
Den BPI Speicher füllen? Mit Promgen das mcs File erstellen und
reinschreiben, wo ist denn das Problem? Promgen hat eine Option, ob up
oder down.
Ich habe im Prinzip die gleiche Frage wie die ursprüngliche:
Kann ich ein FPGA über die JTAG Pins vom PCIe updaten?
Die Antworten sind zwar viel versprechend, gehen aber in eine andere
Richtung als die Probleme die ich noch sehe:
- Werden die JTAG Signale von typischen Motherboards unterstützt (soweit
ich weiß ist die Impelementierung von JTAG Support auf den Motherboards
optional)?
- Wie kann ich die JTAG Signale von der SW aus steuern? Bieten mir Linux
und Windows dafür Schnittstellen an? Gibt es bereits fertige
Bibliotheken?
Chris schrieb:> - Werden die JTAG Signale von typischen Motherboards unterstützt (soweit> ich weiß ist die Impelementierung von JTAG Support auf den Motherboards> optional)?
Nicht so, dass du einen JTAG Controller auf dem MB hättest, sondern nur
so, dass du mit externem Testequipment die Komponenten in der Chain
ansprechen könntest...
> - Wie kann ich die JTAG Signale von der SW aus steuern?
Aus der ersten Antwort folgert: gar nicht.
Danke für die rasche Antwort, Lothar!
Das heißt die JTAG-Signale am PCI Stecker Enden im Motherboard an einem
JTAG-Stecker?
Das ist enttäuschend. Ausserdem verstehe ich den Sinn dahinter dann
nicht wirklich. Dann kann ich den JTAG-Programmer ja gleich direkt auf
der Karte anstecken?!?
Nicht mal das. Im Normalfall sind die überhaupt nicht am Slot auf dem
Mainboard angeschlossen. Die sind am PCIe Finger dran, damit du in der
Firma deine eigene Karte einfacher Testen kannst, denn um die zu
betreiben musst du ja sowieso den PCIe Finger irgendwo reinstecken. Wozu
dann also noch ein JTAG Stecker extra?
Chris schrieb:> Das heißt die JTAG-Signale am PCI Stecker Enden im Motherboard an einem> JTAG-Stecker?
Die werden bei einem "normalen" Mainboard gar nicht angeschlossen sein.
Bestenfalls in speziellen kundenspezifischen Aufbauten wird der
verdrahtet, und so kann z.B. ein Rack gleich "am Stück" getestet werden.
> Ausserdem verstehe ich den Sinn dahinter dann nicht wirklich. Dann> kann ich den JTAG-Programmer ja gleich direkt auf der Karte anstecken?!?
Es geht beim JTAG auch weniger ums Programmieren von Komponenten als
vorrangig ums Testen des Boards. Kein Mensch programmiert seine
PC-Steckkarte über JTAG um. Und wenn das keiner tut, dann verbaut man
als Mainboardentwickler auch keine Ressourcen dafür (Interfacechip,
Leiterplattenfläche oder sonstwas)...
Lothar Miller schrieb:> Kein Mensch programmiert seine> PC-Steckkarte über JTAG um.
Genau DAS wollte ich tun, da der FPGA selbst die PCI-Schnittstelle am
Board bedienen wird und man deshalb beim Umkonfigurieren über PCI
höllisch aufpassen muss um sich nicht selbst vom PCI auszusperren.
Aber danke jedenfalls für eure Infos - jetzt kenne ich mich aus! ;-)
Chris
Chris schrieb:> Genau DAS wollte ich tun, da der FPGA selbst die PCI-Schnittstelle am> Board bedienen wird und man deshalb beim Umkonfigurieren über PCI> höllisch aufpassen muss um sich nicht selbst vom PCI auszusperren.
Dafür gibts Multiboot mit Fallback, zumindest bei aktuellen FPGAs. Da
hast du immer noch ein lauffähiges 2. Image im Flash.
Ich habe einen ähnlichen Bedarf. Allerdings ist es laut obiger Aussage
wohl so, dass der S3E nicht multibootfähig ist. Wäre eine Strategie
denkbar, dass der FPGA einen flash loader integriert hat, sich
irgendwoher ein mcs zieht und es ins flash schiebt um dann selbständig
zu starten?
Wie wäre das möglich?
Naja, so ein FPGA muss immer komplett geladen sein, Partial
Reconfiguration der großen Chips mal ausgenommen. Irgendwie muss also
das Design was den Flash beschreiben soll ja auch in den Chip kommen.
Beim S3e hat man wenig Chancen ein sicheres Update zu machen. Da geht
eigentlich nur erstmalig per JTAG flashen und dann beim Update beten
dass kein Stromausfall ist. Oder einen externen kleinen Controller
einbauen, der den FPGA per Slave Serial lädt, der kann ja leicht mehrere
Images verwalten.
