While Intel works on getting its main manufacturing process technology on track, it is spending just as much time and effort in researching and developing the rest of the chip ecosystem and how it is all connected. On a call with Intel's process and product team, the company confirmed a few details about how Intel is pushing the boundaries of new technologies with its upcoming high profile graphics products.

An Insight into Intel's Strategy on Chiplets and Packaging

In a call with Intel last week, we spoke with Ramune Nagisetty, the Director of Intel’s Process and Product Integration, to discuss Intel’s strategy with regard to chiplets and packaging technologies. Ramune has spent over twenty years at Intel, working in areas such as transistor definition for 65nm, Intel Labs for technical strategy and wearables, and most recently as heading up Intel’s chiplet strategy for product integration. Ramune focuses on the art of the chiplet or the packaging in its own right, rather than the specific technologies it goes into, and it was an enlighting discussion.


Ramune Nagisetty

The story around chiplets is going to be a cornerstone of the semiconductor market for the next generation, being able to provide smaller silicon for specific tasks and connecting them together. Chiplets form the basis of Intel’s current Stratix 10 FPGA product line, and the future of Intel Agilex, as well as consumer products like Kaby Lake G with its HBM chiplet for fast high-speed memory. How Intel integrates its own chiplets, with the company confirming it is working on migrating its AI portfolio into chiplet form factors, as well as other third party IP, is going to be an important strategy going forward. The art of connecting chiplets, however, is all in the packaging. Intel has several technologies of its own that it uses.

EMIB, Foveros, Interposers: Connect the Data

Intel’s Embedded Die Interconnect Bridge ‘EMIB’ has been a talking point for a couple of years now. Because certain high-performance chiplet designs require high-bandwidth links with many more traces than traditional organic chip packaging can support, there is a need for more exotic means to build these dense connections. The 'brute force' solution here is a silicon interposer, essentially stacking chips on top of a large, 'dumb' silicon die that's in place solely for routing purposes.

With EMIB however, rather than using a full silicon interposer, Intel equips a substrate with just a small embedded silicon connection, allowing a host chip and a secondary chiplet to connect together with high bandwidth and small distances. This technology is currently in Intel’s FPGAs, connecting the FPGA to memory or transceivers or third-party IP, or in Kaby Lake-G, connecting the Radeon GPU to on-package high bandwidth memory.

Intel has also uses full interposers in its FPGA products, using it as an easier and quicker way to connect its large FPGA dies to high bandwidth memory. Intel has stated that while large interposers are a catch-all situation, the company believes that EMIB designs are a lot cheaper than large interposers, and provide better signal integrity to allow for higher bandwidth. In discussions with Intel, it was stated that large interposers likely work best for powerful chips that could take advantage of active networking, however HBM is overkill on an interposer, and best used via EMIB.

Akin to an interposer-like technology, Foveros is a silicon stacking technique that allows different chips to be connected by TSVs (through silicon vias, a via being a vertical chip-to-chip connection), such that Intel can manufacture the IO, the cores, and the onboard LLC/DRAM as separate dies and connect them together. In this instance, Intel considers the IO die, the die at the bottom of the stack, as a sort of ‘active interposer’, that can deal with routing data between the dies on top. Ultimately the big challenges with a multi-die strategy come with in thermal constraints of the dies used (so far, Intel has demonstrated a 1+4 core solution in a 12x12mm package, called Lakefield), as well as aligning known good die for TSV connections.

Discussing Strategy: Intel's Engineering Approach

Intel is clearly committed to its chiplet strategy where it currently stands with FPGAs, bringing other aspects of Intel’s technology to the platform (such as AI), and developing features such as EMIB into it. Ramune made it clear that if Intel’s customers have their own third party IP in use with the FPGA, they will need to either provide the EMIB capable chiplets themselves or work with Intel’s foundry business to enable them, and then the packaging will be done solely at Intel. While Intel has offered connectivity standards to the open market, the specific EMIB technology that Intel uses is designated a product differentiation, so customers will have to engage with Intel in order to see their IP in the packaged product.

When it comes to chip stacking technologies like Foveros, Ramune reiterated some of the key areas of the technology that are being worked on, such as thermal limitations as well as die size and efficient stacking. One of the key changes was described as ensuring that when dies are stacked that known good dies (i.e. those that pass yield tests) are used, which requires bare die testing before assembly. Some of Intel’s previous development processes have needed to be adjusted in order to assist for technologies like Foveros and products like Lakefield, as well as other products in the future. Ramune did state that Intel has not specifically looked into advanced cooling methods for Foveros type chips, but did expect work in this field over the coming years, either internally or externally.

