JPH03225436A - Simulator of recording device and its debugger - Google Patents

Abstract

PURPOSE:To confirm the states of signals at respective terminals of an MPU without forming an actual electric circuit board by simulating the circuit operation of LSIs at the periphery of the MPU. CONSTITUTION:A simulation part 400 consists of a simulation control part 410, a window control part 430, an engine part 440, and the debugger 450 and actuates a simulation engine according to hardware information on the target system defined by a configuration part 300 to supply test data, thereby debugging a target program. For control over the simulation, the simulator is provided with a function which generates and closes a window and performs branching to event processing execution in respective windows when an event is generated in an open window and various debugging functions which perform simulation, make a break, and trace the simulation during the simulation by actuating the engine. Consequently, the hardware environment is easily simulated.

Description

[Detailed Description of the Invention] [Field of Industrial Application] The present invention relates to a simulation device that supports the development of recording devices such as copying machines, printers, and facsimile machines, and particularly relates to a simulation device that supports the development of recording devices such as copying machines, printers, and facsimile machines. The present invention relates to a software simulator (hereinafter referred to as simulator) suitable for executing simulations of external signals such as LSIs and sensors, and communication data with other MPUs.

[Conventional technology]

In recent years, due to the diversification of social needs, there have been major changes in the product development of recording devices, such as increasing the number of functions in a single model, and increasing the number of models with only specific functions. Technological innovation in response to these changes is extremely dependent on the introduction of MPLI and its software.As the number of software models increases year by year, the development of this software has come to occupy a large portion of the total man-hours in product development. It's becoming.

Therefore, increasing the efficiency of software development has become a top priority in product development, but in software development using conventional methods, the debugging process requires an actual electrical circuit board or recording device. Even if the software design is completed early, there is a problem in that it is not possible to proceed to the next debugging process until the prototype of the electric circuit board or actual device is completed. In other words, the fact that this software debugging is dependent on the hardware of the recording device, such as the electric circuit board and the actual device, results in the software not only being dependent on the hardware development schedule, but also inevitably falling behind. It appeared to be a vicious cycle. Therefore, in order to increase the efficiency of software development, the current situation is that it is not only a problem of software, but also that it is necessary to increase the efficiency of hardware development.

Furthermore, when a problem occurs during debugging on an electric circuit board or actual device, even if it is a problem on the hardware side, the problem is often solved using software due to development cost/delivery time constraints, so software technology is required. This has led to an increase in the burden on people.

The development of the recording device will be explained below.

FIG. 50 shows the basic configuration of the recording device. In FIG.
120 and an electric circuit board 130 that interfaces between the two, the device body/O0 is equipped with sensors for detecting the operating state and switches for inputting instructions from the control panel. It is being Inputs from these sensors, switches, etc.
- The signal is first supplied to the electric circuit board 130, where predetermined signal processing is performed, and then supplied to the MPU 120 as input data.

Also, some of the inputs are sent to the MPU 12 as interrupt signals.
0. The output data of the MPU 120 is supplied to the electric circuit board 130, and the electric circuit board 130 outputs signals for controlling driving parts such as motors and solenoids.

Additionally, a peripheral LSI (Large Scale Integrated Circuit) is connected to the MPU 120 for interfacing with the MPU and the MPU's external 0 circuit, and is used to precisely operate the v1 elliptic system such as the motor and treid of the device. It produces the signals necessary for

Furthermore, when the recording device system is large, the system is divided into a plurality of modules and an MPU is used for each module. At this time, since the operation of each module needs to be timed with the operation of other modules, it is necessary to inform the other modules of the operating status of each module. For this reason, each module is connected by a communication channel, and data is exchanged using, for example, serial communication data.

The above record bag! As shown in Fig. 51, the development of the system can be roughly divided into the mechanical design of the device itself, the electrical circuit design of the MPU and peripheral LSI hardware, and the equipment! Software development is carried out by three departments, which are the programs that control the operation of the computer. Specifically, the development theme, scale, etc. are first considered and planned during product planning, and each department then begins designing specifications based on these. In the software development department, the first step of creating a program is
The second step is to verify this program using an electric circuit board, and the third step is to install the program on a prototype machine and verify it.
There is a process.

In the first step, software specifications are designed based on electrical circuit and mechanical design specifications, and a program is created in accordance with these specifications. Here, an editor is used as a development tool when creating a source program from a specification. Thereafter, the source program is used to create an object program using a language conversion device such as an assembler, compiler, or linker.

The second step is to run the developed program using an electric circuit board and verify from both software and hardware perspectives whether the signals necessary to control the mechanical parts of the device are output according to specifications. This is a so-called emulation test.

The third step is a so-called actual machine test in which the developed program is run on the completed prototype machine and the operation of the machine is confirmed.

Normally, the work in each of the above departments is carried out in parallel, but the development tempo during this time is not necessarily the same.

When looking at the development progress up to the final stage of actual device testing from the perspective of software development, as mentioned above, the software cannot perform emulation testing without an electrical circuit board, so the development schedule consists of designing and prototyping the electrical circuit board, as well as prototyping. It will depend on the completion of. For example, if the completion of an electrical circuit board is delayed, the development schedule does not allow for the full use of debugging through emulation testing, and software bugs are not eliminated before actual device testing is started. As a result, basic software troubles occur one after another when debugging actual devices.

Below is the recording equipment! The development of the control/O-gram will be explained using a copying machine as an example.

Figure 52 is an automatic document transport bag! 1 shows a schematic diagram of a copying machine equipped with a sorter and a sorter.

In the figure, an automatic document feeder 140 is placed on the top surface of the copying machine main body/O0 for automatically transporting the original onto the platen glass of the copying machine main body, and a A sorter 160 is arranged to sort and discharge subsequent sheets into bins 161.

Inside the copying machine main body /O0, a photoreceptor drum /O1 that rotates in the direction of the arrow is arranged, and around this photoreceptor drum /O1 there are a charger /O2, a developer /O3, a transfer device /O4, and a peeler / O5, cleaner/O6, etc. are arranged in this order.

In addition, a document (not shown) is placed on the top of the copying machine main body/O0.
A light source 111 for illuminating the document, a mirror 112 and a lens 113 for focusing reflected light from the original onto the photoreceptor drum/O1 are provided, and these constitute a scanning optical system. Using this scanning optical system, the charger/
An electrostatic latent image is formed on the photosensitive drum/O1 charged by O2. This electrostatic latent image is
It is visualized as a toner image by O3. At the same time, the first 1st page stores paper of different sizes. Paper from any of the second and third trays 121, 122, 123 is transported by the paper feeder 121 toward the photoreceptor drum/O1, and the toner image on the photoreceptor drum is transferred onto the paper by the transfer device/O4. . At this time, a registration gate (not shown) is provided in the paper transport path so that the paper is fed at a predetermined timing in synchronization with the rotation of the photosensitive drum/O1. The paper after the transfer is peeled off from the photoreceptor drum/O1 by a peeler/O5, and transferred to the conveyor belt 12.
5, the toner image is sent to a fixing device 126, and the toner image is fixed on the paper.

In normal copying, the paper after fixing passes through the inverter 127 as it is and goes to the sorter 160, as shown by the solid line.
It is discharged into a predetermined bin 161. In the case of double-sided copying, as shown by the - dotted line, after the - side has been copied, the front and back sides of the paper are reversed by the inverter 127, and once stored in the double-sided tray 128, the paper is transferred to the circulation device 129 and the paper feeder. The photosensitive drum is conveyed again in the direction of photosensitive drum /O1 via 124, and this time the other side is copied.

In the copying machine as described above, the automatic document transport device 140
When copying is performed using the sorter 160, the original is placed on the original tray 141! Then, copy machine main body/O
When the copy start button (not shown) provided on the console panel of 0 is pressed, the automatic document feeder 140 first
As shown in FIG. 53, the original is conveyed to the specified value 1 on the platen glass 144.

That is, the original on the original tray 141 is moved to the paddle 142 .
143 onto the platen glass 144, and is conveyed to the specified value 1 on the platen glass 144 by the conveyor belt 145.

Next, a scanning optical system including a light source 111, a mirror 112, a lens 113, etc. moves in the horizontal direction in the figure under the platen glass 142 in synchronization with the rotation of the photoreceptor drum/O1 to scan the original.

As a result, 5. After an electrostatic image is formed, well-known processes such as development, transfer, peeling, fixing, discharge, and sorting are performed.

Further, the copied original is removed from the platen glass 144 by the conveyance belt 145, scooped up by the gate claw 146, and discharged to the original document receiver 148 on the upper part of the automatic document conveyance device 140 by the document conveyance roll 147. When this is performed, each process is performed while detecting the operation of each device and the state of paper passage.

Such an automatic document feeder 140. In a copying machine equipped with peripheral devices such as the sorter 160, the operation of each device must be controlled in relation to the status of other devices.
A communication channel connects the copying machine main body and each peripheral device.

Also, each device is controlled by MPLI, but each MPU
Data is exchanged via the interface and the communication channel. Further, even within the same device, a plurality of MPUs may be provided for different functions.

As shown in FIG. 54, the copying machine main body/O0 includes a copying machine mechanism section 131. It is composed of an MPU 132 and an electric circuit board 133 that provides an interface between the two. A console panel 134 for operation is connected to the electric circuit board 133, and signals from keys such as starting the copying machine are supplied to the electric circuit board 133, and data such as the number of copies, messages, etc. console panel 13
4 and displayed by lamps, light emitting diode matrix, etc.

At home, the copier itself/peripheral equipment for O0! , that is,
The above-mentioned automatic document feeder 140, sorter 160, etc. have similar configurations. For example, the automatic document feeder 140 has an automatic document feeder mechanism section 151 and M
Electric circuit board 153 provided between P U 152
Signals and data are exchanged by The operations between the devices are controlled by, for example, serial communication data.

