Xilinx 3E design programs fine with 500E but fails with 250E

Hi,
Ive got a design that uses the spartan XC3S500E, but when I populate
the design with the smaller, but compatible XC3S250E and generate a
bit stream to suit, it fails to program the SPI flash. With a .BIIT
and a .MCS (which works correctly when you download it direct to the
XC3S250E FPGA), it fails to program the external M25P80 SPI flash
using iMPACT 10.1 and a Platform Cable USB II jtag adaptor.

The error message I get with two different identical boards, is a
failure at address 0 (board A) and failure at address 1024 (board B)
I have repalced the flash memories on both boards as a sanity check,
but as expected, no dice.

The very same design works perfectly with 4 other boards, identical,
except populated with the 500E.

Anyone have any idea's on what I could be doing wrong?

many thanks,
steve


IMPACT 10.1 message window dump

PROGRESS_START - Starting Operation.
Identifying chain contents ....'1': : Manufacturer's ID =Xilinx
xc3s250e, Version : 1
INFO:iMPACT:1777 -
Reading C:/Xilinx/10.1/ISE/spartan3e/data/xc3s250e.bsd...
INFO:iMPACT:501 - '1': Added Device xc3s250e successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
done.
PROGRESS_END - End Operation.
Elapsed time =      1 sec.
// *** BATCH CMD : identifyMPM
// *** BATCH CMD : assignFile -p 1 -file "C:/250test.bit"
'1': Loading file 'C:/250test.bit' ...
done.
INFO:iMPACT:501 - '1': Added Device xc3s250e successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
Selected part: M25P80
// *** BATCH CMD : attachflash -position 1 -spi "M25P80"
// *** BATCH CMD : assignfiletoattachedflash -position 1 -file "C:/
250etest.mcs"
// *** BATCH CMD : attachflash -position 1 -spi "M25P80"
// *** BATCH CMD : Program -p 1 -spionly -e -v
Maximum TCK operating frequency for this device chain: 10000000.
Validating chain...
Boundary-scan chain validated successfully.
'1': SPI access core not detected. SPI access core will be downloaded
to the device to enable operations.
INFO:iMPACT - Downloading core file C:/Xilinx/10.1/ISE/spartan3e/data/
xc3s250e_spi.cor.
PROGRESS_START - Starting Operation.
'1': Downloading core...
done.
'1': Reading status register contents...
INFO:iMPACT:2219 - Status register values:
INFO:iMPACT - 0011 0111 1001 1000 0000 0000 0000 0000
INFO:iMPACT:2492 - '1': Completed downloading core to device.
INFO:iMPACT - '1': Checking done pin....done.
'1': Core downloaded successfully.
'1': IDCODE is '13' (in hex).
'1': ID Check passed.
 '1': IDCODE is '13' (in hex).
'1': ID Check passed.
 '1': Erasing Device.
'1': Programming Flash.
'1': Reading device contents...
Failed at address, 1024
'1': Verification Terminated
PROGRESS_END - End Operation.
Elapsed time =     19 sec.

Steve <srkh28@gmail.com> wrote:

>Hi,
>Ive got a design that uses the spartan XC3S500E, but when I populate
>the design with the smaller, but compatible XC3S250E and generate a
>bit stream to suit, it fails to program the SPI flash. With a .BIIT
>and a .MCS (which works correctly when you download it direct to the
>XC3S250E FPGA), it fails to program the external M25P80 SPI flash
>using iMPACT 10.1 and a Platform Cable USB II jtag adaptor.
>
>The error message I get with two different identical boards, is a
>failure at address 0 (board A) and failure at address 1024 (board B)
>I have repalced the flash memories on both boards as a sanity check,
>but as expected, no dice.
>
>The very same design works perfectly with 4 other boards, identical,
>except populated with the 500E.
>
>Anyone have any idea's on what I could be doing wrong?

Maybe the loading of the JTAG bus is different. Try to put a 22pf
capacitor on the JTAG clock line to slow it down a little. Otherwise
get a logic analyzer to see what the JTAG bus is doing.

I've had similar problems with the parallel Xilinx cable. It turned
out they steer tck, tms and tdo at the same time which is a bad idea
because it makes the timing extremely critical.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Hi Noel,

>
> Maybe the loading of the JTAG bus is different.

--> This method of programming does not use the JTAG interface as
such. A small block of code is first doenload into the FPGA that
builds a SPI type bridge to the SPI flash. Then, and image is sent via
JTAG and should be written to the SPI flash. JTAG works fine, as
downloading the image to the FPGA works correct, and the very smae
circuit works fine with the 500E.

Try to put a 22pf
> capacitor on the JTAG clock line to slow it down a little.

--> Id be inclined to avoid this - the device is 75MHz.

The entire set up works fine for the 500E, but not the 250E.

steve

