CN113033127A

CN113033127A - Enterprise IC design method and development platform based on EEBox

Info

Publication number: CN113033127A
Application number: CN202110211713.2A
Authority: CN
Inventors: 赵启林
Original assignee: Shanghai Aiser Education Technology Co ltd
Current assignee: Shanghai Aiser Education Technology Co ltd
Priority date: 2020-11-20
Filing date: 2021-02-25
Publication date: 2021-06-25

Abstract

The invention relates to the technical field of electronic automation, in particular to an enterprise IC design method and a development platform based on EEBox, wherein an EDA tool is required to be installed under a Linux operating system and a server with a high-performance X86 architecture in advance; the method is suitable for developing a large-scale IC system, integrates and optimizes all components required in the IC system development process, and can improve the development efficiency of a design and verification engineer team, reduce the communication cost among the engineer teams, reduce the iteration times of a chip development process, improve the management efficiency of an EDA project database, reduce the use difficulty of EDA tools and avoid low-level artificial errors in the project development process.

Description

Enterprise IC design method and development platform based on EEBox

Technical Field

The invention relates to the technical field of electronic automation, in particular to an enterprise IC design method and a development platform based on EEBox.

Background

The EEBox is a complete solution suitable for developing a large-scale IC system, and integrates and optimizes various components required in the IC system development process, including: simplifying the use of EDA tools, perfecting IP management, managing project database versions, tracking project development progress, tracing project problems and other engineering problems.

The EEBox is suitable for development and management of various IC system projects such as ASIC (application specific integrated circuit), SoC (system on chip), FPGA (field programmable gate array), digital-analog mixed chips, low-power chips, Internet of things chips, communication chips, audio and video chips and the like, can greatly improve the development efficiency of a design and verification engineer group, reduce the communication cost among the engineer group, reduce the iteration times of a chip development process, improve the management efficiency of a project database, reduce the use difficulty of EDA (electronic design automation) tools and avoid low-level human errors in the project development process.

The EEBox is a set of tools mainly compiled by scripting languages such as shell and perl, is suitable for a Linux operating system, is convenient to transplant, can help a digital system design verification team such as ASIC/SoC/FPGA and an integrated circuit design team to quickly build a complete large-scale digital system development platform, and has the characteristics of short deployment time and convenience in use.

Disclosure of Invention

Aiming at the defects of the prior art, the invention discloses an enterprise IC design method and a development platform based on EEBox, which are used for simplifying the use of an EDA tool, perfecting IP management, managing project database versions, tracking project development progress, tracing project problems and other engineering problems.

The invention is realized by the following technical scheme:

the invention discloses a method for designing an enterprise IC based on an EEBox, which comprises the following steps:

s1 installing EDA tool under Linux operating system and high-performance X86 server;

s2, distributing a general work catalog for each project, and containing a catalog structure configured by environment variables in the work catalog;

s3, setting an environment variable in the shell by the user for confirming the working catalog and project;

s4, creating a working directory by using the working directory management script, and automatically setting environment variables in the working directory;

s5, setting an independent design code warehouse, wherein different projects are independent from each other and have independent main lines;

s6, setting a module directory structure IP and basic variables of the IP, and being suitable for different EDA tools;

s7 creating and running configurations for verifying cases and generating catalogs separately into compile time and run time configurations;

and S8, simulating, running the script to execute regression test, and finally labeling and releasing IC design data after the project data are complete and correct.

Furthermore, in S1, the administrator may try out a new version of the EDA tool in the local modification environment, run the script to directly call the corresponding EDA tool, and correctly configure the environment variables of the EDA tool is a precondition for ensuring normal use of the EDA tool.

Furthermore, in S3, the environment variables set in the shell by the user must use absolute paths, the script tool may rewrite the variables by passing parameters so as to perform the test, the script may not use a fixed directory path, and the simulation script must be able to set different paths, so as to prevent the user from working offline through the PC.

Furthermore, in the method, before a script is run or work is developed in a working directory, a setws command must be used to enter the working directory, the command is used for setting a correct working environment variable for the working directory, after the setws command is used to enter the working directory, a new shell is created, if work is needed in a different working directory, or the environment variable set by the setws command is cancelled, an exit command is used to push out the shell, and then the shell enters the different working directory.

Furthermore, in the method, the setws command will run the script, set PATH and other environment variables related to the EDA tool, add the executable PATH of the EDA tool to the file, and all users can use the EDA tool; if offline use, the EDA tool environment variable setting will not be performed and the associated path is set before running the EDA tool.

Furthermore, in the method, any chip mainline comprises a local module and a referenced module and a verification component, and all referenced components such as mainline modules from ip and vc can reference codes of ip and vc through the externals property of the SVN. Options contain external components from snapshots that cannot be modified or from the development mainline.

Furthermore, in the method, another reference model is to create a branch of an IP or vc main line related to the project, so as to simplify external reference, any simulation of a module can only be performed in a chip working directory, each IP is controlled by an independent version, each IP module has an independent simulation working directory, and simulation is performed under a unified project working directory.

Furthermore, in the method, each verification case in the method has a set-up and run configuration file, the configuration file is developed by using Perl grammar, each set-up configuration called by a run script written by Perl is unique, each run configuration is also unique relative to one set-up configuration, and a series of unique instances of the run configuration are arranged on the basis of random seeds.

Furthermore, in the method, a simulation running script is used for running function simulation and comprises a module, a subsystem, a full chip, an RTL (real time language), a gate-level netlist and the like, and the script is written by a perl language;

