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.
Altera_Forum
Honored Contributor
17 years ago
The message is valid for TAN and TimeQuest. The reason it makes you add them is that the destination is your own register driven by your own clock, so if you do anything "funky", you may want a different timing assignment.
I would really make sure that it's a hold issue occuring at these registers. Are you SignalTapping the capture registers(the first registers in the fabric), so you know the data at that point is incorrect? If you can do my experiment mentioned before, where the delay to these registers is longer and shorter, what happens, i.e. does getting the fitter to add delay fix everything? If you take the failing design and heat it up, does it start to work? Do the errors get worse if you cool the part down?
Altera_Forum
Honored Contributor
17 years ago
I have no problem using TimingQuest but at the place I work they use TAN. With my designs, I use TimingQuest but the main build of the design still used TAN. Just on a side note, MC constraints are built-in to the lvds blocks, so I don't have to add them in TimingQuest or TAN? I do remember when I selected to use an external PLL for the lvds, a message appears that I had to add constraints manually from lvds block to registers. Is this still valid or is this for TAN only?

It does look like we have a skew problem, something that doesn't appear with this design in the STX3 150 part. I've set it to run with the derive_clock_uncertainty. Not sure if there any other lvds constraints that we need to have. I've seen stuff about rskm, tccs etc. Not sure if this applies here.
Altera_Forum
Honored Contributor
17 years ago
No derive_clock_uncertainty for TAN. It's only for 65nm and newer products, and I'd really, really, really, really recommend using TimeQuest. Really.
Altera_Forum
Honored Contributor
17 years ago
As a test, set your partitions(you probably only have one unless doing incremental compilation) to Post Fit(Strict) - Placement Only. So your next compile will just re-run the router. Also add a set_min_delay -hold 400ps on these paths, which increases the hold requirement by 400ps, which increases the hold requirement from 0ns to 400ps.(and make sure the fitter setting to Optimize All Paths is on, so the router can add delays to meet hold timing is on. Also check the Optimize All Corners). Re-compile. It should take a few minutes and just re-route, and hopefully it will add delays to these paths. If that's worked, re-run the hardware test. I just want to make sure that you're really having a hold violation on these paths, and that should be a good test.
Altera_Forum
Honored Contributor
17 years ago
Is there a derive_clock_uncertainty equivalent for TAN?

Thanks

MT
Altera_Forum
Honored Contributor
17 years ago
Thanks Rysc. I've tried the set_clock_uncertainty and it didn't make any difference to the output. I put a clock_uncertaintly setup on the lvds clock and the lvds enable. What I can say is that using the lvds enable (on c1 of the pll) for the logic as well, has improved it. If you consider a 64 bits bus split into 4 lanes, then we should get a 0707 pattern on each lane but instead we get the following (lane0 is bits 15 to 0, lane is bits 32 to 16 etc):

lane0: 0707
lane1: 0E07
lane2: 070E
lane3: 0E07

All timing constraints have been met - setup and hold. I also have DPA on the lvds block which might be making things worse.

I have tried all paths before and when the device gets full, it struggles to find the extra routing for the delay to meet any hold time requirements.

I noticed that there a tcl commands called 'max_clock_arrival_skew' and 'max_data_arrival_skew'. Not sure if we can use these or not? Can tcl commands as .sdc commands - are they usable in this way?

Thanks

MT
Altera_Forum
Honored Contributor
17 years ago
With a 0ns hold requirement, it's almost impossible to get a hold failure without some clock skew, but since the clock may use a dedicated path to the LVDS, that's certainly possible(I don't remember off the top of my head). Two points, make sure you have derive_clock_uncertainty in your .sdc file(which makes timing more difficult to meet), and in Assignments -> Settings -> Fitter, turn the Hold Optimizations to All Paths.
Altera_Forum
Honored Contributor
17 years ago
I've attached a screenshot of what TimingQuest reports.
lvds_hold.zip62 KB
Altera_Forum
Honored Contributor
17 years ago
Rsync - apologies for the late response. I've been stuck with other things which is why I haven't had time to look at this.

We're looking into something that is related. We have the following setup: there is a pll with outputs c0(625mhz lvds clock), c1(lvds enable) and c2(with a 156.25mhz logic clock). There is a set of registers on the output of the lvds block - a 64 bit bus. What we find is that from bit 0 to bit 63, the data seems to get more corrupted. What we're thinking is that c0, c1 and c2 are all on different clock networks which may result in skew between networks but also how Quartus handles the timing in this case. What we're trying is use c1 not only as the lvds enable but also as the logic clock to force it all on one clock network.

This test version of the design works perfectly in an Stratrix 150 but not in a Stratix340. That with identical code and constraints.

Forum Discussion

Constraints from LVDS blocks and logic

21 Replies

Recent Discussions

Can Agilex 3 A3CY100BM16AE7S (AXC3000) use SDM cryptographic services?

Product Marking for Stratix III

Quartus 25.1std | Signal Tap Crash

The Quartus Prime Lite Edition Installer 23.1

Request for details<46206 >