Retargeting IP -> Extraction method verifies IP functions

Shrinking the geometries for such designs may affect performance to the extent that the reused device behaves incorrectly or differently from the original. For that reason, verification of the reused custom logic against its original counterpart must be an integral part of the reuse process. Newer, formal methods can both automate the reuse process and ensure identical functional behavior of the core with the original.

In comparing the functional behavior of migrated cores to their originals, companies may choose to write register-transfer level (RTL) behavioral code in an attempt to mimic the function of the core and then perform a simulation comparison against the corresponding transistor netlist to ensure they perform the sam e function. Intimate design knowledge is required to write that behavioral code with accompanying test vector sets.

The rub is that much of that design knowledge may still reside with the original designer, who may or may not be available when needed.

In-house designs

Behavioral models for legacy designs are created based on any internal company knowledge still available. Custom transistor-level designs, typically captured in a schematic format, are difficult to read. The functional boundaries are not clearly depicted. Recreating a structured model truly representing the custom design is immediately prone to misinterpretation and therefore to error.

The reuse engineer will also use any existing Spice simulations to interpret the in-house custom designs further. Rerunning and interpreting the results can be a lengthy process when dealing with the glacial speeds of transistor-level simulation. What's more, because of the lack of full vector coverage, the simulation could never represent the full possible response of the design.

The "code as you go and simulate" for the RTL modeling is an iterative process of trial and error. Simulation vectors for the block-level RTL models are designed with the intent of re-creating and matching the top-level vectors of the transistor design for the top level of the RTL.

Thus, even when simulation comparisons between the behavior model and the transistor design are successful, doubt remains that the two designs are identical, because of the limited set of vectors that are actually applied. Although the transistor design may have been replicated to the extent of having matched top-level simulations, that does not guarantee that the full functionality has been captured in the model.

What's more, when there is a problem after the integration of all the RTL model blocks, assuming the pa rtitioning was done correctly, the possibility of misinterpretation can complicate the task of diagnosing the source of RTL modeling errors. Fixing errors in an original custom design mandates correction not only at the transistor level but also at the behavioral level.

This approach thus leaves much to be desired, in that RTL behavioral-model creation is a manual, slow and error-prone process.

Given the headaches of shrinking and reusing full-, semi- or structured-custom cores, some companies choose to migrate some of the blocks to a standard-cell methodology using logic synthesis. Although there is usually some performance penalty associated with moving from a custom design methodology to a logic synthesis methodology that uses off-the-shelf library components, the practice greatly simplifies and automates reuse and retargeting to newer, smaller technologies.

Core reuse is appealing because it theoretically opens the door to creating an entire system with a plug-and-play ap proach. The availability of ready-made cores, coupled with higher time-to-market pressure, creates a very attractive and compelling reason for core reuse.

Nonetheless, the ability to create system-on-chip devices by reusing a set of selected cores brings with it the realities that plague the designer in assuring consistent functional integrity for a block-based design approach. The end user must either be assured that core functions as intended or must be prepared to verify the core.

Even with the simplest of cores, simulation of all the possible combinations of inputs and state bits is exponential. Thus, in most cases, exhaustive simulation can be done neither by the core's provider nor by the user.

For digital circuitry, the use of formal techniques can dramatically accelerate design core creation while assuring the functionality of the intended design for reuse. That holds true either for a custom-based approach for legacy design cores or for a standard-cell-based approach , as in a soft core. Traditionally, ASIC-specific design practices follow a timing-driven design methodology, often requiring the internal knowledge of the design team for effective reuse.

Custom migration into different technologies is an area where many companies have begun using formal techniques to automate the core design and reuse process. It has been proven that custom design conversion and functional integrity for core reuse can be a painful, tedious and iterative pro-cess. However, the availability of tools having not only the logic function extraction capabilities but also the verification techniques, as found in the Tuxedo Logic Transistor eXtraction (LTX) software from Verplex Systems, enables the conversion of a custom design with secured functional integrity into a reusable core.

Extraction is just one aspect of the overall methodology. Taking the initial step of extraction used to be one of the most difficult in this process. The completely automatic extraction engine is based on Boolean functional analysis. For unrecognizable circuits that may contain some analog circuitry, flexibility exists to allow the user to specify how the functional modeling is accomplished for a specific connectivity model. That is very important when retargeting a design to a new library. The user specifies the platform's transistor netlist for the pattern, along with the corresponding functional RTL model, which is then used every time the corresponding pattern is encountered in the design.

Logic function extraction from a transistor circuit in a Spice netlist eliminates much of the user intervention that may have been required in the past. For example, analysis of transistor logic flow direction and identification of weak transistors are completely automated. The algorithms can determine logic function without extensive user input. Boolean function can be extracted from static CMOS, Pass-Gate and tristate logic. Multiplexers as well as latches and flip-flops are easily recognized.

The extracted logic functions can then be written out as a gate-level primitives using standard logic primitives such as "and" and "not" functions and user-defined primitives (UDPs) for latches and flip-flops. The resultant core netlist can be used for synthesis targeting to a specific ASIC library.

Instead of relying on slow, transistor-level simulation, functional integrity for design reuse can now be accomplished by any number of speedier methods, including higher-level Verilog simulation acceleration (above the transistor level), emulation, or equivalence checking against an RTL behavior model.

Full representation

Having a full representation in an RTL behavioral model as a result of the automatic model extraction process leverages a number of advantages for future reuse, in addition to speeding simulation. Instead of comparing an RTL behavior model simulation against a transistor-level simulation, formal techniques in logic equivalence c hecking guarantee complete functional coverage of the original design.

Within a single environment, the Tuxedo LEC equivalence checker works together with the extraction capabilities of LTX to automate functional-integrity checking. The transistor-level netlist for the custom design is read into the environment and internally abstracted into a gate functional model, which is used to compare against a behavioral model that may have been externally developed.

Since this method is exhaustive and faster than developing a testbench and running simulation to validate the integrity of the RTL model with the custom circuit, it is used in parallel with or as a replacement for the traditional, simulation verification approach.

Although a custom methodology has many steps, the complete set of features required for such a flow for full RTL-to-transistor-level formal verification now exists to handle those steps automatically. The automated process supports both formal-based and simulatio n-based flows for effective core array verification.