the developed scripts may support the tagging operation and switch the working directory to point to these tags, the scripts need to set the environment variable EEBOX _ UPATH in the working directory with the command setws, or the user may set it through the parameter EEBOX _ UPATH, and at the same time the user may run these scripts in any directory, the scripts will automatically switch the directory to point to EEBOX _ UPATH before performing SVN operations.

In a second aspect, the present invention discloses a development platform of an enterprise IC design method based on EEBox, including a processor and a computer-readable storage medium, where computer-executable instructions are stored in the computer-readable storage medium, and when executed by the processor, the computer-executable instructions implement the enterprise IC design method based on EEBox according to the first aspect.

The invention has the beneficial effects that:

the invention has low cost, reduces the development cost of integrated circuit design, including the communication cost of time, manpower and team cooperation;

the invention has simple learning and convenient management. Perl, Shell and Makefile scripting languages are used for realizing the whole development environment, and besides existing design and verification tools, development tools such as logic synthesis, static time-sensitive analysis, physical design and the like can be developed according to project requirements.

The invention is convenient for IC designers to master, and can compile and run verification cases without the IC designers needing to master complex verification methodology such as UVM

The invention is expandable and telescopic, avoids hard coding and excessive automation, reserves enough interfaces, is convenient for adding corresponding processes, methods and tools, avoids multi-level scripts and simplifies the design target by using Makefile.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 is an overall functional diagram of an EEBox according to an embodiment of the present invention;

FIG. 2 is a diagram of the component relationships of an EEBox according to an embodiment of the present invention;

FIG. 3 is a block diagram of a verification platform according to an embodiment of the invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

Example 1

The embodiment discloses an enterprise IC design method based on an EEBox, wherein an overall functional diagram of the EEBox is shown in fig. 1, and a component relation diagram of the EEBox is shown in fig. 2, and the method includes the following steps:

The embodiment discloses an electronic design automation tool installation position, and is suitable for a server for installing a Linux operating system and an EDA tool:

all EDA tools must be installed in the following list:

/eda/<vendor>/<tool-name>/<version>

for example:

/eda/synopsys/vcs/2018.09

the EEBOX universal tool, such as run-script (run-script), code library download script (checkout-script), etc., must be placed under the tools directory, and the specific positions are as follows: /eda/< project >/EEBox

Description of the drawings: the variable < project > is the name of the item, an abbreviation for english or chinese pinyin.

It is desirable to have no need to create a complex tool selection architecture in the short term, letting different engineers select different EDA tools. At present, a symbolic connection method is adopted to establish a consistency relationship between an executable file of a tool and a proper version.

For example: /eda/synopsys/vcs- > vcs/2018.09,

the EDA tool administrator can try out new versions of EDA tools locally in the modification environment. However, this is not rare, and we simplify the EDA tool version configuration function, and can add the function at any time according to actual needs.

Important information: the run script should not use a particular EDA tool installation path, but rather call the corresponding EDA tool directly. For example, the variable $ VCS _ HOME must be set in advance, which can be set in the project configuration script.

Properly configuring the environmental variables of an EDA tool is a prerequisite to ensure that the EDA tool is used properly. If the EDA tool installation script does not support such a directory hierarchy, the installation can be done manually.

This embodiment discloses a list of projects and users, and assigning a general work list to each project has several advantages:

the performance can be improved by accessing one disk area through the safe network service, the data is easy to backup and the completeness of the data is ensured, and meanwhile, the snapshot directory can be made for the database by taking the network service characteristic as well.

In order to ensure the safety of the access of the database, ensure the performance and realize data backup and snapshot, the EEBOX can conveniently manage the disk space, for example, a large amount of disk space is needed when regression test is carried out at the later stage of a project, and an IC designer can conveniently check the working directories of other personnel under a specific directory.

Each item code will be placed in the following list:

/projects/<project-name>/<revision>

option < division > is in the format of M.N (M denotes the major issue number and N denotes the minimum issue number).

For example, a user work catalog may also be placed under a particular project catalog, which catalog is owned by the IC designer.

For example/projects/emcu 3000/1.0/users/< user _ name >/emcu3000

To implement a system that does not require fixed directory entry points, any given working directory must contain a directory structure configured by environment variables. These environment variables are used to run scripts and extend the path of the directory for simulation during simulation.

A typical development flow is: each engineer can create multiple work directories and work in parallel. A simple example is: when a project is made, two working catalogues are set: one referencing the catalog and the other developing the catalog.

Example 2

The embodiment discloses that the environment variable user needs to set the following environment variables in the shell, so as to confirm the working catalog and project. Note that these variables must use absolute paths. The scripting tool may rewrite these variables by passing parameters to facilitate testing.

DSDP _ PPATH is a reference chip download location, which is usually the location of the SVN code warehouse storing chip database

$ DSDP _ UPATH ═ user work directory location

The DSDP _ program must be consistent with the root directory name of the chip, for example, the root directory is DSDP _1.0, and the DSDP _ program must be DSDP

The DSDP _ REV ═ item version number must be consistent with the root directory name of the chip, e.g., the root directory is

DSDP _1.0, DSDP _ REV must be 1.0.

Important information: scripts may not use a fixed directory path, otherwise a default working directory is created. The emulation script must be able to set up different paths (e.g.,/home/< user-name >/workspace) to avoid the user working offline through the PC.

