High speed serial link problems (SERDES/uC/FPGA)

[JVR]

Hi Chaps,

Apologies for the wall of text, but I tried to get as much info into the OP as possible.

I'm designing a board that needs a high speed link between two units, the link needs to be 16 bits wide, and fully async, as each bit is driven from a discreet component.

The current design uses a direct link from a STM32 to a TLK2541 serdes, and yes, I designed this with only cursory looks at the datasheet. 

Background

As such, I have a free running 100Mhz clock driving both the REF_CLK as well as the TX_CLK of the TLK2541, the idea was that the TLK would manage all the serdes and encoding duties, leaving me with a 16 bit bus to do with as I please. The use case for the 16bit bus is 4 bits connected to high speed 485 drivers, and 12 bits connected to the micro to implement a 4 lane 8 bit bus with two control bits for Data Ready and ACK.

D[0:7] - uC connected Data
D[8:9] - Lane Select (Purely a software function)
D[10] - Data Ready
D[11] - ACK
D[12:15] - Direct connect to 485 transceiver

These connections are duplicated on the RX side of each board for BiDi comms

Since I can get away with a fair bit of jitter on the micro side, I devised a DR/ACK system that would control the bus at any jitter level, and allow me to not care about the "sample frequency" of the serdes at 100Mhz. With this in mind, I am sure I can get good transfer at up to 10Mhz. (The serdes would "sample" the 16bit bus at 100MHz)

Problem
So I built it, and started playing, only to realize that I really was stupid in not studying the datasheet. The TLK2541 needs sync words to be sent on the data lines every now and then to keep the PLL locked and to align the bytes on the TX/RX lanes. This of course needs to happen in sync with the TX_CLK. So no way I can get that working as the TX_CLK is free running, and I dont have control of all 16 bits.

Solution Idea
And this is where I need your opinions/help.
The idea I have is to use the TLK2501 serdes, this device is capable of automatically generating both the sync words, as well as idle patterns to keep the link active. As an upside, it also has RX_LOSS to tell you the link is down, something the TLK2541 lacks. The auto-generation still needs to be triggered in sync with the TX_CLK though, but instead of being placed on the bus, all it needs is a pin to be toggled.

So I was thinking of using a small CPLD like the CoolRunnerII in-between the serdes and the rest of the circuit, to "manage" the link. The CPLD will be fed the free running 100Mhz clock, and it is in charge of supplying the clock to the serdes. The idea here is that I halve the bandwidth of the parallel side of the link, and allow the CPLD to generate a sync word for every 2nd clock pulse, but only accept/reveal the valid data on its pins on every other clock pulse, thus hiding the sync from the rest of the circuit, and allowing me to do as I please with the 16bit bus, albeit now at 50Mhz sampling, not 100Mhz.

So the questions:
Will the above small function fit in a CPLD? (Xilinx XC2C24)
Will the CPLD be fine at 100Mhz?
The cost difference between a CPLD and a FPGA is small, is it worth doing this in an FPGA and have some future proofing in there?

I'm a bit of a CPLD/FPGA noob, having only done two small projects with them, so please help a brother out. If anything is not clear, ask away.

Thanks,
JVR

[Scrts]

Well you can take a small FPGA and use LVDS with 8b/10b encoder. In this case, you'd still have to create the protocol by yourself, since you need to recover the clock.
- Does the line have to be 10MHz*16bit = 160Mbit/s?
- Do you have only one LVDS pair?

Having these answers would let us discuss further.

[JVR]

The output from the serdes is fed to a SFP module to send it down a fiber line, so in answering your question, there are two LVDS pairs, one for TX one for RX.

I'd prefer the line to be at 20Mhz*16, but I'll manage with the 10Mhz.

Skipping the serdes for an FPGA might work, however the little Spartan 3 I have on hand can only do LVDS up to 666Mhz, leaving me with about 3.3Mhz available on the parallel side. And a Spartan 6 would be more expensive than a serdes+cpld combo.

