JEDEC Updates HBM Standard with 24GB Capacity and Faster Speed

Subject: Graphics Cards, Memory | December 17, 2018 - 04:33 PM |
Tagged: Vega, radeon, JESD235, jedec, high bandwidth memory, hbm, DRAM, amd

In a press release today JEDEC has announced an update to the HBM standard, with potential implications for graphics cards utilizing the technology (such as an AMD Radeon Vega 64 successor, perhaps?).

"This update extends the per pin bandwidth to 2.4 Gbps, adds a new footprint option to accommodate the 16 Gb-layer and 12-high configurations for higher density components, and updates the MISR polynomial options for these new configurations."

View Full Size

Original HBM graphic via AMD

The revised spec brings the JEDEC standard up to the level we saw with Samsung's "Aquabolt" HBM2 and its 307.2 GB/s per-stack bandwidth, but with 12-high TSV stacks (up from 8) which raises memory capacity from 8GB to a whopping 24GB per stack.

The full press release from JEDEC follows:

ARLINGTON, Va., USA – DECEMBER 17, 2018 – JEDEC Solid State Technology Association, the global leader in the development of standards for the microelectronics industry, today announced the publication of an update to JESD235 High Bandwidth Memory (HBM) DRAM standard.  HBM DRAM is used in Graphics, High Performance Computing, Server, Networking and Client applications where peak bandwidth, bandwidth per watt, and capacity per area are valued metrics to a solution’s success in the market.   The standard was developed and updated with support from leading GPU and CPU developers to extend the system bandwidth growth curve beyond levels supported by traditional discrete packaged memory.  JESD235B is available for download from the JEDEC website.

JEDEC standard JESD235B for HBM leverages Wide I/O and TSV technologies to support densities up to 24 GB per device at speeds up to 307 GB/s. This bandwidth is delivered across a 1024-bit wide device interface that is divided into 8 independent channels on each DRAM stack.  The standard can support 2-high, 4-high, 8-high, and 12-high TSV stacks of DRAM at full bandwidth to allow systems flexibility on capacity requirements from 1 GB – 24 GB per stack.

This update extends the per pin bandwidth to 2.4 Gbps, adds a new footprint option to accommodate the 16 Gb-layer and 12-high configurations for higher density components, and updates the MISR polynomial options for these new configurations.  Additional clarifications are provided throughout the document to address test features and compatibility across generations of HBM components.

Source: JEDEC

Video News

December 17, 2018 | 05:27 PM - Posted by GoodNewsForHBM2OnDiscreteMobileSKUs (not verified)

Samsung's Aquabolt has become the JEDEC standard and now if there could be some Discrete Mobile Vega love for laptops NOT from Apple that would be even better news.

Apple should not be the only option for Laptops that make use of Discrete Mobile Vega graphics and 4GB of HBM2. I'm really wanting to see how Vega's HBCC/HBC IP works out for mobile gaming/Blender 3D workloads with Vega's HBCC able to manage a larger than 4GB virtual VRAM pool paged out to/from regular system DRAM.

What's up with that AMD! How come it's taking so long for that Vega HBCC/HBC IP to make is way into the non Apple laptop discrete mobile GPU market. At 16Gb per layer under the new standard that means that only 2 DRAM stacks would be needed for 4GB of HBM2 and lower packaging costs campared to 4 DRAM Stacks. But really I'm not going to pay Apple's pricing just to get a Discrete Mobile Vega Graphics option and really there better be some non Apple Laptop SKUs with Discrete Mobile Vega Options announced at CES 2019. The higher bandwidth per pin is just icing on the cake as that's good news also.

Hopefully SK Hynix gets some product that's compatable with the latest JEDEC standard so there can be lowered pricing pressure on HBM2.

December 18, 2018 | 04:24 AM - Posted by othertomperson (not verified)

JEDEC? You mean to say that it is NOT an AMD developed AMD standard, as AMD and others in the media have been claiming?

December 18, 2018 | 09:08 AM - Posted by An0n (not verified)

You have a lot of difficulty understanding nuance, don't you?

December 18, 2018 | 11:58 AM - Posted by StandardsOrgsMadeUpOfAllTheReleventPlayers (not verified)

It's the HBM standard that AMD and SK Hynix created and as members of JEDEC got JEDEC to adopt as an industry standard. JEDEC is an industry standards organization with AMD, Nvidia, Intel, Arm Holdings, Samsung, SK Hynix and everybody and their dog in the CPU/GPU/Memory industry.

It's just like PCI-SIG and USB-IF or The Khronos Group(OpenCL, OpenGL, Vulkan, and other software/API standards) VESA(Display Stabdards), and the HDMI Forum/whatever.

Industries tend to start Standards organizations that benifit entire markets of devices. It's lower cost that way for HBM to become an industry and more than one cpmpany support the standard and eventually the cost will come down due to the economy of scale. AMD and SK Hynix did not open up their HBM work only out of the goodness of their hearts they want a wider adoption of JEDEC Standard HBM in order to create that longer term economy of scale and that along with proper competition will result in lower cost HBM for All processor makers.

December 19, 2018 | 05:36 AM - Posted by Othertomperson (not verified)

SK Hynix are involved too?! Someone needs to inform r/AMD, and AMD themselves, apparently.

December 19, 2018 | 10:53 AM - Posted by GamersGotNoBrainsForTheMostPart (not verified)

r/Amd are mostly a bunch of stupid gamers without a single brain cell among the whole lot. And it was in fact AMD and SK Hynix that started the whole HBM thing because more effective bandwidth was needed for GPUs.

And r/anything is really not a good place to get information as r/Amd does more damage to AMD than good as anything gaming dominated is sure to be filled with the lowest common pond scum without a clue about high technology.

