WO2009047685A2

WO2009047685A2 - Assertion based verification of interconnected subsystems

Info

Publication number: WO2009047685A2
Application number: PCT/IB2008/054061
Authority: WO
Inventors: Jan Stuyt; Sylvain Boucher
Original assignee: Nxp B.V.
Priority date: 2007-10-10
Filing date: 2008-10-03
Publication date: 2009-04-16
Also published as: WO2009047685A3

Abstract

A method is discussed of supporting property-based verification coverage for a test of a design for a system comprising multiple sub-systems. The sub-systems are functionally interconnected through interconnects. For the respective interconnects, respective properties are determined relating to respective characteristics of the respective interconnects. During the test the cover properties are temporarily monitored in disjoint time intervals.

Description

Design verification software

FIELD OF THE INVENTION

The invention relates to the structural verification of a systems-on-chip (SoC) design by means of digital simulation.

BACKGROUND OF THE INVENTION

An SoC is a collection of interconnected IP-blocks (also referred to as "cores"), e.g., library cells. An IP -block within this context is a re-usable module for a modular chip design at the logic or functional level. The pre-fix "IP" indicates that the block may be intellectual property of a specific party. Most system- verification methods aim at running functional overall system tests, thereby implicitly testing the interconnectivity of the constituting blocks. However, the preparation of such a functional test requires explicit initialization of the IP -blocks under test, and also of other IP-blocks in the SoC. Instead of such functional tests, one may also run directed tests to find potential structural system errors in an explicit way. Such tests are explicitly concentrating on the connectivity between the blocks. These directed tests are typically executed by running dedicated software on a processor within the same design.

For more background on verification of SoC designs at various levels see, e.g., US patent 7,231,627; US patent 6,571,373; US published patent application 2003/0121011; US published patent application 2006/0242524, all incorporated herein by reference. The question arises how to judge the coverage success of the directed tests executed through verification software, and whether or not the expected signal transitions have actually been seen on the I/O pins of the IP -blocks and on the wires interconnecting them.

In order to measure simulation coverage, cover properties can be used. A property within this context is a declaration about an interface of a component of the design and the declaration relates to the intended functionality and taxonomy assigned to the interface. When a property has been declared it can then be used as a monitor (i.e., coverage property). An assertion is a statement that specifies how the property should hold. Properties can be static or temporal, and can be used in assertions about the values of specified signals that should occur in a circuit according to the intended design. An assertion is to be verified to determine if the property asserted holds, and if the property does not hold, a failure report is to be made. It is also possible to use a property as a coverage property for monitoring a given behavior. This is useful for giving feedback information about reachability of the behavior described by the property. In a simulation-based verification environment, this information is referred to as "coverage". The term "reachability" refers to a mathematical term to describe interconnectedness of vertices in a graph. The behavior could be modeled as a collection of states and transitions between them, which can be mapped onto a graph. Properties are usually captured using language like PSL (IEEE Pl 850: Property Specification Language).

Aspects of assertion-based verification are described in, e.g., US published patent application 2006/0271890, and in a publication "An integrated Methodology for SoC Design, Verification, and Application Development" by Amir Hekmatpour, Robert Devins, Dave Roberts and Michael Hale, of 2004.

SUMMARY OF THE INVENTION

Specifying properties for the verification of SoC interconnectivity requires deep insight in the functional behavior of the SoC. Specifying properties is a manual process which is difficult to automate. Another problem with coverage analysis is that only overall counts are reported of how many times a certain coverage property has been confirmed. Such cover properties will be confirmed by an explicit test, but probably also through other causes unrelated to the directed test. Accordingly, it may still not be possible to judge the quality of a directed test. This may be overcome by making the property condition more complex so as to reduce the likelihood of being triggered by a spurious event, rather than by events caused by the directed test. However, this puts an even a higher burden on the person specifying the properties, and makes automatic creation of such properties near to impossible.

