GB2321118A - Development of integrated circuits - Google Patents

Abstract

Integrated circuits such as "Systems on Silicon" are developed by production of integrated software and hardware specification and block models. Each block model relates to an entity having its own inputs, outputs and functionality. Test vectors are generated at this stage having stimuli applicable to all model levels. The same model code is used throughout to develop a gate-level model which is tested using the previously-generated test vectors lead times are shorter because of the integrated approach.

Description

"Development of Integrated Circuits" The invention relates to the development of integrated circuits, and more particularly to the development of complex integrated circuits having over one million gates of hardware logic and over one MB of embedded software.

Such circuits are often referred to as "Systems on Silicon".

Heretobefore, development of such circuits has involved two separate and parallel paths, one for the hardware and one for the software. On the hardware path a high-level hardware definition specification has been prepared, which is then synthesised to produce a gate-level description.

For example, PCT Patent Specification No. W096/29665 describes a process in which a synthesis shell is generated by beginning with a gate-level description of a fully characterised and optimised block. This is subsequently reduced by removing internal gates. As described in EP0294632 (IBM) a method begins with a set of register transfer statements which are converted to expressions in prefix form. There is then logic reduction and modified expressions are converted to a set of logical function blocks. Other specifications which describe hardware logical simulation include US5402357 (VLSI), W096/02038 (VLSI), US5490082 (VLSI), US5541850 (VLSI), W095/05637 (VLSI), W094/04986 (Siemens), GB2244156 (Sun) and EP0405728 (DEC). Another development in this area is behavioural synthesis, which is a more comprehensive process for efficient hardware synthesis. Such a process is described in US5299137 (VLSI).

In the software path, the software has been typically designed manually using Yourdon or Specification Definition Language (SDL). A different set of design tools has then been used in a design stage. These tools include code generators which produce code using languages such as C or C++. This code tends to be relatively inefficient. The software has then beenb tested using incircuit emulators. This testing involves an iterative approach which unfortunately cannot guarantee that errors do not exist in some complex software algorithms, or that timing errors do not exist. In practice, a complete system such as a GSM mobile telephone would have to be assembled before all software errors can be detected and debugged.

Because the software and hardware paths are separate, in practice a considerable amount of time has been devoted to the testing stage to ensure integrity. This unfortunately causes long lead times in development of integrated circuits, this disadvantage becoming more acute because of the fast-changing way in which integrated circuits are applied. For example, the rate of development of mobile telephones is very fast and there is a need for a much shorter lead time in the development of integrated circuits for this application.

According to the invention, there is provided a process for development of an integrated circuit design, the process comprising the steps of:producing an integrated system specification model in a model code, producing a user interface model, and performing user interactive testing of the specification model using the interface model; producing a block model in said model code of each hardware and software entity which has definable inputs, outputs and functions; optimising the block models and adding constraints; producing test vectors from said specification model and said block models by setting stimuli relating to integrated circuit ports and associated stimulus times and determining corresponding output times according to pipelining delays for lower level models in said model code; synthesising all block models to produce an optimised gate-level model in said model code; and testing the gate-level model using the test vectors.

Thus, the invention provides an integrated approach to development of integrated circuits by use of a common model code for the specification model, the block models, and ultimately the gate-level model. This allows comprehensive monitoring from an early state in the process of all functions of the integrated circuit being developed. Further, it also allows the generation of test vectors at an early stage and setting the input stimulus time whereby these vectors may be used at a low-level by simply allowing for pipelining delays in the corresponding output signals.

In one embodiment, the specification model incorporates sub-models of components of the circuit.

Preferably, the specification model is tested during interaction with external component models and said user interface model.

In one embodiment, the block models include standard cores including RAM, ROM, microprocessor and analog block models.

Preferably, the block models are optimised by utilisation of a microprocessor core model to determine optimised addressing capabilities.

In one embodiment, the hardware blocks are synthesised by initially translating the hardware block models to Register Transfer Level by imposing clock-cycle partitioning, and subsequently performing logical synthesis with a target library and design constraints.

Preferably, software blocks are synthesised by initially compiling the block models into machine code, optimising the machine code, and subsequently synthesising the machine code into optimised gate-level representations in the model code.

In one embodiment, the compiling step includes generation of effective code for the embedded MCU/CPU executive scheduler.

Preferably, the gate-level model is tested by the produced test vectors by input of the vector stimuli followed by monitoring of corresponding outputs at a time set according to the gate-level pipelining delay.