HBM is a JEDEC standard but that does only define hardware/firmware interoperability and both SK Hynix and Samsung have their own specific implementations of the JEDEC HBM Standard so YMMV.

It's juat like AMD's and Intel's Hardware/Firmware imlementation of the x86 ISA and respective microcode and the only thing that the x86 ISA defines is an execution templet that compilers compile their high level code down to. AMD's and Intel's respective underlying hardware/firmware/microcode implementation of that x86 ISA are very different and that's also the same for the custom ARM core desogns that only license the ARM 32/64 bit ISA and set about implimentating that ARM ISA in different respective custom hardware/firmware/microcode implementations.

The Folks at r/Amd do not have the brain power to make that distinction on CPUs and GPUs with GPUs also executing some proprietary ISAs. Gamers are quick to blame GCN and the Vega micro-arch for that difficiency. But it was in fact that first Vega 10(Big Die) tapeout that had an excess of shaders but not enough ROPs to compete with Nvidia's GP102 tapeout that had 96 available ROPs for Nvidia to bin down to 88 ROPs for the GTX 1080Ti and beat AMD in the GigaPxiel/s fill rate and gaming FPS metrics. And higher Pixel-Fill-Rates are directly related to numbers of ROPs and their total pixel fill rates that equate to more FPS. The higher the the pixel fill rates the hgher the FPS.

None of the current Pascal or Vega GPU micro-archs are that much different from each other and it's only been Nvidia's more ROP heavy tapeouts that have allowed Nvidia to maintain any gaming leadership in Raster Oriented gaming titles. AMD really had no funds for a more gaming oriented Vega Big Die Tapeout other than just enough funds to Tapeout that One Vega 10(Big Die) that had to do dual duty as a Base Die Tapeout for AMD's professional Compute/AI market needs and for AMD's Consumer/Gaming needs.

Luckily for AMD at the time there was the conflunce of Vega 10's release with the height of the second Coin Mining Craze where all the excess GPU Shader Compute on Vega 10(Big Die) proved to be popular with the coin miners. But AMD could do another Vega Base Die tapeout with More ROPs and less Shaders and handily compete with the GP102 based GTX 1080Ti as long as AMD could get at least 88 ROPs and make use of at least GF's 12nm process node. The Current Vega 56 Die Bin has the same number of TMUs and Shader cores enabled as the GTX 1080Ti but Vega 56 only has 64 ROPs that's the maximum number of ROPs offered from that Vega 10(Big Die) tapeout.

Maybe a new Vega 2 Base Die Tapeout could be done at 7nm and made to be more gaming oriented with less total Shader cores and way more ROPs and give AMD better gaming performance in Raster Oriented gaming titles than the GTX 1080Ti or the RTX 2080Ti that both only have 88 ROPs out of 96 ROPs enabled via their respective GP102 or TU102 base die tapeouts. Raster oriented gaming is still going to be King for a few more years anyways as any new technology takes years to be fully adopted.

Really since Both Maxwell and GCN both Nvidia's and AMD's GPU Micro-Archs have been similar(thread level parallelism oriented) with their respective Die tapeouts the thing that really defined their gaming performance potential. With Nvidia spending billons more on Tapeouts and AMD at the time of Vega 10(Big Die's) release only able to afford that one Tapeout that did not have enough total available ROPs.

And any renaming AMD/Nvidia GPU micro-archs radical changes gereration to generation up until Turing has been mostly lip service on the part of both AMD and Nvidia, as far as revolutions in GPU micro-arch designs. Turing is a departure and is more revolutionary but the Hybrid Ray Tracing IP is still not ready for prime time just yet and the Tensor Core Upscaling has more immediate potential for gaming.

If anything AMD needs the Tensor Core IP ASAP for its semi-custom console clients, and professional AI clients also for other AI related tasks. But Consoles need Tensor Cores for any AI accelerated upscaling on games but Hybrid Ray Tracing can be added at a later time. AMD could look into adding any Ray Tracing via FPGAs, and even FPGA implemented Tensor Cores could be implemented quicky for any semi-custom console clients. AMD has a patent application for FPGAs added onto the HBM stacks for some programmable in HBM(Now HBM2) Memory compute. So maybe AMD could implement things in FPGA form and update things as new algorithms are made available.

December 18, 2018 | 07:47 AM - Posted by Anonymouse (not verified)

Aside from AMD, it will be interesting to know who else will adopt the HBM tech.

December 18, 2018 | 02:39 PM - Posted by GenePoolDeficiencyIssuesWithYourBasePairs (not verified)

Really do you live in a cave? Nvidia's professional GPUs make use of HBM2 and so does Intel on FPGA/Other professional products and Kaby Lake G on the consumer end. There are even ARM server/HPC systems making use of HBM2 as well as some AI accelerator Third Party PCIe card based OEMs that have IP of their own that make use of HBM2.

HBM/HBM2 has already been adopted some time ago and you Really need to get out of that cave more often!

December 18, 2018 | 09:06 PM - Posted by ayyynon (not verified)

My wild guess would be at least one of the coming generation of consoles.

December 19, 2018 | 03:08 AM - Posted by Hakuren

All nice, but can we finally buy top of the line consumer VGA (like possibly nVidia 3080Ti or AMD Navi 128) which is between 15-20cm at most and not in region of 30cm+. Not to mention 2-3 slot aircoolers.

I know HBM is more expensive, but for small footprint and a lot of power I can invest. Sick and tired of current behemoths.

December 20, 2018 | 07:43 AM - Posted by AlanHurlburt

Does it beat this card?

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote><p><br>
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.