Hi, I have a lvds tx and rx blocks in a Stratix3. There a 20 bits with deserialisation factor of 4. With the Rx side, the data leaving the lvds is registered. The lvds and registers are using clocks from a PLL. TimingQuest gives me an erro and show the sclkout rising edge as the source clock but with the rising edge of the register clock directly underneath. I've used the write sdc command and got the lvds constraints it generates. However, they just don't seem to cover this path between the sclkout and the registers. I would have though that the hold time would have been 4 sclks. I do have a clock mux on a couple of outputs from the PLL and it's the output of the mux that drives the registers. I don't know if this is cause a problem or not. If I put a hold time of 2, then problem goes away but is TimingQuest highlighting a problem? Regards MT

Does your LVDS block have the PLL, or are you creating it outside? If embedded, I think the multicycle constraints should automatically be done in the IP(or they get added when you run derive_pll_clocks). If there outside of the PLL, then in the Megawizard when you check this option, a pop-up comes on and tells you what multicycles to add. It doesn't do exact syntax or endpoints, since some of the registers are in your logic(I think). If you want to, make a side project, copy the LVDS blocks over and have them create the PLL. Throw them into a schematic and compile, and see what MCs are run when you do derive_pll_clocks.

Thanks for the info. When I say that I want a an external PLL, a pop-up box does appear but it states the clock requirements and that you need logic registers but nothing about multi-cycle constraints. However, in the ArriaGX FPGA's, if you do the same thing, it does come up with mc constraints that you must have. Interestingly enough, it doesn't include a hold constraint here either, only a set-up one. The clock is 156.25MHz, so, with serialisation factor of 4, we get the sclk to be 4 x 156.25 = 625MHz. The enable that the lvds block needs is 156.25MHz but with a 25:75 mark space ratio. Now, if I shift the sclk to +180 or -180 degrees and keep everything else at 0, there is no hold timing error and you can see the the sclk has shifted relative to the register clock. MT

It's probably talking about MCs for the Classic Timing Analyzer(which behind the scenes would add a hold multicycle). For the most part, a setup mc of 2 in classic would be done by a setup MC of 2 and hold MC of 1 in TimeQuest. Or more exactly, a setup of N in Classic is a setup MC of N and a hold MC of N-1 in TimeQuest. (Although if you're phase-shifting your clock, that may not be accurate, since Classic TAN did a thing called normalization. For whatever MCs you add, I would explicitly do a report_timing -setup and -hold on those paths and make sure the setup and hold requirement is what you expect.)

I've looked at the the path summary tab in TimingQuest for one of the paths that has failed: from: ...generated|wire_rx_dataout[29] to: postlvds_rx_regd1[29] and it says: Multicycle-Setup Start 4 Multicycle-Hold Start 3 Data Arrival Time 3.759 Data Required Time 4.164 Both the launch clock and latch clock start to rise at 0.8ns. It does appear that there is this hold time hidden in there. But I don't understand where those 3 cycles went. If I set a hold time of 1 clock (end, not start) the timing errors disappear and in the waveform, the rising edge latch clock is at 0.8ns but the sclk launch clock is now at 7.2ns and the hold relationship is shown as -6.4ns. I don't really understand what this is telling me. I hope you can shed some light on it. Thanks MT

When the launch and latch clocs rise at the same time(for hold analysis), that is essentially a hold requirement of 0ns. That means your data path must be longer than your data required path, which I believe is correct. Did you re-fit after adding these constraints, or just re-run TimeQuest? Did you have Assignments -> Settings -> Fitter -> Optimize Hold Timing set to All Paths during the fit. In this last post, are you describing the receive side or transmit side? What's your setup requirement? When you went to a hold time of 1 clock -end, did you also change your setup multicycle, since the hold requirement is dependent on the setup requirement. (I posted a document on how MCs work a while back, which might help. Let me know if you can't find it.)

Constraints from LVDS blocks and logic | Altera Community

21 Replies

Altera_Forum
Honored Contributor
17 years ago
Thanks Rysc.

I did signal tap the data straight out of the lvds block and also out of the registers, and it was going wrong out of the lvds block. I've managed to get something working by tweaking the lvds sclk phase and enable. But on top of this, I changed the DPA settings so that it's using the rising and falling edges of the clock. This is also helped nudge it in the right direction.

I tried adding the clock uncertainty and it didn't make any difference to the results. I also tried changing the constraints but it didn't help either. With the hold error, what it's telling me is that launch clock is getting there very quickly and the latch clock is much slower, hence the hold error. The all paths setting fixes is it for now but I'm not sure what more can be done with this.

What I'm finding from the main build (which uses TAN and this lvds section gets intergrated into it) is that it still seems to try, for example, to meet a 1.6ns (625MHz) timing requirement from the registers in the fabric to the tx lvds registers when the multi-cycle constraints say that the setup time is 3 clocks. I have no idea why it's trying to do this. I don't know if it's trying to do the same with the rx side too. Any idea's why this might be the case? Is it because I've changed the sclk phase in both the rx and tx lvds blocks?

I've added a set of multi-cycle constraints which I translated from TimingQuest. I know these are supposed to built-in but the above seems to suggest it's ignoring them. Maybe that's why there is a hold error too.

Forum Discussion

Constraints from LVDS blocks and logic

21 Replies

Recent Discussions

Issue with configuring EPCQ64A & Cyclone

Agilex5 A5EB013BB23BE4S BSDL

MAX 10 FPGA Programming Failure via JTAG – nSTATUS & CONFIG_DONE as No Connect

ASx4 Interface debug in MSEL=111 (JTAG mode)

Avalon-ST configuration with Agilex 3 fails