[SOLVED] Will my design with lots of setup violations work @ room temp (Xilinx Spartan6)?

Hello,

After synth. of a simple SoC design using Synplify for a Xilinx Spartan6 target, I used Xilinx ISE suite to run the PnR process.
I had a lot of setup violations (for the sdc constraints I have used) but all the processes involved in the PnR completed successfully. Finally I had the .bit file for the FPGA generated.

Can I use this .bit file at *room temperature* and continue with this SoC bit file with its setup violations?

I know this is not good design practice. But for the time being I want to test my design in real hardware (coz of more priority) and do not want to play around with the .sdc file (reason - the .sdc was given to me by a colleague of mine).

I also don't understand exactly why this design with the setup violations might work at room temp. but fail to produce the proper results at other temperatures.

dpaul said:

Hello,

After synth. of a simple SoC design using Synplify for a Xilinx Spartan6 target, I used Xilinx ISE suite to run the PnR process.
I had a lot of setup violations (for the sdc constraints I have used) but all the processes involved in the PnR completed successfully. Finally I had the .bit file for the FPGA generated.

Can I use this .bit file at *room temperature* and continue with this SoC bit file with its setup violations?

Click to expand...

Sure, it's not going to melt the part.

I know this is not good design practice. But for the time being I want to test my design in real hardware (coz of more priority) and do not want to play around with the .sdc file (reason - the .sdc was given to me by a colleague of mine).

Click to expand...

You're free to waste time how you see fit

I also don't understand exactly why this design with the setup violations might work at room temp. but fail to produce the proper results at other temperatures.

Click to expand...

That's a sign that you don't know how to design anything. It's not something that just anyone can do.

Kevin

Being a newbie to timing analysis, I am neither doing a tape-out here nor selling this design to anyone.
I would appreciate technical explanations if possible.

I just tested the .bit file in bare-metal (after merging the ELF/binary) and I can see that R/W to the registers of peripheral IPs can be performed by the uP core.

dpaul said:

Being a newbie to timing analysis, I am neither doing a tape-out here nor selling this design to anyone.
I would appreciate technical explanations if possible.

I just tested the .bit file in bare-metal (after merging the ELF/binary) and I can see that R/W to the registers of peripheral IPs can be performed by the uP core.

Click to expand...

being a newbie or not has no relationship to "tape-out" or "selling" a design.

Static timing analysis is done to check it the design will functionally work at the best (Best P, High V, & low T) case and worst (Worst P, Low V, high T) case corners.

Suppose you violate setup time by 1 ns and your clock period is 30 ns at room temp with an average die (process) you'll be highly unlikely to see any kind of issue given that there is probably a lot of cells and routing between source and destination.

Instead if we violate setup time by 1 ns but our clock is 400 MHz (2.5 ns period), It's very likely that you will have intermittent setup violations (possibly at room temp) that cause functional failure due to metastability. In this case your path delay stack up requires 3.5 ns to work across PVT, which is 40% larger than the 2.5 ns you have to work with.

What you should be doing is looking at why there are timing violations, which is usually because of a poor understanding of pipeline design and "how much you can do with a LUT with x-inputs". Using a design with "bad" timing isn't the way to verify functionality of a design as you'll never know for certain if the errors in functionality are really due to functional problems or timing problems. Even if you are a hobbyist you should fix timing violations

Post a couple worst case paths from the reports showing the data and clock paths and the relevant constraint(s) you have applied to the clock used.

Problem is now solved, no more violations reported.
All I did was a small RTL change as in https://www.edaboard.com/threads/339001/

Currently I don't have an explanation why!

Nevertheless thanks to ads-ee.