HDLC

Does anyone know if there is a parallel implementation algorithm for
HDLC protocol? I know it is a serial protocol, however, if one wants
to deply it for a higher speed application, several hundred Mbps, it
would be nice to have a parallel implentation.

Thanks,
Yosi.

Yosi

Yosi wrote:
> Does anyone know if there is a parallel implementation algorithm for
> HDLC protocol? I know it is a serial protocol, however, if one wants
> to deply it for a higher speed application, several hundred Mbps, it
> would be nice to have a parallel implentation.

You can modify any logically serial process
for parallel data just by looping through
the procedure n times per
clock instead of just once.

Just because you have to check bit
boundaries for flag and and stuff sequences
doesn't mean that you are limited to
handling just one bit per clock.

This is analogous to the problem,
often discussed here,
of calculating an frame check value
for parallel instead of serial data.

-- Mike Treseler

Mike Treseler

On 19 Dec 2003 13:46:15 -0800, (Yosi) wrote:

>Does anyone know if there is a parallel implementation algorithm for
>HDLC protocol? I know it is a serial protocol, however, if one wants
>to deply it for a higher speed application, several hundred Mbps, it
>would be nice to have a parallel implentation.

As Mike said, this is possible and done frequently. I worked on a
10Gbps HDLC encoder in Virtex-E back in 2000. The entire design cycle
took six weeks (from saying "guys, we need an HDLC encoder" to the
completion of testing in the lab).
I know people who have designed HDLC encoders and decoders to work at
40Gpbs in Virtex-2.

Note that high speed HDLC uses byte stuffing rather than bit stuffing.
See ISO 3309 for details. See also RFC 2615 (which refers to RFC
1662).
http://www.apps.ietf.org/rfc/rfc1662.html

The biggest problem is dealing with the increase in bus width due to
stuffing. In the worst case (perhaps due to a denial of service
attack!) every byte will be stuffed and the amount of data per clock
doubles. I used a 128 bit bus (160MHz clock) in my 10Gbps design; I
think the 40Gbps design used a 512 bit bus (200MHz ? clock).

Note that your egress pipe can usually only handle a fixed data rate,
so the variable increase in bandwidth caused by stuffing implies that
you need to be able to throttle your data source.

The next biggest problem only happens if you are trying to achieve the
maximum possible packet rate. This requires that only a single flag
byte appear between packets, which means that the next packet must
start with a rotation which is determined by the amount of stuffing in
the current packet. Signals flow up and down the pipeline! Joy!
Still, most designs seem to work first time (it helps if you have a
good test bench that has lots of packets with different sizes,
stuffing and interpacket gaps).

Another gotcha: most HDLC applications seem to transmit bytes MSB
first. Ethernet does it the other way (just to be different). This
has implications for your CRC calculations, since CRCs are always
defined in terms of bit order on the line. The 32 bit HDLC polynomial
may be the same as the Ethernet one, but that doesn't mean that you
can necessarily reuse a parallel implementation code without some
thought.

Regards,
Allan.

Allan Herriman