GB2430777A - Diagnostic method and system for diagnosing faults on an integrated circuit using a system definition file - Google Patents
Diagnostic method and system for diagnosing faults on an integrated circuit using a system definition file Download PDFInfo
- Publication number
- GB2430777A GB2430777A GB0613204A GB0613204A GB2430777A GB 2430777 A GB2430777 A GB 2430777A GB 0613204 A GB0613204 A GB 0613204A GB 0613204 A GB0613204 A GB 0613204A GB 2430777 A GB2430777 A GB 2430777A
- Authority
- GB
- United Kingdom
- Prior art keywords
- diagnostic
- spirit
- signals
- description
- operable
- 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.)
- Withdrawn
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/263—Generation of test inputs, e.g. test vectors, patterns or sequences ; with adaptation of the tested hardware for testability with external testers
-
- 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/273—Tester hardware, i.e. output processing circuits
- G06F11/2733—Test interface between tester and unit under test
Abstract
A diagnostic method for diagnosing faults on a system comprising one or more integrated circuit or in software running on a component of one of said one or more integrated circuits comprises the steps of reading a SPIRIT description describing said system in a SPIRIT format; generating control signals in response to diagnostic signals and information relating to said system derived from said SPIRIT description, said control signals being operable to control said system to perform diagnostic operations specified by said diagnostic signals; and outputting said control signals. The method may further comprise the steps of interpreting the diagnostic signals using information from the SPIRIT description in order to display information to the user. The user may then modify the diagnostic signals in accordance with the displayed information. In a further embodiment, the method may be implemented by a diagnostic interface having an input port for receiving diagnostic signals and logic to read the SPIRIT description file in order to generate the output signals through an output port to the system.
Description
DIAGNOSTIC MECHANISMS FOR DATA PROCESSING SYSTEMS
This invention relates to the field of data processing systems. More particularly, this invention relates to the field of diagnostic mechanisms within data processing systems.
It is known to provide data processing systems with diagnostic mechanisms which can be used to perform diagnostic operations (e.g. software and hardware fault identification and analysis (debug)) upon the data processing systems so as to assist in the development of hardware, operating systems, application programs, overall system designs and the like.
When analysing a data processing system, such as an integrated circuit or a plurality of interconnected integrated circuits, a debug program may be run on a host system that is connected to the system to be analysed such that control signals specifying diagnostic operations to be performed on the system are passed from the host to the system. Such a debug program is a general purpose program that can be used to analyse a variety of different systems. In order to be able to do this information regarding the system to be analysed needs to be input to the debug program.
At present this is generally done in the form of a proprietary file format such as a BCD (boad/chip definition) file which provides a description of the system to be analysed and is supplied with the system. A disadvantage of this is that as the files are proprietary they need to be generated for each system that is to be analysed and for each diagnostic program.
A standard way of describing electronic systems to EDA/ESL tools is being developed under the SPIRIT standard. This is a standard under development by the SPIRIT consortium (www.spintconsortium.org) to allow system design tools (particularly EDA electronic design automation) to share IP descriptions. A SPIRIT description of a component describes some or all of the interfaces to the component and may reference files descriptions of the implementations of the component. A SPIRIT description of a design describes how the components of the design are connected together, i.e. the topology of the system.
* Viewed from one aspect the present invention provides a diagnostic method for diagnosing faults on a system comprising one or more integrated circuit or in software running on a component of one of said one or more integrated circuits comprising the steps of: reading a SPIRIT description describing said system in a SPIRIT format; generating control signals in response to diagnostic signals and information relating to said system derived from said SPIRIT description, said control signals being operable to control said system to perform diagnostic operations specified by said diagnostic signals; and outputting said modified signals.
The present invention recognises the problem of diagnostic mechanisms such as debug programs requiring proprietary files for describing the system under diagnosis. It addresses this problem by producing diagnostic mechanisms that can read and interpret a SPIRIT description of any system. Using a SPIRIT description which has a standard format, rather than a proprietary format, for describing the system means that these descriptions need only be written, or generated, once, rather than requiring a system designer, user, or diagnostic provider to generate descriptions for each diagnostic system. Furthermore, using SPIRIT as this standard format means that these descriptions can be generated by standard system design tools, as part of a standard system design process, rather than being manually generated or requiring use of proprietary tools. This reduces the work required by system designers, diagnostic providers and diagnostic users to configure a diagnostic mechanism to support new hardware. Thus, faults can be diagnosed on one or more integrated circuits, or in software running on a component of the integrated circuits, or in the interactions between pieces of software running on multiple components within the same or different integrated circuits.
In some embodiments, the method comprises the further step of prior to generating said control signals: generating said diagnostic signals themselves, while in other embodiments the diagnostic signals are not generated by the method but are generated elsewhere and are simply received and then modified to produce the control signals.
In some embodiments, the method comprises the further steps of: receiving signals or messages generated by said system in response to said diagnostic operations; interpreting said received signals or messages using information read from said SPIRIT description; and displaying said interpreted signals.
The SPIRiT description of the system can additionally be used to interpret the signals received back from the system being diagnosed and thus, the results of the diagnostic operation can be displayed to the user in a more comprehensible and user- friendly fashion.
In some embodiments, at least one of said received signals comprises data stored within at least one register, and said interpreting step comprises providing information indicating a location of said at least one register.
Interpretation of the received signals can take a variety of forms, in some of them the location of a register containing data is indicated to the user thus providing clearer and more useful information to the user.
In some embodiments, said step of generating said control signals further comprises: displaying information to a user regarding said at least some diagnostic signals interpreted with information derived from said SPIRIT description; and receiving information from said user and modifying said at least some diagnostic signals in response to said received information.
Diagnostic methods are generally interactive, such that a user specifies diagnostic information such as the position of breakpoints, values to be input to certain registers and so forth. Embodiments of the invention provide information as to the location and interconnection of the components of the system, thus making it easier for the user to make decisions on how be would like a particular diagnosis to be performed.
In some embodiments, said SPIRIT description comprises information regarding an internal diagnostic system within said system, and said step of generating said control signals further comprises: modifying said diagnostic signals in response to information regarding said internal diagnostic system derived from said SPIRIT
description.
It is becoming more usual to use complex internal diagnostic systems within integrated circuits or systems of integrated circuits. With known proprietary debug formats only particular types of internal diagnostic systems are supported. To be able to diagnose a system the diagnostic mechanism needs to have knowledge of the internal diagnostic system. Generally this has been provided within the diagnostic logic itself or in a proprietary file. A particularly advantageous aspect of one embodiment of the invention is to use a SPIRIT description not only to describe the system being diagnosed but also its own diagnostic subsystem. This enables a general diagnostic mechanism to support different internal diagnostic subsystems.
Furthennore, using a standard format, rather than a proprietary format, for describing such a diagnostic subsystems means that these descriptions need only be written, or generated, once, rather than requiring a system designer, user, or diagnostic provider to generate descriptions for each diagnostic system. Using SPIRIT as this standard format means that these descriptions can be generated by standard system design tools, as part of a standard system design process, rather than being manually generated or requiring use of proprietary tools. This reduces the work required by system designers, diagnostic providers and diagnostic users to configure a diagnostic mechanism to support new hardware.
In some embodiments, the method comprises the further steps of analysing an internal diagnostic system within said system and generating a SPIRIT description of said internal diagnostic system; and said step of generating said control signals further comprises modifying said diagnostic signals in response to information regarding said internal diagnostic system derived from said SPIRIT description.
In some circumstances the internal diagnostic system may not be part of the SPIRIT description. in some embodiments, the method is able to generate its own SPIRIT description of the internal diagnostic system and thus is able to diagnose such a system, even without a SPIRIT description being provided.
The SPIRIT description may take a number of forms, in some embodiments it comprises a file describing said system in SPIRIT format, while in others it comprises a plurality of files. In some cases it comprises one file for each integrated circuit of the system in other cases there may be separate files for different components of a single integrated circuit and files for how the components are put together i.e. the topology of the integrated circuit.
A second aspect of the present invention provides a computer program product holding a computer readable medium including computer readable instructions that when executed perform the steps of a method according to a first aspect of the present invention.
A third aspect of the present invention provides a diagnostic interface comprising: an input port operable to receive diagnostic signals operable to specify diagnostic operations to be performed; diagnostic logic operable to read a SPIRIT description describing a system to be diagnosed and to modify said diagnostic signals in response to information regarding said system derived from said SPIRIT description to generate control signals operable to control said system to perform said diagnostic operations; and an output port operable to output said control signals to said system.
A fourth aspect of the present invention provides a data processing apparatus comprising an interface according to a third aspect of the present invention, said data processing apparatus further comprising: logic; an external port connected to said diagnostic interface; wherein said logic is operable to generate said diagnostic signals and to output said diagnostic signals via said external port to said diagnostic interface.
It should be noted that although the interface is described above and in some of the claims as being separate to the data processing apparatus, it could be provided within the data processing apparatus. In such a case the diagnostic logic of the interface could form a single logic block with the logic of the data processing apparatus, this logic block having the functional capabilities of the two separate logic blocks described above and in the claims.
Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 schematically illustrates a data processing apparatus and a target system to be diagnosed according to an embodiment of the present invention; Figures 2a and 2b schematically show a data processing apparatus, interface and target system to be diagnosed according to an embodiment of the present invention; Figure 3 shows the system of Figure 2b in more detail; Figure 4, shows a target system and its diagnostic subsystem; and Figure 5 show the steps of a diagnostic method according to an embodiment of the present invention.
Figure 1 shows a computer system 10 which is hosting a diagnostic program such as a debug program operable to diagnose faults on a target system 20 or in software running on a component of the target system 20. When the diagnostic program runs on the host computer 10, diagnostic control signals specifying diagnostic operations to be performed on a target system 20 which is being diagnosed are produced in response to the program and are output to the target system 20 via external port 16. The host computer 10 comprises a display 12, a keyboard 13, diagnostic logic 14 and a data store 15. Data store 15 stores one ormore SPIRIT flu elating to the target system in this case an integrated circuit 20 to be tested.
In operation, host computer 10 reads the SPIRIT file description 15 of the integrated circuit 20 and modifies the diagnostic signals produced by the diagnostic logic, which in many cases may be a debug program. Control signals that are customised to the target system, integrated circuit 20 are then output. The host computer 10 is an interactive computer and the modification of the diagnostic signals is often performed in conjunction with a user, for example, the location of a breakpoint can be selected by a user. The display is used both for displaying results to a user and also to allow interaction between a user and the system. Most diagnostic mechanisms are interactive, with the user specifying where to set breakpoints and specifying particular values to be held in particular registers at particular times.
With regard to the SPIRIT file(s) stored in data store 15, this data can be obtained in a number of ways. It can, for example, be supplied with the target system, or it can be downloaded from a site accessible on the Internet.
Figure 2a schematically shows an alternative embodiment in which there is an interface between the host computer and the system being diagnosed 20. Instead of the host connecting directly to a target system the connection can be done via an interface.
The interface can be an intelligent interface operable to perform some data processing operations itself; or it can simply act as a buffer between the two systems, storing input and output data as necessary.
The interface 30 of Figure 2a is an intelligent interface and it comprises diagnostic logic 32. In this embodiment, it is the diagnostic logic 32 which is operable to read the SPIRIT description of integrated circuit 20 and to modify any diagnostic signals received from host computer 10 into a form suitable for diagnosing the integrated circuit 20. Although in this embodiment target system 20 is shown as a single integrated circuit, multiple chips ale generally diagnosed together, with the diagnostic mechanism being configured to diagnose multiple chips. In such a case the SPIRIT description will be of the whole system and may comprise a plurality of files. Receipt of the SPIRIT description allows the system to know information regarding the chips, for example, that they contain ARM 9 processors, the diagnostic mechanism then knows how to set breakpoints etc. Figure 2b represents a similar system to that of Figure 2a. In this the user's system work station 10 comprises RVD (Realview debugger) 14 for generating diagnostic signals and an interface RVI (Realview ICE) for modifying the signals to make them appropriate to the target hardware 20, i.e. it translates logical requestes into operations on the JTAG. The signals are input to the target hardware 20 via its JTAG polt Figure 3 shows asimilarsystemto thatofFigure 2b inrnoredetail. In this system, RVI) 14 outputs a diagnostic signal or message to the interface RYI 30. In the example shown the diagnostic signal indicates that a breakpoint should be set for address 0x2000. The interface RVI 30 reads a SPIRiT description of the system being diagnosed and modifies the diagnostic signal or message to generate a control signal appropriate to the target system 20 being diagnosed. In this case, it modifies the signal to set register 21 to 0x2000. Register 21 is one of the debug registers. This information is input by the debug bus 55 to the debug hardware in this case the embedded ICE on processor 22.
Embodiments of the invention are particularly applicable to more complex processor systems which may have their own non-standard and quite complicated diagnostic hardware. For example they may have JTAG hardware, Embedded ICE Macrocells, Embedded Trace Macrocells and an Embedded Trace Buffer. They may also have many other diagnostic components including, for example, Debug Access Port(s), cross triggering components and debug busses. To perform diagnostic operations on such a system, the diagnostic mechanism needs to understand the diagnostic hardware (in some embodiments the debug subsystem) of the target system in order to be able to control the diagnosis. This information is provided by a SPIRIT description of the diagnostic hardware that the diagnostic logic of the host 10, or interface 30 can read and interpret.
Figure 4 shows in schematic form an example of a system having its own fairly complex diagnostic hardware or debug subsystem. In this system there are diagnostic access ports (DAPs), one for trace and one for debug and there is a Debug control bus which has addresses identifying connections to the bus. The debug control bus is linked to different processors and trace units. Thus, when sending control signals derived from the diagnostic signals of the diagnostic program, infonnation regarding the diagnostic hardware needs to be known and used to enable the control signals to be sent to control the appropriate processor.
In the system shown, the portion outlined by dotted line 55 is the portion that is used by the interface 30 (RVI) of figures 2 and 3 to modify the diagnostic control signals to be able to access the appropriate portion of this system. Thus, the RVI needs to know the relevant parts of the register address map and the component Ids, but it may not need to know details of the components. Thus, it may be that the RVI need only read the SPIRIT design files setting out the topology of the system and not the component files.
The portion outlined by dotted line 65 is the portion that is used by the diagnostic logic (RVD) in host computer 10 of Figures 2 and 3 to interpret results of the diagnostic mechanism.
In the system of Figure 1, there is no intelligent interface 30 thus, the diagnostic logic 14 generates the diagnostic signals, modifies them to produce appropriate control signals and interprets the results.
In the system illustrated in Figure 4, the diagnostic hardware is supplied to the diagnostic logic in the form of a SPIRIT description of the system. In some cases such a description may not be available. In some embodiments this may not matter as either the interface 30 or the host computer 10 may comprise autodetection logic, either as part of the diagnostic logic or separate to it. This autodetection logic is operable to analyse the target system and produce its own SPIRIT description of the diagnostic hardware or internal diagnostic system of the target.
Figure 5 shows a flow diagram illustrating a method of diagnosing a target system according to an embodiment of the present invention. Initially a SPIRIT description of the Target system to be analysed is read. This is checked to see if there is a SPIRIT description of the diagnostic subsystem. If there isn't then an autodetection of the subsystem is performed and a SPIRIT file of this subsystem is generated. Diagnostic signals specifying diagnostic operations to be performed on the * target system are then received (if the method is being perfonned on the interface) or are generated (in the case of the host). These signals are then interpreted using the * SPIRIT description and some of the interpreted signals may be displayed to a user, where a user input is required.
The user input is then received and the diagnostic signals are modified to generate control signals using the SPIRIT description and possibly the user input. The control signals are then sent to the target system, where they control the diagnostic operations specified in the original diagnostic signals.
Data resulting from these operations are then received from the target system and this data is then interpreted using the SPIRIT description of the target system and the interpreted data is displayed to the user.
Claims (23)
1. A diagnostic method for diagnosing faults on a system comprising one or more integrated circuit or in software running on a component of one of said one or more integrated circuits comprising the steps of: reading a SPIRIT description describing said system in a SPIRIT format; generating control signals in response to diagnostic signals and information relating to said system derived from said SPIRIT description, said control signals being operable to control said system to perform diagnostic operations specified by said diagnostic signals; and outputting said control signals.
2. A diagnostic method according to claim 1, comprising the further step of prior to generating said control signals: generating said diagnostic signals.
3. A diagnostic method according to claim 2, comprising the further steps of: receiving signals generated by said system in response to said diagnostic operations; interpreting said received signals using information read from said SPIRIT
description; and
displaying said interpreted signals.
4. A diagnostic method according to claim 3, wherein at least one of said received signal comprises data stored within at least one register, and said interpreting step comprises providing information indicating a location of said at least one register.
5. A diagnostic method according to any one of claims 2 to 4, wherein said step of generating said control signals further comprises: displaying information to a user regarding at least some of said diagnostic signals interpreted with information derived from said SPIRIT description; and receiving infonnation from said user and modifying said at least some diagnostic signals in response to said received information.
6. A diagnostic method according to any preceding claim, wherein said SPIRIT description comprises information regarding an internal diagnostic system within said system, and said step of generating said control signals further comprises: modifying said diagnostic signals in response to infonnation regarding said internal diagnostic system derived from said SPIRIT description.
7. A diagnostic method according to any one of claims 1 to 5, comprising the further steps of: analysing an internal diagnostic system within said system and generating a SPIRIT description of said internal diagnostic system; and said step of generating said control signals further comprises: modifying said diagnostic signals in response to information regarding said internal diagnostic system derived from said SPIRiT description.
8. A diagnostic method according to any preceding claim, wherein said SPIRIT description comprises a file describing said system in SPIRIT format.
9. A diagnostic method according to claim 8, wherein said SPIRIT description comprises a plurality of files, comprising at least one file for each of said integrated circuits of said system.
10. A computer program product holding a computer readable medium including computer readable instructions that when executed perform the steps of a method according to any one of claims 1 to 9.
11. A diagnostic interface comprising: an input port operable to receive diagnostic signals operable to specify diagnostic operations to be performed; diagnostic logic operable to read a SPIRIT description describing a system to be diagnosed and to modify said diagnostic signals in response to information regarding said system derived from said SPIRIT description to generate control signals operable to control said system to perform said diagnostic operations; and an output port operable to output said control signals to said system.
12. An interface according to claim 11, wherein said interface further comprises a data store, said data store being operable to store said SPIRIT description.
13. A data processing apparatus comprising an interface according to claim 11, said data processing apparatus further comprising: logic; an external port connected to said diagnostic interface; wherein said logic is operable to generate said diagnostic signals and to output said diagnostic signals via said external port to said diagnostic interface.
14. A data processing apparatus according to claim 13, said data processing apparatus further comprising a display and a data store operable to store said SPIRIT description, said data processing apparatus being operable: to receive signals at said external port generated by said system in response to said diagnostic operations; to interpret said received signals using information from said SPIRIT
description; and
to display said interpreted signals on said display.
15. A data processing apparatus according to claim 13 or 14, said data apparatus further comprising a user input device, and wherein said logic is operable: to display on said display information regarding at least some of said diagnostic signals interpreted with information derived from said SPIRIF description; to receive information from said user input device; and to modify said at least some diagnostic signals in response to said received information.
16. A data processing apparatus according to any one of claims 13 to 15, wherein said SPIRIT description comprises information regarding an internal diagnostic system within said system, and said diagnostic logic is operable to modify said diagnostic signals in response to information regarding said internal diagnostic system derived
from said SPIRiT description.
17. A data processing apparatus according to any one of claims 13 to 15, wherein said diagnostic logic is operable to analyse an internal diagnostic system within said system and to generate a SPIRIT description of said internal diagnostic system; and is further operable to modify said diagnostic signals in response to infonnation regarding said internal diagnostic system derived from said SPIRIT description.
18. A data processing apparatus according to any one of claims 13 to 17, wherein said SPIRIT description comprises a file describing said system in SPIRIT format.
19. A data processing apparatus according to claim 18, wherein said SPIRIT description comprises a plurality of files, comprising at least one file for each of said integrated circuits of said system.
20. A diagnostic method substantially as hereinbefore described with reference to the drawings.
21. A computer program product substantially as hereinbefore described with reference to the drawings.
22. An interface substantially as hereinbefore described with reference to the drawings.
23. A data processing apparatus substantially as hereinbefore described with reference to the drawings.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GBGB0519973.2A GB0519973D0 (en) | 2005-09-30 | 2005-09-30 | Diagnostic mechanisms for data processing systems |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| GB0613204D0 GB0613204D0 (en) | 2006-08-09 |
| GB2430777A true GB2430777A (en) | 2007-04-04 |
Family
ID=35395081
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GBGB0519973.2A Ceased GB0519973D0 (en) | 2005-09-30 | 2005-09-30 | Diagnostic mechanisms for data processing systems |
| GB0613204A Withdrawn GB2430777A (en) | 2005-09-30 | 2006-07-03 | Diagnostic method and system for diagnosing faults on an integrated circuit using a system definition file |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GBGB0519973.2A Ceased GB0519973D0 (en) | 2005-09-30 | 2005-09-30 | Diagnostic mechanisms for data processing systems |
Country Status (1)
| Country | Link |
|---|---|
| GB (2) | GB0519973D0 (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5602990A (en) * | 1993-07-23 | 1997-02-11 | Pyramid Technology Corporation | Computer system diagnostic testing using hardware abstraction |
| JPH09146792A (en) * | 1995-11-28 | 1997-06-06 | Fujitsu Ltd | Fault diagnostic system |
| US5768499A (en) * | 1996-04-03 | 1998-06-16 | Advanced Micro Devices, Inc. | Method and apparatus for dynamically displaying and causing the execution of software diagnostic/test programs for the silicon validation of microprocessors |
| US6393591B1 (en) * | 1999-02-12 | 2002-05-21 | Xilinx, Inc. | Method for remotely testing microelectronic device over the internet |
| US20040070599A1 (en) * | 2002-09-26 | 2004-04-15 | Yokogawa Electric Corporation | Data display unit for field devices |
-
2005
- 2005-09-30 GB GBGB0519973.2A patent/GB0519973D0/en not_active Ceased
-
2006
- 2006-07-03 GB GB0613204A patent/GB2430777A/en not_active Withdrawn
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5602990A (en) * | 1993-07-23 | 1997-02-11 | Pyramid Technology Corporation | Computer system diagnostic testing using hardware abstraction |
| JPH09146792A (en) * | 1995-11-28 | 1997-06-06 | Fujitsu Ltd | Fault diagnostic system |
| US5768499A (en) * | 1996-04-03 | 1998-06-16 | Advanced Micro Devices, Inc. | Method and apparatus for dynamically displaying and causing the execution of software diagnostic/test programs for the silicon validation of microprocessors |
| US6393591B1 (en) * | 1999-02-12 | 2002-05-21 | Xilinx, Inc. | Method for remotely testing microelectronic device over the internet |
| US20040070599A1 (en) * | 2002-09-26 | 2004-04-15 | Yokogawa Electric Corporation | Data display unit for field devices |
Also Published As
| Publication number | Publication date |
|---|---|
| GB0519973D0 (en) | 2005-11-09 |
| GB0613204D0 (en) | 2006-08-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6430741B1 (en) | System and method for data coverage analysis of a computer program | |
| US8607174B2 (en) | Verification module apparatus to serve as a prototype for functionally debugging an electronic design that exceeds the capacity of a single FPGA | |
| US9703740B2 (en) | Opaque bridge for peripheral component interconnect express bus systems | |
| JP5022262B2 (en) | Test system and method capable of using tools during debugging | |
| KR20020011870A (en) | Method and apparatus for tracing hardware states using dynamically reconfigurable test circuits | |
| US20140372657A1 (en) | Hidden Base Address Register Programming in Peripheral Component Interconnect Express Buses | |
| US20050160405A1 (en) | System and method for generating code coverage information | |
| KR20120018307A (en) | Address translation trace message generation for debug | |
| US20140372660A1 (en) | Packet Routing Based on Packet Type in Peripheral Component Interconnect Express Bus Systems | |
| US6442725B1 (en) | System and method for intelligent analysis probe | |
| US7441158B1 (en) | Embedded hardware debugging tool and associated method | |
| US6775793B2 (en) | Data exchange system and method for processors | |
| EP3532936A1 (en) | Debugging system and method | |
| CN112685212A (en) | Debugging and tracking method, device and system for processor exception | |
| US10816600B1 (en) | Protocol analysis and visualization during simulation | |
| GB2430777A (en) | Diagnostic method and system for diagnosing faults on an integrated circuit using a system definition file | |
| JP2003162426A (en) | Computer system with cooperative debug circuit for multiple cpu and debug method | |
| US20120131536A1 (en) | Verification apparatus for semiconductor integrated circuit and verification method for semiconductor integrated circuit | |
| US7313731B2 (en) | Systems and methods for identifying erroneous transactions | |
| CN116521468B (en) | FPGA online debugging method and FPGA supporting online debugging | |
| US8862770B1 (en) | Processor architecture verification | |
| JP2002014847A (en) | Device for checking program and method for the same and recording medium with checking program stored | |
| CN113535490B (en) | Error detecting device and operation method thereof | |
| WO2017149737A1 (en) | High-level synthesis device, high-level synthesis method, and high-level synthesis program | |
| JP3085730B2 (en) | Parallel simulation method for complex CPU system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WAP | Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1) |