Getting your tape-out done on time is hard, but can it be made easier? That was the main topic of Mentor’s Calibre Panel held at DAC 2018, attended by a few key players in IC design ecosystem: Bob Stear, VP of Marketing at Samsung represented the foundry side; from the IP side, Prasad Subramaniam, VP of eSilicon for R&D and Technology; and the fabless side, Satish Dinavahi, Sr. Director of Qualcomm India.
At the core of the discussion is the fact that a heterogeneous chip design includes many teams and dealing with evolving specifications. Project scheduling is then becoming one of the critical facets and should be more proactively done rather than reactively made to accommodate the changes. On the other hand, physical verification (PV) is a common segment for all and Mentor’s Calibre has been used as mainstream PV sign-off tool. As such, the panel is being presented with questions related to their tape-out experiences in this space. In the opening remark, Joe Davis, Product Marketing Director at Mentor shared that based on last year DAC customer survey, 50% of tapeouts are late across technology nodes and product types.
Half of tapeouts late, how does that ring to you guys?
Bob agreed that for larger projects which are taking one to two year design cycle that claim rings true. Satish concurred that design teams need to meet the many PPA requirements and absorb few days schedule shift (Qualcomm products mostly for mobile). From IP standpoint, Prasad acknowledged that a project starts with a given tapeout date, but eventually never meets that –instead, it will get adjusted as the project plan being refined. “And by the time you tapeout, it is surely not the same date,” he quipped. So the continuous improvement on the plan should be addressed up-front.
63% of late tapeout was due to PV/DFM. How does it sound to you?
Timing optimization cycle usually drives the schedule according to Satish. Designers will ignore physical convergence until late in the cycle while addressing PPA (performance, power and area) targets. The expectation is that any delay will get absorbed into PV. Prasad made two distinctions on the problem. He categorized them into FinFET and non-FinFET designs. “If I look on non-finFET designs, I would say most of the delay are in the timing,” he said. “The PV cycle … can be resolved quickly. So the delay can be absorbed in PV.” However it would be more complex for FinFET designs. Hence, if project allocation is done the same way as non-FinFET design, then any delay would not be absorbed as PV is more complex.
What sort of strategy do you put in place to deal with it?
Prasad said that we should anticipate the complexity of the chip by allocating adequate time for PV and technology. On top of that, his recommendation is to do verification as early as possible to disclose any potential technology related issues. It could be done at the block as the complete context may not be available yet. Usually, only 2-3 weeks is allocated for completing PV on same technology, but it might be 2-3 months for a new process node.
From the foundry standpoint, Bob mentioned that addressing the front-end first, looking beyond the sales/marketing guys, to understand the technology requirements and mapping that to your product plan with regards to design changes is key. Once you get further on that, try to bring the back-end up to speed on automation, parallelization, different algorithm on the EDA tools, etc.
Satish recommended two approaches: first, by assessing what went wrong out of multiple projects and reinstating option in the methodology and second, by including extra ECO cycles not only on timing but physical verification related issues.
With the long list of complex design rules such as in 7nm, do PD need to memorize all of that to get their job done?
Satish responded that it is hard for PD engineer to memorize everything. In the DRC, more than half are common and basic rules such as spacing or EOL rules are easy to understand. The more complex rules coming from new technologies such as DPT, forbidden rules are not easy to understand and might incur more time when first applied on a project.
Prasad supported the view that only through stumbling across the violation during verification, designer will learn what the rule violation and how to circumvent that in the future.
Custom layout engineer comes out with own method to be DRC clean as not wanting to be slowed down. What does management think and what kind of area penalty is OK?
“The good news about custom design is that because you design a smaller circuit, you have good visibility of everything: the netlist, the layout…the tools are very good,” said Prasad. So in his view, custom design is much better understood than chip design, so (DRC) problems could be easily tackled.
Satish assessment on his past tapeouts shows that flexibility to adjust area early in floorplaning stage is important as well as having PV capability so that DRC cleanliness can be ascertained when cells are moved to accomodate such adjustment. Increasing area by itself does not guarantee a DRC clean outcome.
In PV closure, how do engineers in custom vs digital flow attack the problem differently?
Prasad stated that IP/analog designers designed the block ahead of time and typically it comes DRC clean, although there might be issues at the chip level (i.e., block boundaries). So doing it early in the floorplanning stage for a chip-level mock integration can help address these boundary issues. The other area is metal fills at block and chip level are not necessarily aligned. Their interaction is not clean and this is the kind of chip-level surprises that need to be resolved.
Satish elaborated that IP/block abstractions takes place to reduce large design footprint during physical implementation stage. As such route optimization and subsequent PV is done on abstractions and polygons created during this process and it does not necessarily capture all the possible DRC when full-blown GDS2 design database is used. It is easier to deal with DRC signoff at custom level but harder at full-chip and interfaces of these IPs.
Bob felt that digital side has the benefit from automation compared with the analog side which requires iterative process and sensitive to finetuning.
Digital designer is usually automation driven in nature, focusing on PPA, not doing sign-off until the end. What is required in order to have PV sign-off getting the same way attention as power and clock tree synthesis?
Satish stated that having in-design sign-off within place and route is a good example, as designers like to operate in their own tool environment, which they are familiar with. “They don’t want to go to the GDS2 world, where lots of physical information exist,” he said. “It will enable them to run sign-off quality checks and help them to do sign-off closure.” Bob and Prasad overall agreed that having in-Tool verification will greatly help PV sign-off.