IC Packagers: Adding Multiple Component Instances without a Schematic

More package designers these days, with the increasing component counts and more complicated electrical constraints, are shifting to using a front-end schematic capture tool. As with IC and PCB design, this allows for verification between the logical design and the physical layout implementation. This is, without a doubt, the best and most comprehensive way to manage these multi-die package substrates. Especially if you're adding discretes, RF devices, or other parts beyond just dies and the carrier package.

There remains a large volume of designs that are a packaging of a die (or die stack) to redistribute the signal pattern out to BGA balls which are configured for routing at the PCB level. In these cases, with the netlist being driven by the die components out to the BGA, the effort of creating a schematic might be viewed as extra work. Since the Allegro Package Designer tools allow you to create, manage, and modify your netlist and connectivity directly in the layout database, this backend-flow remains uniquely available to our APD+ community.

One aspect of the above bears some further consideration, however. That is how to manage situations where you have multiple instances of the same die component (e.g. memory dies in a stack). While these may come in the form of a die text file, the text file describes the definition and, at most, the netlist for just one of the components. What are the alternatives for defining the additional instances in the package design, then, and what advantages does each offer?

Adding Each Instance as a Unique Definition 

I’ll admit. This is probably the most common way to get the job done and simplicity is its own reward! It is never my recommendation, however. While it is quick and easy – just use the Add - Standard Die - Die Text In Wizard command multiple times while specifying a new device name and reference designator with each addition, the results are not ideal for a few reasons.

First and foremost, this will cause confusion in the bill of materials later. The BOM will list 10 different parts, each with one instance, instead of 10 instances of the same part. If they are truly the same die, that’s not right. Someone on the team will have to recombine these into the parts list for ordering purposes.

Beyond this, it makes mistakes more likely. A simple scenario: you need to make a change to the padstack for one or more of the pins. Say pin #1 for the simplest case. When each instance is its own copy of the definition, you must make this edit 10 times. Or, you replace the padstack on each instance – meaning dump libraries and other commands will use the original definition and NOT see the modified padstack assignment.  

If you need to bring in an ECO of that component, you’re going to need to repeat the process, you guess it, ten times. Who wants to do that? What if you miss one of the instances – will you notice before you go to manufacturing?

Adding Instances of an Existing Definition

To add more definitions of an existing definition when you don’t have a schematic, the best mechanism is through the Logic - Edit Parts List command. This tool allows you to add, delete, and modify components in the active layout.

All you need to do is select the line in the table for the device (component definition) you need more instances of. Then, in the Refdes field at the bottom, add the additional designators for the new instances. Don’t forget to press “Add” when you’re finished! You’ll see the quantity in both the table and the bottom section of the form update to reflect the new count. Follow along with the video above if it’s easier the first time through.

All the parts that you add here will initially be unplaced. Use the Place - Manual command to put them down in the layout where they belong.

One reminder: The Edit Parts List tool is geared to display reference designators in a compressed format, with U1-3 indicating U1, U2, and U3. Should you have hyphens in any of your reference designators, or just want to see all the values as discrete items, set the edit_parts_expand_lists variable in your user preferences.

Following this flow, if you need to make a change to the pin #1 padstack, use the symbol edit application mode. Select pin #1 of any of the instances of the definition, make the update, and all instances will immediately be updated to reflect the change. Because the change is made to the definition directly, there is no possibility for any of the instances to be out of sync with the definition (and, if you dump libraries, the padstack change will reflect in the library DRA file that is generated).

Those of you out there who are doing co-design of a die with multiple instances… you can use the same flow! Place all the instances of the die and, when you make changes through the co-design flow, the XDA file you send back to the IC design team will be in sync with all the dies (and if you bring in an ECO update from them, all the instances get updated, too).  

What Do You Think?

In both flows, of course, you’ll need to manage your net assignments to each of the instances. For that reason, please consider moving to a schematic front-end tool. It really WILL make your life that much easier! Cadence offers some incredible front-end solutions for your package substrates; they are well worth checking out if you’ve not used them before.

Even without these, the Cadence package layout tools will support whatever netlist file format you have as a source. There’s always the Logic menu commands for assigning the nets interactively as a last resort.

Do you have a reason to still prefer individual definitions for each component instance? If so, we’d love to hear from you!