JPH03125233A - Recording device simulator and its simulation engine - Google Patents

Abstract

PURPOSE:To simulate a hardware environment in terms of software by providing simulation engine controller which secures the synchronization of the start time among engines based on the configuration information and carries out the simulation. CONSTITUTION:An engine have the earliest request among the action timings of engines 442-447 and another engine having a start request are started based on the system time outputted from an engine controller 441. Then each of engines 442-447 carries out the simulation of the input/output of the external signals of an MPU, an LSI, a sensor, etc., and the transmission/reception of the communication data, etc. For the system time, the time most approximate to the present system time is set among those times of the action timing requests informed to the controller 441 from the engines 442-447 and the times contained in a start request control table. Thus the system time serves as the reference time for synchronization among those engines. Thus a hardware environment can be simulated in terms of software.

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 a simulator) suitable for executing simulations of external signals from LSIs, sensors, etc., communication data with other MPUs, and the like.

[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 to respond to these changes is extremely dependent on the introduction of MPUs and their software, and as the scale of software increases year by year, the development of this software has come to account for a large portion of the total man-hours in product development. It's coming.

Therefore, increasing the efficiency of software development has become a top priority in product development, but in software development using conventional methods, in the debafugu process,
Because an actual electrical circuit board or recording device is required, even if the software design is completed early, the next device or
There is a problem that it cannot proceed to the blowfish process. 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 necessary to increase the efficiency of software development, which is not limited to software-only issues.

Furthermore, in debafugu on electric circuit boards and actual machines,
When a problem occurs, even if it is a hardware problem, the problem is often solved using software due to development costs and delivery schedules, which increases the burden on software engineers.

The development of the recording device will be explained below.

FIG. 79 shows the basic configuration of the recording device. In FIG.
120 and an electric circuit board 130 that provides an interface between the two. The device main body 100 is provided with a sensor for detecting an operating state, a switch for inputting an instruction from a control panel, and the like. 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 M P tJ 120 is supplied to the electrical circuit board 130, and the electrical circuit board 1
30 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 the MPU with circuits outside the MPU, and is used to precisely operate mechanical systems such as motors and threads of the equipment. It produces the necessary signals.

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.

As shown in Fig. 80, the development of the recording device described above can be roughly divided into three departments: mechanical design for the main body of the device, electrical circuit design for the hardware of the MPU and peripheral LSI, and software development for the program that controls the operation of the device. Proceeded by. 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 was to run the developed program on the completed prototype machine and see how it looked! This is a so-called actual machine test to confirm operation.6 Normally, the work of each of the above departments is carried out in parallel, but the development tempo during this period 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 fullest use of debugging through emulation testing, and software bugs cannot be removed before moving on to actual machine testing. As a result, basic software troubles occur one after another when debugging actual devices.

The development of a control program for a recording device will be described below using a copying machine as an example.

FIG. 81 shows a schematic diagram of a copying machine equipped with an automatic document feeder and a sorter.

In the figure, an automatic document feeder 140 is disposed on the top surface of a copying machine main body 100 for automatically transporting a document onto the platen glass of the copying machine main body.

A sorter 160 for sorting the sheets after copying and discharging them into bins 161 is arranged on the side of the main body of the copying machine.

Inside the copying machine body 100, a photosensitive drum 101 that rotates in the direction of the arrow is arranged, and around this photosensitive drum 101, a charging device 102, a developing device 103, a transfer device 104, a peeling device 105, a cleaner 106, etc. are sequentially installed. It is located.

Further, on the top of the copying machine main body 100, a document (not shown) is provided.
A light source 111 for illuminating the document, a mirror 112 for focusing reflected light from the original onto the photosensitive drum 101, and lenses 1 and 3 are provided, and these constitute a scanning optical system. By using this scanning optical system, the charger 1 is
An electrostatic latent image is formed on the photoreceptor drum 101 charged by the electrostatic charge 02. This electrostatic latent image is
03, it is converted into an m-image as a toner image. At the same time, the first 1st page stores paper of different sizes. A sheet of paper from one of the second and third trays 121, 122, and 123 is conveyed toward the photoreceptor drum 101 by the paper feeder 121, and the toner image on the photoreceptor drum is transferred onto the sheet by the transfer device 104. 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 101. After the transfer, the paper is peeled off from the photoreceptor drum 101 by a peeler 105, and transferred to the conveyor belt 12.
5, the toner image is sent to the fixing fi 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 photoreceptor drum 101 is again conveyed via the photoreceptor drum 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, and then the copying machine main body 10
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. 82, the original is conveyed to a prescribed position 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 a prescribed position 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 photosensitive drum 101 to scan the original.

As a result, an electrostatic image is formed on the photoreceptor drum 101, and then the well-known development, transfer, peeling, fixing, ejection, etc.
Each process such as sorting is performed.

Further, the copied document is removed from the platen glass 144 by a conveyor belt 145, scooped up by a gate claw 146, and discharged by a document conveyor roll 147 to a document receiver 148 at the top of the automatic document feeder 140.

When copying work is performed in this manner, each step is performed without detecting the operation of each device and the state of paper passage.

In a copying machine equipped with peripheral devices such as the automatic document feeder 140 and 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.

In addition, each device is controlled by MP[J, 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. 83, the copying machine main body 100 is composed of a copying machine mechanism section 131, an MPU 132, and an electric circuit board 133 that provides an interface between the two. Further, 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.
Data such as number of copies and messages are displayed on console panel 1.
34 and displayed by a lamp, light emitting diode matrix, etc.

Further, peripheral devices for the copying machine main body 100, that is,
The above-mentioned automatic document transport device 140, sorter 160, etc. have similar configurations. For example, the automatic document feeder 140 has an automatic document feeder phase 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. 84 is used as a debugging development tool. This is a tool for performing the emulation test mentioned above.

The simulator kit 170 simulates the actual copying machine mechanism 13.
1 and the input system and output system of the console panel 134 are replaced with a switch panel section 171, a display panel section 172, and a pseudo console panel section 173, and the MPU socket on the electric circuit board 133 is connected to the Targetera) M P
In-circuit emulator 17 by replacing 0132
4 (indicated by ICE in the figure).

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 a, the output from the switch 171& is supplied as a 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 simplicity.

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. 85, 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 a black circle in the figure) is installed, and a motor,
A plurality of red lamps 172b (indicated by white circles in the figure) that display the status of output components such as solenoids are arranged at positions corresponding to each of these components, and are given names. For example, display 18 of the top paper tray
A red lamp 172b labeled FEED-SQL indicates the operation of the feeding solenoid, and a blue lamp 172a+ labeled FEEDOUT-SNR indicates whether the paper is being fed. In addition, on the input side of the photosensitive drum display 181, there are a register that determines the timing to start transporting paper, a red lamp 172b2 that indicates the operation of a solenoid named REG-SQL that controls the storage gate, and a registration gate. REG-SN indicating whether paper is being fed to
A blue lamp 172az named R is provided, and a FUSIN-5N 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 172as labeled R is provided.

Also, FSROtlT- is displayed on the output side of the fuser display 182.
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 17 or initially loaded data to the electric circuit board 133.
The data transmitted to and 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
72b.

Virgin computer control mode is the 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 86 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 actual machine tests, but emulation tests account for approximately 58.1 of the total number of troubles caused by bugs.
%, which is approximately 42.9% in the actual machine test. 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 involves determining the cause and determining how to share countermeasures. 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 a device body (mechanical part), and changing the design of an electric circuit board or device body after completion is particularly difficult in terms of time constraints and costs in the development schedule.

Further, 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 lies in the program, the electric circuit board, or the device itself. Software engineers also identify the cause of this problem. Particularly when a product is nearing completion, situations often occur that require software solutions, including these hardware problems.

Therefore, there has been a problem in that this type of device development requires a great deal of effort from software engineers.

In order to solve these problems, the key is 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 must:
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, timing data is required that corresponds to the change in the output of a sensor disposed in a mechanical part to the specific operating time of the device.

Timing data is created from a timing chart, but the creation of this timing chart is entirely 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 fifl[portion] 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 begin until the electrical circuit boards for all modules are completed, and even if electrical circuit boards are made for debugging, there may be changes in the circuit design. In this case, it is necessary to produce an electric circuit board each time, 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.

■Timing data for all test modes, including abnormal systems, can be created, 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 target programs such as MPU and peripheral LSI 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 alone.

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

■If the target system consists of multiple modules, each module can be debugged independently by supplying the necessary communication data to the MPU of each module from outside without using the electrical circuit board or mechanical parts. can do.

■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 sensors, but also defines abnormal conditions, i.e. Assuming abnormalities in sensors, solenoids, motors, etc. in advance,
It can also be defined based on the output signal of the sensor 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 particularly solves problems related to the simulation engine.

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

Another object of the present invention is to provide a simulator that can perform tests in a multiprocessor system environment.

Another object of the present invention 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 performed on a window.

Another object is to provide a simulator that can perform tests by supplying timing data for all test modes including abnormal systems.

Still another object is to provide a simulation engine necessary for simulating a recording device to be developed using software.

[Means for Solving the Problems and Their Effects] 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 provides information on input terminals of the MPU. a configuration section that generates data indicating signal change states; a simulation engine section that uses software to simulate the electrical and mechanical elements constituting the target system as an engine; The system includes a simulation engine controller that executes simulation by synchronizing engine startup times.

The simulation engine section includes a clock engine, an MPU engine, and an LSI circuit engine.

The target system is composed of a direct signal engine, and a communication data engine that supplies communication data to the LSI circuit engine and the MPU engine with respect to external modules configured by other MPtJs. Signal engine, MP
The U port engine and the LSI circuit engine are associated with each other by a state buffer that stores the state of a terminal or signal, and a status change list that notifies the Ike engine of a change in the state.

Also, there is 1 between the MPU port engine and the LSI circuit engine.
A communication data list that informs communication information that informs communication data, and a transmission/reception buffer communication that informs communication data engine of transmission/reception information from the engine to the communication data engine or from the communication data engine to the engine, and LS.
They are related by a sending/receiving buffer configuration table that defines sending/receiving data buffers corresponding to the I engine.

Further, the MPU port engine and the MPU instruction engine are associated by an interrupt event list that informs the MPU instruction engine of interrupt events that change the state of the MPU port.

In addition, this simulator is provided with an operation timing list that records the next operation timing of each engine and a startup request control table that records the startup of an engine whose operating environment has been changed by another engine, and the list and table are used by the simulation engine controller. The controller is configured to refer to the system time, set the system time for the engine whose startup time is closest to the system time managed by the controller, and start the engine.

This simulator also supports simulation execution control,
It is equipped with a simulation window section for operations such as environment settings, monitoring, data input, and corrections.

The simulation window section is composed of a simulation window in which options for performing simulation operations are provided, and windows for individual setting, selection, and display that are opened depending on the options.

In addition, the simulation window and individual setting windows have pop-up menus that display multiple data prepared for machine layout, target 10 grams, signal tables, direct signal data, and communication data. There are options for configuring settings according to the simulation.

Each engine has the following characteristics:

The clock engine counts clocks at the stage where the clock element wants to change the state of the output terminal, and outputs operation instructions for elements with clock input to each LSI according to this count, and the LSI
The clock engine timing notification macro unit notifies the clock engine of the timing at which the tarok count value changes based on the output change timing data of the clock signal output from the circuit engine and the MPU port engine. By referring to the written clock terminal configuration table, change the clock terminal state to notify that the tarok signal state has changed to an LSI that has a clock input that is connected to a tarok whose output terminal will change in the nearest future in the output change timing. Create a list.

The direct signal engine has a timing data signal name table that stores data in which direct signals D and timing data signal names are associated with each other, and a direct signal I
The LSI is equipped with a direct signal name table that stores data that associates D and direct signal names, reads direct signal data whose state has changed, and indicates that there has been a state change based on both tables. LSI for informing each LSI engine of the circuit engine
A direct signal engine that creates a destination direct signal state change list, stores the direct signal data in a direct state buffer, and notifies the direct signal engine that there has been a change in the state of a direct signal in the LSI engine using a direct signal ID. The target system includes a destination direct signal state change list and a direct signal name table in which data in which direct signal IDs and direct signal names are associated are stored, and the target system operates based on the table by referring to the state change list. Executes processing to display the status on the screen.

The LSI circuit engine is an LSI circuit engine provided for each LSI.
LS with startup requests based on information such as engine, terminal status changes input from each engine, test data, etc.
It consists of an LSI request list in which I engines are organized by circuit level, and an LSI engine driver that refers to the LSI request list and sequentially starts up LSI engines at the same circuit level. By starting the LSI engine, other L
When the state of the SI engine terminal changes, the corresponding LS
A request list is created regarding the I-engine startup request.

