what do the following constraints mean?

Hi all, I am trying to modify some code and I came across these constraints. 'clk_in' is the input clock and 'clk' is generated using a DCM (its is the Divide By 2 output).

NET "clk_in" TNM_NET = "clk_in"; TIMESPEC "TS_clk_in" = PERIOD "clk_in" 20 ns HIGH 50 %;

TIMEGRP "rising_ffs" = RISING "clk"; TIMEGRP "falling_ffs" = FALLING "clk"; TIMESPEC "TS_pos_to_neg" = FROM "rising_ffs" TO "falling_ffs" 5 ns ;

Is there something wrong with the last FROM : TO statement? Can the same condition be specified using the Period statement? I think its supposed to mean "delay between the rising and falling edge is to be kept to 5ns". Thanks Subhasri.K

Reply to
Subhasri krishnan
Loading thread data ...

It means "delay between the flip flops triggered by the rising edge and flip flops triggered by the falling edge is to be kept to 5ns" (more or less). "flip flops" in this case is probably any edge triggered device, e.g. flip flops, rams, SRLs, etc.

Note that this is really a duty cycle specification for the clock.

Regards, Allan

Reply to
Allan Herriman

Yes, the same condition can be specified with a period statement. When ISE sees that opposite edges of the clock are being used, it will automatically cut the period in half (assuming a HIGH 50 % is applicable). So you just need: TIMESPEC "TS_clk" = PERIOD "clk" 10 ns HIGH 50 %;

Reply to
Duane Clark

Thanks both of you. I tried using the period statement and it worked!(when I used the FROM : TO the constraint was failing).

Reply to
Subhasri krishnan

A period of 20ns and a rising to falling time of 5ns would give a duty cycle of 25%, not 50%.

I've never liked the way the duty cycle is specified in UCF, as it's impossible to describe a worst case range. For example, if the duty cycle can vary between 40 and 60%, then one would need to decrease the period spec by 20% to adequately cover the rising to falling and falling to rising paths, but this results in an unnecessarily tight spec for the rising to rising and falling to falling paths.

Xilinx, take note.

Regards, Allan

Reply to
Allan Herriman

Careful here folks,

OP wrote that input clock is "clk_in", and the original UCF says period is 20ns, so 50 MHz.

OP wrote that the clock "clk" comes from the DCM div by 2 output, so it will be 25 MHz, with a period of 40ns, not 100 MHz and 10ns.

So, the original UCF has a real problem with "TS_pos_to_neg" spec, as it logically should be 20ns for a half cycle, not 5ns.

The correct period spec for "clk" would be:

TIMESPEC "TS_clk" = PERIOD "clk" 40 ns HIGH 50 %;

Alternatively, the from-to spec could be:

TIMESPEC "TS_pos_to_neg" = FROM "rising_ffs" TO "falling_ffs" 20 ns ;

Alan's comment:

is not correct, as he missed that the 20ns was the "clk_in" net, but the

5ns spec was for ffs in the rising/falling subsets of the "clk" net. Given that the "clk" clock is at 25MHz, the 5ns is actually just 12% of the cycle time. Even worse.

For Alan's non-symetric duty cycle worst case scenario, I handle it this way (let's stick with 40ns cycle time):

TIMEGRP "rising_ffs" = RISING "clk"; TIMEGRP "falling_ffs" = FALLING "clk"; TIMESPEC "TS_pos_to_neg" = FROM "rising_ffs" TO "falling_ffs" 16 ns ; TIMESPEC "TS_neg_to_pos" = FROM "falling_ffs" TO "rising_ffs" 16 ns ; TIMESPEC "TS_pos_to_pos" = FROM "rising_ffs" TO "rising_ffs" 40 ns ; TIMESPEC "TS_neg_to_neg" = FROM "falling_ffs" TO "falling_ffs" 40 ns ;

This supports the duty cycle ranging from 40% to 60%, while still giving the full cycles paths a whole cycle.

If you actually looked at my UCF files, you would find that I would probably have set the "16 ns" to 15, and the "40 ns" to 38, just so there was a little safety margin for clock jitter, etc.

Philip Freidin

Philip Freidin Fliptronics

Reply to
Philip Freidin

Yes, that's what I do to.

My apologies for missing the fact that a DCM divide by 2 output was used.

Allan

Reply to
Allan Herriman

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.