Stratix V DSP Kit Transcievers

[Altera_Forum]

Hi, 

 I was looking at the schematic and the reference manual for the Stratix V DSP development kit  http://www.altera.com/products/devkits/altera/kit-stratix-v-dsp.html  The transceivers are on Bank 1 of the HSMC ports A and B.  What I don't understand is why there are single-ended clock input/outputs on the banks of the port for transceivers. Am I missing something? Can transceivers function easily without a differential frame clock?  I have a differential frame clock I'd like to use to simplify the of deciphering the data-stream.   But I can't connect it to the Transceiver PHY mega-function's CDR reference clock.  And connecting the single-ended clock to the CDR reference clock of the mega-function isn't working either.  Any ideas as to where I am going wrong?  Thanks Zubair

[Altera_Forum]

--- Quote Start ---   What I don't understand is why there are single-ended clock input/outputs on the banks of the port for transceivers. Am I missing something?   --- Quote End ---   The HSMC standard does not define clocks for the transceivers. The connector defines clocks, but says nothing about what they need to go to. Ideally there would be a clock going to a transceiver block REFCLK input, but that is not a requirement.    --- Quote Start ---   Can transceivers function easily without a differential frame clock?   --- Quote End ---   The term "frame clock" is terminology used to describe a lower-speed clock that is synchronous, i.e., has some form of time alignment, with LVDS data.  A transceiver has a REFCLK, which is a reference clock with a relationship to the bit-rate of the transceiver data, but no requirements on a phase relationship (other than being low jitter).    --- Quote Start ---   I have a differential frame clock I'd like to use to simplify the of deciphering the data-stream.    --- Quote End ---   That'll never happen. The receiver CDRs lock their own PLLs. You cannot recover multi-bit-width data unless the data stream itself has some form of synchronizing code embedded within it.    --- Quote Start ---   But I can't connect it to the Transceiver PHY mega-function's CDR reference clock.  And connecting the single-ended clock to the CDR reference clock of the mega-function isn't working either.  Any ideas as to where I am going wrong?   --- Quote End ---   Check out the example designs that come with the kit. Perhaps they have a clocking scheme example you can re-use.  What are you trying to do?  Cheers, Dave

[Altera_Forum]

Thanks, 

 Currently, I'm compiling and checking pin-outs and assignments to see if our intended hardware PCB can connect between the devices. This particular case was connecting LVDS to CML via AC coupling.  I wanted to connect the LVDS frame clock to the CML CDR clock and see if the data can be recovered easily.  Thanks Zubair

[Altera_Forum]

--- Quote Start ---   I wanted to connect the LVDS frame clock to the CML CDR clock and see if the data can be recovered easily.   --- Quote End ---    You've got a couple of options;  1. Configure the receiver CDR in lock-to-data mode, and feed the LVDS clock into a receiver channel (not a REFCLK, since you don't have one on the HSMC connector). LTD mode requires starting in lock-to-reference mode, which would require an on-board clock source close to the LVDS frame clock.  2. If you are running this board in stand-alone mode, since it is a PCIe form-factor, then you can use a PCIe edge-connector SMA breakout board (Samtec sell them - I have a couple of them). You can then feed the PCIe CLK which will go to a REFCLK with your LVDS frame clock.  However, that still doesn't help you decode your data.  The receiver transceivers start serial-to-parallel conversion of their serial data streams at an arbitrary point in time. LVDS SERDES deaserialize with respect to the frame clock, so you can easily recover your data with them, no matter what the format. For transceiver data recovery, you need to send special codes, or use 8/10B encoding to perform alignment of your bytes that have been serialized.  Cheers, Dave

[Altera_Forum]

So basically doesn't matter what I do with the frame clock and the transceivers. 

 I need my own glue logic for byte/word alignment of my data. :)  It might just be easier to embed the frame clock in the same data stream.  Thanks a lot, Zubair

[Altera_Forum]

