Hi allerseits,
ich arbeite gerade an der Definition einer neuen HW fuer einen
Pruefstand, die soll prinzipiell so aussehen:
* Eine Karte mit uC (Atmel Cortex M3), Spartan6, NAND-Flash mit 2 FPGA
Images. Der Spartan6 wird vom uC nach dem PON geladen. Das ist sehr
aehnlich einer existierenden HW, nur auf ein neues Board verfrachtet.
* Mehrere 'Slave'-Karten mit Spartan6 und SPI-Flash zur Konfiguration.
Diese Karten sollen 'ab Werk' mit Multiboot-Image programmiert werden,
vermutlich via JTAG (indirect programming). Spaetere Feld-Updates sollen
dann mit der uC-Karte/dortigem Spartan6 erfolgen (ueber eine schnelle
Multiport LVDS-SPI).
* Die uC-Karte hat Netzwerk, darueber sollen auch die Updates
eingespielt werden.
Die Slave-Karten sollen sich also immer aus dem SPI-Flash 'aus dem Sumpf
ziehen'. Aber sie sollen halt ueber die Verbindung zum Master (der Karte
mit dem uC) spaeter flashbar sein.
Was brauche ich dazu:
* S6 unterstuetzt Multiboot, also Header, golden Image (Fallback) sowie
die eigentliche Anwendung im SPI-Flash.
* Das kann ich 'ab Werk' via JTAG mit Impact reinflashen
** Kann ich uebrigens dafuer auch sowas wie 'xc3sprog' verwenden? Ich
verstehe bisher noch nicht, wie ich damit das SPI-Flash programmieren
kann. JTAG-Adapter waere entweder Xilinx oder Digilent
* Was muss ich tun, damit spaeter, im laufenden Betrieb, ein neues
'User-Image' in ein SPI-Flash geschrieben werden kann? Da laeuft dann ja
mein 'User-Image' oder das 'golden Image'. Das muss die MP-LVDS zur
uC-Karte sowie einen Teil zur Ansteuerung des SPI-Flash unterstuetzen,
soweit klar.
Bevor ich hier jetzt noch mehr (langweilige) Details schreibe und keiner
mehr mitliest, hat jemand zu dem o.g. eine Idee oder das schonmal
gemacht oder ein paar gute Links? Die UGs von Xilinx habe ich denke ich
alle schon durch und bin der Meinung, dass das machbar ist. Aber da ich
demnaechst den Schaltplan 'absegnen muss' hier mal die Nachfrage nach
Erfahrung damit.
Bin um jeden Tipp dankbar!
PS: Kann man 'indirect programming' mit xc3sprog ueberhaupt machen? Und
geht das evtl. auch auf einem RaspberryPi? (waere fuers Hobby auch noch
interessant)
PS: Da solche Pruefstaende bei und >>10 Jahre in Benutzung sind, muss
das ganze eben auch mit Nachfolgern des S6 funktionieren. Wenn ich das
beim stoebern bei Xilinx richtig interpretiere, ist die
Multiboot-Funktionalitaet bei Spartan7 (oder anderen 7-ern) gleich.
Damit koennte ich die gleiche EE-Architektur in ein paar Jahren auch mit
z.B. S7 beibehalten. Das wuerde ansonsten ja wieder einen Rattenschwanz
an Software-Aenderungen nach sich ziehen...
berndl schrieb:> bei und >>10 Jahre in Benutzung
argh, soll natuerlich
"bei uns >>10 Jahre"
heissen. Komisch, man sieht Schreibfehler niemals nienicht in der
Vorschau. Nach dem absenden aber komischerweise sofort...
Ja, xc3sprog kann meines Wissens angeschlossen SPI Flash programmieren.
Was dann da drin ist, (SingleBoot, MultiBoot, Userdaten) ist dem doch
egal.
Neuprogrammierung kann dann direkt über das laufende Design erfolgen,
also über das Protokoll was die eh zum Unterhalten nehmen. So machen wir
das. Klappt bei S6 und A7 nahezu gleich.
So, jetzt habe ich nicht nur am WE in meiner Freizeit, sondern heute
auch auf Arbeit mal rumgehirnt...
Also, sowohl xc3sprog als auch z.B. Digilent Adept koennen SPI indirect
programming. Gut! Aber das ist nur ein Teil meines Problems...
Ich brauche auf den Slave-FPGAs eine Applikation, die eigentlich genau
das macht, was auch die Xilinx Cores fuer indirect programming machen.
Aber halt nicht die JTAG Pins als Eingang, sondern meine 'golden Image'
und auch 'User Image'.
Damit waere es ja einfach, vom entfernten Master-FPGA ueber SPI mit
meinem Slave zu schwaetzen (halt JTAG Kommandos zu empfangen), die er
dann 1:1 (Xilinx-IP) an das SPI-Flash zum programmieren weiter schickt.
Frage: Gibt es so eine IP? Also das was Xilinx mit der Uebersetzung von
JTAG nach SPI macht, ich aber anstatt der JTAG Pins 'meine User-SPI'
verwende?
Ich hab' da jetzt rumgesucht wie ein Depp, aber leider nicht wirklich
was gefunden. Auch die App-Notes von Xilinx beziehen sich immer auf
Impact und JTAG...
Ideen?
Warum der Umweg über JTAG, wenn du eh schon per SPI mit dem Slave
redest? Dann leite doch das SPI mit einem extra PIn geschaltet diekt auf
den Boot Flash um. Dann kann dein Master den Flash direkt programmieren.
Beim 7er brauchst du für die Ansteuerung des CCLK dann noch die STARTUP
Primitive.
hmm, ja, warum JTAG?
Letztendlich spiele ich doch dem Slave-FPGA Kommandos vor (via SPI),
habe also auch darauf zu achten, dass diverse Timings zum Flash (via
SPI, auf dem Slave) eingehalten werden. Wartezyklen z.B.. Und die
stecken doch nicht im 'bitfile' des Slaves drin, das macht doch
normalerweise Impact via JTAG. Also (denke ich) brauche ich da ein
Interface zwischen 'bitstream in' und 'spi-out'.
Oder liege ich da jetzt komplett neben der Spur?
Die .mcs/.bit File wird ja vom uC der Masterkarte 'abgespielt'. Und
irgendwo muss da ja ein Handshake stattfinden. Klar, wenn ich das auf
dem uC der Masterkarte abhandeln koennte, waere natuerlich viel schoener
als das auf dem Slave-FPGA zu tun.
Also kurzum: Ich verstehe noch nicht richtig, wie das funktionieren
soll...
PS: Handelt sich im Moment um Spartan6. Spaeter mal, wenn HW-Updates
notwendig werden, dann werden wir wohl PCB-Redesigns machen und auf S7
umsteigen (und auch auf einen neueren Cortex-Mx). Muss ja "nur"
SW-Kompatibel zum Host-Rechner sein...
PS zum PS von obigem Post: Das ist auch so ein Grund, irgendwelche
Vendor-IP zu vermeiden, wann immer es geht. Das ist zwar kurzfristig
Klasse, aber langfristig holt es dich ein. Das fuehrt dann halt dazu,
dass manche Sachen immer und immer wieder 'lokal' entwickelt werden...
Naja das Bit File kommt 1:1 in den Flash. Aber du musst natürlich die
Flash Kommandos alle abarbeiten, also z.B. immer das Status Register
pollen nach dem Schreiben ob jetzt fertig ist. Bei Impact oder xc3sprog
macht das dann ein kleiner Core der zuerst runter geladen wird.
Kannst/musst du dann selber schreiben, wird halt eine große State
Machine. Aber die ist auf dem uC DEUTLICH einfacher zu programmieren,
daher mein Vorschlag. Macht übrigens der Rest der Welt auch so.
BTW, auch Impact und xc3sprog haben den Algorithmus zur SPI Flash
Programmierung in der Software, der core der vorher runter geladen wird,
macht nur eine stupide Umsetzung von JTAG auf SPI. Deswegen dauert das
auch so lange...
xc3sprog liefert den Quellcode für das JTAG-to-SPI Image als
Verilog-Datei mit. Das ist nicht kompliziert. Könnte man als Startpunkt
für eine eigene Implementierung nehmen. Den JTAG-Teil tauscht Du halt
gegen die verfügbare Schnittstelle aus.
Du solltest Dir aber besser die XAPP1081 ansehen. Die ist ziemlich
generisch, für die Implementierung des "Remote Update Channels" musst
also selber sorgen. Ab da läuft alles über Register und FIFOs, ist recht
einfach zu benutzen.
