TIG Being Ignored?

I've been performing post-map static timing analysis and have noticed that my TIG UCF constraint is being ignored for some reason. Here is what I have:

## TIG NET "ctrl1_clr" TNM_NET = "TN_ctrl_clr"; NET "ctrl2_clr" TNM_NET = "TN_ctrl_clr"; NET "sync_drpp_clr_inst/sync_r2" TNM_NET = "TN_sync_drpp_clr"; NET "sync_drpp_clr_inst/sync_r2" TNM_NET = "TN_sync_drpp_clr"; TIMESPEC "TS_TIG_clr2synch" = FROM "TN_ctrl_clr" TO "TN_sync_drpp_clr" TIG;

The first two nets listed are assigned to a timing name belonging to paths that are asychronous to another clock. This clock drives registered ports of an instance (synchronization circuit) with port name sync_r2(1:0). Normally I would edit the UCF manually, but it absorbed some of the signal names, so instead I used the constraint tool to generate the above.

When I run timing I get the following:

WARNING:Timing:3223 - Timing constraint PATH "TS_TIG_clr2synch_path" TIG; ignored during timing analysis.

Here is one of the timing errors from the post-map static timing analyzer:

Timing constraint: TS_adc_clk_dcm_clkfx = PERIOD TIMEGRP "adc_clk_dcm_clkfx" TS_adc_clk / 0.7 HIGH 50%;

278920 items analyzed, 4 timing errors detected. (4 setup errors, 0 hold errors) Minimum period is 8.415ns.

-------------------------------------------------------------------------------- Slack: -0.270ns (requirement - (data path - clock path skew + uncertainty)) Source: ctrl2_ins/curr_st_FFd1 (FF) Destination: sync_drpp_clr_inst/sync_r1_1 (FF) Requirement: 0.571ns Data Path Delay: 0.590ns (Levels of Logic = 1) Clock Path Skew: 0.000ns Source Clock: adc_clk_dcm_clk0_bufg rising at 28.000ns Destination Clock: adc_clk_dcm_clkfx_bufg rising at 28.571ns Clock Uncertainty: 0.251ns Timing Improvement Wizard Data Path: ctrl2_ins/curr_st_FFd1 to sync_drpp_clr_inst/sync_r1_1 Delay type Delay(ns) Logical Resource(s) ---------------------------- ------------------- Tcko 0.291 ctrl2_ins/curr_st_FFd1 net (fanout=22) e 0.100 ctrl2_ins/curr_st_FFd1 Tfck 0.199 ctrl2_ins/curr_st_Out11 sync_drpp_clr_inst/sync_r1_1 ---------------------------- --------------------------- Total 0.590ns (0.490ns logic, 0.100ns route) (83.1% logic, 16.9% route)

Why is ISE ignoring my constraint? How am I supposed to know what my true worst path is if I can't eliminate this timing error?

Thanks,

-Brandon

Reply to
Brandon Jasionowski
Loading thread data ...

Your statement:

may show a mis-understanding of how the TNM and TNM_NET constraints form timing groups (not "timing names", the name is just a label to refer to the group). Timing groups are composed of instances of FFs, memories, and other synchronous devices, they are _not_ composed of nets. TNM_NET fans _forward_ from the named net and collects any devices whose inputs are reached either directly or combinatorically from that net.

To get a clue what's happening, use Timing Analyzer to take a look at the timing groups that are formed by your grouping constraints:

Look at the group "TN_ctrl_clr". Does it contain "Source: ctrl2_ins/curr_st_FFd1 (FF)"? Look at the group "TN_sync_drpp_clr". Does it contain "Destination: sync_drpp_clr_inst/sync_r1_1 (FF)"? (I'm guessing no on both...)

If the groups don't contain the source and destination devices for the timing path you want to ignore, the TIG constraint is not applied (or worse, applied to a different set of sources/destinations that you did not intend).

Three possible suggestions are:

1) If you want to ignore _all_ cross clock domain timing, you easily do that with a TIG applied from your CLK1 group to your CLK2 group: NET "adc_clk_dcm_clk0" TNM_NET "TG_Clk1"; NET "adc_clk_dcm_clkfx" TNM_NET "TG_Clk2"; TIMESPEC "TS_Clk1_to_Clk2" =3D FROM "TG_Clk1" TO "TG_Clk2" TIG; (or whatever names you want to use for your TIMEGROUPsand TIMESPEC.) I don't particularly like this though, it may hinder Place/Route by allowing domain crossing nets to be excessively long, thus getting in the way of more critical nets. It may be nicer to simply use a small but achievable value: TIMESPEC "TS_Clk1_to_Clk2" =3D FROM "TG_Clk1" TO "TG_Clk2" 2 ns; (or whatever value works for you). 2) Closer to what you seem to want to do, use TPTHRU:

