JP2002279011A - Method and program for operation simulation of logical unit and computer readable recording medium with the program recorded - Google Patents

Abstract

PROBLEM TO BE SOLVED: To perform function confirmation and architecture evaluation by performing operation simulation in the initial stage of logical unit design and also to flexibly correspond even to architecture change with minimum description change. SOLUTION: A resource manager 12 allocates necessary hardware resource 14 for performance of a thread 13 where a thread manager 11 represents a needed function by the operation completion of a logical unit, in response to the request, the thread manger 11 further controls the performance state of the thread 13 in accordance with the allocation results, the thread manager 11 and the resource manager 12 also work together to repeatedly perform a resource request, resource allocation and thread control until the performance of the thread 13 is completed, and thereby, operation up to the operation completion of the logical unit is simulated.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

TECHNICAL FIELD The present invention relates to an LSI (Large Sc
ale Integrated circuit) and IC (Integrated Circui)
t) A method for simulating an operation of a logic device, a simulation program for an operation of a logic device, and a program for recording the program, which are suitable for use in performing an operation simulation for the purpose of verifying the function and performance in designing the logic device such as t). The present invention relates to a computer-readable recording medium.

[0002]

2. Description of the Related Art Conventionally, logic devices have been designed using HDL (Hardware).
RT (Register Tran) using e Description Language
sfer) Design often starts at the level. But,
Since the RT level is a technology intended for hardware with clock cycle accuracy, it is difficult to verify the function and evaluate the performance by expressing the logic device at the early design stage where the hardware and software are not clearly separated. It is.