Steve <srkh28@gmail.com> wrote:

>
>Hi Noel,
>
>>
>> Maybe the loading of the JTAG bus is different.
>
>--> This method of programming does not use the JTAG interface as
>such. A small block of code is first doenload into the FPGA that
>builds a SPI type bridge to the SPI flash. Then, and image is sent via
>JTAG and should be written to the SPI flash. JTAG works fine, as
>downloading the image to the FPGA works correct, and the very smae
>circuit works fine with the 500E.
>
>Try to put a 22pf
>> capacitor on the JTAG clock line to slow it down a little.
>
>--> Id be inclined to avoid this - the device is 75MHz.
>
>The entire set up works fine for the 500E, but not the 250E.

I still think this may be a timing problem somewhere. How are the
timing constraints on the SPI interface? Are the flipflops inside the
IOBs?

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Steve  wrote:
>
> Ive got a design that uses the spartan XC3S500E, but when I populate
> the design with the smaller, but compatible XC3S250E and generate a
> bit stream to suit, it fails to program the SPI flash.
> <snip>
> Anyone have any idea's on what I could be doing wrong?
>
some things to check:

 - Set the FPGA mode pins to JTAG mode, not to SPI mode, when
   programming over JTAG using the Impact SPI flash core.
  ( Otherwise the FPGA SPI boot process can fight with the JTAG port )

 - Change the JTAG clock rate used by Impact to one of the slower
speeds,
   and make sure it can reliably run the JTAG loopback test at that
rate

Brian

Hi Brian,


> =A0- Set the FPGA mode pins to JTAG mode, not to SPI mode, when
> =A0 =A0programming over JTAG using the Impact SPI flash core.

--> I can try this, but, sorta defeats having a bootable FPGA. The
500E version works fine without needing to do this.


> =A0 ( Otherwise the FPGA SPI boot process can fight with the JTAG port )

--> I think it tries 3 times to load from spi and then gives up.

>
> =A0- Change the JTAG clock rate used by Impact to one of the slower
> speeds,

--> Its not a JTAG related issue, but I have tried this for sanity. I
set the cable speed to its slowest (750Kbps) - still no go.

> =A0 =A0and make sure it can reliably run the JTAG loopback test at that
> rate

--> Loop backworks fine a 10MHZ for 1M test cycles - all passes ok, so
communicating with the device is 100% ok - allways has been.

Talking to the FPGA has always been fine - you can download projects
and things work great. the only problem is, the FPGA is unable to
write to its flash using xilinx precompiled cores, xc3s250e_spi.cor.
this spi bridge core is unique to each device and each package. The
500E PQ208 version works beautifully - but the 250E PQ208 version
seems to be a bug fest.

Is the source available for these? I expect I will have to write my
own, or bite the bullet and leave the spartan and go with altera.

steve

I just went to Xilinx's website to log a case with them.

Xilinx now screen who they feel is suitable for logging cases, and
those who they feel are not - takes a day for them to decide after you
request to log a case.

I think their patent is about to run out... I feel a change of guard
not far off.

Have you verified the SPI chip against the file to identify whether it's a programming or FPGA load
issue. 

I just had a nightmare problem with a Lattice part where the tools would sometimes generate a file
that would run in the device via JTAG but not load from SPI PROM - it was very design-content and in
some cases device type dependent. The Lattice tools look VERY similar to ISE so I wonder if there
may be some connection...

Steve wrote:
>
> > - Set the FPGA mode pins to JTAG mode, not to SPI mode, when
> >   programming over JTAG using the Impact SPI flash core.
>
> I can try this, but,
>

 If you haven't tried this mode change yet, I'd suggest
that you place it at the top of the "things to do" list.

 The recommendation to select JTAG mode during indirect
SPI programming can be found in the newer Xilinx SPI
programming application notes [Ref 1].

>
> sorta defeats having a bootable FPGA.
>

 Set it to JTAG when you connect the JTAG cable to program
the SPI flash with Impact, set it back when you are done...

 Adding a mode select jumper block hardly reduces the
functionality of a board, particularly when this mode
jumper is often needed to use the JTAG port without
experiencing the sort of problems that you are seeing.

 If you want the mode selection to be automatic, the 2mm
14 pin JTAG header pinout can be used to provide a JTAG
cable detect [Ref 2].

>
> The 500E version works fine without needing to do this.
>

 These PROM/JTAG boot conflicts can vary from part to part,
and between mask steppings of the same device.

 The earlier S3E steppings had similar BPI vs. JTAG mode
conflicts, see [Ref 3] for some examples

>
> Is the source available for these? I expect I will have to
> write my own, or bite the bullet and leave the spartan and
> go with altera.
>

 The Impact SPI core source is _not_ available [Ref 4].

 There is an example of an S3E SPI flash programmer in the