Therefore, the inventors propose an alternative approach. The inventors propose a method as specified in claim 1. By means of having the coverage property temporarily enabled, i.e., having the coverage made relevant only in a time window of interest, pollution of the coverage result by unrelated events, triggered in other time windows, is reduced or eliminated.

An embodiment of the method relates to claim 2. The cover properties relevant to verifying of the interconnects are active in disjoint time periods so as to eliminate interference. A further embodiment relates to claim 3. In this embodiment, properties are derived from information available in a database. The database comprises information at the sub-system level, about the interconnectivity and classification type of interconnects between the sub-systems. For an SoC design, such a database comprises, e.g., a netlist at the level of IP-blocks. As known, the term "netlist" refers to the description of connectivity of an electronic design. Examples of classification types are: clock, reset, interrupt request, DMA (direct memory access) flow channel, power switch control, tie-offs, debug trigger event, external interface, internal bus interface, etc. The information about the interconnectivity class of a signal at an interface of a sub-system makes it possible to derive a simple property for it. For example within the context of SoC design, if the signal is an interrupt signal and a related test is to verify the proper connection of this signal, it would be sufficient to determine if this signal changes in a certain way within a certain time window. The software test, whose purpose it is to test the proper connection between the relevant sub-systems for a certain signal, will drive the simulated system in such a way that the signal under test follows a defined pattern.

The invention also relates to software as specified in claim 5. The software comprises instructions for executing the method as specified in claim 1. Such software is commercially interesting to providers of software for running simulations of a design.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is explained in further detail, by way of example and with reference to the accompanying drawing, wherein:

Fig.l is a block diagram of an SoC design; and Fig.2 is a flow diagram of an example test according to the invention. Throughout the Figures, similar or corresponding features are indicated by same reference numerals.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Fig.l is a diagram of an SoC design 100 comprising IP blocks 102, 104, 106, 108, 110, 112 and 114. IP blocks 102-114 are functionally interconnected by means of interconnects 116, 118, 120, 122, 124, 126, 128, 130, 132, 134, 136, 138 and 140. Design 100 is simulated on a data processing system (not shown).

Fig.2 is a flow graph 200 illustrating a computer simulation according to the invention. First, the design is loaded into the simulator and the simulation is initialized in a step 202. For example, a list of interconnects, e.g., interconnects 116-140 is prepared at the simulator or loaded into the simulator. In a next step 204, the next interconnect is selected from the list. In a step 206, relevant information about the selected interconnect in retrieved in order to be able to have a property automatically generated in a step 208. Steps 204-208 are repeated until it has been determined in a step 210 that properties have been generated for all interconnects of the list. The process then continues with a step 212. In the next part of the verification, different groups of the properties generated in steps 204-210 are enabled in disjoint time periods. That is, cover properties are enabled or not depending on which part of the verification is being carried out. For example, when checking for the connectivity specific to DMA (direct memory access) signals, DMA-related cover properties are enabled, while Interrupt-related cover properties are disabled, and vice-versa when checking the connectivity specific to Interrupt signals. Each specific group of cover properties, addressing a specific interconnectivity characteristic, is active only once and other cover properties are disabled when the specific group is enabled. The simulation is then run for this specific group of cover properties in a step 214 and its results are stored in a memory. In a step 216 it is determined if the verification is complete, i.e., all interconnects have been checked. If not, the simulation proceeds with a step 218. In a step 218, the next group of cover properties is selected and the simulation returns to step 212. When all tests have been performed, the simulation proceeds to a step 220 wherein a coverage report is generated. The report holds the counts for all properties covered. A trigger count is the number that indicates how many times a coverage property has been hit in the simulation process, i.e., how many tines the behaviour described by the property was observed. Typically, in most cases the expected trigger count will be set at its default value of unity ("one"). In a step 222, it is checked if the reported count is smaller than the expected count, or not. If the reported count is smaller than the expected count, it is inferred in a step 224 that the software implementation of the test is not correct and revision is needed. The test operator can be notified automatically in this case and the simulation is ended in a step 226. For example, if it is not possible to observe the change of logical value at the interrupt pin while running the software that is intended for the verification of the interconnectivity, it can be deduced that the software does not really verify whether the interrupt pin is connected or not. The software should then be revised and the simulation ends in a step 226. If the reported count is not smaller than the expected count it is determined in a step 228 that all interconnects 116-140 have been covered by the recent simulation run. The inventors' proposal is two-fold. First, simple SoC interconnectivity verification properties are derived automatically from the SoCs IP-level netlist. Then, these properties are dynamically enabled/disabled to make them only relevant in the time window of interest. This latter feature avoids pollution of the coverage result by unrelated events. Accordingly, cover properties that are enabled in the simulator will increae their trigger count whenever the behavior described by the properties is observed. If disabled, the properties' trigger count does not change even if the behavior described by these disabled properties takes place.

