High speed differential to single ended

John_H schrieb:

[]

"pixel clock below 22.5MHz for a duration of 1s is to be considered IDLE (link down)"

this sounds like lower limit?

Antti

Peter Alfke schrieb:

Hi Peter,

I was about to reply to one of your earlier posts but it was nice weather and so I went to "English Garden" instead with children. But you have been busy responding in this thread :)

DVI clock requirement for PLL lock in receiver 25MHz up to supported max (165MHz), one "symbol" is 10 bits those we have bit rate of 250MB/s to 1.65MB/s per differential pair, the electrical levels are differential, DC coupled, with termination to 3.3V transmitter differential swing 500mV (400-600mv) the swing is "centered" half down from termination, so the single ended signal would swing from 3.3V down.

To my knowledge FPGA IO standards do not include and option that would support this signalling directly.

Input differential margin > 150mV , ok that is compatible to FPGA LVDS inputs if they work at around 3.3V DC levels then a 50ohm termination to 3.3V and FPGA LVDS input could work.

DVI clock is at 'symbol rate' those we need a PLL to lock at 10X the clock. Next thing is that we need per line clock lock to the data stream (a digital delay lock) and per line descew correction.

All of the above is just that much of trouble that it makes in not reasonable even to think about implementing the DVI in FPGA without using a proper DVI receiver or transmitter IC.

CH7301 has 12 bit DDR like data bus so it requires for FPGA communication

12 data (SDR or DDR) 1 (or 2) for pixeld clock (can be single ended or differential) 5 for control DE HSYNC VSYNC SDA - i2c for parameter setting SCL

the chip has internal register to adjust the clock edge in order to sample the data lines at correct phase relation.

the chip costs some 8 EUR, I dont have pricing on DVI receiver but I belive those prices also be in range of 10EUR. As an extra the CH7301 also includes Analog RGB DACs so you can uses either DVI or analog monitor!

I hope the above explains why I a said in my first posting in this thread: "NO WAY".

I agree that with some really clever tricks and some ommissions some DVI things could be done directly in the FPGA using FPGA I/O pins, but it really doesnt seem like reasonable thing todo. Unless someone has months and months of time he wishes to waste.

Antti

We have a *pixel clock* of 150MHz, so have to send a whole pixel, which thanks to the transmission encoding takes ten bits, on each of the three colour channels, every 6.7ns; that is, the channel frequency is 1500Mbps.

I don't know whether the 'TMDS Clock' differential pair on the DVI connector oscillates once per pixel or once per bit; my guess is once per pixel, with quite complicated clock-recovery circuitry at the other end of the link to recover the bit clock.

Tom

It's a rather odd encoding:

- write down bit1, bit1^bit2, bit2^bit3, bit3^bit4 ...

- also write down bit1, bit1^~bit2, bit2^~bit3, ...

- pick whichever of the above has fewest transitions, write it down followed by one bit to decide whether you did the per-bit inversion or not

- optionally, if a counter tracking DC balance suggests that you'd be better off with more or fewer set bits, invert all nine bits and append a one. Otherwise append a zero

And it's one differential-pair per colour.

Tom

Thomas Womack schrieb:

1 clock per 10-bit symbol. each of the 3 data lines need separate delay lock to the data stream and the 3 datastreams must be aligned after decoding to restore the pixel data as there may be large skew

Antti

If this is the case, then you can't use an LVDS receiver alone. You HAVE to have a DVI decoder / encoder, unless you want to design the synchronization circuitry (which I don't really have the time to do).

Is this statement correct? Are the 10 bits transmitted one at a time, at each clock cylce? or 10 bits all at once per clock cycle (elapsed inbetween the positive edges of the clock).

Thanks

The 10 bits are transmitted at 10x the serial rate. Antti pointed out the clock is delivered once per 10 bits of encoded color per channel with a dedicated twisted pair for each color.

If your display is not a small LCD panel, you need the dedicated converter.

Can anyone recommend a (possibly cheap?) DVI converter that can decode and encode?

Thanks

vans schrieb:

sure the 10 bits on each of the data lines are transmitted within 1 clock on the clock line.

and you must assume that the skew between the 3 data lines is unknown and may be more than 1 clock on clock line, ie you first need to find the good point to slice the data on each data line in clock domain 10x and then you need to symbol align to get get symbols that belong together to appera at same pixel clock as the skew may shift them into different pix clock phases.

Antti

vans schrieb:

transmitter CH7301C for receiver look at

Antti

What information is there in the pixel data on which you can align the bits? If I understand the 8->10 encoding scheme correctly, any stream of bits decodes to a valid sequence of bytes; is there some kind of synchronisation data sent during the periods when, on a CRT, the electron beam would be returning to line-starts or to the top of the screen?

I can see roughly how you would construct a clock at 10x the frequency of the clock presented, and align it using a variable-tap delay line so that its rising edges correspond to some convenient point in the middle of a symbol bit, but I don't see how you could ensure that it started at bit 0 of a symbol, and even less how you could lock to the first pixel of a scanline.

Tom

Thomas Womack schrieb:

May I suggest you read the DVI specification ?

Antti

Hi,

the CH7301C and all the DVI Tx/Rx chips from TI use high pin packages. There doesn't seem anything that has tube packaging that I can easily use on a breadboard (breadboard probably wouldn't work any way since there are such high speed signals).

I know this is a cumbersome question, but is there any place where I can get a DVI Tx / Rx PCB board? I have seen one on the internet, but it is very expensive. I don't want to go through all the trouble of fab'ing a board if there is already one available.

Thanks.

Agree with your reasoning, I rushed out a post and inevitably confused the situation :) Sorry.

Peter Alfke wrote: