|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
While we don’t need to work the details of PMA specs & waveforem templates to select a proposal, but can work some before and some after, I strongly suggest that we not select proposals piecemeal.
In these complex signal processing systems, most phy vendors know that the complexity is a strong function of many, finely-balanced interacting specifications. As was pointed out in the study group, the specifications for a 10GBASE-T device push state-of-the-art in many respects – DSP complexity, canceller length & linearity, front-end sensitivity, low-power analog design, parallel digital design, magnetics bandwidth and EMI balance, to name a few. We rightfully had more than a year of strong debate on technical and economic feasibility of 10GBASE-T, and, for good reason – these things are hard! As such, the economic feasibility and the market potential needs to be determined on the basis of a more complete proposal, not piecemeal, since these will be dictated by the timeframe not for the standard, but for reasonable complexity standards-compliant devices.
Specifically, proposing line coding or FEC in absence of baud rate and equalization, and, in the absence of relatively complete complexity estimates will lead us away from the 5 criteria which were our goal. Nailing down a piece at a time is like building a 747 without a blueprint, and, worse yet, with congress delegated to make several independent design choices. AND, we don’t have to go down that path. If we get proposals out on the table, and fill them out, we can converge. To give a specific example, I currently see 3 proposals in Sanjay’s spreadsheet which have the level of detail necessary to consider complexity and feasibility – unfortunately, it’s not all 6 submittals. However, each of these 3 does have enough detail that we can begin the work of validating the estimates, of checking for coding performance, and of making the complexity/performance tradeoffs necessary to bring successful 10GBASE-T standard products to market in a reasonable timeframe.
If we were to mix & match and make separate, incremental decisions on these major architectural parameters, or, if we don’t have enough open review for the wider audience to consider the options on the table, we’ll end up with a relatively poor standard, one which will NOT pass muster as an economically feasible solution for a number of years.
I strongly recommend that we quickly zero in on one proposal even if we have to keep some parameters open for fine tuning based on more detailed investigation. I feel this will lead to a better standard in the end.
Carrying multiple proposals forward, specially if they are radically different, is going to be quite impractical and will also mean that the task force resources continue to be divided.
The sooner we converge on one proposal, the more time we will have to develop and test things like PMA specs, waveform templates, startup, autonegotiation, the protocol conformance stuff and a whole load of other items that have to be covered.
To give a specific example, if we to carry PAM and OFDM together in parallel, it will imply differences on almost every front and the Task Force attention and scrutiny will be divided.
On the other hand, given where we are today, it is impractical to nail everything down, so if we decide to continue, for example, with a THP based transmitter, we could put a range for the number of THP taps and take another meeting to narrow it down to a specific number.
If we make a decision now on a forward error correction technique we will have the Task Force's full attention on verifying it and are more likely to find problems (if they exist) and fixes to the problems.
cell (650) 704-7686
office (408) 653-2235
stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG] On Behalf Of Booth, Bradley
Just a clarification of the timeline that George alluded to, and so that the Task Force members understand. As per the current schedule, the Task Force will ask the 802.3 Working Group to permit us to go the Working Group ballot after the March 2005 meeting. To be able to make this request, the Task Force should have a technical complete draft to present to the Working Group at the March 2005 meeting. The Task Force can make some minor technical changes at the March meeting, but it will be up to the Working Group to decide if the Task Force is ready to go to Working Group ballot.
A method to do this is to have a set of baseline proposals that the Task Force adopts as the formation a D1.0. If the Task Force cannot select one proposal, then the Task Force should eliminate those with the least support. The remaining proposals would need to continue to be developed and weened as the Task Force moves forward. For example, if there are 3 coding proposals in July, the Task Force could document these 3 proposals. At each successive meeting, the Task Force would work to adopt only one proposal. Exiting the January 2005 meeting, the Task Force should only have one proposal in the specification. I would like to warn the Task Force that carrying multiple proposals for various portions of the draft specification as the Task Force moves forward will create a tremendous burden on the editorial staff. The faster the Task Force can move to the selection of one proposal, the easier it will be for the editorial staff and for the Task Force to focus on creating a draft that is ready for Working Group ballot.
If anyone has any questions on this, please feel free to ask them on the reflector. It is important that as a Task Force that we all understand the timeline required for us to meet the goals of this project.
Chair, IEEE P802.3an Task Force