The embodiment discloses a working directory management script, and all scripts only support a bash shell script language. By using the scripts, the working directory can be conveniently created, and the environment variables are automatically set in the working directory. This section mainly describes the functionality of these scripts.

A work directory is created that may use the script command cow (check out work-name) < cow < project-name > < project-vision > < work-name > (which relates to the code warehouse settings of the SVN)

For example:

％cows dsdp 1.0/projects/users/<user-name>/ws01

this command will download the database from the dsdp _1.0/trunk directory of the SVN's code repository to the local work directory:

/projects/<user-name>/ws01

before running a script or developing work in the working directory, the setws command must be used to enter the working directory.

The command may set the correct work environment variables for the work catalog. It is explained that after entering the working directory using the setws command, a new shell is created. If it is necessary to work in a different working directory or to cancel the environment variable set by the setws command, the shell must be pushed out using the exit command before the different working directory can be entered.

％setws<project-name><project-version><workspace-name>e.g.

％setws dsdp 1.0 ws01

$ DSDP _ UPATH ═ projects/tiger/1.0/users/< user-name >/ws01 (default working directory)

$DSDP_PPATH＝/projects/tiger/1.0

$DSDP_PROJECT＝tiger

$DSDP_REV＝1.0

The user can also set the absolute path of the working directory by himself instead of the default working directory path.

For example

％setws dsdp 1.0～/ws01

$ DSDP _ UPATH ═ projects/users/< user-name >/ws01 (typically using a well-defined default path)

$DSDP_PPATH＝/projects/tiger/1.0

$DSDP_PROJECT＝tiger

$DSDP_REV＝1.0

To set the environment variables, the cow command creates a hidden file in the user's working directory. The user may not modify the file. The setws command creates the environment variables of the user work directory using two files.

The EDA tool's environment variable, e.g., $ VCS _ HOME, is set by the shell script associated with the project, the shell script's location: $ DSDP _ PPATH/env/tool _ setup.sh (EDA tool related configuration script)

The setws command will run the script, setting the PATH and other environment variables associated with the EDA tool. The executable path of the EDA tools is added to the file so that all users can use them. This file has no version maintenance. To illustrate, if offline use is made, for example, on a virtual machine such as a PC, the $ DSDP _ PPTH variable does not exist. In this case, EDA tool environment variable setting will not be performed, and the user must set the executable path of the EDA tool himself. The script will not check that the mounting path of the EDA tool is correct, it will only set the relevant path before running the EDA tool.

Finally, it should be noted that the user can add the environment variables according to the project requirements. In the user's work directory, if the user creates a.dsdp _ user _ ws.rc file, the script file will be executed after the shell script has executed other scripts.

Example 3

The embodiment discloses a code warehouse architecture, an independent design code warehouse must be arranged, different projects are independent of each other, and the independent main line (trunk/mainline) is provided. A trunk/mainline of 2+ N is normally set.

The IP directory of the design function module main line comprises an IP module and a reusable subsystem module. Each module must contain all design and verification files.

The vc directory of the mainline of the authentication function module contains reusable authentication function modules, such as bus function models, which may contain a bus function model, such as DMA. The bus functional model is separate from the behavior level model, which is placed in the mainline of the design functional module.

The mainline of the project/chip has version management, and the mainline of the project/chip comprises top-level design files and subsystems which cannot be reused, such as I/O modules, and a specific chip hierarchy.

In order to associate a code repository with an item, each version of a chip must have its own main line, e.g., a particular chip must have:

my _ chip _1.0 chip main line of first edition flow sheet

My _ chip _1.1 as chip main line of metal ECO

my _ chip _2.0 chip main line of full-layer mask

Next _ chip _1.0 Next generation chip bus, such as new architecture or directory structure where the original constructed branches can be used for new fullfame tape-out code warehouse is as follows:

ip------

/trunk(mainline)

/branches

/tags

vc------

/trunk(mainline)

/branches

/tags

<chipA>_1.0------

/trunk(mainline)

/branches

/tags

<chipB>_1.0------

/trunk(mainline)

/branches

/tags

such code warehouse architectures may typically support multiple project developments.

The other code warehouse path is mainly used for version control of internal tools, and the position of the code warehouse is as follows: (can be placed in the ip/vc level code warehouse)

svn+ssh://project/svn/repos/EEBOX_tools/trunk/

Any one chip mainline contains local and referenced modules and verification components. All referenced components, such as mainline modules from ip and vc, may reference the code of ip and vc through the externals property of the SVN. This option may contain external components, which may come from a snapshot that may not be modified (stable module) or from the development mainline (module under development). It should be noted that another reference model is to create a branch of the ip or vc main line related to the item, so as to simplify external references.

To simplify the code repository, any emulation of a module should only be done in the chip working directory. There are many benefits to running emulation under the IP working directory, but this requires that each IP must be controlled by a separate version, which results in a separate emulation working directory being necessary for each IP module. Therefore, it is preferable to run the simulation under a unified project work catalog. It is undesirable to design and develop a new IP block before chip development.

Example 4

This embodiment discloses a module directory structure (IP), and each IP module must maintain a uniform directory structure. The directory structure is tightly tied to the IP file manifest (manifest) and the emulation scripts. The directory structure can be expanded, basic variables of the IP module can be set, and the method is suitable for different EDA tools.

The following mainly introduces the key points of the IP directory structure:

all IP related authentication platforms and authentication cases must be placed in the IP directory structure.

