Friday, June 13, 2014

Simultaneous Multi-Chip 3D-IC Physical Verification


In my last post, I hinted that single chip 3D-IC physical verification was an incremental change to design.  Today I'll explore a disruptive change: verify the multiple chips in a single DRC and LVS run.  There are many practical reasons why this is not done (hard to merge libraries, division of design activities, foundry support, etc) - but many people have asked about it - so here are my thoughts on how it could be done.  Keep in mind - I am not aware of anyone making any serious attempts to do this.  If you are aware of any (or you want to try to do this), please post a comment or email me.

Why Do Simultaneous 3-D Design?

With traditional monolithic designs, system designers must make careful decisions about which circuits go on which chips, and expensive I/O circuits and off-chip interconnects must connect related functional circuits.  The promise of 3D-IC is to significantly reduce the cost of communication between chips.  Taking this to an extreme, the chip-abstractions could go away, and during system design, circuits could be moved fluidly between chips.  This is clearly an extreme, as even the small TSVs still have some cost, but it is now realistic to keep the clocks on the different chips synchronized so that connections between the chips can also be synchronous with internal clocks.

Merged 3D-IC Design Process

Let's create a theoretical chip design process.  I’m leaving a lot of questions unanswered, including placement, routing, and timing.  Perhaps I’ll circle back to providing some thoughts on that if there is enough interest.  From a physical verification perspective, we care about:
  • Use interposer 3D-IC design style
    • Common node for functional chips (20nm, 8 metal)
    • Cheaper node for interposer (180nm, 3 layer metal)
  • Single Verilog defines the entire system
    • 20nm functional standard cell library (with SPICE)
    • 180nm interposer buffer library (with SPICE)
  • The individual chip layouts are merged to a single layout
    • Using interposer origin
    • Chip instance origins aligned to interposer
    • Uniquified interposer mask layer numbers

Layout Merging


The chips layouts are instantiated against the interposer coordinate reference


The layers from each chip type could be stored in a single layout file.

DRC

Because we have two processes (20nm and 180nm), we need start with two DRC decks, and we need to somehow 'merge' them.  However, its not as simple as concatenating them.  Because the layer numbers have changed for the Interposer, we need to update the layer assignments in the 180nm DRC runset.  There may be other considerations when merging the runsets as well.  For example, any 'density' checks on the functional chips need to be made aware that there are regions of the merged layout that are not part of the functional die (see image below).  Another consideration is layer naming in the runset.  Depending on how the runsets are written and syntax restrictions of the runset language, name collision is possible (for example, both technologies probably refer to first metal as "m1").  In that case, the layers will need to be renamed with some convention (ie prefixing).

LVS

Similar to the process described for DRC, the LVS can be merged.  The basic connections inside each chip can be unchanged, but we need to include the statements describing how the nets on the individual chips are interconnected.  Merging LVS runsets will be much more complicated than with DRC.  Since we desire 1 netlist as a result of the procedures executed by each runset, the 'netlisting' phase must be merged.  That means all of the extraction steps prior to netlist (connect + extract) need to be merged.  Next, we need to build a combined netlist. Finally the post-netlist (compare) steps must be merged.  The figure below shows how these steps can be roughly mapped from the traditional separate LVS jobs to a single combined LVS job.

Summary

What I've tried to show here is that simultaneous 3D physical verification is possible, but that with existing tools, manual merging of the data, DRC, and LVS runsets are required.  I invite any comments on what I'm suggesting here, and if anyone wants to take this beyond intellectual curiosity, by all means, post a comment or shoot me an email.