Forum Discussion
Honored ContributorConstraints from LVDS blocks and logic
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 MT21 Replies
Altera_ForumIf 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
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
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
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
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
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
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
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
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
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
