Re: [802.3BA] 802.3ba XR ad hoc next step concern

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

Hi Ali,

I think we found the difference in our calculations.

1) I disagree with the two chip approach when calculating the difference in power consumption. You have kept the standalone VCSEL driver in the retimed case. I would like to remind you that this can be integrated. Companies have done this integration in both CMOS and BiCMOS. This integration saves more than 10%. In fact, the modulation for the VCSEL can leverage the Tx CDR drivers. This portion does not need to be duplicated. Nor does the input stages of the laser driver. Taking this into account, the delta for VCSEL functionality is ~30mW per transmit channel

2) In the receive path for the non-retimed case, you didn’t include any limiting amplification functionality. For a non-retimed limiting interface, I think it is appropriate to include a limiting amplifier to ensure swing and rise/fall time requirements are met, and to make this an apples-to-apples comparison. This architecture corresponds well to the block diagrams you have shown in the past (I’ve pasted the ghiasi_02_0108 block diagram for reference below)

If I were to take this into account and modify your calculations, we get:

40GBase-SR4 Module Non-Retimed PD = 4*(230 + 100 + 150) + 150 (uc+misc) = 2070 mW
40Gbase-SR4 Module Retimed = 4x450 + 4*(30 –> VCSEL Delta + 100) + 150 (uc+misc) = 2470 mW

Difference = 100mW per lane using the current technology numbers you proposed. In actuality the current technology numbers for CDRs are better than what you indicate, shrinking the difference even more.

I will be happy to discuss the LR4 compatibility question on the telecon tomorrow.

Best Regards,

Ryan

From: Ali Ghiasi [mailto:aghiasi@xxxxxxxxxxxx]
Sent: September 3, 2008 4:20 PM
To: Ryan Latchman
Cc: David Nelson (Louisville); Gourgen Oganessyan; STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern

Ryan

Please see my response below:

Ryan Latchman wrote:

Hi Ali,

I try to stay away from salty foods J.

Sorry if I didn’t respond to your other comments. I am not sure where the FP/DFB driver requirement comes from in relation to XR.

For 40GBase-LR4 applications.

Can you provide a little more detail on this? I also don’t see how integration limits implementation choices. I am interested in exploring the below comment a little further though…

Current dual XFP CDR burn 450 mW and I suggested we assume 50% power reduction or
"225 mW" assuming more advance process for XLAUI/CAUI CDR

Lets work with 225mW for a dual CDR (with limiting amplifier functionality in the Rx path since as you stated, this integration has been around for a long time). How much extra power consumption do you think it takes to integrate VCSEL driver functionality in the Tx path? Keep in mind that we already had a Tx driver in the ordinal dual CDR. The total power consumption for the 40GbE case would be the following:

40GbE CDR based XR Module Power = 4 * (225mW + Delta VCSEL Driver) + Quad ROSA + uC

Available 11G VCSEL driver burn 230 mW from 3.3 V, TIA burn about 100 mW from 3.3 V, Limiting TIA with RSSI burn about 100 mW from 3.3 V.

Now compare this total module consumption to the case without CDRs. For the without CDR case, please take into account that there is still a need for full fledge VCSEL driver with input / output buffers, limiting amplification etc. Let me know if you still have an issue with my estimate in the spread sheet.

There was no power penalty on the TIA mentioned here to have limiting output. It is also interesting to note all the PMD chips for performance
reason operated from 3.3 V supply, which will not result in 225 mW PD for dual CDRs! The process can be optimize for CDR PD, i.e. advance CMOS
processes with 1 V supply, which is not optimum divining a VCSELs with turn on voltage of about 2.2 Vand in case of TIA not having enough headroom.

Combining the CDR with VCSEL driver my estimate for power saving is about 10% not taking in to account the impact of non optimum process for
CDR and PMD chips.

On a separate note, Gourgen, the 10mW you reference might be associated with the linear interface proposal (as seen in cell F29). The delta in power consumption I referenced below is 40mW. In the spread sheet we have 80mW per lane delta module power consumption.

