SVF-Interpreter (z.B. Xilinx CPLDs) im Mega32

[Clemens H. (sum)]

Hallo,

ich habe mal einen SerialVectorFile-Interpreter für den AVR
geschrieben.
Das Programm arbeitet mit dem UART. Es empfäng eine Zeile der Datei und
verarbeitet sie. Danach wird ein '\n' zurückgesendet. Erst nach dem
Empfang der Antwort darf die nächste Zeile gesendet werden.

Es ist ein JAVA-Programm enthalten, was die Sende-Antwortaufgabe
übernimmt. Das SVF-File einfach mit Copy&Paste an das Javaprogramm
senden (Konsole). Unter Windows ist die Latenzzeit der seriellen
Schnittstelle leider sehr hoch, sodass eine geringe
programmiergeschwindigkeit resultiert. Unter Linux werden etwa 2kB/sec
übertragen.

Eine optimierung auf geringen Speicherplatz lässt sich sicher noch
durchführen.
Eine optimierung für bessere Ausnutzung des Datenspeichers (sprich kein
ASCII Format wie SVF wählen), ist auch noch möglich/nötig.

Derzeit implementiere SVF-Befehle:
SDR, SIR, TIR, TDR, HIR, HDR, ENDDR, ENDIR, RUNTEST, STATE, Comments
(//, !)

Anschließend kann man diesen Code z.B. in eine Zielschaltung
programmieren, die einen AVR und einen CPLD enthält. Damit wird der
JTAG-Adapter für den CPLD überflüssig.

Kommentare, Anregungen, Verbesserungen bitte in netter Form hier
posten!

Grüße, Clemens

[Hagen (Gast)]

Hi Clemens,

ich hätte eventuell 2 Kritikpunkte:

1. ein C-Source wäre wahrscheinlich portabler, bzw. Assembler ist immer
schwieriger in ein bestehendes Projekt zu integrieren. Hast du eventuell
geplant einen C Source zu basteln ?

2. inwieweit kann man die Interpretation der SVF Daten von der
Kommunikation des UARTs abspalten. D.h. wäre es zb. möglich statt der
UART das SVF von einer MMC/SD Karte, oder externem/internem Flash zu
laden ? Ich frage deshalb weil die jetzige Kombination
PC->UART->AVR->CPLD ja im Grunde nichts anders wäre als
PC->Programmer->JTAG, halt eben nur komplizierter und aufwendiger als
gleich den CPLD über JTAG und der entsprechenden freien Software wie
dem ByteBlaster zu programmieren. Sinnvoll wird ein AVR aus meiner
Sicht also erst dann wenn der AVR das SVF von anderen Speichermedien
laden könnte.

Gruß Hagen

[Clemens H. (sum)]

Hallo Hagen,

zu 1: Ja, ein C-Code wäre auch meiner Meinung nach besser, allerdings
kann ich nicht genug C um ein solches Projekt umzusetzen. Der
Assemblercode lässt sich aber dennoch mit dem C-Code linken (ich nutze
AVRstudio Syntax).

zu 2: Ja, man kann die Interpretation vom UART abspalten, siehe Macro
svf_ReadByte svf_WriteByte, svf_ReadLine, svf_WriteLine. Die
Kombination PC->UART-AVR->CPLD ist höchst sinnvoll, schließlich braucht
man dann kein JTAG-adapter sondern nur den (oft vorhandenen) ISP für den
µC. Der CPLD kann dann auch wärend des Betriebes neu bespielt werden,
ganz ohne Programmierer, uvm..

Gruß Clemens

[Dirk M. (avr-nix)]

abo

[KoF (Gast)]

@Clemens Helfmeier

da ich soetwas auch machen wollte, jedoch in c und für einen msp430
währe es für mich mal interessant, was für unterlagen du für die
implementierung von uc -> cpld verwendet hast.

[Clemens H. (sum)]

Hallo KoF:

ich hatte auch überlegt, das in C zu machen, jedoch erschlug mich die
1. das Neuerlernen einer Sprache (ich verstehe zwar das meiste C aber
schreiben kann ich für µC fast garnix:/). Dann wäre es deutlich
portabler, was natürlich schön wäre.
Nun habe ich aber in ASM geschrieben (ging sogar recht einfach mit den
Macros :).

Als Unterlagen bezog ich folgendes:
 XAPP503.pdf von Xilinx (suche nach "xsvf")
 http://www.asset-intertech.com/support/svf.html oder eine äquivalente
Beschreibung der SVF-Kommandos (ich glaube, ich hatte ein PDF)

In der Application Note von Xilinx sind die von ihren Devices
verwendeten SVF-Befehle beschrieben. Ich habe auch nur diese
implementiert.

Schöne Grüße, Clemens

[Clemens H. (sum)]

Hallo,

das Projekt ist nun ein wenig fortgeschriten. Der neue Code befindet
sich im Anhang.

Folgende Funktionen aus dem SVF-File werden unterstützt:
 SIR nBits [TDI (tdi)] [TDO (tdo)] [MASK (mask)] ;
 SDR nBits [TDI (tdi)] [TDO (tdo)] [MASK (mask)] ;
 STATE x;  -> wird zu STATE RESET IDLE;
 .EXIT -> bricht den Übersetzungsvorgang ab

Das Übersetzungsprogramm (main.cpp) müsste ggf. noch erweitert: Die
Funktionen HDR, HIR, TDR, TIR werden gebraucht, sobald JTAG-Chains
programmiert werden sollen. Dazu ist aber lediglich das Zusammensetzten
von Bit-streams in den SDR und SIR Befehlen nötig.

Das Programmieren und verifizieren eines XC9536 von Xilinx dauert nun
ca. 13 Sekunden. Das Übertragungsvolumen beträgt dann ca. 60kByte.

Bei mir arbeitet das Programm gänzlich ohne Fehler, wer dennoch einen
Fehler findet, sage mir bitte bescheid!

Schöne Grüße, Clemens