Design Automation

MOdular TIming VErifier (MOTIVE) from Viewlogic's Quad Design Group (Camarillo, CA) has become a defacto-standard static timing analysis tool. Because it has a modular nature, it can be used for both ASIC and board analysis. However, the tool does not work to its full potential straight out of the box. You have to know a few tricks and develop a systematic strategy to gain optimal use of the tool.

A systematic MOTIVE strategy Here is a systematic MOTIVE strategy for ASIC design that is easy to understand, set up, control, use, and expand (or reduce). Also, it can be automated 100 percent with Make or a single big script.

There are at least a million timing issues to analyze. However, time-to-market pressures won't allow you to analyze all of them. Therefore, you should identify only those areas in an ASIC design that need to be analyzed. This MOTIVE strategy breaks down the ASIC timing analysis into five categories:

1. Internal logic (core logic), including RAM and internal/external BIST (built-in self-test) logic.

2. JTAG circuitry, if any, which should include a test access port (TAP) controller, instruction decoder, scan-chain selection logic, boundary scan registers (BSRs), and so on.

3. External interface for selected primary I/O pins, such as to external RAM or other ASICs.

4. Primary I/O pins not covered by the previous category.

5. Absolute path delay traces for selected paths.

Each of these categories is divided into min and max delay cases, making a total of ten subdirectories (see "Necessities for the motive_ana directory").

The motive_ana directory The motive_ana directory will hold the ten subdirectories. The directory must have the gate-level Verilog netlist and standard delay format (SDF) file for the ASIC or preferably the links to them. Next, decide whether the files can be directly translated for MOTIVE or if they must be modified first. One reason for modifying the netlist is shown in Figure 1. Imagine the zero-delay buffer is not in the highlighted path. This circuit generates the active-low write-enable signal we by using the rising edge of clk , and a delay_cell gate with X ns of delay. In other words, clk's falling edge is not used. One must tell the tool this by using a multicycle path (MCP) statement.

