IP Verification : Verifying timing of external IP key to SoC success

Besides the actual design, IP can include test benches, timing models, layout guidelines and more. Due to the different varieties, forms and support, integrating external IP into your system-on-chip (SoC) designs can be a daunting task. Verifying the IP in your design is the key to successful silicon and achieving timing verification can be the biggest bottleneck.

Timing verification starts once the design has been implemented as a register-transfer-level (RTL) model and functionally verified. Timing verification ensu res that the design performs the function within the timing constraints of the system. Timing constraints are placed on the RTL model, and the design is synthesized into a gate-level netlist. Static-timing analysis of the netlist can determine whether the design meets the speed requirements. This is known as pre-layout timing verification since only an estimate of the interconnect timing is used. The timing constraints and/or the RTL model are modified until pre-layout timing is verified.

Next, the design is laid out and parasitic information is extracted. The extracted information represents the actual timing of the silicon and is used to verify timing again. This is known as post-layout timing verification. At this point, the RTL model, the timing constraints or the layout may need to be modified to pass verification. Once completed, the design progresses into physical verification and on to tapeout.

Integrating external IP into SoC designs and verifying timing can be very challenging. If the external IP is a soft block like an RTL model, then that model should look like any other RTL model in the SoC. So, the timing verification methodology for the SoC should easily incorporate the external IP. The issue becomes more of a design problem since the SoC designer is the one who takes on the responsibility of synthesizing the IP to meet the timing requirements.

If timing cannot be met, the designer may be forced to re-architect the SoC, or migrate to a faster process. If the IP is in the form of a hard block, then a timing model should accompany the IP. The timing model needs to be incorporated into the SoC timing model. For a hard block, the internal signals should already be timing-verified; however, special attention should be paid to the IP interface timing. Issues arise from incompatible timing models that do not allow for easy timing model integration, as the following example shows.

As members of a design team, we needed to integrate an external DSP core into our SoC desig n. The DSP core contained data and program memory and a peripheral bus interface. The IP was in the form of a hard physical layout block. The internal design blocks were dedicated data path blocks that would connect to the DSP core via the peripheral bus.

The DSP core was timing-verified for a typical process, a typical voltage and a junction temperature of 85C. For our SoC, we required timing verification at a worst-case design corner (slow process, low voltage and junction temperature of 125C) and a best-case corner (fast process, high voltage and junction temperature of 0C).

The custom cell library for the DSP was not characterized over the corners we required. Additionally, some of the components on the core were fully custom and would be too difficult to re-characterize.

Since the DSP was already timing-verified, we knew it would function properly, but at the worst-case corner it would operate at a slower rate. We needed to determine how much slower that rate would be. We esti mated the speed of the DSP would decrease by 25 percent at the worst-case corner. There was also silicon available on the DSP to substantiate our estimate. The 25 percent degradation was well within the bounds we required, so the internal DSP timing was sufficient.

Once the internal timing was resolved, we addressed the interface timing. We determined that a block-level timing model of the DSP core could be used to verify the interface. The block-level model would view the DSP core as a black box with timing only for the signals entering and leaving the block. At the top level, the DSP core would essentially look like another cell in the cell library. Thus, a block-level model of the DSP core would allow us to complete timing verification.

Synopsys Primetime was our static-timing tool, and it could also produce a block-level timing model. Primetime needed a netlist of the DSP core and a standard delay format (sdf) file to produce the model. There are many ways to create an sdf file. For pre-l ayout timing, an sdf can be created using a wire load model to estimate the net lengths and the cell library timing models. For post-layout timing, the actual net timing is extracted from the layout plus the cell library timing models.

Although the block-level model needed to be accurate over best-case and worst-case design corners, the custom cell library for the DSP was not characterized for the corners we required and some full-custom logic could not be re-characterized.

Fortunately, the full-custom logic was deep inside the DSP core, and the peripheral bus interface used the cell library extensively. By re-characterizing just the cell library and leaving the original timing on the full-custom logic, the interface timing would be very accurate.

Finally, the DSP core was timing-verified using Ambit static timing. So, the Ambit timing scripts that set up the timing constraints needed to be translated into Primetime. Re-characterizing the cell library to our design corners and transla ting the Ambit scripts was a considerable amount of work, but once completed, it allowed us to pass timing verification across the IP interface.

For successful SoC silicon, timing verification of external IP must be achieved. For soft IP, the challenge becomes a design problem of synthesizing the IP to meet the timing constraints of the system. With the SoC designer already constrained by the fixed implementation of the IP's RTL model, achieving timing verification can become extremely difficult. For hard IP, in most cases, the IP itself has already been timing-verified. The major issue becomes making sure the IP interface signals can be completely verified with the rest of the SoC. The designer is faced with ensuring that the models are compatible and that the tools can integrate the internal blocks with the external IP.

Se e related chart