WO2004038620A1 - システム開発方法及びデータ処理システム - Google Patents

システム開発方法及びデータ処理システム Download PDF

Info

Publication number
WO2004038620A1
WO2004038620A1 PCT/JP2003/012840 JP0312840W WO2004038620A1 WO 2004038620 A1 WO2004038620 A1 WO 2004038620A1 JP 0312840 W JP0312840 W JP 0312840W WO 2004038620 A1 WO2004038620 A1 WO 2004038620A1
Authority
WO
WIPO (PCT)
Prior art keywords
bus
cfg
description
parameter
transition
Prior art date
Application number
PCT/JP2003/012840
Other languages
English (en)
French (fr)
Inventor
Tadaaki Tanimoto
Masurao Kamada
Original Assignee
Renesas Technology Corp.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Renesas Technology Corp. filed Critical Renesas Technology Corp.
Priority to AU2003272931A priority Critical patent/AU2003272931A1/en
Priority to JP2004546404A priority patent/JP3899104B2/ja
Priority to US10/533,062 priority patent/US20060015858A1/en
Publication of WO2004038620A1 publication Critical patent/WO2004038620A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/327—Logic synthesis; Behaviour synthesis, e.g. mapping logic, HDL to netlist, high-level language to RTL or netlist
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking
    • G06F30/3323—Design verification, e.g. functional simulation or model checking using formal methods, e.g. equivalence checking or property checking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/51—Source to source