It is assumed that an IP-level netlist is available that contains interconnectivity classification information about the type of interconnect between IP blocks 102-114 in the design for SoC 100. This is (or will be) the case in SPIRIT IP-XACT design files. Examples of such classes are: clock, reset, interrupt request, DMA flow channel, power switch control, tie-offs, debug trigger event, external interface, internal bus interface, etc. Knowing the interconnectivity class of a signal at an IP block makes it possible to derive a simple property for it. For instance, if the signal is an interrupt signal and a test is to verify the proper connection of all the connecting signals, it is sufficient to see if this interrupt signal did change in a certain way, but only within the time interval, wherein the test is actually checking this very interrupt signal.

Within this context, the SPIRIT Consortium aims to establish IP and tool integration standards to enable improved IP re-use through design automation. IP-XACT is the name given to the set of specifications for IP meta-data and tool interfaces. The IP-XACT IP meta-data description is a meta-data XML schema that creates a common and language- neutral way to describe IP, compatible with automated integration techniques and enabling integrators to use IP from multiple sources with IP-XACT enabled tools. The IP-XACT tool integration API (TGI) provides a standard method to allow tools to exchange design architectural data, enabling systems integrators to build a more flexible, optimized development environment. IP-XACT enabled tools are able to interpret, configure, integrate and manipulate IP blocks that comply with the proposed IP meta-data description. The Tight Generator Interface (TGI) will enable direct data-base querying and writing. The software test, whose purpose it is to test the proper connection of a certain signal, drives the simulated SoC design such that the signal under test follows a defined pattern. The software communicates to the simulator when the relevant properties are enabled or disabled. Accordingly, the cover properties can be switched on and off by the software test, so as to open them up only during a certain time window in which the test is relevant to the given coverage property. This avoids pollution of the coverage metrics by events that have nothing to do with ones caused by the relevant part of the software test. It also allows the properties to be straight-forward and simple, which enables tools to automatically derive these assertions from an SoC design file.

In order to automatically create interconnectivity cover properties, the following approach can be taken. A software tool or script reads a SPIRIT IP-XACT metadata file (XML format) of an SoC (or system) design. It outputs one or more PSL cover properties for each classified signal or group of signals it can find. This is achieved by looking at the bus interface elements of an IP instance in the SoC XML design file and reading the associated attribute(s) representative of the class or type of signal(s) occurring at this interface.

In an embodiment of the invention, the automatic generation of properties relies on the presence of so-called context labels in the system design database. These context labels are associated with the IP blocks in the design and with the interface ports of these IP blocks. The labels are assigned to the interface ports, e.g., manually. The labels are formatted such that an extraction tool can interpret them and can generate the types of PSL property for the connections. Typically, a plurality of different types of these context labels, say 10 or 15, is being used. Accordingly, there are also that many different PSL properties possible, but there may be many instances of them (as many as there are connections in the design). Examples of these context labels are: Clock; Reset; Interrupt; DMA Handshake; Configuration; Power Control; Event; Trigger. The context labels allow a property generator tool to recognize the type of connection, such that the tool can generate the appropriate PSL property for it for purposes of simulation coverage analysis.

