UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Participant sjg69
Participant
1,144 Views
Registered: ‎03-29-2012

Using TMDS for a point-to-point link

Jump to solution

So I'm planning on using a couple of Spartan-7's to (amongst other things) take a parallel signal, squeeze it down to a serial link that can be pushed over a short USB-3 cable using the SuperSpeed diff-pairs, and on the other side, expand it back up again to be the same wide parallel signal. Effectively it's just a serdes pipe from one FPGA to another. As ever, the goal is low-latency, high throughput, with an additional constraint of "this has to go over a 1-3 foot cable".

 

Note that I'm not planning on *implementing* USB-3, I'm just using at as an easily-available electrical cable. I can get 2 Superspeed links for data in the TX direction (and use the separate 480 Mbit/sec line for a word-clock for a total of 3 diff-pair channels) and I can use 2 superspeed links in the RX direction (1 clock, 1 data). My transmit-requirements are far higher than receive so this works out for me.

 

I was originally planning on using a Spartan-6, but with ISE being ever-more-ancient, I was looking at using the S-7, which comes with slightly (1250 vs 1080 Mbit) higher signalling rates as well. The issue is that I was looking at using LVDS-33, since the FPGAs talk to other chips running at 3.3v, however from reading the S-7 datasheet it seems that LVDS is only supported at 2.5v or 1.8v in the S-7.

 

Level-translation introduces 5-6ns delays, as well as takes up board-space, so I'd prefer to go with a 3.3v solution if possible. Reading the SelectIO userguide it says that TMDS is supported at 3.3v, and since I'm controlling both ends of the link, I don't care what the signalling format is like, I just want it to work and work fast. Having not used TMDS before though, and since I need to change the board if level-translation becomes necessary, I had a couple of questions...

 

  • First up, I'd obviously like to use the ISERDESE2 / OSERDESE2 primitives(in networking mode) and train them with Bitslip, I'm assuming that none of these care what the signalling is at the i/o pad, they just parallelise/serialise as necessary, right ?
  • Second, I did see this question about how to specify the TMDS i/o standard whereas the S7 SelectIO user-guide (pg 95) says the IOSTANDARD ought to be specified as TMDS_33. Is this just a Spartan-6 (the part in the linked question) vs Spartan-7 thing ? Just making sure :)
  • Again, I don't care what the *real* TMDS protocol is, I'm just going to be blasting bits across as fast as I can and I'd prefer that to be at 3.3v - so I'm assuming that the IOSTANDARD of TMDS_33 just defines voltage levels on the bus, there's no requirement for the signals to actually *be* 8b/10b with a sustained average DC level ? That's not to say I might not end up using 8b/10b for error correction amongst other things, but it's not a requirement I hope :)

 

If you've reached this line, then thanks for reading all this. Designing the board and coming up with the verilog then all the software sitting on top is something of a stretch for me, so I don't want it all scuppered before I've even got started, by getting the board design wrong :)

 

Cheers

0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
1,169 Views
Registered: ‎04-18-2011

Re: Using TMDS for a point-to-point link

Jump to solution

Hi @sjg69

 

I'll try to answer:

 

First up, I'd obviously like to use the ISERDESE2 / OSERDESE2 primitives(in networking mode) and train them with Bitslip, I'm assuming that none of these care what the signalling is at the i/o pad, they just parallelise/serialise as necessary, right ?

 

The ISERDES/OSERDES will output data at whatever rate you set them to with the CLK/CLKDIV. No Dependancy on the IOSTANDARD.

To understand this best, I'd reccommend an IBIS simulation using the TMDS driver / receiver, the external components (The TMDS standard requires external 50Ω pull-up resistors to 3.3V on the inputs) and a model of the cable.. 

 

Second, I did see this question about how to specify the TMDS i/o standard whereas the S7 SelectIO user-guide (pg 95) says the IOSTANDARD ought to be specified as TMDS_33. Is this just a Spartan-6 (the part in the linked question) vs Spartan-7 thing ? Just making sure :)

 

the IOSTANDARD is called TMDS_33. 

You can set it in your XDC file like this

set_property IOSTANDARD TMDS_33 [get_ports serial_data_p]

You could also open the post synthesis netlist of your design and set it in the IO pin planning view 

 

 

Again, I don't care what the *real* TMDS protocol is, I'm just going to be blasting bits across as fast as I can and I'd prefer that to be at 3.3v - so I'm assuming that the IOSTANDARD of TMDS_33 just defines voltage levels on the bus, there's no requirement for the signals to actually *be* 8b/10b with a sustained average DC level ? That's not to say I might not end up using 8b/10b for error correction amongst other things, but it's not a requirement I hope :)

 

this IO standard is for DVI/HDMI so if they use 8b/10b then this is for a reason. 

As far as i remember the driver and the receiver with the 50ohm pull ups to the rail worked reasonable well when I checked it out in simulation. 

Again, an IBIS simulation would validate this for you. 

 

Keith 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
5 Replies
Moderator
Moderator
1,170 Views
Registered: ‎04-18-2011

Re: Using TMDS for a point-to-point link

