Xilinx 'unconstrained period' problem

I'm using a Xilinx V2Pro part with the 6.2.03i s/w release and I'm seeing the following unconstrained path in the timing report:

================================================================================ Timing constraint: Unconstrained period analysis for net "clk_conv"

Delay: 3.073ns (data path - clock path skew + uncertainty) Source: u0clk_trig_if/trig_conv0 (FF) Destination: u0clk_trig_if/trig_conv1 (FF) Data Path Delay: 3.073ns (Levels of Logic = 0) Clock Path Skew: 0.000ns Source Clock: clk_conv rising at 0.000ns Destination Clock: clk_conv rising at 2.450ns Clock Uncertainty: 0.000ns

Data Path: u0clk_trig_if/trig_conv0 to u0clk_trig_if/trig_conv1 Location Delay type Delay(ns) Physical Resource Logical Resource(s) -------------------------------------------------

------------------- SLICE_X32Y0.YQ Tcko 0.419 u0clk_trig_if/trig_conv0

u0clk_trig_if/trig_conv0 SLICE_X25Y9.BY net (fanout=2) 2.428 u0clk_trig_if/trig_conv0 SLICE_X25Y9.CLK Tdick 0.226 u0clk_trig_if/trig_conv1

u0clk_trig_if/trig_conv1 -------------------------------------------------

--------------------------- Total 3.073ns (0.645ns logic,

2.428ns route) (21.0% logic, 79.0% route)

In my .ucf file, I have set the period on clk_conv, so I don't see why I'm getting this unconstrained path. In fact, in another section of the timing report, I see:

================================================================================ Timing constraint: TS_clk_conv = PERIOD TIMEGRP "clk_conv" 2.450 nS HIGH 50.000000 % ;

4 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold errors)

Thus, I believe the constraint on clk_conv is entered correctly, but for some reason the tools appear to ignore the constraint on some of the registers driven by the clock.

My Verilog code has the registers trig_conv1 and trig_conv0 in the same always block with the proper clock edge. The code seems straight forward, so I don't see how the coding style could cause this.

Any ideas?

Thanks

John Providenza

Reply to
johnp
Loading thread data ...

In the Xilinx timing reports, paths that have exceptions to the period constraint show up as unconstrained. If you have the patience to follow through the chain of net names you may find that this path has either been assigned "TIG" (timing ignore) via some group, or that it doesn't meet the normal definition of a path from clocked flip-flop output to data input, such as a gated clock or reset signal.

================================================================================

================================================================================

Reply to
Gabor

Gabor -

There are no TIG constriants on the nets. I don't see any conflicting constraints that would move the signals into this 'unconstrained period' section of the report.

I'm suspecting a bug in the Xilinx tools, but I'll keep poking around a bit.

John Providenza

Reply to
johnp

================================================================================

================================================================================

I recently encountered a case in which timing constraints were not applied to inputs of RAM16X1Ds. This was for a V4FX60 using ISE 7.1 service pack 4. I opened a web case and sent them the design to look at, and they came up with a work around for me, and filed a change request to have the problem fixed. Here is a copy of the response that explains the work around:

Hi John,

I have found a work around to this issue. You can manually add the missing elements into the time group in the PCF file before running PAR.

  1. Open the PCF file in a text editor.
  2. Locate the TIMEGRP mem_interface_top_0_infrastructure0_clk0_bufg_in
  3. Add the following line: BEL ?mem_interface_top_0/main_00/top_00/user_interface_00/rd_data_00/rd_data_fifo1/ram_fall0/RAM16X1D[31].U_.WE?

  1. Repeat this for each bit of the RAM that is showing up in the unconstrained section.

Just remember to backup the PCF because if you re-run Map it will overwrite the file and your changes will be lost. Also, the change request number is 219222. If you need to check the status you can ping me or call the hotline number.

The details are specific to what I was working on, but you should be able to modify them to fit your case. I am working on a different part of the design at the moment, so I have not tried this workaround yet. If you open a web case, refer them to case 601820, which is the one I opened.

Regards,

John McCaskill

Reply to
John McCaskill

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.