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



View All Comments

  • mode_13h - Saturday, April 20, 2019 - link

    I wouldn't be so dismissive of AMD's point. ISVs don't like multi-GPU, and a chiplet strategy looks a heck of a lot like that.

    And you really can't put all your memory controllers in one chiplet - that would be a huge bottleneck and wouldn't scale at all. GDDR already uses narrow channels, so it naturally distributes to the various chiplets.

    The way to do it is to distribute work and data together, so each chiplet is mostly accessing data from its local memory pool. Using Foveros, you might even stack the chiplet on this DRAM.
  • ats - Sunday, April 21, 2019 - link

    Not really. A multi-die strategy only looks like a multi-gpu strategy if the individual chiplets are exposed.

    And everyone already puts all their memory controllers in 1 die, fyi. You want them all in 1 die to reduce cross talk between dies. The workload is such that distributing the memory results in massive communication overheads.
  • mode_13h - Monday, April 22, 2019 - link

    Hiding the fact that cores are on different dies doesn't make bottlenecks go away - it just hamstrings the ability of software to work around them.

    And when you say "everyone already puts all their memory controllers in 1 die", who exactly is "everyone"? So far, the only such example is Ryzen 3000, which is a CPU - not a GPU. GPUs require an order of magnitude more memory bandwidth. Furthermore, this amount must scale with respect to the number of chiplets, which doesn't happen if you have one memory controller die.
  • ats - Tuesday, April 23, 2019 - link

    Who's hiding cores? No one cares where the shader blocks are as long as they are fed.

    And who is everyone? Nvidia and Radeon. We're talking GPUs here, fyi. 1 memory controller die is fine, it has rather easily connect to 512-1024 GB/s of bandwidth because existing GPUs already do that.
  • mode_13h - Tuesday, April 23, 2019 - link

    You said "A multi-die strategy only looks like a multi-gpu strategy if the individual chiplets are exposed", which means you aim to obscure the fact that GPU cores aren't all on the same die. That's what I meant by "Hiding the fact that cores are on different dies".

    Anyway, I guess you're right and the industry is wrong for going NUMA. They are all idiots and you are the true genius. You should not waste your precious time and talent on here. Instead, go to Nvidia and tell them that they are on the wrong track. Then, hit up AMD and inform them that Wang (and probably also Lisa Su) doesn't really know how to design GPUs and you will step in and do it for them.
  • ats - Tuesday, April 23, 2019 - link

    Um, by your standard of hiding cores, every GPU on the market hides cores. Programmers just generate a workflow, they don't need to know how many shader per SM or how many SMs per die.

    NUMA is and always has been a last resort. Having designed multiple NUMA systems that have shipped for commercial revenue from multiple different vendors and covering 3 different ISAs, I'm fairly confident in saying that. NUMA is never a goal and it is always something you try to minimize as much as possible. Instead it is a compromise you make to work within the given constraints.

    For GPUs with chiplets, those constraints that would require a NUMA design largely don't exist. And a Rome style design is actually the better path for the high end, enthusiast, and enterprise/hpc markets. It allows you to push the technology edge for the actual compute components as fast as possible and keeps costs down while allowing you to use trailing edge process for the mem/interface component and should, give large die effects on freq/power, allow a lower power and over all more efficient design. This is largely enabled for GPUs by the rather limited (to non-existent) shader to shader communication requirements (which is after all the primary computational model advantage of GPUs vs CPUs).

    Let me repeat that somewhat for emphasis: 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).
  • mode_13h - Wednesday, April 24, 2019 - link

    > every GPU on the market hides cores.

    Well, that's the problem Wang cites.

    > they don't need to know how many shader per SM or how many SMs per die.

    Not if they're assuming a SMP memory model. Again, that's a problem, to the extent they control where things execute and where memory is allocated. I know OpenGL doesn't expose those details, but I know far less about Vulkan and DX12.

    > GPUs ... have an expectation and practice communication generally only between computational phases

    You're living in the past. Also, you underestimate how much communication there is between the stages of a modern graphics pipeline (which, contrary to how it may sound, execute concurrently for different portions of the scene). Current GPUs are converging cache-based, coherent memory subsystems.

    (see "Enhanced L1 Data Cache and Shared Memory")

    And from https://en.wikichip.org/w/images/a/a1/vega-whitepa...

    "To extract maximum benefit from Vega’s new cache hierarchy, all of the graphics blocks have been made clients of the L2 cache."
  • ats - Wednesday, April 24, 2019 - link

    Yeah, I've read those. They don't support your argument nor do the actual programming models used support your argument. The second you try to treat GPU memory as dynamically coherent, they slow to a complete crawl. Reply
  • mode_13h - Wednesday, April 24, 2019 - link

    You missed the point, which is that whether you like it or not, GPUs are adopting a cache-based memory hierarchy much like that of CPUs.

    Of course, they *also* have specialized, on-chip scratch pad memory (the Nvidia doc I referenced calls it "shared memory", while I think the operative AMD term is LDS). I don't expect that to disappear, but there's been a distinct shift towards becoming increasingly cache-dependent.
  • ats - Thursday, April 25, 2019 - link

    GPUs have had a cache hierarchy from pretty much day 1, fyi. And no they are not adopting CPU like coherency. Reply

Log in

Don't have an account? Sign up now