HDLC

Discussion in 'VHDL' started by Yosi, Dec 19, 2003.

  1. Yosi

    Yosi Guest

    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, Dec 19, 2003
    #1
    1. Advertising

  2. 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, Dec 19, 2003
    #2
    1. Advertising

  3. 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, Dec 22, 2003
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page