8b10b - Am I doing it right?

[LoveLaika]

I'm working on making an 8b/10b encoder on an FPGA. At first, I followed the general tables along with a guide to build each module step by step (this is NOT for an assignment, but being unfamiliar with it, I tried to search how to do it online which led me to the guide), but I ran into an issue with testing.

I was testing my running disparity finite-state machine using all possible 10-bit test values as found in the guide's encoding table PDFs, but I noticed that the 10-bit values were way off than what I thought. For example, given D0.0, I assumed the 10-bit value would be "100111_1011" assuming an RD of -1, but the actual value was "100111_0100". That 3b/4b encoding confused me. I did some research, and all other resources showed the same value. Something was off. So, out of desperation, I looked at the IEEE 802.3 Standards and found out about how to calculate running disparity:

Running disparity for a code-group is calculated on the basis of sub-blocks, where the first six bits (abcdei) form one sub-block (six-bit sub-block) and the second four bits (fghj) form the other sub-block (four-bit subblock).
Running disparity at the beginning of the six-bit sub-block is the running disparity at the end of the last code-group.
Running disparity at the beginning of the four-bit sub-block is the running disparity at the end of the six-bit sub-block.
Running disparity at the end of the code-group is the running disparity at the end of the four-bit sub-block.

That in bold is the key. FGHJ is dependent on what you choose for ABCDEI. That was never mentioned at all on Wikipedia or the guide (unless I totally missed it). In light of this, given the attached picture, I was wondering if my assumption was correct? I drew up a little picture showing what I assumed (incorrectly) and what I think is the correct assumption. Is my assumed assumption correct in the bottom of the picture? Admittedly, it feels kind of odd, how the next RD for the next 8-bit data is dependent on the last 4-bits previous 10-bit word. You don't use the full 10-bit word to calculate the next RD? This will definitely change some things around in my VHDL code.

[ejeffrey]

Yes, the running disparity is recalculated after each sub-block, and then affects the choice of the next sub-block. I don't know that this is spelled out 100% clearly, but examining the behavior it is clear that is how it has to work.  In your example, D0.0 encoding to 100111_1011 would have a net disparity of +4, so if you started at -1 you would end up at +3.  This violates the rule that the RD must always be +/-1.  Instead, the second code word needs to be the negative disparity alternate that restores the RD to -1.

[LoveLaika]

Thanks for the reply. Yeah, Wikipedia (as well as other pages) doesn't explain this concept real well. It took me a while, but I see the idea now.

If I may ask another question, it's related to what IEEE said at the end of the code word, where the resulting 4-bit Code Block's running disparity becomes the running disparity at the end of the code group (which feeds back to being the RD of the 5b6b-block).

One design I'm also referencing is this PDF from Lattice, and it showcases a finite-state machine. The same goes with my guide that I posted at the beginning, where part 2 involves coding the FSM.

By following the Disparity Table, if the resulting disparity table for the 4-bit block is either -1 or +1 (depending on whether the # of bits is 0 or +2/-2 and the RD from the 6-bit block), how does the FSM function? If the calculated RD is the same as the current RD, it stays the same; otherwise, it changes? From the table, it kind of feels like it will never be disparity neutral.

[TC]

Another design resource / reference...

http://asics.chuckbenz.com/   look for the 8b10b link on that page.

Chuck's code includes comprehensive tests.

I've used Chuck's, Lattice's, and rolled my own from the 8b10b patent... but that was a long time ago.

If I can find my implementation I will post it as it contains a thorough explanation of the code based on the 8b10b patent. That's the approach I used to develop the code. The design was tested in an FPGA and used in a design. However, I think it is unlikely that I still have the code... the PC it was developed on had an ugly death.

[LoveLaika]

Thanks a lot for your reply. Sorry for not responding sooner.

This link for Chuck's 8b10b is really helpful for testing my encoder and decoder. His testbench gives me a great starting point, but what I don't like about it is that it's coded in Verilog, and the very few comments doesn't explain how he's going about his testing process. It's a major pain trying to decode what he's doing and modify them to my own code.

I mean, some parts I get, but others I don't get, especially his testing for all possible 10-bit sequences. It's very confusing to understand how he maps signals and compares them to his decoder.