JEDEC fiddles with DDR4 while LRDIMM burns

JEDEC and DDR4 finalization

UPDATE: 06/10/2012: this article was slashdotted today
UPDATE: 07/24/2012: added Netlist on JEDEC BOD

While JEDEC has time before they finalize the DDR4 standard to secure relevant IP, they did not exercise similar concern when they finalized the LRDIMM standard.

LRDIMMs were standardized without securing the relevant IP.

http://hardware.slashdot.org/story/12/06/09/1839255/jedec-fiddles-with-ddr4-while-lrdimm-burns
JEDEC Fiddles With DDR4 While LRDIMM Burns
Posted by Soulskill on Saturday June 09, @05:02PM

JEDEC

JEDEC is a consortium of companies who seek to set standards in order to lower costs for their member companies.

Ideally they would like to base standards on freely available IP to reduce costs for member companies.

Occasionally JEDEC requires outside IP in order to make a standard work, and this they are supposed to secure before finalization of the standard.

DDR4 will require licensing of IP in load reduction and rank multiplication from Netlist (see below) – however since it has not been finalized yet, there is no hurry to license.

RAND licensing

Since a JEDEC standard is a powerful endorsement for a certain way of making a product, JEDEC can secure licensing on fair terms from holders of IP who stand to benefit from mass licensing of that IP.

This is especially true if JEDEC has the option of not using that IP and instead choosing another way of doing things.

If the company is a member of JEDEC, usually licensing on RAND terms (Reasonable and Non-discriminatory Licensing) is required of the member.

JEDEC power may however be diminished if the IP in question is essential to the way forward (load reduction and rank multiplication as currently used on LRDIMMs and expected to be used on DDR4).

However, once JEDEC has finalized that standard, that negotiating power is considerably diminished as the standard is already out there and there is a degree of “lock in” as products are already being made based on that standard.

This is what has happened with LRDIMMs.

LRDIMMs finalized without licensing relevant IP

JEDEC finalized the LRDIMM standard without securing licensing on load reduction and rank multiplication.

Inphi currently the only maker of LRDIMM buffer chipsets – others have backed off – lost a challenge of Netlist IP at the USPTO – as a result the Netlist patents have become stronger and are going to come back and bite Inphi in Netlist vs. Inphi which was stayed pending these patent reexaminations – patents which survive reexamination can never again be challenged on those issues again – NLST patents ‘537 and ‘274 survived with ALL claims intact which is a powerful statement on the strength of their IP – Inphi has appealed to the BPAI but the USPTO decision is telling.

For examining the patent reexamination info at the USPTO:

https://ddr3memory.wordpress.com/2012/06/04/examining-patent-docs-at-uspto/
Examining patent docs at USPTO
June 4, 2012

When Netlist vs. Inphi resumes, any recall of LRDIMMs or the non-availability of replacement LRDIMMs will constrain end-users of LRDIMMs.

Separately Inphi has dropped it’s retaliatory suit against Netlist unilaterally (I have examined the court docs in Inphi vs. Netlist docs and my feeling is that proceeding would have led to invalidation of two of Inphi patents – for double-patenting – basically same patent were filed using different authors and sent to two different examiners at the USPTO – as a blatant case of patent inflation !).

For more info, see the section “Inphi vs. Netlist (retaliatory)” in:

https://ddr3memory.wordpress.com/2012/05/30/legal-issues-with-lrdimms-repeating-metaram-2/
LRDIMMs similarities with MetaRAM
May 30, 2012

LRDIMM risk factors

LRDIMMs buffer chipsets are sole-sourced by Inphi – if Inphi is prevented from making LRDIMM buffer chipsets then LRDIMMs may face recall as infringing product, or it may become impossible to replace faulty LRDIMMs with new LRDIMMs.

For a description of how other LRDIMM buffer chipset makers have reduced enthusiasm for LRDIMMs:

https://ddr3memory.wordpress.com/2012/05/24/lrdimm-buffer-chipset-makers/
LRDIMM buffer chipset makers
May 24, 2012

When LRDIMMs are used, they have to be used EXCLUSIVELY on ALL the DIMM slots that are going to be populated. This is because LRDIMMs are not interoperable with RDIMMs or HCDIMMs.

There is no other replacement product for LRDIMMs except the products produced by Inphi.

If Inphi is barred from the sale of “iMB” buffer chipsets, there may be NO replacement LRDIMMs available in the future (to replace faulty parts).

For this reason, LRDIMMs could become a “dead end” product in the market.

For more info on the risk factors for LRDIMMs:

