WO2001008028A2 - Timing shell automation for hardware macro-cell modeling - Google Patents

Abstract

An electronic design automation apparatus is provided. The apparatus includes processing circuitry, memory, a keyword symbol table, a macro-cell structural database, a timing shell generator, analysis circuitry, and an error and warning management unit. The memory is coupled with the processing circuitry. The keyword symbol table is stored in the memory. The macro-cell structural database includes timing constraints and I/O declarations of a macro-cell. The timing shell generator is implemented on the processing circuitry and is operative to generate a timing shell for a specific hardware macro-cell. The analysis circuitry includes a lexical analyzer operative to identify the placement of keywords, a syntactical analyzer operative to check syntax, and a semantic analyzer operative to verify meaning, wherein the analysis circuitry is implemented on the processing circuitry. The error and warning management unit is operative to detect and warn of circuitry errors detected during a test procedure. A method is also provided.

Description

DESCRIPTION

TIMING SHELL AUTOMATION FOR HARDWARE

MACRO-CELL MODELING

Cross-Reference to Related Application

This application claims the benefit of U.S. Patent Application Serial No. 09/359,594 filed 23 July 1999. Technical Field

This invention relates to apparatus and methods for delivering hardware macro- cells to third parties and, more particularly, to the development of timing shells for particular hardware macro-cells. Background Art

In the past, timing shells have been developed by hand because sometimes scripts are unreusable. A script is a program that operates on one or several input files and produces one or several output files. Among other things, it consists of the automation of one or several operations, tasks or transformations. Actually these operations or tasks are linked to input and output file formats. Moreover they are linked to a particular field of application or a project. For example, consider the case where you want to convert a file with hexadecimal characters in upper case to a file with hexadecimal characters in lower case. Hexadecimal characters consist of ' 1 ' to '9' plus 'A' to 'F'. When using script in this case, there is no need to convert letters other than 'A' to 'F'. So the script that converts only those characters will not convert upper case to lower case on a text file using all letters from 'A' to 'Z'. Thus it is performed on and for one particular application or project. From a software standpoint, the goal was to convert upper case to lower case. In some cases that goal is not reached. In these cases the script is unreusable and must be modified for another use. Although it is a simple example, it nevertheless shows that scripts are not generic. Let's take the example of a design flow. Once a design project is done, scripts are frozen and packaged with the whole design project database. They will allow anyone to reproduce the same results from the same input files. In the case of minor modifications, they will allow anyone to produce quite quickly some similar results taking into account these modifications. But these scripts may be unreusable for another project for the reasons quoted above. In a nutshell, scripts are not stand-alone programs, but are really specific to one application, and are not generic at all. It is for these reasons that they are unreusable. Modifying scripts can take a significant amount of time at each new application. Prior to modifying the script, it must first be understood. For large scripts, this can take a considerable amount of time. Besides, mixing script usage and development by hand to produce timing shells can result in human error increasing the number of timing inconsistencies. Thus such techniques take too long, and do not produce consistent enough results.

One prior art/background description of the above problem and field is provided in ModelGen Modeling specification from ARM ltd. (Advanced RISC Machines Limited), 90 Fulbourn Road, Cherry Hinton, Cambridge CB1 4JN, United Kingdom. When developing a hardware macro-cell, such as for a microprocessor, Digital Signal Processor (DSP), Phase Looked Loop (PLL), RAM, etc., for embedded use in a chip design that is being developed by a customer, it is necessary to provide the customer with a number of different kinds of models without giving away intellectual property (IP) details which you have developed. The main models that are usually delivered to a customer; e.g., a microprocessor manufacturer, are used in one or more computer aided design (CAD) steps such as simulation, synthesis, static timing analysis and timing driven "place and route".

Most of the time, synthesis, static timing analysis and timing driven place and route models are used as a "phantom" structure - - in other words, having the appearance of a functional circuit structure but without actual substance. In fact, such models only consist of a timing shell that helps other Computer Aided Design (CAD) tools by giving them timing constraints. Thus there is no functionality inside such phantom structure. In a nutshell, the presence of any intellectual property (IP) is lacking. However, all the above forms of timing shells need to be consistent at any step of a design process, and such consistency and accuracy requirement is oftentimes not met by prior art techniques.

According to another prior art technique, a simulation model consists of a timing shell that is placed around a functional model of a circuit structure. On one hand, the timing shell must be consistent with other timing shells at any step of a computer aided design (CAD) process. On the other hand, provision of a functional model is not protective of intellectual property (IP). In order to also realize intellectual property (IP) protection, either encryption or compilation must also be implemented.

As one example of the need for timing shell accuracy, in deep sub-micron technologies such as 0.25μm or 0.20μm, wire delays sometimes become greater than cell delays. In this case, timing shell accuracy becomes crucial in a design flow. The use of back-annotation, which uses a timing shell for simulation, is highly recommended for such technologies.

A design netlist consists of a set of standard cells and/or macro-cells connected together by some wires. On one hand, real wires have a delay associated with them. On the other hand, cells have internal delays (that are intrinsic to each cell). At that point, wires have no length or a predicted length. So they are associated with a null delay or a predicted delay. Simulations are run a first time to check the functionality of the design with these null or predicted delays. Then during the "Place & Route" phase, these cells are put at particular locations to build a physical database. Real wire length can now be extracted. So on account of physical parameters, real wire length and intrinsic cell delays, wire delays can be determined through a delay calculator. These calculated wire delays are put in a SDF (Standard Delay Format). Intrinsic cell delays are put in one particular timing shell used by a delay calculator. It allows calculation of wire delays. The SDF file must be linked to a simulation model through an HDL wrapper. That wrapper is also a timing shell. Back-annotation is a method to update wire delays in a design simulation from a SDF file through an HDL wrapper timing shell. The intrinsic cell's delays timing shell used by the delay calculator and the HDL wrapper timing shell must be consistent. Moreover, internal cell delays must be as accurate as possible in order to get accurate wire delays. They must also be consistent with other timing shells. Accuracy and consistency are the main goals. These goals were not achieved in prior art techniques during back-annotation.

In summary, when delivering a hardware macro-cell to customers, it is necessary to provide the customer with consistent timing shells at any of the steps of a computer aided design (CAD) process. Present prior art systems are found to be lacking when it comes to delivering consistent timing shells.

Additionally, timing shells must be realistic and as close to reality as possible. In order to achieve this requirement, a supplier of a timing shell oftentimes has to wait for the silicon-based characterization by a customer in order to fill in all the necessary timing shells. However, this creates significant delays in the design process besides timing shell development is quite huge and it takes longer to delivery the timing shell to the customer. As a result, time-to-market is significantly increase for the design process which is highly undesirable. As one example, for a macro-cell of 40k gates, 250 ports, almost 60 Setup/Hold checks, 8 Width checks, and 500 output delay paths are required. All timing shells for such example were done by hand and/or scripts which took almost 5-6 months. Additionally, significant human errors can underline such exemplary hand and/or scripts technique that affects the consistency of all timing shells. Accordingly, a significant delay is caused in the time-to-market for such a computer aided design (CAD) process.

Therefore, there exists a need to provide for consistent timing shells, improved techniques for generating such timing shells, and techniques for protecting intellectual property (IP) of a vendor when delivering such timing shells to a customer for use in design stages of a computer aided design (CAD) process. Disclosure of the Invention

A system and method are provided for generating timing shells suitable for macro-cell modeling within the field of Electronic Design Automation (EDA). Consistent timing shells are created in a relatively short amount of time which are suitable for macro-cell modeling for the design steps of simulation, synthesis, static timing analysis or timing driven "place and route". The provision of such timing shells for hardware macro-cell modeling for CAD tools results in consistent timing shells within a relatively short amount of time. Such technique is particularly suited for use with companies that supply libraries that license hardware macro-cells suitable for modeling with CAD tools. According to one aspect, an electronic design automation apparatus is provided. The apparatus includes processing circuitry, memory, a keyword symbol table, a macro- cell structural database, a timing shell generator, analysis circuitry, and an error and warning management unit. The memory is coupled with the processing circuitry. The keyword symbol table is stored in the memory. The macro-cell structural database includes timing constraints and I/O declarations of a macro-cell. The timing shell generator is implemented on the processing circuitry and is operative to generate a timing shell for a specific hardware macro-cell. The analysis circuitry includes a lexical analyzer operative to identify the placement of keywords, a syntactical analyzer operative to check syntax, and a semantic analyzer operative to verify meaning, wherein the analysis circuitry is implemented on the processing circuitry. The error and warning management unit is operative to detect and warn of circuitry errors detected during a test procedure. According to another aspect, a method is provided for generating and testing timing shells, comprising: performing a static timing analysis of a hardware macro-cell; storing timing constraints and I/O declarations in a first file; extracting electrical parameter names from the hardware macro-cell; storing the extracted electrical parameter names in a second file; filling the second file with the results are from the performed static timing analysis; listing operating conditions usable in deep-submicron technology in a third file; filling a single of common database by reading contents of the first, second and third files, and linking the contents together; and creating an output file from the unique database for a format required by a computer aided design (CAD) tool.

