Re: [oc] HDLC controller

[Allan Herriman <allan_herriman.hates.spam@agilent.com>]

Hi,

Jamil Khatib wrote:
> 
> Here are my HDLC feature list
> Please let me know if I should add extra
> 
> HDLC controller initial features:
> 1. 8 bit parallel backend interface
> 2. use external RX and TX clocks
> 3. Start and end of frame pattern generation
> 4. Start and end of frame pattern checking
> 5. Idle pattern generation and detection (all ones)
> 5. a)  Idle pattern is assumed only after the end of a
> frame which is signaled by an abort signal
> 6. Zero insertion
> 7. Abort pattern generation and checking
> 8. Address insertion and detection by software or
> external matching circuit
> 9. CRC generation and checking (Optional, external
> since either crc-16 or crc-32 can be use)
> 10. FIFO buffers and synchronization (External)
> 11. Byte aligned data (if data is not aligned to
> 8-bits extra random bits are inserted)
> 12. Q.921 compliant(???)

If you are just aiming at low speed comms applications, then it's
probably best to make it compatible with a commonly used device such as
the 85C30.

The data sheet (in pdf) is here:
http://www.zilog.com/pdfs/serial/scc_escc_iscc_manual/

Your points 11 and 12 aren't compatible.  Q.921 demands that frames that
aren't octet aligned be thrown away, whereas ISO 3309 HDLC allows these
frames to be received.  They should be padded to an octet boundary in
the receiver (as you suggested).  It is very important that the *number*
of bits in the last octet received be available in a register for
software to read.
I suggest that Q.921 *isn't* the standard you should follow, unless you
really want to connect to an ISDN D channel.

I'm not sure what you mean by your point 5a.  After the receiver has
seen an abort pattern, it should wait until seeing a flag pattern to
receive the next packet.

Regarding point 7, abort sequences on Tx are usually generated whenever
the Tx FIFO underflows.  Some users also want to be able to generate an
abort pattern by issuing a command to a register.

It is also very handy to be able to generated invalid FCS (CRC)
sequences.  This may be achieved by inverting the CRC output.  (Forcing
a particular pattern isn't good enough.  Inverting a number of bits is
the only reliable way.)

Regarding point 9, It will be simpler to just build the appropriate FCS
into the core, so that it can access the data when it's already serial.

I've found including frame count and error count registers very helpful
in debugging.  (More for debugging the end application than the core -
i.e. it's a user feature not a BIST feature.)

Regards,
Allan.