- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oh never mind. I was reminded that the slow clock provides timing info to keep frames in sync.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page