Forum Discussion
Honored ContributorALT_LVDS timing fails for core clock
Hi,
I'm using Quartus 13.1 with a Stratix IV GX dev kit. Trying to implement a simple test design for a 6 bit deserialiser using ALT_LVDS Rx. But I'm getting timing errors in a weird place. The register at the outputs of the LVDS_Rx megafunction. The slow clock. Timequest says the launch clock is the dast clock (480MHz). The latch clock is the slow clock (80MHz). And there are hold errors. I don't see why these exist. Is there something wrong with the way I am reading them? Its a simple design. 8 channels Lvds Rx with 6 bit deserialiser. Slow speeds. Feeds to a DC FIFO.. But I can't meet timing according to quartus.. Attached a couple of screenshots if it helps. Thanks ZubairLK https://www.alteraforum.com/forum/attachment.php?attachmentid=8454 https://www.alteraforum.com/forum/attachment.php?attachmentid=845521 Replies
Altera_Forum--- Quote Start --- I can see the register clocked by rx_outclk so the reported path does not exist. Clearly wrong reporting unless fitter removes it which I doubt. hold multicycle must always be 1 less than setup multicycle (for all source sync cases) as this says the launch/latch edges are those aligned with zero relationship so 5 is ok. --- Quote End --- I'm sorry. I don't understand. The reported path is the one between the SERDES blocks and the register. The dataout from the serdes is at fast clock. And the register is clocked at slow clock. It is still within the LVDS megafunction. This should always work..- Altera_Forum
your first post path is reported between rx lvds and fifo input
your last report(i didn't read it) is now different and is about lvds internal path - Altera_Forum
It is also important to know who set the multicycle to 6/5. Was it you or the lvds ip deconstraint
- Altera_Forum
First post was because I was registering the LVDS output outside in the FIFO.
Now I am trying to register the outputs using the LVDS Megafunction as suggested in earlier posts. And the LVDS IP set the multicycle constraints itself. Not me. I only set up input clock with 90 phase and input delay constraints. Which shouldn't affect core-clock timings. Something tells me its just because there are 8 LVDS Rx channels. It can meet timing on some of the registers. But not on all of them.. - Altera_Forum
Having mc of 6/5 on this path should not be a problem for the fitter, I am surprised. Your problem also got a bit changed from post to post.
you may try this test: add delay to data path as it is too early relative to clk. you have up to 6 clocks to delay it. but two or 3 clock delays should do (on the fast clk period) - Altera_Forum
I don't know how or why the 'optimize hold timing' option was not selected in the fitter settings. Once selected, I started meeting the hold timing..
Thanks for the help and Sorry for the bother. ZubairLK - Altera_Forum
thanks for the feedback. This option is on by default in my version.
It is a bit weird that the tool can be set to not optimise hold when it can detect it then fail it without attempt to add delays. - Altera_Forum
You usually want the hold to be one less than setup. Create a simplified project with your altlvds block and an .sdc that exhibits the problem. So far everything looks good, but if it's something I can compile quickly I'll try and take a look.
- Altera_Forum
Thanks Rysc.
Problem resolved as the 'optimize hold timing' option was not selected in the fitter settings. I checked by opening a fresh golden_top project as well. The hold timing was not selected.. Pretty cruel btw. This is Quartus 13.1 And the Stratix IV Gx development kit. Thanks ZubairLK - Altera_Forum
The reference design that came with it had it disabled? If so, could you file an SR or attach a link to the project? That should not be the case, and is cruel to figure out.