The invention also provides an integrated circuit whenever developed by the process as described above.

The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which: Figs. 1(a) and l(b) are together a flow diagram illustrating a development process of the invention.

Referring to the drawings, there is shown a process 1 for development of an integrated circuit design. In step 10 of the process an integrated specification model is produced using an SDL modelling tool. This provides a comprehensive representation of the full integrated circuit, in this case a "System on Silicon". This model defines functional level and process level details, together with message sequence charts as defined by the relevant standards. Sub-models of other components such as ICs for RF (radio frequencies), EPROMs, etc. are incorporated. An important aspect of the specification model 10 is that it is defined by a common model code that will be used throughout the process, in this embodiment the VerilogTM behaviour level code. VerilogTM is conventionally used for hardware definition, but in this process is also used for software definition because at a later stage in the process (step 17) the code is compiled to generate CPU/MCU dependent code. The compiler used for this step is optimised to produce effective code for the embedded executive scheduler. The software blocks include ROM files, the CPU, and RAM space.

In step 11 the specification model interfaces with an interface model 12 and with external component models 13 for testing, as indicated by step 11. The interface model is based on standard user interface tools such as Visual Basics or Windows > . An important aspect of the invention is the fact that the test step 11 involves interaction of the user with the specification model using the interface model, and there is also interaction with external component models in step 13. This interaction allows use of the user's skill and experience in a very effective manner with a model of the whole integrated circuit.

In step 14 models are produced for both hardware and software blocks, including standard blocks such as microprocessor cores. This falls within what is generally referred to as a system design stage. The block models are produced using tools which support the Veriloga language. The result at this stage is a set of block models including all hardware and software functional blocks and standard cores including RAM, ROM, the microprocessor, and analog blocks. An example of a block is an MCU/CPU interrupt handler, which handles interrupts from the hardware in order to transfer data to/from the hardware block or to indicate that a signal condition is present. More generally, a block is an architectural subdivision of the complete design. Each block has inputs, outputs and functionality.

In step 15 the block models are optimised to minimise embedded memory requirements, namely ROM and RAM requirements. Additional constraints including timing control and clocking strategies are added to the hardware blocks. Optimisation is achieved using a CPU/MCU code optimiser which performs loop unrolling, routine embedding and parameter (bit and byte) extraction to minimise the generated code required. The Verilogw code utilises the capabilities of the MCU/CPU core included in the block models to optimise addressing capabilities to the amount of actual ROM and ROM required. Addressing techniques particular to the MCU to handle bit fields are included in the optimisation process.

An important aspect of the process 1 is that at this early stage both the specification model and the block models are used to develop test vectors. The test vectors are created by building Verilog test benches around the block models. Because each block model has its own inputs, outputs and functionality, the vectors relate directly to the ports of the integrated circuit being development.

Generation of the test vectors at this stage involves performing limited testing to validate the specification and block models. The following is a sample representation of test vectors in which sequences of n bits relate to respective IC ports (n 2 1). The corresponding outputs will have a similar format.

0000100000000101101000000000000000000000 000010000000010110 1000000000000000000000 1000100000000101101000000000000000000000 1000100000000101101000000000000000000000 The test vectors can be generated in step 16 at this early stage because they relate to models at the behavioural level, the RTL level and the gate level. This is because at one level inputs at time X result in outputs at time X + Y. The time Y is the only variable between testing levels and can be determined experimentally before full testing. Again, the fact that the blocks are designed with inputs, outputs and functionality makes this possible. The block models do not have in-built timing constraints and thus the Y value can be determined experimentally and then evaluated for lower levels by determining pipelining delays.

In steps 17, 18, 19 and 20 gate-level representations are generated, which may be combined in step 21 to produce a combined system gate-level model. To perform this efficiently, the hardware and software block models are handled separately - this being the only part of the process at which they are handled separately. In step 17 software block models are compiled into machine code for the microcontroller, followed by further optimisation to ensure optimised use of the microprocessor resources. An important feature of the compiling is that CPU/MCU dependent code is generated, and the compiler is optimised to produce effective code for the embedded MCU/CPU executive scheduler.

There is then ROM synthesis in step 18 whereby the machine code is synthesised into optimised Verilogw gate level format.

The hardware block models are used in step 19 to produce Register Transfer Level (RTL) Verilogm models. These models arise from imposing clock-cycle (timing) partitioning on the high-level Verilogw code of the block models. The code is then synthesised with a target technology library and design constraints which describe the actual physical environment of the design such as input drives, output loads, maximum area, clock-cycle, etc.