Other optional directories must be included for adding different procedures and tools, such as code checking (lint, CDC, SpyGlass), logic synthesis (DC/RC), formal verification (Formality/LEC), static time-of-permission analysis (STA/PT), design for testability (DFT/test), etc.

The structure based on the IP-XACT standard is more suitable for peripherals with memory mapping such as MAC. The core idea is that a register interface is designed by using XML, and header files of various programmable registers such as RTL, verification and software can be automatically generated.

The source code file for a module must be prefixed by or named after the module name. For example, if the name of a module is widget, then all source file names under the views/rtl directory use widget.

widget.v

widget_submoduelA.v

widget _ submoduleb.v., and the like.

The following are the main subdirectories and files of the ip directory structure:

ip < - > the directory is part of the chip main line

- < Module > < -name of design Module

-module >. manifest < -runsim.pl controlled file list

- -import < - -authorized IP directory which can be a subdirectory

---<ip_block_name>

Directory structure provided by a third party

-different views of views < -IP

Registers and other definitions of the-xml-IP-XACT standard

RTL source code for-RTL < -module

-pre < -netlist file after logic synthesis-optional

-post-physical design netlist file-optional

-timing all SDF files and extraction parameters files (subdirectory 13 can be set)

- - -bhv- -behavioral level model

-FPGA < -RTL file optimized for FPGA

-Matlab-model file

- - -sim < - -functional verification directory

-waves < -simulation generated waveform file Verdi-fsdb file and the like

-tests < -verification case list file performing regression testing

---tests

- - - - < test1>/test1.[ s ] v < -verification case document: verilog or SystemVerilog

test1.bconfig < -setup configuration File

test1.rconfig < -run configuration file- - - - - - - < test2>/test2. s ] vtest2.bconfig

test2.rconfig — tb _ common < -verification platform file, predefined file, coverage control file, etc

-doc < -document relating to design modules

The specification of-spec < -design module includes architecture, micro-architecture, state

Machine and programming manual

- - -ref < -reference, book or code

-synthesis directory of synth < -design modules

-scripts < -scripts for executing a logical synthesis flow

- - -logs < -log file

-reports < -report file:

-outputs < -output files generated after the logic synthesis process is performed

Software < -driver or firmware of a design module

Drivers or firmware of the-C < -C language version

-<module2>

--etc…

Example 5

The embodiment discloses a directory structure of a verification component VC, which is similar to the directory structure of an IP:

vc < -the directory is part of the chip main line

- < VC1> < -the name of the VC module

List of files controlled by a manifest < -runsim. pl script

-import < -third party authorized IP subdirectory structure

-a < vc _ block _ name > < -third party published directory structure

Views of the views < -verification component VC

Registers or other definitions of the standard format of-xml < -IP-XACT

- -Verilog "< - -SystemVerilog or Verilog code source file

Code source file of-C-C language

-sim < -verification platform, how to use verification component VC

-waves < -simulation generated waveform file Verdi-fsdb file and the like

-tests < -verification case list file performing regression testing

- - -tests < -verification cases

test1.bconfig < -setup configuration File

test1.rconfig < -run profile

------<test2>/test2.[s]v

test2.bconfig

test2.rconfig

- - -tb _ common < -verification platform document, predefined document, coverage control document, etc

-doc < -document associated with verification component vc

Specification of-spec < -verification component VC includes architecture, state machine, etc

- - -ref < -reference document

For file manifest format

In light of the foregoing, any one of the subsystems or the top layer of the chip can be considered a design block.

Each module has its own < module >. manifest description file. The description file is based on a text format and carries simple variable flags. The following is an example of a typical file list:

<deps>

foo

bar

parts

<rtl>

views/rtl/widget.v

views/rtl/widget_ctrl.v

views/rtl/widget_data.v

<rtl:dirs>

views/rtl

<rtl:deps>

bar–dsm

//comment

<sim>

sim/tb_common/tb_widget.v

sim/tb_common/widget_pkg.sv

<sim:dirs>

sim/common

<sim:deps>

verif_common

<synth>

(rtl)

<synth:deps>

bar–pre

<synth_fpga>

(rtl)

views/ngc/xilinx_fifo.v

<synth_fpga:deps>

(synth)

bar-pre

the file list mainly provides a flexible method for setting files, and directories set in the file list can be used as parameters for generating the file list required by the simulator.

Manifest may allow file configuration. The configuration of the file list does not require a specific directory to be displayed,

for example, the "fpga" configuration does not require a subdirectory of fpga. In this case, the simulation script does not need to pre-define + FPGA for the simulation tool.

Under the identifier of the view, the user can specify the file that the module/view contains, which can be either mparse script specified or a dependent file from other modules.

The < deps > identifier indicates that the module is dependent on other modules. The < config: deps > identifier indicates that the module can locally override any dependencies that were in place based on the configuration information. Typical examples of such applications are: the DSM model can be used for RTL functional simulation, but the use of RTL code is required for logic synthesis, i.e. the configuration of logic synthesis must integrate all RTL configurations. By default, dependencies integrate views containing modules. However, the dependency of the views of the modules may be changed by switches.

For example, module2-fpga may specify that module2 uses a view of fpga. The module view of the dependency can be changed by including another (< new _ view >) identifier of < view: deps >. Once this identifier is used, the dependent modules of the module that do not specify a particular view will use the new attempt of new _ view to replace the view of the original module.

