[En-Nut-Discussion] xsvfexec

[Harald Kipp]

Werner,

On 6/1/2011 12:26 PM, Landsperger, Werner wrote:
> Furthermore it doesn't matter if the hardware is connected or not. I'm

As long as Impact will not perform a verify, there will be no error,
because nothing gets compared automagically. The Executor is not able to
make assumptions about the result of a JTAG action. Such tests must be
embedded in the SVF, created by Impact.


> 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?

That could be the cause. Did you try to increase

#define MAX_BITVEC_BYTES    12

? Not sure, but it may be require one or several kBytes. For the static
globals

static u_char tdiVal[MAX_BITVEC_BYTES];
static u_char tdiVal2[MAX_BITVEC_BYTES];
static u_char tdoExp[MAX_BITVEC_BYTES];
static u_char tdoMask[MAX_BITVEC_BYTES];
static u_char dataMask[MAX_BITVEC_BYTES];
static u_char addrMask[MAX_BITVEC_BYTES];

defining

#define MAX_BITVEC_BYTES    4096

this is no problem. However, in ReShift() we have a local array

u_char tdo_val[MAX_BITVEC_BYTES];

Increasing this array to 1kB or more will create a stack overflow.
Either make this static global too

static u_char tdo_val[MAX_BITVEC_BYTES];
static int ReShift(...

or use

 u_char *tdo_val;
 tdo_val = malloc(MAX_BITVEC_BYTES);
 ...
 free(tdo_val);

I vaguely remember that I heard about SVF for FPGAs containing mostly a
large bit vector and not much else.

Regards,

Harald