For SoC, It's the Whole - Not the Parts

Such is the life of an SoC physical design team, which has to assemble analog intellectual property (IP), memory blocks, soft digital IP from internal design teams, and IP from outside contractors and off-the-shelf IP providers. Only at the point of full-chip physical design assembly, when all IP and place-and-route blocks come together, can the design team verify that the chip will actually work.

Given the increase in the amount of IP included in today's SoCs, three phases of quality checking and integration are required to generate a high-quality SoC: perform quality checks on the IP on a standalone basis; verify the consistency of the IP with the netlist; physically verify the IP in the context of an SoC.

Check as standalone

Many design teams assume IP is design-rule-checking (DRC) and layout vs. schematic (LVS) clean, or can't afford the time to set up or run a precautionary analysis. IP DRC errors can later reveal themselves as numerous design DRC errors if not caught early on.

One customer's chip had 32 libraries, from which five vendors supplied 303 macros. IP that came from multiple sources frequently arrived with library views that were inconsistent with one another. And with five vendors, even more frequent LEF, .lib, .cdl, GDSII and Verilog updates had to be checked for consistency. In addition, the usual IP problems appeared. For example, LEF files had syntax errors, wrong file names, wrong cell names or missing data such as forgetting to turn on name case sensitivity. The multiple library views (abstract, timing, layout) had to be created, sometimes because they were missing or because they were inconsistent, such as when the number or names of pins differed.

If not caught up front, these problems show up in full-chip verification--one big reason tapeouts slip. The solution is to create a complete new set of technology files for all the tools used for the chip's physical design.

Check full-chip netlist

IP must be checked for consistency with an incoming SoC netlist. In many cases, the front-end team may have been using only a register-transfer-level (RTL) header for the IP. These RTL headers often don't correspond to the physical representation of the IP. Errors may be as simple as slightly different pin names, or more severe such as completely missing pins on the IP or in the netlist. Running a netlist audit utility that flags inconsistencies between the physical views of the IP and the netlist is quite handy. It has the added advantage of flagging IP that was referenced in the netlist but missing in the IP library.

Verify physically

Even after checking the standalone quality of the IP and ensuring that all IP is consistent with the SoC netlist, there is still a high level of risk of finding problems in a full-chip physical design context. Individual IP components may pass standalone LVS and DRC checks, but when placed within the design, full-chip physical verification may reveal LVS and DRC errors. IP may have blockages that affect such things as full-chip routability and power grid design. To detect these problems early, designers must have a process to quickly build and analyze the full chip.

On one recent design, a 6-Mbyte MoSys 1-T SRAM occupied half the chip's active area. Because of the overall area limit for the chip, all other components were forced into one small, dense, fixed-size region. This region had to include three mixed-signal components, 23 embedded RAMs and a CPU.

See related chart This shows a GUI used to automatically check all library views necessary for running the physical design point tools and generate the libraries. The colors indicate the status (done = blue, requested = yellow, running = green and error = red.) Source: ReShape Inc.

A different floor plan and power distribution and other design alternatives had to be quickly evaluated by building the entire chip and analyzing the design decisions. EDA software that automated job execution enabled the design team to build the full-chip SoC for any design permutation and analyze the results overnight. Timing, IR drop and electro-migration analysis were routinely run on the entire design, many times over, until the design worked.

The only known solution to a working conglomeration of blocks is to first verify standalone IP from a physical perspective as early as possible, assemble the full chip to GDSII and measure and verify the real results. Many SoCs are implemented using hierarchy, which means multiple place-and-route and verification runs. Newly available EDA software that automates job execution and management of parallel tool execution enables teams to build their full chip SoC overnight and run the associated golden verification tools. The impact of design decisions can be measured in less than 24 hours. Rapid verification that the analog IP, memories and the digital IP all work together helps lead to on-time, on-spec SoC design projects.

Sharlene Gee (sgee@reshape.com) is senior applications engineer at ReShape Inc. (Mountain View, Calif.).