HDLC 7E detection in 64-bit qword format - Design logic confusion

[xtcx]

Hi, I'm working, well worked on HDLC bit level design and was able to validate it. Now working with HDLC Byte level and am able to validate it properly as well. Now the problem here is that input now on comes as 64-bit Qword format from FIFO instead of byte. In HDLC, the 7E (octet) is the start\end of frame. Based on this position of 7E, I need to slice the input 64-bit data as per the byte position. Here the complexity is that I need to read 64-bit qword every clock and the worst thing is that the 7E position will change it's position to any byte lane (from 1 to 8) in the next frame. When the byte lane changes in the next frame my byte encoder changes and I'm missing some bytes in slicing process.

For eg, assume these train of Qwords containing two frame data

007E03FF01020304-05060708090A0B0C-0D0E0F10117E03FF-0102030405060708-.......

Slice it like this, Now I need to reslice (for every time I detect 7E, slice value is not constant) as this way

007E[B][COLOR="#FF0000"]03FF01020304-05060708090A0B0C-0D0E0F1011[/COLOR][/B]7E[B][COLOR="#FF0000"]03FF-0102030405060708[/COLOR][/COLOR][/B]-.......

IT should be packed to this way

03FF010203040506-0708090A0B0C0D0E-0F1011xxxxxxxxx-03FF010203040506-0708........

x- don't care

I tried logic like byte encoder which finds the lane of 7E and uses that value to slice the Qwords accordingly by putting into curr\prev format. However doing so, I'm missing some bytes whenever the 7E position changes to another, even if I try to slice that residual bytes sometimes the position of 7E gives no residual bytes. Couldn't predict a working logic or maybe a different approach. Post this I need to apply byte de-stuffing which removes dome unwanted characters and once again will reshape the 64-bit word.

Hope some of you can throw some light. Don't expect code in VHDL/VERILOG but all I need is a logic or suggestion. Delaying input by 1 clock for each frame is allowed and does not affect global timing.

Thanks.

 

[FvM]

Obviously the byte encoder must run at eightfold qword rate. So one would expect a specification about clock rates as first step to design.

 

[xtcx]

Obviously the byte encoder must run at eightfold qword rate. So one would expect a specification about clock rates as first step to design.

The design runs @ 200MHz, and for every clock I'll be getting 64-bit input qword. I can nowhere run it eight times faster. It could've been true with a byte by byte read, as it worked for STM-1, but I need to do Qword by Qword as this is for STM-64. Also note, can't run multiple instance (say 8) as there are some limitations.

Consider STM-64, where I get 64 x C4 payloads (MAx) with each worth of 2430 bytes in every 125us timeslot. Now I need to process all these 2430 bytes within 125us (Sample time).

So 64 x 2430b = 155,520 bytes = 19440 Qwords (within 125us)

I will have to continuously read this 19440 Qwords from a Fifo (whose input will be written by the deframer). Hence
19440 reads using 200MHz = ~97 us (which is within 125us)

Now, coming to the issue, I almost need to read input for every clock for all 64 C4 payloads. However 27us or 5400 (125-97)clock cycles can be used in between processing. I hope I conveyed.


This is targeted for Altera Stractix 5 FPGA and of course have tons of other modules to sum up.

 

[FvM]

O.K., 200 MHz qword rate and no byte interface. But then you have to define the output interface in a reasonable way.

The specification with xxxx don't care output can't work this way, at least for two reasons:
- it produces more output then input
- it misses a frame start/frame end signal.

You should first define an ouput interface according to your application requirements.

 

[xtcx]

Thanks, as said it produces more output than input, at least once in every frame. But that can be afforded, say I shall de-assert the FIFO rden to hold the input from being read for one clock and can spare the same to write this remaining bytes. So in such case it doesn't miss the next frame because I'm delaying the input by one clock to compensate the 'extra' output qword.

Now, I said it could be(1 clock for 1 frame) afforded because in a typical C4 (2430 bytes), one can expect the IP packet to have a minimum size of say 64bytes (Assuming TCP) and hence it can have about 37 frames and in my case the STM-64 VC4 can have about 64 C4 which translates to 38*64 = ~2400 clocks which is still less than my 5400 cycles (as calc above). So I'm still ahead of the timing. Now can you suggest a possible logic to perform slicing including the residual bytes?, I'm struggling a bit over here for days.

Thanks.

 

[std_match]

From your calculations I understand that you have enough slack to waste one clock cycle for words containing a 7E byte.

A possible solution is then to clock the 64-word containing the 7E byte twice into the byte-shifting logic.
The first word will be shifted according to the previous words to get the last bytes in the correct position.
The second word (the copy) can then use a new setting for the byte-shifting logic.

 

