[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] HDLC controller
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(???)
> >
>
> I'll check the extra features and add them to my core.
>
> > 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.
>
> Is it OK if I just signal an error messageto the
> software?
>
> > I suggest that Q.921 *isn't* the standard you should
> > follow, unless you
> > really want to connect to an ISDN D channel.
> >
>
> I want to design Basic HDLC controller that can be
> widely used (I think ISDN is a good choice or am I
> wrong?)
Q.921 is a subset of HDLC, in that Q.921 supports messages
that are a multiple of 8 bits in length, whereas HDLC
allows any length.
A Q.921 controller will flag an error when it receives a
frame that isn't a multiple of 8 bits long, whereas
an HDLC controller will receive an extra byte, and
present the number of bits in that last byte
in a register somewhere, so that software
can determine the actual length.
Most applications or protocols don't need to be able to set the
length of the message to the exact bit. I don't think
that you would lose much by not supporting it, but
it *would not be HDLC*.
If you want to call your core an HDLC controller, then
you need to be compatible with other HDLC controllers
out there, which means actually attempting to follow
the HDLC standard.
OTOH, if you want to make a Q.921 core, then go ahead
and follow the Q.921 standard.
A lot of HDLC controllers out there have the ability
to receive arbitrary length frames, but can only send
even length frames. (The Motorola 68360 and MPC860 come
to mind.) Perhaps this is a good solution.
But, considering the extra complexity of the full
HDLC design, I would suggest that you only implement Q.921,
and leave the hooks for later modification if there's
demand (which is unlikely).
> > 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.
> >
> I mean upone getting an Idle pattern I signal abort to
> the backend interface which means end of frame and
> abort.
Do you mean that upon receiving an abort pattern you
signal abort to the backend interface?
An idle pattern could be either flags or aborts (all ones).
The tx should be able to be configured to send either when idle.
Q.921 demands that the interframe fill be flags.
Multidrop applications may demand that the interframe fill be
aborts.
The receiver should handle either without flagging errors.
> > 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.)
> >
>
> sorry but I did not get your point
The users may want to be able to force CRC errors for testing
purposes. This is usually done by inverting all CRC bits.
Regards,
Allan.
--
Allan Herriman mailto:allan_herriman.hates.spam@agilent.com
Agilent Technologies Voice: +61 3 9210 5527
Advanced Networks Division Fax: +61 3 9210 5550
347 Burwood Highway Forest Hill 3131 Australia