According to yet another aspect, a method is provided for generating consistent timing shells. This method comprises providing a hardware macro-cell; performing a static timing analysis of the hardware macro-cell; generating a list of timing constraints and I/O declarations for the hardware macro-cell; extracting a timing arc description file including generic electrical parameters from the hardware macro-cell; storing the generic electrical parameters in a characterization file; filling the characterization file with resulting values from the performed static timing analysis; generating a list of operating conditions usable in performing a static timing analysis of the hardware macro-cell; generating a database comprising the stored timing arc description file, the resulting values from the performed static timing analysis, and the list of operating conditions usable in performing the static timing analysis; and generating an output file from the database in a format usable by a computer aided design (CAD) tool.

One advantage results in that consistent timing shells are generated. Another advantage results in that intellectual property (IP) of a vendor, who supplies the timing shell(s) to a customer, is protected. Brief Description of the Drawings Preferred embodiments of the invention are described below with reference to the following accompanying drawings.

Fig. 1 is a schematic block diagram illustrating an electronic design automation (EDA) system using a timing shell generator tool of this invention for one or more stages of the design process for an integrated circuit (IC). Fig. 2 is a schematic block diagram depicting inputs, outputs and functional features of the timing shell generator tool of Fig. 1.

Fig. 3 is a development flow diagram for a macro-cell's timing shell.

Fig. 4 is a block diagram illustrating inout management showing a real macro-cell and a ModelGen™ (ARM Ltd)/IPguard™ (Escalade) macro-cell. Fig. 5 is a schematic diagram illustrating output delay timing.

Fig. 6 is a schematic diagram illustrating active wire and input for setup and hold, and a stable period.

Fig. 7 is a simplified schematic diagram for an exemplary circuit implementation.

Fig. 8 is a schematic block diagram illustrating one exemplary layout for a timing shell development. Best Modes for Carrying Out the Invention and Disclosure of Invention

Applicant's invention provides a solution to the above-described problems. From a consistency standpoint, it can be observed that all kinds of timing shells have essentially the same kinds of data. For example, input/output (I/O) declarations, capacitance, ramp factors, timing arcs (such as setup/hold checks, width checks, output delay paths), etc.. Therefore, a unique database can be used in order to obtain consistency.

In order to achieve the desired results, a common structure is filled from a unique macro-cell description. Such common structure reports timing shells according to any required format. The common structure is realized through a computer aided design (CAD) tool referred to as TimingShellGen that performs Timing Shell Automation. The common structure is used by this tool. By using TimingShellGen, all timing shells in a computer aided design (CAD) process can be generated and tested in one week, and a relatively high consistency level can also be realized concurrently. Figure 1 illustrates a computer aided design (CAD) process 10 utilizing a timing shell generator tool 12 of this invention. The present invention is a method and an apparatus for quickly and efficiently developing consistent timing shells for use in hardware macro-cell modeling. In the following description, numerous specific details are set forth, such as particular architecture, hardware configurations, etc., in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods and hardware configurations are not described in detail in order to not obscure the present invention.

It is understood that the present invention is comprised of an algorithm, hardware and a method that are readily implemented and manufactured using well known computer aided design (CAD) tools and methods. The detailed descriptions presented below are provided largely in terms of algorithms and symbolic representations of operations on data bits within a computer memory. Such algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to those skilled in the art.

The present invention addresses an inherent problem of providing consistent timing shells while at the same time hiding intellectual property (IP) from a customer that receives a timing shell for development purposes.

Figure 1 is a block diagram of an electronic design automation (EDA) system 10 utilizing a timing shell generator tool that incorporates the novel aspects of Applicant's invention and is identified by reference numeral 12. EDA system 10 is implemented on a computer system 14. A circuit designer 16 inputs a proposed integrated circuit design via an interface 18 and a system bus 20 to EDA system 10. A number of computer aided design (CAD) tools 22 are used by the designer 16 in order to design, layout and test a proposed design for an integrated circuit.

One problem encountered when designing, laying out, and testing a proposed integrated circuit design results from the fact that sub-components of an IC design are oftentimes designed by third party vendors 24, and these vendors desire to hide, or protect, the specific design of the subcomponent from view by the designer, or customer, 16. Pursuant to Applicant's invention, a novel timing shell generator, or TimingShellGen tool, 12 is used to generate consistent timing shells 26 that hide any proprietary design features, or intellectual property (IP) of the sub-component that is represented by the timing shell 26.

As shown in Figure 1, timing shell 26 includes timing constraints 28 and input output (I/O) declarations 30. Such timing shell is delivered from timing shell generator tool 32 of vendor 24 to computer system 14 of customer 16.

It is understood that electronic design automation (EDA) system 10 comprises a central processing unit (CPU) or processor, memory, and a data storage device. In one form, the memory comprises random access memory, read only memory, and a data storage device. In one form, the data storage device comprises a hard disk drive. The CPU is used to implement an operating system and application programs, such as an EDA program. Similarly, TimingShellGen tool 12 is implemented on a similar, separate computer system 32 controlled by vendor 24.

A designer, or customer, 16 receives a timing shell 26 from vendor 24 via a portable memory device, or via transmission over a network connection. Such timing shell 26 is then added to a proposed design for an integrated circuit (IC) which allows designer 16 to test the proposed IC design via CAD tools 22. More particularly, CAD tools 22 includes simulation tools 34, synthesis tools 36, static timing analysis tools 38, timing driven place-and-route tools, an "other tools using standard (STD) cell in ASIC design flow" 42.

As shown in Figure 1, designer 16 inputs design information into EDA system 10 via interface 18. Interface 18 comprises one or more of a keyboard 30, a cursor manipulating tactile input device, such as a mouse or a touchpad, a display device, or other input devices including voice recognition systems, joysticks, graphics tablets, data readers, card readers, magnetic and optical readers, other computer systems, etc. Designer 14 receives visual feedback on the design process via interface 18, such as with an output device comprising a graphics display terminal, such as a CRT display or a liquid crystal display. During synthesis and testing of a design, memory is used to store logic design information for an integrated circuit under design. A detailed description file is generated by computer system 14, and includes timing shell 26. The detailed description file comprises a netlist, including nets, for the design under consideration. Such detailed description file is then input into several EDA system programs that include CAD tools 22.

A technique for efficiently generating consistent timing shells 26 that hide intellectual property from designer 16 is implemented via timing shell generator tool 12, as described below in greater detail with reference to Figures 2-8.

The development of timing shells for a particular hardware macro-cell involves four steps. The second through fourth steps use the TimingShellGen tool of Applicant's invention. Accordingly, the TimingShellGen tool behavior is described below as discussed with reference to steps 2-4 and Figure 2.

Pursuant to a first step, a characterization is performed. More particularly, during the characterization all of the setup/hold checks, width checks and output delay paths of a device are found. As shown in Figure 2, "timing arcs" 44 refers to the collection of setup/hold checks, width checks and output delay paths. A "timing arc" comprises one or more timing constraints. Following such characterization, timing parameters are generic names. The I/O declaration consists of all I/O names, I/O capacitance names and I/O ramp factor names. For a hardware macro-cell, all the timing arcs and I/O declaration must be listed in a timing arc description file, or [td] file, according to a particular specification. Timing arc description file specification comprises timely constraints which are presently used in several commercial products and are presently understood in the art.

Pursuant to a second step, once a [td] file is performed, the TimingShellGen tool includes a particular option to create a characterization template file, or [tch] file. Lexicographic analysis is performed on the input [td] file. Accordingly, the tool recognizes key words from a lexicon and separates such key words from the input [td] file. The tool also gets rid of comments. However, neither syntax nor semantic analysis is performed. All timing parameter generic names, capacitance generic names, and ramp factor generic names from the [td] file are extracted and listed in a characterization template file. According to a third step, the [tch] file is filed with characterization values. More particularly, a value is attributed to each generic name; e.g., timing parameter, capacitance and ramp factor. Additionally, the following items are specified in the [tch] file: the model name of the hardware macro-cell, the operating conditions at which the characterization was done, and the technology used.

Pursuant to a fourth step, the [td] and [tch] files are used to generate all timing shells. The technology that has been specified in the [tch] file, according to the third step above, allows the identification of a derating factor file and an operating condition file. This data is useful for certain kinds of timing shells; e.g., for synthesis phantom timing shell applications. The model name that identifies such timing shell is used to name all output files that are created.

As described above, the second through fourth steps provide the TimingShellGen tool of Applicant's invention. Accordingly, a common structure is built and filled from a unique macro-cell description. Hence, a unique database is generated. The TimingShellGen tool works as follows:

A) Reading [td] file - This file performs lexicographic analysis on the [td] file. This file recognizes key words and gets rid of comments from the file. However, the syntax analysis is poor. The semantic analysis is exhaustive according to the timing arc description file. The file specifies the meaning of each sentence. Error and warning messages are printed whenever an irrelevant timing arc occurs. The file extracts all timing arcs, I/O declarations, plus clock attributes and tristate output attributes. The file also fills all the timing arc data into a database.

B) Reading [tch] file - This file performs lexicographic analysis on the [tch] file, as shown by blocks 54-56 of Figure 2. The file recognizes key words and gets rid of comments. Additionally, the file fills all the electrical parameters into an electrical parameter database 64, as shown in Figure 2, establishing a link between a generic name and an associated value.

