Prev: ModelSim Licence problem
Next: Plateform FLASH PROM configuration using a Microblaze.
From: c d saunter on 10 Mar 2006 06:10
Hi Scott,
I can't shed any light on the issue you describe, but...

When the SRAM fails to work, does the 'socket' (i.e. the shrinkwrapped IC
and PCB etc.) on the end of the JTAG-USB cable get very very hot?

Twice now I have had occasions when programming .bit files through one of
these cables the end gets very very hot - although everything still seems
to work. Due to this and other not quite definable oddities I've switched
to programming the platform flash with .svf files and using this to
program the FPGA.

It doesn't inspire faith in the things...

cds

Scott M. Kroll (none(a)nowhere.com) wrote:
: Well, I'm not sure if anyone here has had the same problem, but I have,
: and it has been driving me nuts. My primary machine is a laptop, which
: has no parallel port, so I am stuck with USB. Also, I am in a class
: where we are doing projects using the Spartan-3 Starter Kit from Digilent.

: Since I have no parallel port, I have been using Digilent's JTAG-USB
: cable, which, for the most part, works great. However, there are two
: problems.

: 1. You cannot use Xilinx IMPACT to program the Spartan-3
: 2. The external SRAM does not work when using a .bit file

: Well, #2 seems awfully strange. I know it did for me, I thought I was
: having a problem with VHDL, and that's why I thought it wasn't working.
: Well, I spent a long time tinkering with it over our winter break (I
: know, I know, but it's what I did) and just today I came up with the
: solution.

: A little explanation for this is probably needed. Basically, anything I
: write and compile in IMPACT would work fine. LEDs light up, the
: 7-segment display works fine, everything I've done works great.
: However, every time I tried to write to the SRAM, nothing changed, I
: simply got back garbage/random data. Every time, no questions asked, it
: just didn't work. To make a long story short, here's a solution I
: discovered (which, is a whole another story to how I figured it out).

: 1. Start IMPACT
: 2. Edit -> Add Device -> Xilinx Device
: 3. Loaded c:\Program Files\Xilinx\spartan3\data\xc3s200_ft256.bsd
: 4. Right-Clicked Device, Assigned Configuration File
: 5. Mode -> File Mode
: 6. Clicked SVF-STAPL-XSVF tab, clicked "Yes" when it asked to load from
: Boundary Scan
: 7. Chose to generate a new SVF file, named it
: 8. Right-Clicked Device, chose Program.
: 9. Output -> SVF -> Stop Writing to SVF File
: 10. Quit Impact
: 11. Started Export, did Device Scan, loaded SVF into the xc3s200, set
: the prom to bypass, hit program. Everything worked right.

: Seems like a strange solution, but what I want to know, has anyone here
: had a problem like this? I have a feeling that loading a different .BSD
: file for other Xilinx chips should work just as well with the JTAG-USB
: cable/Digilent's ExPort software, but I couldn't tell you.

: Hope this helps people out.

: If anyone wants to contact me with any more information via email,
: please use: skroll at gmail dot com

From: Scott M. Kroll on 10 Mar 2006 12:18
Believe it or not, just taking jumper M0 off let me program the .bit
file and it worked. But the USB cable is always hot, even when not
programming (it's plugged into my laptop right now, without the
Spartan-3 Board, and it's very warm/near hot. Still, I think that
Digilent needs to do a little work with their software to avoid this
inconvenience.

But like I mentioned before, just pulling that jumper let it work,
although it doesn't boot from the PROM anymore (because the jumper
changes a mode setting).

c d saunter wrote:
> Hi Scott,
> I can't shed any light on the issue you describe, but...
>
> When the SRAM fails to work, does the 'socket' (i.e. the shrinkwrapped IC
> and PCB etc.) on the end of the JTAG-USB cable get very very hot?
>
> Twice now I have had occasions when programming .bit files through one of
> these cables the end gets very very hot - although everything still seems
> to work. Due to this and other not quite definable oddities I've switched
> to programming the platform flash with .svf files and using this to
> program the FPGA.
>
> It doesn't inspire faith in the things...
>
> cds
>
> Scott M. Kroll (none(a)nowhere.com) wrote:
> : Well, I'm not sure if anyone here has had the same problem, but I have,
> : and it has been driving me nuts. My primary machine is a laptop, which
> : has no parallel port, so I am stuck with USB. Also, I am in a class
> : where we are doing projects using the Spartan-3 Starter Kit from Digilent.
>
> : Since I have no parallel port, I have been using Digilent's JTAG-USB
> : cable, which, for the most part, works great. However, there are two
> : problems.
>
> : 1. You cannot use Xilinx IMPACT to program the Spartan-3
> : 2. The external SRAM does not work when using a .bit file
>
> : Well, #2 seems awfully strange. I know it did for me, I thought I was
> : having a problem with VHDL, and that's why I thought it wasn't working.
> : Well, I spent a long time tinkering with it over our winter break (I
> : know, I know, but it's what I did) and just today I came up with the
> : solution.
>
> : A little explanation for this is probably needed. Basically, anything I
> : write and compile in IMPACT would work fine. LEDs light up, the
> : 7-segment display works fine, everything I've done works great.
> : However, every time I tried to write to the SRAM, nothing changed, I
> : simply got back garbage/random data. Every time, no questions asked, it
> : just didn't work. To make a long story short, here's a solution I
> : discovered (which, is a whole another story to how I figured it out).
>
> : 1. Start IMPACT
> : 2. Edit -> Add Device -> Xilinx Device
> : 3. Loaded c:\Program Files\Xilinx\spartan3\data\xc3s200_ft256.bsd
> : 4. Right-Clicked Device, Assigned Configuration File
> : 5. Mode -> File Mode
> : 6. Clicked SVF-STAPL-XSVF tab, clicked "Yes" when it asked to load from
> : Boundary Scan
> : 7. Chose to generate a new SVF file, named it
> : 8. Right-Clicked Device, chose Program.
> : 9. Output -> SVF -> Stop Writing to SVF File
> : 10. Quit Impact
> : 11. Started Export, did Device Scan, loaded SVF into the xc3s200, set
> : the prom to bypass, hit program. Everything worked right.
>
> : Seems like a strange solution, but what I want to know, has anyone here
> : had a problem like this? I have a feeling that loading a different .BSD
> : file for other Xilinx chips should work just as well with the JTAG-USB
> : cable/Digilent's ExPort software, but I couldn't tell you.
>
> : Hope this helps people out.
>
> : If anyone wants to contact me with any more information via email,
> : please use: skroll at gmail dot com
>

From: Antti on 10 Mar 2006 12:29
I belive you.

there are some 'odd' things regarding the JTAG config, when during jtag
config
some other (serial or parallel) interface what is been selected by mode
pins
does clock in a valid config header things go crazy -
there is a xilinx AR workaround also I think suggesting mode pin change

Antti

From: cs_posting on 10 Mar 2006 20:33
Scott M. Kroll wrote:
> Believe it or not, just taking jumper M0 off let me program the .bit
> file and it worked.

It just occured to me... when I program the S3 kit with impact and the
parallel cable, I get this little popup warning that it has changed
that startup clock to jtag vs whatever was in the .bit file. Might
this have anything to do with it - that change might get made in the
SVF, but be missed if you take the .bit file directly to the USB
downloader program?

From: Brian Davis on 15 Mar 2006 21:58
Scott M. Kroll wrote:
> Believe it or not, just taking jumper M0 off let me program the .bit
> file and it worked. But the USB cable is always hot, even when not
> programming (it's plugged into my laptop right now, without the
> Spartan-3 Board, and it's very warm/near hot.

I set up the Digilent USB JTAG cable (Export 1.3) and tried
a few bitfile downloads of my S3 memory test code; the results
match yours, but I can also get the bitfile download to work
with the mode jumpers all on just by doing an extra JTAG
operation as I mentioned earlier.

test notes:

- my cable also stays warm

- after changing mode jumpers, .bit file downloads & runs OK

- with JP1 completely off, M0/M1/M2 jumpers all on, after
the .bit file is downloaded (PROM in bypass), the FPGA
fails to operate ( DONE LED off, user LEDs weakly lit
during/after download ).

However, another JTAG operation will wake up the design,
(DONE LED on) and it functions correctly after a manual reset.

"Another JTAG operation" = either an initialize chain, or just
do a device ID on the FPGA or PROM

- changing the startup clock (user/JTAG) and DCM reset options in
bitgen had no effect on the problem with the mode jumpers all on.

Brian

First  |  Prev  | 
Pages: 1 2 3
Prev: ModelSim Licence problem
Next: Plateform FLASH PROM configuration using a Microblaze.