Therefore, a language for describing a logic device at an early stage of design having a higher level of abstraction than the RT level [eg, C / C +
+, UML (Unified Modeling Language), SDL (Sp
ecification and Description Language). For example, there are documents listed below. `` Hardware-Software Co-design of Embedded System
s-The POLIS approach ”(F.Balarin, E.Sentovich,
M.Chiodo, P.Giusto, H.Hsieh, B.Tabbara and A.Jurec
ska, L. Lavagno, C. Passerone, K. Suzuki and A. Sangio
vanni-VinCentelli, Kluwer Academic Publishers, 199
7． "Coware-a design environment for heterogeneous
hardware / software partitioning problem "(K. Rompa
ey, D. Verkest, I. Bolsens and H. De Man, Proceedings
EuroDAC, 1996. "An Object Oriented Programming Approach for Ha
rdware Design ”(S. Vernalde, P. Schaumont and I. Bo
lsens, IEEE Computer Society Workshop on VLSI, Apr
il, 1999. "A Methodology and Design Environment for DSP A
SIC Fixed Point Refinement "(R. Cmar, L. Rijnders,
P.Schaumount, S.Vernalde and I.Bolsens, Proceeding
s Design and Test in Europe Conference, pp. 271-27
6, March, 1999. "Hardware Reuse at the Behavioral Level" (P.Sc
haumont, R. Cmar, S. Vernalde, M. Engels and I. Bolsen
s 、 The proceedings of 36th Design AutomationConfer
ence. ACM, 1999, pp. 784-789, June 1999. ) "An Efficient Implementation of Reactivity for
Modeling Hardware in the SCENIC Design Environment
t ”(Stan Liao, Steve Tijang and Rajesh Gupta, Pro
ceedings of the Design Automation Conference DAC'9
7, pp. 70-75, June 1999. ) "SpecC System-Level Design Methodology Applied
to the Design of a GSMVocoder ”(A. Gerstlauer, SZ
hao, A. Horak and D. Gajski, Proceedings of the Work
shop on Synthesis And System Integration of MIxed
Technologies, April, 2000. "On the use of C ++ for system-on-chip design"
(DiederikVerkest, Johan Cockx and Freddy Potargen
t, Proceedings of the IEEE Workshop on VLSI (IW
V), pp.42-47, April, 1999. )

[0004] In these design methods, a software thread technology [Ref. "Parallel operating system" (Akira Fukuda, Corona Co., pp.30, 1997.) "Java thread programming" (Scott Oaks, Henry Wong co-authored, Toyoka Tomatsu, translated by Toshihiro Nishimura, Ohmsha Co., Ltd., 1997.)
Has been introduced.

That is, a simulation of a logical device is realized by mapping each thread to one processing block and defining a "communication" function between the blocks.
Here, there are two major factors that affect the design cost of the logic device. One is the presence or absence of rework, and the other is design reusability. That is, as the number of rework operations increases, the design cost increases. In particular, when starting the design at the RT level using HDL immediately from a design specification (hereinafter simply referred to as "specification"), if the design is not confirmed and the mounting design is started, the mounting result is required. If the specifications are not satisfied, the specifications need to be reviewed, and the mounting design must be redesigned in many cases. This is a cause of greatly increasing the design man-hour and the design period. In order to improve this, it is important to make an early and accurate performance estimate.

[0006] On the other hand, with respect to design reusability, there are two types of reusability. One is the reuse of previously designed modules, and the other is the reuse of intermediate descriptions (source code) when the design is staged. For example, in the case of redesign based on the result of estimating the performance in the middle of the design, the need to change the source code affects the design cost. From this viewpoint, the method of designing the RT level directly from the specification has a high design cost. This is because if the design is changed, in the worst case, descriptions at all RT levels may need to be rewritten.

As described above, it can be seen that starting the design process directly from the specification at the RT level leads to an increase in design cost. Therefore, in order to solve this, a method of higher-level design of the system has been proposed. For example, FIG.
0 (A) and FIG. 30 (B), a design approach based on stepwise refinement. In the design approach based on the stepwise refinement, the design is generally performed according to the following procedure.

[0008] A function (block) is extracted from the specification 100 to make a block diagram [Step A in FIG.
1]. Then, based on the block diagram, for example, C
Depending on the language, etc., "UnTimed" level functional model,
In other words, a function model that does not consider the concept of time is constructed (described) [Step A2 in FIG. 30A, FIG.
Step B1]. At this time, the function (block)
If there is a dependency between them, a "communication" function is defined (described) between them, and those functions (blocks) are executed sequentially.

According to the architecture design, the description of the functional block to be mapped to the hardware is
(Bus Cycle Accurate) [Step B2 in FIG. 30 (B)], and the “communication” function becomes a bus communication protocol [Step B3 in FIG. 30 (B)]. This stage (level)
To estimate the performance [Step A3 in FIG. 30 (A)], and confirm the specifications.

[0010] Further description is made by FCA (Full Cycle Accur
ate) (step B4 in FIG. 30B) and change to the actual RT level description [step A4 in FIG. 30A]. At this time, the "communication" function is also incorporated into the description (step A5 in FIG. 30A). By the above-described detailed refinement, the specifications can be confirmed at an early stage, and an executable specification can be realized.

[0011]

However, in the above-described conventional method, since all changes at each level are performed manually, an extra design cost is required when changing from the "UnTimed" level to the BCA level. Is required. Further, in the performance estimation at that stage (step A3 described above), if the design needs to be reviewed, the description must be changed.

In the conventional method, since the architecture is reflected in the configuration of the function (block), if the architecture needs to be changed, the configuration of the function (block) must be changed. Accordingly, the description must be changed.

For example, as shown in FIG. 31, the function “1” is realized by using the hardware resource (resource) “A” by the BCA description (the function “1” is assigned to the hardware resource “A”).
Are mapped), the function “2” is realized using the hardware resource “B”, and the “communication” function is defined between these functions “1” and “2”. Assume that it is necessary to additionally realize the same function "1" as described above using a plurality of hardware resources "A".

In this case, the BCA description of the additional function “1” must be prepared by the number of the hardware resources “A”, and the “CA” between the function “1” and the function “2” must be prepared. The "communications" function must be redefined, including those already defined. As described above, in the conventional method, since the architecture is reflected in the configuration of the function (block),
Every time the architecture needs to be changed, it is necessary to change all the descriptions of the functions (blocks), which significantly increases the design cost and lowers the design efficiency.

The present invention has been made in view of the above-mentioned problems. In the initial stage of the design of a logic device, an operation simulation is performed to confirm functions and evaluate an architecture. An object of the present invention is to make it possible to drastically reduce the design cost of a logical device by making it possible to flexibly cope with the change of the logical device with a minimum change of description.

[0016]

In order to achieve the above object, according to the present invention, there is provided a method for simulating the operation of a logic device, comprising: a thread manager for controlling a thread which is a unit of execution of a program; A resource requesting step of requesting, from a resource manager that manages the hardware resource, a hardware resource required for executing a thread representing a function required until the operation of the logical device according to the device design specification, A resource allocation step in which the resource manager allocates a hardware resource according to the request to the thread according to a predetermined rule; and wherein the thread manager determines an execution state of the thread in accordance with an allocation result by the resource manager. Thread control step to control And simulating the operation until the operation of the logical device is completed by the thread manager and the resource manager cooperating with each other and repeatedly executing the above steps until the execution of the thread is completed. And

The resource manager may monitor the resource request in the resource request step () and determine a deadlock state of the resource request between a plurality of threads based on the monitoring result ( Claim 2).

The resource manager monitors a read / write request for the hardware resource allocated by the resource request in the resource request step (), and based on the result of the monitoring, requests for a hardware resource of a plurality of threads. A conflict state between read / write operations may be determined.

Further, the resource manager may monitor the number of resource requests for the hardware resource and detect a thread bottleneck based on the monitoring result. Further, the resource manager may monitor the number of resource requests for the hardware resource and detect blocking of the resource request based on the monitoring result.

Further, the thread may be given a budget for occupying the hardware resources allocated by the resource manager (claim 6), or the function may be limited to an execution time limit. (Claim 7). The operation simulation method for a logic device according to the present invention (claim 8) includes a comparison step of comparing a simulation result by the operation simulation method with an operation prediction value of the logic device, and a comparison result in the comparison step. And outputting to the external device.

Next, an operation simulation program for a logic device according to the present invention (claim 11) comprises a computer
A thread manager that controls a thread, which is a unit of execution of a program, and a resource manager that manages hardware resources necessary for the execution of the thread.
A resource requesting step of requesting the resource manager for hardware resources necessary for executing a thread representing a function required until the operation of the logical device is completed according to a design specification of the logical device; A resource allocating step of allocating a hardware resource according to the request to the thread according to a predetermined rule, and the thread manager controlling an execution state of the thread according to a result of the allocation by the resource manager By executing the control steps, the above thread manager and the resource manager cooperate with each other to repeatedly execute the above steps until the execution of the thread is completed, thereby simulating the operation until the operation of the logical device is completed. To do It is a symptom.

Further, an operation simulation program for a logic device according to the present invention (claim 12) provides a computer with a comparison step of comparing a simulation result obtained by the above-described operation simulation method with a predicted operation value of the logic device; And outputting the comparison result to an external device.

The computer readable recording medium (Claims 9 and 10) on which the operation simulation program for a logic device according to the present invention is recorded is described in claim 1 above.
1 and 12 are recorded.

[0024]

Embodiments of the present invention will be described below with reference to the drawings. (A) Description of First Embodiment FIG. 1 is a block diagram showing a configuration of a computer (information processing apparatus) such as a personal computer according to a first embodiment of the present invention. The computer 1 shown in FIG. 2 and a display (display device) 3, and the computer main unit 2 (hereinafter sometimes simply referred to as “main unit 2”) includes, for example, a CPU (Central Processing Unit) 4.
A main storage unit (memory) 5, a secondary storage device (hard disk) 6, a floppy (registered trademark) disk (FD) drive 7, and the like are provided. These components are connected to an internal bus such as a PCI (Peripheral Component Interconnect) bus. 8 are communicably connected to each other.

Here, the CPU 4 controls the operation of the computer 1 as a whole, and accesses the memory 5 and the hard disk 6 via the internal bus 8 to make necessary software (application) programs (hereinafter, referred to as “programs”).
The functions required as the computer 1 (in the present embodiment, in particular, the functions as the operation simulation device of the logic device) come to be exhibited by reading and operating the program data or application data. ing. The operation result (including the operation simulation result of the logic device) is displayed (output) on the display 3 as appropriate.

The hard disk 6 stores the above-mentioned programs, application data, and the like (hereinafter, may be simply referred to as “various data” for convenience of description) in advance or by installing. The various data stored therein are read out to the memory 5 having a high access speed from the CPU 4 as appropriate, and the CPU 4 executes the program at a high speed.

Further, the FD drive 7 can install various data by reading various data recorded on a floppy disk (FD; recording medium) 9 under the control of the CPU 4 and storing the data on the hard disk 6. FD9, for example.
If the operation simulation program 10 of the logical device is recorded in the computer 1, the operation simulation program 10 is installed from the FD 9 (stored in the hard disk 6), so that the computer 1 (CPU
4) can function as an operation simulation device for a logic device.

When the operation simulation program 10 (hereinafter simply referred to as “simulation program 10” or “program 10”) for the above logic device is stored in the hard disk 6 or the memory 5, the program 10 is held. Needless to say, the hard disk 6 or the memory 5 becomes a recording medium on which the simulation program 10 is recorded.

The program 10 is, of course, FD
9 may be recorded on a recording medium other than 9 (for example, CD-ROM, magneto-optical disk (MO), etc.). Installation from media is possible. Furthermore, not only installation from the recording medium,
For example, online installation via a desired communication line (network) such as the Internet is also possible. That is, the program 10 includes the FD9 and the CD-RO
It may be provided as a recording medium such as M or MO, or may be provided via a desired communication line such as the Internet.

Next, the details of the simulation program 10 will be described below. The simulation program 10 according to the present embodiment includes, for example, an OMT (Object-oriented Modeling Techniq) as shown in FIG.
ue), the description is based on object-oriented programming. Focusing on the main part, as shown in FIG. 2, the thread manager 11, the resource manager 12, the thread 13, the resource 14, the test bench 1
5, test data 16, input queue 17, execution queue 18, (resource) request 19, answer 21, resource answer queue 22, and the like. "OMT"
For example, see the document “Object-oriented methodology O
MT "(J. Rambo, M. Blaha, W. Plelani, F. Eddy, W. Laurensen, co-authored, translated by Eiichi Hanyuda, Toppan Co., Ltd., 1995.).

Here, first, the test bench 15 provides a function of generating test data 16 necessary for simulating the operation of the logic device according to a predetermined data generation rule, and then transferring the execution right to the input queue 17. The test data 16 generated by the test bench 15 is stored in the input queue 1 owned by the test bench 15.
7 are sequentially retrieved by the thread manager 11 and used to generate a thread 13.

Next, the above-mentioned thread 13 includes "give execution right", "execute", "stop", "stop", "resume", "start", "disappear",
By defining a function such as “generate” (called “method” in OMT), the execution state of the thread 13 is controlled when the execution right is transferred from the thread manager 11.

The thread 13 represents a unit of execution of a program. In the present embodiment, the thread 13 performs processing (function) from input to output (operation completion) of the logical device required according to the design specification of the logical device to be realized. It is described as a represented (defined) sequential flow. Assuming that processes (functions) required from the input to the output of the logical device are process A → process B → process C, and these are represented by one thread 13, for example, when the C ++ description style is used, FIG. It is described as shown. In the following description, a C ++ description style will be applied to a specific description example of the simulation program 10 unless otherwise specified.

When the thread 13 enters the execution state, if it is necessary to secure the resource 14 for its progress (ie, execution of the “methods” such as the processes A, B, and C), A request (resource request) 19 for requesting the resource and a request (release request) 19 for releasing the secured resource 14 are issued independently and sequentially stored in the resource request queue 20 when releasing the secured resource 14. It is going to go.

In this embodiment, the resource 14 refers to information on hardware resources (hardware resources).
IC (Application Specific Integrated Circuit),
Arithmetic units are defined as resource data.

Next, the execution queue 18 provides a function of storing the threads 13 waiting to be executed in each of a plurality of queues. The execution queue 18 is centralized in the thread manager 11.

That is, the thread manager 11 according to the present embodiment includes the execution queue 18 and one or more threads 13
And manages the progress ("methods" such as generation, execution, stop, restart, and disappearance) of the thread 13 and the execution schedule (order) of the plurality of threads 13 (that is,
It functions as a task for controlling the thread 13).
The next operation of the thread 13 is determined by the thread manager 11 taking out the answer 21 issued by the resource manager 12 from the resource answer queue 22 and referring to it (details will be described later).

Further, the resource manager 12 manages resources 14 (types and numbers) necessary for the thread 13 to proceed (to execute the “method”), and executes a unit time according to the above-mentioned “arbitration rule” defined in advance. While arbitrating resource requests 19 per type for each type of resources 14,
The resource 14 according to the resource request 19 is allocated to the requesting thread 13.

The result of the allocation of the resource 14 by the resource manager 12 is issued as a response 21, temporarily stored (added) in the resource response queue 22, and then taken out and referenced by the thread manager 11. Further, the “unit time” means a minimum time unit in which the resource manager 12 arbitrates the resources 14.

Here, when the resource manager 12 is described in the C ++ description style in the same manner as the thread 13, the result is as shown in FIG. 6, for example. That is, the type of the resource (R) 14 managed by the resource manager 12 is, for example, “R1” or “R2”, and the resource request queue 20 and the resource reply queue 22 are defined.

Then, the request method 31a, the resource 1
4 and a mediation method 31c for mediating the resource 14, respectively.
Here, the request method 31a indicates which type of resource 1
4 (“R1” or “R2”) is explicitly specified as a parameter, and the requested resource 14 and the thread ID of the thread 13 that issued the request 19 are registered in the resource request queue 20 as a request message. A function for performing operations.

Further, the release method 31 b
This function performs an operation of releasing the resource 4 and increasing the number of the released resources 14 by one.
Is a function for performing arbitration of resource allocation according to each "arbitration rule" for each type of resource 14 ("R1", "R2"). The resource request queue 20 is not empty according to the description in the broken line frame 311. As long as the request 19 is taken out of the resource request queue 20 one by one, for example, when the type of the resource 14 is “R1”,
The descriptions in 12 and 313 are executed. When the type of the resource 14 is “R2”, the descriptions in dashed frames 314 and 315 are executed.

The description in the broken lines 312 and 314 is as follows.
Requested resource 14 ("R1" or "R2")
If the number is less than or equal to 0 at that time, there are no resources 14 to be allocated,
"1" means that "False" is stored in the resource reply queue 22. The description in the dashed frames 313 and 315 is the case other than the above, that is,
If the number of (“R1” or “R2”) is 1 or more, allocation is possible. Therefore, the resource 14 is allocated according to the arbitration rule of the resource 14, and the arbitration (allocation) result (“True”) is returned. 21 means that it is stored in the resource reply queue 22.

With the above configuration, the simulation program 10 of the present embodiment is executed by the computer 1 (CPU
4) can be operated (functioned) as follows. That is, as schematically shown in FIG. 3, first, the test bench 15 generates test data 16 in accordance with a prescribed “test generation rule” (step S1), and the input queue 1
7 (step S2).

After generating all the test data 16, the test bench 15 gives the execution right to the thread manager 11 (step S 3). The thread manager 11 that has received the execution right extracts the test data 16 from the input queue 17 (step S4), generates a corresponding thread 13 (step S5; thread generation step), and adds it to the execution queue 18 (step S5). Step S
6). At this point, the thread 13 is in an unstarted state in which nothing is executed.

After the input queue 17 becomes empty, the thread manager 11 takes out the waiting thread 13 from the waiting queue 18 and, if the thread 13 has not been started yet, executes the thread 13 to bring it into the "execution state". (Step S7). The thread 13 in the “execution state”
Requests the resource manager 12 to secure a resource 14 required for the first "method" (for example, issues a resource request 19 for the resource "B" of the resources "A" to "C"; Step S8; Resource request step). This resource request 19 is added to the resource request queue 20 by the thread manager 11. The thread 1 that issued the resource request 19
3 is added to the end of the execution queue 18.

After that, when the processing (execution) of all the threads 13 stored in the execution queue 18 is completed, the thread manager 11 transfers the execution right to the resource manager 12 (step S9). The resource manager 12 that has received the execution right sends the resource request queue 20
, The resource requests 19 are sequentially taken out from the beginning (step S10), and while arbitrating the allocation of the resources 14 according to the current "arbitration rule", the requested resources 14 are allocated to the threads 13, and as a result ( Assigned or not; “True” or “False”)
Is issued as an answer 21 and added to the resource answer queue 22 (step S11; resource allocation step).

After the resource allocation process for all the requests 19 stored in the resource request queue 20 is completed, the resource manager 12 transfers the execution right to the thread manager 11 (step S12).
The thread manager 11 that has received the execution right sequentially extracts the answers 21 from the resource answer queue 22 (step S13), and the content of the answer 21 is “True”.
If (allocation OK), the thread 13 corresponding to the thread ID (at this time, located at the head of the execution queue 18) is executed (thread control step), and the next “method” is executed. Required resource request 1
9 is added to the resource request queue 20, and the executed thread 13 is re-executed to the execution queue 18
To the end.

If the answer 21 retrieved from the resource answer queue 22 is “False” (assigned NG), the thread manager 11 adds the current (previously issued) resource request 19 to the resource request queue 20 again. After that, the thread 13 is added to the end of the execution waiting queue 18 again as a “waiting state” (thread control step). In addition, all processing is completed (resource 1
Thread 13 has been deleted)
The thread 13 is deleted from the queue 18.

As described above, the thread manager 1
1 and the resource manager 12 cooperate to repeatedly control the execution state of the thread 13 according to the resource request, the resource allocation, and the answer 21 until the execution of all the threads 13 (the execution of all the “methods”) is completed. By executing, the operation simulation of the logic device is performed.

That is, the thread manager 11 and the resource manager 12 of this embodiment each have the following functional units, as schematically shown in FIG. The thread manager 11 and the resource manager 12 cooperate with each other to repeatedly execute the above-described control of the resource request 19 and the execution state of the thread 13, and output the execution result to, for example, the display 3. It simulates the operation up to completion.

Thread manager 11 and test data 1
The function as the thread generation means 110 for generating a thread representing a function (processing) required until the operation of the logical device is completed in accordance with the design specification of the logical device by input of 6. Function as resource requesting means 111 for requesting resource 14 from resource manager 12-Assignment result by resource manager 12 to request 19 by resource requesting means 111 (response 2
Function as thread control means 112 for controlling the execution state of thread 13 according to 1) Resource manager 12 Resource allocation means 121 for allocating resource 14 according to resource request 19 to thread 13 according to a predetermined "arbitration rule" Function as

In other words, in this embodiment, the description of the hardware resources required by the “processing (function)” to be implemented in the logical device is not made to the thread 13 (“method”), Each time a “method” is executed, the required resources 14 are dynamically allocated by the resource manager 12. In other words, the architecture is not reflected in the "functions" to be realized as in the past.

Therefore, it is possible to perform an operation simulation in the initial stage of the design of the logic device, and to verify the function (algorithm) in the initial stage of the design, such as whether or not the “function” required by the specification can be accurately realized. Even when the architecture needs to be changed, the description of the "function" is hardly changed, and the resource 14, the "arbitration rule" of the resource 14, the scheduling of the thread 13, the request for the resource 14, and the like are changed.
The design can be easily re-verified simply by making a change according to the change.

The fact that the design can be re-verified only by changing the resource 14 or the "arbitration rule" of the resource, the scheduling of the thread, the request for the resource, etc., as described above, means that the architecture suitable for the "function" is required. This means that search, performance evaluation of the architecture when mapping "functions" to the architecture, and timing verification at the initial design stage can be performed.

(A1) Description of Specific Example of First Embodiment Next, the above-described simulation method will be described in more detail with reference to specific examples. That is,
Here, the case of designing a QoS (Quality of Service) system and simulating its operation will be described. Note that the “QoS system” here means I
In a packet transfer device such as a P (Internet Protocol) router, for example, as schematically shown in FIG. 7, an input (received) packet 41 is classified into classes according to a certain rule and stored in a plurality of packet queues 45. In order to satisfy the specified service rate from each of the queues 45, the weight (W0 according to the specified service rate (W0
To W3) is output. For details of "QoS", see, for example, the document "Internet QoS" (Paul Ferguson, Geoff Hus
ton, co-authored by Toda Iwao, Ohmsha, 2000.)

Extraction of Function from Specification First, as shown in FIG. 8, it is necessary to extract the “function” of the QoS system to be realized from the specification 40 as shown in FIG. 8 (step S20). That is, in this case,
The following functions (a) to (c) are required at a minimum. (A) Classification function of packet 41 (see FIG. 7): Classify () This function 42 is a function of classifying according to the value of the “IP Precedence field” of the packet header. It is assumed that classification is performed according to the rules shown in.

[0058]

[Table 1]

(B) Storing the packet in the queue 45 (queuing) function 43: Queuing () This function 43 stores the packet 41 classified by the classifying function 42 in the corresponding queue 45. It is. Here, the maximum number of packets that can be stored in each queue 45 (hereinafter referred to as the maximum size) is predetermined, and packets 41 exceeding the maximum size are discarded.

(C) Dequeuing () function 44 for taking out a packet from the queue 45 The dequeuing function 44
This is a function to take out (output) 1
Has a "service rate" set in advance, and the "service rate" indicates that the packet 4
Decide whether to output 1 or not.

Next, the functions 42 to 44 are threaded as "methods" (step S21 in FIG. 8). That is, a series of processes (functions) of the above-described process A → process B → process C,
As described above with reference to FIG.
Expressed as 3. Classify () → Queuing () → Dequeuing () Here, there are three types of states of the thread 13 as shown in Table 2 below.

[0062]

[Table 2]

Each of the above-mentioned states includes the securing status of the resource 14 (allocation result), the queuing function 42 [Queuin
g ()] and the result of the dequeue function 43 [Dequeuing ()]. For example, when trying to execute Queuing (), if the queue 45 is already full and the packet 41 has to be discarded, the thread 13
Changes from the “executed state” to the “finished state”. If the resource 14 cannot be secured, the thread 13 is added to the end of the execution waiting queue 18 as described above with reference to FIG.

On the other hand, on the other hand, it is necessary to design the architecture of the QoS system based on the specification 40 (step S2).
2). That is, for example, the above Classify () and Queuing ()
Is realized on a certain resource 14 (tentatively R1), and Dequeuing () is realized on another resource 14 (tentatively R2).

Here, the above Classify () is the resource R
1 (that is, Classify () is allocating the resource R1 and executing) when the execution delay time is T1c,
Similarly, when Queuing () is realized on the resource R1, the execution delay time is T1q, and Dequeuing () is the resource R1.
Let T2d be the execution delay time when this is realized on the second.

When contention for the resource R1 occurs, priority is given to the request from Classify (), and when contention for the resource R2 occurs, resources are allocated in the order of arrival of the requests. Further, in order to improve the performance of the dequeuing (), the number of resources R2 is set to, for example, two.

Extraction of Resources from Architecture As described above, the number of resources 14 (R1, R2) and arbitration rules are defined as shown in Table 3 (step S23 in FIG. 8).

[0068]

[Table 3]

Fetching of Resource Request into Thread 13 Next, the above Classify (), Queuing (), and Dequeuing
In order to execute (), the resources R1 and R2 described above must be secured (the resource request is incorporated in the thread 13; step S24 in FIG. 8). That is, it is necessary to realize (describe) the following procedures (1) to (5).

(1) When the packet 41 arrives, the thread 13 is dynamically generated, and the thread 13 enters the execution state. (2) In order to execute Classify (), an attempt is made to secure resource R1 (issue request 19 for resource R1). If you can secure it, go to the next [Execute Classify ()]. If the thread 13 cannot be secured, the thread 13 enters a “waiting state”. In the next step (when the thread 13 enters the “execution state”), the resource R1 is secured again.

(3) After executing Classify (), Queuing
In order to execute (), an attempt is made to secure the resource R1. If you can secure it, go to the next [Execute Queuing ()]. If the thread R 13 cannot be secured, the thread 13 enters the “waiting state”, and in the next step (when the thread 13 subsequently enters the “executing state”), the resource R 1 is secured again.

(4) After executing Queuing (), the Dequeuin
Attempt to reserve resource R2 to execute g (). When it is secured, proceed to the next [Execute Dequeuing ()]. If the thread R13 cannot be secured, the thread 13 enters the "waiting state", and in the next step (when the thread 13 subsequently enters the "executing state"), the resource R2 is secured again. (5) Since all the processes have been completed, the thread 13 is terminated.

Description of Resource Arbitration Rule Next, when a plurality of threads 13 request the same resource 14 (R1 or R2), contention of the resource 14 occurs, so it is necessary to define an "arbitration rule" ( Step S25 in FIG. 8).

First, the "arbitration rule" of the resource R1 (corresponding to the "arbitration rule of R1" in the broken line frame 313 shown in FIG. 6) is described so that the following procedure is realized. (1) It is determined whether the resource R1 is currently free. If it is not empty, a response 21 indicating that the request is not allocated is issued to all requests 19. If not, proceed to the next step.

(2) Classi is included in the request 19 within the unit time.
If there is a resource request for executing fy (), the resource R1 is allocated to the thread 13 (if there are a plurality of threads, the thread 13 that issued the request 19 first). Classify
If there is no resource request 19 for executing (), the resource R1 is allocated to the thread 13 that issued the request 19 first. In response to the other requests 19, a response 21 indicating that the request is not allocated is issued.

On the other hand, the "arbitration rule" of the resource R2 (corresponding to the "arbitration rule of R2" in the broken line frame 314 shown in FIG. 6) is described so that the following procedure is realized. (1) It is determined whether the resource R2 is currently free. If it is not empty, a response 21 indicating that the request is not allocated is issued to all requests 19. If not, proceed to the next step.

(2) Allocate the resource R1 to the thread 13 which issued the request first among the requests 19 within the unit time. In response to the other requests 19, a response 21 indicating that the request is not allocated is issued.

Simulation As described above, the “functions” required for the QoS system are programmed (a simulation program 10 is constructed) and executed on the computer 1 (CPU 4).
An operation simulation of the QoS system is performed (Step S26 in FIG. 8). That is, Calculator 1 (CPU 4)
However, as described above with reference to FIGS. 3 and 4, the operation simulation of the QoS system is performed by operating as the thread manager 11 and the resource manager 12.

Comparison between Simulation Result and Predicted Value A certain simulation result is obtained by the above simulation. That is, for example, it is understood that the packet 41 is output at a certain rate. Then, by comparing the simulation result with the operation result (predicted value) 40 'predicted from the specification 40 (step S27 in FIG. 8; comparison step), the designed algorithm is correct (from the YES route in step S27). (Step S28)
It is determined whether or not (design error) (step S29 from the NO route of step S27), and the result is output (displayed) to, for example, the display 3 as an external device (output step).

That is, the part shown in the broken line frame 51 in FIG. 8 is a comparison step (S27) for comparing the simulation result of the above-described logic device simulation method with the predicted operation value of the logic device, and this comparison step. An output step of outputting the comparison result in (S27) to an external device such as the display 3 is referred to as a computer 1 (CPU 4).
, And functions as a (operation simulation) program for verifying the function of the logic device.

The program 51 is, for example, FD9
And a recording medium such as a CD-ROM, an MO, and the like, and the program 51 recorded on the recording medium is installed in the computer 1 (stored in the hard disk 6), thereby causing the computer 1 (CPU 4) to operate as described above. It can be operated as if.

If there is a design error (for example, the number of packets 41 to be discarded is larger than the specified value), the size of the queue 45 is changed (the description of the queue 45 (resource 14) is changed). Until an optimal architecture is obtained, the above simulation is performed to search for an optimal architecture for the QoS system.

Note that the above predicted value is, in the case of the above example,
Classify () execution delay time T1c, Queuing () execution delay time T1q and Dequeuing () execution delay time T2d
Can be calculated based on In addition, the simulation result and the comparison result with the predicted value are not only displayed on the display 3,
It is also possible to output to a peripheral device such as a printer.

As described above, Qo as a logical device
The function verification of the S system (verification as to whether or not the requirements as the system are satisfied) can be performed at an early stage of system design. Further, even when the architecture needs to be changed, the resources 14 (R1, R1
2) and "arbitration rules" for resources 14, scheduling of threads 13, requests for resources 14, etc.
The design (algorithm) can be easily re-verified simply by making a change according to the change. Therefore, it is possible to realize a highly flexible design method (that is, a description style excellent in reusability) with little rework and a change in description style, and it is possible to greatly reduce the system design cost.

(B) Description of First Modification By the way, a deadlock detecting mechanism 122 may be added to the above-described resource manager 12, as shown in FIG. 9, for example. The deadlock detecting mechanism 122 is for detecting whether or not a plurality of threads 13 may fall into a “deadlock” by competing for the resources 14.

[0086] The "deadlock" here is
This means that two or more threads 13 request a resource 13 occupied by each other and are in a specific state that cannot be resolved. "Deadlock" is described, for example, in the literature "Basics of modern operating systems" (Hagiwara Hiroshi, Tsuda Takao, Okubo Eiji co-author, Ohmsha, p.
p.63, 1995. ).

For example, two threads 13 described as shown in FIG. 10 (for example, thread “1”,
Let us consider the case where it exists. Here, the number of resources 14 (“A”) is three,
4 (“B”) is assumed to be two. FIG.
, A numerical value (in this case, “2”) displayed in a function (parentheses) such as “resource A. request ()” represents a thread ID, and the same applies to the following description.

In such a case, the resource allocation graphs (re
The source allocation graph is as shown in FIG. The state shown in FIG.
e), the state is as shown in FIG. 11B, but in this state, further reduction is already impossible (irreduci
ble).

This is because thread “1” and thread “2”
This means that a "deadlock" may occur between them. The deadlock detection mechanism 122 thus determines the possibility of “deadlock” based on the resource allocation graph. This makes it possible to detect the possibility of “deadlock” in the initial stage of the design, and to verify the function of the logic device.

(C) Description of the Second Modification The resource manager 12 described above includes, for example, FIG.
As shown in FIG. 2, a read / write detection mechanism 123 may be added. Here, the read / write detection mechanism 12
Reference numeral 3 is for monitoring (detecting) the following events (1) to (3) to detect the possibility of a read / write error.

(1) Occurrence of a read request and a write request for the same resource 14 within the same unit time (2) Occurrence of a read request for the resource 14 already occupied by a write request (3) Occurrence of a read request Of write request to existing resource 14

That is, the read / write detection mechanism 12
3, when the plurality of threads 13 sequentially perform the writing operation or the reading operation on the resource 14, it is determined whether or not the order is correct (that is, the reading of the resource 14 between the plurality of threads 13 is performed). / Competition state of the write operation) to verify whether the designed logical device operates correctly.

To realize this, the description of the request 19 is extended, for example, as shown in FIG. That is, a "read / write flag" having the meaning shown in the following Table 4 is defined.

[0094]

[Table 4]

In addition, the description of the resource 14 is described in FIG.
Expand as shown in FIG. That is, when the resource 14 is released, the “current flag (CurrentF
lag) ”to“ 0 ”(broken line frame 316).
When the “current flag” is not “0”, the “read / write flag” of the request 19 and the resource 1
If the "current flag" on the fourth side does not match, error information such as "there is a possibility of a read / write error" is output to the display 3 or the like (dashed box 317).
See).

(D) Description of Third Modification Further, as shown in FIG. 15, for example, a bottleneck detecting mechanism 124 may be added to the resource manager 12 described above. Here, the bottleneck detection mechanism 124
Is to detect a “bottleneck” based on the execution result of the thread 13 and the access status to the resource 14. For example, a simulation is performed in an environment in which the number and type of the resource 14 are limited, 1
By checking the number of accesses to the logical device 4, the waiting time when the resource 14 cannot be allocated, and the like, it is possible to detect a portion of the logical device that is a "bottleneck".

Specifically, for example, as shown in FIG.
If a "method" for counting the number of requests (the number of accesses) is added to the description of the resource 14 and the count result can be called by a "request total member function [request total ()]", the resource 14 A mechanism for monitoring the number of accesses is realized in the resource manager 12.

That is, if the “request total member function” of each resource 14 is called by the bottleneck detecting mechanism 124, the access frequency to each resource 14 can be checked. For example, the resource 14 with the highest access frequency can be checked. Can be inferred to be a "bottleneck" for logic devices. Therefore, performance verification (verification of the presence or absence of a bottleneck) of the logic device can be performed at an early stage of the design of the logic device.

(E) Description of Fourth Modification The above resource manager 12 includes, for example, FIG.
As shown in FIG. 7, a blocking detection mechanism 125 may be added. Here, the blocking detection mechanism 125
Provides a function for checking the occurrence state of "blocking" when the number of requests 19 for the resource 14 from the thread 13 exceeds a predetermined limit. For example, the description shown in FIG. Is realized.

Then, by performing a simulation in an environment in which the “number” of resources 14 is limited (predetermined), requests 19 exceeding the number of resources to be allocated are obtained.
(If the condition of the if statement (“number” <0) is satisfied), it is considered that “blocking” has occurred, and for example, error information such as “the request for resource A needs to be blocked.” Is output to the display 3 or the like.

As described above, in the present modification, the blocking detection mechanism 125 can cause the blocking when the resource request from the thread 13 exceeds the limited number under the environment where the “number” of the resources 14 is limited. By examining the performance, the performance of the logic device can be evaluated.

Note that the deadlock detection mechanism 122, read / write detection mechanism 123, bottleneck detection mechanism 124, and blocking detection mechanism 125 in the above-described first to fourth modifications are all based on the verification items of the logical device. Alternatively, they may be provided in some combinations.

(F) Description of Fifth Modification By the way, the above thread 13
Of the execution time required for a series of processes (“function”; “method”) described in “.
"Time budget", which is a budget for the time occupying the "), may be set for each" function ".

That is, as described above with reference to FIG. 8, when extracting the resources 14 from the architecture and mapping the processing to each resource 14 (after incorporating the resource request into the thread 13 in step S24), the estimation of each processing is performed. The time (time budget) is added to the thread 13 (step S25 'in FIG. 19).

For example, as shown in FIG.
If the “functions” described in “1” are processing 1 and processing 2, delay (time budget of processing 1) and delay
(Time budget of process 2) is set. Then, based on the specification 40, the execution time limit when the logic device processes n input data is set to T (step S2 in FIG. 19).
6b) Generate n data from the test bench 15 and execute the simulation as described above (step 26a).

Thereafter, the time t until all the threads 13 disappear is measured, and if the measured time t is within the time limit T, it can be determined that the design is correct (step S in FIG. 19).
From the YES route of 27 ', step S28'). vice versa,
If the measurement time t is longer than the time limit T, the specification 40
(Step S29 ′ from the NO route of step S27 ′ in FIG. 19).

