Re: [oc] HDLC controller

[Jamil Khatib <jamilkhatib75@yahoo.com>]

Hi,
Thanks for your comments
I have still some questions.

 > 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/
>
I checked it but it seems that it has many features. I
want to build a core that is going to be part of SoC
that has internal CPU which can control many things.

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?)

> 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.

> 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.
>

Yes I have both options 
 
> 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

> 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.
>
yes I agree with you but since crc-16 or crc-32 can be
used I prefere to put it outside the core and let the
system integrator chose the right one. (this will be
done in parralel)
 
> 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.)
> 
yes this is good idea but I do not want to put any
register in my core because I'll leave it the the CPU
or even a generic communication controller

> Regards,
> Allan.

Thanks
Jamil Khatib



__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/