https://ddr3memory.wordpress.com/2012/06/05/lrdimms-future-and-end-user-risk-factors/
LRDIMMs future and end-user risk factors
June 5, 2012

Hedging your options

Currently all the OEMs are supporting LRDIMMs.

However IBM and HP have hedged their bets and are offering IBM HCDIMM and HP HDIMMs (based on Netlist HyperCloud memory).

The HyperCloud product is superior to the LRDIMMs:

– better latency than LRDIMMs
– interoperability with RDIMMs (LRDIMMs require all-LRDIMM on all DIMM slots)
– does not need BIOS update on motherboard to work (LRDIMMs require that)
– and a design that is being copied by DDR4 (see below)

The HyperCloud product also is manufactured by the inventor of load reduction and rank multiplication.

In contrast, LRDIMMs are based on a buffer chipset that is sole-sourced by Inphi (which holds little IP in this area and is facing a possible injunction in the future regarding use of load reduction and rank multiplication IP).

An explanation of Netlist HyperCloud as it is being sold by IBM/HP:

https://ddr3memory.wordpress.com/2012/05/27/what-are-ibm-hcdimms-and-hp-hdimms/
What are IBM HCDIMMs and HP HDIMMs ?
May 27, 2012

HyperCloud is also future ready (compared to the “end-of-life” architecture of the LRDIMMs) – DDR4 is copying HyperCloud in even greater detail than LRDIMMs were doing.

DDR4 licensing

DDR4 has dumped some of the asymmetrical lines and centralized buffer chipset choices in the LRDIMMs (which are the cause of high latency issues in LRDIMMs), in favor of an even closer following of the symmetrical lines and decentralized buffer chipset on the Netlist HyperCloud (see other articles here).

DDR4 will require licensing from Netlist (which might cover LRDIMM along the way) since at DDR4 low voltage and higher frequencies the need for load reduction becomes even more important.

On why lowered voltages for DDR4 increase the need for load reduction:

https://ddr3memory.wordpress.com/2012/06/01/impact-of-lowered-voltages-in-ddr4/
Impact of lowered voltages in DDR4
June 1, 2012

For an explanation of why DDR4 intersects Netlist IP, see the sections “Impact of litigation on LRDIMMs and DDR4” and “DDR4 intersection of Netlist IP” in:

https://ddr3memory.wordpress.com/2012/05/30/legal-issues-with-lrdimms-repeating-metaram-2/
LRDIMMs similarities with MetaRAM
May 30, 2012

Please see these articles for background info:

DISCLAIMER: I am not a lawyer, nor am I qualified to give legal advice – what follows is my own understanding – readers should do their own research before they arrive at a conclusion.

For more info on the risk factors for LRDIMMs:

https://ddr3memory.wordpress.com/2012/06/05/lrdimms-future-and-end-user-risk-factors/
LRDIMMs future and end-user risk factors
June 5, 2012

For examining the patent reexamination info at the USPTO:

https://ddr3memory.wordpress.com/2012/06/04/examining-patent-docs-at-uspto/
Examining patent docs at USPTO
June 4, 2012

On why lowered voltages for DDR4 increase the need for load reduction:

https://ddr3memory.wordpress.com/2012/06/01/impact-of-lowered-voltages-in-ddr4/
Impact of lowered voltages in DDR4
June 1, 2012

On the high latency disadvantages in LRDIMMs and how DDR4 cures them by copying Netlist HyperCloud more:

https://ddr3memory.wordpress.com/2012/05/31/lrdimm-latency-vs-ddr4/
LRDIMM latency vs. DDR4
May 31, 2012

For more information on Inphi similarity with MetaRAM, the history of MetaRAM, and of Inphi retaliatory suit against Netlist and it’s retraction:

https://ddr3memory.wordpress.com/2012/05/30/legal-issues-with-lrdimms-repeating-metaram-2/
LRDIMMs similarities with MetaRAM
May 30, 2012

An explanation of Netlist HyperCloud as it is being sold by IBM/HP:

https://ddr3memory.wordpress.com/2012/05/27/what-are-ibm-hcdimms-and-hp-hdimms/
What are IBM HCDIMMs and HP HDIMMs ?
May 27, 2012

https://ddr3memory.wordpress.com/2012/05/24/intels-need-for-lrdimms-on-roadmap-to-ddr4/
Intel’s need for LRDIMMs on roadmap to DDR4
May 24, 2012

https://ddr3memory.wordpress.com/2012/05/24/the-need-for-high-memory-loading-and-its-impact-on-bandwidth/
The need for high memory loading and it’s impact on bandwidth
May 24, 2012

