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.
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.