When discussing products in the future, one critical comment did arise from our conversation. This might have been something we missed back at Intel’s Architecture Day in December last year, but it was reiterated that Intel will be bringing both EMIB and Foveros into its designs for future graphics technologies. As one might imagine, no further comment was offered regarding the scale, thermal performance, interconnect integration, or anything along those lines, but it is clear that Intel is looking into multi-die graphics technologies. One might by cynical and state that Intel is already using both EMIB and Foveros in graphics today: Kaby G uses EMIB, and Lakefield has an integrated Gen11 graphics on Foveros. However these are two separate products, and our takeaway from the conversation was that both of these technologies might be on a singular product in the future.

This could take many different forms. A central control chip connected by EMIB to compute chips, using Foveros to increase the amount of onboard cache each of the control chips has. Compute chips could be daisy chained by EMIB. The control chip could need a central DRAM repository, either by Foveros or via EMIB. These technologies are like Lego – go build a spaceship, or a ferris wheel, or a GPU.   

Splitting GPUs into chiplets isn’t a new idea in the realm of ideas, however it is a concept that is difficult to conceive. One of the key areas of shuffling data around a GPU is bandwidth – the other is latency. In a graphics scenario, the race is on to get a low frame rendering time, preferably below 16.67 milliseconds, which allows for a refresh rate of 60 Hz to have a full display frame inserted on every refresh cycle. With the advent of variable refresh displays this has somewhat changed, however the main market for graphics cards, gamers, is heavily reliant on quick refresh rates and high frame rates from their graphics. With a multi-chip module, the manufacturer has to consider how many hops between dies the data has to perform from start to finish – is the data required found directly connected to the compute chip, or does it have to cross from the other side of the design? Is the memory directly stacked, or is there an intrapackage connection? With different memory domains, can the data retain its concurrency through the mathematical operations? Is there a central management die, or do each of the compute chiplets manage their own timing schema? How much of the per-chiplet design comes from connectivity units compared to compute units?

Ultimately this sort of design will only win out if it can compete on at least two fronts of the triad of performance, cost, or power. We already know that multi-die environments typically require a higher power budget than a monolithic design due to the extra connectivity, as seen with multi-die CPU options in the market, so the chiplets will have to take advantage of smaller process nodes in order to eliminate that deficit. Luckily, small chiplets are easier to manufacturer on small process nodes, making it a potential cost saving over big monolithic designs. Performance will depend on the architecture, both for raw compute, as well as the interconnect between the chips.


NVIDIA MCM GPU Diagram from ISC '17

We have seen several research papers discuss the concept of a multi-die graphics solution, such as this one from NVIDIA, and you can bet your bottom dollar that everyone involved in high performance graphics and high performance compute is looking at it. Given the fact that a compute platform has fewer restrictions than a graphics platform, we might expect to see a multi-die solution there first.

The other element to our discussion was a reaffirmation of comments made previously by Dr. Murthy Renduchintala, Intel’s Chief Engineering Officer and Group President of the Technology, Systems, Architecture and Client Group. Ramune stated that chiplet technology and packaging technologies are designed to run asynchronously to Intel’s current manufacturing processes. Ultimately the goal here is to apply the technologies to the process currently available, rather than fixing development and tying development to a single node strategy. As we’ve seen with how Intel’s 10nm development has progressed, this disaggregation of product and technology is going to be an important step in Intel’s future.

What We Do Know About Intel's Xe GPU Line

Intel has already stated that after Gen11 graphics, which will be featured in its future Ice Lake consumer processors paired with the Sunny Cove microarchitecture, that we will see its Xe graphics products come to the market. Xe will range from integrated graphics all the way up to enterprise compute acceleration, covering through the consumer graphics and gaming markets as well.

Intel stated at the time that the Xe range will be built on two different architectures, one of which is called Arctic Sound, and the other has not yet been made public. The goal is to create a platform for Xe relating the hardware, the software, the drivers, the platform, and the APIs all into a single mission, which Intel calls 'The Odyssey'. Introducing EMIB and Foveros technologies as part of the Xe strategy seems to be very much part of Intel's plan, and it will be interesting to see how it develops.

Beyond Intel's Core Technologies

Intel’s recent push into graphics technology is well known. The company has hired Raja Koduri from AMD, Jim Keller from Tesla, Chris Hook from AMD, and a number of high profile tech journalists and AMD’s GPU marketing manager to help develop its discrete graphics offerings. Even as of a couple of days ago the company wasn't quite done with their hiring spree, picking up GlobalFoundries' Corporate Communications director to assist in its manufacturing process and packaging technologies disclosures. While 10nm is being fixed, the company is clearly trying to get the attention onto its new product areas, and its new capabilities – we’ve seen new packaging technologies and core configurations at Intel’s Tech Summit in December, and an array of enterprise products other than CPUs at the company’s recent Data Centric launch event. As Intel develops both its chiplet strategy and its packaging implementations, we should expect the expertise to permiate through Intel's product portfolio where it expects to help those products gain an advantage. Lakefield is a key example of this, offering Core, Atom, and Gen11 functionality in a tiny chip and under 7W for small form factor devices.


Lakefield, built with Foveros