For a description of how other LRDIMM buffer chipset makers have reduced enthusiasm for LRDIMMs:

https://ddr3memory.wordpress.com/2012/05/24/lrdimm-buffer-chipset-makers/
LRDIMM buffer chipset makers
May 24, 2012

JEDEC committee meetings

JEDEC committees relevant to LRDIMM/DDR4 are meeting in Washington:

http://www.jedec.org/events-meetings
June 2012
Event/Meeting Location Accommodations Start Date End Date

JC-16, 40, 42, 45, 63, 64
Arlington, VA
Hilton Crystal City
04 Jun 2012 to 08 Jun 2012

At this time they may be able to move forward with finalizing of DDR4 standard, but it could also be delayed.

JEDEC subcommittees relevant to LRDIMMs/DDR4

The JC-16, 40, 42, 45, 63, 64 committees are:

http://www.jedec.org/about-jedec/committee-chairs

JC-16: Interface Technology Doug Stout IBM Corporation
JC-16: Interface Technology Roleof Salters
(Vice-Chair) NXP Semiconductors
.
.
JC-42: Solid State Memories Desi Rhoden Montage Technology Group Ltd.
JC-42: Solid State Memories Jang Seok Choi (Vice-Chair) Samsung Semiconductor
JC-42.2 Subcommittee: SRAM Memories Gary Fleeman Advantest Corporation
JC-42.2 Subcommittee: SRAM Memories Dinesh Maheshwari (Vice-Chair) Cypress Semiconductor
JC-42.3 Subcommittee: DRAM Memories Joe Macri Advanced Micro Devices Inc.
JC-42.3 Subcommittee: DRAM Memories Clement Fang (Vice-Chair) Oracle America Inc.
JC-42.3B Letter Committee on DRAM Functions and Features Kevin Ryan Micron Technology Inc.
JC-42.3B Letter Committee on DRAM Functions and Features Dr. William Shen (Vice-Chair) Taiwan Semiconductor Mfg Company
JC-42.3C Letter Committee on DRAM Timing Todd Farrell Micron Technology Inc.
JC-42.3C Letter Committee on DRAM Timing Jang Seok Choi (Vice-Chair) Samsung Semiconductor
JC-42.4 Subcommittee: Non-Volatile Memory Devices Dong Yang Lee Samsung Semiconductor
JC-42.4 Subcommittee: Non-Volatile Memory Devices Cecil Ho (Vice-Chair) CST Inc.
JC-42.6 Subcommittee: Low Power Memories Hung Vuong (Co-Chair) Qualcomm Inc.
JC-42.6 Subcommittee: Low Power Memories Hangu Sohn (Co-Chair) Samsung Semiconductor
JC-42.6 Subcommittee: Low Power Memories Roger Isaac (Vice-Chair) Silicon Image Inc.
.
.
JC-45: DRAM Modules Mian Quddus Samsung Semiconductor
JC-45: DRAM Modules Peter Linder (Vice-Chair) Nanya Technology Corporation
JC-45.1 Subcommittee: Registered DRAM Modules Takao Ono Elpida Memory Incorporated
JC-45.1 Subcommittee: Registered DRAM Modules Jonathan Hinkle (Vice-Chair) Viking Modular Solution
JC-45.3 Subcommittee: Small DRAM Modules Kazuyoshi Tsukada Buffalo Inc.
JC-45.3 Subcommittee: Small DRAM Modules Jae Han Park (Vice-Chair) SK Hynix
JC-45.4 Subcommittee: Fully Buffered DRAM Modules Won Hyung Song Samsung Semiconductor
JC-45.4 Subcommittee: Fully Buffered DRAM Modules Joe Quddus (Vice-Chair) Montage Technology Group Ltd.
JC-45.5 Subcommittee: Module Interconnect Ricki Williams Oracle America Inc.
JC-45.5 Subcommittee: Module Interconnect Jim McGrath (Vice-Chair) TE Connectivity
JC-45.6 Subcommittee: Hybrid Modules Chris Socci PNY Technologies Inc.
JC-45.6 Subcommittee: Hybrid Modules Kelvin Marino (Vice-Chair) Smart Modular Technologies Inc.
.
.
JC-63: Multiple Chip Packages James Malatesta Micron Technology Inc.
JC-63: Multiple Chip Packages Patrick Moran (Vice-Chair) Qualcomm Inc.
.
.
JC-64: Embedded Memory Storage and Removable Memory Cards Mian Quddus Samsung Semiconductor
JC-64: Embedded Memory Storage and Removable Memory Cards Kimmo Mylly (Vice-Chair) Nokia Corporation
JC-64.1 Subcommittee: Electrical Specifications and Command Protocols Hung Vuong Qualcomm Inc.
JC-64.1 Subcommittee: Electrical Specifications and Command Protocols Victor Tsai (Co-Vice-Chair) Micron Technology Inc.
JC-64.1 Subcommittee: Electrical Specifications and Command Protocols Sung Lee (Co-Vice-Chair) Samsung Semiconductor
JC-64.2 Subcommittee: Form, Fit and Climatic/Environmental Methodologies Dr. Mostafa Abdulla Micron Technolgy Inc.
JC-64.2 Subcommittee: Form, Fit and Climatic/Environmental Methodologies Howard Sussman (Vice-Chair) Sanyo Semiconductor Corporation
JC-64.5 Subcommittee: UFS Measurement Perry Keller Agilent Technologies
JC-64.5 Subcommittee: UFS Measurement HeeChang Cho (Vice-Chair) Samsung Semiconductor
JC-64.8 Subcommittee: Solid State Drives (SSD) Alvin Cox Seagate Technology LLC
JC-64.8 Subcommittee: Solid State Drives (SSD) Frank Chu (Vice-Chair) Hitachi Global Storage Technologies Inc.
JC-64.9 Subcommittee: Wireless Memory Harald Kaaja Nokia
JC-64.9 Subcommittee: Wireless Memory Graziano Mirichigni (Co-Vice-Chair) Micron Technology Inc.
JC-64.9 Subcommittee: Wireless Memory Kyungyong Jeoung (Co-Vice-Chair) Samsung Semiconductor

