[En-Nut-Discussion] xsvfexec

[Landsperger, Werner]

Hallo Harald,

meanwhile I'm sure that the configuration of FPGA provides an flash
which can be programmed by impact.The FPGA is a Virtex 5 SX95T. Directly
programming via PC and JTAG is no Problem. So I've taken the
configuration and created an xsvf file which is the basic of my trial.
Furthermore I've found some little bugs but it still doesn't work. 

I've compared the file via hex editor with the debug output and so I can
say that the File from the MMC would be read out correctly. With your
Debugoutputs and some additionaly outputs I actually got this output:


100 XSVF-Executor 1.2.0 on Nut/OS 4.8.9.0
Pins are defined...
Open File...done.
Init..done (rc: 0)
Execute...

207 XREPEAT
[0]
219 XENDIR
{Run-Test-Idle}
220 XENDDR
{Run-Test-Idle}
218 XSTATE
{Test-Logic-Reset}
218 XSTATE
{Run-Test-Idle}
204 XRUNTEST
[0]
202 XSIR
[10]
reading Bitstream...
[10:03C9]
ReShift...
208 XSDRSIZE
[32]
201 XTDOMASK
[32:0FFFFFFF]
209 XSDRTDO
[32:00000000]
[32:F2ECE093]

done (rc: 2)
402 ERROR

Furthermore it doesn't matter if the hardware is connected or not. I'm
not sure but It appears to me that the problem accrues while reading the
bitstream, because that part is extreamly short. What do you think?

Thanks for your help!

Greets,

Werner


-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Harald Kipp
Sent: Tuesday, May 31, 2011 6:55 PM
To: Ethernut User Chat (English)
Subject: Re: [En-Nut-Discussion] xsvfexec

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

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion