Xilinx XC3S400 reproducibility madness

[nmatringe@gmail.com]

Hello all
I am facing a strange problem: I am not able to generate a properly working bitstream from an original set of files that worked perfectly well just a few days ago. I mean, the FPGA gets programmed OK but the design doesn't work. If I use last week's bitstream it works, if I generate a new one from last week's source files it doesn't.
I use ISE 13.1.
Any clue or hint ?

Thanks
Nicolas

 

[o pere o]

On 11/05/2012 11:53 AM, nmatringe@gmail.com wrote:

Hello all
I am facing a strange problem: I am not able to generate a properly working bitstream from an original set of files that worked perfectly well just a few days ago. I mean, the FPGA gets programmed OK but the design doesn't work. If I use last week's bitstream it works, if I generate a new one from last week's source files it doesn't.
I use ISE 13.1.
Any clue or hint ?

Thanks
Nicolas

Is your design fully constrained and does it meet all timing
requirements? I remember having trouble once when removing or adding a
debug pin gave a working/not working design. However, it was not exactly
the same files.

Pere

 

[nmatringe@gmail.com]

Le lundi 5 novembre 2012 11:53:53 UTC+1, nmat...@gmail.com a écrit :

If I use last week's bitstream it works, if I generate a new one from
last week's source files it doesn't.

Problem update (and partial solution) : there seems to be a conflict on the serial PROM pins, the 3.3V regulator gets really hot. If I unplug the PROM it works fine.

Nicolas

 

[nmatringe@gmail.com]

Le lundi 5 novembre 2012 14:08:20 UTC+1, o pere o a écrit :

Is your design fully constrained and does it meet all timing
requirements? I remember having trouble once when removing or adding a
debug pin gave a working/not working design. However, it was not exactly
the same files.

The pinout is fully defined and the max clock frequency exceeds the constraint.
As I added, there is something wrong with the serial PROM pins. My design doesn't use the dual-use pins (Din, Init_n & Busy) though.

Nicolas

 

On Monday, November 5, 2012 4:53:53 AM UTC-6, nmat...@gmail.com wrote:

Hello all I am facing a strange problem: I am not able to generate a properly working bitstream from an original set of files that worked perfectly well just a few days ago. I mean, the FPGA gets programmed OK but the design doesn't work. If I use last week's bitstream it works, if I generate a new one from last week's source files it doesn't. I use ISE 13.1. Any clue or hint ? Thanks Nicolas

Are you absolutely, positively sure that what you are using as "last week's source files" actually produced "last week's bitstream"? Including all project configuration/script files?

Was "last week's bitstream" created with a script, or was it just button-pushing in the GUI? Generating exact sequences of button-pushing is not very repeatable. If it was a script, has the script changed?

Is or was the synthesis/P&R tool using incremental synthesis/P&R, or is/was the build a "clean" build from scratch?

Is the same version of synthesis, P&R tools used?

Given the issue with the PROM, I would look at the options that went into producing the programming file first.

Andy

 

[Nicolas Matringe]

Le 05/11/2012 18:18, jonesandy@comcast.net a écrit :

On Monday, November 5, 2012 4:53:53 AM UTC-6, nmat...@gmail.com wrote:
Hello all I am facing a strange problem: I am not able to generate a properly working bitstream from an original set of files that worked perfectly well just a few days ago. I mean, the FPGA gets programmed OK but the design doesn't work. If I use last week's bitstream it works, if I generate a new one from last week's source files it doesn't. I use ISE 13.1. Any clue or hint ? Thanks Nicolas

Are you absolutely, positively sure that what you are using as "last week's source files" actually produced "last week's bitstream"?

Well I retrieved a backed-up version of the directory, the files time &
date seem to indicate that yes, the bitstream has been generated from
the source files (VHDL, UCF and tcl script)

Was "last week's bitstream" created with a script, or was it just button-pushing in the GUI?

It's a script called from a .bat command file.

Generating exact sequences of button-pushing is not very repeatable. If it was a script, has the script changed?

The only difference between the runs is that the script sets a generic
parameter based on time & date at runtime so that the design is
time-stamped but it has never caused any such problem before.

Given the issue with the PROM, I would look at the options that went into producing the programming file first.

I hadn't used the PROM on this project until I had a working design, and
then I needed to test some USB issue and programmed the FPGA through
JTAG with a slightly modified design and I ran into this pin conflict. I
still don't know where it comes from. The pad report indicates that the
dual-function pins are not used. CCLK pin ?

Nicolas

 

[Gabor]

Nicolas Matringe wrote:

Le 05/11/2012 18:18, jonesandy@comcast.net a écrit :
On Monday, November 5, 2012 4:53:53 AM UTC-6, nmat...@gmail.com wrote:
Hello all I am facing a strange problem: I am not able to generate a
properly working bitstream from an original set of files that worked
perfectly well just a few days ago. I mean, the FPGA gets programmed
OK but the design doesn't work. If I use last week's bitstream it
works, if I generate a new one from last week's source files it
doesn't. I use ISE 13.1. Any clue or hint ? Thanks Nicolas

Are you absolutely, positively sure that what you are using as "last
week's source files" actually produced "last week's bitstream"?

Well I retrieved a backed-up version of the directory, the files time &
date seem to indicate that yes, the bitstream has been generated from
the source files (VHDL, UCF and tcl script)


Was "last week's bitstream" created with a script, or was it just
button-pushing in the GUI?

It's a script called from a .bat command file.


Generating exact sequences of button-pushing is not very repeatable.
If it was a script, has the script changed?

The only difference between the runs is that the script sets a generic
parameter based on time & date at runtime so that the design is
time-stamped but it has never caused any such problem before.


Given the issue with the PROM, I would look at the options that went
into producing the programming file first.

I hadn't used the PROM on this project until I had a working design, and
then I needed to test some USB issue and programmed the FPGA through
JTAG with a slightly modified design and I ran into this pin conflict. I
still don't know where it comes from. The pad report indicates that the
dual-function pins are not used. CCLK pin ?

Nicolas
What's the setting for unused IOB's when you run BitGen? I seem to

remember that active low drive (not pulldown) is one of the options.

-- Gabor

 

[Nicolas Matringe]

Le 05/11/2012 20:43, Gabor a écrit :

What's the setting for unused IOB's when you run BitGen? I seem to
remember that active low drive (not pulldown) is one of the options.

That was a default setting that stung me several times in the past. But
Xilinx have finally changed it to something else, like "pulled low". I
checked that too (but will recheck anyway)

Nicolas