C) Link [td] and [tch] file - These link files 66 link the timing arcs database 62 and electrical parameters database 64. The system checks to make sure that generic names present in the above two files match. Error and warning messages are printed when a mismatch occurs. A database which results is ready to be requested.

D) Reading derating factor file 48 and operating condition file 46 - The system performs lexicographic analysis 55, 56 on both of the above files. The system recognizes key words and gets rid of comments. E) Creating all timing shells 26 - The system extracts an output file from database 64 according to any kind of output format. Whenever, a particular format has a limitation, TimingShellGen prints a warning specifying the concerned limitation.

Figure 2 illustrates the behavior for the TimingShellGen tool. A summary is provided for how the tool operates on the timing arc description file (timing arcs) 44, the characterization file (parameter values) 46, and the derating factor files 48. According to one implementation, the TimingShellGen tool is written in C programming language. Timing shells 26 are used for simulation, synthesis, static timing analysis, or timing driven place-and-route design steps. As shown in Figure 2, a symbol table 50 and an errors management block 52 cooperate with timing arcs 44, parameter values 46 and derating factors (P,V,T) 48. In addition to the above, syntax analysis 58 and semantic analysis 60 are performed on the timing arcs 44. Consequently, output file generation block 68 generates timing shells 26. Additionally, lexicographic analysis block 54 generates a parameter template 70. With the use of the TimingShellGen tool, timing shells 26 can be generated and tested in a relatively short period of time, such as a week, with a relatively consistent level of performance under timing analysis.

Figure 3 illustrates development flow for generating a timing shell for a macro- cell 72. More particularly, timing arcs 44 and parameter values 46 are shown as independent inputs. When changing a technology, timing arcs 44 are still available for a given functional macro-cell 72. Parameter values 46 are given at a particular operating condition. The derating factors 48 allow a designer to derate from these values.

As shown in Figure 3, timing arcs 44 and parameter values 46 are independent inputs. When changing a technology, timing arcs 44 are also still available for a given functional macro-cell. Parameter values 46 are given at a particular operating condition. The derating factors 48 allow a designer to derate from these values. In use, all timing shells should be exhaustively tested. A back-annotatable HDL wrapper 76, a synthesis library 78, a place-and-route timing driven library 80, and a static timing analysis library 82 result from TimingShellGen tool 12, according to the original macro-cell 72. The simulation timing shell is a VITAL VHDL or verilog shell compliant with

Design Integrator™ (VLSI Technology). Other kinds of timing shell can be considered as phantom.

The following skills are required to develop, use and support such libraries quoted above: ■ Verilog and VHDL languages (IEEE), VITAL specification (IEEE), [sdfj format (IEEE). ■ ITS and STAMP modeling languages from Synopsys,

■ [pmd] format from VLSI Technology.

■ [tim] format from Avant!.

A. Limitations

Each output file format has its own limitations. Let's take the example of the Interface Timing Specification (ITS) language from Synopsys. At most, an input port can have one setup arc and hold arc with respect to any given clock port. From a STAMP model point of view, which is also a Synopsys language, it is not the case. Such limitations can affect the timing shell's consistency.

B. Conclusion Every person who is developing hardware macro-cell models for simulation, synthesis, static timing analysis and timing driven place and route could use this tool of Applicant's invention. Also, a designer who wants to create a "phantom" for any kind of sub-cell to speed up and/or increase the efficiency of a CAD tool could use this tool. Consistency and short development time are guaranteed. It can save several months of work.

TimingShellGen generator tool features A. Data requirements (Input files)

In order to create a timing shell for a macro-cell 72, it is first necessary that a characterization 74 be performed. During performance of the characterization, all setup/hold checks, width checks and output delays of a device need to be identified. Subsequently, all timing values, I/O port capacitance and ramp factors are measured. One suitable timing model for carrying out such measurement is Prop-Ramp. Prop-Ramp is a linear delay model. Such a delay model is also used by numerous other companies and its use is presently understood in the art. Prop-Ramp is the internal name used at VLSI Technology.

All timing arcs are then listed in a timing description file ([td] format). All values are put in a characterization file ([tch] format). Once a [td] file is performed, the TimingShellGen tool can be used to optionally create a [tch] template file. One technique is to fill in the template file manually. Details of how to create and fill such template file are described with reference to the TimingShellGen usage section described below. Additional details are described below with reference to the Timing Arc Description file specification section and Characterization file specification section. Additionally, the following two files are required: "k_factor.pr" and "synopsys.txt". The "k_factor.pr" file contains the "default_max_transition". The "synopsys.txt" file contains all operating conditions that have been characterized on a particular standard cell library; for example, the conditions of vscl083, which is a technology library available from VLSI Technology. It is a .20 micron @ 1.8V library. Both files may be used for synthesis or for static timing analysis timing shells. Even if your macro-cell is not standard cell based, the library's operating conditions and derating factors are still available as they refer to the same technology. Such files can be found in the Design Integrator package. See the TimingShellGen installation and usage section below for further details. See also the "k_factor.pr" file description and "synopsys.txt" file description below for further details.

B. Input files naming conventions

■ Suppose you want to create timing shells for a particular macro-cell, why not use the cell name for all files? (It is not compulsory but advised.)

■ The advised extension for the timing arc description file is: [td].

■ The advised extension for the characterization file is: [tch].

■ The "k factor.pr" and "synopsys.txt" files must have exactly the same name.

C. TimingShellGen advantages ■ It allows us to have a back-annotatable model around a zero delay model. The zero-delay model can be IP protected, but is not necessary. It only consists of the functionality of the macro-cell to be developed.

■ The automation belongs to the EDA field and thus saves considerable development time.

■ The two input files are independent. The [td] file can be considered as a constraint description file as it consists of timing arcs. The [tch] file contains timing values after characterization. So when porting a library, it is not worth modifying the [td] file that is intrinsic to the macro-cell.

■ Every kind of timing shell (Simulation, Synthesis, Static Timing Analysis, Timing Driven P&R) comes from the same two files. Thus, the model's consistency increases significantly.

D. TimingShellGen installation and usage

1) Installation

%> set path = ( $path <directory path of TimingShellGen executable> )

2) Environment setting ■ Set the PRODUCT_SYNOPSYS_DIR environment variable to point to a directory containing the two files: "k_factor.pr" and "synopsys.txt". The "k_factor.pr" file contains the "default_max_transition". The "synopsys.txt" file contains all operating conditions that have been characterized on a particular standard cell library (example: vscl083). Both files may be used for synthesis or static timing analysis timing shells. The directory name in which you can find out these two files is specified by the

"CELL_LIBRARY" string parameter of the characterization file. See characterization file specification. Example:

%> setenv PRODUCT_SYNOPSYS_DIR

/tools2/DIVerilog/v2.0pd/DIVerilog/system/product

■ Set the TIMINGSHELLGEN_TMP_DIR environment variable to point to a temporary directory used by TimingShellGen tool. If not set, /var/tmp directory is used.

Example:

%> mkdir tmp dir (In your current working directory)

%> setenv TIMINGSHELLGEN_TMP_DIR ./tmp_dir

3) Usage

Usage: TimingShellGen -help

Print this message

TimingShellGen my_cellname.td -create_tch

Create a file named "template.tch". You will have to fill it in with parameter values from characterization or static timing analysis. That file matches the input [td] file for later use. Move it to

"my_cellname.tch".

TimingShellGen my cellname.td my_cellname.tch Create all timing shell source files.

4) Errors - warning messages

TimingShellGen helps by printing a few error/warning messages. See Appendix

A below.

E. Output files created Output file names use the "MODEL_NAME" string parameter from the [tch] file.

See characterization file specification. The advised "MODEL_NAME" is "my_cellname".

Otherwise, file extensions ([pmd], [vhd], [v], [mod], [data], [lib]) are set by default by the TimingShellGen tool. Following is a list of all the output files and their names, with extension files being shown in bold character: my_cellname.pmd ([pmd] for simulation) my_cellname.vhd (VITAL VHDL wrapper) my cellname.v (verilog timing wrapper) my_cellname.mod ([mod] source file for STAMP model) my_cellname.data ([data] source file for STAMP model) my_cellname_longpath.lib ([lib] source file for ITS model with longest paths) my_cellname_shortpath.lib ([lib] source file for ITS model with shortest paths) my_cellname_simplified.pmd ([pmd] for Static Timing Analysis)

OUTPUT FILES EXPLOITATION

A. Simulation

1 ) Back-annotation Simply include "my_cellname.pmd" in an existing library or create a new one.

Be sure Delay Calculator from Design Integrator is able to find it. VLSI Technology's Delay Calculator uses an option file that specifies the directory where my_cellname.pmd file can be found, but it depends on the delay calculator that is being used. Other delay calculators are also known in the art. 2) VHDL wrapper

The "my cellname.vhd" file is only a VITAL interface without any functionality being provided inside. The VITAL interface is compliant with standard VITAL ASIC Modeling specification IEEE 1076.4, October 1995. The goal is usually to put that interface on a zero-delay functional model. That interface is fully compliant with ModelGen™ or IPguard™ tool: Actually the port list of the VITAL interface is compliant as regards inout management (inout is split into two ports: an input port, or pin, and an output port, or pin). The output pin has the same name as the original port; the input pin has the same name as the original port, but is appended with "xmgxread". See Figure 4 as described below for further details. Figure 4 illustrates inout management showing a real macro-cell 72 and a

