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.
Hi Chris, super, danke fuer die Info! Gibt's bzgl. xc3sprog da irgendwo ein 'how-to'?
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.
Danke euch beiden, genau so werde ich es auch machen (die xapp1081 kannte ich noch nicht)
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.