Using the buf.add file in the motive_ana directory, write a script that adds the buffer i-z to the design. The other logic in Figure 1 will not be affected by this method, which is one way to root out false paths (all paths originating from clk's falling edge are false in this case). Note that the added buffer is only for the tool's analysis and must not be in the netlist for chip fabrication.

Now, you are ready to produce the tool's database in the motive_ana directory, which will be used by its ten subdirectories. The following is the main sequence of events:

• Run a user script that creates a MOTIVE batch command file in each of the ten subdirectories.
  
• Create the tin_tsh.ref file, which contains all the TIN and TSH statements for primary I/O analysis and will be included by the io.ref file. Use the C language preprocessor cpp and an input file that includes a definition file, define.file . Suppose the input file is called tin_tsh.ref_src:

#include "path/define.file"
TIN PART part_name PIN IN REF clk EDGE R RISE R_MIN R_MAX FALL F_MIN F_MAX
and the define.file contains
#define R_MIN 2.0
#define R_MAX 3.0
#define F_MIN 2.0
#define F_MAX 2.5

--then run cpp

cpp tin_tsh.ref_src tin_tsh.ref

to create tin_tsh.ref:

TIN PART part_name PIN IN REF clk
EDGE R RISE 2.0 3.0 FALL 2.0 2.5

Comments in tin_tsh.ref start with #, which is also the comment notation for the tool.

• If the case shown in Figure 1 applies, insert the required buffer(s) into the netlist and SDF file; then run Quad's vtran utility on the netlist to generate MOTIVE's pin file, core.pin. Use the -s . option if the SDF file uses " . " as the hierarchy separator.

• If the SDF file needs to be modified, such as changing the bus name from bus\[3\] to bus[3] , write a script to perform it here.

At this point, analysis in each subdirectory can be started. Because the goal is to reuse as much existing work as possible to save disk space and run time, the environment presented here requires that int_min and int_max cases be run first. The work done there can be reused by all the other eight cases, which can be run either in parallel or in series.

Figure 1. Additional logic is added to generate the write enable only on rising edges of the clock.

The int_min and int_max subdirectories These two cases are for min and max timing analysis of the ASIC's internal flop to flop transitions. First, run Quad's sdf2mtv utility with the -min option on the SDF file in the motive_ana directory, and put the resulting control file, core.ctl , and interconnect delay data file, core.idd , in the int_min subdirectory. This extracts the min delays. Second, create the technology file, core.tec , ¹ which may be used to scale the min delays (by 120 percent, say) to get the max delays. Note that core.tec scales only the IOPATH delays in the SDF file. To scale the port or interconnect delays by 120 percent, create in the int_min a command file called prt_scl.cmd , which will be used during a MOTIVE run, as shown below:

sv /analysis/delay/scale/Swmin_n_r 1.000000
sv /analysis/delay/scale/Swmin_x_r 0.000000
sv /analysis/delay/scale/Swmin_n_f 1.000000
sv /analysis/delay/scale/Swmin_x_f 0.000000
sv /analysis/delay/scale/Swmax_n_r 1.200000
sv /analysis/delay/scale/Swmax_x_r 0.000000
sv /analysis/delay/scale/Swmax_n_f 1.200000
sv /analysis/delay/scale/Swmax_x_f 0.000000

To automate this process, use prt_scl.cmd , even if no scaling is done. Also, if no scaling is done, simply replace 1.2 with 1.0.

Write a script to read the case.ana file and insert any case analysis specifications into the core.ctl file. Doing so creates a new control file. Finally, run Quad's mmp utility on the new control file, the technology file, and the MOTIVE model libraries to create core.mod . Pay attention to mmp messages. If they contain errors, such as missing models, do not continue. Look into the core.rcf file generated by mmp for debugging hints.

By this time, the batch command file, batch.cmd , that runs the tool in batch mode should have already been created and put at int_min . The following are entries that need discussion:

sv /file/mcp " motive_ana /core.mcp"
sv /file/net " motive_ana /core.pin"
sv /file/ref " motive_ana /core.ref"
sv /file/trc " motive_ana /int_min/
core.trc"
sv /timebase/ 20.0
cycle_time
sv /analysis/zcp disable
cmd motive_ana /int_min/
prt_scl.cmd
save
build
verify
cmd motive_ana /int_min/x.cmd

Note that core.mcp , core.pin , and core.ref files reside in the motive_ana directory. One of the output files is core.trc . The x.cmd file is created at the same time as the batch.cmd file. The x.cmd file resembles the following:

sys get_vio motive_ana /int_min/core.rep
cmd motive_ana /int_min/y.cmd

--where get_vio is a user script that reads the tool's report file, finds all the timing violations, and writes a tw command for each into the y.cmd file (note the last command in y.cmd must be Quit ). ¹ Then, x.cmd recalls the data from y.cmd to do a detailed worst-case analysis of each violation, and it writes the results into core.trc . Note that pulse width violations are really hold violations, and they are specified as such in y.cmd . By creating x.cmd and by calling it from batch.cmd , a detailed worst-case trace of each violation can be obtained in a single MOTIVE run.

Necessities for the motive_ana directory

Other files that need to reside in motive_ana directory are listed and explained below. Their names are chosen by the author. core.ref A MOTIVE reference file for analyzing an ASIC's internal logic. Note that it should contain only clock(s) used by the internal logic and not by the JTAG circuitry. jtag.ref A reference file for analyzing the JTAG circuitry. Specify the JTAG clock in this file. io.ref A reference file for primary I/O analysis. It should contain the core.ref file plus all the TIN and TSH statements (see Note 1). cycle.def This file should contain MOTIVE analysis cycles for the internal logic and JTAG circuitry (see Note 2). buf.add This file should contain the buffer(s) to be inserted into Verilog netlist and SDF file for cases in Figure 1. (see Note 3) case.ana This file is for case analysis, which is very important for rooting out false paths and for doing many kinds of MOTIVE analysis (see Note 4). case.lib This is a special MOTIVE model library that contains all the special models for doing case analysis. core.mcp This is the multicycle path (MCP) file for rooting out false paths and doing multicycle analysis of internal logic. MCPs concerning JTAG circuitry should be in the jtag.mcp file because they are usually set up by the JTAG designer. jtag.mcp MCPs for JTAG logic, which is not part of ASIC's original design and can be analyzed by itself to cut down the number of false paths. abs.cmd This file contains all the tf commands for performing absolute path delay calculation (see Note 5). ext.v It creates the Verilog netlist, ext.v , that instantiates the ASIC and all its external component(s). It also treats this netlist as a "bigger ASIC" and analyzes it. ext.ref A reference file for "bigger ASIC" analysis (see Note 6). ext.mcp MCP file for "bigger ASIC" analysis. It should contain all the entries in core.mcp, plus entries for ASIC's external interface. .tim files These are MOTIVE models for an ASIC's external components, which are instantiated in ext.v . Makefile The MOTIVE environment introduced here is automated 100 percent. If a Makefile is used, it should be in the motive_ana directory. Note 1 To get a list of all the primary I/O pins, first run MOTIVE interactively on the entire design in either int_min or int_max subdirectory, and then use the View-> Design info...->I/O dependency feature. Note 2 The cycle.def file should resemble the following: internal_cycle : 20.0 jtag_cycle : 99.0 Write a script to read cycle.def , and set up a batch command file for each of the 10 subdirectories to run MOTIVE in batch mode. Note 3 Specify the buffer instance name, where it should be inserted, and whether the insertion should be in parallel or in series with an existing gate. To facilitate automation, buf.insertion can be empty if no buffer is inserted. > Note 4 Here are some of the common uses of case.ana : * It performs READ and WRITE analysis separately for internal RAM. * It performs bi-directional path analysis one direction at a time to avoid looping. * It uses a different MOTIVE model for a gate than the default model. One reason for this can be changing delay types from a non-clock propagator to a clock propagator for pulse width analysis. * It hides unused inputs of a gate from MOTIVE to root out false paths. * It specifies false paths that MCP can not (due to MCP limitations). Every gate specified in >case.ana must indicate where its special MOTIVE model resides, and it must indicate the case type. The special models should be in the case.lib file in the motive_ana directory. Note 5 An example of an abs.cmd entry resembles the following: tf source_part pin destination_part pin max_rising norefs --where norefs tells the tool not to stop at any CONST s or MCPs set for this path. Be careful not to specify a nonexistent path. For example, the MOTIVE model for a register should contain no delay path from data input pin d to data output pin q . If a specified path must go from d to q , then the tool can not trace it. Note 6 The ext.ref contains the same information as core.ref plus the information specific to the "bigger ASIC." Make sure each instance or net name has the right hierarchy, because ext.v instead of the original ASIC netlist is used here. Table 1 Analysis modes and directory cross reference MOTIVE subdirectories in the motive_ana directory File int_ int_ jtag_ jtag_ io_ io_ abs_ abs_ ext_ ext_ names min max min max min max min max min max core.ref X X X X jtag.ref X X io.ref X X cycle.def X X X X X X X X X X buf.add X X X X X X case.ana X X X X X X X X X X case.lib X X X X X X X X X X core.mcp X X X X X X jtag.mcp X X abs.cmd X X ext.v X X ext.ref X X ext.mcp X X *. tim X X Makefile X X X X X X X X X X

In batch.cmd , you should turn on reconvergence. Note, however, it does not work for pulse width analysis. This extra pessimism can cause false violations. The 20-ns analysis cycle time, /timebase/cycle_time variable, is arbitrarily chosen and should also be assigned to the internal_cycle variable in the cycle.def file.

Additional tips and tricks

Here are some additional tips and tricks: * Find out whether your ASIC vendor signs off designs on the tool: most vendors usually verify their results with their own proprietary timing tools prior to fabricating the chip. The key here is to do a small test case to find any mismatches in analysis results so that this verification stage will not cause grief later in the design flow. * Suppose the internal logic has two clocks, one with a 30-ns cycle time called clk_30.0 and the other with 90-ns cycle time (derived from clk_30.0 ) called clk_90.0 . Also suppose that clk_30.0 has plus or minus 0.3 ns of uncertainty and clk_90.0 has plus or minus 0.9 ns of uncertainty with respect to itself and plus or minus 10 ns of uncertainty with respect to clk_30.0 , then core.ref could resemble the following: GROUP source REFDEF clk_30 T CYDEF UP 0.0 0.0 DOWN 15.0 15.0 CYCLE 30.0 GROUP derived REF clk_90 T CYDEF UP 0.0 0.0 DOWN 45.0 45.0 CYCLE 90.0 ENDREF CLKGEN source source -0.3 0.3 CLKGEN derived derived -0.9 0.9 SKEWGEN source derived -10.0 10.0 The MOTIVE analysis cycle time for static analysis should be set to 90 ns. If the internal logic has only one clock, then use either CLKGEN or SKEWGEN . SKEWGEN automatically enables zero-cycle path (ZCP) detection, and CLKGEN does not. In addition, MOTIVE can not analyze phase-locked loop (PLL) in the ASIC. Therefore, use the PLL output as the clock reference in core.ref . * Currently, MOTIVE supports gate-level Verilog or EDIF netlist with a matching SDF file, but they are not directly used. Quad's vtran utility translates the netlist into the MOTIVE's pin file and sdf2mtv utility translates the SDF file into its control and interconnect delay data (idd) files. Quad's vtran does not support Verilog's 'include compiler directive. If a netlist consists of more than one file, they must all be specified on the command line. * Each gate in the ASIC design must have a MOTIVE model that is case sensitive: the case of pin names must match that used in the file containing gate delays to be backannotated, such as an SDF file. The tool has no concept of Z states (see figure), but if an SDF file contains output enable (oen) to pad Z state delays, they can be backannotated correctly if the model is set up correctly. For example, suppose a high transition on oen puts pad into Z state. To MOTIVE, this means that if the previous value of pad is low, then there is an oen high to pad high transition delay, which can be backannotated if the model contains oen to pad delay parameters. Tristate output

Now run MOTIVE in batch mode by typing in int_min :

amtv -c batch.cmd

At this time, you need to study and understand all the violations. You can run interactive MOTIVE using its graphical debugging utilities. If there are false or multicycle paths, then specify them in the MCP file. Usually, one MCP specification can eliminate more than one violation coming from the same source. This iterative process will consume most of your time.

You should continue the analysis for int_max in the same manner as for int_min .

The io_min and io_max subdirectories The primary I/O analysis, io_min and io_max , uses the entire database built in int_min and int_max . The batch.cmd file for io_min is similar to that of int_min , with the following important exception:

sv /file/ref " motive_ana /io.ref"

Note the use of the io.ref file. Now run amtv the same way in int_min .

The same process applies to io_max .

The jtag_min and jtag_max subdirectories For JTAG logic analysis, jtag_min and jtag_max use the database built in int_min and int_max . The batch.cmd file for jtag_min is similar to that of int_min , with the following important exceptions:

sv /file/mcp      " motive_ana/jtag.mcp"
sv /file/ref      " motive_ana/jtag.ref"
sv /timebase/cycle_time     99.0

Note the analysis cycle time, which should be the JTAG clock, is arbitrarily chosen to be 99 ns, and it should be assigned to the jtag_cycle variable in the cycle.def file.

The process is similar for jtag_max .

The abs_min and abs_max subdirectories To check abs_min and abs_max requirements, do the following:

• In the motive_ana directory, create the abs.cmd file to tell the tool to do an absolute delay trace for the desired edges of P1 , P2 , P3 , and P4 from their sources (see Figure 2). Save the results in the abs.trc file. The command file abs.cmd is used by both abs_min and abs_max .

• The abs_min and abs_max files. use the database built in int_min and int_max . The batch.cmd file for abs_min is similar to that of int_min , with the following important exceptions:

sv   /file/ref     " motive_ana /io.ref"
sv  /limit/ctime   0
cmd                 motive_ana /abs.cmd

The MCP file, if specified, can be overwritten by using norefs in abs.cmd . Either core.ref or io.ref can be used, but use io.ref if primary I/Os need to be included in this analysis. Finally, note that the /limit/ctime variable is set to "0," which means the tool can spend unlimited time on a path.

• In abs_min , create the abs.comp file, which resembles the following:

g1 (a < b) (skew = 0.25)

AND a rising     longest AND a falling    longest AND b falling    shortest

end g2 (a > b) (skew = -0.25)

AND a rising     shortest add_cycle AND a falling    shortest add_cycle AND b rising     longest

end

Write a script to process both abs.trc and abs.comp to find the timing relationship between AND.a and AND.b signals. In abs.comp , group g1 compares P1 to P3 (see Figure 2). Group g1 performs the following: It tells the script to find the max falling and rising delays of the AND.a path in abs.trc . It adds another 0.25 ns to the delays (indicated by skew = 0.25). It finds the min falling delay for AND.b path. Group g1 also tells you whether AND.a 's two delays are less than the delay of AND.b . Group g2 performs the following: It compares P2 to P4 . It tells the script to find the min falling and rising delays of AND.a path in abs.trc . Group g2 also subtracts another 0.25 ns from the delays, adds a full clock cycle to the delays (indicated by add_cycle because P2 occurs at the second clock cycle), and finds the max rising delay of AND.b. Finally, group g2 tells you whether AND.a 's two delays are larger than the delay of AND.b .

The process for abs_max is similar.

The ext_min and ext_max subdirectories The subdirectories ext_min and ext_max are used to analyze an ASIC's interface to its external components, such as RAM and other ASICs. In the example given here, only the interface between an ASIC's internal logic and its external components is analyzed. Therefore, the database in int_min and int_max is reused. The following is the process for ext_min :

• Run Quad's vtran on ext.v to create the pin file ext.pin , which should be put in motive_ana directory. The ext.pin will be used by both ext_min and ext_max .
  
• Take the core.mod file in int_min , and to each instance in it, add the top level hierarchy in ext.v . Call this new .mod file tmp.mod and put it in ext_min . Note that if scaling was done for IOPATH delays in int_min , it is saved in core.mod and is carried over to tmp.mod .
  
• Create a technology file with no scaling and put it in ext_min .
  
• Create a control file ext.ctl in the motive_ana directory that lists each external component once. It will be used by both ext_min and ext_max .
  
• Run Quad's mmp utility on ext.ctl , MOTIVE models of external components, and the technology file to create the tmp1.mod file; then put it in ext_min .
  
• Concatenate tmp.mod and tmp1.mod into ext.mod . The tool's .mod file has no INCLUDE statement.

  Figure 2. Points P1 and P2 are falling or rising edges of AND.a after the first clock and the second clock, respectively. P1 should always precede P3 with a required margin and P2 should always follow P4 with a required margin (signal AND.b has a pulse width requirement).

• Use Quad's XTK tool or Spice to analyze and calculate the net delays for the ASIC's external interface and come up with an .idd file called tmp1.idd. It should contain both min and max delays (max can be 120 percent of min). Put it in ext_min .
  
• Take the core.idd file in int_min and, to each instance in it, add the top-level hierarchy in ext.v . Call this new .idd file tmp.idd , which is put in ext_min .
  
• At this point, you need to know whether int_min had scaled the core.idd file during its analysis. If so, the scaled delays are not saved in core.idd . Write a script to scale the core.idd file in addition to adding the top-level hierarchy; then save the results in tmp.idd .
  
• Concatenate tmp.idd file with tmp1.idd into ext.idd and put it in ext_min . The tool's .idd file has no INCLUDE statement.

• The command file batch.cmd is similar to that of int_min , with the following important exceptions:

sv   /file/mcp      " motive_ana /ext.mcp"
sv   /file/net      " motive_ana /ext.pin"
sv   /file/ref      " motive_ana /ext.ref"

Note that the prt_scl.cmd in int_min is not included here, because net delays in ext.idd are scaled with a user script.

The process for ext_max is similar.

Due to limited space, the actual ext_min and ext_max analysis can be much more complicated than what was just described. For example, each can be divided into two subcases. For ext_min , there are fast ASIC (int_min) for slow external components, and fast ASIC (int_min) for fast external components. For ext_max , there are slow ASIC (int_max) for slow external components, and slow ASIC (int_max) for fast external components.

Each subcase will have a different MOTIVE database. Also, if the external components include RAM, each subcase can be further divided into separate READ and WRITE analyses. One purpose for creating different subcases is to reduce the number of false paths and to facilitate analysis.

References

Acknowledgments

I would like to thank Joe Quinlivan, Steve Barbas, Mike Homberg, and Clark M. Baker for their encouragement and their valuable suggestions on how best to use MOTIVE.

Luke L. Chang is a member of the CAE group at Ascom Nexion Inc. (Acton, MA).

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@asic.com.

integrated system design  September 1996