Xilinx XC3S400 reproducibility madness

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 wo rk. If I use last week's bitstream it works, if I generate a new one from l ast week's source files it doesn't. I use ISE 13.1. Any clue or hint ?

Thanks Nicolas

Reply to
nmatringe
Loading thread data ...

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

Reply to
nmatringe

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

Reply to
o pere o

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

Reply to
nmatringe

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

Reply to
jonesandy

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

Reply to
Nicolas Matringe

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

Reply to
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

Reply to
Nicolas Matringe

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.