Many thanks to Ramune Nagisetty and her team for the call last week, and some insight into a part of Intel we’ve not normally had contact with before. I’m glad that Intel is starting to open up more into new areas like this, and hope that it continues in the future.

Related Reading

Comments Locked

117 Comments

View All Comments

  • mode_13h - Saturday, April 27, 2019 - link

    Without defining day 1, that's a tautology.

    You're also ignoring the fact that GPUs are increasing dependence on the cache hierarchy, increasing cache sizes, and increasing coherence support. AMD's Vega has coherent L2 and optionally coherent L1. From the Vega Whitepaper (linked above):

    "“Vega” 10 is the first AMD graphics processor built using the Infinity Fabric interconnect that also underpins our "Zen" microprocessors. This low-latency, SoC-style interconnect provides coherent communication between on-chip logic blocks"

    Also, as I cited above, the L1 cache in Volta was promoted to be much more CPU-like:

    "Integration within the shared memory block ensures the Volta GV100 L1 cache has much lower latency and higher bandwidth than the L1 caches in past NVIDIA GPUs. The L1 In Volta functions as a high-throughput conduit for streaming data while simultaneously providing high-bandwidth
    and low-latency access to frequently reused data—the best of both worlds."

    So, to disregard changes in GPUs' cache organization and utilization so dismissively seems baldly disingenuous. I take it as a sign that you've nothing better to offer.
  • mode_13h - Wednesday, April 24, 2019 - link

    > CPUs have both an expectation and practice of computation to computation communication while GPUs do not and instead have an expectation and practice communication generally only between computational phases (a complex way of saying that GPUs are optimized to read from memory, compute in silos, and write back to memory).

    The funny thing about this is that it actually argues *for* NUMA in GPUs and *against* NUMA in CPUs. So, thanks for that.

    But it's also an overstatement, in the sense that CPU code which does too much global communication will scale poorly, and GPUs (and graphics shader languages) have long supported a full contingent of atomics, as graphics code stays a bit less in silos than you seem to think.
  • ats - Wednesday, April 24, 2019 - link

    Um, then you don't understand it. Every shader block basically needs access to every memory blocks to maintain performance. Doing that in NUMA introduces massive bottlenecks.

    You start using a lot of atomics in GPU code, it comes crashing to a halt pretty quickly.
  • mode_13h - Wednesday, April 24, 2019 - link

    You clearly know nothing about graphics programming. You can't design an architecture to solve a problem you don't understand.

    Those who introduced atomics in shaders clearly knew what they were doing and the corresponding performance impacts, but sometimes there's just no way around it. It's also laughable to suggest that there's no locality of reference, in graphics. In particular, to say that right after claiming that GPUs "compute in silos", is quite rich.

    Keep 'em coming. I'll go make some popcorn!
  • mode_13h - Monday, April 22, 2019 - link

    The funny thing is that the only example we really have of a multi-die GPU is Nvidi's ISC 2017 paper, cited in the article:

    https://images.anandtech.com/doci/14211/MGPU.png

    Now, you can try to argue that Nvidia doesn't know what they're doing... but I wouldn't.

    Scaling GPUs from 1-4 chiplets is good enough... at least for a first generation.
  • Rudde - Thursday, April 18, 2019 - link

    You really have to make the memory shared between all chiplets. That is, less theoretical nVidia mcm (the picture in this article) and more Epyc Rome. Rome has a central io-hub that access memory. nVidia outlined a NUMA architecture.

    AMDs approach is probably too slow for gaming purposes, but could turn out to be a nice compute card.
  • ats - Thursday, April 18, 2019 - link

    Shouldn't be too slow. You are adding a handful of latency to what is at best a 100+ ns latency path and upwards of 1000s of ns. In fact the asymmetrical design has a long history in graphic hardware design dating back decades. You only start to run into issues with symmetrical designs where every chip has to communicate with every other chip due to distributed memory.

    This whole too slow for gaming purposes is just laughable. You are realistically dealing with loaded memory latencies well over 100ns in a graphic chip doing a gaming workload. The die crossing is going to add single digit latencies to the path overall. Its not going to have any effect on something that is measured in ms esp since the whole design of a graphic shader pipeline is heavy designed from inception to be latency insensitive by necessity.

    And honestly, in both cases of gpus and server cpus, Rome's design makes much more architectural sense than the previous epyc designs that were primarily constrained to allow 100% reuse of the consumer part in the server market.
  • mode_13h - Saturday, April 20, 2019 - link

    The issue with shuffling data between dies is not latency - it's power and bottlenecks.
  • mode_13h - Saturday, April 20, 2019 - link

    I should qualify that as concerning GPUs, BTW.
  • ats - Sunday, April 21, 2019 - link

    Bottlenecks isn't much of an issue given an EMIB interconnect. Power will increase slightly, but could largely be made up from not having to deal with large die effects.

Log in

Don't have an account? Sign up now