ModelGen/IPguard macro-cell 86. That interface contains a foreign language interface

(FLI) that calls an executable output file from ModelGen™ or IPguard™ as follows:

Architecture CLI of my_cellname_functionality is attribute foreign: string; attribute foreign of CLI: architecture is

"vsystem_DEVICE_ms_elaborate $DIR_DEVICE/DEVICE.o"; begin

— nothing end CLI; Change the call's device name as you want. When running simulation, do not forget to set the $DIR_DEVICE environment variable. Do not forget also to map the VITAL primitive library before simulating.

Although that interface is fully compliant with ModelGen™ or IPguard™ tool, it is still possible to use the same VITAL interface for any kind of architecture (behavior, RTL, structural, mixed). Be aware of the inout management quoted above. 3) Verilog wrapper my_cellname.v B. Synthesis TimingShellGen creates two files: "my cellname longpath.lib" and

"my_cellname_shortpath.lib". These two [lib] files are ITS (Interface Timing Specification) models from Synopsys. They are compiled using DesignCompiler™, which is a Synopsys tool available from Synopsys, Inc., 700 East Middlefield Road, Mountain View, CA 94043-4033, USA, as detailed below to create a [db] files format:

"dc_shell> read_lib my cellname ongpath.lib" "dc_shell> write_lib my_cellname_longpath" It creates "my_cellname_longpath.db" file.

"dc_shell> read lib my_cellname_shortpath.lib" "dc_shell> write lib my_cellname_shortpath"

It creates "my_cellname_shortpath.db" file.

Both [db] libraries consist of a unique cell named "my cellname".

Below is a brief explanation of the difference between

"my_cellname_longpath.db" and "my_cellname_shortpath.Iib". Conceptually, following the immediate prediction of a new output value in response to input changes, the value of the output remains unchanged for a period of time, potentially becomes unknown for a further period of time, then finally settles at the predicted value. See Figure 5 below for further explanation. The files "undef_starttime" and

"def_starttime" are explained in the timing arc description file specification below. This is useful when a particular kind of gate is switching from 0 to 1 or 1 to 0 while the input signal ramp is weak. In that case, on account of the switching threshold, the transition time can be quite big. If the output is well buffered, then there is no use for such feature. Nevertheless, the use of "undef_starttime" is optional, or you can even put the same value for both parameters. Figure 5 illustrates output delay timing. The file "my_cellname_longpath.db" should be used to synthesize in a first step. It allows us to check setup time requirements. Accordingly, "my_cellname_shortpath.db" can be used to do incremental synthesis and to check hold time requirement. C. Timing Driven Place and Route

The file "my_cellname_longpath.lib.file" is used by default, and timing reports are performed under Design Compiler™.

"dc_shell> read lib my_cellname_longpath.lib" "dc_shell> report_lib -timing my_cellname_longpath > my_cellname_longpath.rpt"

The [rpt] file can be used to create a [tim] directory for Apollo™ Timing

Driven P&R (Avant! tool). D. Static Timing Analysis

TimingShellGen creates "my_cellnamejnod" and "my_cellname.data" that are two source files to create a STAMP model. It creates also a particular [pmd] named

"my_cellname_simplified.mod" to back-annotate the STAMP model. STAMP model is a synopsys language dedicated to do static timing analysis under PrimeTime™ (Synopsys tool). pt_shell> compile_stamp_model

-model file <my_cellname.mod> -data_file <my_cellname.data> -output <my_cellname> -library cell

It creates "my_cellname_lib.db" file. That [db] file consists of "my_cellname" model as a library cell.

As a note, since the timing shell has no functionality, conditional timing arcs based on internal signals cannot be handled. So worst case values are taken whatever the conditions. To match such a timing shell, a special [pmd] was necessary. TIMING ARC DESCRIPTION FILE SPECIFICATION A. Syntax

1) Naming convention ■ Sensitivity: The Timing Arc Description file is case-insensitive.

■ Key words: Here below is the list of key words used in a Timing

Arc Description file. They must be used at some particular places. See BNF language for more details. Besides, be careful that having the port name of your device in the list below may cause problems. INPUT, OUTPUT, INOUT, STATE, DELAY, RISING, FALLING, HL, HZ, LH, LZ, ZH, ZL, IF, WHEN, CHECK, STABLE, HIGH, LOW, WIDTH, PERIOD.

Choose a meaningful name for capacitance, ramp-factor and timing parameters.

Device's port must not have any '_' character. Actually the '_' character is used as a separator in the timing generic statements of

VITAL interface. It could be badly interpreted and simulators usually claim mismatches anyway during back-annotation.

BNF language timing_description_file ::= timing_statement* timing_statement ::= timing_declaration

I I = input_check

I I = width_check

1 1 = output_delay timing_declaration ::= signal_declaration

I I = state_declaration signal_declaration ::= INPUT hdl_port bit_range? capacitance;

I I = OUTPUT hdl_port bit_range? capacitance ramp_factor; 1 1 = INOUT hdl_port bit_range? capacitance ramp_factor; state_declaration ::= STATE state ist; state_list ::= state_name

1 1 = statejist, state_name output_delay ::=DELAY hdl_port { delay_condition+ } delay_condition ::= oedge { transition_list+ } condition_at_end?

1 1 = oedge delay_spec condition?; oedge ::= oedge_spec? hdl_port oedge_spec ::= RISING

| | = FALLING transition_list ::= tran delay_spec; tran ::= transition

1 1 = tran, transition transition ::= HL

1 1 = HZ | | = LH | | = LZ | | = ZH | | = ZL delay_spec = undef_timename? def_timename condition_at_end = condition; condition = IF cond_expr 1 1 = WHEN cond_expr I j = IF cond_expr WHEN cond_expr cond_expr ::= cond_expr | cond_term I I = cond_term cond_term ::= cond_term & con d_f actor

I I = cond_factor cond_factor ::= cond_prim

| | = ~ cond_factor cond_prim ::= state_name

I I = hdl_port j j = (cond_expr) input_check :: = CHECK hdl_port { input_condition+ } input_condition : : = iedge setup_timename hold_timename range_checks 1 1 = STABLE condition_at_end iedge ::= iedge_spec hdl_port iedge_spec ::= RISING I I = FALLING I j = HIGH

I j = LOW range_checks ::= condition?

I I = { bit_range_check+ } bit_range_check ::= bit_array condition?; bit_array ::= [natural]

1 1 = bit_range bit_range ::= [natura natural] width_check ::= WIDTH hdl_port { width_cond+ } width cond ::= LOW timename condition?; 1 1 = HIGH timename condition?; = PERIOD timename condition?; hdl_port = string capacitance = string ramp_factor = string state_name = string setup_timename = timename hold timename = timename undef_timename = timename def_timename = timename timename = string Comments may be introduced using /* and continue until */ is encountered. Line comments may be introduced using # and continue to end of line. Comments are replaced by white space. All tokens may be separated by white space or carriage return.

In the above description, a field followed by the '?' character means it is optional. A field followed by the '+' character means you can specify as many running fields as you want (at least once). A field followed by the '*' character means you can specify zero or several statements. B. Semantic

1) Signal declaration ■ Complete port list is required

■ Although some ports have no output delay statement or no Setup/Hold check statement or no Width check statement, they must still be declared.

2) Output timing delays All outputs should be given exactly one delay under all circumstances.

Some simulators emit warnings if an output occurs for which no applicable delay can be determined; others may simply output the transition with no delay, or show some other behavior. The delay applied is unpredictable if at any time an output signal is subject to more than one clause. ■ Only OUTPUT hdl_port or INOUT hdl_port may be delayed in output delay statements.

■ You cannot specify a timing arc from a bus to a pin.

■ You cannot specify a timing arc between two buses having different widths. ■ Output delays between two buses are considered as bitwise.

Let's call the startpoint of a path "from_port", and the endpoint of a path "to_port". The "to_port" may change its value on either RISING edge or FALLING edge of the "from_port". If no edge is specified, it means the "to_port" may change its value whatever the edge of the "from_port" (rising and falling, and only RISING and FALLING: no other "from_port" transition can be specified). The timing description file does not allow us to handle 'X'. Only following transitions as regards "to_port" can be described: 01, 10, 0Z, Zl, 1Z, Z0.

A transition for the "to_port" can be specified. It can belong to {HZ, LZ, ZH, ZL, HL, LH}. If no transition is specified, it means the transition can either be HL, LH, or both. If the transition is specified and belongs to {HZ, LZ, ZH, ZL}, the "to_port" is considered as tri-state output (only if it is an output).

Conceptually, following the immediate prediction of a new output value in response to input changes, the value of the output remains unchanged for a period of time, potentially becomes unknown for a further period of time, then finally settles at the predicted value. Here we find the utility of the optional "undef_timename" field. This is useful when a particular kind of gate is switching from 0 to 1 or 1 to 0 while the input signal ramp is weak. In that case, on account of the switching threshold, the transition time can be quite large. If the output is well buffered, there is no use for that. See Figure 5, which illustrates output delay timing.

3) Width checks

The only transition sequences that give well-defined behavior are 1-0-1 and 0-1-0.

■ Only INPUT hdl_port and INOUT hdl_ρort may be used in width check statements.

■ Width checks specify the minimum time between certain transitions on an hdl_port: their primary use is to check signals used for clocking.