NET "ctrl1_clr" TPTHRU=3D TH_clr; NET "ctrl2_clr" TPTHRU=3D TH_clr; and either: TIMESPEC "TS_Thru_clr" =3D FROM "TG_Clk1" THRU "TH_clr" TO "TG_Clk2" TIG; or possibly better for P/R: TIMESPEC "TS_Thru_clr" =3D FROM "TG_Clk1" THRU "TH_clr" TO "TG_Clk2" 2 ns;

3) To pick out only the particular paths that you show failing, use the instance grouping constraint: INST "ctrl2_ins/curr_st_FFd1" TNM "TG_Src1"; INST "sync_drpp_clr_inst/sync_r1_1" TNM "TG_Dst1"; TIMESPEC "TS_Src1_to_Dst1" =3D FROM "TG_Src1" TO "TG_Dst1" TIG; or TIMESPEC "TS_Src1_to_Dst1" =3D FROM "TG_Src1" TO "TG_Dst1" 2 ns;

Hope one of these is of some help. Regards, John

--=AD-----

Reply to
JustJohn

I completely agree with John. The groups that you have created might not have a valid connection at all to ignore. The Instance based grouping of the elements(third option) looks like the preferred solution for you to dig out the actual critical paths..Please refer to the constraints guide from the ISE --documents--software manuals(pdf) for the correct syntax and to understand the grouping of elements and create constraints,to inform the tool about such exceptions(path specific).

Reply to
ajpanicker

John,

I tried what you suggested, but I'm not having much luck because of some restrictions on TNM u sage and DCMs. The TNM_NET I specified feeds into a DCM_BASE, so I need it to derive all the child clocks.

Page 279 of the cgd says,

The TNM is pushed through the CLKDLL or DCM (as described below) only if the following conditions are met: =B7 The TNM group is used in exactly one PERIOD specification. =B7 The TNM group is not used in any FROM-TO or OFFSET specifications. =B7 The TNM group is not referenced in any user group definition. If any of the above conditions are not met, the TNM is not be pushed through.

I tried the following in my UCF, but it fails.

NET "adc_clk" TNM_NET =3D "TG_adc_clk"; TIMESPEC "TS_adc_clk" =3D PERIOD "TG_adc_clk" 4.0 ns HIGH 50 %; NET "adc_clk_dcm_clkfx" TNM =3D "TG_logic_clk"; TIMESPEC "TS_adcclk_to_logicclk" =3D FROM "TG_adc_clk" TO "TG_logic_clk" TIG;

WARNING:XdmHelpers:793 - The TNM "TG_logic_clk" drives the CLKIN pin of DCM_ADV "adc_clkfx_dcm_inst". This TNM cannot be traced through the DCM_ADV because it is not used exclusively by one PERIOD specification. This TNM is used in the following user groups and/or specifications: TS_adcclk_to_logicclk=3DFROM TG_adc_clk TO TG_logic_clk TIG WARNING:XdmHelpers:625 - No instances driven from the following signals or pins are valid for inclusion in TNM group "TG_adc_clk". A TNM property on a pin or signal marks only the flip-flops, latches and/or RAMs which are directly or indirectly driven by that pin or signal. signal "adc_clk" WARNING:XdmHelpers:644 - No appropriate elements were found for the TNM group "TG_adc_clk". This group has been removed from the design. ERROR:XdmHelpers:650 - The period specification "TS_adc_clk" is invalid because the "TG_adc_clk" group was removed. ERROR:XdmHelpers:648 - The specification "TS_adcclk_to_logicclk" is invalid because its FROM group (TG_adc_clk) was removed.

Do I have to manually derived all of the DCM clocks (I have a lot)? This seems ridiculous!

Thanks,

-Brand> >

----=AD-----

Reply to
Brandon Jasionowski

I realized the the net adc_clk was the input to the DCM, so I switched to the clk0 output of the DCM and it prevented the aforementioned error. Oops!

Thanks, that did the trick.

-Brand> John,

G;

lr"

------=AD-----

th

Reply to
Brandon Jasionowski

I was going to reply that if you have a complex design with lots of cross clock domain timing to worry about, then you're going to have complicated timing constraints that no automated system is going to be able to work out for you. But it looks like you've found your solution. Great, and thanks for letting us know (it was nagging at me)!

Reply to
JustJohn

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.