Prev: ModelSim Licence problem
Next: Plateform FLASH PROM configuration using a Microblaze.
From: Scott M. Kroll on 8 Mar 2006 07:54
Brian Davis wrote:
> Scott M. Kroll wrote:
>> 2. The external SRAM does not work when using a .bit file
>>
> Could you clarify exactly what you mean here; are you
> using the Digilent JTAG utility to program the on-board prom,
> or to directly configure the FPGA via JTAG?
>
> One thing I've seen with IMPACT generated SVF files on both
> V2P's and the S3 starter kit, is the need for one last JTAG
> operation to "wake up" the part.
>
> IIRC, in the Digilent tool, after loading the FPGA with the
> config PROM in BYPASS, just try a device id on the config
> PROM and see if that fixes it.
>
> Also, I think I've had to change the JP1 bitstream readback
> jumper setting to "disable" to get consistent results for JTAG
> download; you may also want to change the configuration mode
> jumpers to "JTAG"
>
> If the DCM doesn't start up after re-configuration, your static
> logic would work but any DCM clocked logic would not:
> Answer Record 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"
>
> Similar things can happen if the part almost, but not quite, finishes
> configuration and ends up in a configured state with GSR or GTS
> still asserted.
>
> To help sort out what is happening, create a test design with:
> - an LED driven from a switch input (no registers)
> - a blinky LED counter driven from the input clock WITHOUT a DCM
> - a blinky LED counter driven from a DCM sourced clock
> - LED's on DCM LOCKED and "clock stopped" status bit
>
> Brian
>

It's very strange, but here's what I meant: I am using Digilent's JTAG
utility (it's called Export) to program the FPGA via JTAG. Using IMPACT
to create the .bit file, and then program the FPGA with the .bit.
Digilent's Export tool only supports .bit and .svf files. If I program
the FPGA via the .bit file, the SRAM never writes, and feeds back random
garbage, never writes correctly. Some ramtesting vhdl I found for the
Spartan-3 Starter doesn't work, nor does anything I've written. It
constantly reads back garbage data. When I go into IMPACT, and generate
a SVF of the chip programming (with the same .bit file, no less), and
then load that into Digilent's tool, the SRAM works correctly (reads
back fine, the ram tester comes out ok).

I know it seems bizarre, but it's what happens.

