Prev: How to program Spartan 3 Altium nanoboard with Xilinx tools ?
Next: Virtex 5 HDMI
From: intermilan on 2 Oct 2009 18:39
The logic function bits (LUT, DFF, MUX ...) for a column of 16 CLBs
are in 4 continuous frames (LUT function are in frame 1, 3; DFF bits
are in frame 0, 2).

I'm make some change in the LUT truth tables (with fpga_editor or ise
or whatever) and these changes affect frames 1 and 3. Actually, my
logic change will turn off 4 LEDs.

I can make bitgen to generate a partial bitstream file. I can then
download this pr bit file using impact or ICAP. This works - and the
pr bit file only write to frame 1 and 3.

I tried another approach: I read back the configuration bits of the 4
frames from ICAP, I made modification to the bits of frame 1 and frame
3 - I know how to change the internal bits for LUT and they look
exactly the same as the bits in the pr bit file generated by bitgen.

Then I write the 4 frames back through ICAP and interesting cases
occurs:
1) if I only write frame 1 and 3, this is essentially the same as
downloading the pr bit file, and the logic change is perfect; all LEDs
are off.
2) if I write the 4 frames in the oder frame 0, 1, 2, 3, hoops ... LED
3 and 4 are on! And even downloading the pr bit file again can't turn
them off. Something weird happens! Yet, from ICAP read back, the LUT
bits are changed ...
3) if I write 4 frames 0, 1, 2, (3), where frame (3) is not modified,
LED 1 & 3 are on and 2 & 4 are off - make sense;
4) if I write 4 frames 0, (1), 2, 3, where frame (1) is not modified,
LED 2 & 4 are on and 1 & 3 are off - make sense;
.......
x) if I write 4 frames in the order 1, 3, 0, 2, again it works.

I spent a whole day to look for reasoning behind this ... but it just
seems non-sense.

While, a fix for 4 frames of CLB logic bits could be just write frame
1&3 together and frame 0&2 together; but how about the other 18 frames
of CLB routing bits? How to debug similar weird case and get a fix?
From: KJ on 2 Oct 2009 21:21
On Oct 2, 6:39 pm, intermilan <wenwei...(a)gmail.com> wrote:
<snip>
> I spent a whole day to look for reasoning behind this ... but it just
> seems non-sense.
>

Or you're not understanding all that you think you do.

> How to debug similar weird case and get a fix?

1. Stop hacking the configuration data bitstream
2. Write source code
3. Use a simulator and timing analysis to insure that your design is
correct
4. Use the synthesis tools to go from source code to configuration
data bitstream.

If you follow this flow, you'll find that you have more time in your
day to do better things than trying to modify configuration data
bitstreams.

KJ

From: Kolja on 4 Oct 2009 07:10
On 3 Okt., 03:21, KJ <kkjenni...(a)sbcglobal.net> wrote:

> If you follow this flow, you'll find that you have more time in your
> day to do better things than trying to modify configuration data
> bitstreams.

Or just use srl16 to change the LUT content.

Kolja
 | 
Pages: 1
Prev: How to program Spartan 3 Altium nanoboard with Xilinx tools ?
Next: Virtex 5 HDMI