Forum Discussion
Altera_Forum
Honored Contributor
17 years agoThanks 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.