Getting Better Results Faster with the Singular RTL-to-GDSII Product

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.

The Challenges of Traditional Flows

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. 

Two Primary Design Phases

Traditional digital design flows work in two major phases: the logical and the physical. Work starts at a highly abstracted logical level, specifying high-level behaviors that the tools will render into logic. Tools use rough-and-ready estimates to complete their tasks more quickly. Work continues in this phase, iterating between design and verification, until performance, power, and area (PPA) have been closed.

Once the logical phase is complete, the physical phase begins. Here the abstracted elements specified in RTL are given physical embodiments: real transistors, real wires, and real passives – all on real silicon. Rather than the estimates used in the logical-phase models, the physical phase uses models tightly bound to physical realities. Tools are more accurate, but they are also slower to run.

As with the logical phase, here again we iterate between physical design and verification tools to get closure. If the numbers used in the logical phase were too inaccurate, then we may need to depart the physical phase and loop back into the logical phase to refine the logical design before returning to the physical design.

Once converged at the physical level, then the final design must be confirmed as manufacturable through exhaustive signoff tools that can run for days given the 200+ corners that must be covered for today’s process nodes. Mistakes found at this juncture can be expensive and time-consuming to fix – especially if small changes result in large circuit changes.

Using a Single Data Model

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.

Integrate a Common Set of Engines

By using the same engines for the logical and physical phases, we no longer have discrepancies between approaches, algorithms, and assumptions made. The engines used early in the design flow will be the same ones used to refine and close the design later on, relying on the same costing methodologies, the same optimization trajectories, and the same view of the entire dataset and how to best utilize it.

Note that this is very different from “unifying” a flow by placing disparate tools under a single integrated design environment (IDE). The IDE does nothing to give full data access to all of the tools, and it does nothing to ensure that a single set of engines is used. A unified flow may include an IDE, but it’s not the IDE that’s responsible for the improved TTR and PPA results.