FAUNA ASOCIADA AL SISTEMA

Figure 2.5 shows Step 3 in the ASIC design flow, which involves creation of test benches. These are used to simulate the RTL code.

A test bench is basically a wraparound environment surrounding a design, which enables the design to be simulated. It injects a specified set of stimulus

STEP 2

FIGURE 2.4. Diagram indicating Step 2 of an ASIC design flow: RTL coding.

TEST BENCH AND SIMULATION 7

TABLE 2.1. The three types of Verilog code

RTL Behavioral Structural

RTL coding, or register Behavioral coding is Structural Verilog coding transfer level, is most used to describe a “black has a data type structure commonly used to describe box” design whereby the that defines the

the functionality of a output of the design is different components and design for synthesis. It specified for a certain their interconnects is also descriptive in input pattern. Behavioral present in a design. It nature, similar to code mimics the represents a netlist of a behavioral Verilog. functionality and design. Structural However, it only uses a behavior of the “black Verilog is normally used subset of Verilog syntax, box” design. It is when passing netlist as not all Verilog syntax normally used for system- information of a design is synthesizable. RTL level testing. between design tools. For

coding can be viewed as example, upon completion

more descriptive than of synthesis, the netlist

structural Verilog but of a design is passed to

less descriptive compared APR (refer to Section 2.6

with behavioral Verilog. for explanation of APR)

using structural Verilog.

module RTL (inputA, inputB, inputC, inputD, outputA);

input inputA, inputB, inputC, inputD;

output outputA;

reg outputA;

always @ (inputA or inputB or inputC or inputD) begin

if (inputA & inputB

& ~inputD) outputA = inputC;

else if (inputA &

inputD & ~inputC)

always @ (inputA or inputB or inputC or inputD) begin

if (inputA & inputB &

~inputD) outputA = #5 inputC;

else if (inputA &

inputD & ~inputC)

input inputA, inputB, inputC, inputD;

output outputA;

wire n30;

AN3 U8 ( .A(inputA), .B(n30), .C(inputB), .Z(outputA) );

EO U9 ( .A(inputD), .B(inputC), .Z(n30) );

endmodule

into the inputs of the design, check/view the output of the design to ensure the design’s output patterns/waveforms match designer’s expectations.

RTL code and the test bench are simulated using HDL simulators. If the RTL code is written in Verilog, a Verilog simulator is required. If the RTL code is written in VHDL, a VHDL simulator is required. Cadence’s Verilog XL, Referring to the Verilog code shown, when simulated or synthesized, both the RTL and structural Verilog will yield the same functionality. Behavioral Verilog, however, is not synthesizable.

Synthesized logic for RTL Verilog and structural Verilog inputA

FIGURE 2.5. Diagram indicating Step 3 of an ASIC design flow: test bench and simulation.

TABLE 2.1. (Continued)

RTL Behavioral Structural

Synopsys’s VCS, and Mentor Graphic’s Modelsim are among some of the Verilog simulators used. Cadence’s NCSim and Mentor Graphic’s Modelsim are capable of simulating both Verilog and VHDL. Synopsys’s Scirocco is an example of a VHDL simulator. Apart from these simulators, there are many other VHDL and Verilog simulators. Whichever simulator is used, the end result is the verification of the RTL code of the design based on the test bench that is written.

If the designer finds the output patterns/waveforms during simulation do not match what he or she expects, the design needs to be debugged. A non-matching design output can be caused by a faulty test bench or a bug in the RTL code. The designer needs to identify and fix the error by fixing the test bench (if the test bench is faulty) or making changes to the RTL code (if the error is caused by a bug in the RTL code).

Upon completion of the change, the designer will rerun the simulation.

This is iterated in a loop until the designer is satisfied with the simulation results. This means that the RTL code correctly describes the required logical behavior of the design.

2.4 SYNTHESIS

Figure 2.6 shows Step 4 of the ASIC design flow, which is synthesis. In this step, the RTL code is synthesized. This is a process whereby the RTL code is converted into logic gates. The logic gates synthesized will have the same logic functionality as described in the RTL code.

SYNTHESIS 9

FIGURE 2.6. Diagram indicating Step 4 of an ASIC design flow: synthesis.

In Step 4, a synthesis tool is required to convert the RTL code to logic gates.

More common tools used in the ASIC industry include Synopsys’s Design Compiler and Cadence’s Ambit.

The synthesis process requires two other input files to make the conversion from RTL to logic gates. The first input file that the synthesis tool must have before making the conversion is the “technology library” file. It is a library file that contains standard cells. During the synthesis process, the logic function-ality of the RTL code is converted to logic gates using the available standard cells in the technology library. The second input file, “constraints file,” helps to determine the optimization of the logic being synthesized. This file normally consists of information like timing and loading requirements and optimization algorithms that the synthesis tool needs to optimize the logic, and even pos-sibly design rule requirements that need to be considered during synthesis.

Step 4 is a very important step in the ASIC design flow. This step ensures that synthesis tweaks are performed to obtain the most optimal results possible, should the design not meet the specified performance or area.

If, upon final optimization, the required performance or area utilization is still not within acceptable boundaries, the designer must reconsider the microarchitecture as well as architectural definitions of the design. The designer must re-evaluate to ensure the specified architecture and microar-chitecture can meet the required performance and area. If the requirements cannot be met with the current architecture or microarchitecture, the designer will have to consider changing the definition of the architecture or microar-chitecture. This is undesirable, as changing the architecture or microarchitec-ture can potentially bring the design phase back to the early stages of Step 1 of the ASIC design flow (specification). If by changing the architecture and microarchitecture definition the design is still unable to provide the kind of performance or area utilization required, the designer must resort to the possibility of changing the specification itself.