Apache forges ahead with RedHawk-NX power analysis

Apache Design Solutions has carved out a strong position in the SoC power analysis space with RedHawk, claiming that 80 percent of the top 20 semiconductor companies are clients in one form or another. But in an industry that slithers into a new process node every year or so, market share for a tool linked to the physical design can be an ephemeral thing unless you work to stay current. And that Apache is doing, today announcing the latest version of their RedHawk analysis package, NX.

RedHawk-NX has been over two years in the making, according to CEO Andrew Yang. Rather than adding major new types of analyses, Apache focused on expanding the capacity and speed of the package to meet the increasing size of designs. Hence the three major new aspects of RedHawk in NX are all capacity-related. But developing these three capabilities required rearchitecting the core engines within RedHawk, Yang said.

Like a SPICE simulator, RedHawk—which performs both static IR-drop and dynamic voltage analysis of power and ground meshes, and scans the resulting data for power integrity, electromigration risks, and other potential faults—comprises two separate core engines beneath the data-management and user-interface layers. One engine extracts models from the design data, and the other is a matrix solver. Both engines came in for major rework.

The primary goal of the changes was to increase the capacity and decrease the run-time of the package. But a second, equally-important point, according to Yang, was to preserve the accuracy of the analysis. Apache didn’t want to create a situation like that of FastSPICE simulators, where the simplifications necessary to give faster execution times can lead to serious inaccuracies, so that learning when it is safe to use the tool becomes a design skill in its own right. The object was to make the new RedHawk a direct replacement for the existing EV version.

The changes produced three new capabilities. The first the company is calling Hierarchical Dynamic (HD) analysis. In essence, HD is a recognition of the fact that SoCs today are primarily created by integrating existing IP blocks, not by creating entirely new netlists. To work efficiently in a sign-off analysis using RedHawk, the imported IP blocks must either be visible to the SoC team at the netlist level or they must have existing RedHawk models of their power meshes. HD permits memory designers and logic IP designers to validate their power meshes and pass abstract models on to the SoC design team. Models for IP can be encrypted, so that the SoC team cannot infer the internal structure of the IP from the power models.

This capability allows the SoC team to treat imported IP either as a white-box or a gray-box model during analysis, substantially reducing run time and complexity. Yang said that using a white-box view of a block, in which the netlist is replaced with an RC network and a file of voltage-drop data, would reduce the run time by 30 to 50 percent, and would yield the same results as flattening the IP into the design database. Employing the gray-box abstraction, which represents the block as a simple voltage-drop model, can reduce the run time by half or more, but can sacrifice up to 5 percent in accuracy compared to a fully flat design.

The second new capability Apache calls Mesh Pattern Recognition. A technique borrowed from the FastSPICE world, MPR preprocesses the flattened power/ground network to identify repeating patterns in the mesh. The tool extracts these patterns, models each once, and then uses that model for all the instances.

Obviously, this technique is most powerful in designs that have large numbers of simliar memory instances or repeated use of specific logic blocks, such as would occur in on-chip multiprocessing or in SIMD pipelines. Depending on the nature of the SoC, Yang said that MPR can reduce compute time by a factor of from perhaps two, working mainly on memory instances in a memory-rich but otherwise fairly random design, to six or more on a dense and repetitive logic chip.

The third major advance is in adapting RedHawk to multicore processors. As we have recently discussed with SPICE engines, the process of adapting a package such as this to multicore computing involves parallelization of both the extraction engine and the matrix solver. Yang said that Apache has done both tasks, with the caveat that today, the matrix solver only scales linearly to about four CPU cores. Beyond that, even on full-chip analyses, the gains start to fall off. "It is possible to scale further by partitioning the flat design," Yang said, "but we have not yet completed development on a way to do that without reducing the accuracy of the results. And in this case accuracy was more important than further scaling."

Taken together the new capabilities make RedHawk ready for 45 nm designs, Yang maintains, and the product is released for production as of today. Still on the drawing board are, one suspects, a partitioning algorithm that will allow the matrix solver to employ more CPUs in parallel, and additional integration of RedHawk with Apache’s Sentinel, a package- and board-level analysis tool. Yang hinted that as SoC designs move up in frequency, designers try to bring broadband signals directly onto SoCs, and designs migrate from a single chip to a multidie system-in-package technology, die-level and board-level analysis tools can no longer stand separately. Apache apparently plans that they should not have to do so.