In this way, it is possible to confirm at an early stage of design whether a logical device constituted by a combination of various "functions" satisfies the performance requirements required by the specification 40.

(G) Description of the Sixth Modification As shown in FIG. 21, for example, as shown in FIG. 21, before incorporating the resource request into the thread 13 in the above-described step S24, as shown in FIG. "Lifetime" may be set (step S21 '). Here, the “lifetime” represents the execution time limit of the “function”.

Then, as described above in the fifth modification, “time budget” is set in the thread 13 (step S
25 '), and a simulation is executed (step S26 "), and JudgeLifeT is executed before the thread 13 disappears.
If the ime () function (see FIG. 22) is called (for example, from the resource manager 12), in addition to the performance verification of the logical device by the above “time budget”, whether the “lifetime” set for the thread 13 has expired That is, it can be determined whether or not the processing has been completed within the “lifetime” (step S27 ″).

As a result of this determination, if the processing of the thread 13 is completed within the “lifetime”, the logical device satisfies the performance requirement relating to the real-time property required by the specification 40 (the design is correct). ) (From the YES route of step S27 ″ to step S2).
8 ″) On the contrary, if the processing is not completed within the “lifetime”, it can be determined that the performance requirement regarding the real-time property is not satisfied (step S29 ″).

As described above, in this modification, the thread 13
By setting "time budget" and "lifetime" in the initial stage of the design of the logical device, the performance requirements related to the processing time and the real-time performance of the entire logical device composed of a combination of various "functions" are set. Can be verified. In this modification,
Although both "time budget" and "lifetime" are set, of course, only "lifetime" is set,
Only the real-time property of the logical device may be verified.

