GB2293886A - Design and testing of electronic systems - Google Patents
Design and testing of electronic systems Download PDFInfo
- 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
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/26—Functional testing
- G06F11/261—Functional testing by simulating additional hardware, e.g. fault simulation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design 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)
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.
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)
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)
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 |
-
1994
- 1994-09-30 IE IE940794A patent/IE73651B1/en not_active IP Right Cessation
- 1994-10-06 GB GB9420170A patent/GB2293886B/en not_active Expired - Fee Related
- 1994-11-18 BE BE9401041A patent/BE1007163A6/en not_active IP Right Cessation
Patent Citations (3)
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)
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 |