cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
thetford
Observer
Observer
5,327 Views
Registered: ‎08-04-2008

timing constraints getting silently dropped

Jump to solution

We seem to have encountered a bug in the tool flow where if you build things a certain way, timing constraints will get dropped such that static timing analysis passes, but postroute timing simulation shows setup/hold violations and the actual device will exhibit timing related bugs.

 

This flow causes problems:

1) build dsp core cdontaining multicycle paths with sysgen targeting hdl netlist

2) synthesize core with ise using the generated project file (after disabling iobuf insertion)

3) copy sysgen ucf file into larger fpga ucf file

4) build larger fpga with other cores, etc.

 

result will pass static timing but fail post route timing sim & real world testing

 

This flow will work:

1) build dsp core cdontaining multicycle paths with sysgen targeting NGC netlist

2) copy sysgen ucf file into larger fpga ucf file

3) build larger fpga with other cores, etc.

 

Note: if  we build using the hdl netlist flow without doing an intermediate step  of synthesizing the core, the tool bombs out complaining of problems with constraints. Apparently synthesizing the core causes the downstream build  process to not notice these timing errors.

 

Has anyone else noticed this sort of thing?

 

Why does the sysgen HDL netlist compilation generate NGC netlists along with the vhd/v files? And why are these NGC files incompatible with the generated ucf file?

 

-Jeff

 

0 Kudos
1 Solution

Accepted Solutions
thetford
Observer
Observer
5,679 Views
Registered: ‎08-04-2008

Turns out that for some reason when in hdl mode, sysgen does not write timing constraint info, and the ise project that it creates is set to NOT write timing constraints through to the ncg netlist when synthesized. When in ngc mode, sysgen it does write the timing constraints. I've been told change request 575329 has been filed to address this issue.

 

View solution in original post

0 Kudos
5 Replies
criley
Xilinx Employee
Xilinx Employee
5,321 Views
Registered: ‎08-16-2007

What's the error message the tool bombs out with complaining about the constraints?

0 Kudos
thetford
Observer
Observer
5,312 Views
Registered: ‎08-04-2008

Annotating constraints to design from ucf file "../../XLGe.ucf" ...
Resolving constraint associations...
Checking Constraint Associations...
ERROR:ConstraintSystem:58 - Constraint <NET "dsp/ce_10_sg_x15*" TNM_NET =
   "ce_10_5ec8ad2a_group";> [../../XLGe.ucf(123)]: NET "dsp/ce_10_sg_x15*" does
   not match any design objects.

WARNING:ConstraintSystem:56 - Constraint <TIMESPEC
   "TS_ce_10_5ec8ad2a_group_to_ce_10_5ec8ad2a_group" = FROM
   "ce_10_5ec8ad2a_group" TO "ce_10_5ec8ad2a_group" 41.5 ns;>
   [../../XLGe.ucf(124)]: Unable to find an active 'TimeGrp' or 'TNM' or
   'TPSync' constraint named 'ce_10_5ec8ad2a_group'.

WARNING:ConstraintSystem:56 - Constraint <TIMESPEC
   "TS_ce_10_5ec8ad2a_group_to_ce_10_5ec8ad2a_group" = FROM
   "ce_10_5ec8ad2a_group" TO "ce_10_5ec8ad2a_group" 41.5 ns;>
   [../../XLGe.ucf(124)]: Unable to find an active 'TimeGrp' or 'TNM' or
   'TPSync' constraint named 'ce_10_5ec8ad2a_group'.

ERROR:ConstraintSystem:58 - Constraint <NET "dsp/ce_2500_sg_x25*" TNM_NET =
   "ce_2500_5ec8ad2a_group";> [../../XLGe.ucf(127)]: NET "dsp/ce_2500_sg_x25*"
   does not match any design objects.

WARNING:ConstraintSystem:56 - Constraint <TIMESPEC
   "TS_ce_2500_5ec8ad2a_group_to_ce_2500_5ec8ad2a_group" = FROM
   "ce_2500_5ec8ad2a_group" TO "ce_2500_5ec8ad2a_group" 10.375 us;>
   [../../XLGe.ucf(128)]: Unable to find an active 'TimeGrp' or 'TNM' or
   'TPSync' constraint named 'ce_2500_5ec8ad2a_group'.


and so on...

0 Kudos
ticktack
Explorer
Explorer
5,277 Views
Registered: ‎08-14-2007

The problem normally occurs on mulit-rate design. If Gateway In is driving a UP/Down Sample block directly, ce is created by mistake. You can insert a register between Gateway In and UP/Down Sample.

 

Here's the relevant answer record :

 

http://www.xilinx.com/support/answers/30377.htm

0 Kudos
thetford
Observer
Observer
5,273 Views
Registered: ‎08-04-2008

OK, so answer 30377 may explain why the build fails when using the hdl netlist is used, since we do have gateway inputs that go right into downsampler blocks. But how would you explain the problem going away when ngc netlist output from sysgen is used?

 

The real question is why does the step of synthesizing the hdl netlist core in XST cause subsequent builds to fail timing, but say that static timing constraints all pass. To summarize:

 

sysgen -> hdl netlist -> build: generates error messages shown above.

sysgen -> ngc netlist -> build: builds fine with no timing errors, everything works

sysgen -> hdl netlist -> synthesize -> build: acts like it builds fine, but device fails postroute timing sim and fails in the lab.

 

This last flow is a killer because you think all is fine, but there are timing errors that don't show up until in the field. This caused us untold pain and months tracking it down. We had been using Synplicity, and when we switched to XST we continued with the hdl netlist flow and synthesizing as an intermediate build step.

 

Perhaps the lesson is don't trust static timing analysis, always follow with a postroute timing sim (what a pain).

 

0 Kudos
thetford
Observer
Observer
5,680 Views
Registered: ‎08-04-2008

Turns out that for some reason when in hdl mode, sysgen does not write timing constraint info, and the ise project that it creates is set to NOT write timing constraints through to the ncg netlist when synthesized. When in ngc mode, sysgen it does write the timing constraints. I've been told change request 575329 has been filed to address this issue.

 

View solution in original post

0 Kudos