On the PMD chips I assume you can not reduce the power supply so the power stays about constant
40GBase-SR4 Module Non-Retimed PD = 4*(230 + 100) + 150 (uc+misc) = 1470 mW
40Gbase-SR4 Module Retimed (assume two chip solution) = 4x450 + 4*(230 + 100) + 150 (uc+misc) = 3270 mW (lowest current dual CDR PD)
40Gbase-SR4 Module Retimed (assume two chip solution) = 4x225 + 4*(230 + 100) + 150 (uc+misc) = 2370 mW (assume future generation of CDRs)

The 225 mW already is very aggressive with 50% lower than current lowest PD of dual CDR and should be the starting power differential between
retimed and non-retimed module. If Ryan wants us to accept 40 mW power differential at face value he need to provide more information.

Thanks,
Ali

Best Regards,

Ryan

David and Gourgen

I could not just stay silent seeing Ryan aggressive power estimate for dual CDR which is also included in the
XR spreadsheet, as it does not serve anyone to create unrealizable expectation.   But Ryan response was
"As previously discussed, your comparison with XFP is flawed" .
I also stated the following in previous email to Ryan:
    - Integrating CDR with VCSEL driver is feasible but not with FP/DFP driver
    - Integrating CDR with TIA is very risky and may have physical restriction
    - Integrating CDR with LD driver or TIA will limit implementation choice
    - Integrating Limiting AMP with CDR has been slam dunk for last 7 years, with our introduction of 1st
    LA/CDR for XFP.
    - Current dual XFP CDR burn 450 mW and I suggested we assume 50% power reduction or
     "225 mW" assuming more advance process for XLAUI/CAUI CDR.

When you sprinkle salt "CDR" all over your dinner you just can't swallow anymore and end up just filling up on water!

Thanks,
Ali


David Nelson (Louisville) wrote:

Saying power is 40mW more per channel than a limiting amplifier is not very helpful.  Limiting ampliers I've seen used range from 120mW to nearly 300mW.

From: Ryan Latchman [mailto:Ryan.Latchman@xxxxxxxxxx]
Sent: Tuesday, September 02, 2008 9:31 AM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern

Hi David, Gourgen,

Thank you for the response. For XR, the group already has our opinion on the additional power consumption for CDR functionality. I am not talking about 4W/10W per each end of cable assembly.

I can’t give exact power consumption numbers due to competitive reasons. With respect to further evidence on the power consumption side, I can tell you that Gennum’s Quad CDR with Limiting Amplifier IC (test chip results have already been shared for XLAUI and 4x10G SMF presentations) will consume less than 40mW more per channel compared to stand alone limiting amplifiers used in SFP+. In follow on generations, this difference will continue to reduce. Similar deltas can be observed in the transmit direction.

I agree with respect to not spending time on SFP+, and focusing on 40/100GbE. I am not proposing to make CDRs a requirement. I am presenting this as an option for achieving XR reach.

Best Regards,

Ryan

From: Gourgen Oganessyan [mailto:gourgen@xxxxxxxxxxx]
Sent: September 2, 2008 10:50 AM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern

I would agree with David. Also, we shouldn’t lose the sight of what we’re talking about: not 10G SFP+, but a 40G/100G solution. So if it’s 1W, you’re talking 4W/10W per each end of cable assembly.

Gourgen

From: David Nelson (Louisville) [mailto:DNelson@xxxxxxxx]
Sent: Tuesday, September 02, 2008 9:20 AM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern

To say the power of an sfp+ with dual cdr is less than 1W is not very helpful, considering 10G sfp+ modules range from under 0.5W to nearly 1W already. If your module including cdr is substantially below 1W, you would be wise, for the sake of furthering your company goal of getting a spec written to include a cdr, to get your company's permission to divulge that information. If the module power with cdr is close to 1W, as many of us suspect, then for many module vendors that would represent a substantial increase in module power, and the requirement to include dual cdr's is not persuasive.

David Nelson, JDSU

From: Ryan Latchman [mailto:Ryan.Latchman@xxxxxxxxxx]
Sent: Tuesday, September 02, 2008 5:58 AM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern

Hi Paul,

Sorry, I can’t divulge that information. What I can say is that there is margin with respect to SFP+ 1W requirement.

Best Regards,

Ryan

From: Paul Kolesar [mailto:PKOLESAR@xxxxxxxxxxxx]
Sent: August 31, 2008 8:41 AM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern

