Constraints from LVDS blocks and logic

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

Thanks for the info. I would appreciate a link to the doc you've mentioned. 

 I didn't refit after adding the constraints - I just re-ran timingquest. I know that when I've tried this before, if I were to re-run the design with the new constraints, it will work.   My problem is that I don't understand what's happening. I don't know what are the correct constraints are for data leaving the lvds block. I've relied on whatever is built in to the models that I'm using. So far it's been fine. In this case, it looks like it's failed, since it appears that a set-up time of 4 and a hold time of 3 is what's required and it's failing the hold time one. And that coupled with what it's telling me about about data arrival/required times, then as you say it's telling that there is a problem here.   That optimize paths setting I know isn't set to all paths - it's on the default setting. I've seen this set to all paths on designs and I've seen the fitter report correcting hold time errors by delaying signals. I presume this should be tried first? Is this a good way to do things?   Since I have control of the phase between clocks, I thought that if I could understand what is happening and what the fix is, then I could adjust the timing and make it more solid without relying on the fitter to look for ways of delaying a signal.   When I tried to change the relationship in the PLL between sclk and the register clock, those two edges were still always together and there were hold errors. It was only when I tried changing the sclk and leaving it's enable alone, that I saw the errors disappear. In fact it didn't matter whether you went +ve or -ve phase, it solved the problem. You could see on the waveform that the launch and latch edges were seperate.   The way I have the pll set-up is:   c0 = 625mhz to lvds c1 = 156.25mhz enable with 25:75 mark:space to lvds c2 = 156.25mhz for clocking logic   So, the problems are between c0 and c2. From what I can see in my notes, changing the phase relationship between c0 and c1, keeping everything else the same, results in the rising edge of c2 (latch) being first and then c0 (launch) being second. It seems to be like that irrespective if the phase is +ve or -ve.   Thanks   MT

[Altera_Forum]

I've tried the all paths settings and it does work, however, when I intergrate this block into the main design (this is just a sub block in a much larger design) some of the paths fail the hold timing. So, I really need to understand this timing problem so that I can put in a fix that doesn't depend on the tools delaying the signals. 

 Any help would be most appreciated.   Thanks   MT

[Altera_Forum]

Another thing I've noticed is that even though it says 'Multicyle-Hold Start 3' in the path summary section, it says in the waveform window of 'TimingQuest', "No Hold Multicycle Exceptions/No Exceptions" which seems to suggest that there are hold execptions despite what's in the path summary window. 

 I also found that if I set a multicyle hold constraint of 3 between the failing paths, it doesn't work but if I do the constrain between the two clocks, then it seems to work fine.  So, I don't know if there is something missing here regarding the hold constraint that should have been in or hasn't been picked up correctly.  MT

[Altera_Forum]

Here's the link: 

http://www.alteraforum.com/forum/showthread.php?t=1845&highlight=timequest  If the hold constraint doesn't work on the individual path but does on the clocks, my guess is that the one of the names in the path constraint doesn't work. You should get a message about this while reading in the .sdc file(also double-click ReportSDC to see if it's there). The messages in TimeQuest are worth looking at, as there's not a whole lot of fluff. So based on your clocks, if co feeds the LVDS receiver and c1 feeds the capture registers in the fabrice, and if you're not phase-shifting them(i.e. they're edge aligned), then the setup requirement should be 0ns and the hold requirement should be the period of the faster clock(1.6ns). Adding a multicycle -setup 4 on the path or the clocks(both should work), will make the setup requirement be 6.4ns, but as the presentation shows, the hold requirement will follow and be 4.8ns. Adding a multicycle -hold 3 will get it back to 0ns. So if your hold requirement is 0ns and the setup requirement is 6.4ns, that means the data can pass between the two registers anywhere between 0 and 6.4ns(and clock skew will factor into that too). From a physical standpoint, I believe the output registers of the LVDS block are clocked by the fast clock, but are enabled at the deserialization rate, i.e. they're clocked by the 625MHz, but only every 4th clock(it is a parallel load of the data coming in serially). Then you have one clock cycle of the lower clock rate to transfer the data to your registers, which is what the MCs are saying.

[Altera_Forum]

Thanks for that link. I'm par way reading your doc and it's very interesting. 

 The thing about when I generate the constraint on the path, rather than using the clock and it doesn't work, is that I actually create that constraint in TimingQuest by right clocking on the failing path and then setting the MC from there. So, I don't actually creat that directly in the sdc file.  I understand what you are saying about the registers on the output of the lvds only presenting new data every 4 clocks since that's the deserialisation factor. I didn't add the set-up and hold constraints as these seem to be built in to the lvds stuff. So, I'm not setting these constraints and I'm just trying to meet whatever they set.  This hold requirement which is turning out to be 0 is something that Altera have set. From what you're saying, by adding that hold cycle of 3, Altera have effectively made the hold time 0ns. So, when TimingQuest tells me that I have a hold time violation, then it's telling me the truth?  All I want to do is clock the data corrctly into those registers every 156.25MHz clock cycle. I do have any additional constraints apart from that so I'm just going with whatever altera have set the setup/hold constraints to be and I'm just trying to make sure it fits that timing. I don't want to fix it by adding a constraint that's not valid.  The only way that I found that it can be fixed(without changing timing condtraints) is by changing the relationship between the 625MHz clock to the lvds and it's 156.25 enable.  Regards  MT

[Altera_Forum]

If the constraints are already there, then you shouldn't be adding constraints(they need to be added in the case where they're not added). Anyway, rather than go back and forth, create a quick schematic/HDL file with the LVDS block coming in, feeding some registers and going out, or something like that, the PLL(if you instantiate one) and the .sdc file that reflects what you have, archive it and attach it. I generally don't look at designs(not enough time), but it should only take a minute or two and faster than posts asking questions.

[Altera_Forum]

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.

[Altera_Forum]

I've attached a screenshot of what TimingQuest reports.

[Altera_Forum]

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]

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]

Is there a derive_clock_uncertainty equivalent for TAN? 

 Thanks  MT

[Altera_Forum]

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]

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]

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]

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?