PERIOD This check specifies two independent checks: one between successive transitions to 1, and the other between successive transitions to 0.

LOW This check requires that when the hdl_port makes a transition to 0, it must stay there for at least the time specified.

HIGH This check requires that when the hdl_port makes a transition to 1, it must stay there for at least the time specified. 4) Input checks

It is neither a requirement that all inputs be checked, nor that an input be checked under all circumstances. The input should be stable for a period of time near to the edge transition of an active wire. Either the setup or the hold time may be negative (subject to the constraint that the sum of the two is greater than zero). Be aware of the fact that some tools can have trouble with negative values. See Figure 6 below, which illustrates the setup and hold check.

■ INPUT hdl_port and INOUT hdl_port may be used in input check statements. ■ An hdl_port referencing a Setup/Hold check must be a pin and not a bus.

■ An hdl_port referencing a Setup/Hold check must be INPUT. Let's call "ref_port" the hdl_port used for reference, and "test_port" the hdl_port to check. These checks require the "test_port" to be invariant during a specified time interval relative to a change, or changes, on the "ref_port". Five types of checks are possible.

RISING check It is performed when the "ref_port" rises.

FALLING check It is performed when the "ref_port" falls. HIGH check Setup time applies to the rising edge of the "ref_port". The Hold time applies to the falling edge of the "ref _port". While "ref_port" is high, the "test_port" must remain stable.

LOW check Setup time applies to the falling edge of the "refjport". The Hold time applies to the rising edge of the "ref_port". While "ref_port" is low, the "test_port" must remain stable.

STABLE check It indicates that the "test_port" must be held stable if the condition holds.

Rising transition is defined as a transition from 0 to 1. Falling transition is defined as a transition from 1 to 0. The effects of other transitions such as from 0 to Z are implementation dependent. One must be careful of that.

Input timing checks can be applied to wires, whole buses and sub-ranges of a bus provided. To check a single bit of a bus, or a bus sub-range, the bit_range_check form of range_checks must be used. When specifying a bus sub-range, the format is always [high:low], for a single bit use [bit]. 5) Conditions

We can declare internal signals through a STATE declaration. This state_name can be either a pin or a bus. They may be used only in conditional timing arc. However, if the timing shell will not envelop a model with functionality inside, internal signals are unknown, thus not usable. It is why conditions can be specified either for a timing shell dedicated to envelop a model with functionality or for a stand-alone timing shell with no functionality inside. Conditions can start with key word "IF" or with key word "WHEN", or they can contain both key words. Timing shell to envelop a model with functionality will use condition behind "IF". You can use INPUT hdl_port pin, OUTPUT hdl_port pin, or state_name pin. Buses are not allowed, even a bit of a bus. INOUT are also not allowed. A stand-alone timing shell will use condition behind "WHEN". You can use only INPUT hdl_port pin. CHARACTERIZATION FILE SPECIFICATION A. Syntax

1) Naming convention

■ Sensitivity: case sensitive.

■ Key words: Below is the list of key words used in characterization file. They must be used at some particular places. See BNF language for more details. MODEL_NAME, CELL_LIBRARY,

S I M _ S C A L E , V D D , T E M P E R A T U R E , PROCESS_DERATING_FACTOR, timing:, ramp_factor:, capacitance:, rise_, fall_, =.

■ Choose a meaningful name for capacitance, ramp-factor and timing parameters.

2) BNF language characterization_file ::=MODEL_NAME = string

CELL_LIBRARY = string SIM_SCALE = float operating_conditions timing_declaration* ramp_factor_declaration* capacitance_declaration* operating_conditions ::= VDD = float PROCESS_DERATING_

FACTOR = float TEMPERATURE = float timing_declaration ::= timing: timename = float timename ::= string ramp_factor_declaration ::=ramp_f actor: rise_<ramp_name> = float ramp_f actor: fall_ < r amp_name > = float

<ramp_name> ::= string capacitance_declaration ::= capacitance: capacitance_name

= float capacitance_name ::= string

10

Line comments may be introduced using # and continue to end of line. In the above description, a field followed by the '?' character means it is optional. A field followed by the '+' character means you can specify as many running fields as you want (at least once). A field followed by the '*' character means you 75 can specify zero or several statements.

B. Semantic

1) MODEL NAME

It may be the product name, the part number or what you want. It reflects the product itself and not only the functionality. It allows us to make the

20 difference between two macro-cells having the same functionality but mapped on different technologies. For example: WF7102 and WF7103. They both have the functionality of ARM7TDMI but they are mapped on different technologies. Also for example: VYF86C07903 and VYF86C07_301. They both have the functionality of ARM7TDMI, but the first one is custom based, the second one is standard

25 cell based. The model name will be used to name all output files. The output files' name corresponds to the MODEL_NAME string converted in lower case concatenated with an extension ([pmd], [mod], [data], [lib], ... ).

Example:

VVF7103 --> Output [pmd] file name: wf7103.pmd 30 vyf86c07_301~> Output [pmd] file name: vyf86c07_301.pmd

2) CELL LIBRARY

It is the name of the standard cell library on which the macro-cell is mapped. Example: vsc983, vscl083. It is linked to the technology (example: 35 vcmn3a3). But it is important to specify the cell library because each library has its own derating factor corresponding to one particular operating condition around which it was characterized. Thus for a custom based macro-cell, specify also the standard cell library which has the same channel length (0.20 μm for example) and which was characterized around the same operating conditions. That string parameter is used to find out the directory name where k_factor.pr and synopsys.txt files are located.

3) SIM_SCALE

That float value allows us to get rid of decimals for timing and ramp factor values. When specifying timing values in nanoseconds, the common SIM_SCALE value is set to 100.

4) Operating conditions

■ VDD is voltage used for the macro-cell characterization.

■ TEMPERATURE is the temperature used for the macro-cell characterization.

■ PROCESS_DERATING_FACTOR is the process derating factor used for the macro-cell characterization. Example for standard cell library vscl083:

5) timing declaration The timing parameter is a string that must match with the Timing Arc

Description file.

Example: timing: tS = 23

The parameter tS must be found in the corresponding [td] file. Be careful of the unit! It is in ns*SIM_SCALE. Suppose SIM_SCALE is set to 100, so it means that tS corresponds to 0.23 ns.

6) ramp factor declaration

For all output ports or inout ports, you must specify a rise ramp factor and a fall ramp factor. The rise ramp factor name must start with rise_. The fall ramp factor name must start with fall_. The unit is ns/pf * SIM_SCALE. Example: ramp_f actor: fall Rq = 241 ramp_factor: rise Rq = 272

Suppose SIM_SCALE is set to 100, so it means that fal l_Rq equals 2.41 ns/pf and rise_Rq equals 2.72 ns/pf. 7) capacitance declaration

The unit is pf. Example: capacitance: Ca 0.001

C. Example

#Tri-state non-inverting buffer with output enable characterization file begin.

MODEL_NAME BUFFER CELL LIBRARY vsc783

# SIM_SCALE must be 100, Do NOT change this!

SIM_SCALE 100 # 1 < = > 0.01 ns

# Operating conditions VDD 3.3 # Volt

PROCESS_DERATING_FACTOR 1 TEMPERATURE 25 # Celsius Degrees

# Timings. Unit (ns*SIM_SCALE) timing: TfromzZH 23 timing: TfromzZL 7 timing: TtozHZ 22 timing: TtozLZ 0 timing: tZHL 30 timing: tZLH 34

# Ramp factors. Unit (ns/pf * SIM_SCALE) ramp_factor: fall_Rz 106 ramp_factor: rise_Rz 123

# Pin Capacitance in pf capacitance: Ci 0.021 capacitance: Coe 0.042 capacitance: Cz 0.029

#Tri-state non-inverting buffer with output enable characterization file end. k factor.pr file specification A. Syntax

1) Naming convention

■ Sensitivity: case sensitive.

■ Key words: All words used in k_factor.pr file are key words. Find below a template to fill in to get such a file. 2) File template

# k_factor.pr file begin default_fanout_load < float > default_output_pin_cap < float > default_input_pin_cap < float >

# In nanoseconds default max transition < float >

# Propagation and Transition

# Kp_ramp k_process_intrinsic_rise < float > k_process_intrinsic_fall < float > k_process_drive_rise < float > k_process_drive_fall < float >

# Kv_ramp k_volt_intrinsic_rise < float > k_volt_intrinsic_fall < float > k_volt_drive_rise < float > k_volt_drive_fall < float >

# Kt_ramp k_temp_intrinsic_rise < float > k_temp_intrinsic_fall < float > k_temp_drive_rise < float > k_temp_drive_fall < float >

# Setup and Hold k_process_hold_rise < float > k_process_hold_fall < float > k_process_setup_rise < float > k_process_setup_fall < float > k_volt_hold_rise < float > k_volt_hold_fall < float > k_volt_setup_rise < float > k_volt_setup_fall < float > k_temp_hold_rise < float > k_temp_hold_fall <float> k_temp_setup_rise < float > k_temp_setup_fall < float >

# Recovery k_process_recovery_fall < float > k_process_recovery_rise < float > k_volt_recovery_fall < float > k volt recovery rise < float > k_temp_recovery_fall < float > k_temp_recovery_rise < float >