UPDATE: 07/24/2012: added Netlist on JEDEC BOD

Despite the tension between Netlist and JEDEC as this article would suggest, Netlist’s VP Engineering has been on the JEDEC Board of Directors for a number of years:

http://www.jedec.org/about-jedec/board-directors
Board of Directors

Jayesh Bhakta Netlist

15 Comments

Filed under Uncategorized

15 responses to “JEDEC fiddles with DDR4 while LRDIMM burns

  1. Pingback: DDR4 borrows from LRDIMM use of load reduction | ddr3memory

  2. Nygan Suanho

    Looks like Samsung has the DDR4 comittee stacked in their favor. They were an original, major investor in IPHI’s IPO. Makes sense that they would push LRDMM approach instead of just going with Netlist. They are obviously using Netlist IP. Why the animosity between these two companies?

    • Inphi is heavily institutional owned. Their IPHI yahoo board is practically desolate. I am not sure they even have any retail investors. Yet until very recently IPHI did not even have a yahoo board – which I have not seen ever for a major company. The IPHI yahoo board was not created for YEARS since their IPO – despite repeated requests by folks on the NLST yahoo board.

      Then suddenly after the IPHI stock fall after recent conference call, a IPHI yahoo board magically appeared.

      But there is no one there.

      Combine that with IPHI’s avoidance of ever mentioning NLST as a competitor in the IPHI conference calls, you have a picture of a company which is in denial (IPHI is able to mention IDTI their competitor in LRDIMMs however, so they are tongue tied only about some things and not others).

      At the very least, IPHI is very careful and sensitive about open discussion of their company strategy and legitimacy.

      From the looks of it IPHI is engaging in a strategy around LRDIMMs which not the behavior of an independent company. For that you can look at IDTI (which has prudently scaled back rhetoric on LRDIMMs and delayed LRDIMMs until Ivy Bridge).

  3. craig

    Stop saying “IP” when you mean “patent”. “IP” is, at best, a wishy-washy vague term that has no significant meaning. It certainly has no legal meaning.

    JEDEC didn’t “fail to secure IP”, they “failed to license relevant patents”.

  4. Pingback: Patent trolls at the JEDEC gate ? | ddr3memory

  5. Pingback: Why are LRDIMMs single-sourced by Inphi ? | ddr3memory

  6. Pingback: Non-viability of 32GB RDIMMs | ddr3memory

  7. Pingback: LRDIMM buffer chipset makers | ddr3memory

  8. Pingback: Examining Netlist | ddr3memory

  9. Pingback: Examining LRDIMMs | ddr3memory

  10. Pingback: HyperCloud to own the 32GB market ? | ddr3memory

  11. Pingback: The Curious Case of Google vs. Netlist | ddr3memory

  12. Pingback: Latency and throughput figures for LRDIMMs emerge | ddr3memory

Leave a comment