ALT_LVDS timing fails for core clock

[Altera_Forum]

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=8455

[Altera_Forum]

Are you saying the serial clock in is 480MHz, serial out is 80MHz then you have dc fifo on 80MHz write side and 480MHz read side? are your clock connections correct. Can you give a short description of your over all design and its clocking scheme.

[Altera_Forum]

I am only receiving data from the LVDS_Rx megafunction 

 ADC sending 12 bit serialized data at 480Mbps. Clock at 480Mhz as well.  I intend to use 6 bit SERDES. And will mux the data later to form 12 bits.  8 channels of serialized data goes into the LVDS_Rx megafunction. 6 bit deserializer 480Mhz clk input  the clk_output from the LVDS_Rx megafunction is 80MHz and goes into the write clock of a DC FIFO. The deserialized data output from the LVDS Megafunction goes into the data input of the DC FIFO.  Timing fails at this point.  The data output from the LVDS_Rx megafunction. I don't know why.  For some reason, timequest says the LVDS_Rx megafunction deserialized data 'output' is clocked at the fast clock (480MHz). and is being latched at the slow clock (80MHz) on the DC FIFO side.  Hope this explains ZubairLK

[Altera_Forum]

So you got two issues. clock wiring reported is wrong and timing fails. weird indeed. 

have you you entered sdc file just in case.

[Altera_Forum]

I believe there is a multicycle from the slow to the fast domain. Try adding "derive_pll_clocks" to your .sdc, as I think that will add it.

[Altera_Forum]

I do have an sdc. Define the clock inputs. Set the input delay based on setup and hold times. 

And have derive pll clocks in it too.  I'll paste it tomorrow morning from the lab.. But its a simple constraints. Took it from the DDR cookbook from the wiki.  I was wondering if giving LVDS megafunction the fast bitclk as clock input would be better or giving it the slow frameclock is better.. And if that makes it quirky..  Hope this helps. ZubairLK

[Altera_Forum]

--- Quote Start ---  I do have an sdc. Define the clock inputs. Set the input delay based on setup and hold times. And have derive pll clocks in it too.  I'll paste it tomorrow morning from the lab.. But its a simple constraints. Took it from the DDR cookbook from the wiki.  I was wondering if giving LVDS megafunction the fast bitclk as clock input would be better or giving it the slow frameclock is better.. And if that makes it quirky..  Hope this helps. ZubairLK  --- Quote End ---    if you have option of registered output on rx lvds then that must be checked. It could be they are not registered and data path is from from bitclk to fifo

[Altera_Forum]

I tried that. Same kind of error. Launch clock fast clock at 480Mhz. And latch clock 160MHz..

[Altera_Forum]

--- Quote Start ---  I tried that. Same kind of error. Launch clock fast clock at 480Mhz. And latch clock 160MHz..  --- Quote End ---    look at the rtl viewer to see why that path is so. I expect there is no register at outputof lvds

[Altera_Forum]

--- Quote Start ---  look at the rtl viewer to see why that path is so. I expect there is no register at outputof lvds  --- Quote End ---    Its there..  I notice the multicycle for setup is 6 and multicycle for hold is 5. These are done by the megafunction. Should the hold multicycle be 6 too?  Here is a screenshot with the RTL..  https://www.alteraforum.com/forum/attachment.php?attachmentid=8457

[Altera_Forum]

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.

[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.