# Minimum Pulse Width k_process_min_pulse_width_high < float > k_process_min_pulse_width_low < float > k_volt_min_pulse_width_high < float > k_volt_min_pulse_width_low < float > k_temp_min_pulse_width_high < float > k_temp_min_pulse_width_low < float >

# Minimum Period kjprocess_min_period < float > k_volt_min_period < float > k_temp_min_period < float >

# Interconnect k_process_pin_cap < float > kjprocess_wire_cap < float > k_process_wire_res < float > k_volt_pin_cap < float > k_volt_wire_cap < float > k_volt_wire_res < float > k_temp_pin_cap < float > k_temp_wire_cap < float > k_temp_wire_res < float >

# k_factor.pr file end

Line comments may be introduced using # and continue to end of line. B. Semantic

The default_max_transition parameter is compulsory and used for the static timing analysis timing shell (STAMP model). All other parameters are optional and may be used by synthesis tools. See Synopsys library compiler main pages. synopsys.txt file specification A. Syntax

1) Naming convention

■ Sensitivity: case sensitive. Key words: Here below is the list of key words used in synopsys.txt file. They must be used at some particular places. See BNF language for more details: begin_timing_range, end_timing_range, process, temperature, voltage, tree_type, begin_operating_conditions, end_operating_conditions, faster_factor, slower_factor, balanced_tree, best_case_tree, worst_case_tree. Choose a meaningful name for timing range name and operating condition names.

2) BNF language synopsys_txt_file comments? timing_range_block comments? operating_conditions_block comments? comments string* timing_range_block begin_timing_range timing_range_ssblock + end_timing_range timing_range_ssblock timing_range_name faster_factor smallest_value slower_factor greatest_value timing_range_name string smallest_value float greatest_value float operating_conditions_block begin_operating_conditions operating_conditions_ssblock + end_operating_conditions operating_conditions_ssblock operating_conditions_name process process_derating_factor temperature temperature_value voltage voltage_value tree_type tree_kind_name operating_conditions_name string process_derating_factor float temperature_value float voltage_value float tree kind name balanced_tree 1 1 = best_case_tree 1 1 = worst case tree

Comments are allowed only outside timing_range_block or operating_conditions_block statements. In the above description, a field followed by the '?' character means it is optional. A field followed by the '+' character means you can specify as many running fields as you want (at least once). A field followed by the '*' character means you can specify zero or several statements. B. Semantic

1) Operating conditions group

The operating condition name identifies the set of operating conditions.

Names of all operating conditions groups must be unique within a library. The operating conditions groups are useful for testing timing and other characteristics of your design in predefined simulated environments. The following attributes are defined in an operating condition group:

■ process: The scaling factor accounts for variations in the outcome of the actual semiconductor manufacturing steps, typically 1.0 for most technologies. The multiplier is a floating-point number from

0 through 100.

■ temperature: The ambient temperature in which the design is to operate, often 25 degrees Celsius (room temperature). The value is a floating-point number from -300 through +500.

■ voltage: The operating voltage of the design. The value is a floating-point number from 0 through 1000, representing the absolute value of the actual voltage

■ tree_type model: It defines the environment interconnect model.

Synthesis tools (For example: Design Compiler™ (Synopsys)) uses the interconnect model to select the formula for calculating interconnect delays. The model is one of the following: a) best_case_tree: Models the case where the load pin is physically adjacent to the driver. In the best case, all wire capacitance is incurred, but none of the wire resistance must be overcome. b) balanced_tree: Models the case where all load pins are on separate, equal branches of the interconnect wire. In the balanced case, each load pin incurs an equal portion of the total wire capacitance and wire resistance. c) worst_case_tree: Models the case where the load pin is at the extreme end of the wire. In the worst case, each load pin incurs both the full wire capacitance and the full wire resistance.

2) Timing range group

A timing range group models statistical fluctuations in the defined operating conditions defined for your design during the synthesis optimization process. A timing range group defines two multipliers that scale the signal arrival times computed by a timing analyzer when it evaluates timing constraints. The following attributes are floating-point number:

■ faster_factor: It is the scaling factor applied to the signal arrival time to model the fastest possible arrival time.

■ slower_factor: It is the scaling factor applied to the signal arrival time to model the slowest possible arrival time.

Example

# synopsys.txt file begin. begin_timing_range

FAST_RANGE faster_factor 0.595 slower_factor 1.0

SLOW_RANGE faster_factor 1.0 slower_factor 1.64 end_timing_range begin_operating_conditions

TYP process 1.0 temperature 25 voltage 3.3 tree_type balanced_tree

WCMAX process 1.247 temperature 140 voltage 3.0 tree_type balanced tree end_operating_conditions If- synopsys.txt file end.

EXAMPLE

A. Macro-cell schema

This example consists of a combinatory part and a sequential part. The sequential part is a buffered positive-edge triggered D flip-flop with active-low clear,

CDN. Data present at the D input during the positive edge of the clock, CP, is transferred to Q. The combinatory part is a tri-state non-inverting buffer with active high enable. Figure 7 illustrates a "flip" cell schema. Let's call "flip" the cell in our example. B. Timing Arc Description file

The cell name can be used for all files. The [td] file will be named "flip.td". Choose meaningful names for capacitance, ramp-factor and timing parameters.

# flip.td file begin.

# I/O Declaration

INPUT D Cd;

INPUT CP Ccp; INPUT CDN Ccdn;

INPUT OE Coe;

OUTPUT Q Cq Rq;

OUTPUT Z Cz Rz; # Width Check

WIDTH CP

{ high Tcph IF CDN; low Tcpl IF CDN;

}

WIDTH CDN

{ low Tcdnl;

}

# Setup/Hold Check CHECK D

{ rising CP tS tH IF CDN;

} CHECK CDN

{ rising CP trelC tHC;

} # Output Delay

DELAY Q

{ rising CP {LH tQLH; HL tQHL;} falling CDN {HL tCQ;}

}

DELAY Z { rising D {LH tZLH;} falling D {HL tZHL;} rising OE {ZH TfromzZH; # Enable

ZL TfromzZL;} falling OE {LZ TtozLZ; # Disable

HZ TtozHZ;}

}

# flip.td file end

C. Characterization template file generation

Execute instructions as follows: %> mkdir my_library

You will create later in that directory k factor.pr and synopsys.txt files. Both files may be used for synthesis or static timing analysis timing shells as they consist of operating conditions and derating factors.

%> setenv PRODUCT_SYNOPSYS_DIR pwd'

%> mkdir tmp_dir

%> setenv TIMINGSHELLGEN_TMP_DIR ./tmp_dir

%> TimingShellGen flip.td -create_tch

%> mv template.tch flip.tch

TimingShellGen creates a file named "template.tch". Move that file in "flip.tch" and fill it with values. So far the [td] file deals only with timing arcs and is generic as regards any technology. Now in our example we will fill values according to 0.5 μm technology. Values are taken at typical operating conditions (3.3V, typical process, 25°C). Let's take values from ntOldl cell from vsc783 for the non-inverting tri-state buffer. Let's take values from dfctnqO cell from vsc783 for the positive-edge triggered D flip-flop. Here below is the resulting "flip.tch" file.

###############################################################

# #

# #

# Technology File: flip.tch #

# Revision File: vl .O #

# #

# Functional Core Name: D flipflop and 3-state buffer #

# Physical Implementation: standard cell based #

# #

# VLSI Part Number: NA #

# Technology: vcmn5 (.5um) #

# #

# Typical Voltage: 3.3 V #

# #

# All values are extracted vsc783 Data Sheet #

# from: (characterization) #

# #

###############################################################

MODEL NAME FLIP

CELL_LIBRARY = my_library

# SIM_SCALE must be 100, Do NOT change this!

SIM SCALE 100 # 1 <=> 0.(

# Operating conditions

VDD 3.3 # Volt

PROCES S_DERATING_FACTOR 1

TEMPERATURE 25 # Celsius Degrees

# Timings. Unit (ns*SIM_SCALE) timing: Tcdnl 50 timing: Tcph 16 timing: Tcpl 36 timing: TfromzZH 23 timing: TfromzZL 7 timing: TtozHZ 22 timing: TtozLZ 0 timing: tCQ 30 timing: tH 5 timing: tHC 47 timing: tQHL 73 timing: tQLH 63 timing: tRelC 0 timing: tS 23 timing: tZHL 30 timing: tZLH 34 # Ramp factors. Unit (ns/pf * SIM_SCALE) ramp_factor: fall_Rq 241 ramp factor: fall_Rz 106 ramp_factor: rise_Rq 272 ramp_factor: rise Rz 123

# Pin Capacitance in pf capacitance: Ccdn 0.038 capacitance: Ccp 0.018 capacitance: Cd 0.037 # Cbuffer +

Cflipflop capacitance: Coe 0.042 capacitance: Cq 0.021 capacitance: Cz 0.029 k factor.pr file

Below is an example of such a file. Put it in "my_library" directory.

# k factor.pr file begin default fanout load 1.0 default_output_pin_cap 0.018 default_input_pin_cap 0.012

# In nanoseconds default max transition 3.0

# Propagation and Transition

# Kp_ramp k_process_intrinsic_rise 1.0 k_process_intrinsic_f ll 1.0 k_process_drive_rise 1.0 k_process_drive_fall 1.0