When one view contains another view, only the files and folders of the view are contained, but the dependent files of the view are not contained. In the above list of files, if the view of the module is set to synth, it also contains the rtl view, that is, the synth view contains the file (widget _ crtl. variable widget _ data. v) contained in the view rtl, and also contains the directory (views/rtl) of the rtl. But the synth view does not contain rtl specific dependencies, like the file list in the example above, and the dsm view where rtl depends on bar is not contained in the synth view. The view of the synth would still use the default dependency such as bar would still be synth.

Description of the drawings: the view of the verification platform of the module (e.g., the sim view) will be handled in different ways. In practice, the rumsim command will be parsed twice, once as an RTL design and once as a verification platform file, typically a sim view.

The parsing script of the file manifest is mparse. As with runsim, they can only start executing from the/project/chip working directory. mparse has the following parameters:

DSDP _ Upath, which can override the environment variable $ DSDP _ UPATH

-DSDP _ PPATH, which can override the environment variable $ DSDP _ PPATH

DSDP _ project can override the environment variable $ DSDP _ RROJECT

-DSDP _ REV, which can override the environment variable $ DSDP _ REV

-module < module-name > -setting the module name

View < view-name > any process library information such as set-up views such as rtl, fpga, etc. is configured with a $ DSDP _ PPATH/env/tech.

The operation output file is a file list character string similar to that recognizable by verilog simulator. In that

The process library variables are defined in the DSDP _ PPATH/env/tech.pl file, so that the file list interpretation script can generate verilog files of-y and-v.

Example 6

The present embodiment discloses build and run configurations, the goal of the EEBOX being to separate the compile time and run time configurations for validating cases and generating catalogs. Each verification case has a configuration file that is created and run, taking into account the directory structure of the module.

To keep up with the goal and convenience, these profiles are developed using Perl syntax and can therefore be called by run scripts written by Perl (using require syntax).

Each set-up configuration is unique, and each run configuration is also unique with respect to one set-up configuration. On the basis of a random seed, the running configuration may have a unique series of instances.

The embodiment discloses a simulation running script, and runsim is a simulation running script which is mainly used for running function simulation and comprises a module, a subsystem, a full chip, an RTL (real time language), a gate-level netlist and the like. This script is written in the perl language. This requires the engineer to be familiar with the perl scripting language, which facilitates maintenance of the script. The script may be invoked from any directory.

A typical application format for invoking runsim is as follows:

％runsim–module<module-name>-view<rtl>-test<test-name>-sim vcs-dump

parameters of runsim:

-DSDP _ update overriding the default variable $ DSDP _ UPATH

Override default variable $ DSDP _ PPATH

DSDP _ PROJECT overriding the default variable $ DSDP _ PROJECT

Override default variable $ DSDP _ REV

Module-because the runsim script can run an emulation from any one directory, it must be specified

Module name, the runsim script does not simply point to the directory that currently calls runsim.

View specifying rtl, fpga, pre or post configurations. The default value is rtl. For subsystems, rtl and fpga are the most common configurations, while pre and post configurations are commonly used for hardmac.

The run script will use these configurations to determine the compiled source files that are already in the file manifest. In addition, macro variables of the FPGA may be defined for specifying some design files or verifying platform file code. The configuration of Pre and post may define the "GATE _ LEVEL" macro variable at compile time.

-bconfig < integer > using integer designations to establish configuration

-rconfig < integer range | list > specifies the run configuration by an integer, range or list, such as 3-10, or 1, 3, 5, etc

Submit the emulation commands into the emulation queue using batch commands

Run _ only-no re-establishment is required. This is useful for regression testing, and simulations can be run using different seeds for the same verification case. This parameter may be used in conjunction with run _ num.

Build _ only-do not run simulation but build

Test specifies the name of the verification case, which must be located in the sim/tests directory.

Dump generating waveform files, etc

A dump _ format specifying the format of the waveform file, with a default value of vcd, the shm of cadence, or the fsdb of verdi

Cov enabling coverage unification function

-seed: if the simulation fails, a specific seed can be designated to rerun the simulation and reproduce the original error

-result base specifying a basic directory for build and run. The default directory location is $ DSDP _ PATH/results/< view >/< module >/< test > (view rtl/pre/post, etc.). The default output PATH may be replaced with an environment variable $ DSDP _ PATH.

Run _ dir < directory > renames the name of the running directory, such as changing "run" to another name. This is useful when re-running failed verification cases, using which a new simulation result catalog can be generated while retaining the old results.

Repeat _ num < integer > the simulation is run repeatedly N times.

Start _ num, by which a unique running number can be provided if the random simulation is re-run during the regression test. The method is mainly used for high-level regression testing scripts and provides a unique run-dir directory for each regression test. The default value is 0, in combination with the repeat _ num parameter, the first initial value of the running value can be set.

Max _ errors < number > -the number of errors that can be checked before the end of the verification case. The default value is 5.

Seed < number | random > specifies a seed for the authentication case. This value must be a decimal number of 32. If random is set, runsim will generate a random seed. The default value is 1.

Sim _ args "< strings >", passing a command line parameter to the simulator, such as a parameter that is not configured in the running configuration

All running all verification cases, including all setup and run configurations

List < list-name > A list of verification cases and configurations is set for the least-scale regression test.

It is shown that the complicated regression test needs to be implemented in a higher-level script, and runsim can be called for many times.

Information filter switch, which can add extra parameters according to project needs to set those verification cases successfully according to plus-arg. For example, parameters may be added for invoking Matlab

Description of the drawings: the created and run directory is placed in the base directory. Basic directory structure of the simulation Structure:

