IP Design Methodology of VLSI Semi-Custom Chip Design

 Hello Dear Readers, 

Today in this post I will provide some deep insight into IP design methodology. 

The design of an IP core entails developing and releasing a set of models for subsequent SoC methodology flow integration. These models are described in the following sections. 

1. Functional Model for Logic Validation:

The functional IP model is first compiled into the SoC simulation environment. The model source is usually provided as part of the IP license either in the hard or soft IP, typically in a hardware description language (HDL) format. For hard IP, for added security of the intellectual property, a compiled binary is licensed, with a set of EDA simulation tool application program interface functions to initialize, exercise, and query the behavior.

 An HDL model can be developed at different levels of functional abstraction— that is, a logic gate–level netlist, a register transfer–level module, or a model utilizing higher-level semantics. For IP with analog content, the IP model may include extensions to the HDL constructs used, as industry-standard HDLs provide support for mixed-signal behavior. The functional simulator used for an SoC project needs to accept any model abstraction level; for models with mixed-signal content, the simulator maintains both a logical event-driven and analog continuous-time network evaluation engine with a synchronization interface between the two model subsets.

The IP functional model needs to include additional support to ensure proper usage in the SoC design. Specifically, HDLs include assertion statements that do not represent additional functionality but rather observe signal behavior in the model to check for events that invalidate IP design assumptions. A simple example would be a combinational assertion that is connected to a set of model inputs that are to be mutually exclusive—say either “zero-or-one-hot” or “zero-or-one-cold.” The severity of the assertion identifies how the simulation tool responds when the assertion condition is invalidated; for example, a fatal assertion would halt the execution, with the time, assertion message, and network state available for direct debugging.

Functional models may also include additional statements to record key events and/or sequences during a simulation test. The complexity of these event monitors ranges from a simple capture of important signal values to more complex statement sequences with internal counters of specific operations executed during simulation. The SoC functional validation plan needs to confirm that the testbench suite goals for thorough model coverage are consistent with the event activity and monitor data available from the IP model.

Note that an increasing percentage of the SoC functional validation workload is being allocated to accelerated simulation hardware platforms as shown in Fig. 1, with a diminishing focus on software tool simulation. The accelerator platforms have unique requirements for the model semantics that can be compiled, partitioned, and mapped to the hardware. If the SoC validation plan includes acceleration, the IP functional model must offer corresponding hardware platform support.

Fig. 1: Architectural diagram of an emulation system

2. A Performance Model:

Functional simulation models include the full detail of the IP behavior (e.g., necessary for SoC validation but too slow for SoC architecture performance optimization). Consider the case where processor cores, caches, and bus interface models are being designed to achieve a target performance for program code examples. A high-level, instruction set architecture (ISA) execution model of the core is required to gain sufficient program execution throughput to identify any performance bottlenecks.

An IP core provider may be required to provide a (C language–based) performance model, in which accurate ISA evaluation and internal cycle latency are the key features. 

3. A Logic Synthesis Model:

For a hard (or a firm) IP core, there is no need to synthesize an HDL model to a library cell implementation. For a soft IP design, a functional model that can be used by a logic synthesis flow is required. Typically, the synthesis models are based directly on the functional simulation model. Any non-functional code in the simulation model, such as assertions and monitors, would include directives (also known as pragmas) to inform the synthesis flow to bypass this section of HDL code.