In addition, these “time budgets”,
The “lifetime” is described in the thread 13 in the above-described example, but may be described in the resource 14. For example, if the data retention time in a storage element such as a memory or a buffer is specified, “time budget” and / or “lifetime” may be described for the storage element (resource). .

(H) Description of Seventh Modification In the above-described embodiment, a case has been described in which a series of processes (functions) required until the operation of the logical device is completed is represented by one thread 13; The “process” may be represented by a plurality of sequential threads 13 (thread “1” to thread “n”), for example, as schematically shown in FIG.

The operation in this case is as follows. That is,
The thread manager 11 generates the first thread "1" by an external input (input of the test data 16). Then, the thread “1” executes the process “1”, and allocates the resources 14 required for the process “1” to the resource manager 12.
Request to.

As a result, resource 1 is assigned to thread “1”.
When the thread “1” completes the process “1” after being allocated to “4” and is deleted by the thread manager 11, the next thread “2” is generated. Resource 1
When the thread 4 is not assigned, the thread 13 is controlled to the “waiting state” by the thread manager 11 in this case as well.

Hereinafter, thread "i" (where i = 1 to 1)
When n-1) disappears, the thread "i" generates the next thread "i + 1". In this way, a series of processes from the input of the logical device to the completion of the operation are represented in a series of sequential threads 13. That is, in the present modified example, the generation of the thread 13 performed by the thread manager 11 can also be generated from the thread 13.