[xtcx]

From your calculations I understand that you have enough slack to waste one clock cycle for words containing a 7E byte.

A possible solution is then to clock the 64-word containing the 7E byte twice into the byte-shifting logic.
The first word will be shifted according to the previous words to get the last bytes in the correct position.
The second word (the copy) can then use a new setting for the byte-shifting logic.

Thanks, I have tried that already. However some residue bytes (when slicing off) comes into picture (when 7E byte comes in qword) and that keeps changing every time. That's my problem.

 

[ads-ee]

Your whole residue bytes problem needs clarification.

Specifically, what is the problem with the bytes you output when the error occurs and what should they be? How about giving an example of the problem using your original example, but instead show the output result that your circuit with error produces.

Seems to me that std_match's suggestion would work fine if the logic is designed correctly.

Using you previous example data.

recieve this:
007E03FF01020304-05060708090A0B0C-0D0E0F10117E03FF-0102030405060708

output this:
03FF010203040506-0708090A0B0C0D0E-0F1011xxxxxxxxxx-03FF010203040506-0708

This is assuming at some point there are times where there is no data frame inputs so the output can "catch up"

Data needs to be put into a pipeline of some sort to allow access to 128-bits (2 qwords)

clk 1:
xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx

clk 2:
xxxxxxxxxxxxxxxx 007E03FF01020304

clk 3: (7E detected: 2 byte shift)       |- output qwords -|
007E03FF01020304 05060708090A0B0C => 007E|03FF01020304 0506|0708090A
clk 4:                                   |                 |
05060708090A0B0C 0D0E0F10117E03FF => 0506|0708090A0B0C 0D0E|0F10117E03FF
clk 5:                                   |                 |
0D0E0F10117E03FF 0102030405060708 => 0D0E|0F10117E03FF 0102|030405060708
                                     0D0E|0F1011xxxxxx xxxx|030405060708

clk 6: (no qword pipeline shift, new 7E detected: 6-byte shift)
0D0E0F10117E03FF 0102030405060708 => 0D0E0F10117E|03FF 010203040506|0708
clk 7:                                           |                 |
0102030405060708 ???????????????? => 010203040506|0708 ????????????|????

Seems like a straight forward design to me. I've done similar things with parsing packet headers and realigning the payload data.

 

[pbernardi]

Is there any specific reason that you store the data first, look for 7E, and then reorganize?

Better would be every time you receive a 7E, you store the next bytes, then you would avoid many logic problems. Perhaps you are doing HDLC over IP, and then this is not possible?

 

[ads-ee]

Is there any specific reason that you store the data first, look for 7E, and then reorganize?

Better would be every time you receive a 7E, you store the next bytes, then you would avoid many logic problems. Perhaps you are doing HDLC over IP, and then this is not possible?

The OP already stated the data arrives as 64-bit qwords not as bytes.

 

[xtcx]

Your whole residue bytes problem needs clarification.

Specifically, what is the problem with the bytes you output when the error occurs and what should they be? How about giving an example of the problem using your original example, but instead show the output result that your circuit with error produces.

Seems to me that std_match's suggestion would work fine if the logic is designed correctly.

Using you previous example data.

recieve this:
007E03FF01020304-05060708090A0B0C-0D0E0F10117E03FF-0102030405060708

output this:
03FF010203040506-0708090A0B0C0D0E-0F1011xxxxxxxxxx-03FF010203040506-0708

This is assuming at some point there are times where there is no data frame inputs so the output can "catch up"

Data needs to be put into a pipeline of some sort to allow access to 128-bits (2 qwords)

clk 1:
xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx

clk 2:
xxxxxxxxxxxxxxxx 007E03FF01020304

clk 3: (7E detected: 2 byte shift)       |- output qwords -|
007E03FF01020304 05060708090A0B0C => 007E|03FF01020304 0506|0708090A
clk 4:                                   |                 |
05060708090A0B0C 0D0E0F10117E03FF => 0506|0708090A0B0C 0D0E|0F10117E03FF
clk 5:                                   |                 |
0D0E0F10117E03FF 0102030405060708 => 0D0E|0F10117E03FF 0102|030405060708
                                     0D0E|0F1011xxxxxx xxxx|030405060708

clk 6: (no qword pipeline shift, new 7E detected: 6-byte shift)
0D0E0F10117E03FF 0102030405060708 => 0D0E0F10117E|03FF 010203040506|0708
clk 7:                                           |                 |
0102030405060708 ???????????????? => 010203040506|0708 ????????????|????

Seems like a straight forward design to me. I've done similar things with parsing packet headers and realigning the payload data.

Thanks a lot. I'm working on this. I'd been trying with a 64-bit shifter instead of 128-bit previously.