The original design consisted of over 30 blocks with a hierarchical device count of around 30,000 (about 200,000 flat).
After the first migration, business opportunities arose requiring the same SerDes IP to be moved to two further different 40nm processes.
Design Environment: 65nm Serdes has been designed in Cadence Virtuoso XL, using the 65nm foundry provided PDK (technology files, pcells, etc). Target 45nm migrated result should be restored into a Cadence Virtuoso XL database environment using the new target 45nm foundry provided PDK. All the Cadence database specific object need to be maintained (pcells, via cells, connectivity, etc.)
The main changes : There were many changes in design rules between the two processes: Dummy poly insertion and pitching being the most challenging. In addition, all devices were resized and the new sizes needed to be gathered from the netlist (netlist-driven migration).
A layout clip showing devices after automatic dummy poly insertion and gate gridding (enforcing strict poly pitch)
The main requirements:
- ∑ The basic topology needed to be preserved.
- ∑ The design hierarchy needed to be preserved.
- ∑ Matching devices and routing should remain as such. Other topology sensitive features such as symmetry, alignment, etc, should be maintained.
- ∑ The migrated SerDes should be LVS clean. This includes both connectivity as well as matching the new schematic device sizes.
- ∑ The flow should allow quick sizing and ECO iterations
- ∑ The migrated SerDes should have minimal remaining DRC violations requiring manual fixup.
- ∑ Maintain data integrity: Virtuoso data structure and all objects kept intact
The schedule: The productivity goal was set to at most 1/5 of original layout time. (minimum 80% effort and time savings) .
Quick Initial Prototyping: One of the first goals was to figure out the effective scaling factor of the migrated IP. This is one of the clear benefits of automated migration which allows designers to try multiple scaling and sizing scenarios based on the target technology devices and rules. Many experiments can be done quickly and very early on, to figure out the effective scaling, footprint, effect on performance, and other consequences of each scaling and sizing scenario.
How the migration was addressed: The entire Serdes IP comprises over 30 main blocks, each having up to 10 level of hierarchy and an average of 1000 devices (hierarchical count).To facilitate concurrent layout-circuit optimizations with quick turn-around time, a block-by-block execution method was chosen.While performing each block at a time, the migration flow also takes care of global (top) level metals and over-the-block supply rails to make sure that the blocks are properly positioned and connected within the top level. Most of the blocks are custom handcrafted using device level programmable cells (Pcells) of the original 65nm foundry PDK . These Pcells as well as other symbolic structures had to be mapped to and substituted by similar devices and structures from the target foundry 45nm process. The migration software uses this mapping to generate the new devices and objects using the right parameters, make room for each of their instances, place them and connect them in the migrated layout. A few blocks also used digital control sections that were implemented using a specific logic cell library shared among all the blocks. This common logic cell library was also migrated to the 45nm target process rules and maintained as a common library across the entire IP, and then used during the block-level migration.
Device Sizing : Final sizing for devices was not fully determined before starting the project. Initial sizing was done based on schematics and then was subsequently refined after layout extraction and circuit validation. This is where having an automated migration flow makes a huge difference as once the flow is in place, all subsequent sizing and tuning layout iteration are run very quickly ( in less than an hour). Using this block-by-block approach enabled having a virtual ďassembly lineĒ pipeline of blocks in different stages of migration and tuning and accelerated the overall project significantly.
Results: The SerDes migration was delivered on-time. LVS was virtually clean (there were a few minor issues due to incompatibilities between the PDK libraries). DRC quality was better than expected, with most blocks having under 50 DRC violations left. In fact the project exceeded its initial productivity goals: each block takes only minutes to run, and the last few remaining DRC errors took only a few hours to clean up. The overall effort, including the manual layout cleanup, took less than 1/10 of the original layout time (90% effort and time savings).
Automatic migration preserves symmetry and matching. Same clip before and after migration.
65nm (green) versus 45nm (purple)
Why Sagantec: The IP design team looked at different commercial solutions for Analog/MS migration and evaluated a few alternative offerings from multiple EDA vendors. While other vendors addressed some aspects of the problem, the customer found Sagantec as having the most complete solution and one that most effectively addresses the size, complexity and the overall layout effort productivity goals. Another significant factor was supporting and maintaining the Cadence Virtuoso database and objects which was important to the design team. Overall the Sagantec approach seemed the most practical and least disruptive to the teamís current design flow and tools.
Consecutive Successes: Following the success of this migration project, the IP design team decided to use the same flow to migrate this IP to two other 40nm processes (using different PDKs and technology files respectively). Each of these subsequent process migrations was also a success, completed on-schedule and exhibited similar productivity gains. Overall this migration methodology and flow enabled the team to respond quickly to new business opportunities and process requirements, leveraging their original design investment and minimizing their efforts per each process implementation.
Custom IP migration: Moving a complex custom IP block from one process to a different process can either be done by an experienced layout team or using an automated flow that handles almost all of the work automatically, such as Sagantecís migration technology. For migration to older process nodes or between similar processes, it is possible that a shrink followed by manual fix-up of violations would work, but in advanced process nodes and when the processes have very different rules, the number of violations generated can be overwhelming and impractical for such approach. The alternative would be a complete redesign, which in this case would be prohibitively expensive in both schedule and resources required. In addition to licensing migration software, Sagantec has also experienced application engineers that can do migrations as a service to minimize turn-around time, get the highest quality results and maximize ROI.
Sagantec Demo Suite Registration
Note: To read/write comments you must be logged in