--- Quote Start ---  So basically doesn't matter what I do with the frame clock and the transceivers.   --- Quote End ---   Exactly. A transceiver block is not just a faster LVDS, its a different beast entirely.    --- Quote Start ---   I need my own glue logic for byte/word alignment of my data. :)  It might just be easier to embed the frame clock in the same data stream.   --- Quote End ---   Depending on your setup, it can be even more restrictive than that. For example, if you are AC coupling the signals onto the transceiver receivers, then you must have enough transitions on the input to keep the CDRs locked. If you DC couple the signals, then you won't get the RC discharging you would with an AC connection, however, you still need enough toggles on the data to keep the CDR PLLs in lock-to-data mode.  If you explain what you are trying to do, I can offer some suggestions.  Cheers, Dave

[Altera_Forum]

Data from a DE3 board via 8 LVDS channels to a Stratix V board via 8 transceivers. 

 Each channel takes data from a FIFO on the DE3 and I need it on a FIFO on the Stratix V.  The data is 12 bit wide. (I pad zeros while the data is in the FPGAs but will be removing the zeros before transmitting via the link)  A tricky mess indeed. And of-course. As fast as possible which is around 1.6Gbps (so technically 1.28Gbps max actual throughput if 8/10b encoding)  Thanks Zubair

[Altera_Forum]

--- Quote Start ---  Data from a DE3 board via 8 LVDS channels to a Stratix V board via 8 transceivers.   --- Quote End ---    Why use the Stratix V board transceivers? The HSMC connector has LVDS too. Why not just connect LVDS to LVDS?    --- Quote Start ---   A tricky mess indeed. And of-course. As fast as possible which is around 1.6Gbps (so technically 1.28Gbps max actual throughput if 8/10b encoding)   --- Quote End ---   If you have to use the transceivers, and you plan on 8/10B encoding, then you should have no trouble configuring the Stratix V transceivers to receive and automatically align the data streams based on the 8/10B encoding.  Cheers, Dave

[Altera_Forum]

The LVDS are already being used for another data stream. All of them except 1 data channel.. 

 8/10b encoding it is. Can you give some guidance for the hardware folks? Because they want to get the PCB routing done as soon as possible.  I am asking for single-ended signals to port B. Plain and Simple. And 8 data channels to the transceivers(AC coupling them).  At the moment, I'm also asking them to route the frame clock to port B on an LVDS dedicated clock port. The clocks on the same port are already populated.  Its a little farther away from the transceivers. Don't know if they'll be useful or not. But just in case.  Any tips or anything I'm missing?  Thanks Zubair

[Altera_Forum]

I could use that one free LVDS data channel to keep the frame clock nearby.. Hmm. But they are physically separate on the FPGA anyways. Transceivers on the columns. LVDS on the rows.. 

 Just rambling..  Zubair

[Altera_Forum]

--- Quote Start ---   Can you give some guidance for the hardware folks? Because they want to get the PCB routing done as soon as possible.   --- Quote End ---   Before you route anything on a PCB you need to create a Quartus project to ensure that it is feasible.   For example, that will confirm that your frame clock can be used as a transceiver reference clock, or if it cannot. If it cannot, then you need another plan.   The way I design these things is;  1) Determine my options (by looking at an evaluation board)  2) Create a block diagram of my interface logic (eg., your proposed HSMC design)  3) Create a Quartus project that interfaces to the proposed design.   If the design synthesizes Ok, i.e., no warnings about clocks or invalid tool settings, then you have much higher confidence that your design will work.  4) Simulate the design.   Make sure you can actually use what you propose, eg., decode the 8/10B data and make sure you can recover data across multiple lanes.  This is all work that is needed in the final application, I'm just advocating that you do it first, so that you do not waste time on a PCB that cannot work.  Cheers, Dave

[Altera_Forum]

:) 

In an ideal world, that would be great. Unfortunately, I stumbled a bit on step 3 let alone step 4. And somebody wants a decision for the PCB soon.  Thanks for the help. I'll spend some time trying to synthesize the design and connections.  Cheers Zubair

[Altera_Forum]

--- Quote Start ---   In an ideal world, that would be great. Unfortunately, I stumbled a bit on step 3 let alone step 4. And somebody wants a decision for the PCB soon.   --- Quote End ---    You're not alone :)  It is critical though that you check that synthesis is "possible", otherwise the PCB is useless.  Cheers, Dave