Ryan,
what is the typical and maximum power dissipation of the SFP+ module with the integrated CDRs that you show below?

Regards,
Paul Kolesar

Ryan Latchman <Ryan.Latchman@xxxxxxxxxx>

08/30/2008 09:04 AM

Please respond to
Ryan Latchman <Ryan.Latchman@xxxxxxxxxx>

To

STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx

cc

Subject

Re: [802.3BA] 802.3ba XR ad hoc next step concern

Ali,

As previously discussed, your comparison with XFP is flawed. The cost and power estimates given for XR assumes CDR integration which is very feasible. For your reference, below is an example PCB of an SFP+ module with CDRs in both directions (CDR with integrated laser driver in the Tx direction, CDR with integrated limiting amplifier in Rx direction). The benefits of this are clear. Systems designers don’t need to worry about jitter budgets (a topic which has plagued SFP+), and it saves them from having to put standalone signal conditioners on the line card, saving material amounts of cost and total system power.

The CDR based solution for achieving extended reach is the most trivial solution since:

1) It uses a simple host interface (XLAUI / CAUI) which can be leveraged to achieve all types of 40GbE or 100GbE PMD interconnect
2) XLAUI / CAUI enables lots of design flexibility. Hosts don’t care that the MMF channel is longer.
3) It is well proven technically.

Sorry I missed the XR call, but I was on a plane at that time. I look forward to additional discussion on this topic.

Best Regards,
Ryan

From: Ali Ghiasi [mailto:aghiasi@xxxxxxxxxxxx]
Sent: August 29, 2008 3:48 PM
To: Ryan Latchman
Cc: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx; DAWE,PIERS; Booth, Bradley
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern

Ryan

If you compare the cost difference between XFP and SFP module you will find more than 50% cost difference.
Adding a CDR to an SMF module will add about 5% to the BOM and about 15% to an MMF module BOM.
As you know the final cost of the module will increase by greater amount than the BOM cost increase.

You assumption about integrating CDR in the LA/LD may require to use special process, may limit availability, may have
technical issue of integrating TIA in to a CDR, or may have physical constrain.

During the XR call yesterday we had discussion how the system cost increase if the port density is reduced my be the greatest cost
factor.

Thanks,
Ali

Ryan Latchman wrote:
Hi Piers,

When considering the 5% cost adder to the module, take a look at the delta area of adding CDR functionality to a limiting amplifier or laser driver. I think you will find the extra area is small, particularly when you take into account bond pads of the LA/LD. Now take into account the other components which contribute to the cost of the module (ROSA, TOSA, uC…). I think you will find that a 5% adder is very realistic.

Best Regards,
Ryan

From: DAWE,PIERS [mailto:piers.dawe@xxxxxxxxxxxxx]
Sent: August 28, 2008 12:15 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern

Hi Brad,

The 5% sounds unlikely (I would have expected more) and similarly the 17% (what I've seen of the surveys says that when invited to lay out equipment anywhere with a 300 m constraint, very few links even go beyond 100 m).

But I'm actually writing to reply to your paragraph about compliance points. Remember that for Gigabit Ethernet, in 38.5, Table 38-10, the Total Jitter at TP1, TP2, TP3 and TP4 are all normative.

Piers
-----Original Message-----
From: Brad Booth [mailto:bbooth@xxxxxxxx]
Sent: 28 August 2008 03:55
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern
Dave,

I agree. A 5% cost adder seems reasonable for a 17% increase in broad market potential.

I do wonder if part of the problem is the compliance points TP0, TP1, TP1a, TP4, TP4a and TP5. In past efforts such as 802.3z and 802.3ae, these compliance points have been left up to MSAs and only TP2 and TP3 were of concern. Now the task force is dealing with such issues as modules and the cost impact of various implementations. IMHO, IEEE 802.3 was trying to avoid writing implementation specifications and was focused on compliance specifications. Could it be that these compliance points are causing the task force some heartache because it results in an implementation specification?

Just food for thought...

Thanks,
Brad

From: Chalupsky, David [mailto:david.chalupsky@xxxxxxxxx]
Sent: Wednesday, August 27, 2008 8:18 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern
The 20% cost premium applies to only one of our proposed XR alternatives.
According to the alternatives spreadsheet (Comparisons_xr_01_0708.xls) the CDR option adds only 5% module cost premium over the base proposal and provides reach of 168m to 251m (across the OM3/4, one-sided/two-sided matrix).

I’m struggling to keep up with the conversation here – but I believe that the 5% alternative addresses the same problem as the 20% alternative, right?

On that assumption I will rephrase Dan’s non-rhetorical question to address a 5% cost adder for 17% increase in coverage:

If I have the choice between:
A) carry two product SKUs: 100m and 150m, with 5% Bill of Material cost delta on the 150m product; or
B) carry only the 150m product
I would accept option B & use only the 150m module even though I know that most of my customers will use it at <100m.

