Any Tool. Any Scale. Any Time.
Shekhar Kapoor, Director Product Marketing
Mark Richards, Sr. Technical Marketing Manager
Each new silicon process node brings a huge jump in complexity. But, if you’re pushing the performance limits on a new process node, you have a particularly tough challenge on your hands. You used to be able to ignore many interactions as second- or third-order effects – but you can no longer do so. Those shortcuts are no longer available to you. As a result, the time it takes for you and your team to complete a high-performance design balloons with each generation. Margins are slim, process windows are tight, and there is simply no room for error in the final design.
Improvements to design tools help, and there are many small changes that can bring respite or temporary relief. But there are two significant changes that can transform both how the tools operate and how quickly a design can be completed. By using a unified single data model both in the early and late phases of the design, and by tightly integrating the engines that use that model, design time can be dramatically reduced. Beyond the traditional boundaries and silos innate in point-tool solutions – each with its own view and interpretation of the design process, a single RTL-to-GDSII solution with a single data model brings better results faster – by design.
Of the factors constraining designers, one stands out: the time it takes to complete a design, which we call time-to-results, or TTR. It can take so long to get the design to converge that success is declared when the design results are merely “good enough.” There’s no time for improvement or optimization; any such changes would trigger a whole new set of full-flow tool runs and push completion out too far, risking a market-window miss. Engineers end up spending their time managing the tools to get adequate results rather than doing what engineers do best: playing with tradeoffs to find the best possible solution.
This poor TTR comes from poor convergence across the wide range of point tools involved in a full end-to-end flow. Each tool does the best that it can, given the limited information that it has available to it, to produce a solution that best meets its own view of success. This is what point tools are required to do. When we place those pieces together in a flow, that “averaged success” often fails to converge and places stresses on later tools in the flow to make up the difference. All of these things conspire to increase overall time-to-results and leave engineers scratching their heads over which part of the flow to tweak to improve the overall system response.
These tools stresses additionally create instability that hurts overall closure convergence. When tools like synthesis engines are pushed to extremes, slight changes can be magnified to dramatically change final results. It’s hard to tweak results by tweaking the tools; the Butterfly Effect magnifies slight input changes to give very different output changes, making convergence a nightmare.
Design time – the time spent doing real engineering where balances and tradeoffs are down to the designer to optimize architectures – is squeezed because too many iterations are required within both the logical and physical phases, and there are too many iterations between the logical and physical phases. The logical phase knows nothing of the physical-phase data, and the physical phase knows nothing of the logical-phase data. And so TTR suffers.
There are two main reasons why convergence is such a tricky business in conventional flows.
The first big step we can take is to use a single data model. Whether a logical or physical model, it’s available to all tools – logical and physical – at all times. That means that logical engines can take some cues from physical parameters to improve their results and similarly, physical tools can mine architectural and logical intent from early in the design process to deliver a better overall solution
A particularly interesting case would be the early stages of the design process where we’re doing floorplanning or assessing overall design “implementability.” Having access to physical information for the target process means that we can create a better high-level layout – one that accounts for the physical characteristics of the process. This early layout will naturally be refined as we progress through the flow.
Another example would be that of clock synthesis. There are new techniques like concurrent-clock-and-data (CCD) optimization that are paramount in efficiently closing server-class Arm® cores due to the Arm architecture, which relies on cycle borrowing across logical partitions. This can’t be done effectively without knowledge of the clock and data drivers to be used. That’s an example of physical data required during the logical phase. Without that specific data, the tools would have to make assumptions about the clock drivers’ potential and what topology it implied. If those assumptions turned out to be too far off, we’d have to go back and re-plan or even re-architect the entire CPU subsystem.
Design results from this approach are encouraging. As examples:
Of course, some of the gains come from improvements to specific tools. But many of those improvements are possible specifically and only because the unified data model gives each engine access to everything.
Moving from a heterogeneous, federated set of data models to a single unified model, and using a single set of engines in a unified RTL-to-GDSII flow can have a significant impact on both TTR and PPA results. With access to all the data, algorithms can be made much more effective. With excellent correlation between logical and physical results, iterations can be dramatically reduced.
With less time spent on managing a design through a flow, we can reach market more quickly. Or we can spend more time optimizing results. And we may even be able to do both: get a more competitive product to market more quickly. Which, at the end of the day is what designers want to and should be doing.