We have three
8b/10b encoders, one per color channel.
The purpose of the encoders is to achieve DC balance and to provide enough state changes to allow clock recovery in the decoders inside the monitor.
//Gigabit Ethernet and USB3.0 also use 8b/10b encoding.
And now, I wanted to know.
When trying to translate the VHDL of Mike Field's 8b/10b encoder, I'm getting something like this (you better check for errors):
Attachment:
dvi1.png [ 383.45 KiB | Viewed 1202 times ]
Attachment:
dvi2.png [ 419.3 KiB | Viewed 1202 times ]
//Don't get confused: for the intermediade results, I had tried to stick with the DVI specification somehow.
D0..7 is a Byte which sets the color for one channel.
DE is display enable, if DE is LOW we are not in the visible part of the picture.
If DE is LOW, C0 and C1 of the blue channel seem to be the horizontal\vertical sync signals.
For DVI, C0 and C1 for the other two color channels are supposed to be LOW. //For HDMI, it's different.
Q0..9 is the encoder output which feeds the data inputs of a fast 10 Bit shift register.
The adder boxes labeled "HA" are half adders, basically an XOR gate and a AND gate,
sort of a habit when adding partial sums in a multiplier or such...
;---
Of course, my block diagram above never would be able to run at dot clock speed.
One needs to break it into, let's say, a 5 level pipeline and to replace the 7485 comparator and the 74283 adders with something that's much faster.
Serial upstream would be 10 times faster than the dot clock, and at a reasonable dot clock IMHO TTL would be too slow,
this asks for OnSemi PECL shift registers. Microchip\Micrel has neat level translators.
Physically, what goes through the DVI\HDMI cable seems to be CML, Microchip\Micrel has neat CML drivers and flipflops, too.
But IMHO the timing skew between the four channels after the encoders (three color chanels and a dot clock channel) would be critical.
Bad thing is: the block diagram only is one channel, so building a non_proprietary DVI encoder would take a lot of chips.
I would estimate it might take at least half a year to build something like that,
and maybe more than 200€ of material cost... if it works at first try, and it usually doesn't.
//DVI encoder chip might cost just 5€ or such.
Of course, one could be cheating and use fast SRAM (preferably sychronous RAM) as a
lookup table (LUT) for replacing that lump of TTL chips,
but then one needs to initialize the lookup table in the RAM from a ROM at power up.
Attachment:
dvi_3.png [ 114.64 KiB | Viewed 1202 times ]
I'm happy I got that stuff off my desk, now to let this thread alone for a while.