By considering only the bill of material of the module we are missing two aspects of the big picture on cost.
1) Carrying multiple product SKUs through design, validation, manufacture, customer qualification, customer confusion, etc. adds cost.
Regardless of whether 802.3ba adds a second objective, if the module supplier base develops two different module solutions for 100 & 150m, then the 100m solution will carry an intangible cost burden and the desired 0% cost adder for 100m will not be achieved anyway.
2) The module is not the whole solution. The CDR module solution does not add cost to the host. Thus a 5% increase in module cost is less than 5% increase in the total cost of the switch plus modules.

I appreciate that the task force is learning from the history of 10GBASE-SR: that over-specifying the solution had a long term cost impact.
However, we should take away another lesson from 10Gbit: that providing too many options confuses the customers & slows adoption.

I strongly urge the task force to provide a single solution for parallel MMF. I believe that it’s worth a 5% cost adder to the module to achieve that.

I really have no personal (or commercial) reason to prefer the CDR option. I’m just looking at the 5% figure in the spreadsheet & wondering why this isn’t a no-brainer.

Thanks for your time,
Dave Chalupsky

From: Dove, Daniel [mailto:dan.dove@xxxxxx]
Sent: Wednesday, August 27, 2008 4:49 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern

Hi Mike,

We are pretty close to full circle now. :)

Assuming we make the decision that we want to stick with the "standard" model at 100m to keep those customers we would lose by adding cost, does the IEEE standardize a 150m solution or do we let the market solve that problem on its own?

This is not a rhetorical question, although it might appear to be.

Can someone provide any insight on the sensitivity of the market to an additional cost of 20% for every 100m link to satisfy the additional reach?

If the market is insensitive to cost (on this scale) then perhaps the additional reach is justified. If the market is going to be sensitive to that differential cost, then the question falls back to whether the IEEE wants to do a 150m spec or leave it to a market-defned solution.

Dan

From: Mike Dudek [mailto:Mike.Dudek@xxxxxxxx]
Sent: Wednesday, August 27, 2008 4:22 PM
To: Dove, Daniel; STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3BA] 802.3ba XR ad hoc next step concern
Hi Dan

Of course if we don’t increase the cost of the basic Grade A model and have a Grade B version of the same part for extra reach with the Grade B version being loaded with any additional costs of handling two product codes and any additional testing, then we shouldn’t lose any customers.

Regards
Mike Dudek
PMTS Standards & Technology
JDS Uniphase
1480 Arthur Ave.
Louisville
CO 80027
Tel 303 530 3189 x7533.
mike.dudek@xxxxxxxx

From: Dove, Daniel [mailto:dan.dove@xxxxxx]
Sent: Wednesday, August 27, 2008 3:23 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern

Let me re-state one word of that message.

From: Dove, Daniel
Sent: Wednesday, August 27, 2008 2:00 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern
Hi Steve,

Yes that helped a lot. I hope the others on the list are not irritated by my request for repetition of the data.

Given the data, it truly is a challenging issue. I see a 20% premium for a 17% increase in coverage.

This means the confidence in the numbers is exceptionally important and assuming they are accurate, a judgement call by the committee on whether or not a 17% increase in port coverage justifies the 20% increase in cost.

This is important because if you increase the *COST* of a solution by 20%, you may decrease the number of customers who are willing to buy it by more than 20%. Thus, in the overall mix, it might turn out to satisfy less customers overall.

Its a pretty challenging judgement call IMHO.

Thanks for providing the data.

Dan