<base-directory>/results/<view>/<module>/<test>

< base-direct > can be set either by $ EEBOX _ PATH or by-restart _ base parameter.

All the operation results are stored in their unique operation directory, and the directory structure is as follows:

<base-directory>/results/<view>/<module>/<test>/build.<build_cfg>/run.<run_cfg>.

<run_num>

example 7

This example discloses regression testing, the basic minimal-scale regression testing can be processed through runsim scripts (-all and-list parameters). Another tool, "regress," is used to run multiple verification cases in parallel. With this tool, each verification case can be randomly tested for regression under the new random seed configuration.

After all the verification case simulations are finished, regress displays a running report of the verification case on a screen, and can also send a mail to a relevant engineer.

A typical command to run progress is as follows:

％regress–module<module-name>-list<test-list>-limit<limit-number>

the regression parameter:

module < module-name > stores the module directory name of the authentication case. The module is stored in

$ DSDP _ UPATH/ip or $ DSDP _ UPATH/vc directory. Description of the drawings: the verification case list can be used to run any depository

List < list > list of running verification cases. This list must be stored in < module >/sim/lists/< list >.

View < view > -specifying a view of the design module. The verification case list may override this parameter by the per-test parameter. The default value is rtl.

-limit < limit > specifying the maximum number of submitted parallel tasks. This number must be less than or equal to the number of processor cores available to the server. If a company has a batch task processing system, the value must be the total core number of cells, otherwise the system may crash. The default value is 2.

-blimit < limit-number > specifies the maximum number of submitted parallel build tasks. This number must be less than or equal to the number of processor cores available to the server. If a company has a batch task processing system, the value must be the total core number of cells, otherwise the system may crash. If the parameter is not set, the value is the same as-limit.

-results < directory > which holds the root directory of runsim's output (including creating and running files that are output). If the parameter gives a relative path, then the path is placed in

After $ DSDP _ UPATH, otherwise the absolute path is used. The script may set any directory. The default value is results.

Details are made to the contents of the regression test report, which usually provides only failed verification cases.

Job _ status, which allows regression to issue a message when a task is submitted or completed. Typically, regress will only output failed verification cases.

Run _ dir < directory > specifies a different name for the run directory under the results directory. The advantage is that the original run directory can be kept while running the simulation in parallel. The default value is regress.

-mailto < user > after the regression testing simulation is completed, the server email system sends the email to the designated user. Default value is $ USER

Non-mail sending

Sim < simulator > sets up the simulator that builds and runs the verification case. Effective values are viriole, ius or vcs. The shell of the regress construction user has already set the executable path of the simulation tool. The default value is virilog.

Maxrr < maxrr _ number > error maxima in the regression test simulation that will stop submitting new tasks when the regression test simulation reaches a maximum. The verification case list may override this parameter value. The default value is 10.

Concur < concur _ number > -sets the number of tasks that each authentication case can run simultaneously. The list of verification cases may cover this value. Specifying that the limit parameter value limits the parameter. The default value is less than 5.

Total _ number > when set, will overwrite the < total > field of each verification case in the list of verification cases

Regression tests are specified in Lists files, which are stored in sim/Lists of the ip or vc module. These files specify the complete regression test. Description although the list of verification cases is stored under the module directory, the verification cases under a particular module may be specified by a module parameter. The verification list file follows the following rules:

the # represents an annotation

Allowable blank space

Definition of each authentication case exclusive to one line

Double quotation marks for parameter use

The following parameters are used to specify a verification case.

The necessary parameters are as follows:

·-test<test-name>:specify the test to run

test < test-name >. optional parameters for the verification case where the simulation is run:

module-module < module-name > module for running simulation

Total _ number > Total _ number total number of the verification case run simulation. If the failed verification case has reached the maximum number maxerr before the total number of verification cases for the batch is reached, the simulation may stop. If the value of the total parameter of the script is not 0, then the value of the total parameter in the verification list is overwritten.

Verification case simulation is the maximum number of parallel runs. The numerical value of the parameter is always limited by the limit parameter of the script, and the overload of the regression testing server task is avoided.

-bconfig < number > number of configuration build

R. rconfig < number > number of running configurations

View of different verification cases

Example (c): modulator _ wrp/sim/lists/all

-test simple-total 1

-test matlab-total 10-concur 10

The above verification case list defines 1 run of a simple verification case and 10 runs of a matlab verification case, allowing the verification case to run parallel 10 instances.

Example (c): chip _ common/sim/lists/all

#This testlist file holds all tests for the project verification

#crc

-module crc-test simple-total 1

#-module crc-test matlab-total 100-concur 10-Not ported yet

#rx_src

-module rx_src-test simple-total 1

-module rx_src-test matlab-total 50-concur 10

Even if the file list is located in the chip _ common directory, it can still run other module level authentication cases by setting the module parameter. The words behind the presentation symbol # presentation # are all comments, which are descriptions and illustrations of the verification case list file.

In the section of the code warehouse directory structure introduced above, each main line (ip, vc, or independent item) has its own tag directory. Because the tag is the outermost layer of the code warehouse catalog, the tag is aligned using methodology

Tags are named, for example, for an IP publication, the SVN URL is always handled by a tag rather than the module name.

The following is a recommended label naming method:

for IP blocks: < MODULE _ NAME > _< MAJOR > < MINOR >

MAJOR is a two-digit decimal number

MINOR is a two-bit decimal number

For example: WIDGET _01.03

