Hello,

I use the 8B10BEncDec Cores to code and decode data for a DVB-ASI
interface (270mbps asynchronous serial interface used in digital video
broadcast). Basically the interface is used to send/receive a MPEG2
transport stream between DVB hardware (i.e. DVB-Satellite Receiver
Tuner decodes satellite signal, decoded MPEG2 TS is then handed over
to DVB-Terrestrial broadcast equipment and then send over the air).

The 8B10B Decoder works correctly, since I implemented a DVB-ASI
Sample-Unit which samples the 270mbps stream and decodes the 10Bit
coded 8Bit data. When I tried to recode the 8Bit data to 10Bit using
the 8B10B encoder I fail to lock to the stream using a second unit.
When I checked the reencoded data stream I noticed the following:

Each MPEG2 TS Packet has a 0x47 start byte which encodes to either
1110000101 or 0001110101 depending on the running disparity (sum of
ones and zeros). However, I ended up seeing 1110001010 or 0001111010
which leads me to the conclusion that the 3B4B subencoder is not
working as intended. It does work in some cases, i.e. I get correct
DVB-ASI fill characters (K28.7: 1100000101 or 0011111010). I compared
the VHDL source code with the 8B10B "specification" (there is no real
spec, it evolved out of a proposition of two IBM guys, back in the 80s
and became a quasi standard). I cannot find any disparity between VHDL
code and specification, however I am not sure whether wired OR (OR
dot, dotted OR, whatever the correct name is) always translates to an
OR, since in VHDL code it sometimes ends up as OR, on other occasions
as XOR. Also, in some places, latched input data bits (F4, G4, H4) in
the VHDL code substitute non latched data bits (according to spec,
i.e. F4 is used where spec would use F).

I tried to fiddle around replacing XOR with OR in cases where a wired
OR was transcripted into a XOR and also using F, G, H instead of their
latched versions F4, G4, H4 as depicted in the spec. To no use, since
I am asking for help here.

Quartus II optimizes away the S and PDL6 registers, which leads me to
the conclusion that there is a problem in the transcription of the
S-function and disparity calculation. PDL6 stores the running
disparity of the 5B6B subencoder.

I did find a Verilog coded 8B10B encoder but it lacked clocked inputs
and didnt work in my design. So has anyone encountered the same
problem and is able to point me into the right direction? Thank you,

JS

p.s.: even if the test bench proves the encoder to work, try encoding
one or more K28.7 special characters (K=1) followed by a standard
coded 0x47 (K=0).

Don't know if it's relevant, but Dvb-asi is easy to invert in the system, and it can't be. It's not a symmetrical code, so if you invert it by some chance you get this sort of error. Andrew -----Original Message----- From: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of krovax at krovax.de Sent: 06 September 2008 17:08 To: cores at opencores.org Subject: [oc] 8B10B Encoder Disparity Problem Hello, I use the 8B10BEncDec Cores to code and decode data for a DVB-ASI interface (270mbps asynchronous serial interface used in digital video broadcast). Basically the interface is used to send/receive a MPEG2 transport stream between DVB hardware (i.e. DVB-Satellite Receiver Tuner decodes satellite signal, decoded MPEG2 TS is then handed over to DVB-Terrestrial broadcast equipment and then send over the air). The 8B10B Decoder works correctly, since I implemented a DVB-ASI Sample-Unit which samples the 270mbps stream and decodes the 10Bit coded 8Bit data. When I tried to recode the 8Bit data to 10Bit using the 8B10B encoder I fail to lock to the stream using a second unit. When I checked the reencoded data stream I noticed the following: Each MPEG2 TS Packet has a 0x47 start byte which encodes to either 1110000101 or 0001110101 depending on the running disparity (sum of ones and zeros). However, I ended up seeing 1110001010 or 0001111010 which leads me to the conclusion that the 3B4B subencoder is not working as intended. It does work in some cases, i.e. I get correct DVB-ASI fill characters (K28.7: 1100000101 or 0011111010). I compared the VHDL source code with the 8B10B "specification" (there is no real spec, it evolved out of a proposition of two IBM guys, back in the 80s and became a quasi standard). I cannot find any disparity between VHDL code and specification, however I am not sure whether wired OR (OR dot, dotted OR, whatever the correct name is) always translates to an OR, since in VHDL code it sometimes ends up as OR, on other occasions as XOR. Also, in some places, latched input data bits (F4, G4, H4) in the VHDL code substitute non latched data bits (according to spec, i.e. F4 is used where spec would use F). I tried to fiddle around replacing XOR with OR in cases where a wired OR was transcripted into a XOR and also using F, G, H instead of their latched versions F4, G4, H4 as depicted in the spec. To no use, since I am asking for help here. Quartus II optimizes away the S and PDL6 registers, which leads me to the conclusion that there is a problem in the transcription of the S-function and disparity calculation. PDL6 stores the running disparity of the 5B6B subencoder. I did find a Verilog coded 8B10B encoder but it lacked clocked inputs and didnt work in my design. So has anyone encountered the same problem and is able to point me into the right direction? Thank you, JS p.s.: even if the test bench proves the encoder to work, try encoding one or more K28.7 special characters (K=1) followed by a standard coded 0x47 (K=0). _______________________________________________ http://www.opencores.org/mailman/listinfo/cores No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.16/1651 - Release Date: 04/09/2008 06:57