Timing constraint question

Are you cutting and pasting directly? I haven't seen the Xilinx tools add the MAXDELAY in the timing constraint before. If there is no MAXDELAY keyword in your definition, is the add1_rdy net in your compiled design? If it got renamed, the "THRU" could be a problem.

Suggestion: if you only have the 32 bit bus by that name, try NET "accumulate" TNM_NET = ACC; to specify all 32 wires feed the latches that you want fixed.

If the accumulate bus is the latch output, that would be your problem: the TNM_NET tags all *downstream* synchronous elements. Me, I'd just include the latches directly in the TO part as LATCHES( MyLatches ) rather than using the TNM_NET to tag them all.

- John_H

Thanks John,

I changed my UCF file to:

## System level constraints Net CLK TNM_NET = CLK; TIMEGRP "RISING_CLK" = RISING "CLK";

# Constrain CLK to 200 MHz TIMESPEC TS_CLK = PERIOD CLK 5 ns;

# Constrain the accumulate latch (one CLK cycle) TIMESPEC TS_ACC_LATCH = FROM "RISING_CLK" TO LATCHES( accumulate ) TS_CLK * 0.99 DATAPATHONLY;

Now that latch constraint is picked up by ISE. I don't think I need the THRU as the ready signal is synchronous with the clock.

And to answer your question, yes, the MAXDELAY was inserted automatically by ISE when it gave the warning in my previous post.

Thanks

So the problem probably was the TNM_NET corresponding to downstream elements rather than the latch itself.

If I wanted to group a bunch of synchronous elements by name, another way would be to use the INST rather than the NET to associate with a group, using TNM rather than TNM_NET. I believe that's what gets you the good associations that aren't simply convenient wildcard groups.

Are you adding this TIMESPEC because Xilinx tools associate the WRONG edge with the timing analysis result? I never have been happy with default timing analysis with latches.

The only reason I am specifying this TIMESPEC is so ISE throws me a failing constraint if the latching delay exceeds one clock cycle. There is a control signal (synchronous with clock) that sets / resets the accumulator (32-bit signal), but the latch itself is asynchronous. I can't make this synchronous because the control line changes state after a small delay from the edge of the clock and I need the latch to switch right away and stabilize before the next rising edge. So this TIMESPEC serves as a check to make sure if I specify a high frequency clock, the latching delay does not exceed the one clock cycle. And it is also indicates what the delay actually is (its a little over 2ns in this case) so I can take note of it.

I suppose you have two outputs a clk out, and one more signal i.e, control signal. And the edge on control signal has to be kept at a time gap from rising edge of the clock. If control signal is generated w.r.t same clock, clk to output delay constraint can be used. Otherwise sample this signal again with the same clock, and use clk to o/p delay constraint.

Rehgards, Veeresh

Veeresh,

Yes, that is what my circuit looks like. Can you show me how I would specify this constraint? I googled it but didn't find particular information on it. Right now I have this in my UCF. I constrained the latch delay to 4.9 ns, just a bit under 5 ns clock (200 MHz).

###### Net "*/my_core/CLK" TNM_NET = dp_clk; TIMEGRP "RISING_DP_CLK" = RISING dp_clk; TIMEGRP "DP_LATCH" = LATCHES("*/my_core/my_core/accumulate"); TIMESPEC TS_DP_LATCH = FROM "RISING_DP_CLK" TO "DP_LATCH" 4.9 ns DATAPATHONLY; ######

Thanks

Dmitriy

Hi, I normally use constraint editor in ISE's IDE. If you double click Xilinx constraint editor, there is a tab- "ports". In that, "clock to tab" button will take u to a window where delay, and the net name can be specified. tool will generate constraint syntax by it self, and write it to your ucf file. Please check if this helps

Regards, Veeresh

Hi, INST "Q.PAD" TNM = "outputs"; TIMEGRP "outputs" OFFSET = OUT 10 ns AFTER "clk" HIGH ;

this state that all nets grouped as outputs will have a clk to o/p delay of 10ns w.r.t rising edge of clk .