IC Packagers: Why You Can’t Start a Co-Design Die in Allegro Package Designer

Let’s investigate this question today, as I’ve been asked a few times over the years by curious designers. The question is one of wanting to start from the Allegro Package Designer environment and begin prototyping a die pin layout. If you know the number of signals and the basic power/ground ratio, this gives you a pin count and distribution. At its very basic, this is enough to start doing feasibility studies on potential bump patterns and optimizing things for the IC Package the die will eventually go into.

The History of Co-Design in the Tool

The ability to co-design your IC’s bump layout has been in the Allegro Package Designer tools for many years. In the very beginning, it used LEF/DEF and then Open Access as the database exchange format. In both cases, the duty fell to the package designer to attempt to extract the data he needed – just the external bump and passivation opening locations, plus the overall component dimensions – from the IC design data.

On its surface, this is simple. If everything uses BUMPCELL class macros for the bumps, then identifying them is easy. But, as we know, not everyone structures their LEF macros in the same fashion. Depending on the design, the bumps or passivation openings could be multiple layers deep inside of the hierarchy. For the package layout engineer, locating them becomes a very difficult task.  

Enter the XDA format. This is a plaintext XML-based file designed specifically for exchanging co-design die information. It can hold the critical information needed by both design teams without getting bogged down by the details. Instead of the entire LEF macro library, only those used for bumps or for macros with integrated pads need to be listed, greatly reducing the volume of elements. And, since it is separate from the IC macros themselves, elements of the macro that are on lower metal layers and not relevant to the co-design flow itself can even be suppressed.

How do I know this bump pattern is good? Hmmm....

Then, at the top level, none of the core cells or internal routing layers need to be passed across. Unless the package designer wants to see the RDL routing on the top metal layer in the die to make more intelligent trade-offs for pin moves and swaps, nothing below the top metal layer is needed in the package. Abstracting out the millions of core cells, the internal routing, and so much more takes a huge, complex IC design and compiles it down to just the information needed by the outside world.

Because the XDA is written from the IC design tool, the IC layout engineer is also able to identify the bumps that are external interfaces. This takes the job off the shoulders of the package designer, who often lacks the context to make those inferences.

With XDA, then, a format that both sides could understand and communicate changes with (efficiently) was available for the first time.

Wait! That Doesn’t Answer My Question!

Not directly, it doesn’t. But, as the package designer, what are some of the things you don’t know about the IC design? That’s right! You don’t know the netlist, the available macro cells (and their geometries) for the bumps or passivation openings. Neither do you know what signals or signal types might be combined into hard macro blocks where the pins have a pre-defined, fixed pattern.

Without this information, many of the bump assignments you make might be completely invalid, illegal even, in the IC design. You’d be potentially wasting time, not saving it!

With the IO buffers for context, this is probably not an ideal bump pattern…

That, ultimately, is why the Allegro product doesn’t allow you to start a new co-design die from scratch. At minimum, you need to understand the stack-up and available macros for the IC design. Ideally, you’d get a netlist, too, even if everything started out as unplaced. By knowing you’re working within a context of what is allowable, the chances are much greater that your proposal will be reasonable to the IC design team. No, they probably won’t take it 100% as-is with no changes (Are any of us that lucky – especially THIS year???), but if it is close, and the adjustments they need to make can also be done in the context of the package layout, then both sides are much closer to getting what they want.

It’d be Nice for the IC Designer to See the Package Context, too…

Yes, that would be nice. And, thankfully, it’s available to you today!

The package overlay file is only available for dies being co-designed. Context is needed in terms of IC design accuracy and netlist, among other things. But, since we’re talking co-design flows today, this should be no problem for you.

When you run this command, you can choose the elements of the package design which the IC designer needs to understand the impact his changes will have on your layout. Whether it’s bond wires and fingers or vias and clines, you can pick exactly how much you need to transfer across. This data will be transferred in a separate XML format from the co-design die XDA, as it contains much different information.

Taking it Home

So, the answer is much simpler than you thought, isn’t it? You may bring an empty XDA into the tool with nothing but the bump macros, layer stack, and netlist to start. But, you need that much data at a minimum to ensure that what you do has a reasonable chance of being accepted for both you AND the IC designer.