In addition, when the LSI engine is started, an MPU pin status change list addressed to the MPU is created to notify the MPU port engine of MPU pin information whose status has changed, and the LSI engine
The MP[J terminal output driver started by the I engine driver refers to the MPU configuration table in which MPU terminal information is stored and creates an MPU terminal status change list addressed to the MPU.

Furthermore, the LSI circuit engine includes an LSI engine that is controlled by the I10 instruction of the MPU, and is equipped with an MPU-I/O processing section that corresponds to a specific address of the MPU.
The I/O processing driver activates the MPU-I/O processing section according to measures from the MPU instruction engine, and controls writing of data to the address.

The communication data engine includes a communication data engine transmitting section that transmits received data to the destination engine, and a communication data engine receiving section that receives the transmitted data from the destination engine and processes the display of the data on a window. and a communication data engine management section in which the engine controller refers to an operation timing request list and an activation request control table and activates either the receiving section or the transmitting section according to the request data.

The communication data engine transmitter includes a protocol data transmitter that transmits communication protocol data, a mode data transmitter that transmits mode data, and a transmitter controller that controls each of the transmitters.

[For production]

Based on the system time output by the engine controller, the engine that is requested or other engines that are requested to start are started at the earliest time among the operation timings of each engine. And each engine is an MPU,
Executes a simulation of input/output 2 communication data transmission/reception of external signals such as LSI and sensors.

The above system time is based on the operation timing request list that the engine controller is notified of from each engine,
The time is set and advanced to the time closest to the current system time among the times in the startup request control table.
This is the reference time for synchronizing each engine.

That is, in the engine to be operated, a system time notified from the engine controller is set, and this system time is advanced as the engine internal system time.

On the other hand, after each engine executes a predetermined operation at the notified time, each engine writes the next operation timing in the operation timing request list.

The engine controller first looks at the operation timing list, calls the Blistage Black Engine, and then
The I engine clock processing section and the MP port engine clock processing section are activated to update the internal counter of the LSI and calculate and set the frequency clock count used by the MPU port engine.

When the MPU instruction engine is called, it refers to the interrupt event list and if there is an interrupt event, the MP
Along with executing the U instruction, the LSI engine MPU I10 processing section and the MPU port engine I10 processing section are activated by the execution of the I10 instruction.

The LSI engine MPU I10 processing unit transfers the location information of the configuration table containing the configuration information of the terminals of the LSI to the LSI for each circuit level in order to inform each LSI engine of changes in the terminals that occur during the simulation of the LSI circuit engine. Created as a request list.

On the other hand, the MPU port engine I10 processing section
The I10 processing unit executes the port operation in response to the I10 command to the port. Based on the result, the I10 processing unit executes the LSI circuit engine to notify the LSI circuit engine of the MPU terminal whose state has changed.
Create a list of MPU terminal status changes addressed to SI.

Next, when the system time is set in the clock engine, the clock engine starts and refers to the clock terminal configuration table and the MPU built-in clock configuration table to inform the LSI circuit engine and MPtJ port engine of changes in the count number. A list of the status of the clock pins destined for the LSI and a list of changes in the status of the clock pins destined for the MPLI are created to notify the real value clock signal that has changed, and the count value of the real value clock signal whose state has changed is stored in the clock count state node. 〈・Clock count station for sofa and MPU Stored in the sofa.

Similarly to the above, when the direct signal engine is activated by the engine controller, an LSI directed signal state change list is created to notify the LSI circuit engine of the direct signal whose state has changed.

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

When the communication engine is started in response to a request from the LSI circuit engine or MPU port engine, it checks the reception or transmission buffer communication information file to confirm whether the communication destination device is ready for communication, and then configures the transmission and reception buffer configuration. Refer to the table to create a list of received data addressed to the SI and a list of received data addressed to the MPtJ to notify the LSI circuit engine and MPU port engine that there is received data and the receive data buffer in which the received data is stored. In addition to informing each of the engines mentioned above, the data communication time is calculated from the transmission or reception time of 1 byte. This information is displayed at the user's request.

Then, when the MPU port 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 station sofa, and based on this clock signal. LSI destination MPU for notifying the LSI circuit engine of the MPU terminal whose state has changed by referring to the received data list and the MPU destination terminal status change list.
Create a terminal state change list. Here, if there is a change in the state of a port that performs interrupt processing among the MPU ports, an event corresponding to the change is written in the interrupt event list.

Also, if there is data to be sent to the communication data engine,
Activates the serial interface transmission operation unit called by the MPU instruction engine to create receive buffer communication information to notify the communication data engine of transmittable information and 1-byte transmission time, as well as to inform the communication data engine of the transmission buffer of the destination and the transmission time. , create a transmission data list in which transmission data and transmission information are arranged, and send it to the communication data engine.

Furthermore, when the LSI circuit engine is started, the clock terminal state change list addressed to the LSI identifies which LSI the clock terminal whose state has changed is connected to by referring to the clock terminal configuration table.
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, a receive buffer communication information file similar to the above is created, and the transmit buffer of the destination, the transmit time, and the transmit data Create a transmission data list in which the transmission information consisting of is arranged and send it to the communication data engine. Then, connect the MPU terminal whose state has changed to M
An MPU terminal state change list addressed to the MPU is created to inform the PU port engine, and a direct signal state change list addressed to the direct signal engine is created to inform the direct signal engine of a direct signal with a state change.

In this way, the simulations run on each engine are dynamically displayed in the machine layout on the window,
It is possible to understand the operating status of the target system.

〔Example〕

Embodiments of the present invention will be described in detail below with reference to the drawings.

Prior to the explanation, in the following explanation, which shows a table of contents for the explanation of this embodiment, (I) to (■) refer to the control system of the recording apparatus to which the present invention is applied (hereinafter referred to as the target system). This is a section that provides an overview of software simulation (hereinafter referred to as simulation) and an overview of the overall configuration of a simulator that executes the simulation, and within that configuration, the section that describes the present invention in detail is (■). .

Table of contents (1) Overview of simulation (+-1) Operational comparison of hardware and software and scope of simulation (1-2) Simulation method (II) Overview of simulator (U-1) Glossary (II-2) Software configuration (It-3) Hardware configuration (II-4> Effect of simulator (I[[) Example of simulator and its engine (
III-1) Simulation management (III-2) Simulation window (I[[-3) Simulation engine (!ll-4) Engine operation (1-5> Engine initialization <I[I-6> Engine controller (Tozu) LSI circuit engine (III-8) Clock engine (II [-9) Direct signal engine (III-10)
) Communication data engine (Ill-11,) MPU instruction engine (1-12) M
PU Port Engine (I [[-13) Monitoring] The present simulator will be described below.

N) Overview of Simulation (1-1) Operational Comparison of Hardware and Software and Scope of Simulation There are major differences between an actual electrical circuit and the computer software that attempts to simulate it. For example, software cannot perform 29 or more operations at exactly the same time, whereas in actual electrical circuits including LSIs, each LSI operates independently and without cooperation with each other at the same time.

The following describes in detail how to handle this structural difference between hardware and software when realizing a simulator.

■Circuit that does not include a loop When considering the logic circuit shown in Fig. 70, when the signal shown in Fig. 71 (a) AIA2 is input to the input terminal 1.2 of the AND circuit A, the signal timing chart is as follows. Figure 71(b) A3. This is shown in Bl and B2. Here, when considering the propagation delay of the signal in an expanded manner, the signal on the actual hardware is such that element B operates after element A operates, as shown in FIG. 71(b). Recognize.

In other words, if only the changes in the elements are simulated, even if the elements A and B are sequentially processed, the operation is the same as that of the hardware.

Therefore, the simulator simulates the parallel operation of hardware on such an electric circuit by sequential processing derived from the connection order.

■Circuit including a loop For example, in the circuit shown in Fig. 72, the input of circuit A is connected to circuit B.
The input of circuit B depends on the output of circuit A. Furthermore, it is not possible to determine which of circuits A and B will operate first. Therefore, the simulator does not support circuits containing loops because the operation of such circuits cannot be replaced with immediate operation.

■Signal delay Normally, there is always processing time in each element and connection in an electric circuit, and this appears as signal delay time, but it is almost impossible to design a circuit that takes advantage of this delay time. do not have. Therefore, during simulation, it is assumed that there is no state change within the delay time. However, in the circuit shown in FIG. 73, if the delay time is ignored,
The actual hardware shown in Figure (a) is shown in Figure 74 (b).
waveform, and it is not possible to support simulation of circuits that use this waveform.

(1-2) Simulation method ■Target components The target system consists of a mechanical section consisting of actuators, motors, various sensors, switches, etc., an MPU that controls the entire device, and an electric circuit that interfaces between the mechanical section and the MPU. It consists of a substrate. When simulating this target system, the components to be simulated include direct signals that simulate input and output of signals between the electric circuit board and the sensors, switches, motors, etc. installed in the mechanical part, multiple MPUs, etc. In the case of a multi-module with
There are four components: communication data exchanged between modules centered on , various LSI circuits on the electric circuit board, and MPU, which is the core of the electric circuit board.

Table 1 shows a comparison of target components and simulators.

Table 1 - Simulation of the entire target system The actual hardware corresponding to each component of this simulator operates in parallel with each other, as shown in Figure 75 (a). As shown in b), each component is treated as operating sequentially.

■ Direct signal simulation The input signal supplied to the electric circuit from outside is High
/Low binary data is unilaterally supplied to the LSI circuit engine, and input/output with the LSI circuit is simulated. The time resolution of this input signal is 1 See.

■Simulation of communication data Actual hardware handles bit strings, but this simulator does not check whether the LSI itself is operating normally, but rather checks whether the MPU target program and LSI circuit are operating as intended. This is to verify whether there are any. Therefore, communication data is simulated as an operation of supplying a data string in bytes to the communication LSI in the LSI circuit and the communication port of the MPU.

(2) Simulation of an LSI circuit The wiring part of an LSI circuit or a single LSI is simulated by sequentially operating the LSIs in the LSI circuit in the order in which they are connected.

However, it is assumed that the signal has no propagation delay.6 (II) Overview of the simulator (II-1) Explanation of main terms used in this simulator A "module" is a module that is controlled by a program executed by one MPU. It usually means an electrical circuit or mechanical part centered around one MPU.

[Target program] is a user's program that is the target of simulation debugging.

rlDJ is a number-based identifier assigned to each piece of data in order to handle the data in a computer. Here, data with ID will be briefly explained. In addition,
All IDs are O origin.

DEVICE name, DEV IO: Data indicating the device to which the signal belongs, representing LSI name, MPU, direct signal, real value clock, etc.

MPU name, MPU ID: Data indicating the MPU, for example r7810. There is r7811J.

LSI name/LSI name, LSI ID: Used when only LSI is the target.

Sequential number by LSr 2 This is a number given to distinguish between LSrs of the same type.

Terminal name, terminal ID: These are the names and IDs given to the LSI and MPU terminals.

Direct signal name, direct signal ID: Name of the direct signal defined by the user.

Terminal type, terminal type ID: Indicates the type of signal defined by the user in the LSI and MPU setting windows.

10 type, IO type ID: Data indicating signal input/output.

State, state ■D; Represents the state of the signal, high ()
There are three types: light, Log, and None.

Address type, address type ID: Indicates the address type, and there are three types (ROM, RAM, I/C1).

Below are typical IDs used in this simulator.
Table 2 shows.

(Margins below) Table 2 "Unit" is a new concept created to realize LSI circuit simulation of this simulator, and as shown in Figure 76, among the functions of one LSI, The parts that operate independently are divided and named units, and each part is assigned a number starting from O and set as a unit ID. For example, program counter r8253. in the case of,
3i1! Since it has l independently operating counters, the number of units is three. This unit ID is LS
Used in I circuit engines.

The "circuit level number" defines, for example, the order in which signals of peripheral LSIs around the MPU are determined.

For example, as shown in FIG. 76, if the circuit level of the MPU is O, then the LSI connected to this MPU, that is, the LSI whose terminal level is determined by the operation of the MPU,
The circuit level number of is set to 1. Also, assume that the circuit level number of another LSI connected to this LSI is 2. Similarly, a circuit level number is automatically assigned by verifying the configuration.

(I[-2) Software Configuration As shown in FIG. 1, this simulator consists of a simulator management unit 200 that controls the specification of product names 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; and a simulation unit 400 that executes simulation of the target system such as an LSI circuit or MPU. The display window section 500 displays various information about the simulator on a graphic display.

The configuration unit 300 includes an MPU clock,
an MPU information setting section 310 that sets 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. In order to understand the machine clock information setting section 330 to be set and the simulation situation on the screen, there is a schematically drawn recording section! The machine layout setting section 340 arranges marks corresponding to the 10 ports and checks the consistency between the various setting data set. Configuration verification unit 35 that creates various data required during simulation
0 and 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. A timing data creation conversion unit 360 that converts the generated timing data into a format that can be used by the simulator into direct signal data, and other MPs.
It is comprised of a communication data generation unit 370 that defines a communication protocol for communicating with U and sets actual communication data assuming a certain operation mode of the target system.

The simulation unit 400 consists of a simulation management unit, a simulation window unit, a debugger, and a simulation engine, and starts the simulation engine based on the hardware information of the target system defined by the configuration unit.
Test data is supplied to this simulation 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.

(II-3) Hardware Configuration FIG. 77 is a schematic diagram configuring the hardware of this simulator. The central processing unit 10 performs overall control and data processing of this simulator, and this central processing bag W10 includes a main memory 11, a keyboard 13 for inputting various data and instructions via a serial data line 12, and processing results. A display 14 for displaying information such as the like is connected. Also connected to the bus of the central processing unit 10 is a disk device 15 that stores 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 stored in the main memory 1.
1, and the central processing unit 10 uses these software resources to execute necessary processing.

(II-4> Function of simulator Figure 78 is a schematic diagram explaining the function of this simulator. Timing data is generated by the test data generation means 21 based on on/off signals such as sensor signals generated within the recording device. After converting the generated timing data into direct signal data applicable to this simulator, a direct signal data file 22 is created.

The direct signal data is sent to the direct signal engine 23.
The signal is supplied to the LSI circuit engine 24 by the LSI circuit engine 24.

On the other hand, the communication data is used for communication between each of the plurality of modules constituting the target system, and this communication data is generated by the communication data generation means 25, and a communication data file 26 is created.

The communication data is supplied by the communication data engine 27 to the LSI circuit engine 24 and the MPU engine 28 .

The LSI circuit engine 24 and the MPU engine 28 simulate the operation of the LSI circuit and MPU using software, and the hardware configuration of the LSI circuit and MPU, such as the bin arrangement and clock frequency, is determined by the hardware. Software configuration setting means 29
is defined as a hardware configuration file 30, and data from this is supplied to the LSI circuit engine 24 and MPU engine 28.

The clock engine 31 simulates the real clock signal (fixed period pulse) configured by the user and the real clock signal that the MPU engine 28 originally has, and connects the change in clock count with the real clock signal. The LSI circuit engine 24 and MPU engine 28 are notified.

The simulation engine controller 32 manages the execution of the simulation based on the time period of each engine. That is, based on the system time output by the simulation engine controller 32, the engine that is requested at the earliest time among the operation timings of each engine or other engines that are requested to start from the engine are started. And each engine is MPU, L
Simulates input/output of external signals such as SI and sensors, transmission/reception of communication data, etc.

(III) Example of a simulator and its engine (
lit-1) Simulation management 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, and starting the simulation engine. It has functions such as running simulations and providing various debugger functions such as breaking and tracing during simulation execution.

FIG. 1 is a block diagram showing functional implementation means for executing simulation management.

The simulation management unit 410 selects the session “si+5ula” in the simulator window 510 shown in FIG.
tion' and select "Go 5ession", the simulator management section 200 calls and starts the engine initialization section 420, the simulation window section 430 (hereinafter referred to as the window section), and the simulation engine section 440 ( (hereinafter referred to as engine section) and debugger 450.

The engine initialization unit 420 initializes the window unit, engine unit, debugger, and the like.

FIG. 3 shows the operation sequence of the simulation management unit.The window management unit 430 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 performing a simulation by the unit 440;
Next, the debugger 450 is activated to execute debugger functions such as break and trace. When executing the simulation, each of the above processes is called and looped as shown by the arrows in the figure.

The window unit 430 controls event processing that occurs within the window and 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 port engine, and an LSI circuit engine according to system time and state changes.

The debugger 450 provides functions such as breaking and tracing within the simulation, monitoring, file display, and correction functions.

(III-2) Simulation Window The window has various simulation functions and the function of opening multiple windows at the same time. The window unit that implements this function receives events such as mouse button clicks and keyboard inputs within the window from the X server, and branches to the event handler for each window.

Each event handler further branches to an event processing module for each event, and processes according to the event are performed.

FIG. 4 is a block diagram showing the configuration of the window section.

The initial window generation unit 4301 is called by the simulation management unit 410 and generates a simulation window 600 (hereinafter referred to as window) shown in FIG.

The window management unit 4300 calls a simulation window event handler 4302 (hereinafter referred to as window event handler) to control the execution of events that occur within the window, and also activates an event handler 4303 by executing the above event to handle each event. control the execution of events that occur within the window.

The event handler 4303 branches to an event processing module in response to an event that occurs within the simulation window.

Here, the window event handler 430 executes the parameters and commands provided in the window.
It is 2.

The window service section 4304 includes the window generation section 43
A common subroutine is provided for registering and deleting the ID of the window opened by 05 or the window closed by the window closing unit 4306 in the window table.

The window table 430^, as shown in FIG.
When receiving an event from the X server, the window management unit 4300 branches to the event handler 4302 of each window, and uses the window ID and event handler 430 of the open window.
3 addresses are registered.

This table is used when branching to a corresponding event handler 4303 from among a plurality of event handlers when a plurality of windows are opened.

The contents of this table are registered when various windows are opened from the window, and are deleted when the window is closed.For example, as shown in Figure 7, when four windows are open, Four window IDs and four event handler addresses are registered in the table. If you close window B,
The addresses of window D and event handler for window B are deleted from the window table.

When the window management unit 4300 recognizes the event,
Depending on which window the event occurred in (window ID), the process branches to the corresponding event handler.

That is, when an event is received from the X server, it refers to the window ID and window table 430^ in the event information, and branches to the corresponding window event handler 4302. Next, the window event handler 4302 refers to the event information, Execute processing corresponding to the event.

In the X-Window system, event information is information that an application program receives from the X server (a structure called an This is the information displayed above, and also includes information such as mouse button clicks and keyboard input.

Next, windows will be explained in detail.

Specify the session ``simulation'' in the simulator window 510 shown in FIG.
If you select "Session", the initial screen of window 600 will be opened. Note that the initial screen of window 600 is
The machine layout 605 is not displayed in the monitoring window 603 shown in the figure.

In this window you can:

■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 and manual communication data and signal data input window 600.
As shown in the figure, a message display section 601 displays error messages and system-related messages.
, a command area 602 in which commands necessary for controlling execution of simulation are provided, a monitoring display section 603 for monitoring, and an information area 604 in which simulation information is provided.

The simulation is performed in the following modes.

(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 without 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. Checks the status of the hardware to be operated, for example, the presence or absence of a sensor output to confirm motor drive.

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, a 10g target is run to check the performance of the monitor without using test data. In practice, values are set in the memory or registers of the CPU as substitutes for test data at locations where test data is required, and the program is run.

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

The execution control of the simulation is performed using START and STELLAR 7 (S) provided in the window.
TEP), stop 7 (STOP) and reset (R
This is executed by a command group 6021 consisting of (ESET).

'5TART' is in simulation mode.
A simulation including communication data and timing data is executed, while in program mode a simulation of only the target program is executed.

"5TEP" 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 an initial state. As the simulation execution mode, a command 6022 consisting of simulation (Simulation Mode) and program (Program Mode) is selected.

"Simulation Mode" launches a simulation mode setting window.

"Program Mode" launches a program mode setting window.

A command group 6023 is provided for performing operations regarding the simulation environment and information.

"Set UP" launches a pop-up menu that sets the environment for the simulation.

“Trace” activates the Bo knob up menu for setting various traces.

"Display/Modify" starts a window for displaying and modifying information regarding the target program.

"Exit" exits the simulation and closes the window.

"C1earLog" deletes the window's message log file.

“Communication Data Manu
"al Input Window" starts a setting window for manually inputting communication data.

The information area 604 only displays information about the current simulation, but does not allow settings to be made.For ``timing DAT^'' and rco+smuieation DATAJ, auto mode is selected in the simulation mode. Sometimes it is possible to temporarily manipulate data travel.

That is, it is possible to stop the timing data or communication data from running at the beginning or in the middle, or to start running the stopped data from the middle. In addition,
In the initial state, both data are used, that is, the setting is for running, and in this state, each time you click, you can alternately select stopping and starting running.

The message display section 601 is displayed to prevent incorrect operations such as clicking "5TART" or "5TEP" when neither the simulation mode nor the program mode is set or when the machine layout diagram is not loaded (displayed). A warning message is given to the user, various messages issued from the simulator side,
For example, it notifies you that a break has occurred or that an abnormality has occurred while running the program.

The windows opened by selecting the above command will be explained below.

The simulation mode window (hereinafter referred to as the mode window) is
n Mode", and various simulation modes can be set. This mode window 610 contains parameters and settings for defining mode data, as shown in FIG. 8(a). There are commands for this.

“APρly” adopts the current settings.

"Abort" returns the current settings to the state they were in when the window was opened.

“Re5et” returns the current settings to default values.

“’Exit” closes the window.

“Auto” executes a simulation using test data created in advance.

"5tep" uses test data created in advance and repeats execution and break for each step.

'Manual' does not use pre-created test data, but allows the user to arbitrarily set necessary information and execute the process.

"Timing DATA" sets the name of existing timing data used in auto or step mode.

Further, when a character is double-clicked, a pop-up menu 611 shown in FIG. 8(b) is displayed and timing data can be selected.

"CommunicationModeData" is
Set the existing communication data name to be used in auto or step mode. Further, when a character is double-clicked, a pop-up menu 612 shown in FIG. 8(c) is displayed and communication data can be selected.

“M/CC1ock Count” sets the count number of machine clock cycles set by the configuration unit 300. This is in manual mode.
It is used to execute the simulation for the M/C clock specified here.

“Simulation Time” sets the simulation execution time. This is used in manual mode to run the simulation for the amount of time specified here.

"Data Repeat Count" sets the number of times specified timing data and communication mode data are repeated.

“5tep Count” sets the number of blocks of timing data input during auto or step.

Next, the operating procedure for setting the simulation mode will be explained. First, set the mode for which data and how to run the simulation.
Select from Manual. Then, the next setting item (parameter) is specified corresponding to the selected mode.

In the auto (^uto) mode, the timing data name, the communication data name, the number of repetitions of the timing data, and the number of blocks (step number) of the test data are set.

In step mode, the timing data name,
Set the communication (communication mode) data name and the number of repetitions of timing data.

In manual mode, the number of M/C clocks or simulation time is set.

Timing data and communication data can be accessed from "Timing DAT^°' or 'C" in the mode window.
o5aunication Mode DATA", a pop-up menu 611 shown in FIG. 8(a) or FIG. 8(b) is displayed, and the data name registered in advance can be selected.After the above settings are completed, When "pp+y" is selected, the current setting contents are adopted, and verification regarding the configuration is executed based on the setting contents. As a result, the target program may access addresses other than the addressing memory set in the configuration unit 300,
If the target program has an address other than the ROM area of the memory map set in the hardware configuration, if some of the data required for each mode setting is missing, or if there is an error between the setting data. If there is a conflict between
By selecting “tUP”, the above setting items can be changed as shown in Figure 9 (
A pop-up menu 620 shown in a) is displayed, and a data list 3 is further displayed for a specific setting item from the pop-up menu, and a predetermined file name is selected from this data list.

For example, FIG. 9(b) shows the setup menu 620.
The Oaking menu 621, which is opened by selecting 'Machine Layout' from 'Machine Layout', is displayed.
t-1), (Layout-2), (Layout-
3) is registered. FIG. 9(C) shows the opening menu 622 opened by selecting Target Progra+a', and this menu shows (Progra) as the target program.
m-1) , (Program-2) , (Progr
am-3) is registered.

Further, FIG. 9(d) shows a signal table window 623 opened by selecting "Signal Table", and in this window, the signal name selected from the restored signal names is displayed in the monitoring window 603, which will be described later.
displayed on the machine layout diagram drawn in

The monitoring window 603 is provided as a subwindow in the window shown in FIG. 5, and is used to monitor changes in the status of each signal during simulation execution, display and delete input/output signal names 606 on the layerer l-605 diagram, And the input signal level can be controlled manually.

In manual mode, when the signal mark 607 is selected on the layout 605 diagram, a pop-up menu 624 shown in FIG. 10 is displayed, and a predetermined signal level can be selected from this menu.

Note that the data that can be manipulated is limited to direct signal data and input signals.

The program mode window is opened by selecting "Program Mode" in the window when executing a simulation targeting only the target program.As shown in FIG. There are 29 parameters, and the “GoStart Add”
'ress' sets the simulation execution start address, and '5tep 5tart Address' sets the simulation step execution start address.

Note that when "History" is selected, a history of previous settings is displayed, and these settings can be reused.

Next, the main windows that are opened by selecting a command from the command group 6022 and 6023 will be explained.

The breakpoint window 640 opened by selecting "Break Point" is provided with the following parameters.

“Memory Address, Ilo Add
ress, Register'' sets memory, I10 memory, or register as a break condition.

Read Data Write Data
A break condition occurs when the CPU reads or writes setting data to a setting address or register.

"[)aja Format" specifies the input format of read data write data as Hex format or Binary format.

"Break Count" specifies the number of times the break condition is satisfied. (A break will occur immediately after the break condition occurs this number of times.) When you have finished setting the above parameters, if you select "°°Set'", the first
As shown in Figure 2, the entry point (EntryPo
int) Break conditions are displayed in the display area.

“D i s p l ay/Modif y”
By selecting , a display/modify pop-up menu 650 is displayed. Figure 13 (a>
shows a specific example of display/modification. When you specify an item from among these, a dedicated window for that item opens, allowing you to perform various settings and modifications.

Next, the main windows from the above menu will be explained.

The memory dump window 651 displays the memory contents of an arbitrary area of the target program in Hex or disassembled format.

This window has the following parameters:

"5tart Address" specifies the display start address.

"End Address" specifies the display end address.

"Data Format" sets the display format (Hex
Specify one of Disassembly.

When the above parameter settings are completed, DIIm p
” is selected, the data is displayed in the display area as shown in FIG. 13(b).

The show file window 652 displays source files, assemble lists, etc. of the target program.

This window has the following parameters:

"Path" displays the bus name at the time the session was started, from the root directory to the current directory. By specifying any displayed directory, the Path (the current directory) can be changed.

If "Directories" is specified and there is a directory on the bus, the name of the directory is displayed.

"Files" is Path (current directory)
Display all file names that exist in . Note that Figure 13 (C) shows that there is no directory in the specified path (NO is displayed), and that there is a file (
30 files).

In "File Name", enter the file name you want to display.

“5search For” specifies a search string.

“'LineNo” indicates the display position of the file currently being displayed. Also, by entering the number of lines and pressing the return key, you can display the file contents near that line.

When a file name is specified, the contents of the 1,000 files are displayed in the display area, as shown in FIG. 13(c). In the example shown in FIG.
The contents of AM are displayed.

The set/clear window 653 allows modification of the target program, CPU registers, and memory contents in Hex or 21monic (hand assembled) format.

This window has the following parameters: (See FIG. 13(d)) '5tart Address' specifies the start address for modification or display.

"End Address" is the end address of the modification or display.
Specify the end address.

“’Register” specifies a register name.

“I/OAddress” specifies the I10 memory address.

“Entry Area” is new data (Hex)
Or enter the command (21 Monique).

The following commands are provided to display the definitions related to the above parameters or to set data and commands.

°"Display" displays the contents of the set memory address space, register, and I10 address.

"Modify" sets data or instructions in a set memory address space or register.

Read' reads the data specified in the set memory address space, register, and I10 address.

Load it into the target program itself. That is,
The target program recognizes that the data has been set to that address or register.

"Fill" sets data or instructions in all set address areas.

"Re5et" returns the target program to the state immediately after it was loaded.

Simulation state window 654 displays current simulation information that has been set or specified. As shown in FIG. 13<e), this window 654 displays the simulation target, the name of the configuration definition information, etc. set in each of the windows described above, and the simulation execution information.

The communication data manual input window 655 is used to manually set new communication data. This window 655 is provided with parameters for defining the communication data shown in FIG. 13(f).

“Data” specifies the commonly used name (up to 12 characters) of the data.

“RawData” is raw data and is specified as a hexadecimal value. (Maximum 32 bytes) “0utside Module” specifies the module name of the data transmission source.

“Byte Interval Time” sets the interval time in μs when the communication data is multiple bytes.

"Rx Bu f f e r Type" sets the receive buffer of the channel.

"Rx Buffer Type" sets the type of the receiving buffer from among three types: memory 1, memory, and register.

”InputType specifies the type of data input method.

“I nterupt” is the communication data generation unit 370 in the configuration unit 300.
The communication data queue is inserted into a communication data queue that is generated according to a communication protocol defined in a communication protocol setting window managed by the display window unit 500 that is opened by a communication protocol setting unit activated by the communication protocol setting unit. Therefore, subsequent data in the queue is affected by this interrupt data.

"Exchange" exchanges the data frame of the corresponding module in the communication data queue. Therefore, data in subsequent queues is not affected at all.

'Immediate 1y' means 'Set
” at the same time, the specified data will be received.
Enter into Nofa.

”Time From Power On
” Sets the time from Waon for each residence.

"Time From Tx Data" sets the time elapsed after certain data is transmitted in edict units.

“TxData” sets a hexadecimal value for transmission data.

“TxBuffer” is the transmit buffer in memory, I1
Set from among the three types: 0 memory and register.

(III-3) Simulation Engine The simulation engine unit (hereinafter referred to as the engine unit) is called by the simulation management unit 410, as shown in FIG. 14, and manages the execution of the simulation by synchronizing the time of each engine. A simulation engine controller 441 (hereinafter referred to as the engine controller) that manages the initialization of the herring, a simulation engine initialization management section 420 (hereinafter referred to as the engine initialization management section) that manages the execution of initialization of the herring, and engine sections 442 to 442 activated by the engine controller. 447, and engine initialization units 421 to 426 that are activated by the engine initialization management unit 420 and initialize various tables and management tables (table location information) used by each engine.

The engine section mainly consists of a tarok engine 442 that simulates a clock signal that generates regular periodic pulses that are input to the clock terminal of a timer/counter, an MPU instruction engine 443 that executes instructions of a target program, and an LSI circuit and external connections. A direct signal engine 444 that executes a simulation of input/output dielet signals, a communication data engine 445 that executes a simulation of communication data, and an MPU port engine 44 that executes a simulation of an MPU built-in port.
6, and an LSI circuit engine 447 that executes simulation of peripheral LSI circuits.

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

The LSI directed signal state change list 444A is data for notifying the LSI circuit engine 447 of a direct signal whose state has changed. FIG. 16 shows an example of a list structure, which is composed of a list in which direct signal IDs of direct signals whose state has changed are arranged.

In the figure, the rNEXTJ link is data that indicates the location of the next data sent, since requests with data are sent to the LSI circuit engine from various engines. be. Further, the data type is a type number indicating that the direct signal status change list 444A addressed to LSI is sent from the direct signal engine 444. In addition, r
NEXTJ links and data types are used with basically the same meaning in Ike's list, so
The following description of the list will be omitted.

The direct signal state change list for the direct signal engine is 447A, which directs the direct signal whose state has changed.
- data for notifying the signal engine 444;
It has the same structure as the LSI directed signal state change list shown in FIG.

The direct signal state buffer 444B is a buffer that stores the state of the direct signal, that is, whether it is high level or low level. FIG. 17 shows an example of the buffer configuration, and each direct signal is The state of the signal is stored by the state fiID shown in Table 3.

The MPU terminal state change list 446A addressed to LSI in Table 3 is data for notifying the LSI circuit engine 447 of the MPU terminal whose state has changed. FIG. 18 shows an example of the list structure.

The MPU terminal state change list 447D addressed to the MPU is data to notify the MPU engine 446 of the MPU terminal whose state has changed, and is data that informs the MPU terminal state change list 447D, which is addressed to the LSI shown in FIG.
It has the same structure as the terminal-shaped variant strike 446A.

The MPU terminal state buffer 446B is a buffer that records the state of the MPU terminal, that is, whether it is high level or low level, and has basically the same structure as the direct signal state buffer 444B shown in FIG. It has become.

Next, clock-related data will be explained.

The LSI destination clock terminal state change list 442A is data for notifying the LSI circuit engine 447 of the real value clock signal whose count number has changed, and has the structure shown in FIG. 19.

The real value clock signal is a frequency signal defined by the user in the configuration section 300 using an actual frequency value.

MPU quad clock terminal state change list 442F This is data for notifying the MPU port engine of the real value clock signal whose count number has changed, and has the structure shown in FIG.

The real value clock signal is a frequency signal used internally by the MPU port engine 446.

The clock count state buffer 442B records the total count value of the real value clock signal defined by the user from the system start time, and has the structure shown in FIG. 21. The LSI circuit engine 447 and MPU port engine 446 that use this data store the count value from the previous operation and know that the difference is the newly added clock number.

The MPU clock count state buffer 442D stores the total count value of the real value clock signal used by the MPU port engine 446 from the system start time. This buffer has basically the same structure as the clock count state buffer shown in FIG.

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.

This table 442C, as shown in FIG.
50 to 9 are composed of the entire clock signal information, numbers 10 to 19 are composed of one entry of clock signal information.

Therefore, the information of Nos. 10 to 19 continues from the clock signal ID[O] to the last clock signal D. Here, frequency refers to the frequency of this real value clock in [ce] units, and the output change timing refers to the LSI whose output terminal will change in the nearest future among LSIs that have a clock input connected to this clock. Change timing is entered in system time units.

The connection terminal information defined by the clock signal information and the configuration connection terminal information are shown in Figure 22 (a) for each connection terminal.
), the table shown in FIG. 22(b) is provided, and this entry has the number of connection terminals and configuration connection terminals.

Built-in MPU built-in clock comfort table 442EM
It has information such as the number of real value clock signals built into the PU, connection terminal information, count value location, frequency, etc.

This table 442E has basically the same structure as the clock terminal configuration table 442C shown in FIG.

Next, communication-related data will be explained.

The LSI-originated transmission data list is sent by the LSI circuit engine 44.
7 to the communication data engine 445,
This is data to be sent 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.

FIG. 23 shows an example of the list structure. When there is data to be sent from the LSI circuit engine to the communication data engine, this data is created only for the send buffer with the send data, and the send buffer ID, send It consists of a list of time and transmission data pairs.

Here, "transmission buffer ID" is the ID number of the transmission buffer, "°transmission time" is the time when the first bit of 1-byte data indicated in system time is started to be transferred, "°data"
is raw data that does not include control bits.

MPU dispatch data list 445BM is data transmitted from the MPU port engine 446 to the communication data engine 445, and has a structure similar to the LSI dispatch data list 445A. This data is also used as a condition for the communications data engine to generate data to send to the MPU port engine.

The LSI destination received data list 445C is data for notifying the LSI circuit engine of the received data from the communication data engine 445 to the LSI circuit engine 447, and has the structure shown in FIG.

The MPU destination reception data list 445D is data for notifying the MPU port engine of the reception data from the communication data engine 445 to the MPU port engine 446, and is the same as the LSI destination reception data list 445 shown in FIG.
It has a similar structure to C.

The transmission buffer communication information 445F is data for informing the communication data engine of the transmission status of the communication LSIMPU communication port and the transmission time required to transmit 1-byte data to the communication data engine. It has time information and the 25th
It has the structure shown in the figure.

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

The transmission time indicates the transmission speed of this communication line, is calculated from the BauRate and the transmission method, and is expressed in units of 0I11s as the transmission time of 1 byte data.

The reception buffer communication information 445G is a communication LSI.

This data informs the communication data engine of the reception status of the MPU communication port and the reception time required to receive 1-byte data from the communication data engine, and has basically the same structure as the transmission buffer communication information 445F.

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. FIG. 26 shows an example of the table configuration. The address and type of the transmission buffer are set when the communication data engine is initialized, and the configuration table location and unit ID are set when the LSI circuit engine is initialized.

The reception buffer configuration table 445I has σ information such as the number of reception buffers, the reception buffer address, and the location of the configuration table of the reception buffer type 2 compatible LSI as reception buffer configuration information. Note that the reception buffer configuration table is the transmission buffer configuration table 4 shown in FIG.
It has basically the same structure as 45H.

The interrupt event list 446B is data for informing the MPU instruction engine from the MPU port engine that an interrupt has occurred, and has the structure shown in FIG. 27.

An interrupt event is an event that occurs when the target system is being simulated in a certain state and an event that is more urgent than the operation currently in progress occurs. This is what to do when it happens. That is, when there is an input (interrupt) to the MPU port provided in response to an erroneous operation, a processing routine for that purpose is run. Therefore, in this type of simulation, the MPU instruction engine 443 is equipped with various processing routines for assuming erroneous operations in advance and causing the target system to perform specific operations in response to the erroneous operations.

That is, when an interrupt corresponding to an incorrect mode is received, the MPU port engine 446 creates an interrupt event list 446B to notify the MPU instruction engine 443 of the content of the interrupt, and then
The instruction engine 443 refers to the interrupt event list and executes a predetermined processing routine accordingly.

The engine control will be explained below.

In the hardware of the recording apparatus, each apparatus operates in parallel within a period T0 as shown in FIG. 75(a). However, when we examine the operation of each device in detail, we find that under certain conditions, such as not including loops, we can perform simulations assuming that each device operates sequentially. There will be no inconvenience if you go. That is, as shown in FIG. 75, the operation of each device is sequentially simulated within the period T0, and the operation of the next device is simulated based on the signal level determined by the device that operated first. Simulations can be performed.

Synchronous control of each engine will be explained with reference to FIG. 28.6 The operation timing request list 441A is data for the active engine, that is, the engine that is starting, to notify the engine controller 441 of the next operation timing. , has the structure shown in FIG.

The startup request control table 441B stores a startup request list of engines to be started in the operating environment of another engine, such as an engine that has changed the terminal level of an LSI to either high or low, to the engine controller 441 with data. This is a table for notifying people, and has the structure shown in FIG.

The request data location contains the location of the area containing the data to be passed to the engine to be started. After each started engine processes a start request, it sets "NULLJ" in this location. In other words, if there is no start request, rNULL is entered.The engine controller 441 looks at this data and issues a start request to each engine. Is there 4!lI1gr
do.

The request data includes a direct signal state change list 444A addressed to the LSI, and a list 446A of MPU terminal state changes addressed to the LSI.
, MPU terminal status change list addressed to MPU 447 Received data list addressed to BLSI 445C, Received data list addressed to MPU 44
5D, Clock terminal change to LSI 442A, MP
Clock terminal state change list to U 442C, direct signal state change list to direct signal engine 447A, LS
I-originated transmission data list 445A, MPU dispatch-data list 445B, and interrupt event list 446B
It is.

Clock engine 442. M P rJ instruction engine 4
43° Direct signal engine 4441 Communication data engine 445, MPU port engine 446 and LS
Synchronization of the I-circuit engine 447 is performed using 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 this started engine can know the current system time. Each engine performs a predetermined operation as described below at the informed time. After this operation, the next operation timing is written in the operation timing request list. The next operation timing for each engine is determined as follows.

The clock engine 442 is determined from the period of the clock.

The MPU instruction engine 443 is determined from the time required to execute an instruction. For example, instructions A and B.

When executing C sequentially, if the currently executing instruction A takes time t, the next instruction B will be executed at time tf&.

The direct signal engine 444 is determined from the input time label of the next direct signal.

The communication data engine 445 is determined from the input time of the next communication data.

MPU port engine 446, LSI circuit engine 44
7 is obtained from the input time of the related direct signal.

The engine controller 441 refers to both the operation timing request list 1-441A and the activation request control table, sets the system time to the time in this list that is closest to the current system time, and advances the time.

For example, if the desired startup time of the MPU port engine 446 is closer to the current system time compared to the desired startup times of other engines or the startup time required by the engine, the engine controller 441 The MPU port engine 446 is set and the engine is started.

The engine controller 441 also refers to the activation request control table 441B and learns which engine should be activated.

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

The engine controller 441 includes an operation timing request list 441A and a startup request control table 4.
41B, each engine is started in the order shown by ■ to ■ in the figure.

At this time, 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 collectively counts clock signals at stages where the clock element does not change its output terminal. However, at the timing when the level of the output terminal of the clock element changes, the clock signal 442 works.

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

For example, when the relationship between the operation of the clock engine and the operation of other engines is as shown in FIG.
During period T1, since no other engines operate, the clock engine is not operated for each clock during this period.
Then, at time t1 when a relationship with another engine occurs, the four clocks up to that point are counted at one time. Count with

Here, the operation of each engine will be exemplified and explained in the order of startup. First, when the prestage clock engine 4420 is started, the LSI engine clock processing section 4421, which performs internal counter updating processing, and the MPU port engine clock processing section 4422, which calculates and sets the reference time of the MPtJ port engine, operate. As described above, the LSI circuit engine 447 and the MPU port engine 446 perform clock processing in advance before the actual startup timing. For example, in the LSI engine clock processing section 4421, the r825
3. When simulating an LSI such as, only the internal counter updating process is performed.

The MPU instruction engine 443 is activated and, for example, the MPU
When the engine I10 instruction is executed, the LSI engine MPLI I10 processing unit 4480 corresponding to the address
and operates the MPU port engine I10 processing unit 470.

Each LSI has memory areas called data addresses and control addresses, and these addresses are
Some are built into the address space of U and can directly read and write data using the MPU's I10 instruction. This address space is called the I10 address.

The LSI engine MPU I, 10 processing unit 4480 is
Processes the response on the LSI side to data being read or written to the above address by an MPU command.

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

The LSI request list 447G 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.

The structure of the list at each circuit level is the same, and consists of the number of registrations, the locations of multiple sets of configuration tables, and pairs of units I-rD.

On the other hand, in the MPU port engine I10 processing section 470,
The I10 command to the MPU port executes the port operation and rewrites 446A that indicates the status of the MPU terminal addressed to LSr.

By the way, the various status change lists that occur in one stage disappear within one stage. However, the transmission data list 445A, the interrupt event list 446B, and the direct signal status change list 447A addressed to the direct signal engine are processed in the next stage due to processing speed and the like. The transmission data list is used by the communication data engine as a data generation condition, and the interrupt event list is processed in the next stage because it only needs to be processed before the next MPU instruction. Also,
Direct signal state change strike 4 addressed to direct signal engine
Since 47^ is information for logging, it is sufficient for the next stage.

In other words, if there is a change in the state of a terminal of the currently activated LSI, the change in state will normally affect other LSs and Is (LSs belonging to different units) connected to that terminal.
It appears immediately as a change in the state of the terminal I). Therefore, changes in the state of terminals are usually processed at the same time, that is, within one stage.6 However, for communication data and direct signal data, changes in state occur in units of units, so the processing is performed several times in the simulation. It will be held after the stage. Therefore, the communication data engine and the direct signal engine do not operate immediately in response to a request from the LSI, but process the request based on a startup request from the LSI. If there is a change in the status of other terminals during that time, the corresponding process will naturally be performed.

In this way, the processing speed is increased by registering in the startup request control table the stage in which each engine should process the state change that has occurred in the current stage.

When the MPU instruction engine 443 executes an MPU instruction, it always refers to the interrupt event list 446B to check whether or not an interrupt is being processed. In other words, interrupt events are handled by predetermined routines, so
It is not necessary to process the request immediately when the request is made, but is configured so that it is processed the next time the request is started, prior to the execution of the MPU instruction.

When the clock engine 442 is activated, the LSI clock terminal state change list 442 and the AMPU clock terminal state change list 442F are replaced, and the contents thereof are transmitted to the LSI circuit engine 447 and the MPU port engine 446.

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

When the communication data engine 445 is started, the LSI destination reception data list 445C and the MP[J destination reception data list 445D are rewritten, and the LSI circuit engine and M
It is communicated to the PU port engine.

When the MPU port engine 446 is activated, the LSI destination MPU terminal state change list 446A, interrupt event list 446B, and transmission data list 445B are rewritten and transmitted to the LSI circuit engine, MPU instruction engine, and communication data engine, respectively.

When the LSI circuit engine 447 is started, the transmission data list I.445A and the MPU terminal status change list 44 addressed to the MPU are sent.
7B and the direct signal state change list 447A addressed to the direct signal engine are rewritten, and the communication data engine,
The signals are sent to the MPU port engine and the direct signal engine, respectively.

Thereafter, depending on the request list generation conditions, the MPU port engine is started again, and the LSI circuit engine is started at nt*. (This is a very rare case.) The reason for starting engines in this order is to run engines that affect other engines first, so that the effects from running the other engines are eliminated. This is because the receiving engine will be executed 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, so a startup loop is being considered between the MPU port engine and the LSI circuit engine. (See Figure 31) For example, in MPU port processing, from MPL+ to LS
Output a clock to I, divide this clock, and output it again to M.
Output to PU. The MPU executes MPU operations using a frequency-divided clock. In this way, when the order of processing is defined between the MPU and the LSI, it is supported by the above activation.

17',-MPU clock is counted and LSI
When assuming processing to change the state of the clock terminal of the LSI, first, the MPU port engine counts the clock, and this count value controls the state change 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 port engine of the result and requests execution of the interrupt event.

In such processing, the clock signal changes only once in one stage, so there is no possibility of multiple loops. It should be noted that although there is an operational priority order among the engines as shown in Table 4, it does not necessarily have to be this way in the simulation.

Note that the order of "-" in the table is irrelevant. Blank fields can be considered either, but choosing one is better than the other.
It is related to position a.

(Left space below) Table 4 By prioritizing and controlling the engines in this way, the software processing for engines that are started less frequently can be ignored and efficiency can be increased.

Synchronization between each engine is performed based on system time managed by the engine controller. As shown in Figure 33, the system time is set by the controller to the time closest to the current system time among the times in the dynamic timing request list notified by each engine and the start request control table, and the time is advanced. This is the reference time for synchronizing each engine. here,
In the engine controller, the function for managing time is called a time controller, and this time controller notifies each engine of the current time.

That is, in the engine to be operated, the system time notified from the time controller is set, and this system time is advanced as the in-engine system time.

On the other hand, after each engine executes a predetermined operation at the notified time, each engine writes the next operation timing in the operation timing request list.

By the way, since each engine is not informed of the latest system time from the time controller, each engine has its own time.

Furthermore, since each engine has its own time, which will be explained next, that time will be explained.

The clock engine has a time based on a clock signal generated by a transmitting element etc. existing in the LSI circuit, a time based on a frequency defined by a real value in the configuration of the interface LSI, and a time based on the frequency of the MPU built-in clock.

The MPU instruction engine has a total MPU time that advances by the time required for each instruction execution than the total number of states, and a next instruction execution time when the next instruction should be executed. Calculated by adding the number of timing states to the number of states.

The direct signal engine has the input time of the most recently input direct signal and the input time of the next input direct signal, and each direct signal input time is represented by the cumulative time of timing data, and its calculation is based on the timing data. This is done in the same unit as the data file.

The communication data engine has input times for the most recently input communication data and the next input communication data.

(III-4) When "S T A RT" is selected when the operations necessary for executing the simulation are completed using the engine operation window, the engine initialization section 420 is called by the simulation management section 410, and the initialization of each engine is performed. The engine controller is activated in a predetermined order based on the system time from among operation requests from each engine and activation requests from the engine, and a simulation is executed. The case where simulation mode is selected will be explained below.

The engine controller first looks at the engine 1F timing list, calls the bristage clock engine, and then
The I engine clock processing section and the MP port engine clock processing section are activated to update the internal counter of the LSI and calculate and set the frequency clock count used by the MPU port engine.

Next, the MPU instruction engine is called, and the LSI engine MPU I10 processing section and the MPU port engine I
10 processing units are activated.

The LSI engine MPU I10 processing unit transfers the location information of the configuration table containing the configuration information of the terminals of the LSI to the LSI for each circuit level in order to inform each LSI engine of changes in the terminals that occur during the simulation of the LSI circuit engine. It is created as a request list (see Figure 36).

On the other hand, the MPU port engine I10 processing unit executes a port operation in response to an I10 command to the MPU port.

Based on the results, the I10 processing unit creates an MPU terminal status change list addressed to the LSI (see Figure 18) for notifying the LSI circuit engine of the MPU terminal whose status has changed, and uses the contents of the list to control activation requests. Register in the table. In the subsequent startup of the LS1 circuit engine,
You can find out which MPU pins have changed states by looking at the LSI destination MPU pin state list, and the state information is sent to the MP
The high or low state is known from the U terminal state buffer and is used for processing related to information from other engines.

When the system time of the MPU instruction engine elapses, the engine controller refers to the operation timing request list and the startup request control table and sets the system time for the engine whose system time is closest to the current system time. do. For example, when the above system time is set in the clock engine, the clock engine starts and the LS
Clock pin status list addressed to LSI and MPU to notify I circuit engine and MPU port engine of real value clock signal with change in count number
A destination quad clock terminal state change list is created and sent to the engine, and the contents of the list are registered in the activation request control table.

Then, the current value of the real value clock signal whose state has changed is stored in the clock count state buffer and the MPU clock count state buffer.

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 engine is started in response to a request from the LSI circuit engine or MPU port engine, it checks the reception or transmission buffer communication information file to confirm whether the communication destination device is ready for communication, and then configures the transmission and reception buffer configuration. Refer to the table to create a list of received data addressed to the LSI and a list of received data addressed to the MPU to inform the LSI circuit engine and MPU port engine that there is received data and the receive data buffer where the received data is stored. It notifies each engine and calculates the data communication time from the transmission or reception time of 1 byte. This information is displayed at the user's request. Thereafter, the contents of the list are registered in the activation request control table.

When the system time of a certain engine has elapsed and the MPU port engine is started, the real value clock signal of the clock terminal is changed by referring to the clock terminal state change list.
- An LSI that takes in the total count value from the MPU clock count state buffer, refers to the received data list and the MPU destination terminal state change list based on this clock signal, and notifies the LSI circuit engine of the MPU terminal whose state has changed. A destination MPU terminal state change list is created 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 port that performs interrupt processing among the MPU ports, an event corresponding to the change is written in the interrupt event list.

Also, if there is data to be sent to the communication data engine,
Activates the serial interface transmission operation unit called by the MPU instruction engine to create receive buffer communication information to notify the communication data engine of transmittable information and 1-byte transmission time, as well as to inform the communication data engine of the transmission buffer of the destination and the transmission time. , transmission data, and transmission information are created and sent to the communication data engine, and the contents of the list are registered in the activation request control table.

When an LSI circuit engine is started after the system time of a certain engine has passed, the clock terminal configuration is performed to determine which LSI the clock terminal whose state has changed is connected to from the LSI destination clock terminal state change list. The total count value of the real value clock signal of that tally terminal is read from the tally count state buffer, and based on this clock signal, a receive buffer communication information file similar to the above is created, and the destination A transmission data list is created in which transmission information consisting of the transmission buffer, transmission time, and transmission data is arranged and sent to the communication data engine. Then, there is a list of MPU terminal status changes addressed to the MPU to notify the MPU port engine of the MPU terminals that have changed in status, and a list of direct signal status changes addressed to the direct signal engine that is used to notify the direct signal engine of direct signals that have changed status. At the same time, the list contents are registered in the startup request control table.

As shown in FIG. 14, the engine initialization section 420 includes a clock engine initialization section 421, an MP'U instruction engine initialization section 422, and a direct signal engine initialization section managed by an engine initialization management section 420^. 423, communication data engine initialization section 424, MPU port engine initialization section 425, and LSI circuit engine initialization section 426, and is configured to initialize data common to the engine, such as operation timing request list, startup request control table initialization, etc. This is done by initializing the table that stores the data within the engine.

(lit-6) Engine Controller The engine controller synchronizes the time of each engine and manages the execution of the simulation. As shown in Figure 33, the main functions are to start the engine with the earliest request based on the system time settings and operation timing request list, and to start requests for other engines that occur when each engine operates. This is to pick up the request from the startup request control table and start the requested engine.

(III-7) LSI circuit engine The LSI circuit engine is the wiring part of the LSI circuit and the LSI circuit engine.
Execute a simulation of the SI alone.

The following simulation is performed on the wiring part of the LSI circuit.

■Transmits direct signals to the connected LSI engine and MPU port engine.

■Transmit communication data to the communication LSI engine.

-Transmits changes in LSI terminals caused by the MPU instruction engine's I10 instruction to the LSI engine connected to it.

■Transmits changes in the LSI engine's output terminal to the connected LSI engine and MPU port engine.

For a single LSI, the following simulation is performed.

■LSI operation due to changes in LSI terminals■MPU I
LSI operation based on 10 instructions FIG. 34 is a block diagram showing the configuration of the LSI circuit engine. .

The LSI circuit engine 447 includes a direct signal input bundler 4471 . It includes an MPU terminal input bundler 4472, a reception data input bundler 4473, a clock terminal input bundler 4474, and an LSI engine driver 4475. In addition, the LSI circuit engine controller 4
470 is the simulation engine controller 44
1 is activated.

The direct signal input bundler 4471 creates a request list for notifying the LSI engine 4477 connected to the changed signal that it will be activated in the future from the LSI directed signal state change list 444A.

The MPU terminal input cable bundler 4472 selects the LSI connected to the changed terminal from the MPU terminal state change list addressed to the LSI.
This creates a list of requests to the SI engine.

The received data input bundler 4473 creates a request list for the LSI engine connected to the received data from the received data list 445C.

The clock terminal input bundler 4474 creates a request list from the LSI destination clock terminal state change list 442A to the LSI engine connected to the changed clock.

The LSI engine driver 4475 includes a direct signal output driver 4476 that transmits the output change to the direct signal engine when the LSI circuit engine changes the output signal of the direct signal, an LSI engine 4477 that simulates various LSIs, and an LSI circuit engine. It manages the MPU terminal output driver 4478, which transmits the output change to the MPU port engine when the output signal from to the MpU terminal changes. This LSI engine driver 4475 starts the LSI engine whose input has changed according to the LSI request list 447G created in response to the change in the signal at the terminal. LSI
After the execution of the engine is completed, a request list for the LSI engine connected to the terminal is created based on the changes in the terminal due to the execution.

The LSI circuit engine also includes an LSI engine clock counter processing section 4421 that is called by the prestage clock engine 4420 and performs only update processing of the internal counter of an LSI engine that uses a clock signal, such as the 8253 engine, and MPU I10 processing unit 4480 of the LSI engine that configures and simulates the CPU70g function of the LSI;
It is called by the I10 instruction of the MPU instruction engine 443,
The MPU I10 processing unit 448 corresponding to the address
It is equipped with an LSII Carrot MPU I10 processing driver 447G that runs 0.

The CPU program function of an LSI refers to an operation of writing data into a specific address in a mapped memory space when the LSI is controlled by the I10 instruction of the MPU. That is, when data is written to a certain address in an LSI, a predetermined operation is performed based on this data.

The internal data of the St circuit engine includes a clock terminal configuration table 442C, an MPU terminal configuration table 446C, a direct signal configuration table 444C, an LSI configuration table 447C, a communication data configuration table 445H, 445I, and LS.
I circuit engine data management block 447E, 'L
SI request list 447G, LSI terminal state buffer 447B, clock count state buffer 442B, LSI internal memory register buffer 447
There are F etc.

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

The MPU terminal configuration table 446 (CMPU terminal configuration information, etc.) also has information such as the number of defined terminals, connection terminal information, and MPU terminal state buffer location.

Direct signal configuration table 444C and LSI
The configuration table 447C has direct signal terminals and L
Contains configuration information for the SI terminal. .

The communication data configuration tables 445H and 4451 are
This is a table containing configuration information of communication channels, including the number of communication channels, reception data buffer start location, communication LSI type, and LSI.
Contains information such as the location of the configuration table.

The LSI circuit engine data management block 447E
This is data that manages data used by the SI circuit engine, and has the location of each data.

As described above, the LSI request list 447G is information for transmitting to each LSI engine changes in the terminals that occur during simulation of the LSI circuit engine, and only circuit-level functions exist (see FIG. 36).

Each state buffer 442B, 444B, 446B
, 447B.

stores the state of terminals and signals.

The LSI internal memory register buffer 447F
It stores information necessary for simulating the LSI, such as the internal memory registers of the I.

In this embodiment, in order to simulate the operation of an LSI circuit, the LSI information setting section 320 of the configuration section is activated, and the LSI information setting section 320 of the configuration section is activated to
How many SIs are used, how each LSI is connected, what kind of signals appear in each bin of each LSI, etc. are displayed using the keyboard or mouse according to the setting window managed by the display window 500. Create LSI configuration data by inputting the data using This L
The simulation section simulates the operation of the LSI circuit based on the SI configuration data and the data created in association with the SI configuration data.

Regarding the procedure for creating the above LSI configuration data, please refer to Patent Application No. 140716 filed in 1999 by the same applicant.
Since the patent application is described in detail in the above application, the above application will be cited and the explanation thereof will be omitted here.

Next, the operation of the LSI circuit engine will be explained with reference to FIGS. 35 and 37. In addition, the operation of one stage is r
The explanation will be based on the clock processing of the 8253J LSI engine.

Here, the r8253J is an LSI with a counter function, and in order to realize different counter functions, six port address data are provided for writing data to each port.

When the LSI circuit engine controller 4470 starts the clock terminal input bundler 4474, the clock terminal configuration table 442 stored in the clock data section of the LSI circuit engine data management block 447E is
Figure 22 (a) corresponds to the clock signal ID of the real value clock signal whose count number has changed from C to LSI.
Hb) Take out the clock terminal configuration table shown in (c) and refer to this table to determine which LSI the clock signal with the output timing closest to the system time stored in the output change timing (NO, 14>) is.
The clock terminal of the clock count state buffer 442B is connected to the clock terminal of the clock count state buffer 442B, and the position of the count value in the clock count state buffer 442B is detected. Therefore, the LSI configuration table 44 defines the terminal ID to which the clock signal is connected based on the connection terminal information of the clock terminal configuration table 442C.
7C1 For example, refer to the 8253 configuration table to find out where in the LSI terminal state buffer 447B the count value of the clock terminal whose state is to be changed is located. In this way, a change in state of a certain clock signal is L
Since the information is transmitted as information about the change in the state of the clock terminal of the SI, when executing a simulation of each LSI, the state change of the terminal requested by another engine is detected based on the 1-1 tall count value of the clock signal. Update and rewrite based on the result.

Therefore, each LSI engine 4477 is managed by the LSI circuit engine controller 4470 to execute the above processing in one stage. In other words, if each LSI engine has a terminal whose state has changed based on the total count value of the clock signal at a certain circuit level or a terminal whose state has changed due to a request from another engine, These terminal information will be notified to other LSI engines that will be activated in the future. Data reception with each engine is performed through the input bundler, and each input bundler 4471 to 447
3 organizes the relationship with the LSI engine as various data by circuit level and creates an LSI request list 447G.
Create.

That is, as shown in Figure 36, in the LSI request list, six LSI terminals whose states have changed are organized by circuit level, and the location and device ID are
This specifies the LSI engine to be activated in the future. When the LSI circuit engine controller calls the LSI engine driver 4475, the LSI engine driver refers to the LSI request list and starts the LSI engine whose input has changed.

The activated LSI engine refers to the LSI configuration tree 447C, and stores the latest state signal rewritten by each engine in the state buffer 447B belonging to each engine to detect changes in the state of the terminals connected to the LSI terminals.
Based on this signal information, the stored contents of the address associated with the terminal in the LSI terminal state buffer are updated. After that, LSI engine driver 4
475 receives a report of a change in the state of a terminal after execution from the engine, and creates a request list I for the LSI engine connected to the terminal.

In other words, the LSI engine driver
By referring to the configuration table of the engine, it is possible to know that there has been a change in the state of the terminal in question, so a request can be made to an LSI engine connected to that terminal at a different circuit level.

Furthermore, a direct signal output driver 447 is used to notify an engine other than the LSI of a terminal whose state has changed.
6 and MPU terminal output driver 4478 are activated.

The direct signal output driver 4476 updates the die reflex I/signal state buffer 444B that stores the corresponding direct signal when the LSI circuit engine changes the output signal of the direct signal.

At that time, Dairef (・Signal config table 444C
The location of the direct signal whose state has changed is stored in the direct signal state buffer with reference to , and the stored contents are rewritten.

The MPU terminal output driver 4478 changes the output signal from the LSI circuit engine to the MPU terminal.
The MPU terminal state buffer 446B, which stores the state of the MPU terminal connected to the LSI terminal whose state has changed, is updated by checking the U-terminal terminal configuration table 446C, and the MPU port engine 446 is notified of the state change of the MPU terminal. MPU to MPU to notify
Create a terminal-shaped modified strike 447D.

Simulation of LSI circuit operation will be explained with reference to the flowchart shown in FIG.

When the simulation is started, first, the MPU engine simulates the MPU, and determines the level of the MPU terminal at the time (steps 101, 102).
Based on the terminal level and other data of the LSI
The circuit engine determines the circuit level number (see Figure 76).
The simulation is performed in descending order of age. The simulation is performed using each unit ID with the same circuit level number.
These steps are performed one after another (steps 103 to 107). This determines the level of the output terminal of the LSI unit connected to the MPU.

When the simulation of all the units to which the circuit level number of
108). That is, the levels of the terminals obtained from the previous stage are sequentially determined.

When the simulation is completed for all circuit level numbers, the simulation of the LSI circuit is completed.

(III-8) Clock Engine The clock engine uses a real value clock signal (periodic pulse) configured by the user and M
Simulates the real value clock signal that the PU port engine originally has. The main functions are clock signal counting and tarok signal status change notification.
The change in clock count is notified to the LSI engine and MPU port engine connected to the real value clock signal.

FIG. 39 is a block diagram showing the structure of the clock engine and its relationship with other parts.

The clock engine 442 is connected to the engine controller 44
1 and counts the clock signal. The count is calculated from the system time and the frequency of the signal.

Regarding the clock signal whose count value has changed, the LSI engine and MPU port engine are notified of the change in status, and a request is made to execute a simulation of an LSI or the like having a clock input.

The pre-clock engine 4420 counts the σ macro clock signal at a stage where the clock element does not change the state of the output terminal, and issues instructions to each LSI engine to operate the element having the clock input accordingly.

The clock engine timing notification macro unit 4423 is
The change timing of the output signal of the LSI element connected to the clock signal is entered in the clock terminal configuration table (connection terminal information part), and the change timing of the output signal of the LSI is notified to the clock engine.

Next, the operation of the clock engine will be explained with reference to the data related diagram shown in FIG.

In the clock engine 442, clock terminal state change list 442A for LSI, clock terminal state change list 442F for MPU, and clock count state no.4
42B, MPU clock count state buffer 4
42D, clock terminal configuration table 442C, M
The data in the built-in clock configuration table 442E built in the PU and the output change timing passed as an argument to the notification macro function are used. Note that the clock signal is basically the same for the LSI circuit engine and the MPU port engine (since it is for iE, the LSI circuit engine will be explained here.

The pre-clock engine 4420 refers to the clock terminal configuration table 442C and selects the L
A clock count is performed at a stage in which the state of the output terminal is not changed for the SI, and an operation instruction is output to each LSI as to when and what minute the output should be changed in accordance with the count. In other words, the clock count state buffer 4 of the clock terminal defined in the clock terminal configuration table
The count value is written to 42B, and the data in this clock count state buffer is transferred to the LS using the clock signal.
A clock count processing unit 4421 in an I engine, for example, an R8253 engine reads the data, and an internal counter is updated based on this data.

Thereafter, the clock engine refers to the clock configuration table and adds the changing clock count value to the total count value stored in the clock state buffer 442B between the connection terminals of the LSI having the clock element and creates a new one. be the total count value. At the same time, a clock terminal shape change 442A addressed to the LSI is created to inform the LSI circuit engine of which clock signal's count number has changed. The LSI circuit engine refers to the clock terminal state change list and executes terminal processing to change the output terminal in the nearest future among the changed clock signals. That is, the clock processing unit identifies the LSI whose output terminal will change in the nearest future by looking at the output change timing of the clock terminal configuration table in which configuration information is defined, and determines the configuration of which LSI from the connection terminal information. Find out what is defined in the table. Then, specifying a clock count state buffer from the clock count value location in the configuration table, and reading the total count value corresponding to the clock signal ID from this buffer.
Based on this total count value, data (notification macro function) 442G is passed to the clock engine timing notification macro section 4423, indicating at what hour and minute the output should be changed.
The clock engine timing notification macro unit 4423 is
The change timing of the output signal of the LSI is calculated from the notification macro function, and the connection terminal information in the clock terminal configuration table 442C is rewritten based on this output change timing.

(III-9) Direct signal engine The direct signal engine is the LS of digital signals input and output from the outside.
Simulate input/output with the I circuit. This direct signal engine.

The direct signal input function sets the direct signal at the input timing to the direct signal state buffer and conveys the state change of the direct signal to the LSI circuit engine, and the direct signal output from the LSI circuit engine to the outside (output direct signal) 1 - Direct signal output function to set signal state buffer and nearest future direct signal input time to engine controller 1
~T1 to Laura! Equipped with an operation timing notification function that provides x1 operation timing notification function.

Note that the engine controller starts the direct signal engine when the direct signal input time comes.

FIG. 41 is a block diagram showing the configuration of the direct signal engine and its relationship with other parts.

The direct signal engine 444 is activated by the engine controller 441, reads direct signal data from a file, sets the data whose input timing has arrived in the direct signal state buffer, and stores the signals whose state has changed in the direct signal state change list. At the same time, it learns the output die reflex 1 to signal that has changed based on the direct signal state change list addressed to the direct signal engine sent from the LSI circuit engine, and executes a service for the user. That is, as a result of the simulation execution of the LSI circuit engine, a certain LSI circuit engine
When the state of the SI direct signal changes, the direct signal engine performs processing to inform the user whether the state change has appeared as a change in the operating status of the elements that make up the target system, such as motors, solenoids, etc. Execute. For example, if a motor operates at a certain point in time, a motor mark is lit on the screen, or the time and minute when the motor was turned on is displayed.

In the direct signal engine, direct signal data 444H in which information such as input time, signal name, signal state, etc. is arranged in the input time no. Direct signal state change list 444A, timing data signal name data 444D in which the signal number of the timing data corresponds to the signal name and a direct signal ID is added, timing data created by reading the timing data signal name data into memory. Signal name table 444E, direct signal I
Direct signal name data 444F, which associates D with direct signal names, and direct signal name table 444G, which is created by reading the direct signal name data into memory, are used.

Next, the operation of the direct signal engine will be explained with reference to the data related diagram shown in FIG.

Note that the timing data is processed by the timing data converter 3.
At 60, after being converted to direct signal data,
The configuration matching unit 350 gives each data a name and converts it into timing data signal name data 4.
44D, direct signal name data 444F is created.

The direct signal engine initialization unit 423 initializes the table and then reads the signal name data.

The timing data signal name table 444E, as shown in FIG. 43, associates the signal number of the timing data with the signal name, and attaches a direct signal ID corresponding to each timing data signal name.

The direct signal name table 444G, as shown in FIG. 44, associates direct signal IDs with direct signal names.

The direct signal engine 444 refers to the timing data signal name table 444E to read the direct signal ID from the timing data signal name of the direct signal data, and also refers to the direct signal name table 444G to read the direct signal ID corresponding to the direct signal ID. Read the name. It is necessary to notify the LSI having the terminal of the direct signal whose state has changed, and for this purpose, a direct signal state change list 444A is created and the direct signal data is stored in the direct state buffer 444B together with the direct signal name. Direct signal status change list 447A sends simulation results of LSI circuit engine to direct signal engine.
Information processing regarding the state change of the direct signal for the above-mentioned user service is performed with reference to .

In other words, refer to the above state change list and set the output direction l-
A signal name corresponding to the signal ID is read from the direct signal name table 444G, and mark processing and display processing on the screen are performed based on this direct signal name. The LSI circuit engine starts the direct signal input bundler 4471, refers to the die reflex 1, the signal configuration table 444c, and the direct signal state change list 444A to find out which terminal of which LSI has experienced an output change, and changes the state of this terminal. The LSI terminal state buffer 447B that stores fhi is rewritten. After that, a direct signal state change block 447A addressed to the direct signal engine is used to start the direct signal output driver 4476 and notify the direct signal engine of the direct signal (output direct signal) whose state has changed in the LSI.
and create the direct signal state buffer 4
44B.

(III-11>Communication Data Engine The communication data engine simulates communication data exchanged between the external module and the communication LSI in the LSI circuit in the target system and the communication port of the MPU as a data string in bytes. This communication data engine has functions for transmitting and receiving communication data such as communication mode data and communication protocol data during simulation execution.In other words, the transmission function uses the nearest future transmission time as an operation timing request. It notifies the list, registers the sent data in the received data list, and executes the transmission to the destination engine.In addition, as a receiving function, it can receive data from other engines, and use the received data to set transmission start conditions. Make a judgment.

FIG. 45 is a block diagram showing the configuration of the communication data engine.

The communication data engine 445 is a communication data engine initialization unit 4 that initializes data used by this engine for IIi.
24, and a communication data engine transmission unit 44 that performs transmission processing.
51 (hereinafter referred to as a data transmitting unit), a communication data engine receiving unit 4452 (hereinafter referred to as a data receiving unit) that performs reception processing, and a communication data management unit 4450 that manages the data transmitting/receiving unit. .

The communication data engine management unit 4450 allows the engine controller to refer to the operation timing request list and
Called when it is time to send or receive. In the case of transmission time, the data transmission section 4451 is activated,
Executes processing related to received data on the destination engine. When it is reception time, the data receiving unit 4452 is activated, and after determining the transmission start condition, reads the transmission data according to the determination condition and executes processing for displaying it on the screen according to the user's request.

As shown in FIG. 47, the data transmitter 4451 includes a transmitter controller 4453 and a protocol data transmitter 4.
454, mode data transmitter 4455, and manual data transmitter 4456. Each data transmitter prepares data scheduled to be transmitted in the near future than the present, and the transmitter controller 4453 refers to these data and transmits communication data to other engines.

The priority order among each transmitting section is as follows: manual data transmitting section > mode data transmitting section > protocol data transmitting section from the highest priority, and according to this order, the data of the transmitting section is
Priority 1: Overwritten by data with a lower value of +n 61.

Next, the operation of the communication data engine will be explained with reference to the data related diagram shown in FIG. 46 and the operation sequence shown in FIG. 47.

Prior to simulation of communication data, the communication data engine is initialized. That is, by starting the engine initialization unit 424, the communication mode data table 44
5J, communication protocol table 445K (hereinafter, both tables are collectively referred to as communication data table), and sending/receiving buffer configuration tables 445H and 4451.
is initialized. the? The communication mode data table 445J includes communication mode data, and the 311 communication protocol data table 445K includes communication mode data.

Each communication agreement data is read. In addition, the transmission/reception buffer configuration table 445H includes communication LS [
The configuration table location and unit ID are set.

When the communication data engine is called by the engine controller and the communication data engine management section is activated, the data transmission section and the data reception section operate to exchange communication data between the communication LSI and the communication port of the MPU. It will be done.

When the engine controller starts the communication data engine with reference to the operation timing request list and the start request control table, the communication data engine management section 4450 starts the operations of the data transmission section 4451 and the data reception section 4452.

First, when the engine controller sends communication data to the engine management section, the engine management section 4450
instructs the data transmitter 4451 to transmit. The data transmitter 4451 checks the reception status from the reception buffer communication information file 445G to confirm whether the communication destination device is in a transmittable state, and then refers to the reception buffer configuration table 445I to send the communication data to which unit. A list of LSI-destined received data 44 that specifies the location in the receive buffer of a certain communication LSI to be stored and is made up of pairs of receive buffer IDs and received data.
Create 5C.

That is, from the perspective of the LSI engine, one piece of communication data means that the received data is written to the receive buffer in the communication LSI configuration table.

In detail, if the activation request is received data addressed to LSI or MPU
The data transmitter is activated when transmitting data, such as destination received data, to the destination engine. The data transmission section is
Data is written to the reception buffer in which request data in the activation request control table, for example, reception data addressed to the LSI, is stored. That is, the data transmitter identifies from the receive configuration table to which unit the receive buffer storing the requested data belongs and to what address, and also determines whether the receive buffer of the destination engine is capable of receiving data. Determine whether this is the case using the receive buffer communication information file. As a result, if the data can be received, the transmitting unit controller operates to transmit the received data to each transmitting unit according to the communication protocol, mode, and manual, and sends the transmitted data including the transmitting time information read from each table. Send out. The transmitter controller identifies the receive buffer of the destination engine from the receive buffer configuration table, and based on the above-mentioned transmit data, sends the data and the receive buffer ID in which it is stored to the destination engine, such as an LSI or MPU, as receive data. Create a list of received data addressed to the registered destination engine.

Further, when the activation request is to receive transmission data from the MPU or LSI, the data receiving unit 4452 is activated. The data receiving unit 4452 uses the transmission buffer configuration table 445H to identify whether the transmission buffer is in the unit based on the location of the request data in the activation request control table, and also refers to the transmission buffer communication information file 445F. Check to see if it is ready to send. As a result, if transmission is possible, the transmission data sent from the MPU or LSI in the transmission data lists 445A and 445B is taken in and displayed on the screen.

(III-11) MPU instruction engine The MPU instruction engine is called by the engine controller and analyzes and executes the instruction pointed to by the current IC (instruction counter).However, as an internal process, this engine After executing the instruction of the current step (pointed to by the current IC), preparation for executing the instruction of the next step (instruction analysis) is performed.By performing this process, the engine controller is informed of the operating time in the nearest future. Can be notified. Below, regarding the instruction engine and port engine related to MPU,
Since the module configuration differs depending on the type of PU, the 7810/7811 will be explained here. In addition,
The standard specifications for the 781077811 are described in the ``COM-87AD User's Manual'' published by NEC Corporation.

FIG. 48 is a block diagram showing the configuration of the MPU instruction engine, and FIG. 49 is a data related diagram.

The MPU instruction engine 443 is an MPU instruction engine initialization unit 42 that initializes tables used by this engine.
2 and an MPU instruction engine section that simulates the execution of MPU instructions.

The MPU instruction engine 443 uses an interrupt event list 446B, an operation timing request list IA as interface data, and an MPU instruction table 443A, an MPU instruction execution table 443B, and an MPU instruction address table 443C as internal data.

The MPU instruction table 443A is created in advance depending on the type of MPU. As shown in FIG. 50, each instruction number has information such as the instruction code, operand instruction byte length, instruction time, and 21 monic.
l Ifrr instruction Referenced when the engine is analyzed and when the debugger assembles and disassembles. Note that the instruction number is a number sequentially assigned to each instruction code of the MPU.

As shown in FIG. 51, the MPU instruction execution table 443B is a table that is set when the MPU instruction engine analyzes an instruction, and contains operand information (memory address, register number, etc.) as a result of analysis from the instruction code. , number of instruction bytes, instruction time, etc. are set. When executing an instruction, this table is referred to and the instruction is executed. Here, the instruction number (NO>) is used as an index of the instruction address table when branching to the instruction execution subroutine.

As shown in FIG. 52, the MPU instruction address table 443C registers in advance the addresses of instruction execution subroutines corresponding to each of over 200 types of instructions, and is referenced when branching to the instruction execution subroutine during instruction execution. . Note that in the case of 7810/7811, n=212.

Next, the operation of the MPU instruction engine will be explained.

When the MPU instruction engine is activated, it executes interrupt event processing in the interrupt event list.

An instruction execution subroutine for processing each interrupt event is prepared and stored in the MPU instruction address table. Therefore, the MPU instruction engine reads the instruction execution subroutine corresponding to the interrupt event ID, and analyzes the instructions in this subroutine by referring to the MPU instruction table. As a result, the MPU instruction execution table contains operand information, the number of instruction bytes, Instruction time etc. are set. Then, referring to the MPU instruction execution table, the instruction pointed to by the instruction counter is executed. Thereafter, the next instruction is analyzed and the next instruction execution time, that is, the nearest future MPU instruction engine operation time is written into the operation request list.

By the way, in the relationship between the debugger and the MPU instruction engine, the debugger provides functions such as breakpoints, traces, and memory dumps to the user, but it has a fairly close relationship with the memory, registers, etc. of the target MPU. In order to provide various services to users, it is necessary to know the status of the MPU's registers and memory.

On the other hand, since it is the MPU instruction engine that actually executes the MPU, the MPU instruction engine naturally accesses registers and memory.

In this way, the registers and memory of the MPU are accessed by the debugger and the MPU instruction engine.
Inconveniences such as referencing the same register or memory twice when executing an instruction may occur.

Therefore, the debugger manages memory and registers based on the software structure, and the MPU instruction engine accesses the memory and registers by using the access service section provided by the debugger. It is configured.

In other words, the MPU instruction engine operates completely independently of functions such as breakpoints and traces, and the debugger is configured to implement breakpoints and trace functions within the access service section. .

<1-12>MPU port engine MPU port engine is a port function of MPU.

Timer function, timer/event counter function,
Perform simulations of serial interface functions and analog-to-digital converter functions. In addition, regarding the simulation of the analog/digital converter function, multiple C
This is executed by generating an internal interrupt when the contents of the R registers are equal.

However, this is performed when writing to the CR register or A/D channel mode register.

FIG. 53 is a block diagram showing the configuration of the MPU port engine.

The MPU port engine initialization block 425 initializes data such as a terminal table and a clock table used by the entire engine. As shown in FIG. 54, this block 425 includes an MPU port initialization unit 4251 that initializes data used by the entire MPU port engine, such as a terminal table and a base clock table.
, a timer initialization unit 4252 that initializes data used only in the timer function block, such as a timer table.
, a timer/event counter initialization section 4253 that initializes data used only in the timer/event counter functional block, such as a timer/event count table, etc., data used only in the serial interface function block, such as the serial interface It consists of a serial interface initialization section 4254 that initializes tables and the like.

The MPU port engine controller 4460 is activated by the engine controller and manages internal time calculation, timer, timer/event counter, and reception operations of the MPU port.

The reset input bundler 4461 monitors input of a reset signal to the MPU terminal, and performs processing when a reset signal is input.

MPU port engine clock count processing section 4422
calculates and sets the clock count of the frequency (divided by 3, divided by 12, etc.) used by the engine.

The MPU terminal input bundler 4462 monitors signals other than the reset signal that are input to the MPU terminal, and performs MPU terminal input processing if there is any input.

The timer operation processing unit 4463 executes timer operation.

The timer/event counter operation processing unit 4464 executes timer/event counter operation.

The serial interface reception operation processing unit 4465 executes the serial interface reception operation.

The MPU port engine terminal controller 449o is the MPU port engine terminal controller 449o.
Controls the level of the PU terminal and changes in the level state. The MPU port I10 instruction terminal processing unit 4491 is
The state of the terminal by the I10 instruction to the MPU port is set at the time of the port read/write instruction of the target program or the port read/write from the window.

The MPU terminal input processing unit 4492 performs processing to set the state of a terminal based on an input signal to the MPU terminal when a signal from an external module such as an LSI circuit engine is present.

The MPU terminal output processing unit 4493 converts the terminal state based on the output signal to the MPU terminal into the TO signal from the target or coo, c○ from the timer/event counter.
Performs setting processing when outputting one signal.

Next, the MPU port engine operation setting processing block for setting the operating environment of the MPU port engine will be described.

As shown in FIG. 55, the MPU port engine operation setting processing block 460 includes a timer operation setting section 4600.

It consists of a timer/event I/counter operation setting section 4601 and a serial interface operation setting section 4602.

The timer operation setting section 4600 sets the timer operation environment.

The timer/event counter operation setting unit 4601 sets the timer/event counter operation environment.

The serial interface operation setting unit 4602 sets the serial interface operation environment.

The serial interface transmission processing unit 4466 executes a serial interface transmission operation.

Analog/digital converter dynamic FIE processing section 4467
performs an analog-to-digital converter operation.

The MPU port engine I10 processing block 470
The I10 command to the PU port executes the port operation, and as shown in Figure 56, input/output port information and mode information for each baud, such as port mode, control mode, and expansion mode settings. Port setting section 4700. It consists of a port write section 4701 that sets latch information for each port, and a port read section 4702 that reads the status of each port.

Next, we will explain the functions of the MPU port engine.
The MPU port engine is divided into a setting section and an operation section for each function (timer, event counter, etc.), and normally only the operation section operates.

The MPU port engine controller 4460 controls the operating section, and performs the following steps.

- Check the input status of the set input to the MPU port engine, and if it is set, perform the reset process, and do not perform other processes until the reset is released.

■Frequency used by MPU port engine (divided by 3, 1
Performs counting processing (such as dividing the frequency by 2).

■Check the input to the MPU terminal, and if there is an input, the MP
Performs U terminal input processing.

■ Perform timer operation 6 ■Timer/Event Performs counter operation.

■Perform serial interface reception operation.

Note that when the MPU port engine is made to correspond to various functions, the module configuration is divided into functional blocks as shown below.

MPU port engine controller l-roller block.

MPU port engine controller 4460, reset input bundler 4461, MPLI port engine clock count processing section 4422, MPU terminal input bundler 4462, MPU port engine initialization block 4
It consists of 25.

The port function block includes a port setting section 4700 and a port light section 4 of the MPU port engine I10 processing block.
701 and a port lead section 4702.

The timer function block includes a timer operation processing section 4463, M
It consists of a timer operation setting section 4600 of the PU port engine operation setting processing block and a timer initialization section 4252 of the MPU port engine initialization block.

The timer/event counter functional block consists of timer,
/Event counter operation processing unit 4484, timer/event counter operation processing block of MPU port engine operation setting processing block
Counter operation setting section 4601, timer/event counter initialization section 4 of MPU port engine initialization block
It consists of 253.

The analog/digital converter function block includes analog/digital converter operation processing units 4467 to f.
The serial interface function block consists of 6 serial interface functions.
It consists of an interface reception operation processing section 4465, a serial interface operation setting section 4602 of the MPU port engine operation setting processing block, a serial interface transmission processing section 4466, and a serial interface initialization section 4252 of the MPU port engine initialization block.

The terminal control block is MPL + port engine terminal co-terminal controller roller 4490 (referred to as lower terminal controller), MPU port ■10 command terminal processing section 4491
, an MPU terminal input processing section 4492, and an MPU terminal output processing section 4493.

The operation of each of the above blocks will be explained below.

FIG. 57 and FIG. 58 are data related diagrams regarding the MPU port engine controller block.

In the MPU port engine controller block, the fifth
MPU port engine initialization management section 4250 shown in FIG.
MPU port initialization unit 4251 managed by.

The timer initialization unit 4252, timer/event counter initialization unit 4253, and serial interface initialization unit 4254 are activated to initialize various tables, and the MPU managed by the MPU port engine controller shown in FIG. Port engine clock count processing unit 4422, MPU terminal input cable bundler 4462
, and the reset input bundler 4461 is activated to set the counted tarok value in the 3-base clock table, and the terminal controller 4490 called by the Pandora activates the MPU terminal input processing section 4492 to update the MPU whose state has changed. Terminal information table 44
Store in 6D.

That is, the MPU port engine clock count processing section 4422 is controlled by the MPLI port engine controller.
When the clock count processing section (hereinafter referred to as the clock count processing section) is activated, the clock count processing section refers to the activation request control table 441B and displays the real value clock of the MPU whose count number has changed by referring to the activation request control table 441B. The configuration information of the signal is stored in the MPU associated with the MPU clock signal ID.
The MPU clock terminal is specified by referring to the U built-in clock configuration table 442E, and the count value of this MPU clock terminal is read from the MPU clock count state buffer 442D and set in the pace clock table 446E. In addition, the MPU terminal input card bundler 4462 refers to the activation liffunis I/control table and detects that there is an MPLI terminal status change list addressed to the MPU.
Call port engine terminal controller 449o,
The terminal controller/roller 4490 activates the MPU terminal input processing section 4492 and manages the input processing of the MPU terminal in which the level of the terminal or the state of the level has changed. That is, the MPU terminal input processing section
MP whose state has changed by referring to the U terminal state change list
The level of the U terminal is read from the MPU terminal state buffer, and the terminal information table 446D is created based on this level.
Rewrite.

The terminal information table 446D, as shown in FIG.
Terminal mode information, ■/○ type, output latch information, terminal level, and terminal state information regarding a terminal level change flag are stored. The contents of each piece of information are set according to Table 5.

(The following is a blank space) FIG. 60 of Table 5 is a data related diagram regarding the port function blocks. In the port function block, the port setting section 470D and the port writing section 4701 are controlled by the MPU instruction engine.
, and the port read unit 4702 are called to receive input/output port information and mode information.

Latch information etc. are processed. That is, the port setting unit 4700 specifies whether the terminal mode is port mode, program mode, or expansion mode, and sets in the terminal information table 446D whether the input port is the output port in that mode. At the same time, the terminal controller 4490 is activated. Further, the port light unit 4701 sets in the terminal information table whether the output is latched as high or low, and activates the terminal controller. Furthermore, the port read unit 4702 checks the terminal information table and learns from the terminal level change flag that there has been a change in the level of the terminal, and starts the terminal controller based on this.

Terminal controller 4490 is M P U h I /
The '0 command terminal processing unit 4491 is activated to set the state of the terminal by the I10 command on MPtJPt.

The MPU port I/10 instruction terminal processing unit 4491 refers to the terminal information table 446D and rewrites the MPU terminal state buffer 446B according to the terminal level, and at the same time notifies the LSI circuit engine that the state of the MPU terminal has changed. An MPtJ terminal state change list 446A addressed to the LSI is created.

FIG. 61 is a data related diagram regarding the timer function block. In the timer function block, first, the timer initialization section is activated by the MPU port engine initialization section, and timer tables T and T are initialized.

The internal tables of the timer function include timer tables T and T.
As such, a timer 0 table, a timer 1 table, and a timer F/F table are provided.

446E in the timer (0,1) table, Figure 62(a)
), the information necessary for the operation of each timer is as follows:
Timer count operation, input clock type, callan j.
The number, INTT generation conditions, and timer reference time are set. Note that timer 0. Since the timer 1 tables have basically the same configuration, only the timer 0 table is shown here.

Here, the count operation of the timer and the input clock type are set according to Table 6 below.

(Leaving space below) Table 6 However, *1: Internal clock divided by 12 *2: Internal clock divided by 384 *3: "Prohibited" for Timer O table and Timer 1
On the table, Shimadai becomes ``timer O match''.

Also, the timer F/F table 446F is shown in FIG. 62(b).
As shown in the figure, the information necessary for the operation of the timer F/F includes the timer F/F input clock type, level, level change status, generation interval from the timer F/F, generation interval to the outside, and reference time. is stored. Here, regarding the timer F/F input clock type and level, please refer to the following 7th section.
Set by table.

Table 7 However, *4: Internal clock frequency divided by 3 Figure 63 is a data related diagram regarding the timer/event counter functional block.

The internal table of the timer/event counter function contains
Event counter table Coo, CO that stores information regarding event counters (input control, clear control) as timer/event counter table C1T.
There are provided a Coo and COI output table that stores information on the amount of I signal output, and an LVO and LVIF/F table that stores information regarding F/Fs (Philip flops) of LVO and LVI.

The event counter table 446G is shown in FIG.
), information regarding the event counter that performs input control and clear control is set regarding the ECNT clear mode type, input clock type, and count number.

Here, the ECNT clear mode type and input tally type are set according to Table 8 below.

(Margin below) Table 8 COO, Cot output table 446H is shown in Figure 64 (b
), information regarding the C00 and C○1 signal outputs is set regarding the output timing flag output level, CO ratio output generation interval, and reference time.

Note that since the CoO and C01 output tables basically have the same configuration, only the C00 output table is shown here.

LVO, LVIF/F table is 4461. Figure 64 (
As shown in c), a level inversion permission flag and an F/F level are set as information regarding F/Fs (flip-flops) of LVO and LVI. In addition, LVO
Since the LVOF/F table and the LVOF/F table basically have the same configuration, only the LVOF/F table is shown here.

FIG. 65 is a data related diagram regarding the serial interface functional block.

In the serial interface function block, first the MP
The U-port initialization section activates the serial interface initialization section, and initializes the serial interface table in which information necessary for serial interface operations (transmission, reception) is stored.

Serial interface table 1. As shown in FIG. 66, T is a buffer for storing received data.

Information regarding the receive data pointer, serial interface mode type, clock rate type, serial clock mode type, 8-bit data transfer rate, transmit permission flag, receive permission flag, reference (update) count, and receive data status flag is stored. Ru. Here, the setting contents of the above information are shown in Table 9.

Table 9 (blank below) describes the serial interface operation. M.P.
When the serial interface operation setting section 4602 and the serial interface transmission processing section 4466 are started by the U instruction engine, the operation setting section 460
2 sets information necessary for transmitting and receiving operations in serial interface table 1, T.

Further, the serial interface transmission processing section 4466
Serial interface table 1. With reference to T.
What mode is the data to be sent in, for example synchronous mode, and is the clock rate used, and if so, what rate?
Furthermore, the transmission process is executed after checking the clock mode and confirming that transmission is possible under these conditions, that is, that the transmission permission flag is set.

Therefore, the serial interface transmission processing section 44
66 first refers to the serial interface table and creates transmission buffer communication information data from the transmission availability information. If transmission is not possible, the communication data engine 445 is notified that there is no data to be transmitted under the conditions specified in the serial interface table.

If transmission is possible, the time required to transmit the transmission data under the conditions specified in the serial interface table, that is, the transmission speed, is input as transmission buffer communication information data. Then, with reference to the transmission buffer configuration table 4451-1, definition information regarding the transmission buffer in which data to be transmitted is stored is extracted from the transmission buffer, and this definition information and the raw data stored in the transmission buffer are extracted. Based on this, the MPU-originated transmission data list h to be able to tell the communication data engine
Create 445B.

The communication data engine 445 refers to the transmission buffer communication information 445F and sends the transmission data if it is possible to send it)
・Rewrite the process of communication data to the next MPU port engine, that is, the MPU destination reception data list 445
D creation and operation timing are determined.

Serial interface reception operation processing unit 4465
When activated by the PU port engine controller,
Referring to Serial Interface Table 1, T,
If reception is possible, that fact is input along with the reception time as reception buffer communication information data. Then, the communication data engine looks at the reception buffer communication information 445G and
A reception buffer configuration table 44 in which configuration information of the reception buffer concerned is stored from the reception buffer ID in the PtJ destination reception data list 445D.
Referring to step 5 (2), write the received data in the MPU destination received data list to the corresponding receive buffer.

FIG. 67 is a data related diagram regarding the terminal control block.

In the terminal control block, I1 to the MPU port
Sets the terminal state according to the 0 command and the input signal to the MPU terminal and the terminal state according to the output signal. Note that the operation of the terminal control block has been explained with reference to the MPU port engine controller block, so the explanation thereof will be omitted here.

([1l-13) Monitoring Debugging of a target program using this simulator will be explained. FIG. 68 is a debugging configuration diagram. FIG. 69 shows the debugging flowchart 1-.

In the following description, each step is processed by the debugger 41, except for the highlighted parts that are particularly noted.

First, prior to starting the simulator, data such as hardware configuration data, timing data, and communication data are created and stored in the external event file 31.

When the simulator is started, the configuration file 30 is loaded (step 201), and then the internal tables of the debugger 41 and the MPU module 45 are initialized (step 202). Also display 14
The simulation window shown in FIG. 5 is opened, and the machine layout is displayed in this window.

Further, the debugger 41 calls the loader to load the target program 42 into the memory table 43 (step 203). Next, the external event file 31 is loaded (step 204), the interface 44 is called from the debugger 41, the interface 44 waits for input of a debugger command (step 205), and user input is accepted (step 106). When the external event file is loaded, necessary displays for monitoring such as direct signal names, signal marks, etc. defined on the above-mentioned frame 214 and frame 91 are displayed.

Note that these steps 205 and 206 are performed by the user interface 44.

The basic flow when debugging a piece of software is to set the input data before executing the program, set a breakpoint at the exit of the program unit to be debugged, and then execute the program from the beginning of the program unit. do.

Then, when the process stops at a breakpoint, the output data is referenced and checked to see if it matches the previously assumed data. If there is a discrepancy, use debugger commands to find where the bug is.

A command line input from the keyboard 13 is analyzed by the user interface 44 and converted into a format that the debugger 41 can understand.

If the user's input is a termination command, the operation of the simulator is terminated (step 207).

Also, it is a command other than the termination command, and the MPU
If it is not an instruction execution command, for example '
write”, r print”, rbreak
J etc., the respective commands are executed (
Steps 208, 217). Then, the execution result is notified to the user interface 44 (step 218).
, is displayed on the display 14 (step 219).

Also, if the user's input is an MPU instruction execution command (step 208), it is determined whether the simulation mode is selected (step 209).
, when in simulation mode, set direct signal data and communication data (step 21
0). Next, after the MPU module simulates MPU instruction execution, that is, starts each engine based on the system time managed by the engine controller (step 211), the timer
The internal functions of the MPU, such as ri/iso/event counter processing, are executed (step 212), and furthermore, the debugger 41 is notified of the instruction execution result, etc. (step 213). Note that when not in the simulation mode, that is, when in the program mode, only the execution operation of the target program is performed and direct signal data and communication data are not required.
Step 210) is skipped. In addition, step 2
11.212.213 is not debugger 41, but MP
It is executed by the U module 45.

The instruction execution result is further notified to the user interface 44 (step 214) and displayed on the display 14 (step 215). For example, 80
If a breakpoint is set at address 90,
When a program is executed in an address space that includes address a090, execution of the target program stops midway, and the message "rbreak at breakl (a090)" is displayed. This display indicates that the execution of the target program starts at a0, which is the address of the first breakpoint.
This means that it stopped at address 90. In this state r
Use the printJ command to display the contents of registers and memory and check whether they match the expected values.

If it matches, the command is r run a090
Enter J to resume execution of the target program from this breakpoint and run the program to the next breakpoint. Perform this operation for each breakpoint.

If the output register or memory contents do not match the expected values, for example, use the [trace J command to display the changes in registers and memory up to the breakpoint for each MPU instruction and locate the bug. search. Once a bug is discovered, the target program is fixed at the object level.

Debugging is performed by repeating the above operations.

At this time, the operating status of the motors and sensors that make up the control system of the recording device can be grasped as a result of executing the action on the window.

If a simulation of execution of the target program over multiple steps is displayed, step 216 is executed until execution of all specified instructions is completed.
Then, the process returns to step 209.6 When the execution of all instructions is completed, the process returns to waiting for input of a debugger command (steps 216, 205).

As described above, in the simulator of this embodiment, when executing a simulation, the target program 42 is loaded into the main memory 43 by the loader, and the configuration file 30, direct signal data file 22, and communication data file 26 are loaded. Based on the data, the MPU module 45 simulates the MPU operation.

〔Effect of the invention〕

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

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

■ By selecting the program mode, you can debug the software alone. 6. By selecting the simulation mode, you can test in a multiprocessor system environment.

■If the target system consists of multiple modules, each module can be debugged independently by supplying the necessary communication data to the MPU of each module from outside without using the electrical circuit board or mechanical parts. can do.

■Direct signal data not only defines the normal operating status of sensors, but also defines what is not normal, that is, the sensor
It is also possible to assume an abnormality in a solenoid, motor, etc. and define it based on the sensor output signal at that 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.

■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.

[Brief explanation of the drawing]

Figure 1 is a block diagram showing the overall configuration of the simulator of the present invention, Figure 2 is a diagram showing the configuration of the simulator window, Figure 3 is a diagram showing the operation sequence of simulation, and Figure 4 is a block diagram showing the configuration of the window section. , Figure 5 is a configuration diagram of the simulation window, Figure 6 is a data related diagram of the window section, Figure 7 is a diagram explaining various windows opened from the simulation window, Figures 8 (a) to (C) are simulation diagrams. 9 (a) shows the simulation mode window, (b) shows the timing data pop-up menu, (C) shows the communication protocol data pop-up menu, and FIGS. 9 (a) to (d) show the mode-related windows. Windows related to setup: (a) shows the setup menu, (b) shows the machine layout pop-up menu, (C) shows the target program pop-up menu, (d) shows the signal table window, and Figure 10 shows the manual mode. Figure 11 shows the configuration of the program mode window;
Figure 2 is a configuration diagram of the breakpoint window, and Figure 13 (a) to (f) are windows related to display/modify, (a) is the display/modify Bob's menu, (b) is the memory dump window, ( C) is the show file window, (d)
Set/Clear Window 1 (e) is the simulation state window, (f> is a diagram showing the communication data manual setting window, Figure 14 is a block diagram showing the configuration of the simulation engine section, Figure 15 is the diagram showing the relationship between each engine. Data related diagram, Figure 16 is L
Figure 17 is a diagram explaining the configuration of the direct signal state change list addressed to SI. Figure 18 is a diagram explaining the configuration of the MPU terminal status change list addressed to LSI. Figure 19 is a diagram explaining the configuration of the direct signal state buffer. Figure 20 is a diagram explaining the configuration of the clock terminal status change list addressed to the MPU. Figure 21 is a diagram explaining the configuration of the clock count state buffer. In Figure 22, (a) to (C) are clock configuration tables, (a) is the overall information of the clock signal and the structure of the signal information, (b) is the structure of the connection terminal information, and (C) is the configuration connection terminal. Figure 23 is a diagram explaining the configuration of the information transmission data list. Figure 24 is a diagram explaining the configuration of the LSI destination reception data list. Figure 25 is the diagram of the transmission buffer communication information file. FIG. 26 is a diagram explaining the configuration of a transmission buffer configuration table. FIG. 27 is a diagram for explaining the configuration of an interrupt event list, FIG. 28 is a diagram for explaining the operation of the engine controller, and FIG. 29 is a diagram for explaining the configuration of an operation timing request list. Figure 30 is a diagram explaining the configuration of the startup request control table, Figure 31 is a diagram explaining the startup order of each engine, and Figure 32 is a diagram explaining the startup order of each engine.
The figure is a time chart to explain the operation of the prestage clock engine, Figure 33 is a diagram to explain the synchronization control of each engine, and Figure 34
The figure is a block diagram showing the module configuration of the LSI circuit engine, Figure 35 is a data 9 relationship diagram between the modules in Figure 34, Figure 36 is a diagram explaining the configuration of the LSI request list, and Figure 37 is the LSI Figure 38 is a flowchart explaining the simulation operation of the LSIUgJM8 engine, Figure 39 is a block diagram showing the module configuration of the clock engine, Figure 40 is the data between the modules in Figure 39. Related diagrams: FIG. 41 is a block diagram showing the module configuration of the direct signal engine; FIG. 42 is a data relationship diagram between the modules in FIG. 41; FIG. 43 is a diagram explaining the configuration of the timing data signal name table; Figure 44 is a diagram explaining the structure of the direct signal name table, Figure 45 is a block diagram showing the module configuration of the communication data engine, Figure 46 is a data relationship diagram between the modules in Figure 45, and Figure 47 is FIG. 46 is a configuration and data related diagram of the communication data engine transmitter, FIG. 48 is a block diagram showing the module configuration of the MPU instruction engine, FIG. 49 is a data related diagram of the MPU instruction engine, and FIG. 50 is a block diagram showing the module configuration of the MPU instruction engine.
The figure is a diagram explaining the configuration of the MPII ffr instruction table,
51 is a diagram explaining the structure of the MPU instruction execution table, FIG. 52 is a diagram explaining the structure of the MPU instruction address table, FIG. 53 is a block diagram showing the module structure of the MPU port engine, and FIG. FIG. 55 is a block diagram showing the module configuration of the engine initialization block in FIG. 53. FIG. 56 is a block diagram showing the module configuration of the engine operation setting processing block in FIG. A block diagram showing the configuration, FIG. 57 is a data relationship diagram between modules regarding initialization of the MPU port engine, FIG. 58 is a data relationship diagram between modules regarding clock count processing of the MPU port engine and MPU terminal input processing, FIG. 59 is a diagram explaining the structure of the terminal information table,
Figure 0 is a data relationship diagram regarding the port function block, Figure 61 is a data relationship diagram regarding the timer function block, and Figures 62 (a) and (b) are internal tables of the timer function.
(a) is timer (0,1) table, (b) is timer F
Figure 63 is a diagram explaining the configuration of the /F table.
Event I... Data related diagram regarding the counter function, Figures 64 (a) to (c) are internal tables of the timer/event counter function, (a) is the event counter table, (b) is the COO output table, (c) is LVO
Figure 65 is a diagram explaining the configuration of the F7F table, Figure 65 is a data relationship diagram regarding the serial interface function block, Figure 66 is a diagram explaining the configuration of the serial interface table, Figure 67 is a data relationship diagram regarding the terminal control block, 681'7I is a block diagram of debugging using the IVIPU simulator, FIG. 69 is a debugging flowchart 1, FIG. 70 is a logic circuit that does not include a loop, and FIGS.
Figure 0 shows the signal timing chart, Figure 72 shows the logic circuit including a loop, Figure 73 shows the logic circuit including signal delay, and Figure 74 shows the
Figure 3 shows the signal waveforms, Figure 75 shows the operational differences between the simulator's target components and the actual hardware, Figure 76 shows the unit and circuit levels, and Figure 77 shows the simulator's hardware. FIG. 78 is a schematic diagram showing the structure of the simulator; FIG. 79 is a block diagram showing the basic configuration of the recording device; FIG.
Fig. 0 is a diagram explaining the development procedure of the recording device, Fig. 81 is a schematic diagram of a copying machine equipped with an automatic document withdrawal device T and a sorter, Fig. 82 is a schematic diagram of an automatic document feeder, and Fig. 83 is a schematic diagram of a copying machine equipped with an automatic document withdrawal device T and a sorter. 8th
FIG. 84 is a block diagram showing the configuration of the copying machine shown in FIG. 1, FIG. 84 is a configuration diagram of the simulator kit, FIG. 85 is a configuration diagram of the display panel section, and FIG. 86 is a diagram explaining problems in the debugging process. Figure 1 00

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 simulator for a recording device, comprising: 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. (2) A claim in which the simulation engine section is composed of a clock engine that generates a clock signal defined as configuration information and a clock signal built into the MPU, an MPU engine that operates the MPU and peripheral LSI circuits using software, and an LSI circuit engine. A simulator of the recording device according to item 1. (3) The recording device simulator according to claim 1, wherein the MPU engine includes an instruction engine that simulates analysis and execution of instructions, and an MPU port engine that simulates state changes of the MPU port. (4) An operation timing request list that records the next operation timing of each engine and a startup request control table that records the startup of an engine whose operating environment has been changed by another engine are provided, and the list and the table startup order are used by the simulation engine. 2. The recording device simulator according to claim 1, wherein the controller refers to and sets the system time for an engine whose startup time is closest to the system time managed by the controller, and starts the engine. (5) The recording device simulator according to claim 1, wherein the simulation engine section includes a clock engine, an MPU engine, an LSI circuit engine, and a direct signal engine that supplies externally input/output digital signals to the LSI circuit. (6) The simulation engine section transmits communication data to the clock engine, MPU engine, LSI circuit engine, direct signal engine, and the target system with external modules configured by other MPUs to the LSI circuit engine and MPU engine. 2. A recording apparatus simulator according to claim 1, further comprising a communication data engine that supplies the communication data engine. (7) Clock engine, direct signal engine, M
3. The recording device according to claim 2, wherein the PU port engine and the LSI circuit engine are associated with each other by a state buffer that stores the state of a terminal or a signal, and a state change list that notifies other engines that the state has changed. simulator. (8) The MPU port engine, LSI circuit engine, and communication data engine are associated by a communication data list that informs communication data information and a send/receive buffer configuration table that defines send/receive data buffers corresponding to each LSI engine. , a transmission/reception buffer that notifies the communication data engine of transmission/reception information from the engine to the communication data engine or from the communication data engine to the engine; data transmission/reception operations between the communication data engine and each of the engines are performed based on communication information; 7. A recording device simulator according to claim 6, configured as follows. (9) The recording device simulator according to claim 3, wherein the MPU port engine and the MPU instruction engine are associated with each other by an interrupt event list that notifies the MPU instruction engine of an interrupt event that changes the state of the MPU port. (10) The simulator according to claim 1, further comprising a simulation window section for performing operations such as simulation execution control, environment setting, monitoring, data input, and modification. (11) The simulator according to claim 10, wherein the simulation window portion comprises a simulation window provided with options for operating the simulation, and windows for individual settings, selections, and displays opened by the options. (12) The simulation window and individual setting windows have pop-up menus that display multiple data prepared regarding machine layout, target program, signal table, direct signal data, and communication data. 12. The simulator according to claim 11, wherein options are provided for making settings according to. (13) The simulator according to claim 11, wherein the simulation window is provided with options for modifying the target program, CPU registers, and memory contents. (14) The simulator according to claim 11, wherein the simulation window is provided with an option to display current settings or specified simulation information. (15) The simulator according to claim 11, wherein the simulation window includes a command display area, a message display area, a monitoring display area, and a simulation information display area. (16) The simulator according to claim 11, wherein the simulation window includes a program mode option for only the target program and a simulation mode option for supplying test data such as communication data and direct signals to the target program. (17) It has a simulation mode window that opens when a simulation mode is selected, and has an auto option that continuously supplies test data to the mode window and executes it, and an auto option that sequentially supplies test data with the same time label and executes it. 17. The simulator according to claim 16, further comprising a step option and a manual option for manually setting and executing test data. (18) The simulator according to claim 17, wherein the simulation mode window is provided with an option for opening a window for manual setting of communication data. (19) The simulator according to claim 16, further comprising a program mode window that is opened when the program mode is selected, and in which an execution start address of the target program or a step start address to be executed for each instruction is set by the mode window. (20) A clock engine equipped with a pre-clock engine that counts clocks at a stage where the clock element wants to change the state of its output terminal, and outputs operation instructions for elements with clock input to each LSI according to this count. . (21) A clock engine timing notification macro unit is provided to notify the clock engine of the timing at which the clock count value changes based on output change timing data of the clock signal output from the LSI circuit engine and the MPU port engine, and the clock engine timing notification is provided. A clock that refers to the clock terminal configuration table written by the macro section and notifies LSIs that have a clock input that is connected to a clock whose output terminal will change in the nearest future of the output change timing that the clock signal state has changed. Clock engine (22) characterized by creating a terminal state change list; a timing data signal name table storing data in which direct signal IDs and timing data signal names are associated; and a direct signal name table storing data corresponding to 1. A direct signal engine that creates a list of direct signal state changes addressed to an LSI to inform the user of the direct signal, and stores the direct signal data in a direct state buffer. (23) A list of direct signal status changes addressed to the direct signal engine that notifies the direct signal engine that there has been a change in the status of a direct signal in the LSI engine using a direct signal ID, and data that corresponds to the direct signal ID and direct signal name. and a direct signal name table in which is stored a direct signal name table, and performs processing for displaying the operating status of a target system on a screen based on the table by referring to the status change list. (24) An LSI engine provided for each LSI, an LSI request list organized by circuit level, and LSI engines that require activation based on information such as terminal status changes and test data input from each engine;
An LSI circuit engine includes an LSI engine driver that sequentially starts LSI engines at the same circuit level by referring to an SI request list. (25) The LSI circuit engine according to claim 24, wherein when the LSI engine driver changes the state of a terminal of another LSI engine by starting each LSI engine, the LSI engine driver creates a request list regarding a request to start the LSI engine. (26) Refer to the MPU terminal state change list addressed to the MPU and the MPU configuration table in which the MPU terminal information is stored to notify the MPU port engine of the MPU terminal information whose state has changed due to the startup of the LSI engine. and an MPU terminal output driver that creates an MPU terminal state change list addressed to the MPU, wherein the MPU terminal output driver is activated by the LSI engine driver.
The LSI circuit engine described. (27) An MPU that includes an LSI engine controlled by I/O instructions of the MPU and that corresponds to a specific address of the MPU.
The PU-I/O processing unit and the MPU-I/O processing unit are
25. The LSI circuit engine according to claim 24, further comprising an MPU-I/O processing driver that is activated by a command from the U-instruction engine and controls writing of data to the address. (28) a communication data engine transmitter that transmits received data to a destination engine; a communication data engine receiver that receives transmitted data from the destination engine and processes display of the data on a window; A communication data engine comprising: a communication data engine management section in which an engine controller refers to an operation timing request list and an activation request control table and activates either the receiving section or the transmitting section according to request data. (29) Claim in which the communication data engine transmitter is comprised of a protocol data transmitter that transmits communication protocol data, a mode data transmitter that transmits mode data, and a transmitter controller that controls each of the transmitters. 28. The communication data engine according to 28. (30) The communication data engine according to claim 29, further comprising a manual data transmitter that transmits the communication data set by the manual setting window.