1. Field of the Invention
The present invention relates to test components used in a test environment to issue test sequences to a device to be tested, hereafter referred to as a “Device Under Test” (DUT).
2. Description of the Prior Art
When developing components for integration into a system, a number of test procedures are typically performed to ensure that the component will operate in the desired manner when integrated into the system.
The development of a hardware component (also referred to herein as a device) typically takes place in a number of stages. Firstly, the functional operation/behaviour of the component is defined, for example using a Register Transfer Language (RTL). Two popular RTLs used are VHDL and Verilog. In addition, prior to performing such RTL coding, a behavioural model may be built, for example using “System C”, to validate at a transactional level that the design intent is correct.
Once an RTL representation of the hardware component has been developed, this is then synthesised into a sequence of hardware elements using any of a number of known synthesising tools. The result of the synthesis is a hardware design that can then be used to produce the actual hardware component, for example using appropriate fabrication of the component on silicon. It would clearly be very costly to perform test procedures on the component once it has actually been reduced to hardware, and instead rigorous testing of the RTL representation of the component is typically performed to ensure that the actual hardware generated from that RTL representation will operate correctly.
Such testing typically involves the provision of a test environment in which the RTL representation of the component to be tested, i.e. the DUT, is incorporated. Further, representations of other devices are also prepared and connected together with the RTL representation of the DUT via a bus. These representations of other devices can take the form of test components within the test environment, which are used to issue test sequences over the bus to the device under test. The waveforms resulting from such test sequences can then be observed either by visual inspection, or by a self-checking mechanism or module integrated into the system simulation providing the test environment.
As designs increase in complexity, the number of states in a given design at any time increases exponentially. For example, in a multi-layer bus system, the number of interconnecting master and slave devices means that the number of paths that would need to be tested is very large compared to a single layer multi-master system. As will be appreciated by those skilled in the art, a master device can be considered to be a device that is designed to initiate transfer requests via the bus, whilst a slave device can be considered to be a device which is a recipient of such transfer requests.
Conventional techniques used for testing single layer systems involve either writing bus functional models (BFMs) for master and slave devices, or re-using existing master and slave components, such as RTL representations of existing processor models and/or slave memory models. One or more of these BFMs or existing components can be used as test components to issue test sequences to the DUT. The test sequences can either be generated manually (for example by programming the processor model) or by generating a pseudo-random test sequence of data.
As systems increase in complexity, for example in the above mentioned multi-layer systems, then a number of issues arise. Firstly, the writing of directed test sequences for such systems is not only time consuming, but also simulation intensive and prone to error, such as, for example, may result from misconfiguration of a BFM. Secondly, the test sequence has low re-usability, and is tightly coupled with the functional coverage required for the particular test environment. For example, manual intervention is required to specify the coverage goals based on a given configuration of the BFM. Accordingly, any functional coverage holes with this approach have to be filled, for example by writing incremental test sequences or by changing the pseudo-random seed. Finally, the flexibility of the approach is limited since, considering an example where a particular processor model is used as the test component for testing the DUT, the available bus transactions may be limited to a subset of the transactions that are actually supported by the bus. It is not possible to dynamically modify the behaviour of the component.
Hence, it is clear that existing techniques give rise to a number of problems, particularly as design complexity increases. In particular, if specific test sequences are written for a particular DUT within a particular test environment, this is very time consuming, and results in large test stimulus files. In addition, it has low re-usability. If instead re-usable test components are provided within the test environment to generate random test sequences, this reduces the time involved in generating specific test sequences, and reduces the size of the stimulus files, but results in test sequences which by their nature are random and do not reflect the actual activities that would be expected within the “real” system.
Verisity (Specman eVC)/Synopsys (Vera based in Designware)/Cadence (with Transaction Verification Modules—TVMs)/Qualis (Design Verification Modules—DVMs) all provide BFMs for verifying bus interconnect. However, for all of these solutions one either has to modify the source code of the BFM or the stimulus input file for each design environment or bus topology that needs to be emulated. Synopsis Vera and Verisity Specman are the most advanced in this respect in that they each have an API for specifying types of transfers that will be generated by their BFMs. The Verisity Specman Elite tool has the ability for the user to program the random generation of test stimulus based on coverage but this is a feature provided by the tool that needs to be manually programmed.
The AMBA Compliance Testbench (ACT) product from ARM Limited allows for the testing of slave port interfaces in active testbench mode, and when performing such testing provides a feature that accelerates coverage collection. This feature allows the specification of a slave memory range in the form of a base address and a maximum size in bytes. The ACT will then generate random burst sequences within the address region specified. The larger the address region given, the more varied the burst length and data sizes used. The burst data sizes that can be chosen are also governed by a separate configuration parameter and can be constrained to a sub-set that are compatible with those supported by the slave under test.
Although directed-random burst transfers to a defined memory region are useful in this context, it is not possible to exactly specify the type and distribution patterns of the generated bursts. Indeed, the bursts are generated in pseudo-random fashion and will only vary between test runs if a different seed is given.
Accordingly, in summary, it can be seen that whilst it is known to provide reusable test components such as BFMs for use in generating test sequences for a DUT, the known techniques for generating pseudo-random test sequences from such test components do not provide testing that accurately reflects the behaviour of the real system. Whilst the writing of specific test sequences can alleviate this problem, this is very time intensive, and results in large stimulus files which have low-reusability. As design complexity increases, it becomes less and less attractive to write specific test sequences.
Accordingly, it is an object of the present invention to provide an improved technique for generating test sequences to be issued over a bus to a device under test.
USPTO Backgrounds
USPTO Backgrounds