From: Brian Davis on 8 Mar 2006 09:14
Scott M. Kroll wrote:
>
> It's very strange, but here's what I meant: I am using Digilent's JTAG
> utility (it's called Export) to program the FPGA via JTAG. Using IMPACT
> to create the .bit file, and then program the FPGA with the .bit.
> Digilent's Export tool only supports .bit and .svf files. If I program
> the FPGA via the .bit file, the SRAM never writes, and feeds back random
> garbage, never writes correctly.

OK, I'll try that tonight and see what I see.

BTW, what versions of ISE and Export are you using ?

> Some ramtesting vhdl I found for the Spartan-3 Starter doesn't work,
> nor does anything I've written.

Follow the bouncing links for my S3 kit SRAM test code and notes:
http://groups.google.com/group/comp.arch.fpga/msg/ee222450bf8e47c8

If I ever find time to debug the S3 -ES DCM oddities I've been seeing,
I'll post a new version of that code that runs the S3 starter kit SRAM
(pipelined) at around 60 MHz.

Brian

From: cs_posting on 8 Mar 2006 09:43
Scott M. Kroll wrote:

> It's very strange, but here's what I meant: I am using Digilent's JTAG
> utility (it's called Export) to program the FPGA via JTAG. Using IMPACT
> to create the .bit file, and then program the FPGA with the .bit.
> Digilent's Export tool only supports .bit and .svf files. If I program
> the FPGA via the .bit file, the SRAM never writes, and feeds back random
> garbage, never writes correctly.

Okay, let me see if I understand this correctly - the digilent
programmer does not seem to be able to make a .bit file work, but if
you use the xilinx tool to turn .bit into .svf, the digilent programmer
can load that.

Your only evidence of working/not working to date is the ram test. But
it's probably that the programming more generally fails?

Anyway, my impression is that a .bit file is just data, while a .svf
file is data expanded into explicit instructions for how to wiggle the
jtag lines to program it into a xilinx part - all the thinking is
already done, only the execution remains. This suggests that your
problem is that the digilent programmer is not using (is not configured
to use) the right programming algorithm for the part in question. When
it's mindlessly executing the .svf instructions things work, when it's
taking responsibility for figuring out how to program a .bit, it fails.

You could either take that up with digilent, or if you want to
streamline your intermediate step, the xilinx tools can be run
command-line style from scripts to do your translation.

From: Mike Harrison on 8 Mar 2006 11:06
On Wed, 08 Mar 2006 07:54:36 -0500, "Scott M. Kroll" <none(a)nowhere.com> wrote:

>Brian Davis wrote:
>> Scott M. Kroll wrote:
>>> 2. The external SRAM does not work when using a .bit file
>>>
>> Could you clarify exactly what you mean here; are you
>> using the Digilent JTAG utility to program the on-board prom,
>> or to directly configure the FPGA via JTAG?
>>
>> One thing I've seen with IMPACT generated SVF files on both
>> V2P's and the S3 starter kit, is the need for one last JTAG
>> operation to "wake up" the part.
>>
>> IIRC, in the Digilent tool, after loading the FPGA with the
>> config PROM in BYPASS, just try a device id on the config
>> PROM and see if that fixes it.
>>
>> Also, I think I've had to change the JP1 bitstream readback
>> jumper setting to "disable" to get consistent results for JTAG
>> download; you may also want to change the configuration mode
>> jumpers to "JTAG"
>>
>> If the DCM doesn't start up after re-configuration, your static
>> logic would work but any DCM clocked logic would not:
>> Answer Record 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"
>>
>> Similar things can happen if the part almost, but not quite, finishes
>> configuration and ends up in a configured state with GSR or GTS
>> still asserted.
>>
>> To help sort out what is happening, create a test design with:
>> - an LED driven from a switch input (no registers)
>> - a blinky LED counter driven from the input clock WITHOUT a DCM
>> - a blinky LED counter driven from a DCM sourced clock
>> - LED's on DCM LOCKED and "clock stopped" status bit
>>
>> Brian
>>
>
>It's very strange, but here's what I meant: I am using Digilent's JTAG
>utility (it's called Export) to program the FPGA via JTAG. Using IMPACT
>to create the .bit file, and then program the FPGA with the .bit.
>Digilent's Export tool only supports .bit and .svf files. If I program
>the FPGA via the .bit file, the SRAM never writes, and feeds back random
>garbage, never writes correctly. Some ramtesting vhdl I found for the
>Spartan-3 Starter doesn't work, nor does anything I've written. It
>constantly reads back garbage data. When I go into IMPACT, and generate
>a SVF of the chip programming (with the same .bit file, no less), and
>then load that into Digilent's tool, the SRAM works correctly (reads
>back fine, the ram tester comes out ok).
>
>I know it seems bizarre, but it's what happens.

A quick "reality check" on programming problems is to program the file into the flash.
If it behaves differently then it's definitely a download problem
From: skroll on 8 Mar 2006 13:03
Believe it or not, every other component seems to work. I wrote a
working UART and was able to send data to and from a terminal no
problem, as well as all the LEDs and Switches work. I've been talking
to Digilent, and they have been working with me in trying to figure out
what's causing it. Only thing that doesn't seem to work is the SRAM
when programming via a .bit file. Everything else is fine, which is
why I hadn't noticed a problem until I tried to use the SRAM.


cs_posting(a)hotmail.com wrote:
> Scott M. Kroll wrote:
>
> > It's very strange, but here's what I meant: I am using Digilent's JTAG
> > utility (it's called Export) to program the FPGA via JTAG. Using IMPACT
> > to create the .bit file, and then program the FPGA with the .bit.
> > Digilent's Export tool only supports .bit and .svf files. If I program
> > the FPGA via the .bit file, the SRAM never writes, and feeds back random
> > garbage, never writes correctly.
>
> Okay, let me see if I understand this correctly - the digilent
> programmer does not seem to be able to make a .bit file work, but if
> you use the xilinx tool to turn .bit into .svf, the digilent programmer
> can load that.
>
> Your only evidence of working/not working to date is the ram test. But
> it's probably that the programming more generally fails?
>
> Anyway, my impression is that a .bit file is just data, while a .svf
> file is data expanded into explicit instructions for how to wiggle the
> jtag lines to program it into a xilinx part - all the thinking is
> already done, only the execution remains. This suggests that your
> problem is that the digilent programmer is not using (is not configured
> to use) the right programming algorithm for the part in question. When
> it's mindlessly executing the .svf instructions things work, when it's
> taking responsibility for figuring out how to program a .bit, it fails.
>
> You could either take that up with digilent, or if you want to
> streamline your intermediate step, the xilinx tools can be run
> command-line style from scripts to do your translation.

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