Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: XGMII



Justin,

As currently proposed, I don't think the XGMII forces one out of an
FPGA or ASIC process.  We have in-house designs running 64-bit
busses with a 156 MHz ref clk.  It's implemented in an FPGA.
Granted, it's not DDR-clocked like XGMII proposes.  Given the
roadmaps that ASIC/FPGA vendors are touting, I think XGMII
will be a challenge, but not an impossible task.

Steve


Justin Gaither wrote:

> Roger,
>     It is only partially to benefit the board people.  It is also to keep
> the MAC/RS layers in the ASIC development process and not require a
> semi-custom bus interface in order to meet the strict timing.  It is fairly
> easy to keep an 8-9 bit bus to the strict timing and not have too many
> headaches.  However to keep 36 bits together to the strict timing is, I
> believe, forcing the MAC/RS into a semi-custom type of chip, rather than and
> ASIC/FPGA type of chip.  Which of course will increase cost.
>
> DDR RAM is expensive.  It is also full custom by nature, the same for the
> Microprocessor which connects to them.
>
> Roger Ronald wrote:
>
> > This interface does not seem to be any harder than interfacing to DDR RAM
> > at the same speed. Every corner garage shop will soon be turning out
> > DDR RAM based motherboards soon.
> >
> > Personally, I'd much rather have relatively tight timing instead of
> > complications in the clocking and a whole new chip to chip
> > protocol to spec/understand/debate/document/build.
> >
> > RR
> > ----- Original Message -----
> > From: "Justin Gaither" <jgaither@xxxxxxxxxxxxxxx>
> > To: "802.3ae" <stds-802-3-hssg@xxxxxxxx>
> > Sent: Monday, July 17, 2000 3:15 PM
> > Subject: XGMII
> >
> > >
> > > Everyone,
> > >
> > >     Concerning the XGMII interface, I remember at least one comment
> > > during the plenary and I have the same reservation concerning the
> > > extreme width and tightness of the setup and hold timing.
> > >
> > > I would like to suggest separate clocks for each of the 8 bit lanes.
> > > This would allow each lane to have a manageable number of tightly
> > > coupled signals, and allow for 1 or two clocks skew between lanes.  The
> > > Bus could easily be spread across the pins of a device enabling
> > > distributed reference and less ground bounce. I don't see adding 3 more
> > > pins to a 37 pin interface to be excessive.  Synchronization of the
> > > lanes could be done using the control lines for a sync.  (i.e.. 1111
> > > followed by 1000 on the control is start of data).
> > >
> > >
> > >
> > > --
> > > Justin Gaither                 Phone: 512-306-7292  x529
> > > RocketChips, Inc.              Fax:   512-306-7293
> > > 500 N. Capital of TX Hwy.
> > > Bldg 3                         email: jgaither@xxxxxxxxxxxxxxx
> > > Austin, TX 78746               WWW:   www.rocketchips.com
> > >
> > >
> > >
>
> --
> Justin Gaither                 Phone: 512-306-7292  x529
> RocketChips, Inc.              Fax:   512-306-7293
> 500 N. Capital of TX Hwy.
> Bldg 3                         email: jgaither@xxxxxxxxxxxxxxx
> Austin, TX 78746               WWW:   www.rocketchips.com
begin:vcard 
n:Augusta;Steve
tel;fax:978-623-0055
tel;work:978-247-8032
x-mozilla-html:TRUE
url:www.amcc.com
org:<image src = "http://www.amcc.com/images/Samcclogo.gif">
adr:;;200 Brickstone Square;Andover;MA;01810;USA
version:2.1
email;internet:saugusta@xxxxxxxx
title:Systems Development Manager
x-mozilla-cpt:;3408
fn:Steve Augusta 
end:vcard