In step 20 there is logical synthesis - much as described in the prior art - to produce the necessary gate-level representation.

In step 21 the hardware and software gate-level representations are combined to form the gate-level model 21, in Veriloga code. Because of the manner in which the block models have been developed, this step is performed in a very simple manner by combining the representations.

The following is an example of a gate or library element.

module FD1 ( Q, QN, D, CP ); input D, CP; output Q, QN; wire D~IN, CP~IN; supply0 NC~O; pmos tsbl(D IN,D,NC O); pmos tsb2(CP IN, CP, NC O); In this example, FD1 is a register, Q and QN are outputs, D is data and CP is a clock. 'Wire indicates connectivity, "pmos" a transistor type, and "tsb" instances.

Referring now to step 22, the gate-level model is tested using the test vectors which had previously been generated. An important aspect of the test vectors is that they comprehensively apply to the whole integrated system for comprehensive testing before masking and final production. The Verilogw code is used for the test vectors in order to generate the stimuli to test the model and analyse the outputs by comparison with expected results.

In generation of the test vectors, test cases for subblocks are derived by sampling the inputs of a sub-block during a top-level simulation and storing these values in a file to use as stimuli when testing the sub-block as a stand-alone entity.

The gate-level model is then used to generate a mask, the following being a sample:module ig~readc (READRESETY,READRESETC,HSTARTlY,HSTARTlC,YLINEE CLINEEND,VSYNC,HSYNC,IRSTL,SYSCLK); input HSTARTlY,HSTARTlC,YLINEEND,CLINEEND,VSYNC,HSYNC,IRSTL,SY output READRESETY,READRESETC; wire HSY2~Q72,~VSYNCl,nl99,HSY3,HSCl,~HSYNC2,HSYl,HSC3~Q115,H n145, ~HSYNCl,n311,n312,n313 ,n314 ,n315,n316 ,n317,n318 ,n319, n320,n321,n322,n323,n324,n325,n326,n327, The variables in parentheses are ports, and the variables following "input" and "output" describe connectivity.

Because the design is thoroughly tested in step 22, it may be released in step 23 without the need for lengthy and expensive testing procedures such as in-circuit emulation.

In effect this means that there is a sign-off of testing at the silicon foundry for both the hardware logic and also the software logic.

The invention is not limited to the embodiments described, but may be varied in construction and detail within the scope of the claims.

Claims (11)

1. A process for development of an integrated circuit design, the process comprising the steps of: producing an integrated system specification model in a model code, producing a user interface model, and performing user interactive testing of the specification model using the interface model; producing a block model in said model code of each hardware and software entity which has definable inputs, outputs and functions; optimising the block models and adding constraints; producing test vectors from said specification model and said block models by setting stimuli relating to integrated circuit ports and associated stimulus times and determining corresponding output times according to pipelining delays for lower level models in said model code; synthesising all block models to produce an optimised gate-level model in said model code; and testing the gate-level model using the test vectors.

2. A process as claimed in claim, wherein the specification model incorporates sub-models of components of the circuit.

3. A process as claimed in claims 1 or 2, wherein the specification model is tested during interact ion with external component models and said user interface model.

4. A process as claimed in any preceding claim, wherein the block models include standard cores including RAM, ROM, microprocessor and analog block models.

5. A process as claimed in claim 4, wherein the block models are optimised by utilisation of a microprocessor core model to determine optimised addressing capabilities.

6. A process as claimed in any preceding claim, wherein the hardware blocks are synthesised by initially translating the hardware block models to Register Transfer Level by imposing clock-cycle partitioning, and subsequently performing logical synthesis with a target library and design constraints.

7. A process as claimed in any preceding claim, wherein software blocks are synthesised by initially compiling the block models into machine code, optimising the machine code, and subsequently synthesising the machine code into optimised gate level representations in the model code.

8. A process as claimed in claim 7, wherein the compiling step includes generation of effective code for the embedded MCU/CPU executive scheduler.

9. A process as claimed in any preceding claim, wherein the gate-level model is tested by the produced test vectors by input of the vector stimuli followed by monitoring of corresponding outputs at a time set according to the gate-level pipelining delay.

10. A process substantially as hereinbefore described with reference to and as illustrated in the accompanying drawings.

11. An integrated circuit whenever developed by a process as claimed in any preceding claim.