Specifically, this can be realized by, for example, as shown in FIG.
()) And threads “1”, “2”, “3”,... Corresponding to process “1”, process “2”, process “3”,. I do.

As a result, each of the processes “1”, “2”,
One thread 13 is generated for each “3”,.
Each thread 13 is generated after the previous thread 13 finishes processing. Thereby, the dependency between the threads 13 becomes clearer than in the above-described embodiment.

The thread 13 configured as described above
Is incorporated into the system described above with reference to FIG. 3 to simulate a logic device in an early stage of design. That is, also in this case, until the processing of all the threads 13 is completed (all the threads 13 disappear), the thread manager 11 and the resource manager 12 cooperate to request the resource 14, allocate the resource 14, and allocate the resource 1.
By repeating the control of the execution state of the thread 13 according to the allocation result of No. 4, an operation simulation of the logical device is realized.

As described above, in this modified example, a series of processes from the input of the logical device to the completion of the operation is represented by a series of sequential threads 13 and simulation is performed.
After clarifying the dependency of processing required for a logic device, its function verification can be performed at an early stage of design.

(I) Description of Eighth Modification A series of processing up to the completion of the operation of the logical device is as follows.
For example, as schematically shown in FIG. 25, it may be represented by a plurality of threads 13 executed sequentially or in parallel. That is, when the thread 13 disappears as described above in the seventh modification, the thread 13 generates a plurality of threads 13 at the same time and causes each thread 13 to execute in parallel, and the plurality of threads 13 disappear. At this time, the next thread 13 may be sequentially generated.

The operation in this case is as follows. That is,
The thread manager 11 generates the first thread "1" by an external input (input of the test data 16). The thread “1” executes the process “1” and requests the resource 14 required for the process “1” from the resource manager 12.
Thereby, when the resource 14 is allocated to the thread “1” and the thread “1” completes the process “1”, when the thread “1” is deleted by the thread manager 11, the next threads “2” to “n” are simultaneously generated. I do. If the resource 14 is not allocated, also in this case,
The thread 13 is controlled by the thread manager 11 into a “waiting state”.

Thereafter, when the threads "2" to "n" proceed in parallel to complete the respective processes, and when these "2" to "n" are deleted by the thread manager 11, The next thread “n + 1” is generated.
Thereafter, similarly to the above-described seventh modification, when the previous thread 13 sequentially disappears, the next thread 13 is generated and the processing is executed.

For example, when the execution result of the processing A and the processing B is used by the processing C, an example of the configuration of the thread 13 is as shown in FIG. And the thread 13 configured in this way
Is applied to the system described above with reference to FIG. 3 to simulate the logic device in the initial stage of design.

That is, until the processing of all the threads 13 is completed (all the threads 13 disappear), the thread manager 11 and the resource manager 12 cooperate to request the resource 14, allocate the resource 14, and allocate the resource 14. By repeating the control of the execution state of the thread 13 according to the allocation result, the operation simulation of the logical device is realized.

As described above, in this modification, the thread 13
By introducing parallelism into the processing to achieve parallel processing, it is possible to realize an operation simulation of a logic device having more complicated "functions" than the above-described embodiment and the seventh modification.

(J) Description of Ninth Modification Next, the resource manager 12 described above
Although all the resources 14 are managed in common regardless of the four types, for example, as schematically shown in FIG. 27, the resource managers 12-1 to 12- -N, each independently manages (locally) one type of resource 14-j (j = 1 to n), and manages the resource 14-j in response to the request 19 to a local "arbitration rule". Requesting thread 13 according to
May be assigned.

In this case, the computer 1 (CPU 4) can be operated as follows. That is, the thread manager 11 generates the thread 13 by an external input (input of the test data 16; step S31) (step S32). Also in this case, the threads 13 progress independently, but the execution order of each thread is managed by the thread manager 11. Then, when it is necessary to secure the resource 14-j in order to proceed with the processing, the thread 13 requests the corresponding resource manager 12-j to secure the resource 14-j via the thread manager 11 (step S33; Resource request step).

The resource manager 12-j arbitrates the resource requests 19 within the unit time locally for each resource 14-j, and issues a response 21 to the thread manager 11 on the result of the allocation of the resource 14-j (step S3).
4: resource allocation step). The thread manager 11 controls the execution state of the thread 13 based on the response 21 from the resource manager 12-j (thread control step).

Also in this case, all the threads 13
Until the process is completed, as described above with reference to FIG. 3, the thread manager 11 and the resource manager 12-j cooperate to repeat the resource request, the resource allocation, and the control of the thread 13, thereby outputting the execution result. (Step S35), the operation simulation of the logic device is realized.

Here, specifically, the resource type is A,
When three types B and C (hereinafter referred to as resources A, B, and C) are used, the resource A managed (referenced) by the resource manager 12-j is configured (described) in the C ++ description style. It is configured as shown in FIG.
That is, the resource request queue 20 and the resource reply queue 22 described above are defined, and the request method 31
a ', a release method 31 for releasing the resource A
b ′, arbitration method 31c ′ for arbitrating resource A
Are defined respectively.

Here, the request method 31a 'is a function for performing an operation of registering the requested resource A and the thread ID of the thread 13 which issued the request 19 as a request message in the resource request queue 20. The method 31b 'is a function that releases the resource A and increases the number of released resources A by one.

The arbitration method 31c 'is a function for independently (locally) arbitrating the allocation of the resource A. According to the description in the dashed box 311', unless the resource request queue 20 is empty, the arbitration method 31c ' Queue 20
From the request 19 one by one, and if the number of requested resources A is 0 or less at that time, a broken line frame 312 '
Are executed, and if the number of requested resources A is 1 or more at that time, the description in the broken line frame 313 'is executed.

That is, if the number of requested resources A is 0 or less at that time, there is no newly allocated resource A, and “False” is stored in the resource reply queue 22 as the reply 21 of the resource allocation result. If the number of requested resources A is 1 or more, allocation is possible. Therefore, allocation is performed in accordance with the arbitration rule of the resource A, and the arbitration (allocation) result (“True”) is set as a response 21 as a resource reply queue 22. It is stored in. Note that resources B and C can be described in the same manner as described above (FIG. 28). So in this case,
Although the description amount is increased as compared with that shown in FIG. 6, the configuration is simplified.

