Possible CRC error on XC3S400 - now what?
Michael Meeuwisse
I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new
prototype but I'm getting some weird results back while programming it.
I hope somebody with more experience can help me out.
The fpga is the 2nd device in a chain of 3 devices, of which the third a
XC95144XL is which can be programmed succesfully. I assume therefore
that there are acceptable noise levels on the bus and bus speed
(currently at about ~1.2MHz - depends a bit on how fast the programmer
can handle incoming data but not faster than that) is Ok.
When fetching the status register before any programming, I get;
mask; 0x01FFFFFFFE
34 bits; 0x0260000000
The fpga being the second device, it actually clocks out 0x30000000 (and
the first device seems to add a 1?)
After programming I get;
34 bits; 0x0262000000
So it actually clocks out 0x31000000
So apparently (if I follow xapp452) the DCM are locked and DCI is
matched (even though I haven't flashed in anything yet - the PROM
onboard doesn't contain valid data - and don't have any DCI pins
configured as actual DCI) and after a programming attempt GHIGH_B is
deasserted, and there are _no_ CRC errors reported here.
It doesn't, however, start up. DONE pin stays low (isn't connected to
anything) as well as GTS_CFG and GWE etc, basically, the startup is
stalled for some reason.
So I decided to pick up the multimeter and start measuring;
DONE stays low
PROG_B stays high
INIT_B goes high, than goes low again after programming
This seems to indicate a CRC error after all? I've tried setting the
BitGen option for unused IOB pins to pull-up (I'm not using the DONE
pin as IO) but that still made DONE go low.
So right now I have no idea how to continue in figuring out what the
problem is or how to get the fpga working. I haven't tried disabling the
CRC check completely yet. Any tips, hints, suggestions are very welcome.
Cheers,
Sky4...@trline5.org
>I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new
>prototype but I'm getting some weird results back while programming it.
>I hope somebody with more experience can help me out.
>The fpga is the 2nd device in a chain of 3 devices, of which the third a
>XC95144XL is which can be programmed succesfully. I assume therefore
>that there are acceptable noise levels on the bus and bus speed
>(currently at about ~1.2MHz - depends a bit on how fast the programmer
>can handle incoming data but not faster than that) is Ok.
* Check power for any dips or transients.
* Connect directly with a parallell port jtag adapter.
Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf
(And only try the USB approch once it confirmed to work)
* Lower the clocking frequency, try 50 kHz.
* Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B,
CCLK, etc)
* You could connect pins to the fpga DIN etc.. back to your PC to verify your
fpga actually get the data you expect.
Thorsten Trenz
> I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new
> prototype but I'm getting some weird results back while programming it.
> I hope somebody with more experience can help me out.
Try to switch the modepins to JTAG only. Do you use a PC3 clone? There
seems to be some problems in certain impact versions with PC3 and S3 if
the chip is not in JTAG only mode.
best regards
Thorsten Trenz
Michael Meeuwisse
Hi,
Sky4...@trline5.org wrote:
> Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:
>
>>I'm trying to configure a Xilinx Spartan 3 s400 through JTAG in a new
>>prototype but I'm getting some weird results back while programming it.
>>I hope somebody with more experience can help me out.
>
>
>>The fpga is the 2nd device in a chain of 3 devices, of which the third a
>>XC95144XL is which can be programmed succesfully. I assume therefore
>>that there are acceptable noise levels on the bus and bus speed
>>(currently at about ~1.2MHz - depends a bit on how fast the programmer
>>can handle incoming data but not faster than that) is Ok.
>
>
> * Check power for any dips or transients.
My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't
really know what's causing this (it's just below the minimum required,
isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V.
> * Connect directly with a parallell port jtag adapter.
> Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf
>
> (And only try the USB approch once it confirmed to work)
The thing is, the programmer is embedded on the board itself so
connecting a different programmer would require me to start cutting pcb
traces.
> * Lower the clocking frequency, try 50 kHz.
Didn't seem to help. Afaik there's no minimum clock so I even tried it
at ~100Hz (which takes forever btw, in case you never tried it) but it
still failed.
> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B,
> CCLK, etc)
M[2:0] are all tied to ground, and changing this would again require
some force so I'd rather not. This shouldn't matter afaik, since you can
always program using JTAG anyway, right? Likewise, when configuring
using JTAG it doesn't matter what CCLK is, does it? I mentioned the
state of INIT_B, PROG_B and DONE earlier.
> * You could connect pins to the fpga DIN etc.. back to your PC to verify your
> fpga actually get the data you expect.
>
Would data pushed in through JTAG appear on DIN? I could write something
that checks TDO but I'm told the spartan spits out zeroes or other
nonsense when I'm shifting data in.
Thorsten Trenz wrote:
> Hi,
>
> Try to switch the modepins to JTAG only. Do you use a PC3 clone? There
> seems to be some problems in certain impact versions with PC3 and S3 if
> the chip is not in JTAG only mode.
The programmer is an FTDI FT2232 using an homebrew XSVF parser. I
believe I've got all the bugs worked out of the software since
programming the CPLD goes without a problem.
Cheers,
Gabor
<mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com>
wrote:
> Hi,
You didn't say what the first device in the chain was. There are
known
issues when placing a PlatformFlash (XCF02S for instance) in front of
a Spartan device wired up for master serial configuration mode.
Do you have a pullup on the DONE pin? If not have you checked the
"Drive Done pin high" option in bitgen?
Are you providing enough clocks at the end of the bitstream load to
start up the device (again look at where DONE is supposed to go high
in the bitgen options)?
That's all I can think of.
By the way if you are using an XFCxxS device in front of your FPGA,
try erasing it to see if that helps the JTAG load.
Regards,
Gabor
Michael Meeuwisse
Yeah sorry, it's a XCF04S. I've got some other issues with that one
however, it seems that is has some dead banks which is why I'm trying to
program the fpga directly in the first place. As far as I can tell these
two problems are unrelated.
> Do you have a pullup on the DONE pin? If not have you checked the
> "Drive Done pin high" option in bitgen?
>
No, no external pull up. I've set "Configuration pin done" to Float and
checked "Drive done pin high" as suggested by table 2.6 of ug332.
> Are you providing enough clocks at the end of the bitstream load to
> start up the device (again look at where DONE is supposed to go high
> in the bitgen options)?
>
I think so, I've tried programming the CPLD after I attempted to program
the FPGA which should provide plenty of clock cycles, but it didn't
change anything.
> That's all I can think of.
>
> By the way if you are using an XFCxxS device in front of your FPGA,
> try erasing it to see if that helps the JTAG load.
>
> Regards,
> Gabor
As it turns out, the LM1086-2.5 needs a minimum of 4V and I'm only
giving it 3.3V so that might be cause of some of the trouble - it
certainly explains why my VccAux is only ~2.3V. I'm going to fix that
now and hopefully it'll help.
Cheers,
Sky4...@trline5.org
>My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't
>really know what's causing this (it's just below the minimum required,
>isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V.
XC3S400-PQ208
http://direct.xilinx.com/bvdocs/publications/ds099.pdf (t31 p58/208)
Min Nom Max
Vccint 1.140 1.200 1.260
Vccaux 2.375 2.500 2.625
Vcco 1.140 - 3.450
LM1086-2.5
http://users.ece.utexas.edu/~valvano/Datasheets/LM1086.pdf
Min Typ Max
Vout 2.450 2.50 2.525 (Vin=4-18V Ifull)
Current limit: Min=1.5A Typ=2.7A at Vin=8V
Your Vcco regulator uses "3V3" for Vin with a 10uF capacitor on each input
and output.
"3V3" comes from S53, S39, S33, S27, S21, C25, C31, C36, C41, C43, C54 on
the PCI connector (CON1).
(Schematic: http://wacco.mveas.com/img/schema1d.png)
So the Vin of the 2.5V regulator is not enough.
Also there's the issue of voltage ramp time upon startup.
Vcco 2000 us
Vccaux - us (no requirement)
Vccint 500 us
(p57 Table 29 Power voltage ramp time requirements)
So you might need to check Vccint vs Vccaux. The Vccaux should be powered
before Vccint, but it's not that sensitive (or?). (see p53)
Check that your oscillator does have proper power. And outputs a correct
waveform at the XC3S400 input (Bank5 GCLK2, P76).
(LVTTL 0.8 - 2.0 swing + flanks)
>> * Connect directly with a parallell port jtag adapter.
>> Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf
>> (And only try the USB approch once it confirmed to work)
>The thing is, the programmer is embedded on the board itself so
>connecting a different programmer would require me to start cutting pcb
>traces.
Measure the output of your onboard usb programmer that it does what you
expect it to do. Ie feedback it's TDO to your parallell port.
If this fails, try the cut traces approach and solder some wires so you can
change programmer at will.
Also use program directly via JTAG mode to start with, only when that works
try eeprom. The first bitstream ("program") should be something simple like
pulsing a LED.
(604-00033G-ND IC FTDI2232L USB/SERIAL 48-LQFP)
Scan chain (reverse order?):
FTDI2232L - XC95144XL - XC3S400 - XCF01S - FTDI2232L
>> * Lower the clocking frequency, try 50 kHz.
>Didn't seem to help. Afaik there's no minimum clock so I even tried it
>at ~100Hz (which takes forever btw, in case you never tried it) but it
>still failed.
Verify bitstream at TDI+TCK?
{M0,M1,M2} = 3'b000 (ds099 p45 for mode table)
So configuration mode is master serial. Thus CCLK+DIN is the ones that
dictates programming. Setting M0=1, M1=0, M2=1 gives you jtag programming
mode. Which might make life easier in the beginning. It's also the mode
that is smoother to use when developing.
>> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B,
>> CCLK, etc)
>M[2:0] are all tied to ground, and changing this would again require
>some force so I'd rather not. This shouldn't matter afaik, since you can
>always program using JTAG anyway, right? Likewise, when configuring
>using JTAG it doesn't matter what CCLK is, does it? I mentioned the
>state of INIT_B, PROG_B and DONE earlier.
M[2:0] = 000 => Master serial mode according to datasheet ds099 page 45.
So CCLK will matter. Btw, check if CCLK (2.5V) does output a proper waveform
at the eeprom input (Pin3 CLK). And that eeprom output is correct at the fpga.
Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V
Signals:
INIT_B Shall go high after memory is cleared. And shall not be tied low.
PROG_B Goes high?
DONE Goes high after configuration is complete.
HSWAP_EN Is tied low in your schematic => Pullup resistors enabled on all
pins not activly involved in the configuration process.
Check that no pullup'ed pin interfere with the configuration process.
(ds099 p101)
You might use these to find out what's going on.
>> * You could connect pins to the fpga DIN etc.. back to your PC to verify your
>> fpga actually get the data you expect.
>Would data pushed in through JTAG appear on DIN? I could write something
>that checks TDO but I'm told the spartan spits out zeroes or other
>nonsense when I'm shifting data in.
My idea was to attach a wire directly to TDI/TDO + TCK back into an INPUT pin
of the parallell port to verify data.
>Thorsten Trenz wrote:
> > Hi,
> >
> > Try to switch the modepins to JTAG only. Do you use a PC3 clone? There
> > seems to be some problems in certain impact versions with PC3 and S3 if
> > the chip is not in JTAG only mode.
>The programmer is an FTDI FT2232 using an homebrew XSVF parser. I
>believe I've got all the bugs worked out of the software since
>programming the CPLD goes without a problem.
Verify board connections -> Power -> Clocks -> Other.
I think also that if you try to program:
Onboard USB -> XCF01S eeprom
eeprom -> FPGA
You add more steps that may fail.
Also you could try to manually read if the contents of the XCF01S is what
you expect.
>it's a XCF04S. I've got some other issues with that one
>however, it seems that is has some dead banks which is why I'm trying to
>program the fpga directly in the first place. As far as I can tell these
>two problems are unrelated.
So you need to alter M[0:2] pins to 1-0-1 (ds099 p45).
And according to table 26 (ds099 p45) you need at least an XCF02S.
So schematic is contradictive.. :)
Your schematic would be easier to follow if you added consistent chip
identifications ie Ux XC3S400 etc..
Also soldering pads for debug fixes could be something to have in mind for
later revisions. Assume failure ;)
Michael Meeuwisse
Sky4...@trline5.org wrote:
>>> * Check power for any dips or transients.
>
>
>>My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't
>>really know what's causing this (it's just below the minimum required,
>>isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V.
>
>
> XC3S400-PQ208
> http://direct.xilinx.com/bvdocs/publications/ds099.pdf (t31 p58/208)
> Min Nom Max
> Vccint 1.140 1.200 1.260
> Vccaux 2.375 2.500 2.625
> Vcco 1.140 - 3.450
>
> LM1086-2.5
> http://users.ece.utexas.edu/~valvano/Datasheets/LM1086.pdf
> Min Typ Max
> Vout 2.450 2.50 2.525 (Vin=4-18V Ifull)
>
> Current limit: Min=1.5A Typ=2.7A at Vin=8V
>
> Your Vcco regulator uses "3V3" for Vin with a 10uF capacitor on each input
> and output.
> "3V3" comes from S53, S39, S33, S27, S21, C25, C31, C36, C41, C43, C54 on
> the PCI connector (CON1).
> (Schematic: http://wacco.mveas.com/img/schema1d.png)
>
> So the Vin of the 2.5V regulator is not enough.
>
Yep, I realised that too and got just back from uni where I've got
better tools than here at home. The Vin is now tied to 5V and the output
is a clean 2.50V. (Also, I fixed the second led on the CPLD but that's
irrelevant for this discussion)
Still can't program the fpga though.
> Also there's the issue of voltage ramp time upon startup.
> Vcco 2000 us
> Vccaux - us (no requirement)
> Vccint 500 us
> (p57 Table 29 Power voltage ramp time requirements)
>
> So you might need to check Vccint vs Vccaux. The Vccaux should be powered
> before Vccint, but it's not that sensitive (or?). (see p53)
>
Hmm, I checked the fpga and it's a revision E with the GQ fabrication
process code so I guess I'm lucky and don't have to worry about any of this.
> Check that your oscillator does have proper power. And outputs a correct
> waveform at the XC3S400 input (Bank5 GCLK2, P76).
> (LVTTL 0.8 - 2.0 swing + flanks)
>
This is where it gets annoying, I don't have anything to check out the
waveform with. I'll have to drag everything to uni tomorrow if I want to
see what's happening on such lines which is a much bigger effort than
just taking the PCI card - I'll do it anyway, but still. It would be
easier if I was able to program the fpga so I could fling a little
counter-thing on it outputting it to the led.
>
>>> * Connect directly with a parallell port jtag adapter.
>>> Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf
>>> (And only try the USB approch once it confirmed to work)
>
>
>>The thing is, the programmer is embedded on the board itself so
>>connecting a different programmer would require me to start cutting pcb
>>traces.
>
>
> Measure the output of your onboard usb programmer that it does what you
> expect it to do. Ie feedback it's TDO to your parallell port.
> If this fails, try the cut traces approach and solder some wires so you can
> change programmer at will.
>
> Also use program directly via JTAG mode to start with, only when that works
> try eeprom. The first bitstream ("program") should be something simple like
> pulsing a LED.
>
Right now the program is exactly (except for pinout of course) the same
as the thing I flashed succesfully into the CPLD. It had the led tied to
counter[25] where counter = counter + 1 on every posedge clk. I'm
completely ignoring the eeprom at the moment.
> (604-00033G-ND IC FTDI2232L USB/SERIAL 48-LQFP)
>
> Scan chain (reverse order?):
> FTDI2232L - XC95144XL - XC3S400 - XCF01S - FTDI2232L
>
>
It's FTDI tdi -> XCF04S -> XC3S400 -> XC95144XL -> FTDI tdo
>>> * Lower the clocking frequency, try 50 kHz.
>
>
>>Didn't seem to help. Afaik there's no minimum clock so I even tried it
>>at ~100Hz (which takes forever btw, in case you never tried it) but it
>>still failed.
>
>
> Verify bitstream at TDI+TCK?
>
The CPLD verifies so I'm pretty sure it's not the programmer. I'll do a
debug output though and check it by hand tonight.
> {M0,M1,M2} = 3'b000 (ds099 p45 for mode table)
>
> So configuration mode is master serial. Thus CCLK+DIN is the ones that
> dictates programming. Setting M0=1, M1=0, M2=1 gives you jtag programming
> mode. Which might make life easier in the beginning. It's also the mode
> that is smoother to use when developing.
>
All documentation seems to say that M[2:0] don't matter at all when you
want to program using JTAG, say, the first line of the chapter "JTAG
Configuration Mode" of ug332 (page 187).
http://www.xilinx.com/support/documentation/user_guides/ug332.pdf
>
>>> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B,
>>> CCLK, etc)
>
>
>>M[2:0] are all tied to ground, and changing this would again require
>>some force so I'd rather not. This shouldn't matter afaik, since you can
>>always program using JTAG anyway, right? Likewise, when configuring
>>using JTAG it doesn't matter what CCLK is, does it? I mentioned the
>>state of INIT_B, PROG_B and DONE earlier.
>
>
> M[2:0] = 000 => Master serial mode according to datasheet ds099 page 45.
> So CCLK will matter. Btw, check if CCLK (2.5V) does output a proper waveform
> at the eeprom input (Pin3 CLK). And that eeprom output is correct at the fpga.
>
> Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V
>
Sorry you lost me - is this a problem? I followed figure 4 of xapp453 to
enable 3.3V powered programming;
http://www.xilinx.com/support/documentation/application_notes/xapp453.pdf
Rpar is R24 in case you can't find it in my (unfortunately somewhat
confusing) schematic.
The only changes I made is the DONE pin connection because I want to
imitate the behavior of Figure 1 of xapp694, which makes it possible to
use parts of the eeprom for user data.
http://www.xilinx.com/support/documentation/application_notes/xapp694.pdf
> Signals:
> INIT_B Shall go high after memory is cleared. And shall not be tied low.
Is low, goes high when programming starts, goes back to low after that
> PROG_B Goes high?
Always high
> DONE Goes high after configuration is complete.
Always low
> HSWAP_EN Is tied low in your schematic => Pullup resistors enabled on all
> pins not activly involved in the configuration process.
> Check that no pullup'ed pin interfere with the configuration process.
> (ds099 p101)
>
I wouldn't know which one besides the ones already mentioned. The only
user IO pin that's connected to any of these is P102 (bank 4) which is
tied to CCLK so I can clock out user data at a later point after
configuration. A pull-up on CCLK shouldn't matter afaik.
> You might use these to find out what's going on.
>
>
>>> * You could connect pins to the fpga DIN etc.. back to your PC to verify your
>>> fpga actually get the data you expect.
>
>
>>Would data pushed in through JTAG appear on DIN? I could write something
>>that checks TDO but I'm told the spartan spits out zeroes or other
>>nonsense when I'm shifting data in.
>
>
> My idea was to attach a wire directly to TDI/TDO + TCK back into an INPUT pin
> of the parallell port to verify data.
>
>
Hmm. Not sure if that's possible, I'd need at least a tool to sample the
parallel port correctly. I'll check the data I'm sending to the FTDI
first, maybe something odd is happening in there.
>>Thorsten Trenz wrote:
>>
>>>Hi,
>>>
>>>Try to switch the modepins to JTAG only. Do you use a PC3 clone? There
>>>seems to be some problems in certain impact versions with PC3 and S3 if
>>>the chip is not in JTAG only mode.
>
>
>>The programmer is an FTDI FT2232 using an homebrew XSVF parser. I
>>believe I've got all the bugs worked out of the software since
>>programming the CPLD goes without a problem.
>
>
> Verify board connections -> Power -> Clocks -> Other.
>
> I think also that if you try to program:
> Onboard USB -> XCF01S eeprom
> eeprom -> FPGA
>
> You add more steps that may fail.
That's why I'm not and didn't mention the eeprom at all at first ;)
> Also you could try to manually read if the contents of the XCF01S is what
> you expect.
>
>
>>it's a XCF04S. I've got some other issues with that one
>>however, it seems that is has some dead banks which is why I'm trying to
>>program the fpga directly in the first place. As far as I can tell these
>>two problems are unrelated.
>
>
> So you need to alter M[0:2] pins to 1-0-1 (ds099 p45).
> And according to table 26 (ds099 p45) you need at least an XCF02S.
> So schematic is contradictive.. :)
>
Since I'm using an XCF04S I have twice the space I really need so I'm
not sure why my schematic is contradictive here. :)
> Your schematic would be easier to follow if you added consistent chip
> identifications ie Ux XC3S400 etc..
>
> Also soldering pads for debug fixes could be something to have in mind for
> later revisions. Assume failure ;)
>
Yeah, that's the big lesson out of all this; use busses and name
everything correctly. You're not the first to be confused by the
schematic. Soldering pads is also a good one, I was stubborn enough not
to add any, which is dumb.
Thanks so far anyway :)
Cheers,
Gabor
<mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com>
wrote:
> Sky46...@trline5.org wrote:
> >>> * Check power for any dips or transients.
>
> >>My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't
> >>really know what's causing this (it's just below the minimum required,
> >>isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V.
>
> > XC3S400-PQ208
>
>
>
>
>
> >>> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B,
> >>> CCLK, etc)
>
> >>M[2:0] are all tied to ground, and changing this would again require
> >>some force so I'd rather not. This shouldn't matter afaik, since you can
> >>always program using JTAG anyway, right? Likewise, when configuring
> >>using JTAG it doesn't matter what CCLK is, does it? I mentioned the
> >>state of INIT_B, PROG_B and DONE earlier.
>
> > M[2:0] = 000 => Master serial mode according to datasheet ds099 page 45.
> > So CCLK will matter. Btw, check if CCLK (2.5V) does output a proper waveform
> > at the eeprom input (Pin3 CLK). And that eeprom output is correct at the fpga.
>
> > Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V
>
> Sorry you lost me - is this a problem? I followed figure 4 of xapp453 to
> Rpar is R24 in case you can't find it in my (unfortunately somewhat
> confusing) schematic.
>
> The only changes I made is the DONE pin connection because I want to
> imitate the behavior of Figure 1 of xapp694, which makes it possible to
I would still recommend trying to get the XCF04S out of the loop.
As I mentioned before, there are known issues with the serial
data stream from the PlatformFlash interfering with JTAG programming.
Perhaps you could unsolder the part and just wire from its TDI
to TDO pin. You may need to generate new SVF files for the shorter
chain, but I think it's worth a try since everything else has
failed...
Regards,
Gabor
Sky4...@trline5.org
>Still can't program the fpga though.
>> Check that your oscillator does have proper power. And outputs a correct
>> waveform at the XC3S400 input (Bank5 GCLK2, P76).
>> (LVTTL 0.8 - 2.0 swing + flanks)
>This is where it gets annoying, I don't have anything to check out the
>waveform with. I'll have to drag everything to uni tomorrow if I want to
>see what's happening on such lines which is a much bigger effort than
>just taking the PCI card - I'll do it anyway, but still. It would be
>easier if I was able to program the fpga so I could fling a little
>counter-thing on it outputting it to the led.
You could also use a "divide by N" approach so you can get an estimate that the
oscillator work properly.
>> Also use program directly via JTAG mode to start with, only when that works
>> try eeprom. The first bitstream ("program") should be something simple like
>> pulsing a LED.
>Right now the program is exactly (except for pinout of course) the same
>as the thing I flashed succesfully into the CPLD. It had the led tied to
>counter[25] where counter = counter + 1 on every posedge clk. I'm
>completely ignoring the eeprom at the moment.
You could try this for an arbitrary divide by N:
if( count < 10000000 )
count = count + 1;
else
begin
count = 0;
led_buffer = led_buffer ^ 1;
end
>It's FTDI tdi -> XCF04S -> XC3S400 -> XC95144XL -> FTDI tdo
All TDO/TDIs with all outputs wired to inputs ..?
>All documentation seems to say that M[2:0] don't matter at all when you
>want to program using JTAG, say, the first line of the chapter "JTAG
>Configuration Mode" of ug332 (page 187).
>http://www.xilinx.com/support/documentation/user_guides/ug332.pdf
"Spartan"-3 Generation FPGAs have a dedicated four-wire IEEE 1149.1/1532 JTAG
port that is always available any time the FPGA is powered and regardless of
the mode pin settings. However, when the FPGA mode pins are set for JTAG mode
(M[2:0] = <1:0:1>), the FPGA waits to be configured via the JTAG port after a
power-on event or after PROG_B is pulsed Low."
(ug332 p187)
The JTAG *interface* is available at all times. But the FPGA will only be
configured by JTAG if the mode pins are M[2:0] = 101.
(An exception might by with JSTART instruction, but I'm not sure).
>> Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V
>Sorry you lost me - is this a problem? I followed figure 4 of xapp453 to
>enable 3.3V powered programming;
>http://www.xilinx.com/support/documentation/application_notes/xapp453.pdf
>Rpar is R24 in case you can't find it in my (unfortunately somewhat
>confusing) schematic.
I might be wrong on this, but CCLK ought to be LVCMOS25 and the XCF04S ought
to be LVTTL. Thus voltage levels might mismatch if you'r unlucky.
LVCMOS25 Vil=0.7 Vih=1.7
LVTTL Vil=0.8 Vih=2.0
(ds099 p61)
>I wouldn't know which one besides the ones already mentioned. The only
>user IO pin that's connected to any of these is P102 (bank 4) which is
>tied to CCLK so I can clock out user data at a later point after
>configuration. A pull-up on CCLK shouldn't matter afaik.
You have also set HSWAP_EN to low. This might affect.
>> My idea was to attach a wire directly to TDI/TDO + TCK back into an
>> INPUT pin of the parallell port to verify data.
>>
>Hmm. Not sure if that's possible, I'd need at least a tool to sample the
>parallel port correctly. I'll check the data I'm sending to the FTDI
>first, maybe something odd is happening in there.
Ohwell.. it's so easier on the unix side of things ;)
But there are free .dll files on the internet that will make it work on win32.
>That's why I'm not and didn't mention the eeprom at all at first ;)
It's still in the scanchain ;), and in engineering the devil is in the details.
>Since I'm using an XCF04S I have twice the space I really need so I'm
>not sure why my schematic is contradictive here. :)
The schematic have more than one designation for the same chip ;)
Michael Meeuwisse
I'll try it the moment I can program it ;)
>
>>It's FTDI tdi -> XCF04S -> XC3S400 -> XC95144XL -> FTDI tdo
>
>
> All TDO/TDIs with all outputs wired to inputs ..?
>
>
>>All documentation seems to say that M[2:0] don't matter at all when you
>>want to program using JTAG, say, the first line of the chapter "JTAG
>>Configuration Mode" of ug332 (page 187).
>>http://www.xilinx.com/support/documentation/user_guides/ug332.pdf
>
>
> "Spartan"-3 Generation FPGAs have a dedicated four-wire IEEE 1149.1/1532 JTAG
> port that is always available any time the FPGA is powered and regardless of
> the mode pin settings. However, when the FPGA mode pins are set for JTAG mode
> (M[2:0] = <1:0:1>), the FPGA waits to be configured via the JTAG port after a
> power-on event or after PROG_B is pulsed Low."
> (ug332 p187)
>
> The JTAG *interface* is available at all times. But the FPGA will only be
> configured by JTAG if the mode pins are M[2:0] = 101.
> (An exception might by with JSTART instruction, but I'm not sure).
>
I keep on arguing that it shouldn't matter, but to be absolutely on the
safe side I'll make it possible tomorrow to set M2 and M0 to 2.5V. I
really hope I'm wrong and changing this makes the problems go away.
>
>>>Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V
>
>
>>Sorry you lost me - is this a problem? I followed figure 4 of xapp453 to
>>enable 3.3V powered programming;
>>http://www.xilinx.com/support/documentation/application_notes/xapp453.pdf
>>Rpar is R24 in case you can't find it in my (unfortunately somewhat
>>confusing) schematic.
>
>
> I might be wrong on this, but CCLK ought to be LVCMOS25 and the XCF04S ought
> to be LVTTL. Thus voltage levels might mismatch if you'r unlucky.
> LVCMOS25 Vil=0.7 Vih=1.7
> LVTTL Vil=0.8 Vih=2.0
> (ds099 p61)
>
Good point, it seems the XCF04S wants at least 2.0V according to ds123
when in 3.3V operation. This might be a problem if the fpga can't fully
pull CCLK up to 2.5V. I'll have to check tomorrow.
>
>>I wouldn't know which one besides the ones already mentioned. The only
>>user IO pin that's connected to any of these is P102 (bank 4) which is
>>tied to CCLK so I can clock out user data at a later point after
>>configuration. A pull-up on CCLK shouldn't matter afaik.
>
>
> You have also set HSWAP_EN to low. This might affect.
>
It only seems to affect other IO pins not used during configuration and
when tied low it enables the pull-ups. So only P102 is interesting here,
but shouldn't cause problems. Again, I'll have to see tomorrow what CCLK
is actually doing.
>
>>>My idea was to attach a wire directly to TDI/TDO + TCK back into an
>>>INPUT pin of the parallell port to verify data.
>>>
>>
>>Hmm. Not sure if that's possible, I'd need at least a tool to sample the
>>parallel port correctly. I'll check the data I'm sending to the FTDI
>>first, maybe something odd is happening in there.
>
>
> Ohwell.. it's so easier on the unix side of things ;)
> But there are free .dll files on the internet that will make it work on win32.
>
Har har :)
I'll see what I can do. I haven't gotten to checking the FTDI output yet.
>
>>That's why I'm not and didn't mention the eeprom at all at first ;)
>
>
> It's still in the scanchain ;), and in engineering the devil is in the details.
>
>
>>Since I'm using an XCF04S I have twice the space I really need so I'm
>>not sure why my schematic is contradictive here. :)
>
>
> The schematic have more than one designation for the same chip ;)
>
I've been looking at this schematic for a few months now and it's the
first time I'm noticing it. X__x I'll change it ASAP.
Cheers,
Falk Brunner
Regards
Falk
Sky4...@trline5.org
>Sky4...@trline5.org wrote:
>> Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:
>> I might be wrong on this, but CCLK ought to be LVCMOS25 and the XCF04S ought
>> to be LVTTL. Thus voltage levels might mismatch if you'r unlucky.
>> LVCMOS25 Vil=0.7 Vih=1.7
>> LVTTL Vil=0.8 Vih=2.0
>> (ds099 p61)
>>
>Good point, it seems the XCF04S wants at least 2.0V according to ds123
>when in 3.3V operation. This might be a problem if the fpga can't fully
>pull CCLK up to 2.5V. I'll have to check tomorrow.
I checked the datasheet again, and you'r in the clear because:
Output of LVCMOS25: Vol=0.4 Voh=Vcco-0.4 => Voh=2.1
(ds099 p62)
Input of LVTTL: Vil=0.8 Vih=2.0
Input of LVCMOS33: Vil=0.8 Vih=2.0
But with a 0.1V margin by definition! So good signal is a must.
Btw, I'm going to check if JTAG configuration works in non-jtag mode. Might
be useful to know.
Thorsten Trenz
> All documentation seems to say that M[2:0] don't matter at all when you
> want to program using JTAG, say, the first line of the chapter "JTAG
> Configuration Mode" of ug332 (page 187).
> http://www.xilinx.com/support/documentation/user_guides/ug332.pdf
Maybe, but our experience shows, that this is not always true. We had a
board, which programmed fine with HW-USB, but failed in a similar way
like yours with PC3. Choosing JTAG only solved the problem.
Brian Davis
>
> I keep on arguing that it shouldn't matter, but to be absolutely on the
> safe side I'll make it possible tomorrow to set M2 and M0 to 2.5V. I
> really hope I'm wrong and changing this makes the problems go away.
>
configuration and mode select lines in various PROM/FPGA
families; common symptoms are failed JTAG configuration,
failed FPGA startup, failed DCM startup, etc.
Sometimes these have been patched in Impact, sometimes with
a die revision of the PROM or FPGA.
For Spartan-3, try these:
AR #22255 - Spartan-3 Configuration - JTAG configuration
completes successfully, but the device is not fully
operational or a verify fails
AR #9013 - Spartan-3/-E/-A - JTAG configuration might fail
when the PROM is loaded with data different from the bit file
Other possibly useful things :
AR #20047 - Spartan-3/-3E/-3A Configuration - The DONE pin
goes High,but the device does not start up (I/Os are
inactive/3-stated)
AR #11778 - Virtex/-E/-II/-II Pro, Spartan-II/-IIE/-3 -
Device configures correctly after PROG is pulsed, but
DLL/DCM/DCI does not function correctly when reconfigured
AR #24862 - PROM-XCF00P - When playing an SVF file to the
XCF00P device, pulsing PROG after file completion does not
cause a configuration
AR #16829 - Virtex and Spartan FPGAs - How does the JTAG
JPROGRAM instruction work?
AR #14444 - XC18V00/XC1700/XCFxx - PROM frozen after the power
cycling test; configuration fails after power-on reset/initial
power up. What are the requirements for power cycling
XC1700/XC18V00/XCFxx PROM?
AR #4219 - 9.1i BitGen - Why does Virtex not pass data to DOUT?
What is the purpose of the "-g DebugBitstream" option? How does
a "debug bitstream" differ from a normal bitstream?
have fun,
Brian
Michael Meeuwisse
Replying to myself here for the moment.
Michael Meeuwisse wrote:
> This is where it gets annoying, I don't have anything to check out
> the waveform with. I'll have to drag everything to uni tomorrow if I
> want to see what's happening on such lines which is a much bigger
> effort than just taking the PCI card - I'll do it anyway, but still.
> It would be easier if I was able to program the fpga so I could fling
> a little counter-thing on it outputting it to the led.
>
The only scope available was a 20MHz one (the clock should be running at
50) which didn't help. I'm seeing a DC voltage ~1.10V and AC voltage of
~2.3V on my (rather embarrassingly cheap) multimeter which makes me
believe there's a clock running on that pin.
>> The JTAG *interface* is available at all times. But the FPGA will only be
>> configured by JTAG if the mode pins are M[2:0] = 101.
>> (An exception might by with JSTART instruction, but I'm not sure).
>>
>
> I keep on arguing that it shouldn't matter, but to be absolutely on the
> safe side I'll make it possible tomorrow to set M2 and M0 to 2.5V. I
> really hope I'm wrong and changing this makes the problems go away.
>
Well I'll be damned. It scared the hell out of me to unsolder a few of
the fpga pins but I can now select between mode 101 (JTAG) and 000
(Master Serial) with a simple pin header. This results in a status
register (before programming) of 0x30B00000 and 0x31B00000 or in other
words;
0011 0001 1011 - no CRC error, DCM locks, DCI Matches, GHIGH_B
deasserted, Mode 101 JTAG, INIT pin high.
I especially like the last one, if I measure it on the print it is
indeed still high after programming - afaik this means that the chip is
programmed correctly without any CRC errors. The values of the
configuration pins are;
INIT_B: 3.3V (high)
PROG_B: 2.5V (high)
DONE: 0V (low)
So why isn't it starting up after that? I've tried doing a runtest (go
to RTI state, output a 1000 clockticks) directly after programming and
the startup clock is set to JTAG in ISE. Didn't seem to help, so
suggestions are once again welcome.
Cheers,
Sky4...@trline5.org
>50) which didn't help. I'm seeing a DC voltage ~1.10V and AC voltage of
>~2.3V on my (rather embarrassingly cheap) multimeter which makes me
>believe there's a clock running on that pin.
I think DC voltage is the right one considering it's pulsed signal and that
the frequency is way above what the multimeter can detect.
Btw, Average of LVTTL threesholds 0.8 and 2.0 is 1.4V :)
20 MHz scope might be doable. Select the fastest timebase and enable 10x
timebase. Adjust for higher intensity. And you should see a *tiny* weak signal.
Probes matter too ofcourse ;)
If you don't have money/equipment then you got to use your mind+time instead ;)
>Well I'll be damned. It scared the hell out of me to unsolder a few of
>the fpga pins but I can now select between mode 101 (JTAG) and 000
>(Master Serial) with a simple pin header. This results in a status
>register (before programming) of 0x30B00000 and 0x31B00000 or in other
>words;
>0011 0001 1011 - no CRC error, DCM locks, DCI Matches, GHIGH_B
>deasserted, Mode 101 JTAG, INIT pin high.
>I especially like the last one, if I measure it on the print it is
>indeed still high after programming - afaik this means that the chip is
>programmed correctly without any CRC errors. The values of the
>configuration pins are;
>INIT_B: 3.3V (high)
Shouldn't INIT_B be pull-up to 2.5V ? (R22 68R)
Though the XCF04S eeprom might have another opinion on this :)
>PROG_B: 2.5V (high)
>DONE: 0V (low)
>So why isn't it starting up after that? I've tried doing a runtest (go
>to RTI state, output a 1000 clockticks) directly after programming and
>the startup clock is set to JTAG in ISE. Didn't seem to help, so
>suggestions are once again welcome.
My suggestion is program that blinks a led (P77,P78) with help of the
50 MHz oscillator (P76).
According to your schematic: http://wacco.mveas.com/img/schema1d.png
You haven't wired anything to the 'DONE' pin (P103).
In ds099.pdf p103:
"A Low-to-High output transition on this bidirectional pin signals the
end of the configuration process.
The FPGA produces a Low-to-High transition on this pin to
indicate that the configuration process is complete. The DriveDone
bitstream generation option defines whether this pin functions as
a totem-pole output that actively drives High or as an open-drain
output. An open-drain output requires a pull-up resistor to produce
a High logic level."
So IF you have defined DONE as TOTEM-pole, you must NOT attach a PULL-up.
If you have defined DONE as OPEN-drain, you must attach a PULL-up to 2.5V.
ds099.pdf p47 have an illustration on this.
Example .ut file:
-g CclkPin:PULLUP
-g TdoPin:PULLNONE
-g M1Pin:PULLDOWN
-g DonePin:PULLUP
-g StartUpClk:JTAGCLK
-g M0Pin:PULLUP
-g M2Pin:PULLUP
-g ProgPin:PULLUP
-g TckPin:PULLUP
-g TdiPin:PULLUP
-g TmsPin:PULLUP
-g LCK_cycle:NoWait
-g Security:NONE
-m
-g Persist:No
And don't forgett that pesky Electrostatic-Sensitive-Devices during rework ;)
Michael Meeuwisse
Sky4...@trline5.org wrote:
> So IF you have defined DONE as TOTEM-pole, you must NOT attach a PULL-up.
> If you have defined DONE as OPEN-drain, you must attach a PULL-up to 2.5V.
I've set "Configuration pin done" to Float and checked "Drive done pin
high" as suggested by table 2.6 of ug332.
The thing is that I'm not getting CRC errors now, but Done won't go high
either. Since this sounded like an entirely new problem I once again
started hunting google and found some similar errors where it seemed
like the byte order of the programmer was incorrect but nothing definitive.
So I'm wondering if I'm interpreting the XSVF file correct. It has a
command like this;
0D...data like...800633554CAAFFFF
If I understand the docs (xapp503 is helpful, the example implementation
of xapp058 as well) correctly, I have to output it as this;
FFFFAA4C55330680 with (for example) 06 being "clock out a 0, then 11,
then another 5x 0".
Also, if the first byte in after a command like 0D says for example 3F
and I've got to clock out x bytes + 6 bits, I'm clocking out the x
bytes, then 5x a 1, and the last 1 while switching to a new state. Or
when the next command is more data (like another 0D command) I just
clock out 6x a 1. This last bit would be the '2' in '3'.
In iMPACT I program the XC3S400 directly with the .bit file so if the
bit file requires any bit/byte flipping I assume iMPACT does it.
Is this all correct? It seems to work without an hitch for XSIR commands
and the like but I'm worried the bit file shouldn't be flipped like this.
Cheers,
Sky4...@trline5.org
>bit file requires any bit/byte flipping I assume iMPACT does it.
You can use this software to program .bit files directly from the parallel
port: http://svn.wantstofly.org/jtag/trunk/
And this parallel cable hardware:
http://www.xilinx.com/support/programr/jtag_cable.pdf
At least I know this works.
AugustoEinsfeldt
I am jumping on this subject now but I may have few words on it.
These FPGAs are very easy to configure. They allways work well.
There are several simple and common mistakes that can prevent of
having it working properly. Maybe you have already passed them but
here they are:
1) be sure the BIT file generated has the correct option for
innitialization clock source. The default option is the CCLK for
Master or Slave Serial mode. When you configure using JTAG you must
change it to JTAG CLOCK. The IMPACT tool normally does it for you with
a warning when you are going to configure the device. But in some
cases it may not do the bit change and the FPGA won't innitialize even
if it configures correctly.
2) The DONE pin must have a pull-up. In your schematic it is floating.
The internal DONE circuit requires a very fast rising time and the pin
must have a strong pull-up externaly. Something like 220 or 330ohms to
the 2.5V supply rail (for your FPGA). Sometimes driving the DONE pin
HIGH (BIT file option) may help but leaving it floating is not a good
design practice. A LED in the DONE pin is always a must because then
you can see the FPGA is correctly configured whenever you make a
change in the bit file stored in the PlatformFLASH.
When the system starts to work don't forget that you will need a power
cycle every time you re-write the PlatformFLASH with a new design in
order to have it downloaded to the FPGA. It is a common mistake doing
the update in the FLASH but forgeting the FPGA will get it only after
a reset in the PROGRAM_B pin.
You do not need to change the mode pins to gain JTAG control and
configuration. You can keep them at 000 (Master Serial) and it will
work perfectly. If you had difficulties with JTAG before it was
because some hardware problem or because the USB code translation to
JTAG tha may not use the proper commands. When you use a Xilinx cable
it works.
For a reference on how to do the circuitry for the configuration part
I would recommend to download the Spartan-3 Demo Board schematic. I
believe you can find it at Xilinx or at Digilent website.
-Augusto
Sky4...@trline5.org
>1) be sure the BIT file generated has the correct option for..
>2) The DONE pin must have a pull-up. In your schematic it is floating..
>You do not need to change the mode pins to gain JTAG control and..
>For a reference on how to do the circuitry for the configuration part
>I would recommend to download the Spartan-3 Demo Board schematic. I
>believe you can find it at Xilinx or at Digilent website.
http://www.xilinx.com/products/devkits/HW-SPAR3-SK-UNI-G.htm
http://www.xilinx.com/support/documentation/boards_and_kits/ug130.pdf
Page 57 (of 64), Figure A-4.
Correct?