Description of: using IP or TAG in the name is redundant because the SVN URL already contains these characters in the path, such as $ SVNROOT/IP/TAGs/WIDGET _01.03/WIDGET …

For the verification component VC, a similar method to IP can be used for the project, and a different publishing method can be used. The different types are as follows:

regression auto-tagging the Regression test script can set a label on the state technology of the whole project data:

YYYY, MM, DD, ri, hh MM, ss, 24 hours: the method comprises the following steps: dividing into: second of

SVN cannot directly tag or sign private files or folders, and in actual practice it makes no sense to create something other than to issue RTL code. However, it is reasonable to distinguish between different releases in view of different objectives, such as regression testing.

FPGA _ mmmm, e.g. FPGA _0245 is the RTL published for the 245 th FPGA setup

GATE _ mmmm-for example GATE _0122 is the RTL issued for logical synthesis setup

RTL _ mmmm for example RTL _0043 is a 43 rd time general purpose RTL snapshot like the application scenarios of IP and VC, SVN URLs can scratch off project name and version information to allow for logical synthesis and physical design output and RTL source code, suggesting a post-end release directory structure as follows:

/projects/my_proj/1.2/backend/rel_0122/…

example 8

The embodiment discloses the structure of the verification platform and the verification case, and fig. 3 shows how to construct a simple module verification platform and the storage location of the related documents.

The verification platform must contain at least one top-level verification platform file that contains common verification platform components (e.g., watchdog timers, signal checkers and drivers, verification models, etc.). The verification platform must also instantiate a design under test DUT. The top level verification platform will contain a specific verification case instance, named test. A separate verification case can be created by replacing the a.v files under the directory < module >/sim/tests/< test > with test.

For example, if a verification case is located in the < module >/sim/tests/simple directory, then this file must be named simple.

Description of the drawings: runsim will first compile the < test >. v file. Thus, at the time each verification press is created in the EEBOX environment, the user must include the "tb _ common.v" file at the top of the < test >. v file.

In this embodiment, the case log macro definition is verified

In order for all verification cases to maintain a uniform code style and verification functionality, the user must process various information such as warnings, errors, fatal errors, etc. encountered in one verification case using the following macro definition.

All log information is printed on a screen or in a file in a uniform format, and the information format comprises simulation time and related information (ERROR, WARNING and INFO).

For example:

95ns:INFO:Driving the input stimulus.

the function $ sformatf is implemented in the functional verilog of EDA tools IUS of Cadence, and macro definitions are no longer needed to generate log files. The $ sformatf functions as $ sformat, printing formatted information. But the $ sformatf function returns a string, while the $ sformat returns a variable of one register type instead of a string.

For example, an example of the $ sformatf function:

"DSDP _ ERROR" ($ sformift ("My checker expected 0 x% 02x and go 0 x% 02 x", exp, actual)) ERRORs, warnings, and fatal ERRORs will always print out the call location of the source file, facilitating debugging.

For example:

EEBOX_FATAL source location logging

position information of EEBOX _ false source file:

`DSDP_FATAL(“Hit a fatal end”)

95ns:FATAL ERROR:Hit a fatal end

95ns:

at

/home/username/ebox/ip/modulator_wrp/sim/tests/simple/simple.v:40

the LOG of the print information can be obtained using the macro variable' EEBOX _ LOG. This macro variable contains an information filtering switch. The range of the switch is 0 to 9 the smaller the value the more information is printed. Since runsim does not support the value 0, if the value of one message is 0, all the messages are printed. The following are definitions:

`define SYSTEM_MSG 0

`define LOW_MSG 1

`define MED_MSG 5

