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

[Steve]

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.

[Nico Coesel]

Post by Steve
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.

[Steve]

Hi Noel,

Post by Nico Coesel
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

Post by Nico Coesel
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

[Nico Coesel]

Post by Steve
Hi Noel,

Post by Nico Coesel
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

Post by Nico Coesel
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?

[Brian Davis]

Post by Steve
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

[Steve]

Hi Brian,

 - 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, sorta defeats having a bootable FPGA. The
500E version works fine without needing to do this.

  ( 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.

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

   and 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

[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.

[Mike Harrison]

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

[Brian Davis]

Post by Steve

Post by Brian Davis
- 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].

Post by Steve
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].

Post by Steve
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

Post by Steve
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] = 001
" to JTAG mode M[2:0] = 101.
"

Table 2, page 5:
"
" For JTAG mode for programming SPI Flash PROMS,
" set M[2:0] = 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=1) and JTAG (M2=0) 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 — 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

[Steve]

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;

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

Post by Steve
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...

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

 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.

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.

 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].

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

Post by Steve
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.

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

[Steve]

Hi All,



We have solved this problem to a functional degree. Thanks to all for
your help. Of 56 production boards, we were able to accurately figure
out our device short falls and produce a work around solution. Some
common facts we now know about the XIlinx 250E and 500E FPGA's.



1. The problem was not associated with purchasing the device from a
non-authorised vendor or device stepping

2. The Xilinx Spartan 500E works as advertised

3. The Xilinx Spartan 250E does not work as advertised (the supplied
SPI flash programming core with ISE 10 and later is precariously
flawed)

4. Using the supplied SPI core with 250E's results in corrupt code
being written to flash causing excess (950mA+) current to be consumed
by VCCint (1V2) and the device failing to execute downloads. We dont
know what is consuming the excess current, but speculate the cause to
be from high speed boot retries of the corrupt code. As we have no
information regarding this core, we can only speculate on what our CRO
and analyser tell us.

5. Behaviour is 100% reliably repeatable.

6. All 250E boards perform correctly and pass function and performance
tests when used with tools other than Xilinx Impact and their SPI
programming core



For those stuck with the 250E and a serial SPI flash, the only
solution to program the attached SPI flash is to use Picoblaze, or
program the SPI device independently.





steve

[c***@hotmail.com]

Post by Steve
4. Using the supplied SPI core with 250E's results in corrupt code
being written to flash causing excess (950mA+) current to be consumed
by VCCint (1V2) and the device failing to execute downloads. We dont
know what is consuming the excess current, but speculate the cause to
be from high speed boot retries of the corrupt code.

Interesting... I had a single example of an 250E turn itself into a
space heater a few weeks back while working on code for loading it
from an embedded processor. It had previously worked flawlessly, as
did the replacement. Perhaps there are certain invalid bit streams
that will introduce enough internal "shorts" to kill it?

[Steve]

Post by c***@hotmail.com
Interesting... I had a single example of an 250E turn itself into a
space heater a few weeks back while working on code for loading it
from an embedded processor.  It had previously worked flawlessly, as
did the replacement.  Perhaps there are certain invalid bit streams
that will introduce enough internal "shorts" to kill it?

Im not suprised. I feel only xilinx could achieve a hardware failure
thru code.

Ive designed with a lot of xilinx devices, and use a lot of devices
with work. They have been great. But its not like that anymore.It all
began with their idiot "inputs only" on banks, then quadrant "global"
clocks, then weird power allocations. All their devices have short
falls now. We have put our spartan 6 products on hold for a while, but
are moving ahead with arria and Cyclone III's. Not a good sign. But
devices not working as advertised is the worst. After this last
horrible ordeal i feel i have changed camps.

[a***@googlemail.com]

Post by Steve
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;

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

Post by Steve
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...

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

 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.

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.

 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].

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

Post by Steve
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.

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

Hi Steve,

i almost always used own JTAG-SPI bypass soft cores and own PC host
software for SPI flash programming
(before the feature was added to impact)