# Kv_ramp k_volt_intrinsic_rise -0.29605 k_volt_intrinsic_fall -0.29605 k_volt_drive_rise -0.29605 k_volt_d rive_fall -0.29605

# Kt_ramp k_temp_intrinsic_rise 0.00207937 k_temp_intrinsic_fall 0.00207937 k_temp_drive_rise 0.00207937 k_temp_drive_fall 0.00207937

# Setup and Hold k_process_hold_rise 1.0 k_process_hold_fall 1.0 k_process_setup_rise 1.0 k process setup fall 1.0 k_volt_hold_rise -0.29605 k_volt_hold_faIl -0.29605 k_volt_setup_rise -0.29605 k_volt_setu p_f ll -0.29605 k_temp_hold_rise 0.00207937 k_temp_hold_fall 0.00207937 k_temp_setup_rise 0.00207937 k_temp_setup_fall 0.00207937

# Recovery k_process_recovery_fall 1.0 k_process_recovery_rise 1.0 k_volt_recovery_fall -0.29605 k_volt_recovery_rise -0.29605 k_temp_recovery_fall 0.00207937 k_temp_recovery_rise 0.00207937

# Minimum Pulse Width k_process_min_pulse_width_high 1.0 k_process_min_pulse_width_low 1.0 k_volt_min_pulse_width_high -0.29605 k_volt_min_pulse_width_low -0.29605 k_temp_min_pulse_width_high 0.00207937 k_temp_min_pulse_width_low 0.00207937

# Minimum Period k_process_min_period 1.0 k_volt_min_period -0.29605 k_temp_min_period 0.00207937

# Interconnect k_process_pin_cap 0.0 k_process_wire_cap 0.0 k_process_wire_res 0.0 k_volt_pin_cap 0.0 k_volt_wire_cap 0.0 k volt wire res 0.0 k_temp_pin_cap 0.0 k_temp_wire_cap 0.0 k_temp_wire_res 0.0

# k_factor.pr file end synopsys.txt file

Below is an example of such a file. Put it in "my_library" directory.

# synopsys.txt file begin. begin_timing_range

FAST_RANGE faster_factor 0.595 slower_factor 1.0

SLOW_RANGE faster_factor 1.0 slower_factor 1.64 end_timing_range begin operating conditions

TYP process 1.0 temperature 25 voltage 3.3 tree_type balanced_tree

WCMAX process 1.247 temperature 140 voltage 3.0 tree_type balanced tree end_operating_conditions

# synopsys.txt file end.

F. Timing shell generation

Now all input files are performed. We can generate all timing shells thanks to TimingShellGen. For that, execute the following command: %> TimingShellGen flip.td flip.tch

It creates: flip.pmd ([pmd] for simulation) flip.vhd (VITAL VHDL wrapper) flip.v (verilog timing wrapper) flip.mod (source [mod] file for STAMP model) flip.data (source [data] file for STAMP model) flip_longpath.lib (source [lib] file for ITS model with longest paths) flip shortpath.lib (source [lib] file for ITS model with shortest paths) flip_simplifϊed.pmd ([pmd] for Static Timing Analysis) G. Library generation with output files generated

1) VITAL VHDL wrapper

The VHDL wrapper (flip.vhd) has no functionality inside. You can put, for example, an RTL architecture for the flip cell. Thus replace: Architecture CLI of flip_functionality is attribute foreign: string; attribute foreign of CLI: architecture is

"vsystem_DEVICE_ms_elaborate

$DIR_DEVICE/DEVICE.o"; begin

~ nothing end CLI; by

Architecture rtl of flip_functionality is begin process (d,oe) begin if (oe-T) then z <= d; else z <= 'Z'; end if; end process; process (cp,cdn) begin if (cdn='0') then q <= '0'; else if (cp=T and cp'event) then q <= ; end if; end if; end process; end rtl;

That model compiles correctly and can be simulated, back-annotated or not. Do not forget to map the VITAL primitive library before simulating. 2) rsdfl generation

Make sure DelayCalculator will find the flip.pmd file during [sdf] generation. The -sdftype advised option is "ovi". 3) ITS model

Install DesignCompiler™ (Synopsys tool) and create as follows synthesis library in [db] file format: dc_shell> read_lib flip longpath.lib dc_shell> write_lib flip_longpath

It creates flip_longpath.db file. dc_shell> read_lib flip shortpath.lib dc_shell> write_lib flip_shortpath

It creates flip_shortpath.db file.

Both [db] libraries consist of a unique cell named flip.

4) rtiml format for Place & Route Timing Driven

We use flip_longpath.lib.file by default and we perform timing reports under

Design Compiler™. dc_shell> read_lib flip longpath.lib dc_shell> report_lib -timing flip longpath > flip longpath.rpt

The [rpt] file can be used to create a [tim] directory for Apollo™ Timing Driven P&R (Avant! tool).

5) STAMP model TimingShellGen creates flip.mod, flip.data that are two source files to create a STAMP model. It creates also a particular [pmd] named flip simplifϊed.mod to back-annotate the STAMP model. STAMP model is a synopsys language dedicated to do static timing analysis under PrimeTime™(Synopsys tool). pt_shell> compile_stamp_model -model_file flip.mod

-data_file flip.data -output flip -library_cell It creates flip_lib.db file. That [db] file consists of flip model as a library cell.

It is important to note that, as the timing shell has no functionality, conditional timing arcs based on internal signals cannot be handled. So worst values are taken whatever the conditions. To match such a timing shell, a special [pmd] was necessary. TIMING SHELL DEVELOPMENT FLOW WITH IPguard™

Figure 8 illustrates one exemplary layout for a timing shell development implementation according to Applicant's invention.

When developing a hardware macro-cell (Microprocessor, Digital Signal Processor (DSP), Phase Looked Loop (PLL)) for embedded use in a chip design for a third-party customer, it is necessary to provide the customer with a hardware macro- cell model without giving away your intellectual property (IP) to the customer:

■ As regards synthesis, static timing analysis and timing driven place and route steps, the models consist of timing shell with no functionality inside (also usually named phantom). They help other Electronic

Design Automation (EDA) tools by giving them timing constraints. There is no IP inside. But they still have to be consistent at any step of a design. ■ As regards simulation step, the model consists of a timing shell around a functional model. On the one hand the timing shell must be consistent with other timing shells at any step of a design, on the other hand the functionality must be IP protected. IP protection is done either by encryption either by compilation. IPguard™ does compilation that is safer.

In deep sub-micron technologies such as 0.25μm or 0.20μm, wire delays sometimes becomes greater than cell delays. It's why back-annotation is highly recommended in a design flow. On account of this, if we want to deliver IP protected and back-annotatable simulation models (compliant with Design Integrator™), it means timing shells must be as closed to reality as possible. To achieve this requirement, we have to wait for the silicon-based characterization to fill in all timing shells.

Once timing shell purpose is demonstrated. Let's take the example of a macro- cell of 40k gates, 250 ports, almost 60 Setup/Hold checks, 8 Width checks, and 500 output delay paths. All timing shells were done by hand and/or scripts in almost 5-6 months, without underlining human errors that affect all timing shells' consistency.

This is out of time-to-market strategies.

Now thanks to Timing Shell Automation, all timing shells can be generated and tested in one week and it guarantee a high consistency level.

All timing shells should be exhaustively tested, almost the back-annotatable HDL wrapper according to the original macro-cell. LIMITATIONS

A. ITS limitations

■ At most an input port can have one setup arc and one hold arc with respect to any given clock port. Note an input port can have setup or hold constraints specified with respect to several clock ports.

B. [pmd] limitations:

■ When an INPUT CHECK is done on a HIGH or a LOW condition, setup an hold check are really done on different edges, but normally the "test_port" must remain stable during the constraint window. This is not handled.

■ PERIOD WIDTH CHECKS and STABLE CHECKS are not handled because they are not handled by [pmd].

C. VITAL limitations

■ Negative Hold checks are not handled on account of VITAL limitation.

APPENDIX A

The program is exiting when the first error occurs. So you can see errors only one by one. On the contrary warnings are all printed without exiting the program.

1. Error - Warning messages when reading a ftdl file a) Errors

** Error: At line %d in file %s

Two successive starting comments were found, The second starting comment was found at line %d.

** Error: At line %d in file %s

Two successive ending comments were found,

Or an ending comment was set without starting comment.

** Error: According to the %s file, the parameter

%s must be declared in the %s file.

** Error: Syntax error at port %s declaration.

** Error: Port %s not declared.

** Error: The %s port referencing a Setup/Hold check on %s must be a pin, not a bus.

** Error: The %s port referencing a Setup/Hold check on %s must be an input.

** Error: Input check on %s[%d:%d] port referenced by %s is out of range.

** Error: You cannot specify an output delay from a bus to a pin (from

%s[%d:%d] to %s).

** Error: You cannot specify an output delay between two buses having different widths (from %s[%d:%d] to %s[%d:%d]).

** Error: Port or state %s in condition not declared. (Output delay declaration on port %s)

** Error: Port or state %s in condition not declared. (Input check declaration on port %s)

** Error: Port or state %s in condition not declared. (Width check declaration on port %s)

** Error: Conditions cannot contain inout ports (%s). (Output delay declaration on port %s)

