[En-Nut-Discussion] xsvfexec

[Harald Kipp]

Werner,

On 5/30/2011 4:55 PM, Landsperger, Werner wrote:
> no error) but with no success. I've read out the states of JTAG and with
> connected or not connected hardware I've got the same states:
>  
> 0x7 (7)
> 0x13 (19)
> 0x14 (20)
> 0x12 (18)
> 0x12 (18)
> 0x4 (4)
> 0x2 (2)
> 0x0 (0)

I'm not very familiar with FPGAs and only used CPLDs. CPLDs are
flash-programmable, most FPGAs are not (except Actel parts, AFAIK). So I
have no clue, what the JTAG transfer actually does on FPGAs.

Anyway, SVF (or the compressed XSVF) will not do any checks by itself.
it simply contains commands, which are executed by the XSVF-Executor.
Thus, it is possible, that you will get no errors, even if no target is
connected.

Typically the SVF is created by the programmer software. Instead of
directly executing the commands, the software will write them out as SVF
commands. However, there are commands, which may, for example, check the
ID of the target device. Such commands have to be generated by the
programmer in the SVF File, the XSVF-Executor is not able to do such
checks by itself.

When creating SVF for the Ethernut 3 CPLD, we typically enable the
'verify' option. This produces a twice large SVF file and contains all
commands to verify the programming result.

A problem we encountered some time ago was, that the original setting of
the AN-52-Sample, on which the Executor is based, contains

#define MAX_BITVEC_BYTES    5

which failed when using later versions of Xilinx tools. In that case,
however, the verify cycle produced and error. We changed this to

#define MAX_BITVEC_BYTES    12

later for Ethernut 3.

SVF is simple text. May be you can inspect the SVF-File manually and
check it against xsvfexec/xsvf.h and eventually the Execute() routine in
xsvfexec/xsvfexec.c. There may have been some kind of extensions, which
the Executor is not able to detect.

Regards,

Harald