Electronic – SDLC Frame Check Sequence details

deserialiserprotocolserial

In the Synchronous Data Link Control (SDLC) protocol, the frame contains a "frame-check-sequence" (a CRC). The protocol contains a number of other implementation details, such as NRZI encoding, and zero-bit insertion when the data contains too many contiguous 1's (so the data is not mistaken for the end-frame flag).

Three people seem to have three different interpretations on how to implement this FCS algorithm, based on the documentation not being explicit:

  • One engineer says you must decode the NRZI encoding and discard the inserted-zero bits, and then the remaining bits will be pushed through a FCS algorithm.
  • Another engineer says you must decode the NRZI encoding, but keep the zero-inserted bits when pumping data into the FCS algorithm.
  • Another engineer says the FCS algorithm just inserts the raw data bits, not decoded and still containing inserted zero bits.

Could someone clarify which scenario is correct (or if none of them are, what is the correct sequence)? Or, if someone has an example waveform (raw logic levels as seen on the physical medium), that would help.

Best Answer

Could someone clarify which scenario is correct

It's the first one you listed:

One engineer says you must decode the NRZI encoding and discard the inserted-zero bits, and then the remaining bits will be pushed through a FCS algorithm.

Sequence of events

The SDLC FCS is calculated at the transmitter on the raw contents of the Address, Control & Information fields, before bit-stuffing and NRZI encoding (*) is done. The bit-stuffing and NRZI encoding is done "just before" transmission, after the FCS has been calculated.

At the receiver, the NRZI encoding and bit-stuffing are reversed first. Then the frames (consisting of the Address, Control and Information fields, and the transmitted FCS) are fed into the FCS checker. That means that the FCS checker (which is later in the processing pipeline) can't even get access to the datastream with the bit-stuffing still in it! That is why the other options you were given cannot be correct.

Confirmation

For confirmation, here is a block diagram of the receive path from the Zilog Z80C30/Z85C30 SCC (Serial Communications Controller) which implements SDLC:

Zilog Z80C30/Z85C30 SCC Receive Data Path

Image source: Zilog Z80C30/Z85C30 SCC (Serial Communications Controller) datasheet

From the RXD input in the bottom-left, you can see that the sequence of processing is NRZI Decode, then Zero Delete (i.e. remove bit-stuffing), and only then, into CRC Checker (i.e. the FCS checker).

Summary

As I explained above, the receiver's FCS checker does not, and cannot, operate on the received bits which are still NRZI encoded or have bit-stuffing - those have already been reversed, before the frames go to the FCS checker. That is why only the one choice which I quoted above from your question, is correct.

(As kindly commented by Peter Smith, the old IBM manual "SDLC Concepts" is available online.)

(*) I have written the text above, assuming that NRZI encoding is being used. Although all the IBM SNA systems which I worked on used NRZI encoding (as far as I can remember - it was a long time ago!), I believe that there can be other encoding types, as long as both ends of a link use the same encoding, of course.

Related Topic