Xilinx XC3S400 reproducibility madness

Le lundi 5 novembre 2012 11:53:53 UTC+1, snipped-for-privacy@gmail.com a écrit :

om

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

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.

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

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

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

Nicolas

erly 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 desig n doesn't work. If I use last week's bitstream it works, if I generate a ne w 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 pro ject configuration/script files?

Was "last week's bitstream" created with a script, or was it just button-pu shing 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 p roducing the programming file first.

Andy

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

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)

button-pushing in the GUI?

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

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.

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

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

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