I've attached a snippet from the schematic. Its currently modified like so:

Modifications:
TXD[16] and TXD[17] connected to the microcontroller
TX_CLK switchable between the REF_CLK input and a pin on the Micro.

System State:
TXD[0:15] and RXD[0:15] connected to a microcontroller.
CTRL0, CTRL1 connected to Microcontroller
RXRATE connected to microcontroller
LOOPEN connected to microcontroller
REF_CLK is fed a 100Mhz signal from a PLL

[Scrts]

666Mbps / 16bits = 41.625MHz. Seems like more than a double of your needs.

How fast is the fibre line? Is it fibre Ethernet? In this case, you will have to implement all the synchronization and idle words according to the standard, plus the line has to have a fixed bitrate pushing idle signals when it's not in use.

I'd say FPGA is the way to go. You can have maximum speed SerDes, while the microcontroller side can be slow. You just feed the data to the FIFO and the FIFO would work as a gearbox accelerating data to the SerDes. When there is no data, the idle signalling is created.

[funkathustra]

How fast is the fibre line? Is it fibre Ethernet? In this case, you will have to implement all the synchronization and idle words according to the standard, plus the line has to have a fixed bitrate pushing idle signals when it's not in use.

JVR isn't using any standards-based protocol -- he/she just wants to send data serially.

 I like JVR's idea of using a CPLD to run all the signals through, which would occasionally interject a comma signal for word alignment, however, I have a hard time believing that chip + CPLD is going to be cheaper than an FPGA with a SERDES built-in.

One other thought: JVR mentioned that the communication only needs to run 16bit @ 10 MHz. A 160 MHz SERDES shouldn't be too difficult to implement on a higher-end CPLD or a low-end flash-based FPGA.

[codeboy2k]

What's preventing you from using the TLK2501 ?

You started with a TLK2541 and a free running 100Mhz REFCLK and TXCLK.  But this lacks the feature-set necessary to automatically keep the link in sync, and you have no access to the clock to send sync data anyways.  So then you yourself suggested the TLK2501 which can do this for you automatically.

But everyone is talking about FPGA's and CPLD's as an in-betweener to stuff sync data into the TLK2541. Sure, that will work as you described, but  it's going add $3-$4 to you BOM and will require some HDL coding and debugging time.  The total cost of the FPGA/CPLD + TLK2541 is about the same cost as the TLK2501, but without any extra HDL coding and debugging effort.

It seems like a no-brainer to me.  Use the TLK2501, it does all that you need without extra effort at the same cost.

Other suggestions to write your own serdes in a small FPGA is acceptable only if you are willing to devote the time and effort to do so. You can do it with a $2.70 part like the Lattice iCE40 , but you are limited to 480Mbps LVDS. Then 480Mbps / 20bits (16 bits = 20 bits in 8b10b) = 24MHz sample clock on the 16bit data lines. The effort to write a synchronous SERDES is not trivial, you need to get the two ends in sync, do 8b/10b encoding, data framing, mark data and idle words, extract the clock at the other end, then re-sync when it's lost, etc.

Why do that unless cost was a major contributing factor and you were going to make 10's of thousands, in which case the effort spent on HDL development could be amortized. Otherwise, the price of the TLK2501 is cheaper, in the bigger picture.

[JVR]

Right, been a while since I've had time to get on here.

 

What's preventing you from using the TLK2501 ?

At this point, the fact that is an unknown. After some serious effort, I got the TLK2541 to sync, by using the tristate buffers in the uC to great sorcery out of spec 

In the meantime, Ive had the prototype at a tradeshow, and the reception is great, so I know I can get these sold. Silicon BOM cost is minor, as the final product will be getting north of $400 worth of connectors. I also have a new high-speed serial feature we want to add to the next prototype, so I'll be going with the CPLD. I've got a coolrunner dev board on order, and will have a bash at getting the logic needed in there before we respin the boards.