Re: 66B mode of VirtexII-ProX Rocket I/O

Hi Magnus,

strange application but anyhow:

I guess, when I look at ieee802.3ae appendix 44a figure 44a-1 the "sync header bits" were prepended every 64 scrambled bits, by the way a great way to synchronize via barrel shifter.

I think if you don´t want that behavior search for a switch in the xilinx manual to switch of sync header generation, or scramble by yourself. (Do you only rely on the balancing character of the scrambler polynom?)

kind regards, thomas

"Magnus Daniels> >

> The 8B/10B (or any other xB/yB) encoding is there so that you transmit

an

> equal number of ones and zeros. This keeps the transceivers from

saturating

> one way or the other. > > Almost true. For the 8B/10B encoding it is certainly true, with its > running disparity you ensure the DC balance i.e. equal balance between > 0s and 1s. In SDH/SONET you use scrambling with a PRBS to acheive DC > balance (an approximation) and in the 64B/66B (10GE) you also use > scrambling, but only for 64 bits while the other two bits (sync) is set > in a separate encoder/decoder block. It is this block which I want to > bypass since it creates an obstacle for my application. I can't use the > sync bits arbitrarilly, they must DC balance on their own (in 10GE they > are either 01 or 10). > > So, I still need to know where these bits show up on my Rocket I/O. > > Cheers, > Magnus - who defeated the SDH/SONET scrambler with a customized ping!
Reply to
T. Irmen
Loading thread data ...

Hi Magnus,

strange application but anyhow:

I guess, when I look at ieee802.3ae appendix 44a figure 44a-1 the "sync header bits" were prepended every 64 scrambled bits, by the way a great way to synchronize via barrel shifter.

I think if you don´t want that behavior search for a switch in the xilinx manual to switch of sync header generation, or scramble by yourself. (Do you only rely on the balancing character of the scrambler polynom?)

kind regards, thomas

Reply to
T. Irmen

Magnus,

I'm not sure about the 64B/66B encoder, but in 8B/10B mode, the extra bits are sent/received on TX/RXCHARDISPMODE and TX/RXCHARDISPVAL

The following app note outlines the connections

formatting link

I'd assume that the 64B/66B mode is similar.

Cheers, Meng

formatting link

Reply to
Meng Soo

Hi Thomas,

Exactly. In IEEE 802.3 (802.3ae is now included in the 802.3 document)

10GBASE-X the 64 data bits is scrambled and the 2 sync bits are not.

However, the sync bits are DC balanced by the "64B66B" encoder (quotes is there not to confuse it with a real line encoder like 4B/5B or

8B/10B, it's really just an encoder of various "messages") as indicated by Figure 49-7 where sync bits 01 means data and 10 means control block, so that is really just a one bit transmission channel using two symbols per transmitted bit (1B/2B). So, those block codes may or may not be usefull, and when doing a non-10GBASE-X application using that hardware, it may be a design-choice not to use the 64B/66B encoder since it does not really do much for the actual line encoding (DC-balance, rate of transitions) except for the two sync-bits in every 66 symbol period.

I can acheive the goals of a line encoding (DC-balance, rate of transitions, alignment) without the 64B/66B encoder/decoder block as long as I ensure the DC balance of the sync bits. Using one as the direct transmission channel and the other just being the inverted version of that channel, I have acheived the same 1B/2B encoding style on which alignment depends as well as the DC-balancing.

Not really. It uses much more overhead than needed, but for an application like 10GE I guess it's OK.

The full 64B/66B encoding path of 10GBASE-X only depends on the scrambling for the data bits for balancing. It's just like in SDH/SONET, but with a sufficiently long self-synchronous scrambler. I'm not really depending on stuff much differently than in 10GBASE-X, I'm just considering using it differently to fit my needs.

Cheers, Magnus

Reply to
Magnus Danielson

Hi Meng,

Yes, I am aware of that. But it would be an assumption made by me, and I wanted to make sure that my assumption was going to be validated since the UG didn't give that detail. Since I asked, the UG35 has come out in V1.3, which does state that TXCHARDISPVAL[0] and TXCHARDISPMODE[0] receives the sync bits [0] and [1] respectively, but the receiver side is however still unclear, but it should probably be safe to assume the same mapping for the RX side.

Yes, assume is the word. Too many assumptions and I have a hell of a debugging to do. Better nail it down early.

Cheers, Magnus

Reply to
Magnus Danielson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.