[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [oc] Re: ATM Core



Hi,

It seems you have lot of good questions I am going to
answer some of them in this email and send extra
information later.

1. First from the first point of view you are talking
about a "full" ATM system not only an ATM phy.

2. PCI is not usable much for ATM interface because 
  a) it can not hold all ATM rates
  b) UTOPIA is the standard interface for all ATM
systems
What I meent by the use of PCI is the use of my
suggested PCI local side interface for local side
utopia interface.

3. regarding the UTOPIA level
--all levels can operate together as far as I know but
you have to connect them in proper way and give the
device teh correct configuration
--when you want to select the utopia interface level
you have to know number of ports on your chip for
example if you have only one port all what you need is
level 1 teh same as managment port. but if you have 4
ports per chip you should chose level 2. 
Anyhow it depends on how you are going to connect the
phys.
-- each level supports different number of phys for
example level2 supports up to 30 phy.

-- You talked about not supporting Mphy but in this
case you are in level 1

4) Frame assembly/diassimbly is called SAR which is
located in the AAL layer.

5)I am not sure if we have to support SONET or SDH in
the ATM phy, or to build only ATM phy


Regards,
Jamil Khatib


--- Rudolf Usselmann <rudi@mozart.inet.co.th> wrote:
> 
> Now I know why I didn't get any email ! All the
> discussions
> happen on the mailing list - Dhu ! ;*)
> 
> OK, ATM core local i/f: I feel PCI would be a bad
> choice. I'm
> looking at the PHY interface (Utopia 3) it can do
> about 3.2Gb/s
> tops, 800Mb/s min. So that leaves out PCI, as it
> would not be
> able to provide sufficient bandwidth.
> I'll take a look at that other thing that has been
> suggested, and
> see if that will work.
> 
> PHY i/f: Hmm, Someone suggested doing Utopia 1 and
> 2, and later 3.
> I'm more inclined starting with 3, maybe include
> backwards compatibility
> to 1 and 2. For Utopia 3, I would also probably not
> support the multi
> phy feature (don't quite understand how it works yet
> anyway ...).
> However I would probably make it configurable to
> support all 3 operational
> modes of Utopia 3: 0.8, 1.6 and 3.2 Gb/s.
> Utopia 4 is about to be released, so I'm thinking 1
> & 2 will be history
> anyway ...
> 
> 
> OK a few questions:
> 
> 1.1) Utopia 3 without MPHY support will be OK (for
> first version) ?
> 1.2) PHY config interface will not be included, OK ?
> 1.3) Supporting 0.8, 1.6 and 3.2 Gb/s: should I make
> the core
> to be configurable at the synthesis level (e.g.
> parameterize it)
> or should it be build in so the user/system (once in
> a chip) can
> decide ?
> 
> 2.1) Should I include the Frame assembly/disassembly
> logic, or should
> that be in a different project ?
> 2.2) If yes to 2.1: Should we include multiple data
> DAM channels ?
> e.g. we can have multiple DMAs going on at the same
> time, interleaving
> cells ... this will be interesting, need to account
> for QoS as well then.
> 
> 3.1) Again, I'm assuming yes to 2.1: I'm thinking of
> doing DMA descriptor
> lists that include the link (path/channel) info and
> a pointer to the actual
> frame data (and it's length). (Kind of a linked list
> in memory... ) Does
> this sound OK ?
> 3.2) How do we handle establishing path & channels ?
> Do it in hardware
> (how?) or leave that to SW ?
> 3.3) I think we might need at least one additional
> DMA, so we can insert
> control/management cells, any ideas ?
> 
> Thanks,
> rudi
> 
> 


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/