as I see the impact solution is still a problem. eh it would be so
much better if xilinx would supply source
code of the spi indirect cores... but they do not :(

Antti

[Steve]

Hi Antii,

Yep, i used too program direct as welll. But with the ease of using a
bridge to a standard interfcae such as SPI or BPI, i dont think I ever
want to go back to that method. Its just so easy to provide a new
level of support to your customers without have pages of inxtructions
or esoteric programming equipment. Xilinx wont fix the bug. If the bug
wasnt that bad, they would have already. The 250E is toast.

Post by a***@googlemail.com
Hi Steve,
i almost always used own JTAG-SPI bypass soft cores and own PC host
software for SPI flash programming
(before the feature was added to impact)
as I see the impact solution is still a problem. eh it would be so
much better if xilinx would supply source
code of the spi indirect cores... but they do not :(
Antti- Hide quoted text -
- Show quoted text -

[a***@googlemail.com]

Post by Steve
Hi Antii,
Yep, i used too program direct as welll. But with the ease of using a
bridge to a standard interfcae such as SPI or BPI, i dont think I ever
want to go back to that method. Its just so easy to provide a new
level of support to your customers without have pages of inxtructions
or esoteric programming equipment. Xilinx wont fix the bug. If the bug
wasnt that bad, they would have already. The 250E is toast.

Post by a***@googlemail.com
Hi Steve,
i almost always used own JTAG-SPI bypass soft cores and own PC host
software for SPI flash programming
(before the feature was added to impact)
as I see the impact solution is still a problem. eh it would be so
much better if xilinx would supply source
code of the spi indirect cores... but they do not :(
Antti- Hide quoted text -
- Show quoted text -- Hide quoted text -

- Show quoted text -

I did NOT program SPI-direct :)

I programed SPI indirect using my own JTAG IP cores and pc side
software

Antti

[Steve]

Hi Antii,

Wow, I missed that bit - ive been so used to info not being what I
wanted to read, that I totally over looked the fact you had written
your own!
Dangling that carrot in front of me is too much, so

Would it be ok if I could have a copy??


Thanks,
Steve

Post by a***@googlemail.com

Post by Steve
Hi Antii,
Yep, i used too program direct as welll. But with the ease of using a
bridge to a standard interfcae such as SPI or BPI, i dont think I ever
want to go back to that method. Its just so easy to provide a new
level of support to your customers without have pages of inxtructions
or esoteric programming equipment. Xilinx wont fix the bug. If the bug
wasnt that bad, they would have already. The 250E is toast.

Post by a***@googlemail.com
Hi Steve,
i almost always used own JTAG-SPI bypass soft cores and own PC host
software for SPI flash programming
(before the feature was added to impact)
as I see the impact solution is still a problem. eh it would be so
much better if xilinx would supply source
code of the spi indirect cores... but they do not :(
Antti- Hide quoted text -
- Show quoted text -- Hide quoted text -

- Show quoted text -

I did NOT program SPI-direct :)
I programed SPI indirect using my own JTAG IP cores and pc side
software
Antti- Hide quoted text -
- Show quoted text -

[a***@googlemail.com]

Post by Steve
Hi Antii,
Wow, I missed that bit - ive been so used to info not being what I
wanted to read, that I totally over looked the fact you had written
your own!
Dangling that carrot in front of me is too much, so
Would it be ok if I could have a copy??
Thanks,
Steve

Post by a***@googlemail.com

Post by Steve
Hi Antii,
Yep, i used too program direct as welll. But with the ease of using a
bridge to a standard interfcae such as SPI or BPI, i dont think I ever
want to go back to that method. Its just so easy to provide a new
level of support to your customers without have pages of inxtructions
or esoteric programming equipment. Xilinx wont fix the bug. If the bug
wasnt that bad, they would have already. The 250E is toast.

Post by a***@googlemail.com
Hi Steve,
i almost always used own JTAG-SPI bypass soft cores and own PC host
software for SPI flash programming
(before the feature was added to impact)
as I see the impact solution is still a problem. eh it would be so
much better if xilinx would supply source
code of the spi indirect cores... but they do not :(
Antti- Hide quoted text -
- Show quoted text -- Hide quoted text -

- Show quoted text -

I did NOT program SPI-direct :)
I programed SPI indirect using my own JTAG IP cores and pc side
software
Antti- Hide quoted text -
- Show quoted text -- Hide quoted text -

- Show quoted text -

i posted to the brain :)

Antti

[Alex Freed]

Post by a***@googlemail.com
I did NOT program SPI-direct :)
I programed SPI indirect using my own JTAG IP cores and pc side
software

From the time it takes impact to "indirectly" program a 500E even when
it works it appears that they use JTAG to toggle the FPGA's pins so that
it communicates with the EEPROM. At the same time Xilinx has an app note
with a Picoblaze doing the flashing that works just fine but requires
another serial channel. I wonder what stops them from creating a "UART"
via the JTAG "user" instruction and use that. So I ended up creating a
core that read the bits from a memory card and programs the flash in a
few seconds.

P.S. I'm the other person on Steve's project. His "we" was not royal.


-Alex.

[Petter Gustad]

requires another serial channel. I wonder what stops them from
creating a "UART" via the JTAG "user" instruction and use that. So I

I've been using the JTAG user module to program various attached
devices for many years. Should not be a problem, but of course the
vendors would probably like you to use their device specific IP.

Petter

[a***@googlemail.com]

Post by a***@googlemail.com
I did NOT program SPI-direct :)
I programed SPI indirect using my own JTAG IP cores and pc side
software

 From the time it takes impact to "indirectly" program a 500E even when
it works it appears that they use JTAG to toggle the FPGA's pins so that
it communicates with the EEPROM. At the same time Xilinx has an app note
with a Picoblaze doing the flashing that works just fine but requires
another serial channel. I wonder what stops them from creating a "UART"
via the JTAG "user" instruction and use that. So I ended up creating a
core that read the bits from a memory card and programs the flash in a
few seconds.
P.S. I'm the other person on Steve's project. His "we" was not royal.
-Alex.

the BSCAN can almost directly be bypassed to IO for SPI indirect
i used hower a very small core for this

hm, if i recall i had intermediate sync protocol what i called SSP
(sync serial protocol) what is essentially spi without select :)
so i had BSCAN-SSP and SSP-SPI modules

the beaty of that is that it is really simple to convert SPI flash
programming data to say SVF and play back that SVF
to the FPGA JTAG and the spi chips gets accessed

i did not use svf/jam (but own software), however using svf/jam would
be easy too, then you can use vendor tools to access the jtag
interface (impact, quartus programmer, whatever)

funny.. I am just now thinking about putting live into that project
http://groups.google.com/group/antti-brain/files?hl=en

U2TOOL jpeg ist current development photo of the hardware gadget
it is already working as USB Blaster and I was able to use Actel
SVF converted to jam, and Altera commandline jam player to
program an ProAsic3 :)
I wonted to test with Stratix board, but i thas the +- in the 9V jack
reversed :(

I had for some years another nice application, FPGA freqeuncy meter
it used LPT based JTAG cable and measured frequency (without the
need of any known clocks connected to FPGA), with usb cables
that isnt possible, well with U2TOOL it will be again.. so it makes
fun
to develop it.

i can dig up my JTAG-SPI ip cores.. the approuch was rather nice
(specially because of easy svf/jam programming)

Antti