Timequest(SDC): constraining posedge launch negedge latch

5th attempt in posting code

always @(posedge clk_in) //clk_in runs around 200Mhz

if (reset)

delay_p <= 0;

else

delay_p <= {delay_p[34:0], in};

always @(negedge clk_in)

if (delay_enable)

comp <= compmux;

else

comp <= compmux[3];

always @*

case (delay_register)

0 :compmux <= delay_p[4];

1 :compmux <= delay_p[5];

2 :compmux <= delay_p[6];

Just constraining your clocks does this.

create_clock -period 10.0 -name clk_A [targetA]

create_clock -period 5.0 -name clk_B [targetB]

(Target is just a place hold for the port or PLL output that creates the clock. The default of create clock is a 50/50 duty cycle, so all falling edge registers are clocked halfway in the period.

So rise -> fall transfers in clkA -> clkA would have a 5ns setup relationship

clkB(rise) -> clkB(fall) would have a 2.5ns relationship

clkA(rise) clkB(fall) would have a 2.5ns relationship. (Launch at 0, latch at 2.5)

clkB(rise) -> clkA(fall) would have a 5ns relationship (launch at 0, latch at 5)

There would be similar relationships with fall -> rise.

If your circuit is designed to transfer over different edges, then multicycles would adjust those.

Note that by just creating two clocks, 16 different relationships are created. All combinations of r/f, i.e. rise -> rise, fall -> fall, rise-> fall, fall -> rise. That's 4. These relationships occur in both directions, clkA -> clkB and clkB -> clkA, so that's 8. Then there is a setup and hold for each one. That gets it to 16.

In most cases, the clocks are the same period, 50/50 duty cycle, and so most of those relationships are the repeated, but under strange relationships they can all be different too.

First, thank you very much for the quick reply Rysc!

I think you're saying that the create_clock constraint is enough to constrain my design.

You've mentioned on your document that i can create_generated_clock in place of the derive_pll_clocks, so i can then do that to follow your clk_A example, since the clock i'm using comes from a PLL.

What confuses me is your clk_B statement. How do i relate that clock within the design if my code is referencing to the same signal? Like:

always @(posedge pllclkout)

....

always @(negedge pllclkout)

...

Would recoding it like below help, just so i can reference to a different node/signal on my SDC??? Just unsure if Quartus will delete the node name..

always @(posedge pllclkout)

....

assign pllclkout_neg = !pllclkout;

always @(posedge pllclkout_neg )

...

Just wanted to add a BIG THANK YOU for the document you've made! It has helped me a lot! More exposure/experience needed though. :)

Yes, clock constraints will do this. Note that derive_pll_clocks calls out create_generated_clock, so in essence they're the same thing. (If you go to TimeQuest messages, there will be one that says something like "Derive PLL clocks" and then it will show every create_generated_clock it calls, in the correct format. So there's really no difference.

I was showing with two clocks, but your case just has one. It's fine to have two always statements, one with posedge and one with negedge. Just constraining that single clock will get you half-cycle setup relationships when doing opposite edge transfers. Also, glad you like the TQ User Guide.

So my contraint was OK. Just need to figure out how to fix my code then...

Thanks!!!