RE: [10GBASE-T] PAR and 5 critters
Hi George,
I appreciate your response. I have gotten some <off reflector>
admonition for raising questions that in my opinion are valid
and would better be answered than ignored.
I looked for EMI measurements in the November CFI presentation
but must be looking in the wrong spot. Could you be more specific
wrt to the presentation and page #?
Regarding DSP feasibility, this is not my strong suit, but I love
to be educated. Please don't consider my questions to be based
upon an adversity, but rather concerned naivete.
I acknowledge that analog processing will likely reduce the DSP
complexity and may render feasibility in available processes. The more
I learn in this area, the more interesting this discussion becomes to me.
Thanks for adding to the discussion.
Regards,
Dan Dove
> -----Original Message-----
> From: George Zimmerman [mailto:gzimmerman@solarflare.com]
> Sent: Wednesday, July 30, 2003 10:59 AM
> To: [unknown]
> Subject: RE: [10GBASE-T] PAR and 5 critters
>
>
>
> In deference to some of Brad & Bob Grow's earlier admonition,
> technical
> feasibility is a matter of increasing confidence as time moves on. The
> tone of this discussion appears to have moved from the "can't
> be done at
> all" to "how much & what kind of silicon will it require". I
> will assume
> that we have entered that stage.
>
> We have presented our estimates of feasibility at about 6X 1000 BASE-T
> and implementable in today's CMOS at the tutorial in November.
> Regardless, there is no doubt that 90nm will be a commercial processes
> well before 10GBASE-T is through the standards process (at
> the earliest
> 2nd half of 2005), and 65nm will be commercial as 10GBASE-T begins to
> ramp in the subsequent years.
>
> In direct response to Dan's concern, there are a variety of algorithms
> that do not require closing the loop at the baud rate, (the
> simplest of
> which are the look-ahead algorithms which have obvious complexity
> drawbacks), various reduced-state and lower-complexity forms are well
> studied in the literature, and have been implemented in commercial
> products. (Dan - you will also see EMI measurements from November)
>
> In deference to earlier comments by Vivek & others, yes, if I
> just take
> the simplest form of design (direct-form FIR) and multiply up by the
> baud rate & # of taps I get a huge complexity multipler
> (something like
> the 45X 1000 BASE-T), but just because the simplest-extension yields a
> huge complexity doesn't mean that it is non-feasible. Current art in
> efficient and multi-rate filtering algorithms don't scale linearly as
> the number of taps or processing speeds go up, and provide significant
> benefits (see November tutorial for an example, but these are
> also well
> studied in the literature).
>
> George Zimmerman
> gzimmerman@solarflare.com
> tel: (949) 581-6830 ext. 2500
> cell: (310) 920-3860
>
> > -----Original Message-----
> > From: DOVE,DANIEL J (HP-Roseville,ex1) [mailto:dan.dove@hp.com]
> > Sent: Wednesday, July 30, 2003 8:38 AM
> > To: 'sreen@vativ.com'; 'Alan Flatman'; 'Kardontchik, Jaime'
> > Cc: '[unknown]'; 'Sterling Vaden'
> > Subject: RE: [10GBASE-T] PAR and 5 critters
> >
> >
> > > 2. Performing large number (x8 relative to 1000BaseT) of DSP
> > > calculations at
> > > 833MHz,
> >
> > Precisely my concern. I think it would be a useful exercise to
> > calculate the loop timing necessary to make such a thing work, and
> > then extrapolate to the process geometry that would enable it.
> >
> > I observed that 1000BASE-T did not really become solid in practice
> > until .18u became available. There were some decent .25 designs, but
> > I suspect that corners were being "trimmed" to make timing close.
> >
> > Dan
> >
> > > -----Original Message-----
> > > From: Sreen Raghavan [mailto:sreen-raghavan@vativ.com]
> > > Sent: Tuesday, July 29, 2003 1:58 PM
> > > To: 'DOVE,DANIEL J (HP-Roseville,ex1)'; sreen@vativ.com;
> > > 'Alan Flatman';
> > > 'Kardontchik, Jaime'
> > > Cc: '[unknown]'; 'Sterling Vaden'
> > > Subject: RE: [10GBASE-T] PAR and 5 critters
> > >
> > >
> > > Dan:
> > >
> > > We are really referring to the theory (Shannon Capacity) when
> > > we say 10Gbps
> > > cannot be achieved over CAT-5e or CAT-6 cabling. Theory shows
> > > that 10Gbps
> > > can be achieved over CAT-7 cabling. Practical issues to
> > > accomplish 10Gbps
> > > over CAT-7 cabling include (assuming PAM-10 modulation):
> > >
> > > 1. Building an 11-bit effective ADC at 833 MBaud,
> > > 2. Performing large number (x8 relative to 1000BaseT) of DSP
> > > calculations at
> > > 833MHz,
> > > 3. DDFSE critical path to be implemented in 1.2 ns
> > > 4. Building a linear transmit driver with an 833MGz bandwidth
> > > & 40 dB SNR
> > >
> > > The above list by no means is exhaustive, but shows the
> implementation
> > > issues that need to be considered.
> > >
> > > Sreen
> > >
> > > -----Original Message-----
> > > From: DOVE,DANIEL J (HP-Roseville,ex1) [mailto:dan.dove@hp.com]
> > > Sent: Tuesday, July 29, 2003 1:09 PM
> > > To: 'sreen@vativ.com'; 'Alan Flatman'; 'Kardontchik, Jaime'
> > > Cc: '[unknown]'; 'Sterling Vaden'
> > > Subject: RE: [10GBASE-T] PAR and 5 critters
> > >
> > > Hi Sreen,
> > >
> > > One thing that occurs to me on this point is the
> difference between
> > > theory and application. Specifically, how many process
> actions have
> to
> > > take place within a baud time to close the loops on the
> DSP and what
> > > process geometry would be required to make that timing closure?
> > >
> > > I know that with 1000BASE-T, the theory was rock solid long before
> the
> > > processes to implement it were reliable.
> > >
> > > Dan
> > > HP ProCurve
> > >
> > > > -----Original Message-----
> > > > From: Sreen Raghavan [mailto:sreen-raghavan@vativ.com]
> > > > Sent: Tuesday, July 29, 2003 11:52 AM
> > > > To: 'Alan Flatman'; 'Kardontchik, Jaime'
> > > > Cc: '[unknown]'; 'Sterling Vaden'
> > > > Subject: RE: [10GBASE-T] PAR and 5 critters
> > > >
> > > >
> > > >
> > > > Just to clarify, Vativ, Broadcom & Marvell presented capacity
> > > > calculations
> > > > at the Portsmouth meeting and showed that worst-case CAT-7
> > > > (Class F) cabling
> > > > had sufficient channel capacity to achieve 10Gbps throughput
> > > > at 100 meter
> > > > distance. The reason for "may be possible" statement in the
> > > > conclusions was
> > > > that the 3 PHY vendors felt that more work needed to be done
> > > > on practical
> > > > implementation issues before the conclusion could be
> > > altered to a more
> > > > definitive statement.
> > > >
> > > > In addition, we proved conclusively that there was NOT
> > > > sufficient channel
> > > > capacity on existing CAT-5e (Class D), or CAT-6 (Class E)
> > > > cables to achieve
> > > > 10 Gbps throughput.
> > > >
> > > > Sreen Raghavan
> > > > Vativ Technologies
> > > >
> > > > -----Original Message-----
> > > > From: owner-stds-802-3-10gbt@majordomo.ieee.org
> > > > [mailto:owner-stds-802-3-10gbt@majordomo.ieee.org] On Behalf
> > > > Of Alan Flatman
> > > > Sent: Tuesday, July 29, 2003 9:51 AM
> > > > To: Kardontchik, Jaime
> > > > Cc: [unknown]; Sterling Vaden
> > > > Subject: RE: [10GBASE-T] PAR and 5 critters
> > > >
> > > >
> > > > Message text written by "Kardontchik, Jaime"
> > > > >Was any reason given why it would not run on Class F ?
> Was it for
> > > > technical reasons or for marketing reasons ?<
> > > >
> > > > The 3-PHY vendor presentation made in Portsmouth
> (sallaway_1_0503)
> > > > calculated 49.36 Gbit/s capacity using unscaled Cat 7/Class F
> > > > cabling. This
> > > > figure was reduced to 37.71 Gbit/s with worst case limits.
> > > Overall, I
> > > > thought that this was a refreshingly realistic
> presentation and I
> > > > interpreted the summary statement "Capacity calculations with
> > > > measured data
> > > > indicate 10 Gigabit data transmission over 100m Cat 7 may
> > > be possible"
> > > > (slide 16, bullet 3) as overly cautious engineering judgement.
> > > >
> > > > So, what has changed since the May interim? Not the laws of
> physics!
> > > >
> > > > Best regards,
> > > >
> > > > Alan Flatman
> > > > Principal Consultant
> > > > LAN Technologies
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
>