The resources A,
If B and C are applied to the system shown in FIG. 3, the resource managers 12-j for each resource type perform resource allocation according to local "arbitration rules" having no dependency on each other. , C can be simulated without any dependency between the types.

(K) Description of the Tenth Modification The ninth modification described above is a case where the resource types do not depend on each other, but if there is a dependency, the local arbitration described above is not sufficient. It is. For example, "CP
A resource called "U" becomes a "logical operation unit (ALU; Arithmet
ic Logic Unit), “Bus (BUS)”, “Register (REGI
STER)), and a resource called "ALU" is further divided into "ADDER", "Subtractor (SUBTRACTER)", "AND circuit", "OR circuit" (OR )), The resource “CPU” is allocated to the thread 13 by assigning the resources “ALU”, “BUS”, and “REGISTE” in the lower hierarchy.
Resources such as "R", "ADDER", "AND", and "OR" must also be available.

As described above, when a resource has a dependency on 14-j, for example, as schematically shown in FIG. 29, the resource manager 12-j depends on the dependency.
Is hierarchized. That is, in the case of FIG.
Since there is no dependency between 4-1 and the resource 14-2, the resource managers 12-1 and 12-2 manage the resources 14-1 and 14-2 locally, respectively.
Since there is a dependency between the resources 14-1 and 14-2 and the resource 14-3, the upper layer resource manager 12-3 manages the lower layer resource managers 12-1 and 12-2. By doing so, it is possible to manage the resources 14-1 and 14-2 in the lower hierarchy.

Similarly, the resource manager 12-3
And the resource manager 12- (n-1) manages the resources 14-3 and 14- (n-1) locally independently of each other, but each of the upper layer resources 14-n
Resource managers 12-n in the upper hierarchy are replaced by the resource managers 12-3 and 1-2 in the lower hierarchy.
2- (n-1) is also managed.

As described above, when the resource 14-j has a dependency and cannot be solved by the local resource arbitration as described above, the resource 14-j is hierarchized to perform a global resource arbitration. In this case,
Calculator 1 (CPU 4) operates as follows. That is, the thread manager 11 receives the thread 1 by an external input (input of the test data 16; step S41).
3 is generated (step S42). Also in this case, the threads 13 progress independently, but the execution order of each thread is managed by the thread manager 11.

When the thread 13 needs to secure the resource 14-j in order to proceed with the processing, the thread 13 allocates the resource 14-j via the thread manager 11 to the resource manager 12 corresponding to the resource type.
-J (step S43; resource request step).

The resource manager 12-j allocates each resource request within a unit time to the resource 1
4-j Local arbitration. Local resource 1
The allocation result of 4-j is transmitted to the resource manager 12-k (k = j + 1) of the upper layer, and the resource manager 12-k of the upper layer transmits the resource manager 12-k of another related (dependent) type of resource 12-k. The resource allocation of the hierarchy is determined in consideration of the allocation result.

Thereafter, similarly, the result of resource allocation of the lower layer is sequentially propagated to the upper layer, and finally, the resource manager 12-n of the highest layer transmits the last result of allocation to the thread manager 11. Answer (step S44; resource allocation step).

That is, in this modification, in the resource allocation step S44, the resource manager 12-k of the upper layer manages the resource 14-k managed by itself and the resource 14-j managed by the resource manager 12-j of the lower layer. The resource allocation is performed in consideration of the dependency between the resources.

Then, the thread manager 11 controls the execution state of the thread 13 based on the response 21 from the resource manager 12-j (thread control step). After that, the thread manager 11 and the resource manager 1
By repeating the above-described resource request, resource allocation, and control of the thread 13 in cooperation with 2-j, an execution result (simulation result) is output (step S45), and simulation of the logical device is realized.

As described above, in this modification, the resource 14
The resource 14-j and the resource manager 12-j are hierarchized according to the dependency of the resource manager 12-j. Resource 14-j can be assigned taking into account
Global arbitration between resource types can be performed, an operation simulation of a logic device having more complicated resource dependencies can be realized, and functions and performance verification can be performed at an early design stage.

The seventh to tenth modifications described above may of course be applied to any of the first to sixth modifications described above, and the advantages and effects of the respective combinations are obtained. As described above, according to the operation simulation method of the logic device of the present embodiment and each of its modifications, the simulation of the function level is performed in the initial stage of the design of the logic device to confirm the “function” and realize the “function” The validity of the architecture to be performed can be confirmed at the initial stage of design, and the function verification and performance evaluation of the logic device can be performed.

In addition, it is possible to confirm whether or not the “function” has been accurately realized in the initial stage of the design, and to confirm the safety of the design. In addition, even when the architecture needs to be changed, the description of the “function” is hardly changed, and the resources 14 (14-j),
Just change "arbitration rules", resource requirements, etc.
Since the design can be easily re-verified, it is possible to avoid an increase in design cost due to a change in the description of the “function” as in the related art.

(L) Others In the above-described embodiment and each of the modified examples, the C ++ description style is used as a specific example of the description of the simulation program 10. However, it is needless to say that the description based on another programming language such as Java is used. It goes without saying that the same operation and effect as described above can be obtained even if the style is applied. The present invention is not limited to the above-described embodiment and each of the modifications, and may be variously modified and implemented in addition to the above without departing from the gist of the present invention.

(M) Supplementary Note (Supplementary Note 1) A thread manager that controls a thread, which is a unit of execution of a program, indicates a function required until the operation of the logical device is completed in accordance with the design specification of the logical device. Requesting a hardware resource required for execution of the hardware resource from a resource manager that manages the hardware resource, and the resource manager sends the hardware resource corresponding to the request to the thread according to a predetermined rule. Allocating a resource, and the thread manager controls a thread execution state according to a result of the allocation by the resource manager, and the thread manager and the resource until the execution of the thread is completed. Manager By repeating the steps described above and,
A method for simulating the operation of a logic device, comprising simulating the operation of the logic device until the operation is completed.

(Supplementary note 2) The operation simulation method for a logic device according to supplementary note 1, wherein the series of functions described above are represented by a plurality of sequential threads. (Supplementary note 3) The operation simulation method for a logic device according to supplementary note 1, wherein the series of functions described above are represented by a plurality of threads that are executed sequentially or in parallel.

(Supplementary Note 4) A plurality of the resource managers are provided corresponding to the types of the hardware resources, and in the resource allocating step, each of the resource managers described above manages the hardware resources managed by itself. Assigned to the thread according to a predefined local rule,
4. The operation simulation method for a logic device according to any one of supplementary notes 1 to 3.

(Supplementary Note 5) A plurality of the resource managers are provided corresponding to the types of the hardware resources, and each resource manager is hierarchized according to the dependency of the hardware resources. Wherein the resource manager allocates the hardware resource in consideration of the dependency between the hardware resource managed by the resource manager and the hardware resource managed by the lower-level resource manager. 4. The operation simulation method for a logic device according to any one of claims 1 to 3.

(Supplementary note 6) The resource manager monitors a resource request in the resource requesting step and determines a deadlock state of a resource request among a plurality of threads based on the monitoring result.
6. The operation simulation method for a logic device according to any one of claims 1 to 5. (Supplementary Note 7) The resource manager monitors a read / write request for the hardware resource allocated by the resource request in the resource request step, and performs a read / write operation on the hardware resource of a plurality of threads based on the monitoring result. 6. The operation simulation method for a logical device according to claim 1, wherein a race condition is determined.

(Supplementary note 8) The resource manager according to any of Supplementary notes 1 to 5, wherein the resource manager monitors the number of resource requests for the hardware resource, and detects a bottleneck of the thread based on the monitoring result. Or 1
The operation simulation method of the logic device according to the paragraph. (Supplementary note 9) The resource manager according to any one of Supplementary notes 1 to 5, wherein the resource manager monitors the number of resource requests for the hardware resource, and detects blocking of the resource request based on the monitoring result. 4. The operation simulation method for a logic device according to claim 1.

(Supplementary note 10) The thread according to any one of Supplementary notes 1 to 5, characterized in that the thread is provided with a budget for time occupying the hardware resources allocated by the resource manager. A logic device operation simulation method. (Supplementary note 11) Any one of Supplementary notes 1 to 5, wherein the thread is given an execution time limit of the function.
The operation simulation method of the logic device according to the paragraph.

(Supplementary Note 12) Any one of Supplementary Notes 1 to 11
And a comparison step of comparing a simulation result by the operation simulation method described in the section with an operation prediction value of the logical device, and an output step of outputting the comparison result in the comparison step to an external device. ,
A logic device operation simulation method.

(Supplementary Note 13) A thread manager that controls a thread, which is a unit of execution of a program, and a resource manager that manages hardware resources necessary for the execution of the thread are provided. A resource requesting unit for requesting the resource manager for hardware resources necessary for executing a thread representing a function required until the operation of the logical device according to the design specification, and a request for the resource by the resource requesting unit. A thread control means for controlling an execution state of the thread according to a result of assignment by the resource manager, and the resource manager assigning a hardware resource corresponding to the request to the thread according to a predetermined rule With allocation means The thread manager and the resource manager cooperate to repeatedly execute the resource request and the control of the thread execution state until the execution of the thread is completed, thereby simulating the operation of the logical device until the operation is completed. Characterized in that
An operation simulation device for logic devices.

(Supplementary Note 14) A computer-readable recording medium on which an operation simulation program for a logic device is recorded, wherein the computer is provided with a thread manager for controlling a thread which is an execution unit of the program, and a computer for executing the thread. And a thread manager that functions as a resource manager that manages the necessary hardware resources, and that is used by the thread manager to execute threads representing functions required until the operation of the logical device is completed according to the design specifications of the logical device. A resource requesting step of requesting a resource from the resource manager; a resource allocating step of the resource manager allocating a hardware resource corresponding to the request to the thread according to a predetermined rule; Executing a thread control step of controlling the execution state of the thread according to the allocation result by the source manager, and cooperating with the resource manager in cooperation with the resource manager until the processing of the thread is completed. A computer-readable recording medium on which a program for simulating an operation of a logic device is recorded, wherein a program for simulating an operation of the logic device up to the completion of the operation by being repeatedly executed is recorded.

