Hallo, ich habe eine XSVF-Datei von einem XC9572. Leider gibt es keine Unterlagen mehr zu dem Projekt :-( Die Hardware selber funktioniert auch noch und man käme auch an das JTAg-Interface. Gibt es eine Möglichkeit, die Programmierung zurückzulesen (ich habe von "readback" über impact gelesen)? Oder gibt es eine Möglichkeit die XSVF-Date irgendwie zurückzuwandeln? Vielen Dank Frank
> Gibt es eine Möglichkeit, die Programmierung zurückzulesen (ich habe von > "readback" über impact gelesen)? Kein Problem, wenn nicht jmd die Sperre gegen Auslesen gesetzt hat. Meine XC95... z.B. kannst du nicht mehr lesen.
Frank P. schrieb: > Oder gibt es eine Möglichkeit die XSVF-Date irgendwie zurückzuwandeln? Schwer. Aber diese alten Bausteine sollten mittlerweile vollständig dokumentiert sein, also welches Bit was bewirkt. Daraus ein eindeutiged HDL zu bauen geht glaube ich nicht. Das ist schlicht keine eindeutige Sache, denn viele sehr unterschiedliche HDL Beschreibungen können zu exakt dem gleichen Bitstream führen. Wenn man also daraus wieder HDL macht, dann wird es wohl etwas das wenig mit dem zu tun hat was früher mal geschrieben wurde.
Aber aus dem gelesenen .bit-File bekommst du genau keinen VHDL-Text mehr zusammengerödelt - du kannst damit lediglich weitere Schaltkreise programmieren.
Auslesen kann man immer (die Xilinx-JTAG-Primitiven lassen sich gut glitchen), die Bit-Map hast du per XSVF aber ja bereits. Daraus aber eine lesbare Netzliste zu reversen ist mit einem Haufen Arbeit verbunden, und die Tools dafür sind etwas verwaist. Bei CPLDs dank der Makrozellen weniger aufwendig als beim FPGA, aber dann hast du immer noch nichts, was du bearbeiten kannst. Also: besser die Schaltung als Blackbox 'erraten' und nachbauen.
Danke für die schnelle Rückmeldung! Mit dem "erraten" habe ich befürchtet :-)
Prinzipiell sollte das Rückübersetzen gehen. Bei CPLDs, wie dem XC9572, könnte das auch noch überschaubar sein. Die Information welches Bit wofür steht, hat Xilinx und auch die entsprechenden Tools. Aber er wird die wohl nicht so recht rausrücken. Für's nachentwickeln ist es hilfreich erstmal rauszufinden, was Eingang und was Ausgang (oder bidirektional) ist. BTDT. Duke
> Prinzipiell sollte das Rückübersetzen gehen. Bei CPLDs, wie dem XC9572, > könnte das auch noch überschaubar sein. Die Information welches Bit > wofür steht, hat Xilinx und auch die entsprechenden Tools. Aber er wird > die wohl nicht so recht rausrücken. Bei mir arbeiten sich die chinesischen Genossen seit 2007 an diesem Problem ab (9536Xl und 9572XL). Resultat: sie kaufen immer noch dmeine Originalgeräte.
Also das auslesen hat schon mal funktioniert, nachdem der China-Clone angekommen ist...kein Leseschutz. Heraus kommt ein JEDEC-File > Das werde ich jetzt noch mal mit xsvf-File vergleichen....wenn ich ein Tool dazu finde. Ob sich das JEDEC-File auch zurückverwandeln lässt habe ich noch nicht heruasgefunden. Ansonsten war dieser Thread ganz hilfreich: Beitrag "Xilinx XC9572"
:
Bearbeitet durch User
Das jedec kann man wenn ich mich richtig erinnere, mit impact statt in das PLD in ein xsvf "brennen". Das war mal für solche Sachen wie die xapp058 wichtig... ist aber lange her. War das nicht so, dass im xsvf dann die JTAG "Anleitung" steht?
Also die XSVF-Datei aus dem Projekt stimmt nicht im geringsten mit dem was ich als XSVF-Date aus dem JEDEC-File über Impact bekommen habe....Allerdings kann ich nicht sagen, wo er Fehler ist.
Hallo noch mal ein Frage in die Runde: Ist es möglich, dass verschiedene IMPACT Versionen unterschiedliche XSVF-Dateien erzeugen? Ich kenne mich zuwenig mit der Materie aus, ich hätte erwartet, dass immer der gleiche Code herauskommt, weil auch die gleiche Funktion in das EPROM/Flash (Sind zwar Makro-Blöcke ab bei 10.000 Zyklen erinnert mich das an was anderes) des Bausteins programmiert wird. Meine Beiden Dateien haben jeweils 51KB aber haben komplett andere Daten als Inhalt...fängt schon am Anfang an: JEDEC to XSVF: 0720 1200 1201 0400 0000 0002 08FE 0800 0000 2001 FFFF FFFF 0900 0000 0029 5040 9302 08FF 0208 E802 08ED 0400 13D6 2008 0000 001B 0100 0000 0009 003F FFFE 0000 0000 0100 0000 0309 003F FFFE 0000 0003 0100 0000 0009 007F FFFE 0000 0000 0100 XSVF aus µC: 0708 1201 0400 0000 0002 08FF 0208 FE08 0000 0020 010F FFFF FF09 FFFF FFFF 0950 4093 0208 FF02 08E8 0800 0000 0801 0009 3F00 0208 EC04 0013 D620 0800 0000 1B01 0000 0000 0900 3FFF FE00 0000 0001 0000 0003 0900 BFFF FE00 0000 0309 013F FFFE Mal abgesehen, dass einges nur verschoben ist, weil da noch Befehle dazwischen geschoben wurde....
Christian R. schrieb: > War das nicht so, dass im xsvf > dann die JTAG "Anleitung" steht? Genau, die Konsequenz davon: Frank P. schrieb: > Also die XSVF-Datei aus dem Projekt stimmt nicht im geringsten mit dem > was ich als XSVF-Date aus dem JEDEC-File über Impact bekommen > habe Wenn ich mich nicht irre (lange her), gilt 'random access' fuer die Makrozellen, d.h. je nach Tool kann die JTAG-Sequenz voellig unterschiedlich aussehen. Also: Die XSVF muesstest du nach JTAG-Kommandos reverse-engineeren, um daraus die Landkarte fuer die Makrozellenconfig rauszukriegen. Aus XSVF konnte man auch mal SVF machen und das dann im Text anschauen/parsen.
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.