Sei sulla pagina 1di 3
Geoff Tate Monday, December 01, 1997 7:06 PM engmar@rambus.com, exec@rambus.com; adiepenb@rambus.com; barth@rambus.com; gasbarro@rambus.com; stark@rambus.com; dnguyen@rambus.com: ksisman@rambus.com, bdmarket@rambus,com ce: gtate@rambus.com Subject: intel exec meeting 12/1/97 ““ACTION ITEMS FOR ALLEN, DAVE, GEOFF**- IGNORE FIRST VERSION: 2ND VERSION AND THIS ONE HAS COMMENTS ON DRAM ROYALTY Too dave and i met this afternoon for 2 hours with ~ pat gelsinger (desktop group vp) = gerry parker (technology/mfg group ve) = pete macwilliams (works for pat - desktop architecture head guy) ~ gidu shroff (works for gerry, is dennis lenehan’s boss) executive summary: they have several issues of major concem, we have lots ‘of work to do, but they are moving ahead (for now). “\WARNING*- don't read the rest of this email til you've put on your thick skin, DRAM ROYALTYIMOTIVATION pete basically agreed that dram companies over the last quarter eithe stayed the same or increased in motivation = we emphasized that the most motivated dram companies are those with direct rambus logic commitments with major customers in the non-pe space AND that we have two more dram companies now negotiating for direct rambus logic based on non-pc customers = we told them warrants have had a positive impact on motivation = but that on royalty reduction we tried several trial discussions with ‘major dram partners and NONE were willing to trade royalty reductions for CHANGES IN BEHAVIOR: all said give me lower royalty and fil be more motivated, but weren't willing to comimitment to specific commitments this surprised intel (who thinks these guys will have no leverage in 12 ‘months) but they said they'll drop beating us on this given this input, (amazing - m sure i l come back up again next quarter) cost = biggest issue = their view is 64M direct rdram is 10-15% over sdram (not average 10% like we think); plus esp price premium; plus dram guys wanting more margin means 64M direct rdram price premiums of 20-30%II as for 128M, pote thinks we can start at 5% but that we will have increasing % premium as shrinks take place: he thinks we need to get a solid plan to work the technical issues to ensure a 5% max die size premium over sdram over the life of 126M as it shrinks: that we need the plan now (on architecture and process ~ especially if we have changes in bank organization/architecture to address cost intel MUST know it NOW to implement in camino or I's useless = “ACTION ALLEN™: this month we have to give pete a plan that convinces him we have a strategy for 5% die size premium at 128M over 128M scram: architecture, process, etc (on process he said m-2 is the only thing he's heard: he thinks we need fo have several other ideas of what needs to be ‘worked in parallel: not tackle the problem serially) = pete did say, in response to pat's question, that on test they agree with ur position in the long term BACKEND CAPITAL, - they are concerned about the capital $ needed and availability of enough 1 FIDENTIAL - FTC DOCKET NO. 9302 RFO673372 cx0974-001 equipment (capacity) to handle the ramp in the aggressive scenarios for direct rdrams: testers, assembly, burnin, etc, = “ACTION™: they are expecting some Sort of analysis/plan from us on this, “DAVE? BELOIT ~ code name: some small town somewhere, no particular meaning - they have an idea they have been working in november to have @ RIMM that ses SORAMS with a “converter” chip that might cost say $5-10 - this module would work with camino in RIMM-capable motherboards: at configuration time @ PC OEM would populate with this BELOIT RIMM or with RDRAM RIMM (later upgrades would have to be consistent) ~ the sdram would be basically an sdram-100 BUT they'd need to get them to change 1/0 for 2.5V to be compatible with RIMM (core Is 2.5V already) which they think is @ change in regulators; and they'd expect they could run @ J00Mnz SDRAM at maybe 133Mhz on @ RIMM with point-to-point links/lower loads/ixed loads-skews + intel would do the "converter chip" at least the first one, then maybe have DRAM vendors do their own for modules - they think that BELOIT Is uninteresting IF rambus meets its cost targets Of say 10%, but it makes a lot of sense ifthe price premium is 20-30% - thelr positioning to dram companies would be that intel is committed to the RIMM standard and this is @ backup plan ~ pete says they've thought through 80% of the technical issues - they would tell cram companies that BELOIT would be a better solution than DOR: it could be used for their non-intel main memory customers too so they could drop DDR ~ PLAN: intel to think through the rest of the details, discuss with us, if ‘no show stoppers then wil roll out to dram guys in Q1, either mid january OF end february were dates pete mentioned - they'll work the communication plan with us -“ACTION™ “DAVE: work above issues with intel; “GEOFF™ to have phone call with pat by 12/23 to review status/plan of record DDR - pat says they have no chipset plans at this time to support DDR they are willing to consider they can work out the tech issues on BELOIT and get our/dram co agreement to it then they'll back off on DDR entirely (think he sald that but dave wasn't sure - we need to take the position that BELOIT is 2 dumb idea if they tell the dram guys just to do more and they'll use DDR too maybe) pat said for segment 0 they are already committed to sdram, but with BELOIT they could use RIMM for the subsequent segment 0 chipset, SEGMENT 0 = pat thinks 32MB Is the minimum for windows 98 (he loses no sleep about microsoft needing more memary) ~ segment 0 will not pay even $7 more for 3x performance improvement: if performance or price/performance mattered they would lose rio processor business in segment 0 MOBILE + pat said we have serious problems for mobile and basically have only an ‘800mbhz desktop story now (our latency at 600mhz makes our performance uncompelling for desktop pete says **CRAIG"722) = our mobile performance is now uninteresting due to latency and nap problems; and we don't have a robust mobile module ~ pote's frustrated because he sees good ideas from rambus'ers but an ‘unwillingness for rambus to commit or even discuss: substantial reduction of nap mode latency; broadside load and cmos refresh; adjustable latency numbers in pipeline logic ~ dave asked if we could address this with 128M: they said colfax schedule 2 \FIDENTIAL ~ FTC DOCKET NO. 9302 RFO673373, x0974-002 is very close to camino, so 128M only makes sense IF itl happen very quickly after 64M = “"ACTION™: need plan to address mobile issues in DECEMBER with pete: ‘step 1 is what changes to make to address mobile issues; step 2 is to agree how to insert into direct rdram roadmap can convince them CONTRACT they have several issues that we've stalled on: SDD, adcitional investment in packaging they didn't plan on; IP re packaging they lose if ‘we dont get to success (777); other logic rights; etc. kod how do we work these issues out = we said chung is too low level and we need big picture give-and-take + plan we agreed on is for us to work with pete/dennis (the original team) to get to an LOI: then chung can get involved to work details; if necessary pat says he can set up a call with me io discuss the major issues for a ‘couple hours: | said i'd use that if we stall with peteidennis - we said we needed a win-win approach and showed several ideas of things We would like: commitment on direct use for intel graphics and public statement; more nre to fund our increased investment in mobile/server, ‘maybe stock purchase to show intel commitment; etc - they didn't gag on any of these things soi think now we can consider asking for them = “ACTION™ DAVE ta schedule pete/dennis meeting; to decide if we should proactively invite larry paley/PCD to head off chung and to get PCD bought in DDR SGRAM = pote says they are NOT promoting DDR SGRAM: they are promoting faster SGRAM (regular flavor) he did say they are working to set a spec on DDR SGRAM even though they tell graphics guys it won't work as dram guys advertise = wo stated that ANY promotion of DDR for graphics is very dangerous as the dram guys and press don't understand the technical distinctions between single chip graphics frame buffer and large main memory system, so if intel is seen to be saying DOR is good for graphics most people will assume that therefore i's good for main memory they had to run for the plane at this point geoff Geoff Tate Rambus Tel NEW AREA CODE: 650-903-3807 FAX NEW AREA CODE: 650-965-1528 “NOTE: THIS EMAIL MAY CONTAIN RAMBUS CONFIDENTIAL INFORMATION" Geoff Tate Rambus ‘Tel NEW AREA CODE: 650-903-3807 FAX NEW AREA CODE: 650-965-1528 “NOTE: THIS EMAIL MAY CONTAIN RAMBUS CONFIDENTIAL INFORMATION™ ONFIDENTIAL - FTC DOCKET NO. 9302 RFO673374 x0974-003

Potrebbero piacerti anche

  • CX0982
    CX0982
    Documento1 pagina
    CX0982
    antitrusthall
    Nessuna valutazione finora
  • CX0992
    CX0992
    Documento2 pagine
    CX0992
    antitrusthall
    Nessuna valutazione finora
  • CX0988
    CX0988
    Documento2 pagine
    CX0988
    antitrusthall
    Nessuna valutazione finora
  • CX0993
    CX0993
    Documento4 pagine
    CX0993
    antitrusthall
    Nessuna valutazione finora
  • CX0987
    CX0987
    Documento5 pagine
    CX0987
    antitrusthall
    Nessuna valutazione finora
  • CX0981
    CX0981
    Documento4 pagine
    CX0981
    antitrusthall
    Nessuna valutazione finora
  • CX0983
    CX0983
    Documento2 pagine
    CX0983
    antitrusthall
    Nessuna valutazione finora
  • CX0986
    CX0986
    Documento1 pagina
    CX0986
    antitrusthall
    Nessuna valutazione finora
  • CX0984
    CX0984
    Documento4 pagine
    CX0984
    antitrusthall
    Nessuna valutazione finora
  • CX0961
    CX0961
    Documento6 pagine
    CX0961
    antitrusthall
    Nessuna valutazione finora
  • CX0974
    CX0974
    Documento3 pagine
    CX0974
    antitrusthall
    Nessuna valutazione finora
  • CX0979
    CX0979
    Documento1 pagina
    CX0979
    antitrusthall
    Nessuna valutazione finora
  • CX0973
    CX0973
    Documento1 pagina
    CX0973
    antitrusthall
    Nessuna valutazione finora
  • CX0968
    CX0968
    Documento1 pagina
    CX0968
    antitrusthall
    Nessuna valutazione finora
  • CX0965
    CX0965
    Documento2 pagine
    CX0965
    antitrusthall
    Nessuna valutazione finora
  • CX0966
    CX0966
    Documento1 pagina
    CX0966
    antitrusthall
    Nessuna valutazione finora
  • CX0963
    CX0963
    Documento1 pagina
    CX0963
    antitrusthall
    Nessuna valutazione finora
  • CX0944
    CX0944
    Documento4 pagine
    CX0944
    antitrusthall
    Nessuna valutazione finora
  • CX0960
    CX0960
    Documento1 pagina
    CX0960
    antitrusthall
    Nessuna valutazione finora
  • CX0953
    CX0953
    Documento1 pagina
    CX0953
    antitrusthall
    Nessuna valutazione finora
  • CX0956
    CX0956
    Documento4 pagine
    CX0956
    antitrusthall
    Nessuna valutazione finora
  • CX0957
    CX0957
    Documento2 pagine
    CX0957
    antitrusthall
    Nessuna valutazione finora
  • CX0947
    CX0947
    Documento2 pagine
    CX0947
    antitrusthall
    Nessuna valutazione finora
  • CX0952
    CX0952
    Documento3 pagine
    CX0952
    antitrusthall
    Nessuna valutazione finora
  • CX0946
    CX0946
    Documento1 pagina
    CX0946
    antitrusthall
    Nessuna valutazione finora
  • CX0942
    CX0942
    Documento1 pagina
    CX0942
    antitrusthall
    Nessuna valutazione finora
  • CX0948
    CX0948
    Documento2 pagine
    CX0948
    antitrusthall
    Nessuna valutazione finora
  • CX0939
    CX0939
    Documento2 pagine
    CX0939
    antitrusthall
    Nessuna valutazione finora
  • CX0937
    CX0937
    Documento2 pagine
    CX0937
    antitrusthall
    Nessuna valutazione finora
  • CX0938
    CX0938
    Documento3 pagine
    CX0938
    antitrusthall
    Nessuna valutazione finora