Implementation of the 66b codec

Author: https://github.com/iwaniwaniwan012

Introduction

For stable operation, data transfer protocols use codecs selected by developers taking into account the following requirements:

• uniform distribution of 0 and 1 in the channel

• ease of encoding/decoding

• have little redundancy

One of the most common protocols that I think about, if not every person, then every engineer has definitely heard of, is Ethernet, which has a large number of standards. It also uses a codec, namely 66b/64b, which is widely known in engineering circles. Here is a small list of popular protocols that use this codec:

General description of the 66b/64b codec

The encoding scheme consists of adding 2 bits before 64 bits of data according to the following scheme:

• if 64 bits constitute only the “payload” data, then the value of 2 bits is b’01

• if 64 bits contain data and service information or only service information, then the value of 2 bits is b’10 and the value of the 1st byte contains information about what type of service information is contained and its quantity

The values ​​b’00 and b’11 for these two service bits are not used and will be perceived as an error on the receiving side.

Further, for uniform distribution of 0 and 1 in the channel, the received data is scrambled in accordance with the polynomial and are transmitted to the communication channel.

The decoding scheme has the reverse procedure, except that at the very beginning a synchronizer is needed, since in the communication channel the receiver does not necessarily, after processing, transmit us data aligned to 2 service bits at the beginning.

Modules required for implementation

Receiver:

Transmitter:

• Encoder

• Scrambler

To check the modules, we also need TestBench to check the correctness of the developed modules.

A small digression:

Those who have experience working with high-speed FPGA interfaces from Xilinx or Altera/Intel can say that all this can be included in IP cores and will of course be right, but sometimes there are cases when such capabilities are not available and then the developed modules will come in handy. especially given the current situation…

Also, due to the peculiarities of IP cores that implement only Physical Media Access, which can work with buses of a maximum of 64 bits, it was decided to additionally implement converter modules from 64 bits to 66 bits and vice versa.

The final scheme of our entire project is as follows:

Module operation algorithm

Converters

They are a shift register, which, depending on the current content, produces shifted data.

Simply put, a shift register and a multiplexer.

Synchronizer

The synchronization algorithm is as follows:

• The search for synchronization is carried out by combining two buses, which represent data received at the previous clock cycle and at the current clock cycle.

• If the first 2 bits take the value only 2’b10 or 2’b01 within 128 clock cycles, then synchronization is achieved, if not, and these two bits take on reserved values, then after 128 clock cycles the synchronization search offset is shifted by 1 bit.

• If in the synchronization state 64 errors occur in 1024 clock cycles, then the synchronization is reset and the transition to a synchronization search occurs.

Description of module input/output pins:

port (
        Clk 		: in std_logic;				--Тактовый сигнал
        Reset 		: in std_logic;				--Сброс
        En_In		: in std_logic;				--входной разрешающий сигнал
        Data_In		: in std_logic_vector(65 downto 0);	--входные данные
        Syn_Out		: out std_logic;			--статус синхронизации
        En_Out		: out std_logic;			--выходной разрешающий выходной сигнал
        Data_H_Out	: out std_logic_vector(1 downto 0); 	--два служебных бита
        Data_Out	: out std_logic_vector(63 downto 0)	--данные
    );

Scrambler/Descrambler

It is a shift register with a 58-bit bus, the least significant bit of which is the next bit of input data. And the output data of scrambling/descrambling is the result of XOR of 58 and 39 bits of the shift register, as well as each input data bit, from least significant to highest.

A description of the algorithm in VHDL is presented below:

if En_In = '1' then
    for i in 0 to 63 loop
        	XorBit 		:= Data_In(i) xor ScrReg(38) xor ScrReg(57);
                ScrReg 		:= ScrReg(56 downto 0) & Data_In(i);
                DataReg(i) 	:= XorBit; 
    end loop;
        En_Out 		<= '1';
        Data_H_Out 	<= Data_H_In;
        Data_Out 	<= DataReg;
else
    En_Out <= '0';
end if;

Testing in a simulation environment

TestBench for the simulation environment is essentially a data generator (serial counter), and on the receiving side it checks that the current data is the value of the previous data -1. Also on the receiving side, for visual verification, if the previous condition is met, then the Data_Test_Ok signal takes the value 1’b1, otherwise 1’b0.

Required FPGA resources and maximum frequency

When developing various FPGA modules, before using them in a real project, we use a test project with the internal name TestFreq, where we use the input pins of the modules as virtual pins, thereby checking how much FPGA resources will be used, as well as at what maximum frequency it will be able to work, and in most cases the second is more important.

We decided to carry out the same measurements for our developed modules (Intel/Altera FPGAs). The results are presented in the table below:

Bottom line

As a result, we were able to implement a 66b/64b codec, which can be used for various projects where there are no ready-made solutions or for some reason we cannot use them.

Link to source codes, including TestBench and description – 66b/64b codec in VHDL

Thank you for your attention!

PS Comments and suggestions are extremely welcome =)