The HDL model for the soft IP is commonly provided at the register-transfer level (RTL) abstraction. Dataflow registers and control flow state flip-flops are fully defined in the model, as is the specific clocking behavior for data operations and state machine sequencing. Combinational logic operations are written to describe the register and state machine inputs for each clock cycle. The RTL model approach provides a suitable trade-off between simulation throughput and the expected specificity of IP logic performance. For IP cores where simulation testbench throughput is a priority, the HDL functional model may include more abstract constructs. For example, cores providing digital signal processing on serial data streams require higher simulation throughput and would be more concisely and easily written in terms of do/while and for loop statements. In this case, a more general sequential synthesis flow is required. The synthesizable model is also typically used to map the IP functionality to a simulation acceleration hardware platform. In addition to the delivery of the IP model for logic synthesis, the constraints used by synthesis algorithms are required (e.g., input clock definitions, input/output pin timing requirements (relative to the clock), timing modes for MCMM path timing analysis). If the IP is designed to support power states, a power format file description is provided, as well; the synthesis algorithms use this description to ensure that the proper cells are selected for level shifting, sleep state retention, output isolation, and sleep gating. The synthesis model may include details about test-specific connectivity within the IP or may defer testing insertion algorithms within the synthesis flow. A key methodology decision pertains to whether the initial HDL validation environment is to include simulation of testability features or whether test architecture validation is to be deferred to later functional simulation steps. If the former, the HDL model needs to include related built-in self-test (BIST) and scan-shift test logic; no test insertion is required. (The final serial scan-shift flop ordering may be updated during IP physical implementation, If testability validation is part of a post-synthesis flow (e.g., using a simulation accelerator platform), the IP model only needs to include sufficient detail for the test insertion synthesis step. 

4. A Test Model, Test Patterns, BIST, and Wrap Test Architectures:

For hard IP, several test approaches are available. A detailed test model could be provided to merge with other SoC models for pattern generation. Alternatively, logic could be embedded within the IP to exercise test patterns directly in support of BIST operation, with both internal pattern generation and response signature compaction features (see Sections 19.3 and 19.4). Alternatively, the hard IP may support a wrap test operation. In this architecture, the IP internal functionality is surrounded by a serial scan-shift register. In wrap test mode, the primary input and output connections to the hard IP are deselected, and the internal scan-shift register is multiplexed to provide the input values and capture the output responses. The test patterns are applied using a scan-shift input sequence, and the response values are then captured and shifted out for observation. The IP is logically isolated from the rest of the SoC during the wrap test. Or, in the most basic approach, test patterns are provided by the hard IP vendor, and the SoC design is responsible for the multiplexing functionality outside the IP to make the pins controllable and observable for pattern application and response capture. Fig. 2 illustrates this embedded macro test approach.

Fig. 2: An embedded macro test architecture provides pattern controllability and observability connections to the IP directly from SoC I/O pads through multiplexing logic

Analog hard IP includes a unique set of test specifications and the interface description to stimulate and capture the corresponding signal measurements. For hard IP associated with high-speed chip I/O serial interfaces, a unique test methodology includes a loopback function, where the transmit (Tx) stream output is connected to the serial receiver (Rx) lane, as depicted in Fig. 3.

Fig. 3: Simplified block diagram of an I/O interface IP design that incorporates a loopback test feature, a common approach for high-speed SerDes interfaces.

The test model for large memory array IP presents some additional considerations if the diagnostic results of an array test are to be used for programming fuses for array repair. For soft (or firm) IP, the netlist model from logic synthesis serves as the basis for the test model. Each library cell includes a specific fault model. The cell instances in the netlist are expanded to provide the potential faults in the network for test pattern generation algorithms to provide production test vectors.

5. A Physical Model:

The physical model for a hard IP block consists of a detailed layout and an abstract for use in floorplanning and global routing flows. For IP security, it is feasible for the model delivery to omit the detailed layout and provide only the abstract. During mask data preparation after tape out, the foundry —or another trusted partner—would insert the layout data and re-confirm the physical verification steps. Note that device models are dependent on nearby layout structures (e.g., adjacent devices and impurity implants for wells and nFET/pFET source/drain nodes). 

When developing the timing model and exercising electrical analysis, a hard IP provider assumes a representative layout context around the IP layout. The methodology team needs to review these context assumptions to ascertain whether the layout-dependent ef effects (LDEs) are accurate for the target SoC design. The methodology team may need to consider re-extracting and characterizing the hard IP layout (if available) with a different layout context. Alternatively, the IP vendor license may include a request for an updated set of models with a specific context from the SoC design team at an additional cost. The physical abstract is a text file that conveys the information needed to integrate the hard IP into the physical implementation flows. This text file is typically derived from a combination of designer input and the IP layout data, where the layout includes shapes on specific non-manufacturing layer (and layer purpose) definitions. An abstract generation methodology flow step (commonly denoted as abgen) at the completion of the IP design produces the abstract file by merging the designer configuration input with the coordinate information of these specific layer shapes.

Possible Interview Questions From the above Content:

1. What do you mean by IPs? and what are the types of it.
2. What are the types of physical verification?
3. What is the concept of rows in the floor plan?
4. What is the difference between logic design and microarchitecture design?
5. What are the different methods of modeling digital logic design and benefits for individuals?
6. How can you reduce dynamic power?
7. What are the contents available in the .lib file? how to identify the process corner from it.
8. What do you mean by Emulator?
9. What do you mean by ISA (Instruction Set Architecture)? how it will help us in the design of the microarchitecture.
10. What do we do for low-power design?  
11. What are the different types of delay models?

Connect with me 

1.Linkedln

2.Instagram

3.Facebook

4.WhatsApp