Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

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

Status
Not open for further replies.

dpaul

Advanced Member level 5
Advanced Member level 5
Joined
Jan 16, 2008
Messages
1,856
Helped
317
Reputation
635
Reaction score
352
Trophy points
1,373
Location
Germany
Activity points
13,441
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.
 

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?
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).
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.
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.
 

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.

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.
 
  • Like
Reactions: dpaul

    dpaul

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top