** Error: Conditions cannot contain inout ports (%s). (Input check declaration on port %s) ** Error: Conditions cannot contain inout ports (%s). (Width check declaration on port %s)

** Error: Conditions cannot contain bus ports (%s[%d;%d]). (Output delay declaration on port %s)

** Error: Conditions cannot contain bus ports (%s[%d;%d]). (Input check declaration on port %s)

** Error: Conditions cannot contain bus ports (%s[%d;%d]). (Width check declaration on port %s)

** Error: Conditions cannot contain internal bus state (%s[%d;%d]).

(Output delay declaration on port %s)

** Error: Conditions cannot contain internal bus state (%s[%d;%d]).

(Input check declaration on port %s)

** Error: Conditions cannot contain internal bus state (%s[%d;%d]).

(Width check declaration on port %s) b) Warning

** Warning: Input pin %s becomes a clock pin because it is referencing Setup/Hold checks.

** Warning: Output pin %s becomes tristate output on account of its high-impedence transitions.

** Warning: Output bus %s[%d:%d] becomes tristate output on account of its high-impedence transitions.

2. Warning when creating output files a) fpmdl file

** Warning: Output delay from %s[%d:%d] to %s[%d:%d] is considered as BITWISE.

** Warning: NOCHANGE CHECK on <pin|bus> not handled by [pmd] (stable input check statement). ** Warning: NOCHANGE CHECK on <pin|bus> between <rising|falling> edge and <falling|rising> edge of <pin>. not handled by [pmd] (<high|low> input check statement).

** Warning: PERIOD CHECK on <pin|bus> not handled by [pmd].

(period width check statement). VITAL Tvhdl file

Warning: Output delay from %s[%d:%d] to %s[%d:%d] is considered as BITWISE.

Warning: NOCHANGE CHECK on <pin|bus> not translated in VITAL [vhd] to match [pmd]. (stable input check statement).

Warning: NOCHANGE CHECK on <pin|bus> between <rising|falling> edge and <falling|rising> edge of <pin>. not translated in VITAL [vhd] to match [pmd]. (<high|low> input check statement).

Warning: PERIOD CHECK on <pin|bus> not translated in VITAL [vhd] to match [pmd]. (period width check statement).

APPENDIX B

Below is the structure used by TimingShellGen tool. It is written in C language. #define name_length_max 120

#define line_length_max 200

enum enu_logic_qualifier{bitwise,equivalent} ; typedef enum enu_logic_qualifier t_enu_logic_qualifier; enum enu_port_dir {input,output,inout,triout,internal}; typedef enum enu_port_dir t_enu_port_dir; enum enu_port_type {pin,bus}; typedef enum enu_port_type t_enu_port_type;

struct str_port_width { int start_bit; int end_bit;

}; typedef struct str port width t_str_port_width;

struct str_capacitance { char name[name_length_max]; float value;

} ; typedef struct str_capacitance t_str_capacitance;

struct str_ramp_factor { char rise_name[name_length_max]; char fall_name[name_length_max]; float rise_value; float fall_value; } ; typedef struct str_ramp_factor t str ramp factor; struct str_parameter { char name[name_length_max]; float value;

}; typedef struct str_parameter t_str_parameter;

struct str_width_check { char kind[name_length_max]; char timename [name length max]; float value; char interna l_condition[line_ length_max]; char external_condition[line_ length_max]; }; typedef struct str_width_check t_str_width_check; struct str_input_check { char kind[name_length_max]; char active_wire[name_length_max] ; char setup_timename[name_length_ max]; float setup value; char hold_timename[name_length_ max]; float hold value; t_str_port_width bit range; char internal_condition[line_length_ max]; char external_condition[line_length_ max];

}; typedef struct str_input_check t_str_input_check;

struct str_output_delay { char output_edge[name_length_ max]; char active_wire[name_length_max]; char transition[name_length_max] ; char undef_timename[name_length_ max]; float undef time; char def_timename[name_length_ max]; float def_time; char internal_condition[line_length_ max]; char externa l_condition[line_length_ max]; t_enu_Iogic qualifier logic_qualifier;

}; typedef struct str_output_delay t_str_output_delay; struct str_hdl_port { char name[name_length_max]; t_enu_port_dir port_dir; t_enu_port_type port_type; t_str_port_width port_width; t str capacitance capacitance; t_str_ramp_factor ramp_factor; int clock_attribute; int number_of_width_check; int number_of_input_check; int number_of_output_delay; t_str_width_check *width_check; t_str_input_check *input_check; t_str_output_delay *output_delay;

}; typedef struct str_hdl_port t_str_hdl_port; struct str_extra_state { char name[name_length_max]; t_enu_port_dir port dir;

}; typedef struct str_extra_state t_str_extra_state;

Claims

1. An electronic design automation apparatus, comprising: processing circuitry; memory coupled with the processing circuitry; a keyword symbol table stored in the memory; a macro-cell structural database including timing constraints and I/O declarations of a macro-cell; a timing shell generator implemented on the processing circuitry and operative to generate a timing shell for a specific hardware macro-cell; analysis circuitry including a lexical analyzer operative to identify the placement of keywords, a syntactical analyzer operative to check syntax, and a semantic analyzer operative to verify meaning, the analysis circuitry implemented on the processing circuitry; and an error and warning management unit operative to detect and warn of circuitry errors detected during a test procedure.

2. The electronic design automation apparatus of claim 1 wherein the processing circuitry is provided by a computer.

3. The electronic design automation apparatus of claim 1 wherein the timing shell generator receives input comprising timing constraints, parameter values, and derating factors.

4. The electronic design automation apparatus of claim 1 wherein the timing shell generator comprises an electronic design automation (EDA) tool.

5. The electronic design automation apparatus of claim 1 wherein the analysis circuitry is provided by the processing circuitry.

6. The electronic design automation apparatus of claim 4 wherein the derating factors comprise at least one of process, voltage and temperature.

7. The electronic design automation apparatus of claim 1 wherein the error and warning management unit comprises processing circuitry.

8. The electronic design automation apparatus of claim 1 wherein the macro-cell structural database comprises a timing arc database and an electrical parameter database.

9. The electronic design automation apparatus of claim 1 wherein the lexical analyzer receives timing arcs, parameter values and derating factors, and the analysis circuitry generates an output file.

10. The electronic design automation apparatus of claim 9 wherein the output file comprises a timing shell.

11. A method of generating and testing timing shells, comprising: performing a static timing analysis of a hardware macro-cell; storing timing constraints and I/O declarations in a first file; extracting electrical parameter names from the hardware macro-cell; storing the extracted electrical parameter names in a second file; filling the second file with the results from the performed static timing analysis; listing operating conditions usable in deep-submicron technology in a third file; filling a single common database by reading contents of the first, second and third files, and linking the contents together; and creating an output file from the unique database for a format required by a computer aided design (CAD) tool.

12. The method of claim 11 further comprising the step of performing lexicographic analysis on timing arcs.

13. The method of claim 11 further comprising the step of performing lexicographic analysis on parameter values.

14. The method of claim 11 further comprising the step of performing lexicographic analysis on derating factors.

15. The method of claim 14 further comprising the step of performing syntax analysis on timing arcs.

16. The method of claim 11 further comprising performing semantic analysis on timing arcs.

17. The method of claim 11 further comprising generating a timing arc database.

18. The method of claim 11 wherein the output file comprises a consistent timing shell.

19. The method of claim 18 wherein the output file is delivered to a synthesis library.

20. The method of claim 18 wherein the output file is delivered to a place-and-route timing driven library.

21. The method of claim 18 wherein the output file is delivered to a static timing analysis library.

22. The method of claim 18 wherein the output file is delivered to a back-annotatable simulation library.

23. A method of generating consistent timing shells, comprising: providing a hardware macro-cell; performing a static timing analysis of the hardware macro-cell; generating a list of timing constraints and I/O declarations for the hardware macro-cell; extracting a timing arc description file including generic electrical parameters from the hardware macro-cell; storing the generic electrical parameters in a characterization file; filling the characterization file with resulting values from the performed static timing analysis; generating a list of operating conditions usable in performing a static timing analysis of the hardware macro-cell; generating a database comprising the stored timing arc description file, the resulting values from the performed static timing analysis, and the list of operating conditions usable in performing the static timing analysis; and generating an output file from the database in a format usable by a computer aided design (CAD) tool.

24. The method of claim 23 wherein the output file comprises a timing shell.

25. The method of claim 24 wherein the timing shell comprises timing constraints and I/O declarations.

26. The method of claim 25 wherein the timing constraint comprises at least one of timing checks and output delay paths.

27. The method of claim 26 wherein the timing checks comprise at least one of setup-time checks, hold-time checks, and width checks.

28. The method of claim 25 wherein the I/O declarations comprise at least one of direction and load.

29. The method of claim 28 wherein the I/O declaration comprises direction including at least one of input, output, and inout.

30. The method of claim 23 wherein after generating a list of timing constraints and I/O declarations, further comprising the step of storing the list of timing constraints and I/O declarations in a first file.

31. The method of claim 30 wherein after extracting a timing arc description file, further comprising the step of saving the generic electrical parameter names in a second file.

32. The method of claim 31 wherein after generating a list of operating conditions, further comprising the step of saving the list of operating conditions in a third file.