(Supplementary Note 15) The above-described series of functions is represented by a plurality of sequential threads.
A computer-readable storage medium storing the logic device operation simulation program according to supplementary note 14. (Supplementary note 16) The computer-readable recording of the logic device operation simulation program according to Supplementary note 14, wherein the series of functions described above is represented by a plurality of threads that are sequentially or concurrently executed. recoding media.

(Supplementary Note 17) The resource manager
A plurality of hardware resources are provided corresponding to the types of the hardware resources, and in the resource allocation step, each of the resource managers allocates the hardware resources managed by itself to the thread according to a predetermined local rule. 17. A computer-readable recording medium recording an operation simulation program for a logic device according to any one of Supplementary Notes 14 to 16, characterized by the above-mentioned.

(Supplementary Note 18) The resource manager
A plurality of hardware managers are provided corresponding to the types of the hardware resources, and each resource manager is hierarchized according to the dependency of the hardware resources. 17. The logical device according to any one of appendices 14 to 16, wherein the hardware resource is allocated in consideration of a dependency relationship between the hardware resource and a hardware resource managed by a lower layer resource manager. A computer-readable recording medium on which an operation simulation program of the present invention is recorded.

(Supplementary Note 19) The resource manager is
Monitoring a resource request by the resource request step;
19. A computer-readable recording program for the operation simulation program for a logical device according to any one of appendices 14 to 18, wherein a deadlock state of a resource request between a plurality of threads is determined based on the monitoring result. recoding media.

(Supplementary Note 20) The resource manager
Monitoring a read / write request for the hardware resource allocated by the resource request in the resource request step, and determining a race condition of a read / write operation on the hardware resource of a plurality of threads based on the monitoring result. Supplementary notes 14-1
A computer-readable recording medium recording the operation simulation program for a logic device according to any one of claims 8 to 13.

(Supplementary Note 21) The resource manager is
19. The simulation program according to claim 14, wherein the number of resource requests for the hardware resource is monitored, and a bottleneck of the thread is detected based on the monitoring result. A computer-readable recording medium on which is recorded.

(Supplementary Note 22) The resource manager is
19. The logical device operation simulation program according to any one of claims 14 to 18, wherein the number of resource requests for the hardware resource is monitored, and blocking of the resource request is detected based on the monitoring result. A computer-readable recording medium on which is recorded.

(Supplementary note 23) The thread according to any one of Supplementary notes 14 to 18, characterized in that the thread is provided with a budget for time occupying the hardware resources allocated by the resource manager. A computer-readable recording medium on which an operation simulation program for a logic device is recorded. (Supplementary note 24) A computer-readable recording recording a logic device operation simulation program according to any one of Supplementary notes 14 to 18, wherein the thread is given an execution time limit of the function. Medium.

(Supplementary Note 25) A computer-readable recording medium storing an operation simulation program for a logic device, wherein
A comparison step of comparing a simulation result by the operation simulation method according to any one of the above with an operation prediction value of the logic device, and an output step of outputting the comparison result in the comparison step to an external device. A computer-readable recording medium on which an operation simulation program for a logic device is recorded, wherein the operation simulation program is recorded.

(Supplementary Note 26) An operation simulation program for a logical device, wherein a computer is used as a thread manager that controls a thread that is a unit of execution of the program and a resource manager that manages hardware resources necessary for execution of the thread. A resource request for causing the thread manager to function, and requesting the resource manager for hardware resources necessary for executing a thread representing a function required until the operation of the logical device is completed according to the design specification of the logical device. A resource allocation step in which the resource manager allocates a hardware resource according to the request to the thread according to a predetermined rule; and the thread manager controls the resource in response to the allocation result by the resource manager. A thread control step for controlling the execution state of Red, and the thread manager and the resource manager cooperate with each other to repeatedly execute the above-described steps until the processing of the thread is completed. An operation simulation program for a logic device, characterized in that the operation up to the completion of the operation is simulated.

(Supplementary Note 27) The above series of functions are represented by a plurality of sequential threads.
27. An operation simulation program for a logic device according to attachment 26. (Supplementary note 28) The operation simulation program for a logic device according to supplementary note 26, wherein the series of functions described above is represented by a plurality of threads that are sequentially or concurrently executed.

(Supplementary Note 29) The resource manager is
A plurality of hardware resources are provided corresponding to the types of the hardware resources, and in the resource allocation step, each of the resource managers allocates the hardware resources managed by itself to the thread according to a predetermined local rule. 29. The operation simulation program for a logic device according to any one of supplementary notes 26 to 28, wherein:

(Supplementary Note 30) The resource manager
A plurality of hardware managers are provided corresponding to the types of the hardware resources, and each resource manager is hierarchized according to the dependency of the hardware resources. 29. The logical device according to any one of supplementary notes 26 to 28, wherein the hardware resource is allocated in consideration of a dependency relationship between the hardware resource and a hardware resource managed by a lower layer resource manager. Operation simulation program.

(Supplementary Note 31) The resource manager is
Monitoring a resource request by the resource request step;
31. The operation simulation program for a logical device according to any one of appendices 26 to 30, wherein a deadlock state of a resource request between a plurality of threads is determined based on the monitoring result. (Supplementary Note 32) The resource manager monitors a read / write request for the hardware resource allocated by the resource request in the resource request step, and performs a read / write operation on the hardware resource of a plurality of threads based on the monitoring result. 31. The operation simulation program for a logic device according to any one of supplementary notes 26 to 30, wherein a race condition is determined.

(Supplementary Note 33) The resource manager
31. The logical device operation simulation program according to any one of supplementary notes 26 to 30, wherein the number of resource requests for the hardware resource is monitored, and a bottleneck of the thread is detected based on the monitoring result. . (Supplementary note 34) Any one of Supplementary notes 26 to 30, wherein the resource manager monitors the number of resource requests for the hardware resource, and detects blocking of the resource request based on the monitoring result. An operation simulation program for a logic device according to item 1.

(Supplementary note 35) The thread according to any one of Supplementary notes 26 to 30, wherein the thread is provided with a budget for time occupying the hardware resources allocated by the resource manager. An operation simulation program for a logic device. (Supplementary note 36) The operation simulation program for a logic device according to any one of Supplementary notes 26 to 30, wherein an execution time limit of the function is given to the thread.

(Supplementary Note 37) This is an operation simulation program for a logic device.
11. A comparison step of comparing a simulation result by the operation simulation method according to any one of 11 with an operation prediction value of the logic device, and an output step of outputting the comparison result in the comparison step to an external device. An operation simulation program for a logic device.

[0176]

As described in detail above, according to the present invention,
A description of hardware resources (hereinafter, simply referred to as “resources”) required by “functions” to be implemented in a logical device is not given to a thread, and each time the thread is executed, necessary resources are allocated. Simulating the operation until the operation of the logical device is completed by the thread manager and the resource manager cooperating and repeatedly controlling the execution state of the thread until the execution of the thread is completed while dynamically assigning the resource by the resource manager. Therefore, the following advantages can be obtained.

By comparing with the operation prediction value of the logic device,
It is possible to confirm the "function" and confirm the validity of the architecture for realizing the "function" at an early stage of design, and perform function verification and performance evaluation of the logical device. By comparing with the predicted operation value of the logic device, it is possible to confirm whether or not the “function” was correctly realized in the initial stage of the design.

Even when the architecture needs to be changed, the description of the "function" is hardly changed, and the resources, the resource allocation rules, the thread scheduling, the resource requests, and the like are changed according to the architecture change. Only by doing so, it is possible to easily re-verify the design, and it is possible to avoid an increase in design cost due to a change in the description of the “function”.

The search for an architecture suitable for the “function”, the performance evaluation of the architecture when mapping the “function” to the architecture, the verification of the timing at the initial design stage, and the like can be performed. Note that a series of “functions” required until the operation of the logical device is completed may be represented by a plurality of sequential thread groups, or may be represented by a plurality of sequential or concurrently executed thread groups. You may. In the former case, it is possible to simulate the operation of the logic device with more clarified dependencies on the "functions", and in the latter case, it is possible to simulate the operation of a logic device with a more complex "function" configuration become.

A plurality of resource managers may be provided corresponding to the types of resources. For example, resources managed by each resource may be assigned to a thread according to a predetermined local rule, or each resource manager may be assigned to a thread. Can be hierarchized in accordance with resource dependencies, and resources can be allocated in consideration of the dependencies between the resources managed by the respective resources and the resources managed by the lower-level resource managers.

In the former case, it is possible to simulate a logical device having no dependency on resources by a simple description (configuration), and in the latter case, it is possible to arbitrate global resource allocation in consideration of resource dependencies. . Further, the resource manager can monitor the resource request and determine a deadlock state of the resource request among a plurality of threads based on the monitoring result. In this case, the deadlock state of the deadlock state is determined in an initial stage of design. The possibility of occurrence can be detected, and the function of the logic device can be verified.

Further, the resource manager monitors a read / write request for a resource allocated by the resource request, and determines a contention state of a read / write operation for a resource of a plurality of threads based on the monitoring result. In this case, when a plurality of threads sequentially perform a write operation or a read operation on a resource, it is determined whether or not the order is correct, and it is verified whether or not the designed logical device operates correctly. can do.