Jump to solution

Hi @sjg69

 

I'll try to answer:

 

First up, I'd obviously like to use the ISERDESE2 / OSERDESE2 primitives(in networking mode) and train them with Bitslip, I'm assuming that none of these care what the signalling is at the i/o pad, they just parallelise/serialise as necessary, right ?

 

The ISERDES/OSERDES will output data at whatever rate you set them to with the CLK/CLKDIV. No Dependancy on the IOSTANDARD.

To understand this best, I'd reccommend an IBIS simulation using the TMDS driver / receiver, the external components (The TMDS standard requires external 50Ω pull-up resistors to 3.3V on the inputs) and a model of the cable.. 

 

Second, I did see this question about how to specify the TMDS i/o standard whereas the S7 SelectIO user-guide (pg 95) says the IOSTANDARD ought to be specified as TMDS_33. Is this just a Spartan-6 (the part in the linked question) vs Spartan-7 thing ? Just making sure :)

 

the IOSTANDARD is called TMDS_33. 

You can set it in your XDC file like this

set_property IOSTANDARD TMDS_33 [get_ports serial_data_p]

You could also open the post synthesis netlist of your design and set it in the IO pin planning view 

 

 

Again, I don't care what the *real* TMDS protocol is, I'm just going to be blasting bits across as fast as I can and I'd prefer that to be at 3.3v - so I'm assuming that the IOSTANDARD of TMDS_33 just defines voltage levels on the bus, there's no requirement for the signals to actually *be* 8b/10b with a sustained average DC level ? That's not to say I might not end up using 8b/10b for error correction amongst other things, but it's not a requirement I hope :)

 

this IO standard is for DVI/HDMI so if they use 8b/10b then this is for a reason. 

As far as i remember the driver and the receiver with the 50ohm pull ups to the rail worked reasonable well when I checked it out in simulation. 

Again, an IBIS simulation would validate this for you. 

 

Keith 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Participant sjg69
Participant
1,061 Views
Registered: ‎03-29-2012

Re: Using TMDS for a point-to-point link

Jump to solution

Thank you - that's really good to know. 

 

I'm going to have to ask about how to do these IBIS simulations that people keep talking about :) This is my first foray into high-speed (well, relatively, for me, we're not talking the 'T' model chips with their transceivers) serial links. There's always more to learn :)

 

Regarding 8b/10b; I was assuming that the HDMI spec was catering for a lot worse situations than my needs (literally a 1-foot long superspeed usb-3 cable) because it has to be able to run over a lot longer distance. I'm not averse to using 8b/10b if that's what it takes, it'll reduce my bandwidth a bit, but I'm fine with that if it boosts the reliability of the link. I'm just not sure yet that it's going to be required.

 

0 Kudos
Moderator
Moderator
1,056 Views
Registered: ‎04-18-2011

Re: Using TMDS for a point-to-point link

Jump to solution

you could see if you can download a trial version of Hyperlynx or see if there is a free simulator available online. 

I would encourage you to validate this topology with an IBIS simulation if at all possible.

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Participant sjg69
Participant
1,028 Views
Registered: ‎03-29-2012

Re: Using TMDS for a point-to-point link

Jump to solution

So, just to follow up on this. I started looking around for ways to simulate the high-speed (well, ok, high-speed *for me*) communications link, and since I didn't have $40k to drop on a HyperLynx license, I found PyBert which can be used for precisely this. It's really designed to work with the transceivers, but it works well for the TDMS signals as well. 

 

I got in touch with David Banas (the guy who wrote it), and he was good enough to give me some tips on how to configure the application for my Spartan-7 I/o by return email. Shout-out to David for such a quick response - I wish some of our *paid* support was as good...

 

To get the Spartan-7 specifics, I downloaded the IBIS model from Xilinx, and extracted the parasitic capacitance of the pin (ball, I guess, really), the single-ended voltage swing of the TMDS signalling option I intend to use (0.125v) and specified a cable length of 1' (actually 0.33m) which is the length of cable I'll start out with. Any USB-c cable under 18" is passive (there's no active parts trying to optimize the signal) which'll keep things simple. I also had to add in the C_comp parameter for the capacitance to model the Rx Buffer capacitance. I specified the cable differential impedance (90 ohms) and the differential source and receiver impedances (100 ohms). For a 1' cable it looks like:

 

Screen Shot 2018-08-24 at 3.13.16 PM.png

 

... and if I bump the cable up to 1m, it looks like:

 

Screen Shot 2018-08-24 at 3.15.06 PM.png

 

Note that these aren't specifically USB-c cables, the model is for a 28-awg twisted pair. If I get the individually-shielded-diff-pair USB-c cables it ought to be better than this. Anyway, this looks reasonably good to my untutored eye, so I'll press on with the board design as it is.

0 Kudos
Visitor rsabhilash
Visitor
374 Views
Registered: ‎06-15-2018

Re: Using TMDS for a point-to-point link

Jump to solution

I think you managed to implement this. I would like to know, for a point to point link between fpga, whether external pull up is mandatory or not.

0 Kudos