Brian Jackson Introduces a Mystery Product at IMAPS (Shh, It's OrbitIO)

I have been criticized in the past for calling OrbitIO the "red-headed stepchild" of the Cadence product line. I think I shall have to improve my positioning and simply call it "ahead of its time". OrbitIO is the cockpit for all things to do with 3D-IC, 2.5D-IC, system-in-package (SiP), chiplets, and anything to do with designs where more than one die end up in the same package. Until the last few years, these sorts of advanced packaging technologies were in limited use, and so OrbitIO was in limited use. But in the last five years or so, interest in assembling systems this way has become really hot. Talking of "hot", a year and a half ago I wrote a blog post HOT CHIPS: Chipletifying Designs that summarized all the designs from 2019's HOT CHIPS that had more than one die in a package. There were a lot. I encourage you to at least glance over that post if you haven't seen it before.

There are obviously many drivers for this sudden proliferation of SiPs, but I think the biggest one of all is that doing monolithic integration of a system on a single die has become increasingly unattractive because:

• Some designs are too big for a single reticle, so you can't do it
• Some things (analog, RF) are impossible to do in the most advanced nodes, so you can't do it
• IP availability (e.g., SerDes or DDR or PCIe) may not yet be available when you need them, so you can't do it yet
• It makes no sense to design an entire system in an advanced node when only some parts of the system require it or can take advantage of it, so it's too expensive to do it
• Small die improve yield, so it's too expensive to do it
• You can't get enough memory on the monolithic die, so you can't do it

All of this means that OrbitIO has done a Wayne Gretsky and gone where the puck will be. It is full of all the capabilities required for doing these designs that are leveraging advanced packaging as opposed to monolithic integration. OrbitIO is no longer ahead of its time, it is in the right place at the right time.

IMAPS

There is a conference on all this known as IMAPS. That actually stands for International Microelectronics Assembly and Packaging Society. Officially, the conference is actually called the International Conference on Device Packaging. But everybody calls it IMAPS.

One of the presentations was by Cadence's Brian Jackson, System Level Design Assembly and Management for 3D-IC Architectures. The rules of the conference are that "no product adverts are allowed". So Brian gave an entire presentation on OrbitIO without mentioning it. I guess complete invisibility makes "red-headed stepchild" a compliment. Actually, he structured his presentation as a tour of the requirements for an ideal tool for pulling together this sort of design. I didn't know about the "no product names" rule, so I was fully expecting that towards the end, Brian would go "ta-da" and introduce OrbitIO, but he was not allowed to do that. Well, this is a Breakfast Bytes blog post, so I'm under no such limitation. Let me tell you about what Brian said, and then give you an introduction to OrbitIO.

One top-level message is that it is no longer really feasible to design all the different pieces in separate design tools, and then use ad hoc approaches to pull everything together. We need:

• System design aggregation, assembly planning, and management
• Manage logic and physical relationships between the various die and the package
• TSV creation and power distribution planning
• Integated world-class implementation tools
• System-level analysis to verify the entire design

System Design Aggregation and Management

Designers need to be able to assemble the complete design, made up of all the chips or chiplets, the package. So that means things like the 3D stack(s), and top-level Verilog netlists for the entire design. There needs to be a "golden netlist" that captures all the connectivity and which can be used for, among other things, driving implementation and final verification.

Each of the individual pieces of the design needs to implement its share, but at the top level, the global netlists need to be managed to correctly connect all these components. This requires being able to import and export each die and associated system data.

Another wrinkle is designing and optimizing passive interposers (no transistors on the interposer) and package. This means optimizing the bottom bumps/balls and optimizing the assignment, to improve routing. Finally, exporting designs ready for implementation.

If this all seems a bit hand-wavy, that's because every design is very different, and there are a number of different approaches to doing the design. Bottom-up, where the die are designed and the top-level connectivity added later, or top-down, where all the different implementations tools receive their marching orders from the top-level golden schematic, to various hybrid approaches. There is also the reality that some die may exist (especially if we enter the true chiplet era), others may yet have to be completed, or perhaps even started.

Manage Logical and Physical Relationships between Die / Package

The design stacks can get complex, ranging from simply stacking die on top of each other, to embedded substrates and bridges. But one thing needs to be kept track of accurately: if a die on top contacts to a die underneath, no matter what the connectivity technology, all the connections need to line up correctly. If you move a connection, it has implications. If you move a whole die, or rotate it, then a lot of things need to move. Additional complexity comes from multiple pad sizes, pad shapes, and high-current multi-pad macros.

One of the most important features to provide is the capability to view and optimize system connectivity across the design, and maintain it as die are moved and flipped. System connectivity can be optimized based on connectivity, and bump creation, especially for power and ground, should be handled automatically. Nobody wants to manually have anything to do with the thousands of bumps that are often involved or even have to think about the ball assignment for the package.

TSV Creation and Power Distribution Planning

Through-silicon-vias (TSVs) are naturally very invasive. Not only do they form part of the netlist connectivity, they affect the layout of the die that they are punching through, requiring keep-out regions. In fact, they don't just have physical impacts, they can impact the performance of transistors that are nearby due to inducing stress during their manufacture.

In a design using TSVs, there will be many TSVs that are used to deliver power and ground from the lower die to the upper die.

Since there are so many TSVs, when they are used, proper TSV planning is required up-front, and things like interconnect obstructions must be handled automatically. There are also reliability and signal performance implications of TSVs to be kept track of.

Integrated Implementation and System-Level Analysis

Implementation depends on the details of the design, but can include digital P&R, custom layout, RF layout, package.

There is then also the integrated analysis capability, which includes:

• Signal integrity
• Power integrity
• Thermal analysis
• IR drop analysis

Finally, physical verification and signoff.

OrbitIO

That was basically Brian's presentation, setting up requirements for the ideal tool for handling these complex multi-die designs. As it happens, of course, Cadence already has such a tool: OrbitIO. This post is way too long already, so I'm not going to attempt to give you a deep dive into its capabilities. I'll just say that it can do all the things that Brian laid out as requirements. Here's a picture of how it ties everything together. OrbitIO is the orange rectangle across the top, with tentacles descending into all the implementation and analysis tools.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.