Further, the resource manager can monitor the number of resource requests for resources and detect a bottleneck of a thread based on the monitoring result. In this case, the resource with the highest access frequency is a logical device. It can be inferred that there is a possibility that the bottleneck has occurred, and the performance verification of the logic device (verification of the presence or absence of the bottleneck) can be realized in the initial stage of the design of the logic device.

Further, the resource manager can monitor the number of resource requests for resources and detect blocking of resource requests based on the monitoring result. In this case, the performance of the logical device can be evaluated by detecting the possibility of blocking of the resource request.

Further, the above thread may be given a budget for the time for occupying the resources allocated by the resource manager. In this way, it is possible to confirm at an early stage of the design whether or not a logical device composed of a combination of various “functions” satisfies the performance requirements relating to the processing time required by the design specifications. .

The above thread may be given a time limit for executing the above function, and in this case, it is verified whether or not the logic device satisfies the real-time performance requirement in the initial stage of design. It is possible to do. Further, the above-described operation simulation method may be provided by an operation simulation program that causes a computer to operate as described above and a computer-readable recording medium that records the operation simulation program. If the computer is installed (if installed), the computer can be made to function as a device that executes the above-described logic device operation simulation method (logic device operation simulation device), which greatly contributes to its widespread use.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a configuration of a computer (information processing device) such as a personal computer according to a first embodiment of the present invention.

FIG. 2 is an object model diagram for explaining an operation simulation program according to the first embodiment of the present invention.

FIG. 3 is a diagram for explaining an operation of a computer based on the operation simulation program shown in FIG. 2 (operation simulation method of a logic device);

FIG. 4 is a block diagram showing a configuration focusing on a main part of the computer shown in FIG. 1;

FIG. 5 is a diagram illustrating a description example of a thread according to the first embodiment;

FIG. 6 is a diagram illustrating a description example of a resource manager according to the first embodiment.

FIG. 7 is a block diagram for explaining “functions” necessary for the logic device (QoS system) according to the first embodiment.

FIG. 8 is a flowchart for explaining a design procedure (operation simulation method) of the logic device (QoS system) according to the first embodiment.

FIG. 9 is a block diagram showing a configuration focusing on a main part of a computer according to a first modification of the first embodiment.

FIG. 10 is a diagram illustrating a description example of a thread according to a first modification;

FIGS. 11A and 11B are resource allocation graphs for explaining detection of a deadlock of a thread according to a first modification;

FIG. 12 is a block diagram illustrating a configuration focusing on a main part of a computer according to a second modification of the first embodiment.

FIG. 13 is a diagram illustrating a description example of a resource request according to a second modification.

FIG. 14 is a diagram illustrating a description example of a resource according to a second modified example.

FIG. 15 is a block diagram showing a configuration focusing on a main part of a computer according to a third modification of the first embodiment.

FIG. 16 is a diagram illustrating a description example of a resource according to a third modification.

FIG. 17 is a block diagram illustrating a configuration focusing on a main part of a computer according to a fourth modification of the first embodiment.

FIG. 18 is a diagram illustrating a description example of a resource according to a fourth modification.

FIG. 19 is a flowchart illustrating a design procedure (operation simulation method) of a logic device according to a fifth modification of the first embodiment.

FIG. 20 is a diagram illustrating a description example of a thread according to a fifth modification;

FIG. 21 is a flowchart illustrating a design procedure (operation simulation method) of a logic device according to a sixth modification of the first embodiment.

FIG. 22 is a diagram illustrating a description example of a thread according to a sixth modification;

FIG. 23 is a schematic diagram illustrating a thread generation method according to a seventh modification of the first embodiment.

FIG. 24 is a diagram illustrating a description example of a thread according to a seventh modification;

FIG. 25 is a schematic diagram for explaining a thread generation method according to an eighth modification of the first embodiment.

FIG. 26 is a diagram illustrating a description example of a thread according to an eighth modification;

FIG. 27 is a block diagram illustrating a configuration focusing on a main part of a computer according to a ninth modification of the first embodiment.

FIG. 28 is a diagram illustrating a description example of a resource according to a ninth modification.

FIG. 29 is a block diagram illustrating a configuration focusing on a main part of a computer according to a tenth modification of the first embodiment.

FIGS. 30A and 30B are flowcharts for explaining a conventional logic device design procedure.

FIG. 31 is a diagram for describing a problem caused by a conventional logic device design procedure.

[Explanation of symbols]

REFERENCE SIGNS LIST 1 Computer (information processing device; logic device operation simulation device) 2 Computer body 3 Display (display device; external device) 4 CPU 5 Main storage unit (memory) 6 Secondary storage device (hard disk) 7 Floppy disk (FD) drive Reference Signs List 8 internal bus 9 floppy disk (computer-readable recording medium) 10, 51 logic device operation simulation program 11 thread manager 12, 12-1 to 12-n resource manager 13 thread 14, 14-1 to 14-n resource ( Hardware resources) 15 test bench 16 test data 17 input queue 18 execution queue 19 request 20 resource request queue 21 reply 22 resource reply queue 31a, 31a 'request method 31b, 31b' release method 31 , 31c 'arbitration method 41 packet 42 classification function 43 queuing function 44 dequeue function 45 queue 110 thread generation means 111 resource request means 112 thread control means 121 resource allocation means 122 deadlock detection mechanism 123 read / write detection mechanism 124 bottleneck Detection mechanism 125 Blocking detection mechanism

Continued on the front page (72) Inventor Kazuhiro Matsuzaki 4-1-1, Kamidadanaka, Nakahara-ku, Kawasaki-shi, Kanagawa Prefecture Inside Fujitsu Limited (72) Inventor Takeshi Doi 4-1-1, Kamiodanaka, Nakahara-ku, Kawasaki-shi, Kanagawa F-term in Fujitsu Limited (reference) 5B046 AA08 BA03 5B098 GA05 GD01 GD14 GD24

Claims (12)

[Claims] A thread manager for controlling a thread, which is an execution unit of a program, includes a hardware necessary for executing a thread representing a function required until the operation of the logical device is completed according to a design specification of the logical device. A resource requesting step of requesting a hardware resource from a resource manager that manages the hardware resource; and a resource allocating step of the resource manager allocating the hardware resource corresponding to the request to the thread according to a predetermined rule. The thread manager having a thread control step of controlling an execution state of the thread according to a result of allocation by the resource manager, and the thread manager and the resource manager cooperating until the execution of the thread is completed Each of the above steps Repeating the steps to simulate the operation of the logical device until the operation is completed,
A logic device operation simulation method. 2. The resource manager according to claim 1, wherein the resource manager monitors a resource request in the resource request step, and determines a deadlock state of the resource request among a plurality of threads based on the monitoring result. Operation simulation method for a logic device. 3. The resource manager monitors a read / write request for a hardware resource allocated by the resource request in the resource request step, and performs a read / write operation on a hardware resource of a plurality of threads based on the monitoring result. 2. The operation simulation method for a logic device according to claim 1, wherein a race condition is determined. 4. The logical device according to claim 1, wherein the resource manager monitors the number of resource requests for the hardware resource, and detects a bottleneck of the thread based on the monitoring result. Behavior simulation method. 5. The logical device according to claim 1, wherein the resource manager monitors the number of resource requests for the hardware resource and detects blocking of the resource request based on the monitoring result. Behavior simulation method. 6. The method according to claim 1, wherein the thread is provided with a budget for time occupying the hardware resources allocated by the resource manager. 7. The operation simulation method according to claim 1, wherein the thread is given an execution time limit of the function. 8. A comparison step of comparing a simulation result obtained by the operation simulation method according to claim 1 with an operation prediction value of the logic device, and the comparison result in the comparison step is stored in an external device. And an output step of outputting to a device. 9. A computer-readable recording medium recording an operation simulation program of a logic device, comprising: a thread manager for controlling a thread as an execution unit of the program; and a hardware necessary for executing the thread. The thread manager functions as a resource manager that manages hardware resources, and the thread manager allocates hardware resources necessary for execution of threads representing functions required until the operation of the logical device is completed according to the design specifications of the logical device. A resource requesting step for requesting the resource manager; a resource allocating step in which the resource manager allocates a hardware resource corresponding to the request to the thread according to a predetermined rule; Executing a thread control step of controlling the execution state of the thread according to the allocation result by the manager, and repeating the above steps in cooperation with the thread manager and the resource manager until the execution of the thread is completed. A recording medium storing an operation simulation program for a logic device, wherein the program stores a program for simulating the operation of the logic device up to the completion of the operation. 10. A computer-readable recording medium on which an operation simulation program for a logic device is recorded, wherein the computer stores a simulation result by the operation simulation method according to claim 1 and the logic. An operation simulation program for executing a comparison step of comparing an operation predicted value of the apparatus with an output step of outputting a comparison result in the comparison step to an external apparatus is recorded. A computer-readable recording medium recording an operation simulation program. 11. A program for simulating the operation of a logical device, wherein a computer functions as a thread manager that controls a thread that is a unit of execution of the program and a resource manager that manages hardware resources necessary for executing the thread. A resource requesting step of requesting the resource manager for hardware resources required for execution of a thread representing functions required until the operation of the logical device according to the design specification of the logical device. A resource allocation step in which the resource manager allocates a hardware resource in response to the request to the thread according to a predetermined rule; and Executing a thread control step for controlling a line state, and repeatedly executing each of the above steps in cooperation with the thread manager and the resource manager until the processing of the thread is completed. An operation simulation program for a logic device, characterized in that the operation up to completion is simulated. 12. An operation simulation program for a logic device, comprising: a computer for comparing a simulation result by the operation simulation method according to claim 1 with a predicted operation value of the logic device. An operation simulation program for a logic device, characterized by executing a step and an output step of outputting a comparison result in the comparison step to an external device.