altlvds pll clock timing constraints

Altera_Forum · ‎11-22-2007

Hello,

I'm getting a hold slack violation between clock outputs on the PLL used by an altlvds_rx module. clk0 output is 300MHz and clk2 is div 7 or 42.86.

My question is, should I be including these in the same clock group or should they be separated into separate groups?

In the sdc file I have:

set_clock_groups

-exclusive

-group

{

Main_clk

}

-group

{

BUSS_CHAN_LINK_DATA[6]

}

-group

{

altera_reserved_tck

}

Many thanks,

Dave W.

Altera_Forum · ‎11-22-2007

There's two issues:

1) Yes, these should be in separate groups, becasue there really is no constant relationshp between a 300MHz clock and a 42.8571428...MHz clock. So there's no way a hold or setup requirement could be correct. So yes, put them in separate groups.

2) In separate groups, TimeQuest will no longer do timing analysis between them, which is correct. Your design needs to now make sure they are treated in an asynchronous manner if passing data between the two domains. An asynch FIFO, a handshaking scheme, or something like that.

Actually, there is another possibility. Your data may be "shaped" for this, i.e. your logic produced 7 bits of data that then need to be transferred to the 300Mhz domain on every 7th clock. Is that's what is going on?

(I haven't answered exactly, but please provide more info based on that and we can probably figure it out. One last thing might be to try running derive_pll_clocks, and see what that does in its Info message, since I believe that constraints ALTLVDS PLLs too.)

Altera_Forum · ‎11-23-2007

Thankyou,

actually, I think there is something in what you have suggested. I seem to remember running derive_pll_clocks in TimeQuest and getting a list of multicycle type messages as well as the list of pll clocks. To be honest, I don't understand them very well but I'll try it again and post the results.

It's a SERDES so there is a transfer of a word on every 7th clock cycle. That's why I was unsure whether or not the clocks should be in the same group.

Altera_Forum · ‎11-23-2007

I believe the derive_pll_clocks adds a multicycle on the paths from the SERDES into the fabric. This should be accurate and help your timing.

Altera_Forum · ‎11-23-2007

Thanks for your help so far.

This is what I get (below) So I have three questions:

1) Does this help the fitter to achieve timing?

2) Should I keep all derived clocks in the same clock group?

3) If I get a hold violation, what, if anything, can I do about it?

Info: Deriving PLL Clocks

Altera_Forum · ‎11-25-2007

1) Yes. The multicycles and false paths loosen the default constraints. If these were critical paths, it can make a huge difference. If they weren't though, it might not help.

2) Depends. The general rule of thumb is that every clock that comes in on a different I/O port is a new domain. So if it feeds 2 PLLs, then that port clock plus all the generated clocks out of the two PLLs would be in the same group. If another clock comes in on another port and feeds another PLL, all of those would go in another group. There are cases where this doesn't hold true though. Sometimes the same board clock feeds two input ports, so they might be related. Sometimes a single PLL creates clocks that are not related(I have one that creates a 1x clock and a 25/19x clock), so they're in separate groups and I handle the domain crossing correctly(carefully).

3) Depends. What's causing the hold violation. There are many possibilities, so it's tough to say. In general, with edge aligned, related clocks, there will never be a hold violation because the clock edges hit the source and destination registers are approximately the same time. So something is causing your clocks to hit the source and destination at different times, like a gated clock on one of the clocks. There are plenty of other possibilities for this, so you really need to understand what the hold violation is telling you, why it's occuring, and make a plan of action from there.

Altera_Forum · ‎11-27-2007

Thanks again,

perhaps this needs to be addressed to Altera support. My problem is that the clocks are generated by Altera IP (within the altlvds megafunction) and/so there is little I can or know how to do to get to the bottom of any internal timing problems. I think I'll make a support request and see what they have to say. I am confident that I'm not pushing the device beyond it's performance limits (which could have been a possibility).

Dave W.