S3E starter kit examples [Ref 5], but I've never used it.

 I think there is also some sort of FlashWriter app in the
EDK, but I have no experience with that one either.

Brian

-------------

[Ref 1]  S3 SPI application notes suggesting JTAG mode jumper

XAPP974 (v1.1.3) Indirect Programming of SPI Serial Flash PROMs
with Spartan-3A FPGAs

figure 2, note 5, page 4:
"
" The jumper on the M[2] pin is an enhancement for prototyping
" and debugging, to allow changing from SPI Mode M[2:0] =3D 001
" to JTAG mode M[2:0] =3D 101.
"

Table 2, page 5:
"
" For JTAG mode for programming SPI Flash PROMS,
" set M[2:0] =3D 101
"
http://www.xilinx.com/support/documentation/application_notes/xapp974.pdf


-------------

[Ref 2] Automatic JTAG Cable Detection

  The 14 pin, 2mm Xilinx JTAG header pinout allows for the
 use of pin 13 as a cable detect.

  On the newer USB II cables, pin 13 is an open drain output
 called 'PGND' that is grounded when the cable is active:

 DS593 v1.2, page 15
 http://www.xilinx.com/support/documentation/data_sheets/ds593.pdf

  On the older Parallel IV and original Platform Cable USB
 pin 13 is a ground pin:

 DS300 v3.2
 figure 17, page 9
 http://www.xilinx.com/support/documentation/data_sheets/ds300.pdf

  So tie pin 13 to a pullup on board, and use the resulting
 logic level to select the configuration mode, either
 directly or through some logic or jumpers on the board.

  For S3E, M2 is the only pin that changes between serial
 SPI (M2=3D1) and JTAG (M2=3D0) modes, so the pin 13 pullup
 could simply be tied to the M2 line.

-------------

[Ref 3] S3E JTAG/PROM conficts & steppings

 AR #22142 - Spartan-3E Configuration - I cannot program a
 Spartan-3E FPGA via JTAG if the FPGA is in BPI Mode
 http://www.xilinx.com/support/answers/22142.htm

 2008 post listing other similar bugs:
 http://groups.google.com/group/comp.arch.fpga/msg/b06ca9faf716c347

-------------

[Ref 4] Unavailability of Impact SPI core source

XAPP974 (v1.1.3)
third paragraph, page 17
"
" The core is for iMPACT runtime use only =97 the source code
" is not available for designs.
"
http://www.xilinx.com/support/documentation/application_notes/xapp974.pdf

-------------

[Ref 5] S3E Picoblaze based SPI flash programmer
 http://www.xilinx.com/products/boards/s3estarter/files/s3esk_serial_flash.=
pdf
 http://www.xilinx.com/products/boards/s3estarter/files/s3esk_serial_flash.=
zip

Hi Brian,

Thanks for the solid response. Ill try the things you suggest to see
if that resolves the problem, but I do have a few initial comments on
some of these suggestions;

> =A0The recommendation to select JTAG mode during indirect
> SPI programming can be found in the newer Xilinx SPI
> programming application notes [Ref 1].


--> Thats somewhat dissapointing, as i have an existing design in
production based on their "Designs can migrate between
the XC3S250E and XC3S500E without further consideration." statement
found on page 189 of their DS312 datasheet (who knows if its current,
or true - does it matter?)

>
>
> > sorta defeats having a bootable FPGA.
>
> =A0Set it to JTAG when you connect the JTAG cable to program
> the SPI flash with Impact, set it back when you are done...

Hard to do with 0402 components, but ill bolt it on an see what
happends.

>
> =A0Adding a mode select jumper block hardly reduces the
> functionality of a board, particularly when this mode
> jumper is often needed to use the JTAG port without
> experiencing the sort of problems that you are seeing.

I think it does. For upgrades, plugging up to the JTAG port and
downloading is a lot easier than including instructions for jumpers,
especially when the product is closed to the world. DS312, it also
states JTAG always gets priority over other methods, well, up until
now. A jumper is a bug fix for this device, for xilinx. Again, may
have to do it, but if I have to spin the board again, its just as easy
for me to put another vendor device on there.


>
> =A0If you want the mode selection to be automatic, the 2mm
> 14 pin JTAG header pinout can be used to provide a JTAG
> cable detect [Ref 2].

--> I dont wish to be tied to just xilinx programmers. Native JTAG
interface is what we are using. JTAG has too many pins as it is.
>
>
>
> > The 500E version works fine without needing to do this.
>
> =A0These PROM/JTAG boot conflicts can vary from part to part,
> and between mask steppings of the same device.

Ive noticed with xilinx, the same part varies as well - going with an
xilinx ES part is suicide. However, since it was spelt out in DS312
its ok to swap a 250E with a 500E with only code changes, I sorta
thought that meant I could swap between a 250E and a 500E with only
code changes.

steve