Optionally, the tool also reads more detailed information as to how the associated signal or signal group is supposed to behave; otherwise it is sufficient to simply assume that there will be an event involving the signal(s). The cover properties are collected in a single PSL file related to the SoC under test. In order to create the time window for a specific property to be observed, one proceeds as follows. It is assumed that dedicated software tests for SoC interconnectivity verification already do exist. Their purpose is to test a particular connection on an IP instance in the SoC. An IP block has a number of interfaces. An interface can be a collection of pins that together form a structured bus port, or an interface may be as simple as a single pin. Then, the interconnectivity tests can be run with cover properties. An SoC property-enabled simulation job is started which runs the interconnectivity test. Each part of the test enables its own associated cover properties. If there is no associated coverage property, the simulation will still proceed, but no coverage result will exist at the end. When the simulation finishes, a coverage report is generated. The report holds the trigger counts of all cover properties.

These counts are then compared with expected counts. These counts are available per IP type and depend on the implementation of the software tests. It is expected that the reported trigger counts are at least not lower than the expected counts. If the reported count is lower than the expected count, the conclusion can be drawn that either the software test implementation or the design implementation of SoC 100 is incorrect, and revision is desired of the software or the hardware. If the reported count is higher than the expected count, the conclusion can be drawn that the software test implementation may or may not be incorrect.

Although the invention has been illustrated within the context of electronic circuitry design, the invention is also applicable in other fields such as the design of automobiles, urban transportation infrastructure planning, flight schedule planning for commercial airlines, the design of airport security systems, etc.

Claims

CLAIMS:

1. A method of supporting an assertion-based verification test of a design (100) for a system comprising multiple sub-systems (102-114) functionally interconnected through interconnects (116-140), wherein the method comprises: - determining for a first one of the interconnects a coverage property relating to a characteristic of the first interconnect; temporarily enabling (212) the coverage property during the test; and generating (216) a contribution to a coverage report based on the temporarily enabled coverage property.

2. The method of claim 1, comprising: determining for a second one of the interconnects a further coverage property relating to a further characteristic of the second interconnect; and temporarily enabling the further property during the test so as to have the coverage property and the further coverage property enabled in disjoint time periods.

3. The method of claim 1 or 2, wherein the determining the coverage property comprises: consulting a database comprising information about the first interconnect; and - automatically deriving the coverage property based on the information.

4. The method of claims 1, 2 or 3, wherein the system comprises a system-on- chip, and wherein each respective one of the multiple sub-systems comprises a respective one of multiple IP -blocks.

5. Software for supporting an assertion-based verification test of a design (100) for a system comprising multiple sub-systems (102-114) functionally interconnected through interconnects (116-140), wherein the software comprises: first instructions operative to determine for a first one of the interconnects a coverage property relating to a characteristic of the first interconnect; second instructions operative to temporarily enable the coverage property during the test; and third instructions operative to generate a contribution to a coverage report based on the temporarily enabled coverage property.

6. The software of claim 5, further comprising: fourth instructions operative to determine for a second one of the interconnects a further coverage property relating to a further characteristic of the second interconnect; and - fifth instructions operative to temporarily enable the further coverage property during the test so as to have the coverage property and the further coverage property enabled in disjoint time periods.

7. The software of claim 5 or 6, wherein the first instructions for determining the coverage property comprise : sixth instructions operative to consult a database comprising information about the first interconnect; and seventh instructions operative to automatically derive the coverage property based on the information.

8. The software of claims 5, 6 or 7, configured for the system comprising a system-on-chip, wherein each respective one of the multiple sub-systems comprises a respective one of multiple IP-blocks.