Definitions

  • the present invention relates to a method for developing a digital circuit from a language capable of describing parallel operation, and further relates to a data processing system for performing hardware synthesis of a digital circuit from a language capable of describing parallel operation.
  • Patent document 1 Japanese Patent Application Laid-Open No. 2002-279333
  • Patent Document 2 Japanese Patent Application Laid-Open No. 2000-035898
  • Patent Document 3 Japanese Patent Application Laid-Open No. 07-084832 Disclosure of the Invention
  • An object of the present invention is to reduce the man-hour for hardware design of a bus system using a program language capable of describing parallel operations such as Java (registered trademark). To reduce.
  • An object of the present invention is to provide a new design method of a bus system that satisfies real-time constraints, using a programming language capable of describing parallel operations and a parameter 'model checking'.
  • Another object of the present invention is to provide a new design method by fusing the model checking technology and the hardware synthesis technology.
  • Still another object of the present invention is to realize modeling by a programming language capable of describing parallel operation and verification by parameter-based model checking for a bus system having real-time constraints, and also realize hardware synthesis. Is to do.
  • a program description that defines a plurality of devices using a programming language that can describe parallel operations is input, the input program description is converted to an intermediate expression, and the intermediate expression satisfies the real-time constraint.
  • Parameter Generates an evening and synthesizes a circuit description using a hardware description language based on the generated parameter.
  • the intermediate representation is a concurrent control flow flag, a concurrent parameter-with-time automaton, or a parameter-with-time automaton.
  • parameter-based model checking is performed for the parameter generation.
  • a new design method can be provided by fusing the model checking technology and the hardware synthesis technology.
  • the real-time constraint is given by RPCTL.
  • the program description defines a device using a run method and defines clock synchronization of the device using barrier synchronization.
  • FIG. 1 is a flowchart illustrating the entire design method according to the present invention.
  • FIG. 2 is an explanatory diagram exemplifying a design pattern of modeling a single bus system in the Java language.
  • FIG. 3 is an explanatory diagram showing an example in which a clock synchronization method based on barrier synchronization is used as a synchronization mechanism in modeling.
  • FIG. 4 is an explanatory view exemplifying a description of modeling for realizing writing of a value to a register.
  • FIG. 5 is an explanatory diagram exemplifying a method for managing acquisition of a bus right.
  • FIG. 6 is a call graph showing the calling relationship of each method in FIG.
  • FIG. 7 is an explanatory diagram exemplifying a Java language description of a bus right acquisition mechanism.
  • FIG. 8 is an explanatory diagram of a Java language description that is a continuation of FIG.
  • Fig. 9 is an explanatory diagram of the method for managing bus release.
  • FIG. 10 is a call graph showing the calling relationship of each method in FIG. It is.
  • FIG. 11 is an explanatory diagram exemplifying a Java language description of a bus right release mechanism.
  • FIG. 12 is an explanatory diagram of the Java language code of the sync-read method.
  • FIG. 13 is an explanatory diagram showing an example of a description of the sync-read method in run ().
  • Fig. 14 is an explanatory diagram showing the Java language code of sync-burst-read.
  • FIG. 15 is an explanatory diagram showing a Java language code of endBurstAccess.
  • FIG. 16 is an explanatory diagram showing a Java language code of freeBurstBusLock.
  • FIG. 17 is an explanatory diagram showing a description example of burst read in run ().
  • FIG. 18 is an explanatory diagram showing the Java language code of sync-write.
  • FIG. 19 is an explanatory diagram showing an example of a sync-write method description in run ().
  • FIG. 20 is an explanatory diagram showing a sync-burst-write Java language code.
  • FIG. 21 is an explanatory diagram showing a description example of a burst write in run ().
  • FIG. 22 is an explanatory diagram showing schematic specifications of an implementation example using Java language description.
  • FIG. 23 is an explanatory diagram showing a part of an implementation example of the run () method relating to the command interface.
  • FIG. 24 is an explanatory diagram showing a continuation of the mounting example of FIG.
  • FIG. 25 is an explanatory diagram showing a continuation of the implementation example of FIG.
  • FIG. 26 is an explanatory diagram showing a continuation of the implementation example of FIG.
  • FIG. 27 is an explanatory diagram showing an implementation example of the nm () method for unified memory.
  • FIG. 28 is an explanatory diagram showing an implementation example of the run () method relating to the graphic drawing unit.
  • FIG. 29 is an explanatory diagram showing a continuation of the implementation example of FIG.
  • FIG. 30 is an explanatory diagram showing a continuation of the implementation example of FIG.
  • FIG. 31 is an explanatory diagram showing the continuation of the example of FIG. 30.
  • FIG. 32 is an explanatory diagram showing a continuation of the example of FIG. 31 implementation.
  • FIG. 33 is an explanatory diagram showing an implementation example of the run () method for the display unit. .
  • FIG. 34 is an explanatory diagram showing a continuation of the mounting example of FIG.
  • FIG. 35 is an explanatory diagram exemplifying the details of the conversion process to the intermediate representation as a whole.
  • FIG. 36 is an explanatory diagram illustrating the format of C-CFG.
  • Fig. 37 is an explanatory diagram showing the handling of synchronized (for hardware synthesis).
  • Fig. 38 is an explanatory diagram showing the handling of synchronized (parametric 'model checking').
  • 'Fig. 39 is an explanatory diagram showing CFG in the case of Co Marauding and Interface.
  • FIG. 40 is an explanatory diagram showing an example of a CFG for hardware synthesis in relation to Co Marauders and Interface.
  • FIG. 41 is an explanatory diagram showing an example of CFG for parametric model checking.
  • FIG. 42 is an explanatory diagram illustrating a CFG relating to a Graphics Rendering Unit (Graphics Rendering Unit).
  • FIG. 43 is an explanatory diagram showing a continuation of C F and G in FIG. .
  • FIG. 44 is an explanatory diagram showing an example of a CFG for parametric model checking.
  • FIG. 45 is an explanatory view showing a continuation of the CFG of FIG. 45.
  • FIG. 46 is an explanatory diagram exemplifying CFG regarding the display unit (Display Unit).
  • FIG. 47 is an explanatory diagram showing an example of a CFG for parametric model checking.
  • FIG. 48 is an illustration exemplifying the connection state of each start node in the CFG of the Command Interface, the CFG of the Graphics Rendering Unit, and the CFG of the Display Unit.
  • FIG. 49 is an explanatory diagram exemplifying a fixed priority scheduler.
  • FIG. 50 is a first explanatory diagram showing, in order, an abstraction of CFG of a command interface.
  • FIG. 51 is an explanatory view showing a sequel to FIG. 50.
  • FIG. 52 is an explanatory view showing a continuation of FIG. 51.
  • FIG. 53 is an explanatory view showing a sequel to FIG. 52.
  • FIG. 54 is an explanatory view showing a sequel to FIG. 53.
  • FIG. 55 is an explanatory view showing a sequel to FIG. 54.
  • FIG. 56 is an explanatory view showing a sequel to FIG. 55.
  • FIG. 57 is an explanatory diagram exemplifying the result of the abstraction processing on the CFG by the Graphics Rendering Unit (Graphics Rendering Unit).
  • FIG. 58 is an explanatory diagram exemplifying the result of the abstraction processing for the CFG of the display unit (Display Unit).
  • FIG. 59 is an explanatory diagram showing, in order, the conversion of CFG into TNFA in the command interface (Command Interface).
  • FIG. 60 is an explanatory view showing a sequel to FIG. 59.
  • FIG. 61 is an explanatory view showing a sequel to FIG. 60.
  • Fig. 62 is an explanatory diagram showing the conversion of CFG to TNFA of the Graphics Rendering Unit in order.
  • FIG. 63 is an explanatory view showing a sequel to FIG. 62.
  • FIG. 64 is an explanatory view showing a sequel to FIG. 63.
  • FIG. 65 is an explanatory view showing a sequel to FIG. 64.
  • FIG. 66 is an explanatory diagram illustrating, in order, a state of conversion of CFG of the display unit (Display Unit) to TNFA.
  • FIG. 67 is an explanatory view showing a sequel to FIG.
  • FIG. 68 is an explanatory view showing a sequel to FIG. 67.
  • FIG. 69 is an explanatory diagram showing a configuration example of the product TNF A of the TNF A obtained in FIG. 61, FIG. 64, and FIG.
  • FIG. 70 is an explanatory diagram showing a process of deleting transition branches that do not satisfy the constraints at the stage of constructing the product TNF A when an upper limit is given to the parameter overnight.
  • FIG. 71 is an explanatory view showing a sequel to FIG. 70.
  • FIG. 72 is an explanatory view showing a sequel to FIG. 71.
  • FIG. 73 is an explanatory view showing a sequel to FIG. 72.
  • FIG. 74 is an explanatory view showing a sequel to FIG.
  • FIG. 75 is an explanatory view showing a sequel to FIG. 74.
  • FIG. 76 is an explanatory view showing a sequel to FIG. 75.
  • FIG. 77 is an explanatory diagram showing a part of the progress of processing when the Abstraction of TNFA is called in a timely manner by C-TNFA2TNFA.
  • FIG. 78 is an explanatory view showing a sequel to FIG. 77.
  • FIG. 79 is an explanatory view showing a sequel to FIG. 78.
  • Figure 80 shows the result of solving the linear programming problem of minimizing the objective function as the sum of each parameter value for the obtained parameter overnight condition. It is explanatory drawing which illustrates.
  • FIG. 82 is an explanatory diagram illustrating a solution obtained by adding a constraint that the number of parameter variables other than krl is 1 or more to the result of FIG. 81.
  • FIG. 83 is an explanatory view exemplifying allocation of an execution cycle to BasicBlock.
  • FIG. 84 is an explanatory diagram exemplifying a fixed priority scheduler.
  • FIG. 85 is an explanatory diagram illustrating a CFG after being transformed using a part of the fixed priority scheduler shown in FIG. 84.
  • FIG. 86 is an explanatory diagram exemplifying a part of the CFG of the Coed Band and Interface after the deformation.
  • FIG. 87 is an explanatory view showing a sequel to FIG. 86.
  • FIG. 88 is an explanatory diagram exemplifying a CFG regarding allocation of the CFG to an isolated node.
  • FIG. 89 is an explanatory diagram exemplifying a description to be subjected to inline expansion for generating a CFG with respect to a shared registry.
  • FIG. 90 is an explanatory diagram exemplifying a pseudo C description regarding the shared registry.
  • FIG. 91 is an explanatory view showing a sequel to FIG. 90.
  • Figure 1 shows the entire design method.
  • the system to be designed is modeled by a description in Java language (Java language description) (S1).
  • Java language description Java language description
  • devices on a single bus are described using the nm () method of Java language.
  • nm () method a program code to be executed in a thread constituting a multi-thread is described in ().
  • the clock is implemented using barrier synchronization.
  • barrier synchronization can be understood as a synchronization method for waiting for all data to be processed at the same time when receiving data from multiple modules.
  • the Java language description (Java code) 1 generated in S1 is read and converted to an intermediate representation (S2).
  • the intermediate representation 2 is a concurrent control 'flow' graph (hereinafter C-CFG), a concurrent parameter-with-time automaton (hereinafter C-TNFA), and a parameter-with-time automaton (with evening)
  • CFG Control-Huichi 'Graph
  • TNFA TNFA
  • CFG Control-Huichi 'Graph
  • TNFA is a system that receives a finite number of inputs at discrete times, classifies a sequence of inputs from the past to the present into classes less than the number determined by the circuit, and stores them. Based on this, it can be understood as a logical model of a circuit that outputs a limited type of output.
  • the parameter setting condition is set as a cycle constraint, and C-CFG is read and high-level synthesis (S4) is used to execute HDL (hardware description language).
  • HDL hardware description language
  • the circuit description is, for example, RTL (Register Transfer Level).
  • the above-mentioned development method is performed by executing a program for realizing the method on a computer device.
  • Development support programs for obtaining HDL from Java language descriptions can be positioned as digital circuit design support programs.
  • This design method enables modeling and verification in the upstream process of a single bus system, and also enables automation of hardware design that satisfies real-time constraints. Verification in the upstream process is possible because the system to be designed is modeled in the Java language description and the description itself is made executable.
  • Constraint 1 relates to the process change of LSI, and is considered to be an acceptable constraint because it deals with hardware.
  • constraint 2 is considered to be an acceptable constraint because only the part directly related to bus operation needs to be modeled as long as the purpose is to verify the bus protocol.
  • Figure 2 illustrates a design pattern for modeling a single bus system in the Java language.
  • the modeling of a single-bus system in Java language is described according to the design pattern shown in Fig. 2 given in UML (Unified Modeling Language).
  • Each device operation on the bus is implemented in the run () method in the Devicelmpl Class.
  • Registers in the device that have access via the bus are implemented as attributes in the Register Class.
  • Implement the synchronous communication method as a Register Class method.
  • a Bus Class corresponding to the bus, a BusController Class for managing the bus interface, and a Clock Controller Class for managing the clock synchronization are implemented.
  • Bus lock management means control of bus navigation.
  • a triangle symbol with a bar indicates a inheritance.
  • Devicelmpl Class is a child class of Device Class, and Devicelmpl Class can use the method of Device Class.
  • the symbol means use.
  • Device Class uses the method of Clock Controller Class.
  • Addition and modification of the bus protocol (addition and modification of the Register Class synchronous communication method), Defines a design 'pattern so that Java language code can be changed.
  • Implement the Device class as a class that summarizes the common elements for devices, such as member variables for the device and methods for registering information on the shared registry that each device can access.
  • Class corresponding to the shared register It consists of a member variable that represents the value of the registry and a method that reads / writes that value.
  • Class corresponding to bus Displays whether the bus is in use or not. It consists of a member variable, a member variable representing a shared register connected to the bus, and a method for changing the state.
  • This class opens the bus and releases the bus when accessing the shared registry via the bus. Ask the class to release the bus.
  • it includes a method for setting a flag variable to 1 when one device accesses the bus. This flag is used as a bus access flag as a member variable, and this member variable prevents multiple bus opening operations within the same clock.
  • the clock synchronization mechanism will be described.
  • the clock is realized using the clock synchronization method based on the barrier synchronization shown in FIG. More specifically, it collects notifications of the end of processing for one clock, and when the end of processing for all devices is confirmed, notifies that processing for the next clock may be performed. If no bus lock remains, reset the Bus Access-Flag of the Bus Class to 0. Note that the clock transition is parameterized at the time of input to the parametric model / checking, so it is not always in units of one clock.
  • bus right acquisition mechanism will be described as a synchronization mechanism for bus right management.
  • the bus right acquisition mechanism manages bus right acquisition by the method shown in FIG.
  • the request for the bus right is made by the getBusLock method.
  • FIG. 6 shows a call graph showing the calling relationship of each method in FIG.
  • FIGS. 7 and 8 show examples of the Java language description of the above bus right acquisition mechanism.
  • the bus release mechanism manages the bus release using the method shown in Fig. 9.
  • the bus right is released using the freeBusLock method.
  • FIG. 10 shows a call graph representing the calling relationship of each method in FIG. Figure 11 illustrates a Java language description of the above bus release mechanism.
  • the exclusive synchronous read method is explained as an exclusive synchronous access method to the bus.
  • the exclusive synchronous read 'method includes the following single read and burst read.
  • Single read is realized by calling the sync_read method with run ().
  • Burst reading is realized by using the synchronized block of the sync-burst-read, endBurstAccess, and consume-lock method run ().
  • FIG. 12 shows a Java language code of the sync read method
  • FIG. 13 shows an example of a description of the sync read method in run ().
  • Undefined method ie, do—something—w—or one wo—clock—boundary () means some processing that may include a clock boundary, and do—something—wo—one.
  • clock-boundary means some processing that does not include the clock boundary.
  • FIG 14 shows the Java language code of sync—burst_read
  • Figure 15 shows the Java code of endBurstAccess
  • Figure 16 shows the Java code of freeBurstBusLock
  • Figure 17 shows the run () code.
  • a description example of burst read is shown. In the burst read, the bus occupancy is acquired repeatedly for each call, and the value is returned without releasing the bus. Then, when the reading of the number of burst reads is completed, the stacked lock is released at a stretch. This implementation realizes a burst operation in which the read value is returned every cycle.
  • the exclusive synchronous write method will be described as an exclusive synchronous access method to the bus.
  • the exclusive synchronous write method includes the following single read and burst read. Single writing is achieved by calling the sync-write method with run (). The burst write is implemented by using the sync-burst-write, endBurstAccess, and consume-clock methods in the run block's synchronized block.
  • FIG. 18 shows the Java language code of sync-write
  • FIG. 19 shows an example of the sync_write method description in run ().
  • FIG. 20 shows the Java language code of sync-burst-write
  • FIG. 21 shows an example of the description of the burst write in run ().
  • the bus lock is acquired repeatedly each time a call is made, and the process ends without releasing the bus after the write process ends. Then, when the number of burst writes has been completed, the stacked lock is released at once. Has become the way.
  • This implementation realizes a burst operation in which the write value can be written every cycle.
  • Figure 22 shows the schematic specifications of the implementation example.
  • a shared memory type two-dimensional graphics drawing / display system is taken as an example.
  • the system shown in the figure has a command interface (Command Interface), a unified memory (Unified Memory), a graphics rendering unit (Graphics Rendering Unit), and a display unit (Display Unit). Shared to a single bi-derection bus.
  • the thigh and interface receives an external drawing command and transfers the received drawing command to the memory via the bus.
  • Unified Memor is a memory that stores drawing commands, drawing source data, and display data centrally. Cost reduction of the system. Great effect for reducing the number of parts. To simplify the model, it is represented by an array in Java. This device is a slave device.
  • the Graphics Rendering Unit checks whether there is a drawing command in the Unified Memory by polling, and if it exists, performs the drawing process while reading the drawing command and the drawing data via the bus, and displays the drawing result. Is stored in the internal buffer, and is transferred to the Unified Memory at once. To simplify the model, drawing commands and drawing data are transferred by continuous access to the array.
  • the Display Unit displays one line at a time while reading the display data.
  • Vertical synchronization is not modeled to simplify the model.
  • Bus access is not performed during the horizontal flyback period.
  • the above command interface (Command Interface), graphic A drawing unit (Graphics Rendering Unit) and a display unit (Display Unit) are bus master devices, and a unified memory (Unified Memory) is a bus slave device.
  • a unified memory Unified Memory
  • the priority of acquiring the bus right is as follows: Display Unit> Command Interface> Graphics Rendering Unit. I do.
  • the wait signal is te, otherwise the wait signal is false.
  • the wait_flag variable is set to false during execution of command reception.
  • the command accepted by the Command Interface consists of command flags, drawing commands, drawing source data, and texture data storage start and end addresses, and the texture data storage start and end addresses are included in the drawing commands. I do.
  • FIG. 27 An implementation example of the ⁇ () method for unified memory is described. An example of its implementation is illustrated in Figure 27.
  • mem-con-reg. current-value [4] It has the structure of drawing source data and display data after drawing.
  • the memory space between the drawing source and the array storing the display data after drawing is divided into two (one is BufferO and the other is Bufferl), and the memory array is divided into frames for each frame display.
  • the command flags 0 and 1 of the Unified Memory are read out by sync-burst-read at certain intervals (bus right acquisition / release operation). If one of the values is 1, set the internal state variable render—start to true, attempt to acquire the bus right, and if successful, draw the drawing command and data with sync_burst—read, and perform the rendering process. And writes the drawing result to the internal buffer (the command flag is cleared to 0 and the bus right is released as soon as reading is completed).
  • n is an appropriate positive integer
  • each variable is as follows: display—begin: rising event from 0 to 1 of the internal variable display_start display_end: internal variable display—start falling event from 1 to 0
  • render_begin internal variable render—start event from 0 to 1
  • render_end internal variable render—start falling from 1 to 0 event
  • FIG. 35 the details of the conversion process to the intermediate representation are illustrated as a whole.
  • bus The Java language description described by modeling the system is converted to C (concurrent) — CFG (Java2C-CFG), C—CFG is converted to C—TNFA (C-CFG2C-TNFA), and C—TNFA is TNFA Is converted to (C-TNFA2TNFA).
  • C-C is converted 1101 ⁇ through parametric 'model checking (C-CFG2HD. Note that in the notation such as Java2C-CFG above, the number "2" means "to" I want to be understood.
  • a CFG for the call method is created, and if the call method exists in a synchronized block, the synchronized in the call method is deleted from the CFG.
  • the calling method is a communication method in the Register class
  • no CFG is created, and only the name of the communication method and the name of the communication method in which device and access to the device are identified from the instance relation. And retain that information in the CFG.
  • information on which registry evening to access is omitted.
  • the communication method includes a clock synchronization method inside, mark the clock boundary on the output branch.
  • the call method is inlined except for deriving the cycle constraint of the entire call method. This example Then, the Rendersing method and Display method are not inlined.
  • Synchronized is expanded to a predetermined CFG, and a fixed priority scheduler for hardware synthesis is given as a skeleton in the form of FSM (Finite State Machine) as a skeleton and the run () method that actually generates the CFG Is automatically generated using the number of
  • FSM Finite State Machine
  • run () method that actually generates the CFG Is automatically generated using the number of
  • two types of CFGs are created, one for hardware synthesis and one for parametric model checking.
  • Code level optimizations such as fixed value propagation and local variable elimination by substitution are performed on CFG.
  • signal input, output, and input / output are represented by member variables, and with regard to the terminal direction, the assignment statement in the program is analyzed on the right side or left side, and how variables are used in conditional statements. To decide. If the signal is identified as an input / output signal, appropriate signals are renamed for input and output to separate them in consideration of data dependency.
  • Java 2 C-CFG the following describes the CFG generation result, C-CFG generation result, and FSM of the fixed priority / scheduler of each run () method according to a Java description example.
  • Fig. 36 illustrates the format of C-CFG.
  • Each CFG includes a node representing the start and end of a branch and a node representing the start and end of a loop, and has a form in which a branch condition and a loop end are added to the corresponding branch.
  • a clock boundary is represented by adding a clock boundary node on a branch.
  • the link with the sub CFG is expressed.
  • Fork nodes that represent the parallel execution of each CFG are represented by adding them to the vertices of the CFG. The handling of synchronized (for hardware synthesis) is explained.
  • the start of synchronized is represented on the CFG as a node labeled begin-sync
  • the end of synchronized is the node labeled end-sync
  • the CFG is Generate. Then, both nodes Are respectively converted as shown in the figure below.
  • the CFG for hardware synthesis is shown in FIG. 40, and the CFG for parametric'model checking is illustrated in FIG.
  • FIGS. 42 and 43 show examples of the CFG
  • FIGS. 44 and 45 show the CFG for checking the parametric model.
  • CFG is exemplified.
  • FIG. 46 shows an example of the display unit (Display Unit), and FIG. 47 shows an example of the CFG for parametric model checking. .
  • Fig. 48 shows the command interface (Co-band and Interface) CF.
  • G the connection state of the respective start nodes in the CFG of the Graphics Rendering Unit and the CFG of the Display Unit are exemplified.
  • FIG. 49 illustrates a fixed priority scheduler corresponding to this example. The meaning of the signals in FIG.
  • burst start requires two cycles or more
  • burst operation requires one cycle or more
  • burst end requires one cycle or more.
  • the cycle constraint is corrected. Abstraction is performed by regarding nodes with constraints other than Begin-sync and End-sync nodes as clock boundaries.
  • the communication method abstracts all the operation contents, and if it is continuous, one node
  • the meaning of the transition cycle constraint given to the clock boundary due to the parameterization of each clock boundary is the cycle constraint for the transition from the clock boundary to the next clock boundary.
  • FIGS. 50 to 56 sequentially illustrate how the command interface is extracted for CFG.
  • Fig. 57 shows an example of the result of the abstraction process for the CFG of the Graphics Rendering Unit.
  • FIG. 58 shows an example of the result of the abstraction processing for the CFG of the display unit (Display Unit).
  • T N F A is a time automaton, where each transition is
  • C—TNFA is a model in which a plurality of TNFAs operate in parallel
  • operation sync is a model in which only one TNFA can be executed at most.
  • other TNFAs cannot interrupt continuous operation sync. Note that it is possible to impose a time constraint on each TNF A to give an upper limit to the transition from the initial state to the initial state.
  • the obtained state assignment candidates are assigned without any duplication, state assignment is performed, and the conversion from each state to the state is performed by traversing DFS (Depth First Search) to TNFA.
  • DFS Depth First Search
  • TNFA a transition corresponding to the sync block is detected and set as a sync transition. Transitions that are not consecutive sync transitions are combined into one transition to reduce the number of states.
  • the conversion of the command interface (CFG) to TNFA is illustrated in order from FIG. 59 to FIG. 61.
  • Figures 62 to 65 include the Graphic Drawing Unit (Graphics Rendering Unit) is converted to TNFA for CFG.
  • the verification property is as follows: drawing may start after the display data acquisition is completed, and may end by the start of the next display. Cycle is included, and the display is completed within n cycles. ”Since this is a verification property based on the assumption that drawing may be started, if any, in the TNFA corresponding to the Graphics Rendering Unit, The transition from R2 to R1 indicating that there is no unexecuted drawing command in Unified Memory by the end of display data acquisition is not required for this verification. Therefore, it has been deleted.
  • FIG. 66 to FIG. 68 sequentially illustrate examples of conversion of a display unit (Display Unit) to TNFA for CFG.
  • a product TNFA is constructed from C-TNFA in accordance with the following policies (1) to (5).
  • transition is made with the one with the highest static priority.
  • transition to age (s, t) state in which only time t has elapsed in state s.
  • no other operation can be interrupted between successive sync transitions.
  • s [e / t] Replaces the variable t that appears in the transition condition from the state s with the expression e. If the reconstructed P (t) has an inconsistent expression, the transition is deleted and all states that reach only the transition are deleted.
  • the strongly connected component of each TNFA is determined, the longest path where the sum of the lower transition times of each transition that passes through the transition branch within the strongly connected component only once is the maximum, and the vertex on that path is The lower limit of the transition time to the vertex is found, and the two paths are obtained by adding the path to the next vertex to the longest path. Next, the total of the lower transition time of each path is calculated. This allows Command Interface: 22 23
  • the upper limit time of each transition of each TNFA is determined by giving the minimum value of the value obtained for other TNFAs, and it is already determined whether the obtained upper limit of the time transition is inconsistent.
  • the upper limit is checked by comparing it with the upper limit of the given transition, and if there is a contradiction, it is increased to twice. Otherwise, a logical combination of linear inequalities is constructed by giving the upper bound found to the transitions for which no upper bound is given. In particular, when the number of times is increased, a value obtained by multiplying the total of the lower limit transition times of the longest paths by the number of times and a value obtained by adding the minimum transition time obtained earlier to the value may be calculated.
  • the parameter checking and model checking are performed, and even if the parameter overnight does not have a nonnegative integer solution, the number of times is increased and the process is performed.
  • linear programming is used to calculate the nonnegative integer solution. Specifically, the solution that minimizes the sum of the parameters over time is calculated within the range that satisfies the parameters over time conditions obtained using the free software LP-S0LV. If the obtained solution does not make sense, it is dealt with by adding the minimum value of the parameters.
  • This process is a method called Assume Guarantee Reasonin, and it is not publicly known that the process is performed by parametric analysis.
  • FIG. 69 shows a configuration example of the TNFA product of the TNFA obtained in FIG. 61, FIG. 64, and FIG. The process of obtaining the TNFA based on this is shown in FIGS. 70 to 76. ⁇ Abstraction of TNF A ⁇
  • TNF A abstraction processing will be described. First, the outline of the algorithm is explained. In TNF A, leave only the transition nodes that substitute for the variables left at the time of abstraction, and the start node and end node of the transition branches. By recalculating the transition time while traversing the edges, all other vertices are abstracted. However, the state corresponding to the leaf is excluded from the target of abstraction.
  • Figure 9 shows a part of the process when the Abstraction of TNFA is called in a timely manner with C-TNFA2TNFA. Here, it is assumed that no specific value is given to kl.
  • Hardware generation is performed according to the policy of 1).
  • the shared registry is assigned only to Unified Memory, and the shared registry assigned from the Unified Memor specification is
  • the device to which the shared registry is assigned has only Unified Memor, so global address assignment is not performed.
  • the shared registry is assigned to only one device, but this is not a generality in the following description. This will become clear from the following procedure.
  • the bus access and method are wrapped up from the original CFG, and a communication node between the bus access and the method and the original CFG is established. Specifically, the following is performed.
  • Bus access '' Basic that performs the following processing on the node representing the method Replace with Block.
  • bus_cmd Basic Block ⁇ ? Urachate Node
  • FIGS. 86 and 87 show a part of the CFG of the Command Interface after the modification.
  • the variables described beside the clock boundaries are parameters, which means that clock boundaries are generated by that number.
  • AD-BUS represents an address bus
  • D-BUS represents a data bus
  • data-in-en-i represents a data input stage
  • data_out_en_i represents a data output stage.
  • i represents the index of each device.
  • the bus width of the addressless bus is The bit width of the address command is the sum of the bit width of the address and the bit width of the address.
  • the variables placed beside the clock boundary are parameters, which means that the number of clock boundaries generated. The value of each variable is equal to the value of the variable used in the CFG deformation process.
  • the CFG corresponding to the inline expanded version of the description in Fig. 89 may be generated.
  • the input and output variables AD_BUS and D-BUS are not separated into input and output, and in the optimization on CFG, the variables are not optimized for AD-BUS and D_BUS. I do.
  • Figures 89, 90 and 91 are pseudo-C descriptions relating to the shared registry.
  • the present invention can be widely applied to a data processing system for performing hard-air synthesis of digital circuits from a language capable of describing parallel operations.

