GB2293886A - Design and testing of electronic systems - Google Patents

Design and testing of electronic systems Download PDF

Info

Publication number
GB2293886A
GB2293886A GB9420170A GB9420170A GB2293886A GB 2293886 A GB2293886 A GB 2293886A GB 9420170 A GB9420170 A GB 9420170A GB 9420170 A GB9420170 A GB 9420170A GB 2293886 A GB2293886 A GB 2293886A
Authority
GB
United Kingdom
Prior art keywords
code
testing
target system
workstations
analysis
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
GB9420170A
Other versions
GB9420170D0 (en
GB2293886B (en
Inventor
Maurice Vincent Whelan
Lionel Barker
Joseph Thomas Knox
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
S3 Research and Development Ltd
Original Assignee
S3 Research and Development Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to IE940794A priority Critical patent/IE73651B1/en
Application filed by S3 Research and Development Ltd filed Critical S3 Research and Development Ltd
Priority to GB9420170A priority patent/GB2293886B/en
Priority to BE9401041A priority patent/BE1007163A6/en
Publication of GB9420170D0 publication Critical patent/GB9420170D0/en
Publication of GB2293886A publication Critical patent/GB2293886A/en
Application granted granted Critical
Publication of GB2293886B publication Critical patent/GB2293886B/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26Functional testing
    • G06F11/261Functional testing by simulating additional hardware, e.g. fault simulation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/32Circuit design at the digital level
    • G06F30/33Design verification, e.g. functional simulation or model checking

Abstract

A method (1) is described for design and test of an electronic target system. The sub-steps of the method (1) provide for versatility in the type of target system. These steps include data flow analysis (3), timing analysis (4), state transition/control analysis (5), detailed process analysis (6) and size and performance estimation (7). Target system performance requirements are estimated as a function of data through put. Testing (9) is carried out in a distributed manner using simulation by directly-connected and network-connected simulators with automatic test coverage feedback. <IMAGE>

Description

"Design and Testing of Electronic Systems" The invention relates to the design and testing of electronic systems.
Many developments have been made in design and testing of particular types of electronic systems. For example, PCT Patent Specification No. WO 92/1420 (DEC) describes a simulation method which allows testing and debugging of computer programs concurrently. On the other hand, European Patent Specification No. EP-A2-0404482 (Hyduke) describes a system and method for simulating logic circuit designs using a data table and a model library.
The methods described in these specifications are undoubtedly beneficial for the specific tasks which they address. For example, the method of the EP-A2-0404482 specification appears to provide for efficient and comprehensive testing of logic circuit designs by use of dynamically generated tables. These systems follow the general trend which has been towards increased specialisation in design and test areas whereby methods are restricted to hardware (silicon) systems or alternatively to software systems. Furthermore, it is generally the case that the methods apply only to particular types of hardware or software, for example ASIC circuits. The apparent reason for this trend has been the increased complexity of the target electronic systems and resultant design and test specialisation.This has led to a large commercial dependence of individual businesses on particular sectors, which of course is risky. In addition, the service provided is often not satisfactory because a third party must apply considerable effort to integrate the system with other elements or sub-systems.
There is therefore a need for a method which provides for design and testing of electronic systems which are primarily hardware, primarily software, or a mixdepending on the customer requirements.
The invention is directed towards providing a versatile method which has the steps which are necessary for the design and testing of different types of electronic systems without sacrificing quality or efficiency.
According to the invention, there is provided a method for the design and testing of an electronic target system, the method being carried out by a production system having workstations connected in a distributed network arrangement, the method comprising the steps of:a central hub of the production system monitoring workstation interfacing signals and directing access of all workstations to required stored design and testing programs and data; workstations generating technical specifications defining the following aspects of the target system: functional aspects of the target system including the number of parallel data streams; signalling formats for interfacing; functional partitioning into the major operating components; and performance requirements in terms of data throughput, operating frequency, failure criteria and code parameters, workstations implementing the following operations based on the generated technical specifications: automatic data flow analysis; automatic timing analysis as a function of cumulative propagation delays and input timing requirements; state transition and control analysis; detailed process analysis; size and performance estimations based on the specification data, said estimations including physical semiconductor size and logical memory sizes; developing code in a distributed manner at different workstations of the production system, the code being automatically optimised according to data throughput as a function of response time or code execution cycle and size estimations; and testing the designed target system by simulating hardware performance and by simulating electronic systems which are to be connected to the target system in operation, the simulation being carried out by high-speed parallel simulators connected directly to workstations of the production system and by distributed workstations within the system providing simulation signals through production system network cables.
Preferably, testing comprises the steps of identifying the smallest operating components of the target system and carrying out automatic test history analysis of the components and subsequently carrying out component testing by random generation of test instructions.
In one embodiment, the test history analysis step comprises the step of identifying components having complex timing structures.
In another embodiment, testing comprises the further steps of interlinking the target system components followed by system-level testing in which simulation of the target system and systems within the operating environment is carried out.
In a still further embodiment, a workstation of the production system provides automatic test coverage feedback by continuously monitoring test coverage of all component and system-level tests via the network cables.
In the latter embodiment, test coverage is preferably quantified by automatic tracing of source code as the associated machine code is being executed.
In another embodiment, system level tests may be repeated or augmented according to the automatic test coverage feedback.
Preferably, tests are implemented by inclusion of test code within code of the target system, and wherein said test code is deleted on compiling the code.
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: Fig. 1 is a flow chart providing an outline of the overall steps of the method of the invention; Fig. 2 is a block diagram showing a design and test production system for implementing in the method; Fig. 3 is a timing chart showing the manner in which step 4 of Fig. 1 may be implemented; Fig. 4 is a state transition diagram showing how the step 5 of Fig. 1 may be implemented; Fig. 5 is a detailed process description showing how step 6 of Fig. 1 may be implemented; and Fig. 6 is a flow chart showing the testing step 9 of Fig 1. in more detail.
Referring to Fig 1, there is shown a method of the invention for the design and testing of an electronic target system. The method is indicated by the numeral 1.
The method 1 may be used for example for design and testing of full-custom, semi-custom, or mixed signal integrated circuits. Another example is the development of an application specific integrated circuit of (ASIC) for time switches and multiplex structures. Further, the method 1 of the invention may be used for the design and testing of software systems such as production control software for running on an open system hardware platform.
Alternatively, the method 1 may be used for the design and testing of integrated hardware and software systems.
Step 2 of the method 1 involves preparation of a technical specification for the target electronic system. These include: - A functional description of the target system.
This defines the number of parallel data streams and the number of time slots per data stream to be processed by the target system.
- An interface definition of the environment in which the target system is to be installed. These include electronic, signal, and link format definitions.
- Descriptions of the functional partitioning of the system in terms of the major operating components.
- A definition of the performance requirements of the target system. Data throughput, operating frequency, data latency, mean time before failure (MTBF), and code size and efficiency are typical performance parameters.
Referring to Fig 2, a design and test production system 10 for implementing the method 1 is illustrated. The system 10 comprises a central hub 11 which is connected by a network thick wire cable 12 to a repeater 13. The repeater 13 is connected to a network 14 of workstations of the SUN, DXa type. The repeater 13 is also connected to a network 15 of microcomputers. A bridge 16 connects the repeater 13 to a repeater 17 which is connected to a minicomputer cluster 18.
A thick wire cable 20 connects the central hub 11 to a switch 21 which in turn is connected by a thin wire cable 22 to a repeater 23. The repeater 23 is connected to three networks, namely a workstation network 24, a workstation network 25, and a microcomputer network 26. The workstations 24 are also of the SUN PXa type, while the workstations 25 are of the SUN Sparc-IDw type. A thick wire cable 30 connects the central hub 11 with a switch 31 which is in turn connected by a thin wire cable 32 to a repeater 33. The repeater 33 is also connected to three networks, namely a workstation network 34, a microcomputer network 35, and a workstation network 36. The workstations in the network 34 are of the SUN PXw type whereas the workstations in the network 36 are of the HP/APOLOw type.Additional test devices are connected in the system 10 and these are described in more detail below. The technical specifications which are generated in step 2 of the method 1 are generated on different workstations in the system 10, however, these workstations have similar interfaces and are linked by a common target system code. The fact that different workstations are used and there is distributed processing in general for the design and testing of the target system allows many different people work on a single project and there is a large degree of versatility. It also allows parallel processing where there is a very high processing requirement such as in some of the testing operations.
This is described in more detail below.
An important aspect of the production system 10 is that a common file structure with segregated categories of data including user data, product data, and automatic tool data is used. This allows easy and correct identification of different categories of product data, and within those categories clear identification of the components. This allows ready access of all workstations to relevant project information.
Another aspect of the system 10 is that the central hub 11 is programmed to continuously monitor the inter-linking of devices in the system 10 and to direct access of all devices to allowed data and programs. This feature allows re-configuration of the system 10 in a versatile manner according to production requirements.
Following generation of the technical specifications, various design tasks are then carried out and these are indicated by steps 3 to 7 in Fig 1. These steps are shown as being carried out in series, however, as is clear from the configuration of the system 10, they may be carried out in parallel at different workstations. Step 3 involves data flow analysis, followed by timing analysis in step 4. The result of this analysis is shown in Fig 3. It is carried out automatically by a data flow analysis program loaded on one of the workstations and provides information as to the relative timing of clock, read, write, address and various data signals. In more detail, the analysis is carried out as a function of cumulative propagation delays, input timing requirements of clocked elements, and operational disruptions caused by possible imperfections of the clocking system.Another important factor is the interfacing method to guarantee correct data transfers on multi-clock target systems.
Step 5 involves state transition/control analysis and a typical analysis output is shown in Fig 4. This diagram shows when the target integrated circuit is idle and when it is waiting for acknowledgements, when new connections are to be made and when alarm signals are to be transmitted.
Step 6 involves the generation of detailed process descriptions, also using automatic operation of a workstation as selected and configured by the central hub 11. The description which is generated defines inputs, the manner in which messages are constructed during processing, the manner in which connections are created and deleted and the manner in which address buses are selected. The diagram of Fig. 5 illustrates a particular process description in diagrammatic format.
Finally, in step 7 the size and performance of the target system is automatically estimated as a function of the prior analysis steps. This includes an analysis of the silicon area, the number of pins, the estimated power dissipation and the required heat sink. For a software target system the required hardware for running of the software and the read-only and random access memory requirements are specified.
In step 8 of the method 1, code is developed for the target electronic system. Where this is primarily hardware, the code which is developed is the microcode for the circuit, and where primarily software it is the full code of the target software system. The code is generated so as to optimise the data throughput in the target system. An important feature is the fact that this is determined in terms of code execution cycle, response time, and size in terms of code space on physical logic area. An important aspect of code generation is that different personnel work on generation of different aspects of the code using different workstations of the system 10. All of the workstations in the system 10 have a common coding standard defining the manner in which code may be written. This provides consistency and clarity of the coded function.This of course provides for easy interchanging of project personal as well as providing an employee backup.
There is also a common mechanism for defining interfaces within the system 10 and connecting the resulting code of many workstations. The coding standard limits the use of a given program language to those constructs which are easily understood and common between the various languages. This allows a migration of the code across different tools such as various different C compilers and the ability to easily transfer the functional code to different language compilers. A very important aspect of code generation is that the basic criteria for optimisation is identified as the data throughput as a function of either response time or code execution cycle and size in terms of code (RAM/ROM) or physical logic area of Silicon). The tools of the systems 10 are programmed to automatically analyse code for optimisation according to criteria.
Finally, testing is carried out in step 9 to provide the finished target system product. The sub-steps involved in testing are illustrated in Fig 6.
In step 71 of the method 9, each sub-component of the system which is being developed is identified. An important aspect is that each component is the smallest operational unit of the target system. For software this may be two to four lines of code carrying out a simple sub-routine. For hardware it may be a set of 500 logic gates. This identification is carried out by use of user interaction with system analysis tools and partly automatically by the manner in which data relating to parts of the target system is stored on the production system 10. In step 72 there is an automatic test history analysis for each component of the target system to help in developing a test plan. This step involves identification of the most vulnerable components of the system. For example, for a particular type of system it may be identified that a messaging system is the most vulnerable part and particularly exhaustive testing of these components is required. The analysis step 72 is based on stored data relating to previous projects. It has been found that step 72 generally results in identification of components having complex timing structures, multiple clock domains or very tight real time constraints.
In step 73, component testing is carried out. In both cases the test instructions are randomly generated for comprehensive component testing. For example, for a primarily software target system every line of a component is executed during a test. For a primarily hardware target system, the control section is identified and tested comprehensively.
In step 74 the various components are interconnected and a system-level test is carried out. Simulation is an important part of this step and in particular simulation of the environment for the target system. For such tests, the layout of the production system 10 is very important as various distributed workstations may carry out modelling operations to provide a comprehensive target system environment. To carry out such tests, dedicated hardware devices providing test instructions are connected directly to the workstation which is modelling the target system. Further, such hardware devices (commonly referred to as accelerators ) may be connected directly to a workstation to carry out direct simulation of the target system, the workstation providing simulation of interfaces with other simulators.The accelerator which is used in the production system 10 has a typical simulation performance in the region of 2 million to 5 million events per second. However, by connection of additional processing units for increased parallelism, up to 75 million events per second may be simulated. It has been found that the combination of directly-connected accelerator devices and the distributed workstation environment provides for the necessary functionality in target system and environment simulation for testing.
An important aspect of testing of code whether in a primarily software or primarily hardware target system is the fact that some of the target system code has built-in test codes to provide status outputs for different stages of the processing. In step 81, the code is compiled and the compiler automatically deletes the test codes to provide the final product code.
Steps 76 to 78 inclusive are implemented together to provide comprehensive system testing and they are followed by step 79 which involves an automatic test coverage analysis and feedback. One of the workstations of the production system 10 is configured to automatically monitor the various different workstations testing a particular target system and to monitor the level of test coverage. Test coverage is quantified by the percentage of code which is executed, as measured by automatic tracing of the source code as it is being executed. In other words the source code is continuously linked to the machine code as it is being executed. Because hardware is simulated, the same technique applies to integrated circuit design and testing. A feedback signal is provided in step 79 and this forms the basis of the decision step 80 whereby further system tests may be carried out or whereby testing may be regarded as complete. The test coverage feedback signals may take the form of graphs indicating the components of the system which have been less comprehensively tested.
It has been found that the method of the invention provides for the versatile design and testing of electronic systems and thus target systems which are primarily hardware, primarily software, or a combination may be designed and tested in an efficient manner. The manner in which the production system 10 is constructed greatly helps in providing this versatility.
The invention is not limited to the embodiments hereinbefore described but may be varied in construction and detail.

Claims (10)

AIMS
1. A method for the design and testing of an electronic target system, the method being carried out by a production system having workstations connected in a distributed network arrangement, the method comprising the steps of: a central hub of the production system monitoring workstation interfacing signals and directing access of all workstations to required stored design and testing programs and data; workstations generating technical specifications defining the following aspects of the target system: - functional aspects of the system target including the number of parallel data streams; signalling formats for interfacing; functional partitioning into the major operating components; and performance requirements in terms of data throughput, operating frequency, failure criteria and code parameters, workstations implementing the following operations based on the generated technical specifications:: automatic data flow analysis; automatic timing analysis as a function of cumulative propagation delays and input timing requirements; state transition and control analysis; detailed process analysis; size and performance estimations based on the specification data, said estimations including physical semiconductor size and logical memory sizes; developing code in a distributed manner at different workstations of the production system, the code being automatically optimised according to data throughput as a function of response time or code execution cycle and size estimations; and testing the designed target system by simulating hardware performance and by simulating electronic systems which are to be connected to the target system in operation, the simulation being carried out by high-speed parallel simulators connected directly to workstations of the production system and by distributed workstations within the system providing simulation signals through production system network cables.
2. A method is claimed in claim 1, wherein testing comprises the steps of identifying the smallest operating components of the target system and carrying out automatic test history analysis of the components and subsequently carrying out component testing by random generation of test instructions.
3. A method as claimed in claim 2, wherein the test history analysis step comprises the step of identifying components having complex timing structures.
4. A method as claimed in claim 3, wherein testing comprises the further steps of interlinking the target system components followed by system-level testing in which simulation of the target system and systems within the operating environment is carried out.
5. A method as claimed in claim 4 wherein a workstation of the production system provides automatic test coverage feedback by continuously monitoring test coverage of all component and system-level tests via the network cables.
6. A method as claimed in claim 5, wherein test coverage is preferably quantified by automatic tracing of source code as the associated machine code is being executed.
7. A method as claimed in claim 6, wherein system level tests may be repeated or augmented according to the automatic test coverage feedback.
8. A method as claimed in any preceding claim, wherein tests are implemented by inclusion of test code within code of the target system, and wherein said test code is deleted on compiling the code.
9. A method substantially as hereinbefore described, with reference to and as illustrated in the accompanying drawings.
10. A target system whenever produced by a method as claimed in any preceding claim.
GB9420170A 1994-09-30 1994-10-06 Design and testing of electronic systems Expired - Fee Related GB2293886B (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
IE940794A IE73651B1 (en) 1994-09-30 1994-09-30 Design and testing of electronic systems
GB9420170A GB2293886B (en) 1994-09-30 1994-10-06 Design and testing of electronic systems
BE9401041A BE1007163A6 (en) 1994-09-30 1994-11-18 Electronic design and control systems.

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
IE940794A IE73651B1 (en) 1994-09-30 1994-09-30 Design and testing of electronic systems
GB9420170A GB2293886B (en) 1994-09-30 1994-10-06 Design and testing of electronic systems
BE9401041A BE1007163A6 (en) 1994-09-30 1994-11-18 Electronic design and control systems.

Publications (3)

Publication Number Publication Date
GB9420170D0 GB9420170D0 (en) 1994-11-23
GB2293886A true GB2293886A (en) 1996-04-10
GB2293886B GB2293886B (en) 1999-04-07

Family

ID=30118637

Family Applications (1)

Application Number Title Priority Date Filing Date
GB9420170A Expired - Fee Related GB2293886B (en) 1994-09-30 1994-10-06 Design and testing of electronic systems

Country Status (3)

Country Link
BE (1) BE1007163A6 (en)
GB (1) GB2293886B (en)
IE (1) IE73651B1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000041050A1 (en) * 1998-12-31 2000-07-13 Abb Research Ltd Testing device for industrial control systems

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4916647A (en) * 1987-06-26 1990-04-10 Daisy Systems Corporation Hardwired pipeline processor for logic simulation
EP0442277A2 (en) * 1990-02-16 1991-08-21 International Business Machines Corporation A logic simulation using a hardware accelerator together with an automated error event isolation and trace facility
EP0450837A2 (en) * 1990-03-30 1991-10-09 International Business Machines Corporation Logic simulation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4916647A (en) * 1987-06-26 1990-04-10 Daisy Systems Corporation Hardwired pipeline processor for logic simulation
EP0442277A2 (en) * 1990-02-16 1991-08-21 International Business Machines Corporation A logic simulation using a hardware accelerator together with an automated error event isolation and trace facility
EP0450837A2 (en) * 1990-03-30 1991-10-09 International Business Machines Corporation Logic simulation

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000041050A1 (en) * 1998-12-31 2000-07-13 Abb Research Ltd Testing device for industrial control systems

Also Published As

Publication number Publication date
BE1007163A6 (en) 1995-04-11
IE940794A1 (en) 1996-04-03
GB9420170D0 (en) 1994-11-23
IE73651B1 (en) 1997-06-18
GB2293886B (en) 1999-04-07

Similar Documents

Publication Publication Date Title
US6708329B1 (en) Method and apparatus for producing modules compatible with a target system platform from simulation system modules utilized to model target system behavior
US8666721B2 (en) Resource remapping in a hardware emulation environment
KR100483636B1 (en) Method and apparatus for design verification using emulation and simulation
NL192892C (en) Computer-aided system for integrated circuit design.
US20020138244A1 (en) Simulator independent object code HDL simulation using PLI
JP2002526908A (en) Block-based design method
US20090240457A1 (en) Testing in a hardware emulation environment
US7043596B2 (en) Method and apparatus for simulation processor
Bombieri et al. On the evaluation of transactor-based verification for reusing TLM assertions and testbenches at RTL
JP2004139599A (en) Method for automatically decomposing dynamic system model into submodel
CN114139475A (en) Chip verification method, system, device and storage medium
KR20040028598A (en) Vcd-on-demand system and method
GB2293886A (en) Design and testing of electronic systems
IES62316B2 (en) Design and testing of electronic systems
Doshi et al. THEMIS logic simulator-a mix mode, multi-level, hierarchical, interactive digital circuit simulator
Pino et al. Interface synthesis in heterogeneous system-Level DSP design tools
Chu et al. Three decades of HDLs. I. CDL through TI-HDL
US7424418B1 (en) Method for simulation with optimized kernels and debugging with unoptimized kernels
Robinson et al. Verification of dynamically reconfigurable logic
Bidjan-Irani A rule-based design-for-testability rule checker
Saitoh et al. Logic Simulation System Using Simulation Processor (SP).
US20030233504A1 (en) Method for detecting bus contention from RTL description
Duncan et al. Parallel processing in high integrity aircraft engine control
Hefferan et al. The STE-264 accelerated electronic CAD system
Hong et al. Don't care-based BDD minimization for embedded software

Legal Events

Date Code Title Description
PCNP Patent ceased through non-payment of renewal fee

Effective date: 20131006