In developing a program to be executed by the MPU 132 in this type of copying machine, a device called a simulator kit shown in FIG. 55 is used as a debugging development tool. This is a tool for performing the emulation test mentioned above.

The simulator kit 1f0 is the actual copying machine mechanism section 13.
1 and the input system and output system of the console panel 134 are connected to the switch panel section 171. In addition to replacing the display panel section 172 and pseudo console panel section 173, the target MPU 1 is inserted into the MPU socket on the electric circuit board 133.
32 and in-circuit emulator 174 ((
] (indicated by ICE).

The switch panel section 171 is provided with a plurality of switches 171a for setting the status of each component from the outside. Then, the switch 171 of the switch panel section 171
By operating the switch 171a, the output from the switch 171a is supplied as an input signal to the electric circuit board 133. At this time, a blue lamp 172a provided on the display panel section 172 lights up to display the status of the corresponding input component.

Further, the output signal from the electric circuit board 133 is supplied to the red lamp 172b corresponding to each output component, and its status is displayed.

Although a plurality of switches 171a, blue lamps 172a, and red lamps 172b are provided, only one of each is shown in the figure for convenience.

Further, the electric circuit board 133 includes a level converter 175.
, a personal computer 177 is connected via an input/output interface 176.

The simulator kit is provided with a display panel section 172 on which the layout of the copying machine is schematically drawn. As shown in FIG. 56, the display panel section 172 schematically depicts the layout of the copying machine to be developed so that the flow of paper during copying can be visually grasped.

For example, in the figure, 181 is a photosensitive drum, 182 is a fixing device, 183 is a roller, and 184 is a paper feed tray. In addition, a document conveying device 140, a conveying belt 145
At the location corresponding to , there is a display 186 corresponding to the bin 161.
There is. Furthermore, the display panel section 172 includes a plurality of blue lamps 172a that display the outputs of input components such as various sensors.
(indicated by black circles in the diagram) are arranged, and a plurality of red lamps 172b (indicated by white circles in the diagram) that display the status of output components such as motors and solenoids correspond to each of these components. They are placed in different locations and each has a name. For example, display 184 of the top paper tray
There is a red lamp 172b+ named FEED-SQL that indicates the operation of the feeding solenoid, and a FEED OυT SNR (1) that indicates whether the paper is being fed.
A blue lamp 172a+ named .

Further, on the input side of the display 181 of the photosensitive drum, there is a red lamp 172b indicating the operation of a solenoid named REG-SQL that controls the registration gate that determines the timing to start transporting the paper, and a red lamp 172b that indicates the operation of a solenoid named REG-SQL. REG indicating whether paper is being fed
- A blue lamp 172a2 labeled SNR is provided, and a FUS l lamp is provided on the input side near the fuser display 182 to indicate whether paper is being fed to the fuser.
A blue lamp 172a, named N-5NR, is provided.

Also, FSRO [IT-
Red lamp 1 indicating the operation of the roll named ROLL
72b is provided. In addition, a blue lamp indicating the arrival status of the paper and a red lamp indicating the operating status of the motor, solenoid, etc. are displayed on each route, but a description of these will be omitted.

Additionally, lamps are similarly provided at locations corresponding to the automatic document feeder and sorter.

As mentioned above, the electric circuit board 133 includes the personal computer 177 and the input/output interface 176.
and a level converter 175.

Timing data and communication data from this personal computer 177 are input to the input/output interface 1.
The signal is branched into a predetermined number of signal paths by 76, matched in level by level converter 175, and supplied to electric circuit board 133. Note that the timing data and communication data simulate signals from each sensor and other peripheral devices.

Further, the state of the signal output from the electric circuit board 133 is configured to be displayed on the console of the personal computer 177.

Next, the operation of the above simulator system will be explained.

This simulator system has a manual control mode and a personal computer control mode.

In the manual control mode, transmission/reception simulation, sensor signal simulation, etc. are performed.The transmission/reception simulation is performed by transmitting data input from the keyboard of the personal computer 177 or initially loaded data to the electric circuit board 133.
The data received from the electric circuit board 133 is displayed on the console of the personal computer 177.

As described above, in the sensor signal simulation, a signal to the electric circuit board 133 is set by turning on/off the switch 171a of the switch panel section 171, and its state is displayed by the blue lamp 172a.

In addition, the output signal from the electric circuit board 133 is the red lamp 1.
72b.

In personal computer control mode, electric circuit board 1
This is used when debugging the control program of No. 33 and performing a paper running test etc. according to the timing chart.

Here, the paper running test will be explained.

When paper is conveyed sequentially inside the copying machine,
How the program is executed depending on the conveyance position of the paper is simulated based on, for example, timing data that simulates the output of a sensor.

That is, the in-circuit emulator 174 executes the same program as the target MPU 132 while supplying various sensor signals from the switch panel section 171 or the personal computer 177, and displays the lamps 172a and 172b on the display panel section 172. By observing the operating status of the copier as expressed by blinking,
Checking whether the program is working properly.

If the operation is abnormal, the lamps 172a, 17
The defective part of the program is estimated from the state of 2b, and the in-circuit emulator 174 is used to detect and correct the error in the program.

Additionally, a logic analyzer is used to detect timing data, and an oscilloscope is used to inspect the actual waveforms of each part.

Technical issues of this simulator Traditionally, in software development for recording devices,
As mentioned earlier, it is carried out in three steps,
Among these, in emulation tests and actual machine tests for debugging software, the later the test goes, the more man-hours are required to deal with software problems, which becomes a problem in terms of the overall product development schedule. Figure 57 is a graph showing the number of troubles in the debugging process and the number of man-hours required for countermeasures.In Figure 1, the developed software is not debugged by itself,
Bugs are discovered through emulation tests and real machine tests, and the proportion of bugs in the total number of troubles is about 571% in emulation tests and about 42.9% in real machine tests.

In other words, slightly less than 60% of bugs are discovered during emulation testing and removed at this stage, while the remaining 40% or more are removed during the next actual machine test.

The time it takes to investigate and take countermeasures for these problems varies greatly depending on the stage at which they are discovered.

At the emulation test stage, since problems affect two departments: electrical circuit design and software design, both hardware and software problems can be resolved in a relatively short period of time. However, at the stage of actual machine testing, it affects three departments: mechanical design, electrical circuit design, and software design, so solving a single problem requires coordinating how to divide the cause and countermeasures among each other. It is very time-consuming and requires a large number of man-hours. Incidentally, when comparing the efficiency of troubleshooting at each test stage, it takes 1.7 times more man-hours for troubleshooting in an actual machine test than in an emulation test.

Applying this to the number of troubles mentioned above, troubles in emulation tests account for about 30.6% of the total troubleshooting man-hours, while in actual machine tests it accounts for about 69.4%.
%. Furthermore, when looking at the total man-hours for software development, the man-hours for debugging account for 50% of the total. Therefore, increasing the efficiency of debugging greatly contributes to increasing the efficiency of software development as a whole. Therefore, it is strongly desired to reduce the number of debugging steps.

In this way, with the conventional method in which software cannot be debugged by itself, many troubles occur during electrical circuit board/software connection and debugging of the actual device.Furthermore, the later you go, the more man-hours are required to deal with the problem, and as a result, it becomes difficult to develop products. This leads to a decrease in efficiency.

By the way, it takes several months to design and prototype an electric circuit board or device body (mechanical part), and in particular, changing the design of an electric circuit board or device body after completion is a difficult task due to time constraints and costs in the development schedule. When a problem occurs during testing of a program on an electric circuit or a prototype device, it is difficult to determine whether the problem is in the program, the electric circuit board, or the device itself. Software engineers also identify the cause of this problem. especially,
As a product nears completion, situations often arise that require software solutions, including these hardware problems.

Therefore, there is a problem in that this type of device development requires a great deal of effort on the part of software engineers.

The key to solving these problems is how to discover software problems early and deal with them.

Against this technical background, there was a need for a support system (simulator) that would allow software debugging without the need for an electric circuit board or a prototype device.

Next, we will discuss the problems with the configuration of this simulator.

In order to achieve the intended purpose, the target recording device is
The mechanical parts are configured to perform a series of operations based on control signals from the electric circuit board, and in order to simulate this series of operations, first, data indicating the operating state of the device,
In other words, a! Timing data is required that corresponds to the change in the output of the sensor placed in the 11th section to the specific operating time of the device.

Timing data is created from timing charts, but the creation of these timing charts is all done manually, which takes a lot of time and effort. Furthermore, since the work is done visually, human errors such as reading errors and writing errors are likely to occur, making it difficult to create accurate timing charts. Therefore, timing data for simulation could not be prepared in a short period of time.

On the other hand, the electric circuit board supplies a signal to the MPU based on the timing data, and outputs a signal to control the mechanical parts according to a program installed in the MPU.

Debugging such an application program is
Even if the program is completed at the source level, if the actual electric circuit board is not fully completed including the peripheral LSI, what kind of signals will be supplied to each terminal of the MPU, or what kind of signals will be supplied to each terminal of the MPU? It is not possible to know how the signal from the terminal is output to the outside.

Furthermore, in a device composed of a plurality of modules, debugging cannot be performed with a single module, and communication data from other modules is required.

Therefore, comprehensive debugging cannot be started until the electrical circuit boards of all modules are completed. Further, even if an electric circuit board for debugging is to be made, it is necessary to prepare an electric circuit board every time there is a change in the design of the circuit, which requires a great deal of effort and cost.

For this reason, due to constraints on the test period, etc., the device is sent to the next actual device debugging step before complete debugging is performed. In this actual device debugging, the target MPU is combined with an actual electrical circuit or mechanical part and the software is tested, but a problem arises in that many bugs are discovered at this stage.

However, troubles discovered during the debugging stage of the actual device require a great deal of time and effort to investigate the cause and take countermeasures, which significantly reduces the development efficiency of the entire system.

Furthermore, with conventional tools, only one type of MPU can be debugged, and if the type of MPU changes, it is necessary to change to a different in-circuit emulator.

This simulator, which was developed in view of the above-mentioned conventional software development circumstances, has the following features.

■The hardware environment in which the target program runs can be completely simulated in software, including the MPU and peripheral LSI.

■It is possible to create timing data for all test modes, including abnormal systems, enabling a wide range of tests.

■Tests can be performed in a multiprocessor system environment.

■Provides an advanced user interface using multiple windows and a mouse.

■By connecting to the target program manufacturing system via Ethernet, it provides a complete online development environment from manufacturing to debugging.

In order to have these features, this simulator has the following functions.

■The hardware environment surrounding the target program such as the MPU, surrounding area, and SI can be defined in software.

■Creating external signal data such as sensors and executing simulations.

■Generate communication data with other MPUs and execute simulation.

■Execute simulation of MPU and peripheral LSI circuits.

■Provides a debugging environment such as breakpoints, tracing, and monitoring.

By realizing the above functions, the following technical effects are expected.

■Simulation data can be created accurately, easily, and in a short time.

■You can debug the software in its entirety.

■By simulating the circuit operation of the LSI around the MPU, it is possible to
You can check the signal status at each terminal of the PU.

■If the target system is composed of multiple modules, the communication data necessary for each module's MPU can be supplied as data using software without using electric circuit boards or mechanical parts. Can be debugged independently.

■Output signals from sensors placed in mechanical parts are converted to direct signal data and used during simulation, but this direct signal data not only defines the normal operating status of the sensors, but also defines abnormal conditions. Assuming abnormalities in sensors, solenoids, motors, etc.
It is also possible to define three sensor output signals at this time. By executing a simulation using such an abnormal mode, it is possible to verify in advance the understanding of the situation in the event of an abnormality, and to formulate countermeasures.

[Problem to be solved by the invention]

Among the problems of the present simulator described above, the present invention is particularly intended to solve the problems related to a simulator equipped with a debugger.

The main object of the present invention is to provide a simulator for simulating the hardware environment in which a target program runs completely in software by determining the MPU and peripheral LSI.

Another purpose is to develop a record bag! The object of the present invention is to provide a debugger that simulates the target program using software and depacks the target program.

Still another object is to provide a simulator equipped with a user interface that allows all operations for grasping the situation and defining information during simulation execution to be executed on a window.

[Means to solve the problem]

In order to achieve the above object, the present invention defines hardware information of a target system including an MPU that executes a target program and peripheral LSIs, and a configuration that generates data indicating change states of signals to input terminals of the MPU. a simulation engine section that performs a software simulation of the electrical and mechanical elements constituting the target system as an engine; and a simulation engine section that synchronizes the startup time of each engine based on the configuration information and executes the simulation. A subsystem is configured from a simulation engine controller that updates the memory, I/O memory, and register states of the engine section that change when the subsystem is started, and performs set operations under each setting condition of break or trace. and a breakpoint function that outputs the trace contents when at least the setting conditions are satisfied, the execution process of the target program, any data changes, the target program before and after the setting conditions are met, or The debugger has a trace function that outputs the state of the MPU.

It also has a simulation window for controlling simulation execution and operating environment settings, and a debugger window for displaying depacking function condition settings and trace contents.

In order to realize the break trace function, the debugger has a set processing section that registers break or trace conditions in a table, a break trace management setting section that is called during set processing and registers debugger information in a memory management table, etc. a break trace management monitoring unit that monitors the break trace or break condition fulfillment information that the access service unit sets in the memory management table during simulation execution; and a break trace execution processing unit that determines a break or trace condition and executes a break or trace after the condition is satisfied.

[For production]

By starting the set processing section, the break trace information set in the break or trace setting window is set in the table, and at the same time the break trace management setting section is called, and the write or read debug information is stored as a break or trace point in the memory etc. Set in the management table.

After that, when the simulation is executed and the subsystem is started, the memory access module of the access service section will check whether a memory special code is set in the access address of the memory management table when accessing memory, I/O memory, or registers. For example, break trace condition fulfillment information is set in a memory management table. The break trace management monitoring unit monitors the above information set by referring to the memory etc. management table. The break trace execution processing section refers to the table and updates the count every time it is called by the monitoring section.

That is, when executing a simulation, it is determined through the access service section how many times a memory address set as debug information of the memory space should be accessed to break or trace. Each time a set condition is satisfied, the monitoring section activates each execution processing section, counts down the count value of the counter in the table, and breaks or traces when the count reaches "0".

〔Example〕

Embodiments of the present invention will be described below based on the drawings. Regarding the hardware configuration function that constitutes this simulator, please refer to Japanese Patent Application No. 1-140716 (filed on June 2, 1999) previously filed by the same person, and regarding the subsystem including the sophisticated simulation engine. , is described in detail in Japanese Patent Application No. 1-262908 (filed on October 11, 1999), so this application cites the above application and describes the constituent elements described in the above application regarding the present invention. Detailed explanation will be omitted.

(1) Structure of simulator FIG. 2 is a schematic diagram of the hardware structure of this simulator. The central processing unit/O performs overall control and data processing of this simulator, and this central processing unit f
Connected to lo is a main memory 11, a keyboard 13 for inputting various data and instructions via an internal bus 12, a display 14 for displaying processing results, and a disk device 15 for storing programs and data.

The disk device 15 stores programs necessary for all processing during simulation execution,
Software resources such as data are stored as files, and when executing a program, the program and data in the disk device 15 are loaded into the main memory 11 and the central processing unit executes the program. /O uses these software resources to perform necessary processing.

Next, the lfi function realizing means for realizing the software configuration of this simulator will be explained based on FIG.

This simulator includes a simulator management unit 200 that controls the specification of product and module names, window display, and starts each session process.
a configuration unit 300 that sets various hardware conditions of the target system and generates various data necessary for simulation;
It is composed of a simulation section 400 that executes simulation of a target system such as an I circuit or MP[I, and a display window section 500 that displays various information of the simulator on a graphic display.

The configuration unit 300 includes an MPU clock,
MPU information setting unit 3/O for setting memory, terminals, etc.;
There is an LSI information setting section 320 that defines control/data addresses of various interface LSIs and terminal connection relationships, and a clock that is used to execute target programs, count timing data, and serve as a reference during simulation. A machine clock information setting section 330 for setting, a machine layout setting section 340 for arranging marks corresponding to I/O boats on a schematically drawn recording section in order to understand the simulation situation on the screen, A configuration verification unit 350 that checks the consistency between various setting data and creates various data required during simulation.
Then, information indicating the operating state of the target system, that is, timing data in which signal levels of sensors, etc. of mechanical parts are arranged in chronological order, is generated, and this generated timing data or a separately provided data creation block is used to generate timing data. A timing data creation/conversion unit 360 that converts the format of the generated timing data into direct signal data that can be used by the simulator, definition of a communication protocol for communicating with other MPUs, and the definition of a communication protocol when assuming a certain operation mode of the target system. It is composed of a communication data generation section 370 that sets actual communication data.

The simulation unit 400 includes a simulation management unit 4/O, a window management unit 430, an engine unit 440, and a debugger 450, and runs a simulation engine (hereinafter referred to as the engine) based on the hardware information of the target system defined by the configuration unit. ) and supplies test data to this engine to debug the target program.

The display window unit 500 displays various data in a window on a bitmap display when setting definition information or generating data in the configuration unit.

Simulation management includes functions such as creating and closing windows, branching to event processing execution in each window when an event occurs in an open window, starting the engine to execute a simulation, and It has functions such as providing various debugger functions such as break and trace.

The simulation management unit 4/O selects the session "'Simula" of the simulator window 5/O shown in FIG.
When "Go 5ession" is specified and "Go 5ession" is selected, it is called and started by the simulator management section 200, and controls the simulation initialization section 420, window management section 430, engine section 440, and debugger 450.

Figure 4 shows the operation sequence of the simulation management section. It checks whether or not there is event processing in a window, and if there is event processing, it is executed for each window, and after the event processing is finished, the engine executes the simulation. , then starts the debugger and executes debugger functions such as break and trace. When executing the simulation, the process loops as shown by the arrows while calling each of the above processes.

The window management unit 430 manages windows related to various simulations and events.

The engine unit 440 executes a simulation by starting a clock engine, an MPU instruction engine, a direct signal engine, a communication data engine, an MPU boat engine, and an LSI circuit engine according to system time and state changes.

The debugger 450 provides functions such as breaking and tracing within stain alignment, as well as monitoring, file display, and correction functions.

(n) Window Figure 5 specifies the session ``Simulation'' in the simulator window and selects ``GO5essi''.
This is a simulation window that opens when you select on. Note that the initial screen of the window is a state in which the machine layout is not displayed in the monitoring window. This window allows you to manipulate the following executions:

■Simulation execution control ■Various settings for simulation environment (mode) ■Various target program selections ■Various layout diagram selections ■Display and settings of registers, memory, etc. ■Monitoring, breaking, tracing, and monitoring of signal changes during simulation execution A simulation window 600 for manually inputting communication data and signal data has a message display section 601 that displays error messages and system-related messages. It consists of a command area 602 in which commands necessary for controlling execution of simulation are provided, and an information area 604 in which simulation information is provided. Note that the simulation is executed by selecting the mode command 6022.

(a) Simulation mode Simulation of the target program is executed in synchronization with the external environment such as communication data and timing data.

In this mode, there is an auto mode in which test data such as communication data and timing data is continuously supplied and executed, and a step mode in which test data is supplied and executed sequentially at the same time label, that is, in steps on data queuing. , a manual mode can be selected in which test data is supplied and executed through manual settings.

Since the auto mode runs the target program while continuously supplying test data, it is effective for automatic debugging of the program.

Step mode supplies test data at the same time label to check the target program at a certain operating stage.For example, suppose a paper passes through a certain position at what hour and what minute as a certain operating stage. The state of the hardware to be operated at that time, for example, the presence or absence of a sensor output that confirms the drive of the motor is checked.

In manual mode, test data can be set arbitrarily, so system abnormalities can be reproduced.

(b) Program mode A simulation is executed for only the target program.

In this mode, the target program is run without using test data to check the operation of the monitor. In practice, this is done by setting values in the memory or registers of the CPU as substitutes for test data at locations where test data is required, and running the program.

Additionally, in program mode, you can check the execution time of each step or subroutine.

Then, the execution control of the simulation is started (S
TART), step (STEP), stop (ST
This is performed by a command group 6021 consisting of OP) and reset (RESET).

"S T A RT" executes a simulation including communication data and timing data in the simulation mode, while in the program mode it executes a simulation of only the target program.

"STEP" causes the simulation of the target program to be executed step by step.

Here, in the simulation mode, one step refers to a block of signal data that changes at the same time in timing data, and in the program mode, it refers to one instruction of the target program.

"S T OP" stops the simulation execution.

"RESET" sets the simulation environment to its initial state.

(I [I) Engine As shown in FIG. 6, the entire engine section is called by the simulation management section 4/O, and the simulation engine controller 441 ( (hereinafter referred to as an engine controller), an engine initialization section 420 that initializes the engine, and engines 442 to 447 that are started by the engine controller 441.

The engine section 440 mainly includes a clock engine 442 that simulates a clock signal that generates a fixed periodic pulse that is input to a clock terminal of a timer/counter.
, an MPU instruction engine 443 that executes instructions of a target program, a direct signal engine 444 that executes a simulation of dielet signals input and output between the LSI circuit and the outside, a communication data engine 445 that executes a simulation of communication data, It includes an MPU boat engine 446 that executes a simulation of an MPU built-in board, and an LSI circuit engine 447 that executes a simulation of a peripheral LSI circuit.

Next, data such as lists, buffers, and tables used between each engine will be explained with reference to FIG. 7.

The LSI-destination direct signal state change list 444^ is data for notifying the LSI circuit engine 447 of a direct signal whose state has changed.

Direct signal state change strike 4 addressed to direct signal engine
47^ is data for notifying the direct signal engine 444 of the direct signal whose state has changed.

Direct signal state buffer 444B stores the state of the direct signal, ie, whether it is high level or low level.

The LSI destination MPU terminal state change list 446^ is data for notifying the LSI circuit engine 447 of the MPU terminal whose state has changed.

The MPU terminal state change list 447D addressed to the MPU is data for notifying the MPU boat engine 446 of the MPU terminal whose state has changed.

The MPU terminal state buffer 446B stores the state of the MPU terminal, that is, whether it is at high level or low level.

The LSI address clock terminal state change 442^ is data for informing the LSI circuit engine 447 of the real value clock signal whose count number has changed.

This is data for informing the MPU boat engine 446 of a real value clock signal whose count number has changed.

Clock count state buffer 442B stores the total count value of the user-defined real value clock signal from the system start time.

The MPU clock count state buffer 442D stores the total count value of the real value clock signal used by the MPU boat engine 446 from the system start time.

The clock terminal configuration table 442C has the number of real value clock signals, connection terminal information, and count value location information defined as real value clock signal configuration information.

The MPU built-in clock configuration table 442E is
It has information such as the number of real value clock signals built into the MPU, connection terminal information, count value location, frequency, etc.

LSI Shipping Shipping-Data List 445^ This is data for transmitting data to be sent from the LSI circuit engine 447 to the communication data engine 445 to the communication data engine. This data is also used as a condition for the communication data engine to generate data to be sent to the LSI circuit engine.

MPU Shipping Shipping - Data List MPU Boat Engine 4
46 to the communication data engine 445.

The LSI destination received data list 445C is data for notifying the LSI circuit data of the received data from the communication data engine 445 to the LSI circuit engine 447.

The MPU destination received data list 445D is data for notifying the MPU boat engine of the received data from the communication data engine 445 to the MPU boat engine 446.

The transmission buffer communication information 445F is the communication LS1. MPU
This is data for informing the communication data engine of the transmission status of the communication boat and the transmission time required to transmit 1-byte data to the communication data engine, and has information on the transmission status and transmission time for each piece of data.

Here, the transmission status defines whether or not the communication LSI and communication boat are in a transmittable state.

The reception buffer communication information 445G includes communication LSI, MPU
This data is used to notify the communication data engine of the reception status of the communication boat and the reception time required to receive 1 byte data from the communication data engine.

The transmission buffer configuration table 445H has information such as the number of transmission buffers, transmission buffer addresses, and the location of the configuration table of the transmission buffer type 1 communication LSI as transmission buffer configuration information.

Receive buffer configuration table 445Ic. Receive P+ buffer configuration information including the number of receive buffers, receive buffer address, and receive buffer format 1.
It has information such as the location of the configuration table of the communication LSI.

The interrupt event list 446B is data for transmitting from the MPU boat engine 446 to the MPU instruction engine 443 that an interrupt has occurred.

Below, we will explain how to control the engine.

Synchronous control of each engine will be explained with reference to FIG.

The operation timing request list 441^ is registered with data for the active engine, that is, the engine that is currently running, to notify the engine controller 441 of the next operation timing.

The start request control table 441B is a table in which the operating environment of another engine, for example, an engine that has changed the terminal level of an LSI to either a high or low state, notifies the controller of a start request list of engines to be started with data. A table is registered to do this.

The request data includes a direct signal state change list addressed to LSI, an MPU terminal state change list addressed to LSI, an MPU terminal state change list addressed to MPU, a received data list addressed to LSI, a received data list addressed to MPU, a clock terminal state change list addressed to LSI, M
Quo clock terminal status change list directed to PU Direct signal status change list addressed to engine, transmission data list addressed to LSI.

These are a transmission data list addressed to the MPU and an interrupt event list.

Clock engine 442. MPU instruction engine 443° Direct signal engine 4441 Communication data engine 4
45. The MPU boat engine 446 and the LSI circuit engine 447 are synchronized using the system time managed by the engine controller 441. This system time serves as a reference time for synchronizing each engine.

A time controller located within engine controller 441 informs each engine of the current system time. However, among the engines, only the engine whose operation timing has come is started, so only the started engine can know the current system time. Each engine performs a predetermined operation as described later at the notified time, and writes the next operation timing into the operation timing request list 461^.

The starting order of each engine will be explained with reference to FIG. 9.

The engine controller 441 includes an operation timing request list 441^ and a startup request control table 4.
41B, the engines are sequentially started in the order indicated by ■ to ■ in the figure.

In the second case, operating the clock engine 442 for each clock increases the load on the simulation device, so in this embodiment, in addition to the clock engine, an engine called a prestage clock engine 4420 is provided. This engine 4420 processes the clock elements up to the first stage, that is, the LSI elements that function to count clocks, at the operating timing of other engines. However, the level of the output terminal of the tallock element is At the timing of the change, the clock engine operates regardless of the operation of other engines.

Note that a stage is the minimum time resolution time period required for the simulator to execute a simulation.For example, when simulating a certain target program, it is the operating time required by the engine to execute one instruction. .

The operation of each engine will be explained in order of startup. First, when the Blistage clock engine is started, the LSI engine clock processing section 442 performs updating processing of internal counters, etc.
1. and an MPU boat engine clock processing unit 4422 that calculates and sets the reference time of the MPU boat engine.
operates, and as described above, the LSI circuit engine 44
7 and the MPU bottom engine 446 perform clock processing in advance before the actual startup timing. For example, when simulating an LSI such as the R8253 that uses a clock, the LSI engine clock processing unit 4421 only performs processing for updating an internal counter.

When the MPU instruction engine 443 is started, it is called by the MPU engine's I/O instruction, and the LSI engine MPU I/O processing section 4470 and MPU corresponding to the address are called.
The PU boat engine I/O processing unit 4460 is operated.

Each LSI has memory areas called data addresses and control addresses, and these addresses are
Some are built into the address space of the U and can directly read and write data using MPU I/O commands. This address space is called an I/O address.

The MPU I/O processing unit 4470 sends MPU to the above address.
Processes the response on the LSI side to data reading and writing performed by the PU command.

That is, when the terminal level of an LSI changes, this level change is written to the LSI request list 447C, and the change is transmitted to other LSIs connected to the terminal of that LSI.

The LSI request list 447C is for notifying each LSI engine of changes in the terminal level that occur during simulation of the LSI circuit engine, and a list is created for each circuit level.

On the other hand, the MPU boat engine I/O processing unit 4460 executes a boat operation according to an I/O command to the MPU boat, and rewrites the MPU terminal state change list 446^ addressed to the LSI.

When the clock engine 442 is activated, it rewrites the LSI clock terminal state change list 442^ and the MPU clock terminal state change list 442F, and the contents are transmitted to the LSI circuit engine and the MPU boat engine.

When the direct signal engine 444 is activated, the LSI
Addressed direct signal status change list 444^ is rewritten,
The contents are transmitted to the LSI circuit engine.

When the communication data engine 445 is activated, the LSI destination reception data list 445C and the MPU destination reception data list 4
45D is rewritten, LSI circuit engine and MPU
transmitted to the boat engine.

When the MPU boat engine 446 is started, the MPtJ terminal state change list 446^1 addressed to the LSI is replaced with the interrupt event list 446B and the MPU dispatch data list 445B, and sent to the LSI circuit engine, MPU instruction engine, and communication data engine, respectively. Reportedly.

When the LSI circuit engine 447 is started, the transmission data list 445^ and the MPU terminal state change list 447 addressed to the MPU are sent.
The direct signal status change list 447^ addressed to D and direct signal engine is rewritten, and communication data engine, M
After being transmitted to the PU boat engine and the direct signal engine, the MPU boat engine is started again, and finally the L
The SI circuit engine is started.

The reason why engines are started in this order is to run engines that affect other engines first, and run engines that are affected by the execution of other engines later.

By the way, there is a possibility (almost never) that a loop will be created between the MPU terminal and the LSI circuit element, and this cannot be found in the LSI circuit configuration. Therefore, a startup loop is considered between the MPU boat engine and the LSI circuit engine. (Figure 9■■■
(See ■) For example, count the MPU clock and
When assuming processing to change the state of the clock terminal of an LSI, first, the MPU boat engine counts clocks, and this count value controls the change of state of the clock terminal of the LSI. After changing the state of the clock terminal based on the count value, the LSI engine notifies the MPU boat engine of the result and requests execution of the interrupt event.

(1%') When "5TART" is selected after completing the operations necessary for simulation execution using the simulator's action window, the engine initialization section is called by the simulation management section and initialization of each engine is executed. The engine controller starts each engine in a predetermined order.
A simulation is run. The case where simulation mode is selected will be explained below.

The engine controller first looks at the operation timing list, calls the prestage clock engine, and then
The engine clock processing unit and the MP boat engine clock processing unit are activated to update the internal counters of the LSI and
Calculate and set the frequency clock count used by the PU boat engine.

Next, the MPU instruction engine is called, and the LSI engine MPU I/O processing section and the MPU boat engine I
/O processing section is activated.

In order to notify each LSI engine of changes in pins that occur during simulation of the LSI circuit engine, the LSI engine MPU I/O processing unit stores location information of the configuration table containing configuration information of the pins of the LSI for each circuit level. It is created as an LSI request list.

On the other hand, the MPU boat engine I/O processing unit executes a boat operation by issuing an I/O command to the MPU boat.

Based on the results, the I/O processing unit creates an MPU terminal status change list addressed to the LSI to notify the LSI circuit engine of the MPU terminals whose status has changed, and registers the contents of the list in the startup request control table. . In the subsequent startup of the LSI circuit engine, the state of M
The PU terminal can be known by looking at the MPU terminal state list addressed to the LSI, and its state information is known as either high or low from the MPU terminal state buffer, and is used for processing related to information from other engines. be done.

When the system time of the MPU instruction engine has elapsed, the engine controller refers to the operation timing request list and the startup request control table and sets the system time for the engine that has the system time closest to the current system time. For example, when the above system time is set in the clock engine, the tarok engine is started and the clock terminal configuration table and MP
Creates a clock terminal status list for the LSI and a list of clock terminal status changes for the MPU to notify the LSI circuit engine and MPU boat engine of real-value clock signals whose counts have changed based on the U built-in clock configuration table. In addition to sending the list to the engine, the contents of the list are registered in the activation request control table.

Then, the count value of the real value clock signal whose state has changed is stored in the clock count state buffer and M
Store in clock count state buffer for PU.

Similarly to the above, when the direct signal engine is activated by the engine controller, a list of direct signal status changes addressed to the LSI is created and sent to the LSI circuit engine to notify the LSI circuit engine of direct signals that have changed status. Register the list contents in the startup request control table.

Here, in a multi-system composed of a plurality of MPU modules, a simulation of communication data performed by each MPU module is performed.

When the communication data engine is started, it checks the reception or transmission buffer communication information file to confirm whether the communication destination device is in a communicable state, and then refers to the transmission and reception buffer configuration table to configure the LSI circuit. A list of received data addressed to the LSI and M
A list of received data addressed to the PU is created and sent to each of the engines, and the data communication time is calculated from the transmission or reception time of one byte. This information is displayed at the user's request. Thereafter, the contents of the list are registered in the activation request control table.

After the system time of a communication data engine has passed, the MP
When the U-boat engine is started, it refers to the clock terminal state change list, takes in the total count value of the real value clock signal of the clock terminal from the MPU clock count state buffer, and based on this tally signal, reads the received data list and the MPU. Referring to the destination terminal state change list, an LSI destination MPU terminal state change list is created to inform the LSI circuit engine of the MPU terminal that has undergone a state change, and the contents of the list are registered in the activation request control table.

Here, if there is a change in the state of a boat that performs interrupt processing among the MPU boats, an event list corresponding to the change is written in the interrupt event list.

Also, if there is data to be sent to the communication data engine,
A receive buffer for notifying the communication data engine of transmittable information and 1-byte transmission time, and a transmit buffer for the destination.

A transmission data list in which transmission time, transmission data, and transmission information are arranged is created and sent to the communication data engine, and the contents of the list are registered in the activation request control table.

When the system time of a certain engine has passed and the LSI circuit engine is started, a clock terminal status change list for the LSI is displayed.The clock terminal whose status has changed is connected to which LSI in the clock terminal configuration. The total count value of the real value clock signal of that clock terminal is read from the clock count state buffer, and based on this clock signal, receive buffer communication information similar to the above is created, and the transmission destination is buffer.

A transmission data list is created in which transmission information consisting of transmission time and transmission data is arranged and sent to the communication data engine. Then, an MPU terminal status change list addressed to MPtJ is sent to notify the MPU boat engine of the MPU terminal that has changed in status, and a direct signal status change list is sent to the direct signal engine to notify the direct signal engine of the direct signal that has changed status. At the same time, the contents of the list are registered in the activation request control table.

(V) Debugger As shown in Figure 1, the debugger is managed by the simulation management section and provides breakpoint functions, trace functions, etc. to the user at the same time as the simulation is executed.
Each of the above-mentioned functions will be explained below, which provides memory and register setting/display functions, monitoring functions, and set-up functions.

(V-1) Breakpoint function This is a function that stops running the target program when a certain condition is met.

This function is used to check whether the program passes the set conditions, and to check the contents of memory and registers when the conditions are met.

FIG. 2 shows a module configuration for setting and executing various breakpoints.

The window management unit 430 is the simulator management unit 200
The simulation window event handler 4300 managed by the window event handler 4300 and the event handlers 431 of various windows opened by the window event handler are managed.

The window generation unit 43/O executes °'Bre from the debugger command 6023 of the simulation window 600.
akpaint” is activated by the simulation window event handler 4300, and the first
The breakpoint setting window shown in Figure 1 will open.

The breakpoint setting window 700 includes a command selection section F01 in which commands for executing operations such as setting and deletion are provided, a parameter display section 702 in which parameters are provided for specifying which conditions to break, and Entry point display section 7 that displays break conditions
It is equipped with 03.

The window drawing unit 4311 performs processing for displaying specified parameters and set breakpoints in a window.

The set processing unit 4312 is activated by specifying the command °'Set'' and registers the contents specified by the parameters in the breakpoint table.

The clear processing unit 4313 is activated by specifying "C1ear" and deletes only the currently selected entry point.

The clear all processing unit 4314 is activated by specifying “C1ear^11” and deletes all breakpoints displayed in the entry point display unit 703.

When the set processing, clear processing, and clear all processing are executed, a break trace management setting section of the access service section, which will be described later, is called and the information in the memory management table is updated.

The history processing unit 4315
” to display the contents of the breakpoint history file in a pop-up menu.

The exit processing unit 4316 is started by specifying “Exit” and operates the window closing unit 4317 to close the window 700.

The information setting unit 4318 inputs data input from the window such as memory register information, read/write type, hex (Hex) or binary (Binary).
) to set the data format and break count.

The functions of the above-mentioned parts are basically the same as the module configurations of the signal timing trace, clock count trace, running trace, and halt trace described below, so the explanation for each trace will be omitted. Also timing data trace, runtime sampling,
Since some of the module configurations of the memory dump are basically configured with the same functions, their explanations will be omitted.

The breakpoint function uses memory, I/O memory, and register management table 430 as interface data.
(hereinafter referred to as a memory management table), a breakpoint table 431^, and a breakpoint history file 431B as internal data.

The data processing will be explained below.

The debugger collectively manages registers and memory, and has respective management tables in addition to the tables storing the actual data of registers, memory, and /O memory in order to satisfy various functions.

(a) Register management This is done using a register table, register relationship table, and register management table.

The register table has the same size as the actual MPU register and functions in the same way.

The register relationship table defines relationships i such as register bears for all registers, and an example of the table structure is shown in FIG. 12(a).

Furthermore, Table 1 shows the HL of MPU 78/O/7811.
This is an example of setting a register relationship table for registers.

The register management table shown in Table 1 has information such as the setting status of break points and trace points, and an example of the table structure is shown in FIG. 12(b).

The register total flag is a flag set so that the break trace management can perform break trace processing efficiently.If there is no access to the register where a break point/trace point is set, the register total flag is set to 0.
”, and if there is an access, a value other than “0” is set.

The debug information is set with data representing the breakpoint setting state.

Register relationship table points are register access/
When a module accesses a register, it is used to check whether debug information is set for the register related to that register.

The flag is "0" if no breakpoint/tracepoint is set in the register, or if the breakpoint/tracepoint is set but the above point is not accessed.
Further, if a breakpoint/tracepoint is set in a register and the register is accessed, a value other than "0" is set.

(b) Memory management is performed using a memory table and a memory management table.

The memory table is a space of the MPU, and the target program is also loaded into this table.

The memory management table has information such as the setting status of breakpoints and tracepoints. When a breakpoint or tracepoint is set, a special memory code (described later) is set in the memory at the corresponding address, and the actual data is set in this table.

Note that this table is created only for memory addresses where breakpoint trace points are set.

FIG. 13 shows an example of the structure of the memory management table.

The memory total flag is provided for the same purpose as the register total flag described above, and is used for breakpoints/
If there is no access to the memory address where the trace point is set, "0" is set, and if there is an access, a value other than "0" is set.

As the debug information, data representing the setting state of the trace point is set.

The address is a memory address where debug information is set.

The data is the actual data that was on the memory table.

Next, data registered in the memory table and memory management table when setting a trace point will be explained with reference to FIG. 14.

In the memory table before a trace point is set, actual data is registered at an address, and when a trace point is set at the actual data at a certain address, a memory special code is set in place of this actual data. . The actual data at this time is registered in the memory management table together with the address. Figure 14 shows an example of settings for each table when a trace point is set at the actual data "f7" at address r 0002, and at the same time a memory special code rxxJ is set at address "0002" in the memory table. The address r 000 is in the memory management table.
2J and data "f7" are set.

Memory special code means that when a breakpoint or tracepoint is set at a memory address,
This is data set in place of the actual data in the memory table.

When accessing memory (table), the memory access module checks whether the data at the address to be accessed is a memory special code, and if it is a memory special code, reads/writes the data in the memory management table. Write 6 Of course, if it is not registered in the memory management table, it will not be regarded as a memory special code, and the data in the memory table will be read/written as actual data. Note that memory special codes are similarly used in registers and in setting breakpoints.

The breakpoint table 431^ stores details of the breakpoint setting status, and an example of the table structure is shown in FIG. 15.

Here, the counter counts down at an initial value (=count) every time a break condition is satisfied, and breaks at "0".

When the format is binary, the mask is r□, ,
This is mask data for supporting both rl and rl.

For example, when (0××1××××), the data is (00
01oooo >, and the mask data is (/O
0/O000), and the access data at the time of simulation execution is (0111/O00), the breakpoint determination unit checks only the bits that are set to "1" in the mask data, and checks whether the break conditions are met. Make a determination as to whether or not. In this case,
Since [IJ is set in the fourth bit of both mask data and access data, the data (000/O000) created by this check is the data (000/O0) of the breakpoint table to be compared.
00), it is determined that the break condition is satisfied.

The breakpoint history file stores the breakpoint table as a disk file.

As shown in FIG. 16, break trace management includes a setting section 4320 called by each set processing section 4312, 4332, and a monitoring section 4321 called by the simulation management section 4/O each time a trace condition is established during startup of the subsystem. It is composed of.

This break trace management function allows you to set and delete breakpoints and trace points in memory and registers, as well as run simulations. When a break trace point is accessed by referring to the memory management table 430^, the trace determination unit 4319.
The trace execution unit calls each break trace execution module.

The setting unit 4320 is a common subroutine group that sets and deletes trace points such as breaks and various traces in the memory management table as debug information using the memory special code shown in FIG.

The monitoring unit 4321 refers to the total flag in the memory management table and calls execution modules such as break and various traces.

By the way, the debugger has various information about the memory and registers of the MPU, such as breakpoint and trace point settings, and naturally accesses the memory and registers.On the other hand, the MPU instruction engine also Accesses memory and registers.

The access service unit 4324 is provided so that the debugger can exclusively manage memory and registers accessed by a plurality of subsystems. By adopting such a configuration, access to memory and registers can be shared, and it is also possible to avoid the inefficiency of having to access the debugger again to determine breakpoints and traces after the MPU instruction engine has accessed it during instruction execution. The situation can be avoided.

Note that when the MPU instruction engine accesses the memory, the /O memory, or the registers, the access service section of the debugger is used instead of directly accessing the memory.

The debugger uses an image of the actual hardware (for example, MPU7
In the case of 8/O memory, it has 64 memory spaces, and separately has a management table in which management information such as breaks and traces is stored.

Since these tables are managed collectively by the debugger, management becomes easy and there is no possibility of mutual influence between subsystems.

Next, Figure 17 shows the effect of the breakpoint function.

This will be explained based on FIG. 18.

FIG. 17 is an inter-module data relationship diagram when executing a breakpoint function.

When you click Set, Clear, or Clear All in the breakpoint setting window, each processing section starts and each process is executed. At the same time, the break trace management setting section starts and the above processing results are stored in the memory etc. management table as debug information. set. On the other hand, the information setting unit updates the breakpoint table based on the set process, clear process, and clear all process.

Also, because the breakpoint is stored in the breakpoint history file by the set process, this history information can be saved in the “Old 5” in the breakpoint settings window.
By specifying "try", the history processing section is activated, the data is read out, and the data is set in the breakpoint table.

After that, when you specify "Exit", the window closing part starts and the breakpoint setting window is closed.
If "T" is specified, each engine is started based on the target program and the simulation is executed. Changes in the state of each terminal of the MPU and LSI due to the start of each engine are managed by the memory management table through the access service section. stored in memory or registers.

Here, the debug information is information for debugger break/trace provided in memory and register management tables, and data indicating whether a break point or trace point is set is set. Further, when each bit is '1'°, it means that the set shown in Table 2 is made.

(Margin below) Table 2 Next, the operation of the break trace function will be explained in detail.

FIG. 18 shows the operation sequence when breaking into the MPU memory space.

By starting the set processing section, the break information set in the break setting window is set in the breakpoint table, and at the same time the setting section, which is a common subroutine for break trace management, is called, and as shown in Figure 14, the break information is set as a breakpoint. Write or read debug information is set in the memory management table.

Then, when the simulation is run, the access
The memory access module of the service section accesses the memory table when the MPU instruction engine executes an instruction, and if a memory special code is set at the address to be accessed, sets a number other than r□ as a flag in the memory management table.

The above flags are set, for example, during write access. Flag nib bag information & 0X5555 During read access Flags - Debug information & 0XAAAA Here, & indicates a logical product, and 0x indicates a hexadecimal number.

The break trace management monitoring unit refers to the memory management table and monitors the set state of the flag. For example, when the debug information is r0203J (4 hexadecimal digits), that is, when the breakpoint is set to read/write,
If there is a read access, the flag becomes rOXO202] and the break determination unit is called.

The break determination unit refers to the breakpoint table every time it is called by the break trace management monitoring unit,
Update count. That is, when executing a simulation, it is determined through the access service section how many times a memory address set as debug information of the memory space is accessed to cause a break.

In other words, each time the break condition is met, the monitoring unit
The break determination section is started, the count value of the counter in the break point table is counted down, and when the count reaches "0", a break is made.

(V-2>)-Race function Set various trace points and execute them.

Trace functions include signal timing trace that displays arbitrary data changes in the target program in a timing chart, timing data trace that traces the transmission and reception of input/output data and communication data, and counts changes in input signals at falling or rising edges. A clock/counter trace that displays the number of counts that have occurred, a running trace that traces changes in arbitrary addresses and registers, a halt trace that displays the state of the target program and MPU before and after conditions are met, and a halt trace that measures the processing time while the target program is running. There is runtime sampling to display.

The trace function can be activated by clicking “'T” in the simulation window.
By specifying "race", each trace that is called by the simulation window event handler and opens the window of the trace selected from the trace window pop-up menu and the window generator that displays the trace window pop-up menu (see Figure 19). It consists of an event handler that calls the window generator.

The basic sequence of various traces is basically the same as the breakpoint function described above, except that the setting contents of each trace window are set in each trace point table, so the explanation thereof will be omitted here.

Note that the module configuration for realizing various trace functions basically has the same functions as those for the breakpoint function described above, such as window generation, drawing, set processing, clear processing, and exit processing. Here, in order to avoid duplication of explanation, the module configuration diagram of each trace is omitted, and the operation of Configuration 1 will also be explained using an inter-module data relationship diagram.

(a>Signal timing trace Figure 20 is a data relationship diagram between modules of signal timing trace.Signal timing trace uses the contents set in the signal timing trace setting window 7/O in the signal timing trace point table 433^
, is registered in the memory etc. management table 430B, and is registered in the break trace management monitoring unit 4322 during simulation execution.
refers to the memory etc. management table 430B and performs access/
The signal timing trace execution unit 4339 is configured to be activated when a flag set by the service unit 4324 is set, that is, when a memory or the like is accessed regarding a signal trace point in a subsystem.

After determining the trace conditions of the signal timing trace point table 433^, the signal timing trace execution section 4339 writes the contents of the trace into the timing data trace data file 433C and displays it on the display section 714.

The signal timing trace setting window 7/O is
As shown in Figure 1, the trace conditions (Memory Address, I/O^d
Memory, I/O from oressRegisterl
Specify either memory or register, input its memory address and register name, and define high data and low data of the data written to the memory address or register name.

Next, after specifying the data format in byte J or hit, click "Set" in the command display section 711, and the set processing section 4332 and information setting section 43 will be displayed.
38 is activated and the set contents are registered in the signal timing trace point table and displayed on the entry point display section 713 at the same time. Up to five trace points can be set as the entry point. In the illustrated example, 1 byte of 0IFA address, 2
Two bits 2 of the FOOO address are entered in the row.

Thereafter, when the simulation is executed, the signal timing trace execution unit 4339 is activated, and after the trace point conditions are satisfied, the trace contents are stored in the signal timing trace data file 433C, and the timing chart of the entry point is displayed on the display display unit 714. is displayed.

The display section 714 is provided with a range specification for displaying the timing chart and a Bose W1 function for temporarily holding the display. The figure shows /
There is an example where the range is O0m5. A history of operations in this window is also stored in the signal timing trace log file 433D.

The signal timing trace point table 433^ is
Specify whether the object to be traced is memory or I/O memory register, determine which address or register number is to be traced, and define the data conditions using high data and low data.

FIG. 22 is an example of the table structure of the signal timing trace point table.

(b) Timing data trace FIG. 23 is an inter-module data relationship diagram of timing data trace.

For timing data trace, when you click the command "5tart" in the timing data trace setting window, the start processing unit 4342 is started, and the timing data trace execution unit 4349 is called by the communication data engine and direct signal engine, and when the simulation is executed, The timing data and manual data input/output by each of the above engines are traced and written to the timing data trace log file 434^, and at the same time, the trace contents are displayed on the display.

As shown in FIG. 24, the timing data trace setting window 720 includes commands such as "'5tart" and "5top" for starting and ending tracing, and the trace contents are displayed on the display section 721.

In the display example of FIG. 24, the ON signal of the gate sensor is used as the input signal to start the simulation /O0++s?
It is input to barley (1O count in M/C), and r00113421. But the same < 20
0+5 (indicates that the M/C received it at the /O0 count.

(C) Clock/Counter Trace FIG. 25 is a data relationship diagram between modules of clock/counter trace.

For the clock/counter trace, the contents set in the clock/counter trace setting window 730 are registered in the clock counter trace point table 435^, and this table is sent to the clock counter trace execution unit 43.
59, counts the set timing (rising or falling) of the set signal name, and displays the result.

The clock counter trace setting window 730 is
As shown in Figure 6, in the parameter display section 731, specify the signal name "Signal Na■e" and the count timing as the high edge "old gh Edge" or the low edge "Low Edge" as the trace condition, and select "Set". ”, the set processing section 4351
．． The information setting section 4352 is activated and registers the above trace conditions in the clock counter trace point table 435^, and at the same time displays the setting contents (trace points) on the entry point display section 732.

In the display example shown in Figure 26, the high edge of the machine clock is set as the entry point, and the count value is 1.
It shows that the count is 20.

The clock counter trace point table 435^ is composed of a signal ID, a signal name, a count condition, and a count value, and indicates a change from high to low (high edge) or a change from low to high (low edge) for each signal. It is set as a count condition.

FIG. 27 is an example of the table structure of the clock count trace point table.

(d) Running trace FIG. 28 is a data relationship diagram between modules of running trace.

The running trace registers the contents specified in the running trace setting window 740 in the running trace table, memory management table 430C, and executes the running trace when the trace conditions are satisfied in the same manner as the signal timing tray 2 described above when the target program is running. The trace execution unit 4369 is activated and writes changes in the data stored in the memory address or register specified by the parameter to the running trace log file 436C and displays it on the display unit.

In the running trace setting window 740, as shown in FIG. 29, a parameter display section 741 displays types such as memory and I/O memory as trace conditions.

Specify from a register, enter the memory address or register name, and display the data of the specified memory address or register name on the display in any data format.
The display format and data display format such as Binary or ``5''
After specifying the screen control to “crawl” or “No 5 crawl” and clicking “Set”, the set processing section 4361 and information setting section 4362
starts and runs the above trace conditions.Trace point table 436^, memory etc. management table 430C
At the same time as registering, the setting contents are displayed on the entry point display section 742. Further, when the simulation is executed, the process of change of the white meat is displayed on the display section 743 as described above.

In the display example of FIG. 29, the execution process of memory address 2300 and the H register is shown. For example, at memory address 2300, data in Hex format (54) is shown.
→(50)→(00).

FIG. 30 is an example of the table structure of the running trace point table.

(e) Holt trace FIG. 31 is a diagram of inter-module data relationship of Holt trace.

Holt trace is set to 7 in the Holt trace settings window.
50. Holt trace point type and contents, read/write type and contents, data format, trace mode, trace count, AND/OR condition specification for combining multiple trace conditions, etc. The break trace management monitoring unit 4324 refers to the memory management table 437^ and the memory etc. management table 430D during simulation execution, and starts the halt trace execution unit 4379 if the debug information is accessed.・Holt trace point table 43 based on the
After determining the trace conditions registered in step 7^, if the trace conditions are satisfied, the contents of the trace are stored in the Holt trace log file 437C and displayed on the display section 753.

As shown in FIG. 32, the Holt trace setting window 750 specifies the type of trace condition from memory, I/O memory, or register in the parameter display section 751, and
Enter the memory address and register name. and,
Regarding data, specify whether to read or write, input the data value, and specify the data former. Furthermore, one of "Formarcl", "Back", and "Center" after the above trace point is specified as the trace mode.

That is, in forward tracing, the state of the processor after the trace condition is satisfied is captured into the trace buffer, and when the buffer becomes full, the trace is terminated. Furthermore, in center tracing, tracing is performed so that the position where the tracing condition is met is the midpoint. Furthermore, the backtrace traces the state of the processor before the trace condition is satisfied in the same way as above.

Next, to specify the trace count, input the number of times the trace condition is satisfied. Also, options include combinations of multiple trace conditions.

Specify using Or'°.

&nd'' starts or ends tracing according to the trace mode when all of the trace conditions integrated thereby are satisfied.

The OR “'Or” starts or ends tracing according to the trace mode when any of the trace conditions integrated thereby is satisfied.

After setting each of the above parameters, click "'Set" to start the set processing section 4371 and information setting section 4372, and convert the above trace conditions to the halt trace point table 437^, debug information, etc. to the break trace. At the same time as registering in the memory management table 430D through the management setting section 4320, the setting contents are displayed on the entry point display section 752. When the simulation is executed, the state of the processor is displayed as a trace on the display section 753 according to the set trace mode.

In the display example in Figure 32, ■/O address r 0FFC
” is read, or the I/O address ro023. "53 indicates that tracing will start when 20J is written."
" and "20" are HEX data.

The display section shows the process executed by the processor after this condition is met.

FIG. 33 is an example of the table structure of the Holt trace point table.

(f) Runtime sampling FIG. 34 is a data relationship diagram between modules for runtime sampling.

Runtime sampling measures and displays the processing time while the target program is running, so the start point of the process measured in the runtime sampling setting window 760
tart Trigger” and end point “EndTrig”
ger" with addresses, register names, read/write access types, their data, and data formats. Register these contents in the runtime sampling table 438^, memory management table 430E,
During simulation execution, the break trace management monitoring unit 4321 refers to the memory etc. management table 438^ in the same way as the halt trace described above, and if the trace conditions are accessed, the runtime sampling execution unit 4389 determines the trace conditions in the runtime sampling table. conduct. If the runtime sampling conditions are met, the measured value of the processing time for the specified section is stored in the runtime log file 438C, and the display section 7
The maximum, minimum and standard processing times are displayed at 63.

The runtime sampling settings window 760
As shown in Figure 5, the starting point of the processing time you want to measure (5ta
rt TriFIger), End Trigg
Parameters are provided for setting the pair &(data) to be er). As for the trace conditions for each trigger, after setting the type data format etc. and inputting the contents in the parameter display section 761, as with each trace described above,
When you click “pply”, the apply processing section 4381
, the information setting unit 4382 starts up and stores the settings of the start point and end point in the runtime sampling table 438^,
In addition to being registered in the memory etc. management table 43E, each trace point of the start point and end point is displayed on the entry point display section 762.

When the simulation is executed, the processing time between the set trace points is displayed on the display section 763 in the three forms described above.

In the display example in Figure 35, the memory address "0F/O"
After reading “53” at the memory address r
It shows the processing time until "20" is written to 0FFO. Here r53. , r20. is HE
This is X data. The display shows that the maximum processing time is 122 μs and the minimum /O5 μs, and that the standard processing time is 120 AZ seconds. Note that N-3 is the number of samplings.

FIG. 36 is an example of the table structure of the runtime sampling table.

(V-3>Memory register setting display function This function includes
Memory dump to display the contents of memory, show file to display the contents of files.

There is a set clear to display and modify the contents of memory, etc., and a simulation state to display the current settings or specified simulation information.

Figure 37 shows 'D' in the simulation window in Figure 0, which is the module configuration for realizing this function.
isplay/Modify”, the window generation unit 4390 starts up and creates the window table 4.
The above-mentioned processes in step 39Δ are displayed in a pop-up menu 800 shown in FIG. When an item on the pop-up menu is selected, the window management unit 430 calls the event handler 439, starts processing related to the specified item, and opens a dedicated window.

The module structure of each function is basically the same as the break trace function, with command functions provided in each window, an execution processing section activated by parameter settings, and output from each processing section. It is equipped with a window drawing section for displaying on the display section. Here, the explanation of the module configuration of each function will be omitted, and each function will be explained in each window. After setting '5tart Address', 'End Address' and display format, 'D
ump”, the above settings are processed and displayed on the display section 812.

The show file function displays the contents of the file as specified by the parameters in the show file setting window 820 shown in FIG. 40.

The set clear function displays the contents of registers and memory in the format specified by the entry format parameter by setting ="Display" in the set clear setting window 830 shown in FIG.
fy” changes its contents in the same way as above, and “R
"ead" reads the registers in the same way as above, "'Fill" changes the memory contents in the range specified by the parameter to the specified data, and "'Re5et" reloads the target program. The above settings are displayed in the parameter display section 831.
is set.

When changing the contents of the memory register using “Md1fy”, “Fill”, “Read”, etc., the changed contents are input into the entry area display section 832. The display section 833 shows the modified results and “Display”.
” Output etc. for the command will be displayed.

The simulation state function displays information such as the CPU name, product name, machine layout name, timing data name, and simulation conditions on the display section 841 in the simulation state window 840 shown in FIG.

(V-4) Machine layout 6 displayed in the monitoring window 603 of the monitoring function simulation window (see Figure 5)
05, the changing state of each signal is displayed in real time.

FIG. 43 shows a module configuration for realizing this function. Window drawing section 4600 displays signal data on a monitoring window.

The pop-up menu generation unit 4602 generates the signal mark 6
By specifying 07, a signal level pop-up menu (see FIG. 46(b)) is generated. The signal level of the signal mark is selected when controlling the level of the input signal during manual operation.

When the state of the direct signal changes due to activation of the direct signal engine 444, the signal data control unit 4602 refers to the signal layout table 461Δ, and if the signal is registered, the signal data table 4
Based on the high/low information of the signal stored in 61B, the display of the signal mark for the information is controlled.

FIG. 44 shows an example of the structure of a signal layout table, and FIG. 45 shows an example of the structure of a signal data table.

Next, window operations for the monitoring function will be explained.

FIG. 46 is a window related to the signal table.

'Set UP' in simulation window 600
When , a setup pop-up menu 620 consisting of machine layout and target program signal table is displayed as setup items. When "Signal Table" is specified in this menu, a signal table pop-up menu 630 is displayed, and the signal name selected from this menu is displayed on the machine layout according to the predefined machine layout and signal layout. Here, if manual is selected, the level of each signal mark can be selected from the signal level pop-up menu 640. Note that the signal level can only be selected for input signals of direct signal data.

(V-5>Setup function This function is for machine layout, target program,
Load and display the signal table.

In the simulation window 600, click “Set up”
” in the setup menu (see FIG. 46) that is opened, and the items selected from the individual menus that are opened are loaded and displayed.

The machine layout setup function has a module configuration shown in FIG. 47, and when a machine layout is specified from the machine layout setup menu 650 (see FIG. 48(a)), the event handler 461 starts the file load section 46/O. It starts up, loads the machine layout file 460^ and the signal layout file 460B, stores signal layout data for positioning signals on the machine layout in the signal layout table 461^, and stores the data of the laid out signals in the signal data table 461B. Store in. The data in each table is used in the monitoring function.

The target program setup function has the module configuration shown in FIG. 49, and when a target program is specified from the target program setup menu 660 (see FIG. 48(b)), the event handler
62 starts the file loading unit 4620 and loads from the target program file 462^.

The signal table setup function is configured (apply processing) by specifying signal table data from the table window shown in Figure 46, and also performs reset processing to return the contents specified by parameters on the window to initial values. Abort processing can be performed to invalidate changed data.

The module configuration includes a module for loading signal table data in the same way as the target program setup function, and also includes modules for executing apply processing, reset processing, and abort processing.

〔Effect of the invention〕

As described above, according to the present invention, the following effects are expected.

■By simulating the circuit operation of the LSI around the MPU, it is possible to
You can check the signal status at each terminal of the PU.

■If the target system is composed of multiple modules, the communication data necessary for each module's MPU can be supplied as data using software without using electric circuit boards or mechanical parts. Allows independent debugging.

■Debugger has break, trace, and monitoring functions.

It is equipped with various functions that provide a debugging environment such as setup and memory/register display settings, so it is possible to perform multifaceted simulations of various recording devices.

■The access service module commonly manages access to memory and registers from the subsystem and the debugger, which is inefficient as the debugger must access it again to determine breakpoints and traces after the subsystem has accessed it. situations can be avoided.

■The debugger is equipped with a memory management table that stores management information such as breaks and traces, making management easier and preventing interference between subsystems.

[Brief explanation of drawings]

Figure 1 is a block diagram showing the overall configuration of the simulator of the present invention, Figure 2 is a schematic diagram showing the hardware configuration of the simulator, Figure 3 is a configuration diagram of the simulator window, and Figure 4 shows the operation sequence of the simulation. Figure 5 is a configuration diagram of the simulation window, Figure 6 is a block diagram showing the configuration of the simulation engine, Figure 7 is a diagram of data relationships between each engine, and Figure 8 explains synchronous control of each engine. Figure 9 is a diagram explaining the startup of each engine, Figure /O is a module configuration diagram for realizing the breakpoint function, Figure 11 [J is a configuration diagram of the breakpoint setting window, Figure 12 is a register In the diagram explaining the table structure, <a
> is a register relationship table, (b) is a register management table, Figure 13 is a diagram explaining the memory management table structure,
Figure 4 is a diagram explaining trace point settings, Figure 15 is a structure diagram of a breakpoint table, Figure 16 is a configuration diagram of break trace management, Figure 17 is a diagram of inter-module data relationships of breakpoint functions, and Figure 18 Figure 19 is a diagram explaining the operation sequence of break trace management, Figure 19 is a diagram showing the trace pop-up menu, Figure 20 is a diagram showing the data relationship between modules of the signal timing trace function, and Figure 21 is a diagram of the signal timing trace setting window. Figure 22 is a diagram of the structure of the signal timing trace point table, Figure 23 is a diagram of data relationships between modules of the timing data trace function, Figure 24 is a diagram of the configuration of the timing data trace setting window, and Figure 25 is a diagram of the clock counter. Inter-module data relationship diagram of the trace function. Figure 26 is a configuration diagram of the clock counter trace setting window. Figure 27 is a structural diagram of the clock counter trace point table, i@28e is a data relationship diagram between modules of the running trace function, Figure 29 is a configuration diagram of the running trace setting window, and Figure 30 is a structural diagram of the running trace point table. , Figure 31 is a diagram of inter-module data relationship of the Holt trace function, Figure 32 is a configuration diagram of the Holt trace setting window, Figure 33 is a structural diagram of the Holt trace point table, Figure 34 is inter-module data of the runtime sampling function. Related diagrams: Figure 35 is a configuration diagram of the runtime sampling setting window. Figure 36 is a diagram of the structure of the runtime sampling table. Figure 37 is a diagram of data relationships between modules of the memory/register setting 9 display function. Figure 38 shows the display/modify pop-up menu, Figure 39 shows the configuration of the memory dump setting window, and Figure 4 shows the configuration of the memory dump setting window.
Figure 0 is a configuration diagram of the show file settings window, Figure 41 is a configuration diagram of the set clear settings window, and Figure 4
Figure 2 is a configuration diagram of the simulation state window, Figure 43 is a diagram of data relationships between modules of the monitoring function, Figure 44 is a diagram of the structure of a signal layout table, Figure 45 is a diagram of the structure of a signal table, Figure 46 (a) 46(b) is a diagram showing the pop-up menu of the signal level, FIG. 47 is a diagram showing the data relationship between modules of the machine layout setup function, and FIG. 48(a) is a diagram showing the configuration of the window related to the signal table. Figure 4811J(b) is a diagram showing the layout setup menu, Figure 4811J(b) is a diagram showing the target program setup menu, Figure 49 is a module configuration diagram of the target program setup function, Figure 50 is the basic configuration of the recording device. Block diagram, 5th
Figure 1 is a diagram explaining the development procedure of a recording device, Figure 52 is a schematic diagram of a copying machine equipped with an automatic conveyance device and a sorter, Section 53 is a schematic diagram of an automatic document conveyance device, and Figure 54 is a schematic diagram of a copying machine equipped with an automatic document conveyance device.
FIG. 2 is a block diagram showing the configuration of the copying machine; Section 55 is a configuration diagram of the simulator kit; FIG. 56 is a configuration diagram of the display panel section; FIG. 57 is a diagram explaining problems in the debugging process.

Claims (1)

[Claims] (1) MPU that executes the target program, peripheral L
A configuration unit that defines the hardware information of the target system including SI and generates data indicating the state of change of signals to the input terminals of the MPU, and software that uses the electrical and mechanical elements that make up the target system as an engine. A subsystem is constituted by a simulation engine unit that performs a simulation based on the configuration information, and a simulation engine controller that synchronizes the startup time of each engine and executes the simulation based on the configuration information, and a simulation engine controller that performs a simulation by synchronizing the startup time of each engine based on the configuration information. The memory of the engine section, I
/O A breakpoint function and target program that has an access service section that updates the state of memory and registers and performs a set operation under each setting condition of break or trace, and breaks when the setting conditions are satisfied. A simulator for a recording device, comprising: a debugger having at least a trace function for outputting the execution process, any data changes, and the state of the target program or MPU before and after the establishment of setting conditions. 2. The recording device simulator according to claim 1, further comprising a simulation window for controlling execution of simulation and operating environment settings, and a debugger window for displaying condition settings for debugging functions and trace contents. (3) The recording device simulator according to claim 2, wherein a debugger execution control command for opening a debugger window is provided in the simulation window. (4) A set processing unit that registers break or trace conditions in a table, a break trace management setting unit that is called during set processing and registers debugger information in a memory management table, and an access service unit that a break trace management monitoring unit that monitors break trace or break condition fulfillment information set in a memory management table; and a break trace management monitoring unit that is called by the monitoring unit after the condition is satisfied and determines the break or trace condition registered in the table; A debugger comprising a break trace execution processing unit that executes a break or trace after the condition is met. (5) signal timing chart trace processing means for displaying a timing chart of arbitrary data changes in the target program on a signal timing trace window;
A timing data trace processing means that displays input/output of timing data and communication data in a timing data trace window, and a timing data trace processing means that displays input/output of timing data and communication data in a timing data trace window, and
Or a clock counter trace processing means that counts at the rising edge and displays it on a clock counter trace window, a running trace processing means that traces the execution process of the target program and displays it on the running trace window, and a target program and MPU before and after the trace condition is satisfied. Claim 1: The debugger comprises a trace function configured by a halt trace processing means for displaying the state of the trace in a halt trace window.
Simulator of the recording device described. (6) Set and clear the memory dump processing means that displays the memory contents in the memory dump window, the show file processing means that displays the source files and assembly list of the target program in the show file window, and the contents of the target program, registers, and memory. 2. The debugger includes a register/memory display setting function configured by set clear processing means for modifying on a window and simulation state processing means for displaying set or designated simulation information on a simulation state window. Recording device simulator. (7) A machine layout processing means that loads a machine layout file and displays it on a monitoring window based on this machine layout data, a target program processing means that loads a target program, and a signal table that loads a signal table and uses this signal table as a signal. 2. The recording device simulator according to claim 1, wherein the debugger has a setup function configured by signal table processing means for displaying on a table window and specifying display or non-display of signals in the signal table. (8) The debugger is equipped with a monitoring processing means that is called by the activation of the direct signal engine and displays the signal status stored in the signal data table for the signals defined in the signal layout table on the machine layout diagram in real time. 2. A simulator for a recording device according to claim 1. (9) Equipped with a means for displaying a signal level menu by specifying a signal mark on the machine layout diagram and a means for setting the signal level selected from the menu, making it possible to control the input signal level during manual operation. A simulator for a recording device according to claim 8.