harald.kipp at egnite.de
Wed Jun 1 14:40:10 CEST 2011
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
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];
#define MAX_BITVEC_BYTES 4096
this is no problem. However, in ReShift() we have a local array
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(...
tdo_val = malloc(MAX_BITVEC_BYTES);
I vaguely remember that I heard about SVF for FPGAs containing mostly a
large bit vector and not much else.
More information about the En-Nut-Discussion