WO2001008028A2 - Automatisation par modele de simulation pour effectuer une modelisation de macrocellules de materiel - Google Patents

Automatisation par modele de simulation pour effectuer une modelisation de macrocellules de materiel Download PDF

Info

Publication number
WO2001008028A2
WO2001008028A2 PCT/US2000/019868 US0019868W WO0108028A2 WO 2001008028 A2 WO2001008028 A2 WO 2001008028A2 US 0019868 W US0019868 W US 0019868W WO 0108028 A2 WO0108028 A2 WO 0108028A2
Authority
WO
WIPO (PCT)
Prior art keywords
timing
file
cell
analysis
macro
Prior art date
Application number
PCT/US2000/019868
Other languages
English (en)
Other versions
WO2001008028A3 (fr
Inventor
Luc Orion
Original Assignee
Koninklijke Philips Electronics Nv
Philips Semiconductors, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Philips Electronics Nv, Philips Semiconductors, Inc. filed Critical Koninklijke Philips Electronics Nv
Priority to EP00950497A priority Critical patent/EP1196861A2/fr
Publication of WO2001008028A2 publication Critical patent/WO2001008028A2/fr
Publication of WO2001008028A3 publication Critical patent/WO2001008028A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking
    • G06F30/3308—Design verification, e.g. functional simulation or model checking using simulation
    • G06F30/3312—Timing analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2115/00—Details relating to the type of the circuit
    • G06F2115/08—Intellectual property [IP] blocks or IP cores

Definitions

  • 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.
  • 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'.
  • 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.
  • scripts may be unreusable for another project for the reasons quoted above.
  • 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.
  • a simulation model consists of a timing shell that is placed around a functional model of a circuit structure.
  • the timing shell must be consistent with other timing shells at any step of a computer aided design (CAD) process.
  • CAD computer aided design
  • provision of a functional model is not protective of intellectual property (IP).
  • IP intellectual property
  • either encryption or compilation must also be implemented.
  • timing shell accuracy 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.
  • 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.
  • real wires have a delay associated with them.
  • cells have internal delays (that are intrinsic to each cell).
  • 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.
  • 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.
  • 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.
  • 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.
  • CAD computer aided design
  • 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".
  • EDA Electronic Design Automation
  • 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.
  • an electronic design automation 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 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.
  • CAD computer aided design
  • a method 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.
  • CAD computer aided design
  • 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.
  • EDA electronic design automation
  • 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 ModelGenTM (ARM Ltd)/IPguardTM (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.
  • I/O input/output
  • 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.
  • CAD computer aided design
  • TimingShellGen 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.
  • 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.
  • CAD computer aided design
  • 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.
  • IP intellectual property
  • FIG. 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.
  • CAD computer aided design
  • 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.
  • 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.
  • EDA system 10 comprises a central processing unit (CPU) or processor, memory, and a data storage device.
  • the memory comprises random access memory, read only memory, and a data storage device.
  • 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.
  • 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.
  • STD standard
  • 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.
  • 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.
  • timing shell generator tool 12 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.
  • TimingShellGen tool behavior is described below as discussed with reference to steps 2-4 and Figure 2.
  • timing arcs 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • syntax analysis 58 and semantic analysis 60 are performed on the timing arcs 44. Consequently, output file generation block 68 generates timing shells 26.
  • lexicographic analysis block 54 generates a parameter template 70.
  • 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.
  • FIG. 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.
  • 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 IntegratorTM VLSI Technology
  • Other kinds of timing shell can be considered as phantom.
  • 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.
  • ITS Interface Timing Specification
  • TimingShellGen generator tool features A. Data requirements (Input files)
  • a characterization 74 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.
  • 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.
  • 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.
  • TimingShellGen my_cellname.td -create_tch
  • TimingShellGen my cellname.td my_cellname.tch Create all timing shell source files.
  • TimingShellGen helps by printing a few error/warning messages. See Appendix
  • 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)
  • 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 ModelGenTM or IPguardTM 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
  • the file "my_cellname_longpath.lib.file” is used by default, and timing reports are performed under Design CompilerTM.
  • the [rpt] file can be used to create a [tim] directory for ApolloTM Timing
  • 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
  • STAMP model is a synopsys language dedicated to do static timing analysis under PrimeTimeTM (Synopsys tool).
  • 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.
  • VITAL interface It could be badly interpreted and simulators usually claim mismatches anyway during back-annotation.
  • 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.
  • 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.
  • 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).
  • ⁇ Width checks specify the minimum time between certain transitions on an hdl_port: their primary use is to check signals used for clocking.
  • 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.
  • 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.
  • 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.
  • bit_range_check form of range_checks must be used.
  • the format is always [high:low], for a single bit use [bit]. 5)
  • 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
  • Line comments may be introduced using # and continue to end of line.
  • 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.
  • WF7102 and WF7103. They both have the functionality of ARM7TDMI but they are mapped on different technologies.
  • VYF86C07903 and VYF86C07_301. They both have the functionality of ARM7TDMI, but the first one is custom based, the second one is standard
  • 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], ... ).
  • That float value allows us to get rid of decimals for timing and ramp factor values.
  • the common SIM_SCALE value is set to 100.
  • ⁇ 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.
  • Timing Arc a string that must match with the Timing Arc
  • 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.
  • 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.
  • # k_factor.pr file begin default_fanout_load ⁇ float > default_output_pin_cap ⁇ float > default_input_pin_cap ⁇ float >
  • 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
  • Timing_range 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.
  • timing_range_block or operating_conditions_block statements are allowed only outside timing_range_block or operating_conditions_block statements.
  • 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.
  • the operating condition name identifies the set of operating conditions.
  • 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:
  • 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
  • ⁇ 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 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.
  • 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.
  • TYP process 1.0 temperature 25 voltage 3.3 tree_type balanced_tree
  • 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.
  • 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.
  • INPUT CP Ccp INPUT CDN Ccdn;
  • 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.
  • # k factor.pr file begin default fanout load 1.0 default_output_pin_cap 0.018 default_input_pin_cap 0.012
  • TYP process 1.0 temperature 25 voltage 3.3 tree_type balanced_tree
  • TimingShellGen flip.td flip.tch
  • 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
  • the VHDL wrapper (flip.vhd) has no functionality inside. You can put, for example, an RTL architecture for the flip cell.
  • Replace: Architecture CLI of flip_functionality is attribute foreign: string; attribute foreign of CLI: architecture is
  • the [rpt] file can be used to create a [tim] directory for ApolloTM Timing Driven P&R (Avant! tool).
  • 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 PrimeTimeTM(Synopsys tool).
  • flip_lib.db file It creates flip_lib.db file. That [db] file consists of flip model as a library cell.
  • Figure 8 illustrates one exemplary layout for a timing shell development implementation according to Applicant's invention.
  • 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.
  • 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. IPguardTM does compilation that is safer.
  • 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.
  • 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.
  • Timing Shell Automation all timing shells can be generated and tested in one week and it guarantee a high consistency level.
  • 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.
  • 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.
  • %s must be declared in the %s file.
  • 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;
  • 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;
  • 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];
  • 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;

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Design And Manufacture Of Integrated Circuits (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

L'invention concerne un dispositif électronique servant à automatiser une conception. Ce dispositif comprend un circuit de traitement, une mémoire, une table de symboles de mots-clé, une base de données structurale de macrocellules, un générateur de modèle de simulation, un circuit d'analyse et une unité de gestion d'erreurs et d'avertissement. La mémoire est couplée au circuit de traitement. La table de symboles de mots-clé est mémorisée dans la mémoire. La base de données structurale de macrocellules comporte des contraintes temporelles et des déclarations d'entrée-sortie d'une macrocellule. Le générateur de modèle de simulation est mis en application sur le circuit de traitement et sert à générer un modèle de simulation pour une macrocellule spécifique de matériel. Le circuit d'analyse possède un analyseur de lexique servant à identifier le positionnement des mots-clé, un analyseur de syntaxe servant à vérifier la syntaxe et un analyseur sémantique servant à vérifier le sens, ce circuit d'analyse étant mis en application sur le circuit de traitement. L'unité de gestion d'erreurs et d'avertissement sert à détecter des erreurs sur le circuit pendant un processus d'essai et à avertir de ces erreurs. L'invention concerne également un procédé correspondant.
PCT/US2000/019868 1999-07-23 2000-07-19 Automatisation par modele de simulation pour effectuer une modelisation de macrocellules de materiel WO2001008028A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP00950497A EP1196861A2 (fr) 1999-07-23 2000-07-19 Automatisation par modele de simulation pour effectuer une modelisation de macrocellules de materiel

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US35959499A 1999-07-23 1999-07-23
US09/359,594 1999-07-23

Publications (2)

Publication Number Publication Date
WO2001008028A2 true WO2001008028A2 (fr) 2001-02-01
WO2001008028A3 WO2001008028A3 (fr) 2002-02-14

Family

ID=23414495

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/019868 WO2001008028A2 (fr) 1999-07-23 2000-07-19 Automatisation par modele de simulation pour effectuer une modelisation de macrocellules de materiel

Country Status (2)

Country Link
EP (1) EP1196861A2 (fr)
WO (1) WO2001008028A2 (fr)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003050725A3 (fr) * 2001-12-07 2004-04-08 Cadence Design Systems Inc Gestion d'assertions pour extraction d'un modele de synchronisation
WO2004077213A2 (fr) * 2003-01-30 2004-09-10 Vaman Technologies (R & D) Limited Systeme et procede permettant d'analyser des demandes pour des objets independamment de la fonctionnalite du serveur
WO2009010817A1 (fr) 2007-07-19 2009-01-22 Renault Trucks Procédé et système pour limiter des bruits de véhicule
WO2015048532A1 (fr) * 2013-09-26 2015-04-02 Synopsys, Inc. Extraction de paramètres de dft
US10078735B2 (en) 2015-10-30 2018-09-18 Synopsys, Inc. Atomic structure optimization
US10402520B2 (en) 2013-09-26 2019-09-03 Synopsys, Inc. First principles design automation tool
US10417373B2 (en) 2013-09-26 2019-09-17 Synopsys, Inc. Estimation of effective channel length for FinFETs and nano-wires
US10489212B2 (en) 2013-09-26 2019-11-26 Synopsys, Inc. Adaptive parallelization for multi-scale simulation
US10516725B2 (en) 2013-09-26 2019-12-24 Synopsys, Inc. Characterizing target material properties based on properties of similar materials
US10734097B2 (en) 2015-10-30 2020-08-04 Synopsys, Inc. Atomic structure optimization
US10776560B2 (en) 2013-09-26 2020-09-15 Synopsys, Inc. Mapping intermediate material properties to target properties to screen materials
US11682047B2 (en) 2018-08-28 2023-06-20 International Business Machines Corporation Cognitive elevator advertisements

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5517658A (en) * 1990-11-09 1996-05-14 Lsi Logic Corporation Method for testing design timing parameters using a timing shell generator
WO1996023263A1 (fr) * 1995-01-25 1996-08-01 Lsi Logic Corporation Generation de coquilles de listes d'interconnexions par reduction des listes d'interconnexions

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5517658A (en) * 1990-11-09 1996-05-14 Lsi Logic Corporation Method for testing design timing parameters using a timing shell generator
WO1996023263A1 (fr) * 1995-01-25 1996-08-01 Lsi Logic Corporation Generation de coquilles de listes d'interconnexions par reduction des listes d'interconnexions

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MCKINNEY M D SR: "Implementing a timing shell for VHDL simulation using the proposed EIA-567 standard" PROCEEDINGS SIXTH ANNUAL IEEE INTERNATIONAL ASIC CONFERENCE AND EXHIBIT, SIXTH ANNUAL IEEE INTERNATIONAL ASIC CONFERENCE AND EXHIBIT, ROCHESTER, NY, USA, 27 SEPT.-1 OCT. 1993, pages 288-291, XP002177035 Sept. 1993, New York, NY, USA, IEEE, USA ISBN: 0-7803-1375-5 *
TOYODA T ET AL: "A fully integrated characterization and management system for ASIC libraries" PROCEEDINGS OF FIFTH ANNUAL IEEE INTERNATIONAL ASIC CONFERENCE AND EXHIBIT (CAT. NO.92TH0475-4), ROCHESTER, NY, USA, 21-25 SEPT. 1992, pages 245-248, XP002177036 1992, New York, NY, USA, IEEE, USA ISBN: 0-7803-0768-2 *

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003050725A3 (fr) * 2001-12-07 2004-04-08 Cadence Design Systems Inc Gestion d'assertions pour extraction d'un modele de synchronisation
US6928630B2 (en) 2001-12-07 2005-08-09 Cadence Design Systems, Inc. Timing model extraction by timing graph reduction
US7356451B2 (en) 2001-12-07 2008-04-08 Cadence Design Systems, Inc. Assertion handling for timing model extraction
WO2004077213A2 (fr) * 2003-01-30 2004-09-10 Vaman Technologies (R & D) Limited Systeme et procede permettant d'analyser des demandes pour des objets independamment de la fonctionnalite du serveur
WO2004077213A3 (fr) * 2003-01-30 2005-05-19 Vaman Technologies R & D Ltd Systeme et procede permettant d'analyser des demandes pour des objets independamment de la fonctionnalite du serveur
WO2009010817A1 (fr) 2007-07-19 2009-01-22 Renault Trucks Procédé et système pour limiter des bruits de véhicule
US10402520B2 (en) 2013-09-26 2019-09-03 Synopsys, Inc. First principles design automation tool
US10776560B2 (en) 2013-09-26 2020-09-15 Synopsys, Inc. Mapping intermediate material properties to target properties to screen materials
US9836563B2 (en) 2013-09-26 2017-12-05 Synopsys, Inc. Iterative simulation with DFT and non-DFT
US9881111B2 (en) 2013-09-26 2018-01-30 Synopsys, Inc. Simulation scaling with DFT and non-DFT
US10049173B2 (en) 2013-09-26 2018-08-14 Synopsys, Inc. Parameter extraction of DFT
US11249813B2 (en) 2013-09-26 2022-02-15 Synopsys, Inc. Adaptive parallelization for multi-scale simulation
WO2015048532A1 (fr) * 2013-09-26 2015-04-02 Synopsys, Inc. Extraction de paramètres de dft
US10417373B2 (en) 2013-09-26 2019-09-17 Synopsys, Inc. Estimation of effective channel length for FinFETs and nano-wires
US10489212B2 (en) 2013-09-26 2019-11-26 Synopsys, Inc. Adaptive parallelization for multi-scale simulation
US10516725B2 (en) 2013-09-26 2019-12-24 Synopsys, Inc. Characterizing target material properties based on properties of similar materials
US10685156B2 (en) 2013-09-26 2020-06-16 Synopsys, Inc. Multi-scale simulation including first principles band structure extraction
US10706209B2 (en) 2013-09-26 2020-07-07 Synopsys, Inc. Estimation of effective channel length for FinFETs and nano-wires
US11068631B2 (en) 2013-09-26 2021-07-20 Synopsys, Inc. First principles design automation tool
US9727675B2 (en) 2013-09-26 2017-08-08 Synopsys, Inc. Parameter extraction of DFT
US10831957B2 (en) 2013-09-26 2020-11-10 Synopsys, Inc. Simulation scaling with DFT and non-DFT
US10734097B2 (en) 2015-10-30 2020-08-04 Synopsys, Inc. Atomic structure optimization
US10078735B2 (en) 2015-10-30 2018-09-18 Synopsys, Inc. Atomic structure optimization
US11682047B2 (en) 2018-08-28 2023-06-20 International Business Machines Corporation Cognitive elevator advertisements

Also Published As

Publication number Publication date
WO2001008028A3 (fr) 2002-02-14
EP1196861A2 (fr) 2002-04-17

Similar Documents

Publication Publication Date Title
Cohen VHDL coding styles and methodologies
Bhatnagar Advanced ASIC chip synthesis
Airiau et al. Circuit synthesis with VHDL
US8554530B1 (en) Methods and systems for property assertion in circuit simulation
US11238202B2 (en) Verifying glitches in reset path using formal verification and simulation
US10769329B1 (en) Retention model with RTL-compatible default operating mode
US9141741B1 (en) Methods, systems, and articles of manufacture for implementing mixed-signal electronic circuit designs with power data in standardized power formats
WO2001008028A2 (fr) Automatisation par modele de simulation pour effectuer une modelisation de macrocellules de materiel
US7210109B2 (en) Equivalence checking of scan path flush operations
Simpson FPGA design
Stavinov 100 power tips for FPGA designers
US11475197B2 (en) Hardware simulation systems and methods for identifying state-holding loops and oscillating loops
Munden ASIC and FPGA verification: a guide to component modeling
US6668359B1 (en) Verilog to vital translator
US7516060B2 (en) Circuit-level memory and combinational block modeling
US10579760B2 (en) Force/release support in emulation and formal verification
US20230195982A1 (en) Transformations for multicycle path prediction of clock signals
Skahill A designer's guide to VHDL design and verification
Smith HDL basic training: Top-down chip design using Verilog and VHDL.
Gibiluka Analysis of voltage scaling effects in the design of resilient circuits
Bhatnagar Synopsys technology library
US6701290B1 (en) Method and apparatus for evaluating the design quality of network nodes
Cummings SystemVerilog-Is This The Merging of Verilog & VHDL?
Mantooth Modeling tools built upon the HDL foundation
Cohen Component design by example

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): CN JP KR

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

WWE Wipo information: entry into national phase

Ref document number: 2000950497

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): CN JP KR

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

WWP Wipo information: published in national office

Ref document number: 2000950497

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2000950497

Country of ref document: EP

NENP Non-entry into the national phase in:

Ref country code: JP