FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

altlvds bit alignment question

Altera_Forum
Honored Contributor II
1,489 Views

Hi, 

 

I have a noob question. I'm using a Cyclone 3 FPGA and use the ALTLVDS megafunction. The lvds link works fine, but I had a technical question of how the megafunction handles frame bit alignment when using a serialization value like 8. My colleague claims would be handled by the mega function, but its not clear to me this is the case and how it would do it. When I say "frame", I mean the "frame" is the parallel data word going into the tx mega function which then is serialized over the lvds link. The rx mega function re assembles serial data back and presents parallel data word "frame" at the receive side. 

 

My board lvds link is not using CDR and has a separate tx/rx clock pin. The link does work correctly when used correctly. During debug I can sometimes get the link to get fouled up. Unplugging lvds cables/ reconfig fpgas while the system is running does it. I dont have a exact method to do this. Usually when the link is fouled up I reprogram both tx and rx fpga chips and the link goes good again. This issue supports thoughts that the ALTLVDS megafunction does not have a header block to allow it to re sync if it somehow get out of bit alignment. What I mean is unless there is some extra info or control signals, I do not see how the RX can correctly re package the frame data if it gets out of sync somehow. The frame cannot be reassembled is unless the ip encodes some unique header before the data so that IP can use this to insure the frame is aligned or realign it if it was out of sync. That is my thinking. 

 

This problem comes up only when I'm doing not normal things so I'm not too concerned. I do however wish to know how smart the LVDS mega function is and how it recovers if it does have the smarts. Please share.
0 Kudos
2 Replies
Altera_Forum
Honored Contributor II
698 Views

Oh never mind. I was reminded that the slow clock provides timing info to keep frames in sync.

0 Kudos
Altera_Forum
Honored Contributor II
698 Views

I guess, the reported sync problem is caused by a loss-of-lock of the receiver PLL. Basically, the PLL must be reset (by pll_areset) after a stable reference clock is supplied respectively supplied again. As far as I see, no automatic reset is provided for the internal option.

0 Kudos
Reply