`define HIGH_MSG 9

example DSDP _ LOG:

`DSDP_LOG(`SYSTEM_MSG,“starting my test”)

description of the drawings: there is no semicolon after the macro definition, otherwise virilog would suggest a syntax error.

For the WARNING information, a DSDP _ WARNING macro definition may be used.

`DSDP_WARNING($sformatf(“Received an unknown value of％0d”,value))

For ERROR information, the' DSDP _ ERROR macro definition may be used

`DSDP_ERROR($sformatf(“My checker expected 0x％02x and got0x％02x”,exp,

actual))

The macro definition' DSDP _ ERROR has the additional function of ending the simulation when the number of ERRORs in the verification case reaches the value of-maxerr. The user may set the value of-maxerr to 0, which may prevent premature termination of the simulation.

For a fatal error, such as an assumed condition in the code is not satisfied, there is no need to continue the simulation. "DSDP _ FATAL ($ sfrformatf (" Received return value of% d, can not processed ", value))

Finally, the user may invoke the macro definition' DSDP _ FINISH to inform the emulator that the verification case is over. Otherwise, runsim would assume that the verification case ended prematurely and an error message would be printed. "EEBOX _ FINISH has a parameter that is tied to a signal that can confirm whether the verification case is completely stationary or finished, e.g., all checkers and input stimulus signals are complete. If an authentication case does not require this functionality, the user may pass a parameter 1 to DSDP _ FINISH.

Example (c):

//complete a test with no end-of-test checking

stopping the simulation without checking the end of the verification case

initial begin

sig_driver.DriveSignals()；

//…

`DSDP_FINISH(1)

End

The embodiment discloses that the verification case data file runsim is not used for establishing or operating the verification case under the verification case directory. This is done to avoid generating files in the source code repository. Any generated files are always stored in the results directory. The runsim command enters the build directory when compiling the verification case and the run.n.k directory when running a particular verification case.

Therefore, special attention needs to be paid to the link data files during the running of the verification case. For example, a direct verification case may input a hexadecimal data to drive the signal, while also requiring a hexadecimal data output for inspection. runsim provides a simple perl scripting tool that points verification cases from the directory where the simulation is run to the directory of verification cases by means of symbolic links. This file is runsim. The file is written in the perl language and runsim will execute this perl script before running each verification case.

An example of a runsim run.pl under directory modulator _ wrp/sim/tests/simple is as follows. It links 3 files in.dat, modulator _ wrp _ out.dat and modulator _ out.dat to the directory of the verification case.

runsim will set the environment variable $ TESTDIR to point to this verification case directory. If the perl script execution succeeds, a return value of 1 is passed to runsim.

#runsim.run.pl

#when this file is present in a test directory,runsim will execute this PERL script

before starting the#simulation so the user may copy files,customize the

environment,etc.

#Note that when this script is executed,runsim will be cd`ed into the run directory:

#e.g:results/…/build.0/run.0.0

#The variable TESTDIR is set to the absolute path of the test directory.

#Create links from TESTDIR to run directory(we are currently cd`d to there)of the

input stimulus

#and the expected sig_checker files.

system“ln–sf$TESTDIR/in.dat.”；

return 0if$？；

system“ln–sf$TESTDIR/modulator_wrp_out.dat.”；

return 0if$？；

system“ln–sf$TESTDIR/modulator_out.dat.”；

return 0if$？；

#must return non-zero value indicate success to PERL

1；

This embodiment discloses a random seed, runsim provides one random seed for each verification case run. This seed is a 32-bit signed integer that is passed to the verification case by the parameter + seed ═ number > with a default value of 1. That is, if a verification case is run without a random seed, the results are the same for each run of the simulation.

runsim support parameter "-seed random", that is runsim, generates a random seed, which is then passed to the verification case via the system function $ plusargs. In addition, the seed set by the user can be delivered through the parameter "-seed < number >".

The verification case may not automatically generate a random seed. The random seed must be passed to Matlab or verilog code through an external system function $ plusargs to ensure that the verification case can be reproduced. A product is described below

A method for generating random seeds.

integer seed；

initial begin

if(！$value$plusargs(“seed＝％d”))begin

seed＝1；

end

//use seed in the first$random call only

addr＝$random(seed)；

length＝$random％MAX_LEN+1；

end

In conclusion, the invention has low cost, reduces the development cost of integrated circuit design, including the communication cost of time, manpower and team cooperation;

the invention has simple learning and convenient management. The whole development environment is realized by using a Perl script language, and besides the existing design and verification tools, development tools such as logic synthesis, static time-sensitive analysis, physical design and the like can be developed according to project requirements.

The above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.

Claims

1. An enterprise IC design method based on EEBox is characterized by comprising the following steps:

2. The EEBox-based enterprise IC design method of claim 1, wherein in S1, the administrator can try out the EDA tool of new version on the local modification environment, the running script directly calls the corresponding EDA tool, and the correct configuration of the environment variables of the EDA tool is a precondition for ensuring the normal use of the EDA tool.

3. An EEBox based enterprise IC design method according to claim 1, wherein in S3, the environment variables set in the shell by the user must use absolute path, the script tool can rewrite these variables by passing parameters to facilitate the test, the script may not use fixed directory path, the simulation script must be able to set different path to avoid the user working off-line through PC.

4. An EEBox based enterprise IC design method according to claim 1, wherein before running a script or developing work in a working directory, a setws command must be used to enter the working directory, which is used to set the correct working environment variables for the working directory, after entering the working directory using the setws command, a new shell is created, and if it is needed to work in a different working directory, or the environment variables set by the setws command are cancelled, an exit command is used to exit the shell and enter a different working directory.

5. An EEBox based enterprise IC design method according to claim 1, wherein in said method the setws command will run the script, set the PATH and other environment variables related to the EDA tool, add the executable PATH of the EDA tool to the file, all users can use the EDA tool; if offline use, the EDA tool environment variable setting will not be performed and the associated path is set before running the EDA tool.

6. An EEBox-based enterprise IC design method according to claim 1, wherein any chip main line in the method contains local and referenced modules and verification components, and all referenced components such as main line modules from ip and vc can refer to code of ip and vc through the exceptions attribute of SVN. Options contain external components from snapshots that cannot be modified or from the development mainline.

7. An EEBox-based enterprise IC design method according to claim 1, wherein another reference model is to create a branch of the IP or vc main line related to the project, simplify external references, any simulation of a module can only be performed in the chip working directory, each IP is controlled by a separate version, each IP module has a separate simulation working directory, and the simulation is run under the unified project working directory.

8. An EEBox based enterprise IC design method according to claim 1, wherein each verification case has a build and run configuration file, the configuration file is developed using Perl syntax, called by Perl written run script, each build configuration is unique, each run configuration is also unique with respect to a build configuration, and the run configurations are a series of unique instances on the basis of random seed.

9. The EEBox-based enterprise IC design method according to claim 1, wherein, in said method, a simulation run script is used for running function simulation, including module, subsystem, full chip, RTL and gate-level netlist, etc., the script is written in perl language;

10. A development platform of an EEBox-based enterprise IC design method, comprising a processor and a computer-readable storage medium, wherein the computer-readable storage medium has stored therein computer-executable instructions, which when executed by the processor, implement the EEBox-based enterprise IC design method according to any one of claims 1 to 9.