Encoding HDLC flags, FEC

[Silverlined]

In particular related to the AX5043 Deframer, line 23
How is the final state of '10001010111001101000101011100110' reached?

Would it be possible to elaborate on the encoding process of the synchronization sequence.
The inline comment suggests that two HDLC flags (i.e. 0x7E7E) are convolutionally coded (cc) with k=5, g0=25, g1=23 and interleaved (4x4 matrix).
However, the cc process includes 0 padding (k - 1) bits to the beginning of the original data in order to initialize the state of the encoder. The 1/2 rate encoder outputs 2x number of input bits. Therefore, encoding 0x7E7E (16 bits + (k-1) bits) will result in output of 40 bits.
40 is not divisible by 16 and interleaving cannot be performed, unless 8 bits are added/removed.

[daniestevez]

I'm speaking from memory based on what I remember from doing this 2 years ago, so maybe there are some errors in what I say.

The whole message (starting with the two HDLC flags but continuing with the rest of the payload) is convolutionally encoded and then interleaved with the 4x4 matrix. At the beginning of the packet, the encoder shift register is filled with zeros. We push in the 16 bits corresponding to 0x7E7E into the encoder and extract 32 bits out. At this point the state of the encoder shift register is the last 4 bits of 0x7E7E, sure, but we don't extract these bits out just yet. We pass the 32 bits out through the 4x4 interleaver. This is okay, because 32 bits is exactly 2 interleaver blocks. At this point we should obtain '10001010111001101000101011100110' . I haven't run the calculations manually to check if this is right.

So what happens is that these 32 bits are the first 32 bits of each packet. After this, the packet transmission continues by pushing in the payload bits into the encoder. At the end of the payload there is probably a tail to flush out the encoder and probably some padding to a 16-bit interleaver block. But all of this happens at the end of the whole packet. There is no convolutional encoder tail at the end of the syncword. Also note that only the first 32 bits that are transmitted are completely independent from the payload. The next bits already depend on the payload, because already the first payload bits have entered into the convolutional encoder.

So maybe the key remark here is that the concatenation of the syncword and payload is convolutionally encoded as a whole, rather than as two separate things.

[Silverlined]

Thank you for the answer, Daniel!

I will continue the thread as there seems to be some additional step in order to obtain the final syncword representation.
Something that captures attention is the comment at AX5043 Deframer, line 52 which suggest that the output of the first branch of the encoder is inverted. It is not particularly clear to me how this is so based on the datasheet FEC schematic which includes only XOR gates.
On another note, AND9309/D FEC mentions the following:
"whenever two or more sequential (back−to−back) HDLC flags enter the FEC encoder, it aligns the second and all following flags to the interleaver by inserting up to 7 zeros." which raises ambiguity in interpretation.
Do you recall performing any other operation during encoding?

[Silverlined]

input:
[0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 0]

encoded (first 32 bits):
cc(k=5, polynomials=[25, 23])
[0 0 1 1 1 0 1 1 0 1 1 0 1 0 0 1 0 0 1 0 0 1 1 1 0 1 1 0 1 0 0 1]

4x4 interleaved:
[0 1 0 1 0 0 1 0 1 1 1 0 1 1 0 1 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 1]

@daniestevez any thoughts on this? It is quite different to the suggested 10001010111001101000101011100110

[Silverlined]

In case anyone else comes across this, the AX5043 FEC can be emulated by the following operations.

Encoding (HDLC frame):

• Shift by 1 to the right (insert 0 bit in front)
• Add convolutional coding (k=5, poly=[25,23])
• Add zero padding % 16 == 0
• XOR every other bit (because the g0 branch of the CC is inverted)
• Interleave in a 4x4 matrix

Decoding (HDLC frame):

• Deinterleave
• XOR every other bit
• Viterbi decode (k=5, poly=[25,23])