Abstract

　並列動作の記述が可能なプログラム言語を用いて複数のデバイスを定義したプログラム記述（１）を入力し、入力したプログラム記述を中間表現に変換し（Ｓ２）、中間表現に対し、実時間制約を満足するパラメータを生成し（Ｓ３）、生成したパラメータに基づいてハードウェア記述言語による回路記述を合成する（Ｓ４）。中間表現は、コンカレントなコントロールフローフラグ、コンカレントなパラメータ付き時間オートマトン等である。前記パラメータ生成に、パラメトリック・モデルチェッキングを行う。プログラム記述は、ｒｕｎメソッドを用いてデバイスの定義を行い、バリア同期を用いてデバイスのクロック同期を定義する。これにより、実時間制約を満たすバス・システムを設計することができる。

Description

明 細 書 システム開発方法及びデータ処理システム 技術分野
本発明は、並列動作を記述できる言語からディジ夕ル回路を開発する方法、 更には並列動作を記述できる言語からディジタル回路のハードウェア合成を 行うデータ処理システムに関する。 背景技術
近年、 モパイル 'コンピューティング環境を実現する上で、 システム L S Iの果たす役割はその重要性を増している。 また、 モパイル ·コン ピューティングでは実時間制約を如何に満たすかが、 しばしば問題とな る。更に、 システム L S Iを実装する上で要求性能を満たすよう設計す る場合、 バス · システムの設計が重要となる。 然るに、 バス ' システム を実時間制約を満たすよう効率良く設計する為の設計手法がシステ ム-シミュレーションによる方法以外提案されていないのが現状である。 システムシミユレーションについて記載された文献の例として下記の 特許文献がある。
特許文献 1 ：特開 2 002— 279 333号公報
特許文献 2 ：特開 2000— 035898号公報
特許文献 3 ：特開平 07— 08483 2号公報 発明の開示
本発明の目的は、 J ava (登録商標） 等の並列動作を記述可能なプ ログラム言語を用いてバス 'システム等のハードウエア設計の工数を低 減することにある。
本発明の目的は、並列動作を記述可能なプログラム言語とパラメ トリ ヅク 'モデルチヱッキングを用いた、 実時間制約を満たすバス ·システ ムの新規設計手法を提供することにある。
本発明の別の目的は、モデルチェッキング技術とハードウエア合成技 術の融合による新たな設計手法を提供することにある。
本発明のさらに別の目的は、 実時間制約を有するバス ·システムに対 する並列動作記述可能なプログラム言語によるモデル化とパラメ ト リ ヅク ·モデルチェックングによる検証、 更にはハ一ドウエア合成を実現 することにある。
本発明の前記並びにその他の目的と新規な特徴は本明細書の記述及 び添付図面から明らかになるであろう。
本願において開示される発明のうち代表的なものの概要を簡単に説 明すれば下記の通りである。
すなわち、並列動作の記述が可能なプログラム言語を用いて複数のデ バイスを定義したプログラム記述を入力し、入力したプログラム記述を 中間表現に変換し、 この中間表現に対し、 実時間制約を満足するパラメ —夕を生成し、生成したパラメ一夕に基づいてハードウヱァ記述言語に よる回路記述を合成する。
上記より、 J a v a (登録商標） 等の並列動作を記述可能なプログラ ム言語によりバスシステム等に対するモデル化を行って、実時間制約を 満たすシステムの設計を行うことができる。 これにより、 ハードウエア 設計の工数低減が可能になる。
本発明の一つの形態として、 前記中間表現は、 コンカレントなコント ロールフローフラグ、コンカレントなパラメ一夕付き時間ォートマトン、 又はパラメ一夕付き時間オートマトンである。 本発明の一つの形態として、 前記パラメ一夕生成に、 パラメ トリ ヅ ク ·モデルチェヅキングを行う。モデルチヱッキング技術とハードウヱ ァ合成技術の融合による新たな設計手法を提供することができる。 本発明の一つの形態として、前記実時間制約は R P C T Lで与えられ る。
本発明の一つの形態として、前記プログラム記述は r u nメソヅ ドを 用いてデバイスの定義を行い、バリァ同期を用いてデバイスのクロヅク 同期を定義する。 図面の簡単な説明
第 1図は本発明に係る設計方法の全体を例示するフローチャートで ある。
第 2図は単一バス ·システムのジャバ言語によるモデル化のデザィン パターンを例示する説明図である。
第 3図はモデル化におけるク口ヅク同期メカニズムとしてバリア同 期によるクロック同期メソッ ドを用いた例を示す説明図である。
第 4図はレジスタへの値書込みを実現するモデル化の記述を例示す る説明図である。
第 5図はバス権獲得を管理するメソッ ドを例示する説明図である。 第 6図は第 5図の各メソッ ドの呼び出し関係を表すコールグラフで ある。
第 7図はバス権獲得メカニズムのジャバ言語記述を例示する説明図 である。
第 8図は第 7図の続きを示すジャバ言語記述の説明図である。
第 9図はバス権解放を管理するメソッ ドの説明図である。
第 1 0図は第 9図の各メソヅ ドの呼び出し関係を表すコールグラフ である。
第 1 1図はバス権解放メカニズムのジャバ言語記述を例示する説明 図である。
第 1 2図は sync— readメソヅドのジャバ言語コードの説明図である。 第 1 3図は run( )での sync— readメソヅ ド記述例を示す説明図である。 第 1 4図は sync—burst— read のジャバ言語コードを示す説明図であ る。
第 1 5図は endBurstAccessのジャバ言語コ一ドを示す説明図である。 第 1 6図は freeBurstBusLockのジャバ言語コ'一ドを示す説明図であ る。
第 1 7図は run( )でのバーストリードの記述例を示を説明図である。 第 1 8図は sync— writeのジャバ言語コードを示す説明図である。 第 1 9図は run( )での sync— writeメソヅド記述例を示す説明図であ る。
第 2 0図は sync— burst— writeのジャバ言語コ一ドを示す説明図であ る。
第 2 1図は run( )でのバーストライ トの記述例を示す説明図である。 第 2 2図はジャバ言語記述による実装例の概略仕様を示す説明図で ある。
第 2 3図はコマンドィンタフヱースに関する run( ) methodの実装例 の一部を示す説明図である。
第 2 4図は第 2 3図の実装例の続きを示す説明図である。
第 2 5図は第 2 4図の実装例の続きを示す説明図である。
第 2 6図は第 2 5図の実装例の続きを示す説明図である。
第 2 7図はユニファイ ドメモリに関する nm( ) methodの実装例を示 す説明図である。 第 2 8図はグラフィ ヅク描画ュニヅトに関する run( ) methodの実装 例を示す説明図である。
第 2 9図は第 2 8図の実装例の続きを示す説明図である。
第 3 0図は第 2 9図の実装例の続きを示す説明図である。
第 3 1図は第 3 0図の実装例の続きを示す説明図である。
第 3 2図は第 3 1図の実装例の続きを示す説明図である。
第 3 3図は表示ュニットに関する run( ) methodの実装例を示す説明 図である。 .
第 3 4図は第 3 3図の実装例の続きを示す説明図である。
第 3 5図は中間表現への変換工程の詳細を全体的に例示する説明図 である。
第 3 6図は C- CFGの形式を例示する説明図である。
第 3 7図は synchroni zedの扱い （ハード合成用） について示す説明 図である。
第 3 8図は synchronizedの扱い （パラメ トリック 'モデルチェッキ ング用） について示す説明図である。 ' 第 3 9図は Co匪 and Interfaceの場合の C F Gを示す説明図である。 第 4 0図は Co匪 and Interfaceに関しハード合成用の C F Gを例示す る説明図である。
第 4 1図はパラメ トリック ·モデルチェッキング用の C F Gを例示す る説明図である。
第 4 2図はグラフィ ック描画ュニヅト (Graphics Rendering Unit) に関する C F Gを例示する説明図である。
第 4 3図は第 4 2図の C F ,Gの続を示す説明図である。 .
第 4 4図はパラメ トリック ·モデルチヱッキング用の C F Gを例示す る説明図である。 第 4 5図は第 4 5図の C F Gの続を示す説明図である。
第 4 6図は前記表示ユニット （Di splay Unit) に関する C F Gを例示 する説明図である。
第 4 7図はパラメ トリック ·モデルチェッキング用の C F Gを例示す る説明図である。
第 4 8図はコマンドィン夕フェース（Command Interface)の C F G、 グラフィック描画ュニヅト （Graphics Rendering Unit) の C F G、 及 び前記表示ユニット （Display Unit) の C F Gにおける夫々の開始ノー ドの結合状態を例示する説明図である。
第 4 9図は固定優先度スケジューラを例示する説明図である。
第 5 0図はコマンドイン夕フェース （Command Interface) の C F G に対する抽象化の様子を順を追って示す最初の説明図である。
第 5 1図は第 5 0図の続を示す説明図である。
第 5 2図は第 5 1図の続を示す説明図である。
第 5 3図は第 5 2図の続を示す説明図である。
第 5 4図は第 5 3図の続を示す説明図である。
第 5 5図は第 5 4図の続を示す説明図である。
第 5 6図は第 5 5図の続を示す説明図である。
第 5 7図はグラフィヅク描画ュニヅト （Graphics Rendering Unit) の C F Gに対する抽象化処理の結果を例示する説明図である。
第 5 8図は表示ュニッ ト （Display Unit) の C F Gに対する抽象化処 理の結果を例示する説明図である。
第 5 9図はコマンドイン夕フエ一ス （Command Interface) の C F G に対する T N F Aへの変換の様子を順を追って示す説明図である。 第 6 0図は第 5 9図の続を示す説明図である。
第 6 1図は第 6 0図の続を示す説明図である。 第 6 2図はグラフィック描画ュニット （Graphics Rendering Unit) の C F Gに対する T N F Aへの変換の様子を順を追って示す説明図で ある。
第 6 3図は第 6 2図の続を示す説明図である。
第 6 4図は第 6 3図の続を示す説明図である。
第 6 5図は第 6 4図の続を示す説明図である。
第 6 6図は表示ュニット （Display Unit) の C F Gに対する T N F A への変換の様子を順を追って例示する説明図である。
第 6 7図は第 6 6図の続を示す説明図である。
第 6 8図は第 6 7図の続を示す説明図である。
第 6 9図は第 6 1図、第 6 4図、 第 6 8図で求めた T N F Aの積 T N F Aの構成例を示す説明図である。
第 7 0図はパラメ一夕に上限値を与えた時に、積 T N F Aを構成する 段階で制約を満たさない遷移枝の削除過程を示す説明図である。
第 7 1図は第 7 0図の続を示す説明図である。
第 7 2図は第 7 1図の続を示す説明図である。
第 7 3図は第 7 2図の続を示す説明図である。
第 7 4図は第 7 3図の続を示す説明図である。
第 7 5図は第 7 4図の続を示す説明図である。
第 7 6図は第 7 5図の続を示す説明図である。
第 7 7図は C- TNFA2TNFAで Abstraction of TNFAを適時コールした場 合の処理の経過の一部を示す説明図である。
第 7 8図は第 7 7図の続を示す説明図である。
第 7 9図は第 7 8図の続を示す説明図である。
第 8 0図は得られたパラメ一夕条件に対して目的関数を各パラメタ 値の合計として、これを最小化するという線形計画問題を解いた結果を 例示する説明図である。
第 8 1図は第 8 0図の結果に対し、 kbl=2, kb2=l，kb3=lの制約を追加 して得た解を例示する説明図である。
第 8 2図は第 8 1図の結果に対し更に krl 以外のパラメ夕変数を 1 以上という制約を追加して得た解を例示する説明図である。
第 8 3図は BasicBlockへの実行サイクルの割り当てを例示する説明 図である。
第 8 4図は固定優先度スケジューラを例示する説明図である。
第 8 5図は第 8 4図に示す固定優先度スケジューラの一部を用いて 変形した後の C F Gを例示する説明図である。
第 8 6図は変形後の Co匪 and Interfaceの C F Gの一部を例示する説 明図である。
第 8 7図は第 8 6図の続きを示す説明図である。
第 8 8図は孤立ノードへの C F Gの割り当てに関する C F Gを例示 する説明図である。
第 8 9図は共有レジス夕に関し C F G生成のためのィンライン展開 の対象になる記述を例示する説明図である。
第 9 0図は共有レジス夕に関する擬似 C記述を例示する説明図であ る。
第 9 1図は第 9 0図の続を示す説明図である。 発明を実施するための最良の形態
本発明の一例として、実時間制約を有するバス ·システムの J a v a (登録商標）によるモデル化及びパラメ トリヅク 'モデルチェヅキング による検証とハ一ドウエア合成について説明する。本明細書では J a V , a (登録商標） を単にジャバ言語とも記す。 《設計方法の全体》
第 1図には設計方法の全体が示される。設計対象とされるシステムは ジャバ言語による記述 （ジャバ言語記述） でモデル化される （S 1) 。 ジャバ言語記述によるモデル化では、単一バス上のデバイスをジャバ言 語の nm()メソッ ドを用いて記述する。 nm()メソヅ ドはマルチスレヅ ドを構成するスレヅ ドにおいて実行させたいプログラムコ一ドがその ()内に記述される。 クロックはバリア同期を用いて実現される。一般的 にバリァ同期とは複数のモジュールからのデ一夕を受信する場合に同 時刻に処理されるべき全てのデ一夕を待っための同期手法として把握 することができる。
次いで、 S 1で生成されたジャバ言語記述 （ジャバコード） 1を読み 込み、 中間表現に変換する （S 2) 。 ここで、 中間表現 2は、 コンカレ ン トなコン トロール ' フロー ' グラフ （以下、 C一 CFG)、 コンカレ ントなパラメ一夕付き時間オートマトン（以下、 C— TNFA)、 パラメ —夕付き時間オートマトン（以下、 TNFA)からなる。 CFG (コント ロール ·フ口一 'グラフ） は一般に関数内部において制御の流れを示す グラムを意味する。 TNFA (ォ一トマトン） とは、 有限の種類の入力 を離散的な時刻に受け、 過去から現在までに入力された入力の系列を、 回路で決まった個数以下のクラスに分類して記憶し、それに基づいて有 限の種類の出力を出す回路の論理的なモデルとして把握することがで きる。
中間表現 2 と して得られた T N F Aと RP C T L ( Real Time . Parametric Computation Tree Logic) 3で記述された実時間制約を読 み込み、 パラメ 卜リ ック -モデル ·チヱヅキングを実行し (S 3) 、 入 力； P CTL等を満たすパラメ一夕条件 4を導出する。
満足するパラメ一夕条件がなければ方式変更を行いジャバ言語記述 を修正し、 満足するパラメ一夕条件があれが、 そのパラメ一夕条件をサ ィクル制約として、 C— C F Gを読み込んで高位合成 （S 4 ) により H D L (hardware Description Language (こよる回路 ΰ述 5へ変換する。 回路記述は例えば R T L (Register Transfer Level ) である。
上記開発方法はそれを実現するためのプログラムをコンピュータ装 置で実行することによって行なわれる。ジャバ言語記述から H D Lを得 る為の開発支援プログラムはディジタル回路の設計支援プログラムと して位置付けることができる。
本設計手法により、 単一バスシステムの上流工程でのモデル化、 検証 が可能となり、かつ実時間制約を満たすハ一ドウエアの設計自動化が可 能となる。上流工程での検証が可能なのは、 設計対象システムはジャバ 言語記述でモデル化され、その記述自身が実行可能にされるからである。
《ジャバ言語によるモデル化に対する制約》
ジャバ言語によるモデル化に際してのジャバ言語記述とバスシステ ムに対する制約について説明する。単一バス ·システムのジャバ言語に よるモデル化を目的とするため、 ジャバ言語記述に対し、
1 ) ダイナミック · ィンスタンシェ一ションの禁止、
2 ) run( )メソッ ドからの 3セ&1"1:( )メソッ ドコールの禁止、
の制約を置く。 制約 1 ) は L S Iのプロセス変更に関するものであり、 ここではハ一ドウエアを扱っている事から、許容可能な制約であると考 えられる。 また、 制約 2 ) はバス ·プロ トコルの検証を目的とする限り に於いては、 直接バス動作に関わる部分のみをモデル化すれば良い為、 許容可能な制約であると考えられる。
また、 パラメ トリック ·モデルチヱッキング · ツールの制約から、 モ デルに対して、
3 ) 単一双方向バス · システム、 4 ) バス権制御は固定優先度
5 ) バス上の各デバイスは一定周期で処理を終了、 の制約を課す。 上記 制約の緩和は新たな課題として位置付けられる。
《ジャバ言語によるモデル化の為のデザインパターン》
第 2図には単一バス ·システムのジャバ言語によるモデル化の為のデ ザィンパターンが例示される。単一バス ·システムのジャバ言語による モデル化は U M L (Unif ied Model ing Language) で与えられる第 2図 のデザィンパターンに沿って記述される。 バス上の各デバイス動作を Devicelmpl Class内の run( ) メソッ ドに実装し、 バスを介してァクセ スがあるデバイス内レジス夕は Register Class内の attribute (属性） として実装し、 バスを介しての同期通信メソッ ドを Register Classの メソッ ドとして実装する。 また、 バスに対応する Bus Class, バスの口 ヅク管理を行う BusControl ler Class, 及びクロック同期を管理する Clock Control ler Class を実装する。 バスのロック管理とはバスァ一 ビトレ一ションの制御を意味する。第 2図の標記において、 棒線を付し た三角記号△は継承を意味し、例えば Devicelmpl Classは Device Class の子クラスであり、 Devicelmpl Classは Device Classのメソヅ ドを使 用可能である。 記号 はユース （use) を意味し、 例えば Device Class は Clock Control ler Classのメソヅ ドを利用する。
尚、 ジャバ言語コードの再利用性を高めるため、 下記方針
1 ) デバイスの追加 · 削除 （Devicelmpl Classの追加 ·削除） 、
2 )デバイス動作の変更（Devicelmpl Classの run( )メソヅ ドの変更）、
3 ) 共有変数の追加 · 削除 （Register Class の attributeの追加 · 削 除） 、
4 ) バスプロ トコルの追加 .変更 （Register Class の同期通信メソッ ドの追加 ·変更） 、 にて、 ジャバ言語コードの変更が可能となるようデザィン 'パターンを 定義している。
第 2図のデザインパターンにおける各クラス （Class) について説明 する。
( 1 ) Deviceクラス
デバイスに共通の要素をまとめた抽象クラスである。レジス夕やバス は複数ある場合でも処理内容自体が異なることはないため、同じクラス オブジェク トを複数生成ことにより複数存在することを表現できるが、 デバイスはデバイスごとにその処理内容が異なる。 よって、 並列動作を 行なうために Threadクラスを継承し、 Clock control ler Classのイン スタンス、 Register Classのインスタンス、 Bus Classのインスタンス を表すメンバ変数、各デバイスがアクセス可能な共有レジス夕の情報を 登録する為のメンバ変数、及び各デバイスがアクセス可能な共有レジス 夕の情報を登録する為のメソッ ドといったようなデバイスに共通な要 素をまとめたクラスとして Deviceクラスを実装する。
( 2 ) Devicelmpl クラス
実際のデバイスにあたるクラスである。デバイスはデバイスごとに処 理内容が異なるため、 デバイスに必要な要素をまとめた Deviceクラス を継承し、 その処理内容を記述する。 つまり、 A という処理を行なう Devicelmp クラス、 B という処理を行なう DevicelmplBクラスといつ たように処理ごとに Deviceクラスの実装クラスが存在することになる。
( 3 ) Regi sterクラス
共有レジスタに対応するクラスである。レジス夕の値を表すメンバ変 数と、 その値をリード/ライ 卜するメソッ ドから成る。
( 4 ) Busクラス
バスに対応するクラスである。バスが使用中であるか否かの状態を表 すメンバ変数、そのバスに繋がっている共有レジスタをあらわすメンバ 変数、 及び、 状態を変更するメソッ ドから成る。
( 5 ) BusControl lerクラス
バスを介した共有レジス夕へのアクセス時のバス口ヅクとバスの口 ヅク解放を行なうクラスである。バスの口ック ·口ヅク解放はこのクラ スに対して依頼する。特に、 バスに対して 1つデバイスがアクセスを行 うとフラグ変数を 1に設定するメソヅ ドを含む。このフラグをバスァク セス ·フラグとしてメンバ変数として持ち、 このメンバ変数により、 同 一クロヅク内での複数回のバス口ヅク動作を回避している。
( 6 ) ClockControl lerクラス
ク口ック管理クラスである。バスシステム上の各デバイスにクロック 同期動作を行なわせるために、 1 クロック分の処理終了の通知を集め、 全デバイスの処理終了が認められたら、次のクロックの処理を行なって よいという通知を行うと同時に BusControl ler Classのバスアクセス · フラグを 0にリセヅ トする。
《モデル化におけるクロック同期メカニズム》
クロック同期メカニズムについて説明する。第 3図に示すバリア同期 によるクロック同期メソヅ ドを用いて、 クロックを実現する。具体的に は、 1クロック分の処理終了の通知を集め、 全デバイスの処理終了が認 められたら、 次のクロックの処理を行なってよいという通知を行う。 また、 バスのロックが残っていない場合には、 Bus Classのバスァク セス -フラグを 0にリセッ トする。尚、クロック遷移はパラメ トリヅク · モデル ·チヱッキングへの入力に際して、 パラメ一夕化される為、 必ず しも 1クロック単位であるとは限らない。
このクロヅク遷移のパラメ一夕化により、サイクル精度でのモデル化 よりも抽象度の高いモデル化を実現する。 レジス夕への値書き込みには 1クロックを要する為、それを実現する 必要がある。 これは、 consume—し clockメソッ ド内で、 第 4図に例示さ れる Register Class の assignWriteValue メソヅ ドをコールする事で 実現している。
《モデル化におけるバス権獲得メカニズム》
バス権管理の同期メカニズムとして、先ずバス権獲得メカニズムにつ いて説明する。バス権獲得メカニズムは、第 5図に示すメソヅ ドにより、 バス権獲得を管理する。 バス権の要求は getBusLockメソッ ドにより行 う。第 6図には第 5図の各メソッ ドの呼び出し関係を表すコールグラフ が示される。第 7図及び第 8図には上記バス権獲得メカニズムのジャバ 言語記述が例示される。
《モデル化におけるバス権解放メカニズム》
次にバス権解放メカニズムについて説明する。バス権解放メカニズム は第 9図にに示すメソッ ドにより、 バス権解放を管理する。バス権の解 放は freeBusLockメソッ ドにより行う。第 1 0図には第 9図の各メソヅ ドの呼び出し関係を表すコールグラフが示される。第 1 1図には上記バ ス権解放メカニズムのジャバ言語記述が例示される。
《モデル化における排他的同期リード ' メソッ ド》
バスへの排他的同期アクセス方式として、排他的同期リード 'メソッ ドについて説明する。排他的同期リード ' メソヅ ドには以下のシングル リードとバーストリードがある。 シングルリ一ドは sync_read メソヅ ドを run( )でコールする事で実現される。 バース ト リー ドは、 sync—burst— read、 endBurstAccess、 consume— c lock メソッ ド run( ) の、 synchronizedブロヅク内で用いる事で実現される。
第 1 2図には sync一 readメソッ ドのジャバ言語コード、第 1 3図には run( )での sync readメソヅ ド記述例が示される。 run( )での記述例に現 れる未定義メソッ ド、 即ち、 do— something— w— or一 wo—clock— boundary( ) は ク ロ ッ ク 境界を含んで も よ い何 ら かの処理を意味 し、 do— something— wo一 clock— boundary( )はク口ヅク境界を含まなレ、何らか の処理を意味する。
第 1 4図には sync— burst_read のジャバ言語コード、 第 1 5図には endBurstAccessのジャバ言語コ一ド、 第 1 6図には freeBurstBusLock のジャバ言語コード、 第 1 7図には run( )でのバーストリードの記述例 が示される。バーストリ一ドでは、 バスの口ックはコールする度に重ね て獲得し、 バスの解放を行わないで値を返す。 そして、 バーストリード 回数のリードが終了すると、重ねたロックを一気に解放するという実装 方法となっている。 この実装により、 毎サイクル、 リード値が返ってく るというバースト動作を実現している。
《モデル化における排他的同期ライ ト . メソヅ ド》
バスへの排他的同期アクセス方式として、 排他的同期ライ ト ·メソヅ ドについて説明する。排他的同期ライ ト ·メソッ ドには以下のシングル リードとバーストリ一ドがある。 シングルライ トは sync— write メソヅ ド を run( )でコールする事で実現される。 バ一ス ト ライ ト は sync一 burst— write、 endBurstAccess、 consume—clock メソヅ ドを runリ の、 synchronizedブロヅク内で用いる事で実現される。
第 1 8図には sync— writeのジャバ言語コードが示され、 第 1 9図に は run( )での sync_writeメソヅ ド記述例が示される。
第 2 0図には sync— burst— writeのジャバ言語コードが示され、 第 2 1図には run( )でのバーストライ トの記述例が示される。 バース トライ トでは、 バスのロックはコールする度に重ねて獲得し、 書き込み処理終 了後バスの解放を行わないで処理を終了する。そして、 バーストライ ト 回数のライ トが終了すると、重ねたロックを一気に解放するという実装 方法となっている。 この実装により、 毎サイクル、 ライ ト値が書き込め るというバースト動作を実現している。
《ジャバ言語記述による実装例》
ジャバ言語記述による実装例を説明する。第 2 2図には実装例の概略 仕様が示される。 ここでは、 共有メモリ方式の 2次元グラフィ ヅクス描 画 ·表示システムを一例とする。 同図に示されるシステムは、 コマンド インタフヱ一ス (Command Interface) 、 ユニファイ ドメモリ (Unified Memory) 、 グラフィ ヅク描画ュニヅ 卜 (Graphics Rendering Unit) 、 及び表示ュニヅ ト （Display Unit)を有し、 それらは双方向バス（Single bi-derection Bus) に共有する。
( 1 ) Co腿 and Interfaceは、 外部からの描画コマンドを受付け、 バ スを介して受け付けた描画コマンドをメモリへ転送する。
( 2 ) Unified Memor は、 描画コマンド、 描画ソースデータ、 表示 データを一元的に格納するメモリである。 システムの低コスト化 ·部品 点数削減に効果大。モデルを単純化する為、 Javaでは配列で表現する。 本デバイスはスレーブデバイスである。
( 3 ) Graphics Rendering Unitは、 Unified Memoryに描画コマンド があるかをポ一リングで調べ、 存在する場合は、 描画コマンド、 描画デ 一夕をバスを介してリードしながら描画処理を行い、描画結果を内部バ ッファに格納し、 一気に Unified Memoryへバ一スト転送する。 モデル を単純化する為、 描画コマンド、 描画データ転送は配列への連続ァクセ スで実現する。
( 4 ) Display Unit は、 表示データをリ一ドしながら 1ラィンずつ 表示を行う。モデルを単純化する為、垂直同期はモデル化しない。また、 水平帰線期間はバスアクセスを行わないものとする。
上記コマンドインタフェース (Command Interface) 、 グラフィ ック 描画ュニヅ ト （Graphics Rendering Unit)、及び表示ュニヅ ト （Display Unit ) がバスマスタデバイスであり、 ユニファイ ドメモリ （Unified Memory)がバススレーブデバイスである。バスマス夕デバイスが同時に バス権獲得を行った場合の、 バス権獲得の優先順位は、 表示ユニッ ト (Display Unit) >コマンドイン夕フェース （Command Interface) > グラフィ ック描画ュニヅト (Graphics Rendering Unit) とする。
次に、 第 2 2図の仕様に対する run( ) methodの実装例について説明 する。
(丄 ) Command Interface
先ず、 コマンドイン夕フェースに関する run( ) methodの実装例を説 明する。 その実装例は第 2 3図乃至第 2 6図に例示される。 外部入力 write_req信号 （具体的には CPU からのライ ト信号） があり且つ wait 出力信号の値決定に用いる内部変数 wait_flagが falseだとコマンド受 付を実行（一定サイクル消費） し、 その後に先ず waitjlag変数を true とする。 次いで、 バス権取得を試み、 取得できたら Unified Memoryの コマンドフラグ 0 , 1を syncjmrst— readで読み出し、 値が 0 (描画コ マンド処理済み）であるコマンドフラグに対応するメモリ領域に対して、 バス権を取得した状態のままで、 syncjmrst— write を実行し、 コマン ドフラグ、 描画コマンド、 描画ソースデ一夕を転送し、 wait_flag変数 を fal seとする。 但し、 モデル簡略化の為、 例えコマンドフラグが両方 とも 0であっても、 コマン ドフラグ 0に対応するメモリ領域への sync— burst— write による書き込みのみを実行するものとし、 描画ソ一 スデ一夕の転送は省略する。
write— flag変数が trueで、 write— req入力信号が trueの場合のみ、 wait信号を t e とし、 それ以外は wait信号を false とする。 特に、 コマンド受付実行中は wait_flag変数を false とする。尚、 wait信号、 wait— f lag変数ともに初期値は falseとする。
また、 Command Interfaceが受け付けるコマンドは、コマンドフラグ、 描画コマンド、 描画ソースデータ、 テクスチャデータの格納開始 '終了 ァドレスからなっており、 テクスチャデータの格納開始 .終了ァドレス は描画コマンドに含まれているものとする。
2 ) Unified Memory
ユニファイ ドメモリに関する πιη( ) methodの実装例を説明する。 そ の実装例は第 2 7図に例示される。 グラフィ ツクス描画コマンド、 描画 ソース 'グラフィ ックス ·データ、 描画後の表示用データを一元的に格 納しているメモリ。モデル化を簡略化する為、 何も実行しないスレッ ド として実現。 このメモリの実体は Regi ster Cl assのインスタンスとし て run( )メソヅ ド内でアローケートされている。 .
尚、 モデル簡略化の為、 メモリ配列を下記
mem一 con— reg. current— value [0] ： コマンドフラグ 0、
mem— con— reg. current— value [ l ] ：描画コマンド 0、
mem— con一 reg. current— value [2] ： コマンドフラグ 1、
mem— con— reg. current— value [3 ] ：描画コマンド 1、
mem— con— reg. current— value [4]：描画ソース ·データ、 及び描画後の表 示用データ、 の構造としている。
実際には、 描画ソース ·デ一夕と描画後の表示データを格納している 配列のなすメモリ空間を 2分し （一方を BufferO、 他方を Bufferl とす る） 、 フレーム表示毎にメモリ配列を、
( BufferO , Bufferl ) = (描画ソース .デ一夕，描画後の表示用データ） ( BufferO, Bufferl ) = (描画後の表示用データ，描画ソース ·データ） となるように、 交互に切り替えているとする。 従って、 描画ソース 'デ 一夕を描画後の表示用データで上書きする事はないとする。更に、 モデ ル簡略化の為、 描画ソース ·デ一夕の転送は省略する。
また、 モデル簡略化の為に、 テクスチャ，データは省略しており、 描 画コマンドも最高で 2つしか格納しないものとし、 コマンド 0， 1の実 行順番がどうであっても描画結果には影響しないものとする。
( 3 ) Graphics Rendering Unit
グラフィック描画ュニットに関する run( ) methodの実装例を説明す る。 その実装例は第 2 8図乃至第 3 2図に例示される。 Unified Memory のコマンドフラグ 0 , 1をある一定周期毎に sync— burst— readにより読 み出す （バス権獲得 ·解放動作） 。 何れか一方の値が 1であった場合、 内部状態変数 render— startを trueとし、 バス権獲得を試み、 獲得に成 功したなら、 描画コマンド、 描画データを sync_burst— readで読み込み ながら、 描画処理を実行し、 描画結果を内部バッファに書き込む （読み 込み終了次第、 コマンドフラグを 0にクリアし、 バス権解放する） 。 但 し、 モデル簡略化の為、 例えコマンドフラグが両方とも 0であっても、 コマンドフラグ 0に対応する描画コマンドのみを実行するものとし、描 画ソースデ一夕の転送は省略する。 再び、 バス権獲得を試み、 獲得に成 功したなら、描画結果を sync— burst— writeで Unified Memor へ転送し、 バス権を解放し、 内部状態変数 rende startを false とする。 尚、 内 部状態変数 render— startの初期値は falseである。
( 4 ) Display Unit
表示ュニヅ トに関する run( ) methodの実装例を説明する。 その実装 例は第 3 3図及び第 3 4図に例示される。 Unified Memory から描画後 の表示用データを読み込み C R Tへ出力する。但し、モデル簡略化の為、 水平同期のみを扱うものとする。 これは、 水平帰線期間内に描画が開 始 '終了する為のサイクル制約をパラメ トリック 'モデルチヱヅキング で求める事を目的としているからである。 ' さて、 Display Unitは、 内部変数 display一 startを tureに設定し、 Unified Memoryから描画後の表示用デ一夕を sync— burst_readにて読 み込む。デ一夕読み込み終了後に内部変数 display二 startを falseとし て、 ライン表示を実行し、 ライン表示終了後から水平帰線期間に相当す る適当なサイクルを消費し、再び、 ライン表示を同じ手順で行うものと する。 また、 転送サイクルのみをモデル化すれば良いので、 メモリアド レスは簡略的に表現し、常に同一メモリ空間から読み出しているものと する。
《パラメ トリック解析》
ここでパラメ トリヅク解析の目標について説明する。本来、描画は 1 フレーム表示の表示期間及び、垂直帰線期間の間に 1フレーム分の実行 を終了しておれば良いと考えられるので、水平帰線期間での描画が満た すべき性質を勘案すると、検証内容としては下記条件を満たすサイクル 制約の導出で十分である。即ち、 「表示用データ取得終了後に描画を開 始し、 次の表示開始までに描画を終了する事がある。 但し、 描画開始 · 終了にデータ転送サイクルは含まれ、 表示は nサイクル以内に終了す る。」である。上記制約を R P C T L (Real Time Parametric Computation Tree Logic) で記述すると下記
EF{く di splay_end>(AF ( <render_begin>true )
&&{ AF ( <render_end>true )AU( <display_begin>true ) }) }
&& AG{ [display— begin] (AF<=n( [ di s 1 ay_end ] true ) ) }
の 3個の制約のアンド条件となる。尚、 表示データ取得終了迄に未実行 の描画コマンドが Unified Memory上に常に存在する事が仮定できるも のとする。 ここで、 n は適当な正整数であり、 各変数は下記の通り、 display— begin： 内部変数 display_startの 0から 1への立ち上がりィ ベント display_end： 内部変数 display— startの 1から 0への立ち下がりィべ ン卜
render_begin： 内部変数 render— startの 0から 1への立ち上がりィべ ン卜
render_end： 内部変数 render— startの 1から 0への立ち下がりィベン 卜
を表す。
パラメ トリック ·モデルチェヅキングを高速化する目的で、 RP CT Lを
AG{ [display— begin] (AF<=n( [display一 end]true))} (*)
と、 それ以外の部分に分離し、 例えば、
EF{ <di sp 1 ay— end> ( EF ( <render_Degin>true EF ( <render— end>true ) A U^<display_begin>true)})}
から実行し、パラメ一夕条件を導出し、導出されたパラメ一夕から（*) の nの上限を求め、既に求めたパラメ一夕条件に矛盾しないパラメータ 条件が導出できるまで、 nの値を減じて繰り返し、 （*) のパラメ ト リ ック解析を実施するものとする。
RP C T Lやそれを用いたパラメ トリック ·モデルチェヅキングの詳 細は次の文献、 " Akio Nakata and Teruo Higashino: "Deriving Parameter Conditions for Periodic Timed Automata Satisfying
Real-Time Temporal Logic Formulas", Proc. of IFIP TC6/WG6.1 Int' 1
Conf . on Formal Techniques for Networked and Distributed
Systems(F0RTE2001), Cheju Island, Korea, Kluwer Academic
Publishers, pp.151-166, Aug. 2001."に記載ある。
《中間表現への変換》
第 3 5図には中間表現へ変換工程の詳細が全体的に例示される。バス システムをモデル化して記述されたジャバ言語記述は C (concurrent) — CFGに変換され （Java2C-CFG)、 C— C F Gは C— T N F Aに変換 され （ C-CFG2C- TNFA ) 、 C— T N F Aは T N F Aに変換される (C-TNFA2TNFA) 。 パラメ トリック ' モデルチヱッキングを経て C— C （ が1101^こ変換される （C-CFG2HD 。 尚、 上記 Java2C- CFG等の標 記において、 数字 "2"は "to"を意味するものと理解されたい。
《 Java 2 C- CFG》
ジャバ言語記述から C - C F Gへの変換アルゴリズムの概要を説明 する。 各 run() メソッ ドに対応する C F Gを生成する。 特に、 クロヅ ク同期メソッ ド （consume_clock) はクロック境界として識別し、 呼び 出しメソヅ ドは呼び出し関係を表すノードを用いて表現する。 各 run() メソッ ドに対応する C F Gが生成されると、 fork ノードを設け、 その ノードから各 CFGの開始ノードへの：ork枝を付加する。 特に、 バス 上の各デバイスに run()メソヅ ドが対応するものとして Javaが記述さ れている事を前提とし、 メモリデバイスに関しては、 C FG生成対象外 である事の指定を与えるものとする。
次いで、 呼び出しメソッ ドの C F Gを作成し、 呼び出しメソッ ドが synchronized ブロック内に存在する場合は、 呼び出しメソッ ド内の synchronized を C F Gから削除する。 特に、 呼び出しメソッ ドが Register クラス内の通信メソッ ドである場合は C F Gの作成を行わず、 インス夕ンス関係からどのデバイス内のどのレジス夕へのアクセスか と通信メソッ ドの名前だけを識別し、その情報を CFGに保持する。 但 し、 図ではどのレジス夕へのアクセスかの情報は省略している。 尚、 通 信メソッ ドが内部にクロック同期メソッ ドを含む場合は、その出力枝に クロック境界をマークする。更に、 呼び出しメソヅ ド全体のサイクル制 約を導出する以外は、 呼び出しメソッ ドをインライニングする。 この例 では、 Rendersingメソッ ド、 Displayメソッ ドはインライニングしない。 synchroni zed を予め定めた C F Gに展開し、 ハード合成用の固定優 先度スケジューラを F S M (Finite State Machine) の形式でスケルト ンとして予め与えてあるライブラリと実際に C F Gを生成した run( ) メソッ ドの個数を用いて、 自動生成する。 ここで、 C F Gはハード合成 用とパラメ トリック · モデルチヱヅキング用の 2種作成する。
尚、 固定値伝播や、 代入によるローカル変数消去等のコードレベル最 適化を C F G上で実施する。 特に、 信号の入力 ·出力 ·入出力はメンバ 変数で表し、 端子方向に関しては、 プログラム内での代入文で右辺にあ るのか左辺にあるのかや条件文での変数の用いられ方を解析して決定 する。 入出力信号として識別された場合、 データ依存性を考慮して、 入 力と出力に適当な信号のリネームを行って分離する。
Java 2 C- CFGに関し、 以下で、 Java記述例に沿って、 各 run( )メソヅ ドの C F G生成結果、 C— C F G生成結果、 及び固定優先度 .スケジュ ーラの F S Mについて説明する。
先ず C F Gの形式について説明する。第 3 6図には C— C F Gの形式 が例示される。各 C F Gは分岐枝の開始と終了を表すノードと、 ループ 枝の開始と終了を表すノードを含み、 分岐条件、 ループ終了条件を対応 する枝に付加した形式とする。特に、 クロック境界ノードを枝上に付加 する事でクロック境界を表現する。 また、 メソヅ ドコールに対応するノ 一ドを用いる事で、 サブ C F Gとのリンクを表現する。各 C F Gの並列 実行を表す forkノードは C F Gへの頂点へ付加する事で表現する。 synchronized の扱い （ハード合成用） について説明する。 第 3 7図 に例示されるように、 synchronizedの開始を C F G上で begin— sync と ラベル付けされたノ一ドとして表し、 synchronizedの終了を end一 sync とラベル付けされたノードでし、 C F Gを生成。 その後、 その両ノード を夫々下図に示すように変換する。
synchronized の扱い （パラメ トリック .モデルチェッキング用） に ついて説明する。 第 3 8図に例示されるように、 synchronized の開始 を C F G上で Begin_sync とラベル付けされたノードとして表し、 synchroni zedの終了を End_syncとラベル付けされたノードでし、 C F Gを生成。その後、その両ノードを夫々第 3 8図に示すように変換する。 上記に従うと、 前記 Command Interfaceの場合、 C F Gは第 3 9図に 示される。 getWriteSignal ( )メソヅ ドは、 シミユレ一ションを実施する 為に行った記述であり、 処理系への入力では外部からの入力信号 write— reqであるとして修正されているものとし、 入力テストベクタの 個数を.表す dcom_indexを補正する記述も削除されているものとする。 また、 drawing— commands も配列として表現されているが、 これもシミ ュ レ一シ ョ ンを実施する為になされたものであ り、 内部変数 input— commandに入力変数 drawing— commands が入力されてレ、る記述が 処理系に入力されているのもとして扱う。
前記 Co匪 and Interfaceに関し、 ハード合成用の C F Gは第 4 0図に 示され、 パラメ トリック 'モデルチェッキング用の C F Gは第 4 1図に 例示される。
前記グラフィ ヅク描画ュニッ ト ( Graphics Rendering Unit) に関し、 第 4 2図及び第 4 3図にはその C F Gが例示され、第 4 4図及び第 4 5 図にはそのパラメ トリック■モデルチェッキング用の C F Gが例示され る。
前記表示ユニッ ト （Display Unit) に関し、 第 4 6図にはその〇 0 が例示され、 第 4 7図にはそのパラメ トリック ·モデルチヱッキング用 の C F Gが例示される。 . .
第 4 8図にはコマンドインタフェース （Co匪 and Interface) の C F G、 グラフィック描画ユニッ ト (Graphics Rendering Unit) の C F G、 及び前記表示ユニッ ト （Display Unit) の C F Gにおける夫々の開始ノ ―ドの結合状態が例示される。
固定優先度スケジューラ （Fixed Priority Scheduler) について説明 する。実際にトップレベルの C F Gを生成した runメソッ ドの数を識別 し、 夫々のデバイスにバス権取得通知を行うための信号 locked— i の組 みからなるステートを作成する。単一バスシステムであるため、 それら ステ一トは、 1つの locked_i のみが 1でその他が 0であるものを構成 すれば良い。 また、 全ての locked— i が 0であるステートも作成する。 優先度情報に基づき、 バス権要求信号 lock一 i を受けて行う状態遷移枝 を設ければバス権管理用の固定優先度スケジューラが構成できる。特に、 全ての locked— i が 0であるステートをリセッ ト解除時の開始ステート とする。 また、 各状態遷移は l<=t<=kl の時間制約が付加されているも のとする。 このパラメ一夕は後のパラメ トリック -モデルチヱッキング で決定されるパラメ一夕である。 尚、 例えば、 kl=2 とし、 各遷移を 2 クロック遷移とした場合は、 出力値は変化が起こるまで、 前の値を保持 しているものとして解釈するものとする。
第 4 9図には本例に対応する固定優先度スケジューラが例示される。 同図における信号の意味は、
lock— 1 ： Command Interfaceからのバス権要求信号
lock— 2： Graphics Rendering Unitからのバス権要求信号
lock一 3： Display Unitからのバス権要求信号
locked一 1 ： Command Interfaceへのバス権取得通知信号
locked一 2： Graphics Rendering Unitへのバス権取得通知信号 locked— 3： Di splay Unitへのバス権取得通知信号
である。 尚、 バス権取得の優先度が、 Display Unit > Command Interface > Graphi cs Rendering Unit であるので、 遷移条件は、
lock— 3： Display Unitへの遷移
! lock— 3&&lock— 1： Command Interfaceへの遷移条件
！ lock_3&& ! lock_l&&lock_2： Graphi cs Rendering Unitへの遷移条件 otherwi se：全ての locked_iが 0であるステートへの遷移条件 となる。
《Abstraction of each CFG》
夫々の C F Gの抽象化処理について説明する。先ず、 そのアルゴリズ ムの概要を説明する。 各 BasicBlockに対して、 0<=t<=kiなる時間遷移 条件を付加し、 Begin— syncノードと End— syncノ一ドに対して 0<=t<=kl を付加し、 通信メソッ ドを表すノードに対して、 バース ト開始に K=t<=kbU バースト動作に 0く =t<=kb2、 バースト終了に 0<=t<=kb3 を 付加する。但し、 通信メソヅ ドを表すノードに対しては、 バースト開始 が 2サイクル以上、 バースト動作時は 1サイクル以上、 バースト終了が 1サイクル以上を要すると考え、後述のノードのマージによる抽象化を 行う際には、 サイクル制約の補正を行う。 Begin— syncと End— syncノ一 ド以外の制約を付加したノードをクロック境界と見做して抽象化を行 ラ。
通信メソッ ドは動作内容を全て抽象化し、 連続する場合は、 1つのノ
—ドにまとめ、 例えばバースト開始（l<=t<=kbl )、 クロック境界（t=l )、 (バース ト動作（0く =t<二 kb2 ) +クロック境界（t=l ) ) 3回、 バース ト終了 ( 0く二 t<=kb3 )、 クロック境界（t=l )とすると、
6く二 t<=(kbl+l- l )+3(kb2+l-l )+(kb3+l - 1 ) = kbl+3kb2+kb3 ( >=2+3*1+1 = 6 )
なるサイクル制約を持つクロヅク境界として 1つにまとめる。 また、 分 岐ノ一ドは全て非決定分岐であるとする。 Basic Blockノードに関して は、 入力 RPCTLで用いる変数のみ残し他は抽象化する。分岐ノード下位 に存在する Basic Blockに対応する部分が異なる分岐で同じ場合は、 1 つを残して他を削除する。
特にループノードに関しては、 break、 continueを含まない固定回数 ループの場合はアンローリングを実施し、 それ以外の場合は、 ループを 抜ける条件枝の直前に全体で 0<=t<=kloop のサイクル制約を持つよう な C F Gノードの集合を設ける事でループを削除する。 ここで、 kloop の満たすべき条件を別に算出するものとする。更に連続するクロック境 界はパ一コレ一シヨン 'ベースの移動を行う事で、 1つに纏め、 遷移サ ィクル制約を更新する。
ここで、 各クロヅク境界のパラメ一夕化により、 クロヅク境界に与え た遷移サイクル制約の意味は、ク口ック境界から次のクロック境界への 遷移に対するサイクル制約である。
コマンドイ ン夕フェース (Command Interface) の C F Gに対する抽 象化の様子が順を追って第 5 0図乃至第 5 6図に例示される。第 5 7図 にはグラフィ ヅク描画ュニッ ト （Graphics Rendering Unit) の C F G に対する抽象化処理の結果が例示される。 第 5 8図には表示ュニッ ト (Display Unit) の C F Gに対する抽象化処理の結果が例示される。 《C- CFG2C- TNFA》
C— T N F Aから T N F Aへの変換処理について説明する。 T N F A とは時間オートマトンであり、 各遷移が、
s-a@?t [P(t) ]->s'
の形式で表されるものである。 ここで、 各記号の意味は、
s, s' :状態、
a：動作（省略可能）、 @?t：状態 sを訪れてから動作 aを実行するまでの経過時間を tに代入、 P(t) ： 時間制約（tに関する線形不等式の論理結合） 、
である。 また、 その意味は 「sから t単位時間経過後に状態 s'に遷移。 ただし、 tは時間制約 P(t)を満たす場合に限る」 である。
C— T N F Aは、複数の T N F Aが並列動作するモデルであり、 動作 sync は高々 1つの T N F Aしか実行できないモデルである。 特に連続 する動作 syncに対しては他の T N F Aが割り込めない。 尚、 各 T N F Aに対して、初期状態から初期状態への遷移に対して、 上限を与える為 の時間制約を課す事が可能である。
次に C— C F Gから C— T N F Aへの変換処理について説明する。先 ず、 その変換アルゴリズムの概要を説明する。 Begin— sync、 End_sync で挟まれた部分を識別し、 sync ブロックとする。 Sync ブロック内に存 在しないクロック境界ノードにステート割り当て候補とし、 また sync プロヅク内であっても検証性質に必要となる信号が Basic Blockとして 与えられている場合はその前後のクロヅク境界ノ一ドにステートを割 り当て候補とし、 最後に Begin— sync、 End— syncの変換で導入したクロ ック境界をステート割り当て候補とする。得られたステート割り当て候 補を重複が無いようにし、 ステート割り当てを行い、 各ステートからス テートまでを D F S (Depth First Search) でトラバースする事で T N F Aへの変換を行う。 得られた T N F Aに対して、 sync ブロックに対 応する遷移を検出し、 sync遷移とする。 連続する sync遷移でない遷移 は 1つの遷移に纏める事でステート数の削減を行う。
コマンドインタフェース （Command Interface) の C F Gに対する T N F Aへの変換の様子が順を追って第 5 9図乃至第 6 1図に例示され る。
第 6 2図乃至第 6 5図にはグラフィ ヅク描画ュニヅ ト （Graphics Rendering Unit) の C F Gに対する T N F Aへの変換の様子が順を追つ て例示される。第 6 5図において、 検証性質は、 「表示用デ一夕取得終 了後に描画を開始し、次の表示開始までに描画を終了する事がある。但， し、 描画開始 ·終了にデータ転送サイクルは含まれ、 表示は nサイクル 以内に終了する。 」であり、 これは、 描画が開始される事がもしあれば という前提にたった検証性質であるから、 Graphics Rendering Unitに 対応する T N F Aにおいて、 表示デ一夕取得終了迄に未実行の描画コ マンドが Unified Memory上に存在しない事を表す R2から R1への遷移 はこの検証には不要となる。 従って、 これは削除されている。
第 6 6図乃至第 6 8図には表示ユニット （Display Unit) の C F Gに 対する T N F Aへの変換の様子が順を追って例示される。
《C-TNFA2TNFA》
C一 T N F Aから T N F Aへの変換アルゴリズムの概要を説明する。 先ず、 下記方針 （ 1 )〜（ 5 ) に従って C一 T N F Aから積 T N F Aを 構成する。
( 1 ) sync 動作とそれ以外の動作は互いにインタリ一ブされる。 こ こで、 sync動作を行っている間にバス権をとる必要が無い動作、 即ち sync でない動作を （一般に複数） 並行して実行できることを表現。 但 し、 sync動作を 1遷移実行する間の他の TNFAの並行遷移に遷移枝を通 る回数に制限を設け、それを満たす各遷移の遷移時間の上限を導出する。 特に、 回数は 1から始め、 意味のある解が得られるまで、 回数を 1づっ インクリメントするものとする。
( 2 ) 複数の sync動作が実行可能な場合は静的優先度が最も高いも のによつて遷移する。ここで、動いていない状態 sに関しては age( s，t) (状態 sで時間 tだけが経過した状態）に遷移。ただし、 連続する sync 遷移の間には他の動作は割り込めない。 ( 3 ) age(s,t)以降の遷移に関しては、 時間 tに関して下記補正を行 う。 即ち、 s - [P(tl)]- > s，ならば age(s，t) -[P(t+tl)]->s，[t+tl/tl]ヽ とする。 ここで、 s[e/t] ： 状態 sからの遷移条件に現れる変数 tを式 e で置き換えることを表す。 尚、 再構成した P(t)が矛盾した式になつ ている場合、 その遷移は削除し、 その遷移へのみ到達する状態全てを削 除するものとする。
( 4 ) 各遷移の時間変数 tは下記に示すように、 異なる名前に変更す る。 即ち、 s-[P(t)] -〉 s，- [Q(t)]- >s "は S- [P(tl)]->s，- [Q(t2)]- >s"に変 更する。 age(s,t)に関する補正によって、 各遷移条件はそれ以前の遷移 の時間変数も含む式になるため、 それらを区別するために、 この変更が 必要となる。
( 5 ) 上限を与えた TNF Aがある場合、 構成後の TNFAでその初 期状態を含む状態間の遷移がその上限を満たさない場合、その途中にあ る状態で上限を満たす遷移内に存在する状態を削除対象外とし、削除対 象外とならなかった状態を削除する。
尚、 Abstraction of each CFGのステップで抽象化対象から除外され た R P C T Lに用いられている変数を伴う遷移が現れるとその次の状 態まで構成し、 上記構成方針での作成での切りの良いところで、 Abstraction of TNFAをコールし、 構成中の T N F Aの抽象化を行う。 次に C— T N F Aから T N F Aへの変換処理を詳細に説明する。先ず、 遷移回数の仮定による遷移時間の上限を決定する。即ち、 各 TNFAの 強連結成分を求め、強連結成分内での遷移枝を 1回のみ通る各遷移の下 限遷移時間の総計が最大となる最長パスと、そのパス上の頂点でその後 段の頂点への遷移時間の下限が最小の頂点を求め、最長パスにその後段 頂点へのパスを追加したパスの 2つを求める。次いで、 夫々のパスの下 限遷移時間の総計を求める。 これにより、 Command Interface： 22 23
Graphics Rendering Unit： 28 29
Display Unit： 11 12
が求まる。さて、 各 T N F Aの 2つ目の下限遷移時間の総計から 1引い た値、
Command Interface： 22
Graphics Rendering Unit： 28
Display Unit： 11
を求める。各 T N F Aの各遷移の上限時間を、他の T N F Aに対して求 めた値の最小値を与える事で決定し、得られた時間遷移の上限値が矛盾 したものとなっていないかを、既に上限が与えられている遷移の上限値 と比較する事で調べ、 もし、 矛盾がでたなら 2回に増加させる。 そうで なければ、上限が与えられていない遷移に求めた上限を与える事で線形 不等式の論理結合を構成する。特に、 回数を増加させる場合、 最長パス の下限遷移時間の総計と回数の積を取った値と、その値に先に求めた最 小の遷移時間を加えた値を算出すればよい。
尚、 パラメ トリヅク 'モデルチヱヅキングを実施し、 パラメ一夕条件 が非負整数解を持たない場合にも回数の増加を行って処理をすすめる 事とする。 ここで、 非負整数解の算出には、 線形計画法を用いる。 具体 的には、フリーソフト LP- S0LVを用いて得られたパラメ一夕条件を満た す範囲で、 パラメ一夕の和が最小となる解を算出する。仮に、 得られた 解が意味をなさない場合は、パラメ一夕の最小値を付加するなどして対 処する。
さて、 本例の場合、 遷移枝を一回のみ遷移可能とした仮定では、 各 T N F Aの遷移時間の上限として
Command Interface： 11 Graphics Rendering Unit： 11
Display Unit： 22
が求まる。 また、 矛盾が起こることなく、 以下に示す線形不等式の論理 結合、
0<=kl+k2+kloopl<=7 && 5<=kbl+kb2+kb3+klく =8 &&
7<=kbl+3kb2+kb3+kl<=l l&& K=kl<=ll && 1く =kl+k2+k3+kloopl+klく =6 && 3<=k4<=ll && 5<=kbl+kb2+kb3+kl<=l l && 6<=kbl+4kb2+kb3+3krl<=12 && 1く =3kr2+klく =8&& 9<=kbl+5kb2+kb3+klく =12 && krl=kb2- 1 && 8<=kbl+5kb2+kb3<=24 && K=kl+6kd<=19
が得られる。 また、 遷移枝を 2回まで遷移可能とした場合、 各 T N F A の遷移時間の上限として
Command Interface： 22
Graphics Rendering Unit： 22
Di splay Unit： 44
が求まり、 以下に示す線形不等式の論理結合、
0 kl+k2+klooplく =18 && 5<=kbl+kb2+kb3+klく =19 &&
7<=kbl+3kb2+kb3+kl<=22 && l<=klく =22 && K=kl+k2+k3+kloopl+kl<=17 && 3<=k4<=2 && 5<=kbl+kb2+kb3+kl<=22 && 6<=kbl+4kb2+kb3+3krl<=23 && 1く二 3kr2+klく =19 && 9<=kbl+5kb2+kb3+klく =23 && krl=kb2- 1 && 8<=kbl+5kb2+kb3<=46 && l<=kl+6kdく =41
が得られる。
この工程は、 Assume Guarantee Reasonin と呼ばれる手法であり、 パラメ トリヅク解析での実施は公知ではない。
第 6 9図には第 6 1図、第 6 4図、 第 6 8図で求めた T N F Aの積 T N F Aの構成例が示される。これに基づいて T N F Aを求める過程が第 7 0図乃至第 7 6図に示される。 《Abstraction of TNF A》
TNF Aの抽象化処理について説明する。先ず、 そのアルゴリズムの 概要を説明する。 TNF Aで抽象化時に残した変数への代入を行ってい る遷移枝と、 その遷移枝の始点ノード及び終点ノードのみを残し、 残す べき頂点を始点として、次に残すべき頂点が現れるまで頂点と辺をトラ バースしながら遷移時間を再計算する事で、その他の頂点を全て抽象化 する。 但し、 葉に対応する状態は抽象化の対象から除外する。
先の例では抽象化の実施がまだ起こらない段階までしか TN F Aを 構成しなかったので、抽象化が必要となる様先の例を意図的に若干修正 して、 第 7 7図乃至第 7 9図にに C- TNFA2TNFAで Abstraction of TNFA を適時コールした場合の処理の経過の一部を示す。 ここでは、 kl には 具体的な値は与えないものとする。
《パラメ トリック解析結果》
前記文献に述べられているアルゴリズムを用いて、遷移を 2回以上通 らない制約で、 探索深さ最大値 1 6として、 以下の検証性質
EF (<displayend>( (AF(<renderbegin>true )
and ( , AF <renderend>true ) ) AU (<displaybegin>true))))
に関してパラメ夕条件を導出すると、 以下の条件、
0 く二 kd && 0 <= kr2 && 0 <= krl && 0 <= kb3 && 0 く二 kb2 && 0 く二 kbl && 0 <= kloopl && 0 <= k5 ML 4 く = k4 && 0 く = k3 && 0 <= kl && 0 <= k2 && 12 <= kbl+9kb2+kb3 && 4 <= kl)
を得る。 これと先に求めた、 遷移を 2回以上通らないという制約から得 られたパラメ一夕条件
0<=kl+k2+kloopl<=7 && 5<=kbl+kb2+kb3+klく =8 && 7<=kbl+3kb2+kb3+kl<=ll 1 klく =11 && 1く =kl+k2+k3+kloopl+klく =6 && 3く二 k4く二 11 && 5<=kbl+kb2+kb3+kl<=ll && 6<=kbl+4kb2+kb3+3krl<=12 && 1く =3kr2+klく =8 && 9<=kbl+5kb2+kb3+klく =12 && krl=kb2-l && 8く二 kbl+5kb2+kb3く二 24 && l<=kl+6kdく =19
との論理積を取って、 得られたパラメ一夕条件に対して、 目的関数を各 パラメタ値の合計として、これを最小化するという線形計画問題をフリ —ソフ ト LP一 SOLVEにて解かせると、 第 8 0図の解を得る。
第 8 0図の結果では、バスアクセス終了通知が 0サイクルで行われな ければならず、 また、 描画サイクル kr2 と表示サイクル kdが 0である ので、 意味のある解とは言えないので、 kbl=2, kb2=l，kb3=lの制約を追 加し、 第 8 1図の解を得た。
第 8 1図の結果でも、 描画サイクル kr2 と表示サイクル kdが 0であ るので、 意味のある解とは言えないので、 kbl=2，kb2=l，kb3=lの制約に 加えてさらに、 krl 以外のパラメタ変数は 1 以上という制約を追加し、 第 8 2図の解を得た。以後、このパラメ一夕値を採用して議論を進める。
《ハード合成》
ハードゥヱァ合成処理についてその概要を先ず説明する。 （ 1 )〜（ 1
1 ) の方針にてハードウェアの生成が行なわれる。
( 1 ) 事前に Registerクラスに登録された通信メソヅ ドの種類から バスコマンドの割り当てを行う。
( 2 ) ユーザ情報として、 どのデバィスにどの共有レジス夕が存在す るかを受付け、各デバイス内のレジスタ数に対応するデバイス内ァドレ スを割り当てる。
( 3 ) 共有レジス夕が割付られたデバイス (run( )メソッ ド） の数を 取得し、共有レジス夕が割り当てられたデバイスにグロ一バルなァドレ スを割り当てる。
( 4 ) インライニング （展開） を実施しなかった通信メソヅ ド以外の メソヅ ドのィンライニングを行う。 (通信メソヅ ドと指定したメソヅ ド 以外のメソヅ ドは事前にィンライニングされている事に注意。 ）
(5) パラメ トリック解析結果から得られた、 Basic Blockの実行サ イクルを各デバイスの合成用 C FGに反映する。
(6)各デバイス夫々の CFGを ¾形し、 通信メソヅ ドとそれ以外の コント口一ルフ口一部が互いに通信するモデルに変換する。
(7)前記 （6)で得られた変換後の CFG内の通信メソヅ ドに対応 する部分に、 バスコマンド生成記述を挿入する。 通信メソッ ドは、 グロ —バルァドレス、 共有レジスタァドレス、 バスコマンドを出力し、 デー 夕読み出し ·書き込みの何れかを実行する記述からなる C F Gとなり、 それらの信号生成 ·受理に要するサイクルは、 パラメ トリック解析の結 果により決定される。
( 8 ) 共有レジスタァドレスから、 各デバイス内のレジス夕の配列ィ ンデックスを生成するァドレスデコーダとグローバル'ァドレスを識別 するァドレスデコーダを共有レジスタが割り当てられたデバイス内に 生成し、 出力トライステートを共有レジス夕の出力に接続し、 トライス テート ·ィネーブル信号として、 各デバイスからのデータ入力ステージ を表す信号の論理和を用いる 。 共有レジス夕の入力に関しては、 取り 込み動作が起こらない限り内部変数は前の値を保持する為バスから信 号を接続すれば良よく、各デバイスからのデータ入力ステージを表す信 号の論理和を元にデータ取り込み判定を行う。但し、 これらは CFGと して表現する。 （自デバイス内に共有レジス夕があつたとしても、 こ の方式に従って、 アクセスが行われているものとする。 )
(9) 変形等で得られた各 CFGの信号通信関係 （入力、 出力） を識 別し (バスは入出力) 、 夫々をモジュールとして識別する。
( 10 ) 各 C F Gを 「サイクルアキュレートなプログラム記述からの ハード合成」 に従って、 HDLへと変換する。 ( 1 1 ) バスに対してリピータ回路を H D Lの形式で挿入する。 前記バスコマンドの割り当てに関し、 本例で登録したバスアクセス · メ ソ ッ ド は 、 sync— read、 sync— write 、 sync— burst— read、 sync— burst_write、 endBurstAccessであるが、 各 run( )メソヅ ドの C F Gを解析すると、 実際に用いられているバスアクセスメソヅ ドは、 sync— burst一 read、 sync— burst一 write、 endBurstAccessであるため、 パ スコマン ドを
sync_burst_read 2'b00
sync— burst一 write 2'b01
endBurstAccess 2'blO
NOP 2'bll
のように割り当てる。
上記アドレス割り当てに関しては、 共有レジス夕は Unified Memory にのみ割り付けられ、 Unified Memor の仕様から割り付けられた共有 レジス夕は
raem_con_reg current— value [0 J コマン ドフラグ 0、
mem_con_reg current— value [ l J 描画コマン ド 0、
mem_con_reg current— value [2 J コマン ドフラグ 1、
raera_con_reg current一 value [3 j 描画コマンド 1、
mem_con_reg current— value [4] 描画ソース ·データ 及び描画後の表 用 7—グヽ
mera_con_reg current value [5]：描画ソース .デ一夕、 及び描画後の表 示用データ、
mem_con_reg current value [6]：描画ソース■データ、 及び描画後の表 示用データ、
mem— con reg current value [7]：描画ソース ·データ、 及び描画後の表 示用デ一夕、
mem— con— reg. current— value[8]：描画ソース ·データ、 及び描画後の表 示用データ、
mem— con一 reg. current— value [9]：描画ソース 'データ、 及び描画後の表 示用デ一夕、 となる。 尚、 ユーザ情報から各レジス夕のビヅ ト幅が指定 されているものとし、 それぞれ 3 2ビッ ト （unsigned int) であるとす る。
バスアクセス 'メソッ ドはレジス夕内のバイ トアクセス等を行わない ので、 各レジス夕のアドレスを
mmeemm—_ ccoonn_ rreegg.. ccuurrrreenntt_——vvaalluuee[[00J ： 4，b0000、
mem— con—reg. current一 value [ 1 4'b000U
mem一 con— reg. current一 value [2 4'b0010、
mem— con— reg, current一 value [3 4 '固 1、
mem— con— reg， current— value [4 4'b0100,
mem— con— reg . current_value [ 5 4'b010U
mem_con_reg. current_value[6 4，b0110、
mem— con— reg, current— value [7 4，b0111、
mem— con— reg, current— value [8 4'bl000,
mem— con_reg. current—value [9 4'blOOU のように決定する。
また、 ァドレス割り当てに関し、 共有レジス夕が割り当てられたデバ イスは Unified Memor しか存在しないため、 グロ一バルァドレスの割 付を行わない。
尚、本例では 1つのデバイスのみに共有レジス夕の割り当てを行って いるが、以降の説明に於いてこれは一般性を欠くものではない。それは、 以降に処理手順を示す事で明らかとなる。
前記 BasicBlockへの実行サイクルの割り当てに関しては、ここでは、 Command Interfaceのみ取り上げて説明を行う。 特に、 先に求めたパラ メータ値から、 kl = 4， kbl = 2, kb2 = 1， kb3二 1、 kl = k2 = k3 = 1、 として説明を行う。 パラメ一夕条件から、 各 BasicBlockの下に割り当 てられたサイクル数のクロヅク境界を挿入する。 ここでは、 バスァクセ ス ·メソヅ ドを扱う対象としていない事に注意。 更に、 与えたパラメ一 夕で、 例を示しているが一般性を失わない事に注意。次ページに変形後 の C F Gを示す。 尚、 kl の値は、 直接各デバイスのハード合成用 C F Gには影響を与えない事にも注意。 これは、 固定優先度スケジューラに のみ影響する。 第 8 3図には BasicBlockへの実行サイクルの割り当て の例が示される。
固定優先度スケジユーラの修正に関しては、既に得られている F S M (Finite State Machine) の遷移サイクルを kl に変更する、 即ち、 ク 口ック境界を各遷移枝に 4つ付加すれば良い。ここからの H D L生成は、 各状態からの遷移を分岐ノードに表現し直し、かつ各状態での信号代入 はその状態への遷移枝上での最後のクロック境界直下に BasicBlockを 設け、 そこにレジスタ代入文を記述する形式で置き換える事で、 この F M S自体を C F Gと見做す事で、 「サイクルアキュレートな記述からの H D L生成」を用いる事で可能である。第 8 4図に示す固定優先度スケ ジユーラの一部を用いて変形後の C F Gが第 8 5図に示される。
C F Gの変形に関しては、 元の C F Gからバスアクセス ·メソッ ドの 括りだしを行い、 バスアクセス，メソッ ドと元の C F Gとの通信ノード を設る。 具体的には、 下記を行う。
1 )ハード合成用の. C F G生成段階で、 クロック境界を含むバスァク セス ·メソヅ ドのクロックをバスアクセス .メソヅ ドを表すノードの直 下にクロック境界を追加したが、 これを削除する。
2 ) バスアクセス ' メソッ ドを表すノ一ドを下記処理を行う Basic Blockに置き換える。
① 出力信号 start_comm に 1を代入する。
② パスコマンドを出力信号 bus_cmdに代入する。バースト転送の場合、 初期サイクルでは、
く 1> 出力信号 initの 0を代入
<2> アクセスするデバイスのァドレスと共有レジス夕のァドレスを連 結して出力信号 addressに代入
<3> ク口ック境界挿入 X n b f
<4> リードメソッ ドなら、 代入すべき変数に入力信号 data_inを代入 く 5>ライ トメソッ ドなら、出力すべき値または変数を出力信号 data— out に代入
<6>ク口ヅク境界 xmb f、 を行う。 ここで、 nb f +mb f 二 kb 1 である。 この例では、
Figure imgf000041_0001
f = lとする。
バースト転送の場合、 転送終了では、
く 1>クロック境界挿入 X n、 を行う。 ここで、 n = kb 3である。 ここ では、 n = 1とする。
バースト転送の場合、 それ以外では、
<1> 出力信号 initに 1を代入
<2> アクセスするデバイスのアドレスと共有レジス夕のアドレスを連 結して出力信号 addressに代入
<3> ク口ック境界揷入 X n b
<4> リードメソッ ドなら、 代入すべき変数に入力信号 data_inを代入 <5>ライ トメソヅ ドなら、出力すべき値または変数を出力信号 data— out に代入
<6> クロック境界 xmbを行う。 ここで、 nb+mb = kb 2である。 この例では、 nb = 0、 mb= lとする。 シングル転送の場合、
<1> アクセスするデバイスのァドレスと共有レジスタのァドレスを連 結して出力信号 addressに代入
<2> クロック境界挿入 x n s
<3> リードメソッ ドなら、 代入すべき変数に入力信号 data_inを代入 く 4>ライ トメソッ ドなら、出力すべき値または変数を出力信号 data— out に代入
く 5>クロック境界挿入 X m s、 を行う。 ここで、 n s + m s = k sであ る。
③ 出力信号 start— comm に 0を代入する。
3 )バスアクセスメソヅ ドを表す孤立ノードを作成し、 置き換えて生 成した Basic Blockとの通信ノードを設ける。 通信ノードとして、 start— comm： Basic Block→ 孤立ノ一ド
bus_cmd： Basic Block→ ？瓜立ノ―ド
address： Basic Block→ 孤立ノ一ド
data— in：孤立ノード ~ Basic Block
data_out： Basic Block→孤立ノード、 を設ける。
第 8 6図及び第 8 7図には変形後の Command Interfaceの C F Gの一 部が示される。第 8 7図において、 クロック境界の傍らに記載された変 数はパラメータであり、その数だけクロック境界を生成することを意味 する。
孤立ノードへの C F Gの割り当てに関しては、第 8 8図の C F Gを自 動生成する。第 8 8図において、特に、 AD— BUSはァドレスバスを、 D— BUS はデータバスを表し、 data— in— en— i はデータ入力ステージを、 data_out_en_i はデータ出力ステージを表す。 ここで、 i は各デバイス のィンデヅクスを表す。 また、 ァドレスバスのバス幅は、 割り当てたバ スコマンドのビッ ト幅とアドレスのビヅ ト幅の合計とし、デ一夕バスは アクセスするレジス夕のビヅ ト幅とする。 また、 クロック境界の傍にか かれた変数はパラメ一夕であり、その数だけクロック境界を生成する事 を意味する。 尚、 各変数の値は、 C F Gの変形過程で用いた変数の値と 等しい。
共有レジス夕に関しては、第 8 9図の記述をィンライン展開したもの に対応する C F Gの生成を行えばよい。但し、入出力変数である AD_BUS、 D— BUSの入力、 出力への分離は行わず、 また C F G上での最適化に於い ては、 AD— BUS、 D_BUSに対する変数最適化は実施しないものとする。 第 8 9図、第 9 0図及び第 9 1図には共有レジス夕に関する擬似 C記述で ある。サイクルアキュレートな記述からの H D L生成に関しては本発明 者による先の出願（特願 2 0 0 2 - 3 0 0 0 7 3 ) を参照することがで きる。
以上本発明者によってなされた発明を実施形態に基づいて具体的に 説明したが、 本発明はそれに限定されるものではなく、 その要旨を逸脱 しない範囲において種々変更可能であることは言うまでもない。
例えば、 積オートマトンの構成に関しては、 T N F A積オートマトン を構成するとき、 遷移枝の通過回数で Assume Guarantee Reasoningを 実施したが、 本来は、 sync動作の通過回数で行うべきである。理由は、 sync 動作はバスアクセス動作を意味しており、 並列に動いている T N F Aが何回 sync動作を実施したかは、 その T N F Aに対応するデバイ スがバスァクセスを何回行ったかに対応するからであり、 Ref inement 及びパラメ トリック ·モデルチヱヅキングで得られるのは、 遷移サイク ルの条件のみならず、 その検証性質を実施している間に各デバイスが 高々どれだけバスアクセスを行うかの情報も得られるからである。但し、 この手法であると、 組み合わせ爆発を起し得るので、 何らかの高速な枝 切りが必要となる。
積オートマトンの構成に関しては、 今回は、 パラメ トリヅク ·モデル チヱヅキングの停止性を吟味せず、 パウンデッ ド .モデルチヱツキング として、 検証性質を満たす必要条件を求める事を行ったが、 本来は十分 を求める必要がある。 その為、 アルゴリズムの停止性に関する研究を更 に行う必要がある。
バスモデルの拡張に関しては、 単一双方向バスのみではなく、 単方向 バスや、 ローカルバスを含むもの、 またバス .ブリッジを介してバスが 階層化されているような複数バスシステムを扱うようにしてもよい。 また、 水平帰線期間のみを扱ったが、 本来は垂直帰線期間もモデル化 して、 1 フレームを表示している間に最低 1フレーム分の描画が終了す るための十分条件を求める必要がある。 産業上の利用可能性
本発明は、並列動作を記述できる言語からディジタル回路のハードゥ エア合成を行うデ一夕処理システムなど広く適用することができる。

Claims

請 求 の 範 囲
1 .並列動作の記述が可能なプログラム言語を用いて複数のデバイスを 定義したプログラム記述を入力し、入力したプログラム記述を中間表現 に変換し、 この中間表現に対し、 実時間制約を満足するパラメ一夕を生 成し、生成したパラメ一夕に基づいてハードウヱァ記述言語による回路 記述を合成することを特徴とするシステム開発方法。
2 . 前記中間表現は、 コンカレントなコントロールフロ一フラグ、 コン カレントなパラメータ付き時間オートマトン、又はパラメ一夕付き時間 オートマトンであることを特徴とする請求項 1記載のシステム開発方 法。
3 . 前記パラメ一夕生成に、 パラメ トリック 'モデルチェヅキングを行 うことを特徴とする請求項 2記載のシステム開発方法。
4 .前記実時間制約は R P C T Lで与えられることを特徴とする請求項 3記載のシステム開発方法。
5 .前記プログラム記述は r u nメソヅ ドを用いてデバイスの定義を行 い、バリア同期を用いてデバイスのクロック同期を定義することを特徴 とする請求項 4記載のシステム開発方法。
6 .並列動作の記述が可能なプログラム言語を用いて複数のデバイスを 定義したプログラム記述を入力し、入力したプログラム記述を中間表現 に変換し、 この中間表現に対し、 実時間制約を満足するパラメ一夕を生 成し、生成したパラメ一夕に基づいてハ一ドウエア記述言語による回路 記述を合成することを特徴とするデータ処理システム。
7 .前記プログラム記述は r u nメソヅ ドを用いてデバイスの定義を行 い、バリァ同期を用いてデバイスのクロック同期を定義することを特徴 とする請求項 6記載のデータ処理システム。
PCT/JP2003/012840 2002-10-28 2003-10-07 システム開発方法及びデータ処理システム WO2004038620A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU2003272931A AU2003272931A1 (en) 2002-10-28 2003-10-07 System development method and data processing system
JP2004546404A JP3899104B2 (ja) 2002-10-28 2003-10-07 システム開発方法及びデータ処理システム
US10/533,062 US20060015858A1 (en) 2002-10-28 2003-10-07 System development method and data processing system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2002-313201 2002-10-28
JP2002313201 2002-10-28

Publications (1)

Publication Number Publication Date
WO2004038620A1 true WO2004038620A1 (ja) 2004-05-06

Family

ID=32171161

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2003/012840 WO2004038620A1 (ja) 2002-10-28 2003-10-07 システム開発方法及びデータ処理システム

Country Status (4)

Country Link
US (1) US20060015858A1 (ja)
JP (1) JP3899104B2 (ja)
AU (1) AU2003272931A1 (ja)
WO (1) WO2004038620A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010286885A (ja) * 2009-06-09 2010-12-24 Toshiba Corp アーキテクチャ検証装置
US9027002B2 (en) 2010-10-27 2015-05-05 Hitachi, Ltd. Method of converting source code and source code conversion program
US11537415B2 (en) 2018-10-02 2022-12-27 Inter-University Research Institute Corporation Research Organization Of Information And Systems Information processing apparatus, information processing circuit, information processing system, and information processing method

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8095921B2 (en) * 2005-10-12 2012-01-10 International Business Machines Corporation Identifying code that wastes time switching tasks
EP1804185A1 (en) * 2005-12-27 2007-07-04 Semiconductor Energy Laboratory Co., Ltd. Parameter setting method and circuit operation testing method and electronic processing device
TW200725412A (en) * 2005-12-30 2007-07-01 Tatung Co Ltd Method for converting high-level programming language method into hardware component graph
TW200725415A (en) * 2005-12-30 2007-07-01 Tatung Co Ltd Method for automatically translating high level programming language into hardware description language
US8645923B1 (en) * 2008-10-31 2014-02-04 Symantec Corporation Enforcing expected control flow in program execution
JP5770073B2 (ja) * 2011-11-25 2015-08-26 株式会社ジャパンディスプレイ 表示装置及び電子機器
CN102624476B (zh) * 2012-01-10 2014-09-10 南京邮电大学 一种基于模型检测的无线传感器网络时间同步检验方法
US8959494B2 (en) * 2012-03-20 2015-02-17 Massively Parallel Technologies Inc. Parallelism from functional decomposition
US9424168B2 (en) * 2012-03-20 2016-08-23 Massively Parallel Technologies, Inc. System and method for automatic generation of software test
US9977655B2 (en) 2012-03-20 2018-05-22 Massively Parallel Technologies, Inc. System and method for automatic extraction of software design from requirements
US9324126B2 (en) 2012-03-20 2016-04-26 Massively Parallel Technologies, Inc. Automated latency management and cross-communication exchange conversion
US9229688B2 (en) 2013-03-14 2016-01-05 Massively Parallel Technologies, Inc. Automated latency management and cross-communication exchange conversion
US11636245B2 (en) 2021-08-11 2023-04-25 International Business Machines Corporation Methods and systems for leveraging computer-aided design variability in synthesis tuning

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2317245A (en) * 1996-09-12 1998-03-18 Sharp Kk Re-timing compiler integrated circuit design

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6226776B1 (en) * 1997-09-16 2001-05-01 Synetry Corporation System for converting hardware designs in high-level programming language to hardware implementations
US7035781B1 (en) * 1999-12-30 2006-04-25 Synopsys, Inc. Mixed language simulator
US20030121027A1 (en) * 2000-06-23 2003-06-26 Hines Kenneth J. Behavioral abstractions for debugging coordination-centric software designs
US20030005407A1 (en) * 2000-06-23 2003-01-02 Hines Kenneth J. System and method for coordination-centric design of software systems
US6598218B2 (en) * 2000-12-19 2003-07-22 United Microelectronics Corp. Optical proximity correction method
US6691301B2 (en) * 2001-01-29 2004-02-10 Celoxica Ltd. System, method and article of manufacture for signal constructs in a programming language capable of programming hardware architectures
US7299470B2 (en) * 2001-09-13 2007-11-20 International Business Machines Corporation Method and system for regulating communication traffic using a limiter thread
US6964029B2 (en) * 2002-10-31 2005-11-08 Src Computers, Inc. System and method for partitioning control-dataflow graph representations

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2317245A (en) * 1996-09-12 1998-03-18 Sharp Kk Re-timing compiler integrated circuit design

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
HITOSHI OKEWATARI, JIM HIWATASHI ET AL: "Multi Processor ni yoru Bunsan Shori o Ishiki Shita Senyo Processor Sekkei Shien System SYARDS no Kochiku. "Syards: A design system for special purpose processors using distributed processing with a multiprocessor."", INFORMATION PROCESSING SOCIETY OF JAPAN KENKYU HOKOKU, INFORMATION PROCESSING SOCIETY OF JAPAN, vol. 95, no. 6, 20 January 1995 (1995-01-20), pages 105 - 112, XP002977661 *
KAZUTOSHI WAKABAYASHI ET AL.: "Densoyo LSI o Dosa Gosei de Kaihatsu, Kino Sekkei no Kikan ga 1/10 ni Tanshuku", NIKKEI ELECTRONICS, NIKKEI BUSINESS PUBLICATIONS, INC, no. 655, 12 February 1996 (1996-02-12), pages 147 - 169, XP002977660 *
KITAGUCHI ET AL.: "Jitsujikan Seiyaku o Yusuru Tan'itsu Bus System no JAVA ni yoru Model-ka oyobi Parametric Model Checking o Mochiita Sekkei Shubo no Teian. "Modeling single bus system with real-time constraints by Java and design methodology using parametric model checking."", INFORMATION PROCESSING SOCIETY OF JAPAN KENKYU HOKOKU, INFORMATION PROCESSING SOCIETY OF JAPAN, vol. 2002, no. 113, 28 November 2002 (2002-11-28), pages 19 - 24, XP002977662 *
MASAYUKI IENAGA ET AL.: "Seigyo Shori Hardware no Koi Gosei no Tame no Kosoku na Menseki/Jikan Saitekika Algorithm", DA SYMPOSIUM 2000, INFORMATION PROCESSING SOCIETY OF JAPAN, vol. 2000, no. 8, 17 July 2000 (2000-07-17), pages 27 - 32, XP002977658 *
NAKATA, A. ET AL.: "Deriving Parameter conditions for Periodic Timed Automata Satisfying Real-Time Temporal Logic Formulas", PROC. OF IFIP TC6/WG6. 1 INT. CONF. ON FORMAL TECHNIQUES FOR NETWORKED AND DISTRIBUTED SYSTEMS (FORTE2001), KLUWER ACADEMIC PUBLISHERS, August 2001 (2001-08-01), pages 151 - 166, XP002977659 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010286885A (ja) * 2009-06-09 2010-12-24 Toshiba Corp アーキテクチャ検証装置
US9027002B2 (en) 2010-10-27 2015-05-05 Hitachi, Ltd. Method of converting source code and source code conversion program
US11537415B2 (en) 2018-10-02 2022-12-27 Inter-University Research Institute Corporation Research Organization Of Information And Systems Information processing apparatus, information processing circuit, information processing system, and information processing method

Also Published As

Publication number Publication date
AU2003272931A1 (en) 2004-05-13
US20060015858A1 (en) 2006-01-19
JP3899104B2 (ja) 2007-03-28
JPWO2004038620A1 (ja) 2006-02-23

Similar Documents

Publication Publication Date Title
US20210081258A1 (en) Synthesis Path For Transforming Concurrent Programs Into Hardware Deployable on FPGA-Based Cloud Infrastructures
US7143388B1 (en) Method of transforming software language constructs to functional hardware equivalents
USRE40925E1 (en) Methods for automatically pipelining loops
US7509619B1 (en) Auto generation of a multi-staged processing pipeline hardware implementation for designs captured in high level languages
US6026219A (en) Behavioral synthesis links to logic synthesis
WO2004038620A1 (ja) システム開発方法及びデータ処理システム
Coussy et al. GAUT: A High-Level Synthesis Tool for DSP Applications: From C Algorithm to RTL Architecture
US7234126B2 (en) Task concurrency management design method
US20020166110A1 (en) Apparatus and method for performing event processing in a mixed-language simulator
US8386973B2 (en) Behavioral synthesis apparatus, method, and program having test bench generation function
JP2002140379A (ja) 高位合成方法および高位合成装置
US20070271080A1 (en) Model generation method for software/hardware collaboration design
US6952817B1 (en) Generating hardware interfaces for designs specified in a high level language
JP2007207120A (ja) システム検証装置及びその検証方法
JPWO2004036463A1 (ja) コンパイラ及び論理回路の設計方法
US8260597B1 (en) Accessing time driven environment data stores from a state driven environment
Gladigau et al. A system-level synthesis approach from formal application models to generic bus-based MPSoCs
US20020183997A1 (en) Apparatus and method for specifying the configuration of mixed-language simulation models
US7113901B1 (en) Reuse of hardware components
Ku et al. Synthesis of asics with hercules and hebe
Mahajan et al. Verification driven formal architecture and microarchitecture modeling
US20020170037A1 (en) Apparatus and method for controlling event ordering in a mixed- language simulator
Gajski et al. Methodology for design of embedded systems
US9891955B2 (en) Heterogenous multicore processor configuration framework
Pinto Metropolis design guidelines

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004546404

Country of ref document: JP

ENP Entry into the national phase

Ref document number: 2006015858

Country of ref document: US

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 10533062

Country of ref document: US

122 Ep: pct application non-entry in european phase
WWP Wipo information: published in national office

Ref document number: 10533062

Country of ref document: US