WO2002101564A1 - Mutiprocessor system, method for designing the same, and multiprocessor system described in hardware describing language - Google Patents

Mutiprocessor system, method for designing the same, and multiprocessor system described in hardware describing language Download PDF

Info

Publication number
WO2002101564A1
WO2002101564A1 PCT/JP2001/004965 JP0104965W WO02101564A1 WO 2002101564 A1 WO2002101564 A1 WO 2002101564A1 JP 0104965 W JP0104965 W JP 0104965W WO 02101564 A1 WO02101564 A1 WO 02101564A1
Authority
WO
WIPO (PCT)
Prior art keywords
bus
processors
engine
internal
data
Prior art date
Application number
PCT/JP2001/004965
Other languages
French (fr)
Japanese (ja)
Inventor
Yukoh Matsumoto
Original Assignee
Tops Systems Corporation
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 Tops Systems Corporation filed Critical Tops Systems Corporation
Priority to PCT/JP2001/004965 priority Critical patent/WO2002101564A1/en
Publication of WO2002101564A1 publication Critical patent/WO2002101564A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/362—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
    • G06F13/364—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control using independent requests or grants, e.g. using separated request and grant lines

Definitions

  • the present invention relates to a multiprocessor system and a design method thereof, and a multiprocessor system described by a hardware description language. Background art
  • a programming language used for circuit design of semiconductor devices such as LSIs is generally called a hardware description language (HDL).
  • Representative hardware description languages include VHDL (VHSIC Hardware Description Language) and Verilog-HDL.
  • the hardware description language also supports low-level hardware description such as RTL (register transfer level) and gate level. This makes it possible to perform a top-down design that describes the operation level, gate level, etc. in a series of processes from hardware architecture design to late design and testing. Therefore, design productivity and design reliability can be dramatically improved.
  • RTL register transfer level
  • the present invention provides a shared bus, a plurality of processors connected to the shared bus, and a round-robin system for issuing a bus use request to the shared bus issued from the plurality of processors.
  • An arbitration machine for tracing A method for designing a multiprocessor system comprising a hardware description language, wherein the source text in the hardware description language supports up to a predetermined maximum number of processors.
  • a description of the translation mechanism and an instance of the processor are generated up to an arbitrarily set number equal to or less than the maximum number of processors, and the plurality of processors are implemented in the multi-processor system.
  • the present invention provides a method for designing a multiprocessor system according to claim 1, wherein the plurality of processors comprises a plurality of different processors.
  • the present invention (claim 3) provides a method for designing a multiprocessor system according to claim 1, wherein the plurality of processors are provided with an instruction to stop the operation. .
  • the present invention (claim 4) provides a method for designing a multiprocessor system according to claim 1, wherein the plurality of processors share a plurality of buses.
  • the present invention (claim 5) provides a method for designing a multiprocessor system according to claim 1, wherein an arbitration mechanism is mounted on each of the plurality of processors. .
  • the present invention (claim 6) provides a method for designing a multiprocessor system according to claim 1, wherein the hardware description language is VHDL.
  • a shared bus is connected to the shared bus.
  • a multi-processor comprising a plurality of connected processors and an arbitration mechanism for performing arbitration by round robin of a bus use request to the shared bus issued from the plurality of processors.
  • a multiprocessor system is provided, wherein each of the plurality of processors is provided with an instruction for stopping its operation.
  • the present invention (claim 8) is based on a shared bus, a plurality of processors connected to the shared bus, and a round robin of a bus use request issued from the plurality of processors to the shared bus.
  • An arbitration mechanism that performs arbitration is a multiprocessor system described by a hardware description language, and the source text in the hardware description language is a predetermined maximum processor.
  • a description of the arbitration mechanism that supports up to the number of processors and an instance of the processor are generated up to an arbitrarily set number equal to or less than the maximum number of processors, and the plurality of processors are added to the multi-processor system.
  • Multiplicity described in a hardware description language that includes a description that implements Provide a processor system.
  • FIG. 1 is a block diagram of a single-chip multiprocessor system adopting a distributed bus / bitrition system according to an embodiment of the present invention.
  • FIG. 2 is a block diagram showing a connection relationship of control signals of a single-chip multiprocessor system employing a distributed bus arbitration system according to an embodiment of the present invention.
  • FIG. 3 is an explanatory diagram showing the arbitration relationship between each bus and each cell by the adaptive round robin in the distributed bus bit rate method according to the embodiment of the present invention. is there.
  • FIG. 4 shows a program and a RISC engine or DSP engine using the internal instruction bus IBUS, the internal data bus DBUS, and the internal system bus SBUS in the distributed bus bit rate system according to the embodiment of the present invention.
  • Read / write cycle with memory IM and data memory DM and using the internal system bus SBUS from the mass storage controller MC, RISC engine or DSP engine.
  • the controller BC the light cycle to the peripheral bus IF, and the internal system bus SBUS, the master controller MC and the memory IM for programs and the memory DM for data are used.
  • FIG. 2 is a diagram showing a lead cycle and a light cycle.
  • FIG. 5 is a diagram showing a light site from a RISC engine or a DSP engine to a memory DM for overnight using an internal data bus DBUS in a distributed bus * bit-ratio method according to an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating a case where READ_BUSY is generated in an address transmission cycle and the next read request is prohibited in arbitration.
  • FIG. 4 is a diagram showing a write cycle from a RISC engine or a DSP engine to a data memory DM using an internal data bus DBUS in the distributed bus / bit-bit system according to the embodiment; It shows a case where the bus is used continuously by issuing a business after acquiring the right to use.
  • FIG. 5 is a diagram showing a light site from a RISC engine or a DSP engine to a memory DM for overnight using an internal data bus DBUS in a distributed bus * bit-ratio method according to an embodiment of the present invention.
  • FIG. 6 is a diagram
  • FIG. 7 is a diagram illustrating an example of a distributed bus arbitration scheme according to an embodiment of the present invention, in which an internal system bus SBUS is used and an external controller is provided by a master controller MC, a RISC engine or a DSP engine. It is a figure showing a lead cycle from memory.
  • FIG. 8 is a diagram showing a configuration in which the internal system bus SBUS is used in the distributed bus bit rate system according to the embodiment of the present invention to read data from an external memory by the master controller MC, RISC engine, or DSP engine.
  • This is a diagram showing a read cycle of the master controller MC, the RISC engine or the DSP engine notifies the bus controller BC of the number of transfer data n when transmitting an address. This indicates that
  • FIG. 9 is a diagram illustrating a program memory IM performed by the master controller MC using the internal system bus SBUS in the distributed bus * bit rate system according to the embodiment of the present invention.
  • FIG. 4 is a diagram showing a cycle of a program. In a write cycle to a program memory IM, an RE-BUSY is generated in an address transmission cycle, and an internal system bus SBUS and an internal instruction bus IBUS are combined. Indicates that the ban is prohibited.
  • FIG. 10 is a diagram for explaining the priority indicated by priority (l: 0) in the distributed bus / key bit rate system according to the embodiment of the present invention.
  • FIG. 11 shows the master controller MC according to the access status of the program memory by the internal instruction bus IBUS and the internal system bus SBUS in the distributed bus and bit rate system according to the embodiment of the present invention.
  • Generates i 6 is a table showing a signal generation algorithm.
  • FIG. 12 is a diagram for explaining the meaning of the request (O) output from the RISC engine RE0 in the distributed bus-and-bit rate system according to the embodiment of the present invention.
  • FIG. 13 is a diagram for explaining the rules of arbitration of the internal instruction bus' IBUS in the distributed bus key pit resolution system according to the embodiment of the present invention.
  • FIG. 14 is a diagram illustrating the meaning of the command cmd in the distributed bus arbitration scheme according to the embodiment of the present invention.
  • FIG. 15 is a diagram for explaining the priority indicated by d-priority (l: 0) in the distributed bus / key bit rate system according to the embodiment of the present invention. As shown here, arbitration by round robin is realized by updating d_priority (l: 0).
  • FIG. 16 is a diagram illustrating a main controller according to the state of access to data memory by the internal data bus DBUS and the internal system bus SBUS in the distributed bus / key bitrate method according to the embodiment of the present invention.
  • 9 is a table showing a generation algorithm of a d_busy (l: 0) signal generated by MC.
  • FIG. 17 is a diagram for explaining the meaning of d-request (O) output from the RISC engine RE0 in the distributed bus / bit rate system according to the embodiment of the present invention.
  • FIG. 18 is a diagram illustrating rules for arbitration of the internal instruction bus IBUS in the distributed bus arbitration system according to the embodiment of the present invention.
  • FIG. 19 is a diagram showing a command for data memory in the distributed bus / bit rate system according to the embodiment of the present invention.
  • FIG. 4 is a diagram for explaining the meaning of a command d—cmd (3: 0).
  • FIG. 20 is a diagram for explaining a priority indicated by sys-priority (2: 0) in the distributed bus / biter bit rate system according to the embodiment of the present invention.
  • FIG. 21 is a diagram for explaining the meaning of sys-request-sl (0) output by the bus controller BC in the distributed bus arbitration system according to the embodiment of the present invention.
  • FIG. 22 is a diagram for explaining the meaning of the sys-busy (O) signal driven by the no controller BC in the distributed bus arbitration system according to the embodiment of the present invention.
  • FIG. 23 is a diagram illustrating the meaning of the sys_busy (l) signal driven by the controller BC in the distributed bus arbitration scheme according to the embodiment of the present invention.
  • FIG. 24 is a diagram showing a state in which the master controller MC is accessed depending on the access state of the memory for data by the internal data bus DBUS and the internal system bus SBUS in the distributed bus arbitration system according to the embodiment of the present invention.
  • This is a table showing the algorithm for generating sys — busy (3: 2) signal to generate.
  • FIG. 25 shows the master controller MC generating the status of the access of the program memory by the internal instruction bus IBUS and the internal system bus SBUS in the distributed bus arbitration system according to the embodiment of the present invention.
  • 9 is a table showing an algorithm for generating a s ys one busy (5: 4) signal.
  • FIG. 26 is a diagram illustrating the meaning of the sys-busy (6) signal generated by the peripheral bus IF in the distributed bus-key bit rate system according to the embodiment of the present invention.
  • FIG. 27 is a diagram illustrating a case where the peripheral bus IF in the distributed bus / arbitration system according to the embodiment of the present invention is driven.
  • FIG. 14 is a diagram for explaining the meaning of a sys-busy (7) signal.
  • FIG. 28 is a view for explaining the meaning of sys_request (0) output from the RISC engine RE0 in the distributed bus arbitration scheme according to the embodiment of the present invention.
  • FIG. 29 is a diagram for explaining the rules of arbitration of the internal system bus SBUS in the distributed bus arbitration system according to the embodiment of the present invention.
  • FIG. 30 is a diagram showing a list of commands output by the master controllers MC, the RISC engine, and the DSP engine in the distributed bus arbitration system according to the embodiment of the present invention.
  • FIG. 31 is a diagram illustrating a general design procedure of a multiprocessor system using a hardware description language according to an embodiment of the present invention.
  • FIG. 32 is a package file in the source text of the multiprocessor system according to the embodiment of the present invention.
  • FIG. 33 is a mounting part in the source text of the multiprocessor system according to the embodiment of the present invention.
  • FIG. 4 is a diagram illustrating the first half of the file.
  • FIG. 34 is a diagram illustrating the latter half of the file of the mounting part in the source text of the multiprocessor system according to the embodiment of the present invention.
  • FIG. 1 is a block diagram of a single-chip multiprocessor system employing a high-performance distributed bus / arbitration scheme for an internal bus according to an embodiment of the present invention.
  • This multiprocessor system includes a master It has five processors: a controller MC, a RISC engine RE0, a RISC engine RE1, and a DSP engine DEO and a DSP engine DEI.
  • the master controller MC performs overall control, and is an asymmetric multiprocessor system.
  • the RISC engine RE0 and the RISC engine RE1 are generally general-purpose RISC processors provided on an equal footing, respectively. However, the same processor engine or different processor engines may be used. An existing processor engine may be used, or a new processor engine may be designed. However, these processor engines need to be equipped with distributed bus arbitration according to the embodiment of the present invention, which will be described in detail below.
  • the DSP engine DE0 and the DSP engine DE1 are numerical processors having specific processing contents, and are capable of processing a high-rate data stream in real time.
  • the DSP engine DE 0 and the DSP engine DE 1 can be implemented by using the same existing processor engine or by using different existing processor engines. May be designed. However, each of these processor engines still needs to implement the distributed bus arbitration according to the embodiment of the present invention described in detail below.
  • RISC engine RE 0 and RISC engine RE 1 and DSP engine DE 0 and DSP engine DE 1 are connected via internal instruction bus IBUS and internal system bus SBUS. Connected to the program memory IM. Similarly, they are connected to the data memory DM via the internal data bus DBUS and the internal system bus SBUS. These RISC engine and DSP engine are the internal instruction bus IBUS, the internal data bus DBUS and the internal system bus SBUS.
  • the program memory IM and the data memory DM are bus slave devices of the internal instruction bus IBUS and the internal data bus DBUS.
  • the master controller MC is connected to the program memory IM via the internal system bus SBUS, and is connected to the data memory DM via the internal data bus DBUS.
  • the master controller MC is the bus master of the internal system bus SBUS.
  • Each of these internal instruction bus IBUS, internal data bus DBUS, and internal system bus SBUS has a bus width of 128 bits, and each has a 32-bit address bus. If this 128-bit bus width is driven at 200 MHz, data can be transferred with a maximum bandwidth of 3.2 Gbytes.
  • these numbers are exemplary, and further expansion or contraction is determined by the application.
  • the internal data bus DBUS has d-priority (l: 0), d-busy (3: 0), d-request (3: 0), d_cmd (3: 0), d-ready, Each signal line of d_berr is provided.
  • the internal system bus SBUS includes sys-prioritvC2: 0).
  • Sys_busy (8: 0), sys- requesti4: CH, sys- request_s 1 (1: 0), sys- address (31: 0), sys_cmd (10: 0), sys biu-berr, sys-ipu-berr, sys-dm-berr signal lines are provided.
  • Figure 2 is a block diagram showing the connection relationship. However, the error related signal (X-berr) is omitted in the figure.
  • two address data buses are provided for accessing external memory.
  • One is an external system bus EM1, which has a 22-bit address bus and a 16-bit data bus. Then, up to 8 Mbytes of ROM / flash ROM, up to 16 Mbytes of RO MZ flash ROM, and up to 24 Mbytes of external resources are connected to this external system bus EM1. Can be connected.
  • the other is the external system bus EM2, which has a 20-bit address bus and a 16-bit or 32-bit data bus.
  • a maximum of 8 Mbytes of ROM / flash ROM, a maximum of 32 Mbytes of SRA MZ SDRAM, and a maximum of 2 Mbytes of external resources (peripherals) are transferred to the external system bus EM 1
  • the built-in bus controller BC accesses this multiprocessor system and external memory.
  • This bus controller BC is connected to the RISC engine RE 0 and RISC engine via the internal system bus SBUS.
  • RE 1 and DSP engine DEO and DSP engine DE 1 as well as the controller MC and split transaction.
  • the no-controller BC is connected to the master controller MC by a dedicated instruction bus Ml and a data bus MD, and provides instructions to the master controller MC. And data supply. Also, an instruction cache is interposed between the bus controller BC and the master controller MC, and performs caching in a usual manner.
  • a timer circuit and an IZO port are connected to an internal system bus SBUS via a peripheral bus and a peripheral bus IF (interface circuit).
  • This evening circuit is equipped with six timers, which are connected to the RISC engine RE0, RISC engine RE1, DSP engine DEO, DSP engine DEI, and master controller MC via the timer bus. Perform an interrupt.
  • a timer interrupt is performed to the CPU interrupt control circuit via the peripheral bus.
  • the processor interrupt control circuit issues a processor interrupt of each processor engine via the processor interrupt request bus.
  • the controller BC, the peripheral bus IF, the program memory IM and the data memory DM are bus slave devices of the internal system path SBUS.
  • RISC engine RE0 RISC engine RE1
  • DSP engine DEO DSP engine DE1
  • master controller MC bus controller BC
  • instruction cache instruction cache
  • timer circuit processor Split processor interrupt control circuit
  • peripheral bus IF peripheral bus I IF port
  • I IF port The chip is implemented as a one-chip integrated circuit.
  • the arbitration method adopts a distributed arbitration method that can determine the priority in a short time by minimizing the round trip of the signal. That is, each processor engine has a built-in bus arbiter, and all of the control signals related to arbitration described below are input to the sub-arbiter. Then, can the bus arbiter acquire the right to use the bus for each cycle by referring to requests from other processors and its own requests, the busy status of the bus, and the priority order? Judge whether or not. As a result, the processor that has acquired the right to use the bus can send commands and addresses in the next cycle and use the bus. Priorities are determined on a round robin basis based on the right to use the bus.
  • RISC engine R Each of E0, RISC engine RE1, DSP engine DEO and DSP engine DE1 has the following transactions with program memory IM and data memory DM: (1) Address address It has one bit rate phase, (2) address command and phase, and (3) data transfer phase. These three phases are implemented in pipelines with a latency of two clocks and a throughput of one clock cycle. In other words, 128 bits of data can be transferred in one clock.
  • transactions between the master controller MC, the RISC engine RE 0, the RISC engine RE 1, the DSP engine DEO, and the DSP engine DE 1 and the bus controller BC are performed in the following manner. This is done in a transaction. That is, (1) address * address resolution phase, (2) address / command phase, (3) data arbitration phase, and (4) data Overnight Has a transfer phase. However, (1) address arbitration phase and (2) address command phase, (3) data and arbitration 'phase and (4) data transfer phase Is divided.
  • Arbiter one in each processor, c and each bus arbiter to issue a re Quest to use the bus during the state in which output re QUEStionable I to check the signal busy ⁇ velvetleaf preparative Resho Nsai cycle First, it determines whether it can acquire the right to use the bus by referring to requests from other processors, its own requests, and priorities.
  • FIG. 3 is an explanatory diagram showing the arbitration relationship between each bus and cell using adaptive round robin.
  • the bus controller B C always has the highest priority and the internal system bus S B
  • the right to use US can be obtained. Even if the bus controller BC obtains the right to use the bus, the priority of other buses and buses does not move.
  • the master controller Priority is set by adaptive round robin between the MC, the RISC engine RE0, the RISC engine RE1, and the DSP engine DEO and the DSP engine DE1. Processors issuing requests in the given order get the right to use the bus.
  • no-controller BC, peripheral bus IF, and other bus-master (processor) groups perform fixed-priority distributed arbitration, and other bus-master groups.
  • decentralized arbitration is performed based on adaptive round robin.
  • efficient priority arbitration of the multiprocessor bus and split transactions with fixed priorities are provided, thereby realizing efficient composite arbitration.
  • the requesting processor immediately processes the data.
  • the processing speed is increased by one cycle.
  • the processor that has given the bus use right to the bus controller BC may delay the processing by one cycle, or may have no substantial processing delay.
  • the basic bus cycles of the internal instruction bus IBUS and the internal data bus DBUS are pipelined so that they can be executed continuously in one clock cycle of throughput.
  • the pass cycle is processed in a three-stage pipeline as described above.
  • a fetch cycle is accepted every clock, so that each RISC engine and DSP engine can execute an instruction fetch once every four cycles on average.
  • the lower 4 bits of the branch target address are 8h or more, that is, only one instruction code (2 bytes) of 4 instructions or less can be fetched in one fetch cycle. It is used when it is necessary.
  • Figures 4A, 4B, and 4C use the internal instruction bus IBUS, the internal data bus DBUS, and the internal system bus SBUS to connect the RISC engine or DSP engine to the program memory IM or data.
  • the read cycle and the write cycle between the master controller MC and the program memory IM and the data memory DM are performed.
  • FIG. 4B shows a read cycle in which the bus is used continuously by issuing a visit after acquiring the right to use the pass.
  • Fig. 4C shows a continuous read cycle from the program memory IM and the data memory DM using the internal instruction bus IBUS, internal data bus DBUS, and internal system bus SBUS. However, this shows a read cycle where different processors take turns using the bus.
  • Fig. 5 is a diagram showing a write cycle from the RISC engine or DSP engine to the data memory DM using the internal data bus DBUS.
  • the read cycle is performed in the address transmission cycle. BUSY is generated and the next read request is prohibited in arbitration.
  • Figure 6 also shows This figure shows a write cycle from the RISC engine or DSP engine to the memory DM for overnight using the internal data bus DBUS.
  • a bus is issued after the right to use the bus is acquired. In this case, the bus is used continuously. At the end of a continuous write, a read busy must be issued to prohibit the next read request.
  • a continuous write to the bus controller BC one cycle request is issued. The number of transfers is notified when a command is sent using a command.
  • the bus controller BC always has the priority of using the bus. Can be used.
  • FIG. 7 is a diagram showing a read cycle from an external memory by the mass controller MC, RISC engine, or DSP engine using the internal system bus SBUS.
  • the master controller MC, RISC engine or DSP engine sends an address together with a command to the bus controller BC after the arbitration.
  • the bus controller BC receives data from external memory, it obtains the right to use the internal system bus SBUS by arbitration (request), issues a Ready signal, and issues the corresponding RISC engine or DSP.
  • the engine captures that data.
  • Figure 8 is a diagram showing a read cycle from an external memory by a mass controller MC, RISC engine or DSP engine using the internal system bus SBUS.
  • the master controller MC> RISC engine or DSP engine Notify n to the bus controller BC.
  • the no controller BC transfers the ready from the external bus and transfers the data continuously, it keeps issuing the request and transfers the data to the internal bus in response to the ready from the external bus. Can be.
  • FIG. 9 is a diagram showing a write cycle to the program memory IM performed by the mass controller MC using the internal system bus SBUS.
  • RE_BUSY is generated in the address transmission cycle, and arbitration of the internal system bus SBUS and the internal instruction bus IBUS is prohibited. You.
  • FIG. 10 is a diagram for explaining the priority indicated by priority (l: 0). By updating i_priority (l: 0) as shown here, arbitration by round robin is realized.
  • Each RISC engine or DSP engine issues a request to use the internal instruction bus IBUS when it is in the “available” state upon seeing the busy (l: 0) signal, and according to the priority, the internal instruction bus IBUS is used. Acquire the right to use.
  • the busy (0) signal is output by the master controller MC.
  • Figure 11 shows the generation algorithm of the i busy (0) signal generated by the master controller MC according to the access status of the program memory by the internal instruction bus IBUS and the internal system bus SBUS.
  • (1st) or (2nd) indicates the order in which requests overlap. For example, when read requests overlap, the first processed read request is Read (lst), and the next processed read request is Read (2nd) It is.
  • Write Last means the last write cycle of continuous writing.
  • the busy (l) signal is 1 when the RISC engine or DSP engine that has acquired the bus right sends a command and the internal instruction bus IBUS is used continuously, and only 1 cycle of the internal instruction bus IBUS. If used
  • the program memory outputs a data ready signal to the read request and outputs ready.
  • This data ready signal ready indicates that data transmission for the address transmission (command) is ready.
  • the processor receives the data for the read by seeing the data ready signal from the program memory and ready. Here, the data ready is the next cycle after sending the address.
  • the program memory reads the internal system bus SBUS and then reads the internal instruction bus.
  • the data cycle (and ready) to the internal instruction bus IBUS is delayed by one cycle to read from IBUS.
  • each RISC engine or DSP engine For requests to use the bus from the RISC engine or DSP engine, each RISC engine or DSP engine outputs a 1-bit signal in request (3: 0). That is, RISC engine RE 0 is request (0), RISC engine RE 1 is request (l), DSP engine DEO is i request (2), DSP engine DEI then drives request (3).
  • FIG. 12 is a diagram for explaining the meaning of request (O) output from the RISC engine RE 0. Since a fetch cycle is accepted every clock, each RISC engine or DSP engine can execute an instruction fetch once every four cycles on average.
  • the lower 4 bits of the get address at the end of the branch are 8h or more, that is, only one instruction code is 4 bytes or less in one fetch cycle. Used when fetching is not possible.
  • the RISC engine and the DSP engine can use the internal instruction bus IBUS for two consecutive cycles by a double fetish cycle.
  • FIG. 13 is a diagram for explaining the rules of arbitration of the internal instruction bus IBUS.
  • the priority (l: 0) of the next cycle is the RISC engine or DSP engine next to the RISC engine or DSP engine that has acquired the bus use right (the order is RE0 ⁇ RE1 ⁇ DE0 ⁇ DE1). ⁇ RE0).
  • FIG. 14 is a diagram for explaining the meaning of the command icmd.
  • Program memory Writing to is performed via the internal system bus SBUS.
  • program memory is a data cycle when the address sent from the processor is outside the address space where the program memory is mounted. returned. At this time, the contents of the program memory output data (12f: 0) are invalid.
  • FIG. 15 is a diagram illustrating the priority indicated by d—priority (l: 0). As shown here, d_priority (l: 0) is updated. Arbitration by round robin is realized.
  • Each RISC engine or DSP engine issues a request to use the internal bus DBUS when it is in the “available” state by seeing the d_busy (3: 0) signal, and according to the priority, the internal instruction bus IBUS. Acquire the right to use.
  • d_busy (3: 2), a processor that has acquired the bus use right is generated according to the bus use status in the address transmission cycle.
  • the master controller MC drives "00".
  • Figure 16 shows the master controller MC card depending on the access status of data memory via the internal data bus DBUS and internal system bus SBUS.
  • 9 is a table showing a generation algorithm of a generated d_busy (l: 0) signal.
  • d—busy (2) is a reserved bit for the future, and is used when an internal resource is added.
  • d_busy (3) is 1 if the RISC engine or DSP engine that has acquired the bus right uses the internal data bus DBUS continuously when sending a command, or 1 if the internal data bus DBUS is used for only one cycle. Drive 0 for
  • each RISC engine or the DSP engine For requests to use the bus from the RISC engine or the DSP engine, each RISC engine or the DSP engine outputs a 1-bit signal in d—request (3: 0). That is, RISC engine RE 0 drives d_request (0), RISC engine RE 1 drives d_request (l), DSP engine DEO drives d-request (2), and DSP engine DEI drives d-request (3).
  • FIG. 7 is a diagram for explaining the meaning of d—request (0) output by the RISC engine RE0.
  • FIG. 18 is a diagram for explaining the rules of arbitration of the internal instruction path IBUS.
  • d_priority (l: 0) of the next cycle is the RISC engine or DSP engine next to the RISC engine or DSP engine that has acquired the bus use right (the order is RE0 ⁇ RE1 ⁇ DE0 ⁇ DE1). ⁇ RE0).
  • each RISC engine and DSP engine obtains the right to use the bus in the arbitration cycle, and then, in the next cycle (address sending cycle), stores the data memo together with the address.
  • FIG. 19 is a view for explaining the meaning of the command d—cmd (3: 0) for the data memory.
  • the data memory outputs a data ready signal d_ready for a read request.
  • the data ready signal d_ready indicates that data for the address transmission (command) is ready.
  • the processor receives the data for the read by looking at the data ready signal d_ready from the program memory.
  • the data ready is the next cycle after sending the address.
  • the program memory reads after reading from the internal system bus SBUS. Since data is read from the internal instruction bus IBUS, the data cycle (d_re ady) to the internal data bus DBUS is delayed by one cycle.
  • the master controller MC, the RISC engine RE0, the RISC engine RE1, the DSP engine DE0, and the DSP engine DE1 are connected to the five processors via the internal system bus SBUS. Read and write cycles for BC and Peripheral bus IF and program memory IM and data—evening memory DM Can run. However, the bus controller
  • the BC can directly execute a read cycle and a write cycle on the program memory I M and the data memory D M.
  • the read cycle from the five processors to the master controller MC uses split 'transactions to increase effective bus utilization. ing.
  • FIG. 20 is a diagram for describing the priority indicated by sys_priority (2: 0).
  • each RISC engine or DSP engine outputs a 1-bit signal in sys_request_sl (l: 0).
  • the bus controller BC drives sys_request-sl (0)
  • the peripheral bus IF drives sys_request_sl (l) .
  • Figure 21 shows the meaning of sys_request_sl (0) output by the bus controller BC.
  • the peripheral bus IF cannot output sys_request sl (0) when sys_request_sl (0) is asserted.
  • each RISC engine or DSP engine cannot output sys_request ( 4 : 0) when sys-request-sl (0) or sys-request-sl (0) is asserted.
  • Each RISC engine or DSP engine uses the sys-busy (8: 0) signal (bus code) when neither the no-controller BC nor the peripheral bus IF requests the use of the internal system bus SBUS.
  • the sys_busy (0) signal is driven by the bus controller BC. That is, when the no controller BC asserts the sys_busy (0) signal, the other processor issues a bus use request for the purpose of accessing the bus controller BC. Can not. Specifically, when the bus controller BC receives a read command or an address from the master controller MC, RISC engine, or DSP engine, the bus controller BC temporarily stores it in the controller. The buffer is kept in the buffer, and the external memory which is relatively slow is accessed and the read result is returned. However, when the read command is issued continuously and the internal buffer becomes full, it asserts the sys-busy (O) signal and stops further reception.
  • FIG. 22 is a diagram for explaining the meaning of the sys-busy (l) signal driven by the bus controller BC.
  • the sys_busy (l) signal is output from the master controller MC, RISC engine, and DSP engine to the NOS controller. Outputs the command described later to BC and asserts for one clock at the same time. This prohibits other processors from accessing the controller BC until the controller BC returns a response state to the command (one clock). To do that.
  • FIG. 23 is a diagram for explaining the meaning of the sys-busy (l) signal driven by the bus controller BC.
  • Arbitration between the master controller MC, the RISC engine RE0 RISC engine RE1, the DSP engine DE0 and the DSP engine DE1 is performed by an adaptive round robin.
  • a 3-bit signal sys—priority (2: 0) is used to indicate the priority of using the internal data bus DBUS at a certain point in time.
  • FIG. 29 is a diagram for explaining the priority indicated by sys-priority (2: 0). As shown here, arbitration by round robin is realized by updating sys-priority (2: 0).
  • the sys—busy (3: 2) signal is driven by the master controller MC and indicates the status of the data memory DM. That is, the master controller MC monitors the access (command) to the data memory DM via the internal data bus DBUS and the internal system bus SBUS, and monitors its busy status. Is output.
  • Figure 24 is a table showing the algorithm for generating the sys_busy (3: 2) signal generated by the master controller MC according to the access status of data memory by the internal data bus DBUS and the internal system bus SBUS. .
  • the busy state neither read access nor write access can be requested, In the Ready Busy state, write access can be requested, but read access cannot be requested.
  • sys_busy (3: 2) "ll" indicates that the data ready from the data memory DM is delayed by one clock, so the internal system bus SBUS must be disabled in the busy state. Become.
  • the sys_busy (5: 4) signals are driven by the master controller MC and indicate the status of the program memory. That is, the master controller MC monitors access (command) to the program memory via the internal instruction bus IBUS and the internal system bus SBUS, and outputs the busy status.
  • Figure 25 shows the algorithm for generating the sys_busy (5: 4) signal generated by the MC according to the access status of the program memory by the internal instruction bus IBUS and the internal system bus SBUS.
  • the sys_busy (6) signal is driven by the peripheral bus IF and indicates the status of the peripheral bus IF.
  • Figure 26 shows the meaning of the sys_busy (6) signal generated by the peripheral bus IF.
  • the peripheral bus IF is connected to the master controller MC and the RISC interface.
  • the peripheral bus IF temporarily stores it in an internal buffer, accesses relatively slow peripheral circuits, and returns the result. .
  • the read command is issued continuously and the internal buffer becomes too busy, it asserts the sys_busy (6) signal and stops further reception.
  • the sys-busy (7) signal is output from the master controller M :, RISC engine, and DSP engine to the peripheral bus IF at the same time as one clock. To remove. This is to prevent other processors from accessing the peripheral bus IF until the response state to the command is returned from the peripheral bus IF (one clock).
  • FIG. 27 is a diagram for explaining the meaning of the sys—busy (7) signal driven by the peripheral bus IF.
  • the sys_busy (8) signal is used when the controller MC, RISC engine or DSP engine that has acquired the right to use the bus issues a command when the internal system bus SBUS is used continuously. Drive 0 when using only one cycle of system bus SBUS. This allows the bus to be used continuously.
  • the sys_busy (8) signal indicates that the mass controller MC, RISC engine, or DSP engine requires read access like the bus controller BC or the peripheral bus IF, and the data is ready. When waiting, this signal is output by the processor that has acquired the right to use the bus until the last ready is received from the command transmission cycle.
  • the request for using the internal system bus SBUS is svs requ
  • the master controller MC and each RISC engine and DSP engine output a 1-bit signal in est (4: 0). That is, RISC engine RE 0 is sys_request (0), RISC engine RE 1 is sys-request (l), DSP engine DE 0 is sys-request (2), DSP engine DE 1 is sys_request (3), master The controller MC drives sys-request (4).
  • FIG. 28 is a view for explaining the meaning of sys_request (0) output by the RISC engine RE0.
  • the right to use the bus is determined according to the rules shown in Figure 29. After acquiring the right to use the bus, the master controller MC, RISC and DSP engines output a command together with the address in the next cycle.
  • Figure 30 is a list of commands output by the master controller MC, RISC and DSP engines.
  • the Px of the command issuer SRC is the controller MG, RISC engine or D
  • the processor ID of the SP engine indicates the pass controller BC
  • DM indicates the data memory DM
  • IM indicates the program memory IM
  • IPU indicates the peripheral bus IF.
  • the command sys_cmd (3: 0) is the number of data to be transferred (used when the BIU is commanded in load multi and store multi). For example, “0000” is 16 long words, “000 1 "Is one longword, and” 1111 "is fifteen longwords.
  • the command sys—cmd (5: 4) is the data size (00: note, 01: word, 10: longword, 11: reserve). Identifies the store (0: store, 1: load), and sys_cmd (10: 7) indicates the destination of the access (excluding commands from BC). Change When "0000", the command is NOP.
  • the above multiprocessor system implements two RISC engines and two DSP engines.
  • Other components are mainly a mass controller MC, a pass controller BC, a peripheral bus IF, a program memory IM, and a data memory DM.
  • the number of RISC engines and DSP engines can be easily increased or decreased according to the required processing capacity.
  • an arbitration circuit corresponding to the maximum number of processors is previously provided for each.
  • the number of RISC engines and DSP engines can be changed freely.
  • this allows the number of engines to be actually operated in the installed RISC engine and DSP engine to be freely changed, and enables fine-grained power saving functions to be implemented in the application. It can be implemented at the case level.
  • the source text in the 81st software description language or an object obtained by compiling the source text includes useful features introduced by the present invention.
  • the physical device finally embodied also has features corresponding to those features. And, due to its features, it is possible to implement fine-grained power saving functions at the application level.
  • FIG 31 is a diagram illustrating the general design procedure for a multiprocessor system using a hardware description language.
  • source text is created in a hardware description language.
  • this source text is compiled to generate an object code.
  • an operation simulation is performed using this object code.
  • step S4 if the result of the operation simulation does not satisfy the required specifications, the source text is corrected, and the compilation and the operation simulation are performed again. The operation simulation is performed. If the result of the above meets the required specifications.
  • an actual physical device is created in step S5, and a final operation simulation is performed.
  • round robin arbitration some of the processors will work without any problems. In other words, the number of processors actually functioning does not matter for the arbitration circuit. There is only an upper limit on the number of processors that can do round robin.
  • the arbitration circuit As a result, there is little overhead for hardware.
  • the number of ID bits for managing the processors separately is only required to be different.
  • the number of pits of the processor ID for the RISC engine and the DSP engine is three. That is, the maximum number of processors is eight.
  • FIG. 32 is a package file in the source text of a multiprocessor system according to an embodiment of the present invention. This file declares the parameters and their values that will be referenced throughout the design.
  • a constant named RE-NUM is defined corresponding to the number of RISC engines
  • a constant named DE-NUM is defined corresponding to the number of DSP engines.
  • FIG. 32 shows the above embodiment, in which RE NUM and DE — Both NUM are listed as 2.
  • RE NUM and DE Both NUM are listed as 2.
  • the hardware of the master controller MC, the bus controller BC, the peripheral bus IF, the program memory IM, and the data memory DM is fixed.
  • FIG. 33 is a diagram illustrating the first half of the file (MISC.VHD) of the mounting part in the source text of the multi-processor system according to the embodiment of the present invention.
  • This file describes the design itself.
  • the ENTITY declaration of MISC declares the names of the input / output ports of the entire multiprocessor system and the types of signals to be connected.
  • the RISC engine is declared as a component called RE.
  • the processor number is an argument as GENERIC PARAMETER.
  • the DESP engine is declared as a component called DE. After all, the processor number is the argument as GENERIC PARAMETER.
  • the RISC engine and the DSP engine are equipped with the integration logic of the bus for 8 processors for each of the internal system bus SBUS, internal command bus IBUS and internal data bus DBUS. .
  • SIGNAL statement declares the names and types of signals used in the design called MISC. Up to the part described so far in the file of the implementation part, the actual RE NUM and DE The value of _NU M does not appear.
  • FIG. 34 is a diagram illustrating the latter half of the file (MIS C. VHD) of the mounting part in the source text of the multiprocessor system according to the embodiment of the present invention. That is, in the FOR loop, almost the same number of component cards RE — NUM and DE_NUM are repeatedly generated.
  • the variable i to be incremented here is passed as PROCES SOR-NUM, that is, the processor ID, and can be referred to as the drive of each request signal such as request as described above. It is described as follows. That is, for example, it is implemented to drive the request signal i_request [i]. Therefore, the same component that differs only in the suffix of the array of the request signal to be driven is repeatedly generated.
  • a power-down instruction (STOP instruction) is mounted in the RISC engine and the DSP engine in advance.
  • This STOP instruction is a normal instruction that can be used in a program. Is kept to a minimum.
  • an interrupt instruction from the mass controller MC is used.
  • the arbitration circuit in the adaptive round robin of the stopped processor does not issue a request to use the bus, and the arbitration priority is automatically reduced to the number of processors. Can adapt to the situation.
  • a RISC engine or a DSP engine is used as a processor type, but it is extremely easy to implement a different type of processor. That is, by adding a SIMD type processor engine (SE), a vector type processor engine (VE), a graphics processing processor engine (GE), etc.
  • SIMD type processor engine SE
  • VE vector type processor engine
  • GE graphics processing processor engine
  • the number of configurable systems can be increased to accommodate a very wide range of applications, such as the IP of a processor engine for the appropriate graphics processing. It is good to get and incorporate.
  • add a constant definition called GE—NUM and insert the code that generates the number of instances. In the above case, any combination is possible as long as the total power of RE-NUM, DE-NUM, and GE_NUM is up to 8.
  • the master controller MC and each RISC engine and DSP engine are asymmetric multiprocessor systems.
  • those skilled in the art can also implement a symmetric multiprocessor including only each RISC engine or DSP engine as an embodiment of the present invention from the above disclosure.
  • the combination of only the RISC engine and the DSP engine is used.
  • other engines for example, an S program memory, a D type engine, a graphics engine, a Vector type engine, or a custom engine are used.
  • a specific hard air block can also be incorporated as an engine as an engine.
  • the number of processor engines is four, but increasing the number of engines to 8, 16, or 32 in a similar manner is as follows. It is easily possible for those skilled in the art.
  • the internal memory is two, the instruction memory and the data memory.
  • the number of the external bus controller is one.
  • the internal peripheral unit is provided with an image and an I / O.
  • the peripheral device it is not possible to change the peripheral device to include various peripheral devices in the same manner. It is easily possible for traders.
  • the example of the architecture of the master controller, the RISC engine, and the DSP engine is shown.
  • the program memory IM and the data memory DM can transfer data in a no-way manner
  • the internal instruction bus IBUS and the internal data bus DBUS are used in the split transaction.
  • large-capacity program memory and data memory are connected to the internal instruction bus IBUS and internal data bus DBUS, and three buses are connected. Each of these may be a split transaction bus.
  • the bus use request from the RISC engine and DSP engine shall be a round robin arbitration system, and the bus use request from a large-capacity program memory and data memory shall be An arbitration method having a fixed priority with a higher priority may be used.
  • an arbitration circuit corresponding to the maximum number of processors is previously provided for each processor.
  • the number of RISC engines and DSP engines can be changed freely by installing them in the engine.
  • the number of engines to be actually operated can be freely changed among the mounted R13 (3 engines ⁇ 0 5? Engines), and a fine-grained power saving function can be applied to the application. It can be implemented at one session level.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Bus Control (AREA)
  • Multi Processors (AREA)

Abstract

A method for designing in a hardware describing language a multiprocessor system comprising a shared bus, a plurality of processors connected to the shared bus, and an arbitration mechanism for arbitration by round robin of bus use requests issued by processors to use the shared bus. A source text written in the hardware describing language includes a description of the arbitration mechanism for supporting up to a predetermined maximum number of processors and a description for creating a given number of instances of processors smaller than the maximum number of processors and equipping the multiprocessor system with processors.

Description

明細書 マルチプロセッサ · システムとその設計方法及びハー ドウ エア記述言語によって記述されたマルチプロセッサノ シス テム 技術分野  Description Multiprocessor system, design method thereof, and multiprocessor system described by hardware description language
本発明は、 マルチプロセッサ ' システムとその設計方法 及びハー ドウェア記述言語によって記述されたマルチプロ セッサ ' システムに関する。 背景技術  The present invention relates to a multiprocessor system and a design method thereof, and a multiprocessor system described by a hardware description language. Background art
LSIをはじめとする半導体デバイスの回路設計のために 使われるプログラミ ング言語は、 一般にハー ドウェア記述 言語 (. HDL: Hardware Description Language)と呼はれる。 代表的なハ一 ドウエア記述言語には、 VHDL(VHSIC Hard ware Description Language)や、 Verilog- HDL 力 ある。  A programming language used for circuit design of semiconductor devices such as LSIs is generally called a hardware description language (HDL). Representative hardware description languages include VHDL (VHSIC Hardware Description Language) and Verilog-HDL.
ハー ドウェア記述言語は、 R T L ( Register Transfer L evel) ゃゲ一 ト レベル等、 低レベルでのハー ドウェアの記 述もサポー ト している。 これによ り、 ハー ドウェア ' ァ一 キテクチャの設計から レイァゥ ト設計 · テス 卜に至る一連 の工程の中で， 動作レベルゃゲー ト レベルなどの記述を経 た ト ップダウン設計を行う ことが可能となり， 設計生産性 と設計信頼性を飛躍的に向上させる ことができる .  The hardware description language also supports low-level hardware description such as RTL (register transfer level) and gate level. This makes it possible to perform a top-down design that describes the operation level, gate level, etc. in a series of processes from hardware architecture design to late design and testing. Therefore, design productivity and design reliability can be dramatically improved.
一方、 大量の計算能力を必要とするアプリ ケーショ ンで は、 ますますマルチプロセッサ ' コ ンピューティ ング ' シ ステムが使用されるようになっている。 多く のダイ プのマ ルチプロセッサ · システムが存在するが、 一般に、 このよ うなシステムでは、 プロセッサ間の資源の共用を容易にす るために共通バス上にまとめて結合された複数のプロセッ ザが独立して動作している。 On the other hand, applications that require large amounts of computing power are increasingly using multiprocessor 'computing' systems. There are many types of multiprocessor systems, but in general, In such a system, a plurality of processors are independently operated collectively on a common bus to facilitate sharing of resources between the processors.
また、 O S も含め、 そのようなアプリ ケーショ ンは、 特 定の個数のプロセッサに特化したものではなく 、 最大個数 のみが指定されている。 一方、 ハー ドウェアレベルでは、 プロセッサの個数の増減があると、 ハー ドウエア記述言語 で書かれたソースコー ドの全体を見直し、 書き換える必要 がある。  Also, such applications, including OS, are not specific to a particular number of processors, but only the maximum. On the other hand, at the hardware level, if the number of processors increases or decreases, it is necessary to review and rewrite the entire source code written in the hardware description language.
更に、 要求される能力が小さい場合には、 プロセッサへ の電源の供給を限定すれば、 マルチプロセッサシステムの 消費電力を低減することが可能となる。 しかし、 一部のプ 口セッサのみ動作を安全に停止する方法が知られていなか つた。 発明の開示  In addition, if the required performance is small, limiting the power supply to the processor can reduce the power consumption of the multiprocessor system. However, there was no known method for safely stopping the operation of only a part of the processor. Disclosure of the invention
本発明の主な目的は、 実装されているプロセッサの個数 を自由に変更する ことができるマルチプロセッサ · システ ムとその設計方法及びハー ドウェア記述言語によって記述 されたマルチプロセッサ · システムを提供するこ とである 本発明の別の目的は、 実装されているプロセッサの中で 実際に動作させたいエンジンの個数を自由に変更すること ができ、 きめの細かい省電力の可能なマルチプロセッサ · システムを提供することである。  A main object of the present invention is to provide a multiprocessor system in which the number of mounted processors can be freely changed, a design method thereof, and a multiprocessor system described by a hardware description language. Another object of the present invention is to provide a multi-processor system capable of fine-grained power saving, in which the number of engines to be actually operated among the installed processors can be freely changed. That is.
本発明 （請求項 1 ) は， 共用バスと、 前記共用バスに接 続された複数のプロセッサと、 前記複数のプロセッサから 発行される前記共用バスへのバス使用要求のラウン ドロビ ンによるァ一ビ ト レ一ショ ンを行うァービ ト レ一ショ ン機 構とか らなるマルチプロセッサ · システムの設計をハー ド ウェア記述言語によって行う方法であっ て、 前記ハー ド ウ エア記述言語によるソーステキス トは、 所定の最大プロセ ッサ数までサポー トする前記ァービ ト レーショ ン機構の記 述と、 前記プロセッサのイ ンスタ ンスを、 前記最大プロセ ッサ数以下で任意に設定された数まで生成し、 前記マルチ プロセ ッサ · システムに前記複数のプロセ ッサを実装する 記述を含むこ とを特徴とするマルチプロセッサ · システム の設計方法を提供する。 The present invention (Claim 1) provides a shared bus, a plurality of processors connected to the shared bus, and a round-robin system for issuing a bus use request to the shared bus issued from the plurality of processors. An arbitration machine for tracing A method for designing a multiprocessor system comprising a hardware description language, wherein the source text in the hardware description language supports up to a predetermined maximum number of processors. A description of the translation mechanism and an instance of the processor are generated up to an arbitrarily set number equal to or less than the maximum number of processors, and the plurality of processors are implemented in the multi-processor system. Provide a method for designing a multiprocessor system characterized by including a description.
本発明 （請求項 2 ) は，上記請求項 1 において， 前記複 数のプロセッサは複数の異なるプロセッサか らなる こ とを 特徵とするマルチプロセッサ · システムの設計方法を提供 する。  The present invention (claim 2) provides a method for designing a multiprocessor system according to claim 1, wherein the plurality of processors comprises a plurality of different processors.
本発明 （請求項 3 ) は，上記請求項 1 において， 前記複 数のプロセッサには、 その動作を停止する命令が実装され ている ことを特徴とするマルチプロセッサ ' システムの設 計方法を提供する。  The present invention (claim 3) provides a method for designing a multiprocessor system according to claim 1, wherein the plurality of processors are provided with an instruction to stop the operation. .
本発明 （請求項 4 ) は，上記請求項 1 において， 前記複 数のプロセッサは、 複数のバスを共用する こ とを特徴とす るマルチプロセッサ · システムの設計方法を提供する。  The present invention (claim 4) provides a method for designing a multiprocessor system according to claim 1, wherein the plurality of processors share a plurality of buses.
本発明 （請求項 5 ) は，上記請求項 1 において， 前記複 数のプロセッサの各々 に、 アービ ト レーショ ン機構が実装 されている こ とを特徴とするマルチプロセッサ · システム の設計方法を提供する。  The present invention (claim 5) provides a method for designing a multiprocessor system according to claim 1, wherein an arbitration mechanism is mounted on each of the plurality of processors. .
本発明 （請求項 6 ) は，上記請求項 1 において， 前記ハ — ドウエア記述言語は、 V H D Lである こ とを特徴とする マルチプロセッサ · システムの設計方法を提供する。  The present invention (claim 6) provides a method for designing a multiprocessor system according to claim 1, wherein the hardware description language is VHDL.
本発明 （請求項 7 ) は， 共用バスと、 前記共用バスに接 続された複数のプロセッサと、 前記複数のプロセッサか ら 発行される前記共用バスへのバス使用要求のラウン ド ロ ビ ンによるァービ ト レーショ ンを行う ァービ ト レーショ ン機 構とからなるマルチプロセ ッサ · システムであって、 前記 複数のプロセッサの各々 に、 その動作を停止する命令が実 装されている こ とを特徴どするマルチプロセ ッサ · システ ムを提供する。 According to the present invention (claim 7), a shared bus is connected to the shared bus. A multi-processor comprising a plurality of connected processors and an arbitration mechanism for performing arbitration by round robin of a bus use request to the shared bus issued from the plurality of processors. A multiprocessor system is provided, wherein each of the plurality of processors is provided with an instruction for stopping its operation.
本発明 （請求項 8 ) は， 共用バス と、 前記共用バスに接 続された複数のプロセッサと、 前記複数のプロセッサから 発行される前記共用バスへのバス使用要求のラウ ン ド ロ ビ ンによるアービ ト レーショ ンを行う アービ ト レーショ ン機 構とからな り、 ハー ドウェア記述言語によって記述された マルチプロセッサ ' システムであって、 前記ハー ドウェア 記述言語によるソーステキス トは、 所定の最大プロセ ッサ 数までサポー トする前記アービ ト レーショ ン機構の記述と 前記プロセッサのイ ンスタ ンスを、 前記最大プロセッサ数 以下で任意に設定された数まで生成し、 前記マルチプロセ ッサ · システムに前記複数のプロセッサを実装する記述を 含むこ とを特徴とするハー ドウエア記述言語によって記述 されたマルチプロセッサ · システムを提供する。 図面の簡単な説明  The present invention (claim 8) is based on a shared bus, a plurality of processors connected to the shared bus, and a round robin of a bus use request issued from the plurality of processors to the shared bus. An arbitration mechanism that performs arbitration is a multiprocessor system described by a hardware description language, and the source text in the hardware description language is a predetermined maximum processor. A description of the arbitration mechanism that supports up to the number of processors and an instance of the processor are generated up to an arbitrarily set number equal to or less than the maximum number of processors, and the plurality of processors are added to the multi-processor system. Multiplicity described in a hardware description language that includes a description that implements Provide a processor system. BRIEF DESCRIPTION OF THE FIGURES
図 1 は、 本発明の実施形態による分散バス · ァ一ビ ト レ —ショ ン方式を採用 したシングルチッ プ · マルチプロセッ サシステムのブロ ッ クダイ アグラムである。  FIG. 1 is a block diagram of a single-chip multiprocessor system adopting a distributed bus / bitrition system according to an embodiment of the present invention.
図 2 は、 本発明の実施形態による分散バス · ァービ ト レ ーショ ン方式を採用 したシングルチッ プ · マルチプロセッ サシステムの制御信号の接続関係を示すブロ ッ ク図である 図 3 は、 本発明の実施形態による分散バス · ァ一ビ ト レ ーシヨ ン方式における、 適応型ラウ ン ド ロ ビンによる各バ ス . マス夕間のアービ ト レーショ ンの関係を示す説明図で ある。 FIG. 2 is a block diagram showing a connection relationship of control signals of a single-chip multiprocessor system employing a distributed bus arbitration system according to an embodiment of the present invention. FIG. 3 is an explanatory diagram showing the arbitration relationship between each bus and each cell by the adaptive round robin in the distributed bus bit rate method according to the embodiment of the present invention. is there.
図 4は、 本発明の実施形態による分散バス · ァ一ビ ト レ ーシヨ ン方式における、 内部命令バス I B U S、 内部デ一 夕バス D B U S及び内部システムバス S B U S を使用 して R I S Cエンジンや D S Pエンジンとプログラム用メモ リ I Mやデータ用メモ リ D Mとのリ ー ドサイ クル及びライ ト サイ クル、 及び、 内部システムバス S B U S を使用 して、 マス夕一コ ン ト ローラ M C、 R I S Cエンジンや D S Pェ ンジンから、 ノ'スコ ン ト ローラ B C、 ペ リ フエラルバス I Fへのライ トサイ クル、 及び、 内部システムバス S B U S を使用 して、 マスタ一コ ン ト ローラ M C とプログラム用メ モ リ I Mやデータ用メモ リ D Mとの リ ー ドサイ クル及びラ ィ トサイ クルを示す図である。  FIG. 4 shows a program and a RISC engine or DSP engine using the internal instruction bus IBUS, the internal data bus DBUS, and the internal system bus SBUS in the distributed bus bit rate system according to the embodiment of the present invention. Read / write cycle with memory IM and data memory DM, and using the internal system bus SBUS from the mass storage controller MC, RISC engine or DSP engine. Using the controller BC, the light cycle to the peripheral bus IF, and the internal system bus SBUS, the master controller MC and the memory IM for programs and the memory DM for data are used. FIG. 2 is a diagram showing a lead cycle and a light cycle.
図 5 は、 本発明の実施形態による分散バス * ァ一ビ ト レ —シヨ ン方式における、 内部データバス D B U S を使用 し て、 R I S Cエンジンや D S Pエンジンからデ一夕用メモ リ D Mへのライ トサイ クルを示す図であ り、 ア ド レス送出 サイ クルで READ_BUSYが生成され、 ァービ ト レーショ ンで次の リ 一 ド リ クエス 卜が禁止される場合を示している , 図 6 は、 本発明の実施形態による分散バス · ァ一ビ ト レ ーショ ン方式における、 内部データバス D B U S を使用 し て、 R I S Cエンジンや D S Pエンジンからデータ用メモ リ D Mへのライ 卜サイ クルを示す図であ り 、 バス使用権を 獲得後、 ビジ一を発行する こ とによって連続してバスを使 用する場合を示している。 図 7 は、 本発明の実施形態による分散バス · ァービ ト レ ーシ ョ ン方式における、 内部システムバス S B U S を使用 して、 マス夕一コ ン ト ローラ M C、 R I S Cエンジンや D S Pエンジンによる、 外部のメモ リ からの リ ー ドサイ クル を示す図である。 FIG. 5 is a diagram showing a light site from a RISC engine or a DSP engine to a memory DM for overnight using an internal data bus DBUS in a distributed bus * bit-ratio method according to an embodiment of the present invention. FIG. 6 is a diagram illustrating a case where READ_BUSY is generated in an address transmission cycle and the next read request is prohibited in arbitration. FIG. 4 is a diagram showing a write cycle from a RISC engine or a DSP engine to a data memory DM using an internal data bus DBUS in the distributed bus / bit-bit system according to the embodiment; It shows a case where the bus is used continuously by issuing a business after acquiring the right to use. FIG. 7 is a diagram illustrating an example of a distributed bus arbitration scheme according to an embodiment of the present invention, in which an internal system bus SBUS is used and an external controller is provided by a master controller MC, a RISC engine or a DSP engine. It is a figure showing a lead cycle from memory.
図 8 は、 本発明の実施形態による分散バス · ァ一ビ ト レ ーシヨ ン方式における、 内部システムバス S B U S を使用 して、 マスターコ ン ト ローラ M C、 R I S Cエンジンや D S Pエンジンによる、 外部のメモリ からの リ ー ドサイ クル を示す図であ り、 ア ド レスを送出する際に、 マスターコ ン ト ロ一ラ M C、 R I S Cエンジンや D S Pエンジンは、 転 送データ数 nをバスコ ン ト ローラ B Cに通知する こ とを示 している。  FIG. 8 is a diagram showing a configuration in which the internal system bus SBUS is used in the distributed bus bit rate system according to the embodiment of the present invention to read data from an external memory by the master controller MC, RISC engine, or DSP engine. This is a diagram showing a read cycle of the master controller MC, the RISC engine or the DSP engine notifies the bus controller BC of the number of transfer data n when transmitting an address. This indicates that
図 9 は、 本発明の実施形態による分散バス * ァ一ビ ト レ ーシヨ ン方式における、 内部システムバス S B U S を使用 して、 マスタ一コ ン ト ローラ M Cが行う プロ グラム用メモ リ I Mへのライ トサイ クルを示す図であ り 、 プログラム用 メモ リ I Mへのライ トサイ クルでは、 ア ド レス送出サイ ク ルで RE— BUSYが生成され、 内部システムバス S B U S と 内部命令バス I B U S のァ一ビ ト レーショ ンが禁止される こ とを示している。  FIG. 9 is a diagram illustrating a program memory IM performed by the master controller MC using the internal system bus SBUS in the distributed bus * bit rate system according to the embodiment of the present invention. FIG. 4 is a diagram showing a cycle of a program. In a write cycle to a program memory IM, an RE-BUSY is generated in an address transmission cycle, and an internal system bus SBUS and an internal instruction bus IBUS are combined. Indicates that the ban is prohibited.
図 1 0 は、 本発明の実施形態による分散バス · ァ一ビ ト レーショ ン方式における、 し priority(l :0)によって示され る優先順位を説明する図である。  FIG. 10 is a diagram for explaining the priority indicated by priority (l: 0) in the distributed bus / key bit rate system according to the embodiment of the present invention.
図 1 1 は、 本発明の実施形態による分散バス · ァ一ビ ト レーシヨ ン方式における、 内部命令バス I B U S及び内部 システムバス S B U S によるプログラム用メモ リ のァクセ ス状況によって、 マスタ一コ ン ト ローラ M Cが生成する i 信号の生成アルゴリ ズムを示す表である。 FIG. 11 shows the master controller MC according to the access status of the program memory by the internal instruction bus IBUS and the internal system bus SBUS in the distributed bus and bit rate system according to the embodiment of the present invention. Generates i 6 is a table showing a signal generation algorithm.
図 1 2 は、 本発明の実施形態による分散バス · ァー ビ ト レーシヨ ン方式における、 R I S Cエンジン R E 0 が出力 する し request(O)の意味を説明する図である。  FIG. 12 is a diagram for explaining the meaning of the request (O) output from the RISC engine RE0 in the distributed bus-and-bit rate system according to the embodiment of the present invention.
図 1 3 は、 本発明の実施形態による分散バス · ァ一 ピ ト レ一シヨ ン方式における、 内部命令バス' I B U S のァービ ト レーショ ンの規則を説明する図である。  FIG. 13 is a diagram for explaining the rules of arbitration of the internal instruction bus' IBUS in the distributed bus key pit resolution system according to the embodiment of the present invention.
図 1 4 は、 本発明の実施形態による分散バス · ァービ ト レーシヨ ン方式における、 コマン ド し cmd の意味を説明す る図である。  FIG. 14 is a diagram illustrating the meaning of the command cmd in the distributed bus arbitration scheme according to the embodiment of the present invention.
図 1 5 は、 本発明の実施形態による分散バス · ァ一ビ ト レーショ ン方式における、 d— priority(l :0)によって示され る優先順位を説明する図である。 こ こに示した通り 、 d_pr iority(l :0)が更新される こ とによって、 ラウン ドロ ビンに よるァービ ト レ一ショ ンが実現される。  FIG. 15 is a diagram for explaining the priority indicated by d-priority (l: 0) in the distributed bus / key bit rate system according to the embodiment of the present invention. As shown here, arbitration by round robin is realized by updating d_priority (l: 0).
図 1 6 は、 本発明の実施形態による分散バス · ァ一ビ ト レーショ ン方式における、 内部データバス D B U S及び内 部システムバス S B U S によるデータ用メモ リ のアクセス 状況によって、 マス夕一コ ン ト ローラ M Cが生成する d_b usy(l :0)信号の生成アルゴリ ズムを示す表である。  FIG. 16 is a diagram illustrating a main controller according to the state of access to data memory by the internal data bus DBUS and the internal system bus SBUS in the distributed bus / key bitrate method according to the embodiment of the present invention. 9 is a table showing a generation algorithm of a d_busy (l: 0) signal generated by MC.
図 1 7 は、 本発明の実施形態による分散バス · ァ一ビ ト レーシヨ ン方式における、 R I S Cエンジン R E 0 が出力 する d— request(O)の意味を説明する図である。  FIG. 17 is a diagram for explaining the meaning of d-request (O) output from the RISC engine RE0 in the distributed bus / bit rate system according to the embodiment of the present invention.
図 1 8 は、 本発明の実施形態による分散バス · ァ一ビ ト レーシヨ ン方式における、 内部命令バス I B U S のァ一ビ ト レーショ ンの規則を説明する図である。  FIG. 18 is a diagram illustrating rules for arbitration of the internal instruction bus IBUS in the distributed bus arbitration system according to the embodiment of the present invention.
図 1 9 は、 本発明の実施形態による分散バス · ァ一ビ ト レーシヨ ン方式における、 データ用メモ リ に対するコマン ド d— cmd(3:0)の意味を説明する図である。 FIG. 19 is a diagram showing a command for data memory in the distributed bus / bit rate system according to the embodiment of the present invention. FIG. 4 is a diagram for explaining the meaning of a command d—cmd (3: 0).
図 2 0 は、 本発明の実施形態による分散バス · ァー ビ ト レーショ ン方式における、 sys— priority(2:0)によって示さ れる優先順位を説明する図である。  FIG. 20 is a diagram for explaining a priority indicated by sys-priority (2: 0) in the distributed bus / biter bit rate system according to the embodiment of the present invention.
図 2 1 は、 本発明の実施形態による分散バス · ァービ ト レ一シヨ ン方式における、 バスコ ン ト ローラ B Cが出力す る sys— request— sl(0)の意味を説明する図である。  FIG. 21 is a diagram for explaining the meaning of sys-request-sl (0) output by the bus controller BC in the distributed bus arbitration system according to the embodiment of the present invention.
図 2 2 は、 本発明の実施形態による分散バス · ァービ 卜 レーシヨ ン方式における、 ノ スコ ン ト ローラ B Cが ド ライ ブする sys— busy(O)信号の意味を説明する図である。  FIG. 22 is a diagram for explaining the meaning of the sys-busy (O) signal driven by the no controller BC in the distributed bus arbitration system according to the embodiment of the present invention.
図 2 3 は、 本発明の実施形態による分散バス · ァービ ト レーシヨ ン方式における、 ノ'スコ ン ト ローラ B Cが ド ライ ブする sys_busy(l)信号の意味を説明する図である。  FIG. 23 is a diagram illustrating the meaning of the sys_busy (l) signal driven by the controller BC in the distributed bus arbitration scheme according to the embodiment of the present invention.
図 2 4 は、 本発明の実施形態による分散バス · ァービ ト レーシヨ ン方式における、 内部データバス D B U S及び内 部システムバス S B U S によるデ一夕用メモ リ のアクセス 状況によって、 マスターコ ン ト ローラ M Cが生成する sys — busy(3:2)信号の生成アルゴリ ズムを示す表である。  FIG. 24 is a diagram showing a state in which the master controller MC is accessed depending on the access state of the memory for data by the internal data bus DBUS and the internal system bus SBUS in the distributed bus arbitration system according to the embodiment of the present invention. This is a table showing the algorithm for generating sys — busy (3: 2) signal to generate.
図 2 5 は、 本発明の実施形態による分散バス · ァービ ト レーシヨ ン方式における、 内部命令バス I B U S及び内部 システムバス S B U S によるプロ グラム用メモリ のァクセ ス状況によって、 マスターコ ン ト ローラ M Cが生成する s ys一 busy(5:4)信号の生成ァルゴリ ズムを示す表である。  FIG. 25 shows the master controller MC generating the status of the access of the program memory by the internal instruction bus IBUS and the internal system bus SBUS in the distributed bus arbitration system according to the embodiment of the present invention. 9 is a table showing an algorithm for generating a s ys one busy (5: 4) signal.
図 2 6 は、 本発明の実施形態による分散バス · ァ一ビ ト レーシヨ ン方式における、 ペリ フエラルバス I Fが生成す る sys一 busy(6)信号の意味を示す図である。  FIG. 26 is a diagram illustrating the meaning of the sys-busy (6) signal generated by the peripheral bus IF in the distributed bus-key bit rate system according to the embodiment of the present invention.
図 2 7 は、 本発明の実施形態による分散バス · ァービ ト レーシヨ ン方式における、 ペリ フエラルバス I Fが ド ライ ブする sys一 busy(7)信号の意味を説明する図である。 FIG. 27 is a diagram illustrating a case where the peripheral bus IF in the distributed bus / arbitration system according to the embodiment of the present invention is driven. FIG. 14 is a diagram for explaining the meaning of a sys-busy (7) signal.
図 2 8 は、 本発明の実施形態による分散バス · ァービ ト レーシヨ ン方式における、 R I S Cエンジン R E 0 が出力 する sys_request(0)の意味を説明する図である。  FIG. 28 is a view for explaining the meaning of sys_request (0) output from the RISC engine RE0 in the distributed bus arbitration scheme according to the embodiment of the present invention.
図 2 9 は、 本発明の実施形態による分散バス · ァービ ト レーショ ン方式における、 内部システムバス S B U S のァ ービ ト レーショ ンの規則を説明する図である。  FIG. 29 is a diagram for explaining the rules of arbitration of the internal system bus SBUS in the distributed bus arbitration system according to the embodiment of the present invention.
図 3 0 は、 本発明の実施形態による分散バス · ァービ ト レーシヨ ン方式における、 マスターコ ン ト ローラ M C 、 R I S Cエンジンや D S Pエンジンが出力するコマシ ドの一 覧を示す図である。  FIG. 30 is a diagram showing a list of commands output by the master controllers MC, the RISC engine, and the DSP engine in the distributed bus arbitration system according to the embodiment of the present invention.
図 3 1 は、 本発明の実施形態によるハー ドウェア記述言 語によるマルチプロセッサ · システムの一般的な設計手順 を説明する図である。  FIG. 31 is a diagram illustrating a general design procedure of a multiprocessor system using a hardware description language according to an embodiment of the present invention.
図 3 2 は、 本発明の実施形態によるマルチプロセッサシ ステムのソーステキス 卜の中のバーケージフ ァイルである 図 3 3 は、 本発明の実施形態によるマルチプロセッサシ ステムのソーステキス 卜の中の実装部分のフ ァイルの前半 部分を説明する図である。  FIG. 32 is a package file in the source text of the multiprocessor system according to the embodiment of the present invention. FIG. 33 is a mounting part in the source text of the multiprocessor system according to the embodiment of the present invention. FIG. 4 is a diagram illustrating the first half of the file.
図 3 4 は、 本発明の実施形態によるマルチプロセッサシ ステムのソーステキス トの中の実装部分のフ ァイルの後半 部分を説明する図である。 発明を実施するための最良の形態  FIG. 34 is a diagram illustrating the latter half of the file of the mounting part in the source text of the multiprocessor system according to the embodiment of the present invention. BEST MODE FOR CARRYING OUT THE INVENTION
図 1 は、 本発明の実施形態による内部バスの高性能分散 バス · アービ ト レーショ ン方式を採用 したシングルチッ プ · マルチプロセッサシステムのブロ ッ クダイ アグラムで ある。 このマルチプロセッサシステムには、 マスターコ ン ト ロ一ラ M C と、 R I S Cエンジン R E 0， R I S Cェン ジン R E 1 と、 D S Pエンジン D E O 及び D S Pエンジン D E I の 5 つのプロセ ッサが備え られている。 こ こで、 マ スターコ ン ト ローラ M Cは、 全体の制御を行っ てお り 、 非 対称のマルチプロセッサシステムとなっている。 FIG. 1 is a block diagram of a single-chip multiprocessor system employing a high-performance distributed bus / arbitration scheme for an internal bus according to an embodiment of the present invention. This multiprocessor system includes a master It has five processors: a controller MC, a RISC engine RE0, a RISC engine RE1, and a DSP engine DEO and a DSP engine DEI. Here, the master controller MC performs overall control, and is an asymmetric multiprocessor system.
R I S Cエンジン R E 0及び R I S Cエンジン R E 1 は 一般にはそれぞれ対等の立場で設けられている汎用の R I S Cプロセ ッサであるが、 同一のプロセッサエンジンでも 良い し、 異なる プロセ ッサエンジンを用いても良い。 また 既存プロセ ッサエンジンを利用する こ と も、 新たにプロセ ッサエンジンを設計してもよい。 しかし、 それらのプロセ ッサエンジンには、 以下に詳細に説明する本発明の実施形 態による分散バス · アービ ト レーショ ンを、 それぞれに実 装する必要がある。  The RISC engine RE0 and the RISC engine RE1 are generally general-purpose RISC processors provided on an equal footing, respectively. However, the same processor engine or different processor engines may be used. An existing processor engine may be used, or a new processor engine may be designed. However, these processor engines need to be equipped with distributed bus arbitration according to the embodiment of the present invention, which will be described in detail below.
D S Pエンジン D E 0及び D S Pエンジン D E 1 は、 特 定の処理内容を持つ数値演算プロセッサであ り、 転送レー 卜の高いデ一夕の流れをリ アルタイムで処理する こ とが可 能である。 こ こでも、 D S Pエンジン D E 0及び D S Pェ ンジン D E 1 は、 同一の既存プロセッサエンジンでも良い し、 異なる既存プロセッサエンジンを用いても実装できる また、 既存プロセッサエンジンを利用する こ とも、 新たに プロセッサエンジンを設計してもよい。 しかし、 それら の プロセッサエンジンには、 やはり、 以下に詳細に説明する 本発明の実施形態による分散バス · アービ ト レーショ ンを それぞれに実装する必要がある。  The DSP engine DE0 and the DSP engine DE1 are numerical processors having specific processing contents, and are capable of processing a high-rate data stream in real time. In this case, the DSP engine DE 0 and the DSP engine DE 1 can be implemented by using the same existing processor engine or by using different existing processor engines. May be designed. However, each of these processor engines still needs to implement the distributed bus arbitration according to the embodiment of the present invention described in detail below.
R I S Cエンジン R E 0及び R I S Cエンジン R E 1 と D S Pエンジン D E 0及び D S Pエンジン D E 1 は、 内部 命令バス I B U S及び内部システムバス S B U S を介して プロ グラム用 メモ リ I Mに接続されている。 同様に、 これ らは、 内部データバス D B U S及び内部システムバス S B U S を介してデータ用メモ リ D Mに接続されている。 これ ら R I S Cエンジンと D S Pエンジンは、 内部命令バス I B U S と、 内部データバス D B U S及び内部システムバス S B U S のバス ， マス夕 ' デバイスである。 また、 プロ グ ラム用メモ リ I M及びデ一夕用メモ リ D Mは内部命令バス I B U S と、 内部デ一夕バス D B U S のバス · ス レーブ ' デバイスである。 RISC engine RE 0 and RISC engine RE 1 and DSP engine DE 0 and DSP engine DE 1 are connected via internal instruction bus IBUS and internal system bus SBUS. Connected to the program memory IM. Similarly, they are connected to the data memory DM via the internal data bus DBUS and the internal system bus SBUS. These RISC engine and DSP engine are the internal instruction bus IBUS, the internal data bus DBUS and the internal system bus SBUS. The program memory IM and the data memory DM are bus slave devices of the internal instruction bus IBUS and the internal data bus DBUS.
また、 マス夕一コ ン ト ローラ M Cは、 内部システムバス S B U S を介してプログラム用メモ リ I Mに接続され、 内 部データバス D B U S を介してデータ用メモ リ D Mに接続 されている。 マス夕一コ ン ト ローラ M Cは、 内部システム バス S B U S のバス · マスタである。  The master controller MC is connected to the program memory IM via the internal system bus SBUS, and is connected to the data memory DM via the internal data bus DBUS. The master controller MC is the bus master of the internal system bus SBUS.
これら内部命令バス I B U S、 内部データバス D B U S 及び内部システムバス S B U Sは、 それぞれ 1 2 8 ビッ ト のバス幅をもち、 それぞれに 3 2 ビッ トのア ド レスバスが 備え られている。 この 1 2 8 ビッ トのバス幅を、 2 0 0 M H z で駆動すれば、 最大 3 . 2 Gバイ トのバン ド幅でデー 夕の転送を行う こ とができる。 もちろん、 これらの数値は 例示的なもので、 更に拡張又は縮小する こ とは、 応用によ つて決定される。  Each of these internal instruction bus IBUS, internal data bus DBUS, and internal system bus SBUS has a bus width of 128 bits, and each has a 32-bit address bus. If this 128-bit bus width is driven at 200 MHz, data can be transferred with a maximum bandwidth of 3.2 Gbytes. Of course, these numbers are exemplary, and further expansion or contraction is determined by the application.
また、 1 2 8 ピッ トのバス幅をもち、 それぞれに 3 2 ビ ッ トのア ド レスバスに加えて、 これら内部命令バス I B U S、 内部データバス D B U S及び内部システムバス S B U S には、 以下の説明で詳しく 述べる次の様な制御信号線が 設けられている。 即ち、 内部命令バス I B U S には、 i_pr iority(l:0)> i— busy(l:0)、 i request(3:0)、 ι— cmd、 i ready. し berrの各信号線が設けられている。 また、 内部デ一夕バ ス D B U S には、 d一 priority(l:0)、 d一 busy(3:0)、 d— request (3:0)、 d_cmd(3:0)、 d— ready, d_berr の各信号線が設けら れている。 また、 内部システムバス S B U S には、 sys— pr ioritvC2:0). sys_busy(8:0), sys— requesti4:CH、 sys— request_s 1(1:0), sys— address(31:0)、 sys_cmd(10:0) , sys biu— berr、 s ys— ipu— berr、 sys— dm— berrの各信号線が設けられている。 図 2 は、 これらの接続関係を示すブロ ッ ク図である。 ただ し、 図ではエラ一関係の信号（X— berr)は省略している。 It has a bus width of 128 bits, and in addition to the 32-bit address bus, these internal instruction bus IBUS, internal data bus DBUS and internal system bus SBUS are described below. The following control signal lines to be described in detail are provided. That is, i_priority (l: 0)> i—busy (l: 0), i request (3: 0), ι—cmd, i ready. Each signal line of berr is provided. The internal data bus DBUS has d-priority (l: 0), d-busy (3: 0), d-request (3: 0), d_cmd (3: 0), d-ready, Each signal line of d_berr is provided. The internal system bus SBUS includes sys-prioritvC2: 0). Sys_busy (8: 0), sys- requesti4: CH, sys- request_s 1 (1: 0), sys- address (31: 0), sys_cmd (10: 0), sys biu-berr, sys-ipu-berr, sys-dm-berr signal lines are provided. Figure 2 is a block diagram showing the connection relationship. However, the error related signal (X-berr) is omitted in the figure.
また、 本実施形態による シングルチッ プ · マルチプロセ ッサシステムでは、 外部のメモ リ へのアクセス用に、 2 系 統のア ド レス データバスが設けられている。 1 つは、 外 部システムバス E M 1 であ り 、 2 2 ビッ 卜のア ド レスバス と、 1 6 ビッ トのデータバスを持っている。 そして、 最大 8 Mバイ トの R O M /フ ラ ッ シュ R O M、 最大 1 6 Mバイ 卜の R O MZフラ ッ シュ R O M、 及び最大 2 4 Mバイ トの 外部リ ソースを、 この外部システムバス E M 1 に接続する こ とができる。  Further, in the single-chip multiprocessor system according to the present embodiment, two address data buses are provided for accessing external memory. One is an external system bus EM1, which has a 22-bit address bus and a 16-bit data bus. Then, up to 8 Mbytes of ROM / flash ROM, up to 16 Mbytes of RO MZ flash ROM, and up to 24 Mbytes of external resources are connected to this external system bus EM1. Can be connected.
もう 1 つは、 外部システムバス E M 2 であ り、 2 0 ビッ 卜のア ド レスバス と、 1 6 ビッ ト又は 3 2 ビッ トのデ一夕 バスを持っている。 そして、 最大 8 Mバイ トの R O M /フ ラ ッ シュ R O M、 最大 3 2 Mパイ 卜の S R A MZ S D R A M、 及び最大 2 Mバイ トの外部リ ソース （ペリ フエ ラル） を、 この外部システムバス E M 1 に接続する こ とができる このマルチプロセッサシステムと、 外部のメモリ とのァ クセスは、 内蔵されているバスコ ン ト ローラ B Cが行う。 このバスコ ン ト ローラ B C は、 内部システムバス S B U S を介して、 R I S Cエンジン R E 0 及び R I S Cエンジン R E 1 と D S Pエンジン D E O及び D S Pエンジン D E 1 と、 更に、 マス夕一コ ン ト ローラ M C と、 スプリ ッ ト ト ラ ンザク シヨ ンを行う。 それとは別に、 ノ スコ ン ト ローラ B Cは、 マスターコ ン ト ローラ M C と、 専用の命令バス M l とデ一夕バス M Dによって接続されてお り 、 マス夕一コ ン ト ローラ M Cへの命令とデータの供給を行う。 また、 バス コ ン ト ローラ B C とマスタ一コ ン ト ローラ M C との間には 命令キャ ッ シュが介在してお り 、 通常の方法によって、 キ ャ ッ シングを行う。 The other is the external system bus EM2, which has a 20-bit address bus and a 16-bit or 32-bit data bus. A maximum of 8 Mbytes of ROM / flash ROM, a maximum of 32 Mbytes of SRA MZ SDRAM, and a maximum of 2 Mbytes of external resources (peripherals) are transferred to the external system bus EM 1 The built-in bus controller BC accesses this multiprocessor system and external memory. This bus controller BC is connected to the RISC engine RE 0 and RISC engine via the internal system bus SBUS. RE 1 and DSP engine DEO and DSP engine DE 1, as well as the controller MC and split transaction. Separately, the no-controller BC is connected to the master controller MC by a dedicated instruction bus Ml and a data bus MD, and provides instructions to the master controller MC. And data supply. Also, an instruction cache is interposed between the bus controller BC and the master controller MC, and performs caching in a usual manner.
更に、 内蔵の周辺回路と して、 タイマ回路と I Z Oポー 卜が、 ペリ フエラルバス及びペリ フエラルバス I F (イ ン 夕一フェース回路） を介して、 内部システムバス S B U S に接続されている。 この夕イマ回路は、 6本のタイマを実 装してお り 、 タイマバスを介して、 R I S Cエンジン R E 0、 R I S Cエンジン R E 1 、 D S Pエンジン D E O 、 D S Pエンジン D E I 、 マスターコ ン ト ローラ M Cへ、 タイ マ割り込みを行う。 また、 ペリ フエラルバス を介して、 プ 口セッサ割り込み制御回路へ夕イマ割り 込みを行う。 プロ セッサ割り込み制御回路は、 プロセッサ割り込み要求バス を介して、 各プロセッサエンジンのプロセッサ割り込みを 行う。 ノ、スコ ン ト ローラ B C、 ペリ フエ ラルバス I F、 プ ログラム用メモ リ I M及びデータ用メモ リ D Mは内部シス テムパス S B U Sのバス · ス レーブ · デバイ スである。  Further, as built-in peripheral circuits, a timer circuit and an IZO port are connected to an internal system bus SBUS via a peripheral bus and a peripheral bus IF (interface circuit). This evening circuit is equipped with six timers, which are connected to the RISC engine RE0, RISC engine RE1, DSP engine DEO, DSP engine DEI, and master controller MC via the timer bus. Perform an interrupt. In addition, a timer interrupt is performed to the CPU interrupt control circuit via the peripheral bus. The processor interrupt control circuit issues a processor interrupt of each processor engine via the processor interrupt request bus. In addition, the controller BC, the peripheral bus IF, the program memory IM and the data memory DM are bus slave devices of the internal system path SBUS.
以上の、 構成要素、 R I S Cエンジン R E 0、 R I S C エンジン R E 1 、 D S Pエンジン D E O 、 D S Pエンジン D E 1 、 マスターコ ン ト ローラ M C、 バスコ ン ト ロ一ラ B C , 命令キャ ッ シュ、 タイ マ回路、 プロセッサ割プロセ ッ サ割り込み制御回路、 ペリ フエ ラルバス I F、 I 〇ポー 卜 は、 1 チッ プの集積回路と して実装される。 The above components, RISC engine RE0, RISC engine RE1, DSP engine DEO, DSP engine DE1, master controller MC, bus controller BC, instruction cache, timer circuit, processor Split processor interrupt control circuit, peripheral bus IF, I IF port The chip is implemented as a one-chip integrated circuit.
その他の外部制御信号や、 付随する制御回路は、 従来の シングルチッ プ ' マルチプロセッサシステムと、 基本的に 同 じなので、 詳細な説明を省略する。  Other external control signals and associated control circuits are basically the same as those of the conventional single-chip multiprocessor system, and therefore detailed description is omitted.
以下、 本発明の特徴である内部バスの高性能分散バス · アービ ト レーショ ン方式について、 詳細に説明する。 前述 の 5 つのプロセッサエンジンには、 内部命令バス I B U S データバスそして、 内部システムバス S B U S のそれぞれ のバスを通して目的のペリ フエラルも し く はメモリ にァク セスする為のバスアービタを内蔵している。 ァービ ト レ一 ショ ンの方法は、 信号の往復を最小限にする ことによって 短時間で優先順位を決定する ことができる分散型のァ一ビ ト レ一シヨ ン方式を採用する。 即ち、 それぞれのプロセ ッ サエンジンは、 バスアービタ一を内蔵してお り、 以下に説 明するアービ ト レーショ ンに関係する制御信号は全てこの ノ、'スアービタ一に入力されている。 そして、 バスアービタ 一は、 他のプロセッサからの リ クエス 卜 と自分自身の リ ク ェス ト、 バスのビジー状態、 及び優先順位を参照する こ と によってサイ クル毎にバスの使用権を獲得できるかどうか 判定する。 この結果、 バスの使用権を獲得したプロセ ッサ が次のサイ クルでコマン ド及びァ ド レスを送出しバス を使 用する ことができる。 優先順位は、 バスの使用権に基づい てラウン ド ロ ビン方式で行われる。  Hereinafter, the high-performance distributed bus / arbitration scheme of the internal bus, which is a feature of the present invention, will be described in detail. These five processor engines have a built-in bus arbiter for accessing the target peripheral or memory through the internal instruction bus IBUS data bus and the internal system bus SBUS. The arbitration method adopts a distributed arbitration method that can determine the priority in a short time by minimizing the round trip of the signal. That is, each processor engine has a built-in bus arbiter, and all of the control signals related to arbitration described below are input to the sub-arbiter. Then, can the bus arbiter acquire the right to use the bus for each cycle by referring to requests from other processors and its own requests, the busy status of the bus, and the priority order? Judge whether or not. As a result, the processor that has acquired the right to use the bus can send commands and addresses in the next cycle and use the bus. Priorities are determined on a round robin basis based on the right to use the bus.
この実施形態では、 プログラム用メモ リ I M及びデータ 用メモ リ D Mは、 ノーウェイ トでデータ転送が可能なので 内部命令バス I B U S と内部データバス D B U S は、 スプ リ ッ ト ト ラ ンザク ショ ン · バスではな く 、 通常の接続 ト ラ ンザク シヨ ン ' ノ'スである。 従って、 R I S Cエンジン R E 0、 R I S Cエンジン R E 1 、 D S P エンジン D E O 及 び D S P エンジン D E 1 のそれぞれは、 プロ グラム用メモ リ I M及びデータ用メモ リ D Mとの ト ラ ンザク ショ ンは、 (1)ア ド レス · ァ一 ビ ト レーシヨ ン ' フェーズ、 （2)ァ ド レ ス コマン ド ， フェーズ、 及び（3)データ転送フェーズを 有する。 これらの 3 フェーズは、 パイ プライ ンで実装され レイ テンシは 2 ク ロ ッ ク、 スループッ トは 1 ク ロ ッ クサイ クルとなる。 すなわち、 1 ク ロ ッ クで 1 2 8 ビッ トのデー 夕の転送が可能である。 In this embodiment, since the program memory IM and data memory DM can transfer data in a no-way manner, the internal instruction bus IBUS and the internal data bus DBUS are not split transaction buses. In addition, it is a normal connection transaction 'no'. Therefore, RISC engine R Each of E0, RISC engine RE1, DSP engine DEO and DSP engine DE1 has the following transactions with program memory IM and data memory DM: (1) Address address It has one bit rate phase, (2) address command and phase, and (3) data transfer phase. These three phases are implemented in pipelines with a latency of two clocks and a throughput of one clock cycle. In other words, 128 bits of data can be transferred in one clock.
一方、 マス夕一コ ン ト ローラ M C、 R I S Cエンジン R E 0、 R I S Cエンジン R E 1、 D S Pエンジン D E O 及 び D S Pエンジン D E 1 のそれぞれと、 バスコ ン ト ローラ B C との ト ラ ンザク ショ ンは、 スブリ ツ ト ト ラ ンザク ショ ンで行われる。 すなわち、 （1)ア ド レス * ァ一ビ ト レ一シ ヨ ン ' フェーズ、 （2)ア ド レス /コマン ド · フェーズ、 （3) データ · アービ ト レーショ ン · フェーズ、 及び（4)デ一夕 転送フェーズを有する。 ただし、 （1)ア ド レス · ァービ ト レーシヨ ン · フェーズ及び（2)ア ド レス コマン ド · フエ ーズと、 （3)デー夕 · アービ ト レーショ ン ' フェーズ及び (4)データ転送フェーズとは、 分割されている。  On the other hand, transactions between the master controller MC, the RISC engine RE 0, the RISC engine RE 1, the DSP engine DEO, and the DSP engine DE 1 and the bus controller BC are performed in the following manner. This is done in a transaction. That is, (1) address * address resolution phase, (2) address / command phase, (3) data arbitration phase, and (4) data Overnight Has a transfer phase. However, (1) address arbitration phase and (2) address command phase, (3) data and arbitration 'phase and (4) data transfer phase Is divided.
ぐバス使用権の獲得方法 >  How to get the right to use the bus
各プロセッサ内のバスアービタ一は、 ァ一ビ ト レーショ ンサイ クルでビジーの信号をチェ ック してリ クエス 卜が出 せる状態のときバスを使用する為に リ クエス ト を発行する c また各バスアービタ一は、 他のプロセッサからの リ クエス ト と 自分自身のリ クエス ト、 及び優先順位を参照する こ と によってバスの使用権を獲得できるかどうか判定する。 Arbiter one in each processor, c and each bus arbiter to issue a re Quest to use the bus during the state in which output re QUEStionable I to check the signal busy § velvetleaf preparative Resho Nsai cycle First, it determines whether it can acquire the right to use the bus by referring to requests from other processors, its own requests, and priorities.
内部命令バス I B U S と内部データバス D B U S のァー ビ 卜 レーシ ョ ンサイ クルでは、 判定は以下のルールに従つ て行われる。 Internal instruction bus IBUS and internal data bus DBUS In the bite cycle, the judgment is made according to the following rules.
①優先権を持つプロセッサがリ クエス ト を発行していれ ば、 そのプロセッサがバスの使用権を得る。  (1) If a processor having priority issues a request, that processor gets the right to use the bus.
②優先権を持つプロセッサがリ クエス ト を発行していな ければ、 優先権の与え られる順序に従ってリ クエス ト を発 行しているプロセッサがバスの使用権を得る。  (2) If the processor having the priority has not issued the request, the processor issuing the request obtains the right to use the bus in the order in which the priority is given.
③リ クエス 卜が全く 無い場合、 あるいはリ クエス ト先が ビジ一でリ クエス トが受け付けられない場合、 優先権は移 動しない。  ③ If there is no request, or if the request destination is busy and the request cannot be accepted, the priority does not move.
④次のサイ クルの優先権は、 バスの使用権を獲得した次 のプロセッサに移動する。  ④The priority of the next cycle moves to the next processor that has acquired the right to use the bus.
このよう なアービ ト レーショ ンの方法は、 適応型ラウン ド ロ ビンと呼ばれる。 図 3 は、 適応型ラウン ド ロ ビンによ る各バス · マス夕間のアービ ト レーショ ンの関係を示す説 明図である。  Such an arbitration method is called adaptive round robin. Fig. 3 is an explanatory diagram showing the arbitration relationship between each bus and cell using adaptive round robin.
内部システムバス S B U S のァービ ト レーショ ンサイ ク ルでは、 判定は以下のルールに従って行われる。  In the arbitration cycle of the internal system bus SBUS, the judgment is made according to the following rules.
①バスコ ン ト ローラ B Cが、 常に最高の優先権を持って おり、 他のバス · マス夕に先んじて内部システムバス S B ① The bus controller B C always has the highest priority and the internal system bus S B
U S の使用権を得る こ とができる。 バスコ ン ト ローラ B C がバスの使用権を得ても、 他のバス · マス夕間の優先権は 移動しない。 The right to use US can be obtained. Even if the bus controller BC obtains the right to use the bus, the priority of other buses and buses does not move.
②バスコ ン ト ローラ B Cがリ クエス ト を発行していない 場合、 ペリ フエラルバス I Fが、 内部システムバス S B U (2) When the bus controller BC has not issued a request, the peripheral bus IF is connected to the internal system bus SBU.
S の使用権を得る ことができる。 The right to use S can be obtained.
③バスコ ン ト ロ一ラ B C とペリ フエラルバス I F のいず れも リ クエス トを発行していない場合、 マス夕一コ ン ト ロ ーラ M C と、 R I S Cエンジン R E 0， R I S Cエンジン R E 1 と、 D S Pエンジン D E O及び D S Pエンジン D E 1 との間の適応型ラウ ン ド ロ ビンによるァ一 ビ ト レ一シ ョ ンによって、 優先権の与え られる順序に従っ て リ クエス ト を発行しているプロセッサがバスの使用権を得る。 (3) If neither the bus controller BC nor the peripheral bus IF has issued a request, the master controller Priority is set by adaptive round robin between the MC, the RISC engine RE0, the RISC engine RE1, and the DSP engine DEO and the DSP engine DE1. Processors issuing requests in the given order get the right to use the bus.
④リ クエス トが全く 無い場合、 あるいはリ クエス ト先が ビジーでリ クエス トが受け付けられない場合、 優先権は移 動しない。  優先 If there is no request, or the request destination is busy and the request is not accepted, the priority does not move.
⑤バスコ ン ト ローラ B Cやペリ フエラルバス I F以外の バス · マスタ （プロセッサ） が、 バスの使用権を獲得した 場合、 次のサイ クルの優先権は、 バスの使用権を獲得した 次のプロセッサに移動する。  場合 If a bus master (processor) other than the bus controller BC or the peripheral bus IF acquires the right to use the bus, the priority of the next cycle moves to the next processor that acquired the right to use the bus. I do.
すなわち、 ノ ス コ ン ト ロー ラ B C、 ペ リ フ エ ラルバス I F と、 他のバス · マスタ （プロセッサ） のグループとでは 固定優先の分散型アービ ト レーショ ンを行い、 他のバス - マスタのグループの内部では、 適応型ラウン ドロ ビンに基 づいて、 分散型アービ ト レーショ ンを行う 。 即ち、 マルチ プロセッサバス の均等な優先順位の移動と、 固定的に優先 権の与え られたスプリ ツ ト ト ランザクショ ンによる、 効率 の良い複合アービ ト レーショ ンが実現する。  In other words, no-controller BC, peripheral bus IF, and other bus-master (processor) groups perform fixed-priority distributed arbitration, and other bus-master groups. Inside, decentralized arbitration is performed based on adaptive round robin. In other words, efficient priority arbitration of the multiprocessor bus and split transactions with fixed priorities are provided, thereby realizing efficient composite arbitration.
このような複合アービ ト レーショ ンによれば、 スプリ ッ ト · ト ラ ンザク ショ ンによ りバスの実効的な使用効率を向 上させる上で、 明瞭なア ドバンテージをもた らす。 本件発 明者が調査したと ころ、 一般的なプログラムの実行におい て、 バスコ ン ト ロ一'ラ B Cに常に最高の優先権を与えたこ とによる処理が遅れる具体例は発見できなかった。 そして . 統計的に、 バスの使用効率の向上と全体の処理速度の向上 が期待できる こ とが分かった。 これは、 次の様な事情による。 すなわち、 バスコ ン ト ロSuch combined arbitration offers a distinct advantage in improving the effective use of buses through split transactions. According to the investigation by the present inventor, no specific example of delay in processing due to always giving the highest priority to the bus controller BC in the execution of a general program was found. Statistically, it was found that improvement in bus use efficiency and overall processing speed could be expected. This is due to the following circumstances. In other words, the bus controller
—ラ B Cがリ ク エス ト を発行している場合、 バスコ ン ト ロ ーラ B Cがバスにデータ を出力する と、 それを要求したプ 口セッサは、 直ちにそのデ一夕の処理を行う こ とができ、 確実に 1 サイ クル分処理が速まる。 一方、 バスコ ン ト ロー ラ B C にバスの使用権を譲ったプロセッサは、 1 サイ クル 分処理が遅れる場合と、 実質的な処理の遅れはない場合が ある。 If the bus controller BC has issued a request and the bus controller BC has output data to the bus, the requesting processor immediately processes the data. The processing speed is increased by one cycle. On the other hand, the processor that has given the bus use right to the bus controller BC may delay the processing by one cycle, or may have no substantial processing delay.
それに対してバスコ ン ト ローラ B C力 リ クエス ト を発行 している場合で、 も し他のプロセッサにバスの使用権を与 えた場合には、 プロセ ッサはバスの使用後、 次のデータが く るまで、 そこで処理が止まってしまう という こ とがあ り 得る。 一方、 ノ スコ ン ト ローラ B C も確実に 1 サイ クル分 処理が遅れ、 そのデータを待っているプロセ ッサもやはり 1 サイ クル分処理が遅れる。  On the other hand, if a bus controller BC request has been issued, and if the right to use the bus has been granted to another processor, the processor uses the bus to transmit the next data. Until that happens, the processing may stop there. On the other hand, the processing of the no-controller BC is certainly delayed by one cycle, and the processing of the processor waiting for the data is also delayed by one cycle.
ぐバスサイ クルとバスの動作モー ド >  Bus cycle and bus operation mode>
内部命令バス I B U S及び内部データバス D B U S の基 本バスサイ クルは、 1 ク ロ ッ ク · サイ クルのスループッ ト で連続実行できるよう にパイ プライ ン化されている。 パス サイ クルは、 上記の通り 3 ステージのパイ プライ ンで処理 される。  The basic bus cycles of the internal instruction bus IBUS and the internal data bus DBUS are pipelined so that they can be executed continuously in one clock cycle of throughput. The pass cycle is processed in a three-stage pipeline as described above.
バスの動作モー ド と して、 シングル ' ト ラ ンスフ ァ一と 連続 ト ラ ンスフ ァ の 2つのモー ドがある。 1 つは、 シング ル · ト ラ ンスフ ァ一と呼ぶ基本的なサイ クルで、 1 回のバ ス ' ト ラ ンザク ショ ンで 1 つのデータ を転送する。 これに 対して連続 卜 ラ ンスフ ァーでは、 ロー ド ' マルチ、 ス ト ァ · マルチ、 命令の連続フェッチのいずれかで連続転送を 行う。 内部命令バス I B U S (連続フェ ッチ） では、 バス使用 権獲得後、 コマ ン ド送出と同時に ビジーを発行し次のァー ビ ト レ一ジョ ンを禁止する こ とによって連続してバス を使 用する こ とができる。 ア ド レスおよびコマン ド送出はシン ダル ト ランスフ ァーと同 じであるが、 連続フェ ッチは 2 回 (ダブル · フェ ッチサイ クル） なので、 最初のコマン ド送 出時にビジ一を発行し、 2回目 はビジ一を発行しない。 There are two modes of bus operation: single transfer mode and continuous transfer mode. One is a basic cycle called a single transfer, in which one data transfer is performed in a single bus transaction. On the other hand, in continuous transfer, continuous transfer is performed by one of load 'multi, store multi, and continuous instruction fetch. In the internal instruction bus IBUS (continuous fetch), after acquiring the right to use the bus, the bus is issued continuously at the same time as the command is issued, and the next arbitration is inhibited to use the bus continuously. Can be used. The address and command transmission is the same as that of the sindral transfer, but since the continuous fetch is performed twice (double fetch cycle), a business is issued when the first command is transmitted. No second visit will be issued.
この場合、 フェ ッチサイ クルは、 毎ク ロ ッ クで受け付け られるため、 各 R I S Cエンジンや D S Pエンジンは平均 で 4サイ クルに 1 回の割合で命令フェ ッチを行う ことが出 来る。  In this case, a fetch cycle is accepted every clock, so that each RISC engine and DSP engine can execute an instruction fetch once every four cycles on average.
ダブル · フェ ッチサイ クルは、 分岐のターゲッ トァ ド レ スの下位 4 ビッ 卜が 8h以上、 即ち 1回のフェ ツチサイ ク ルで 4命令以下の命令コー ド （ 2バイ ト） しかフェッチで きないような場合に用い られる。 この時 R I S Cエンジン や D S Pエンジンは最初のフェ ッチのコマン ド送出サイ ク ルでビジ一を発行し （後述の制御信号 し busy(l) = l と し て） 、 次のサイ クルも続けて内部命令バス I B U Sを使用 する。 その結果、 R I S Cエンジンや D S Pエンジンはダ ブル · フェッチサイ クルによ り 内部命令バス I B U S を 2 サイ クル連続で使用する こ とができる。  In a double fetch cycle, the lower 4 bits of the branch target address are 8h or more, that is, only one instruction code (2 bytes) of 4 instructions or less can be fetched in one fetch cycle. It is used when it is necessary. At this time, the RISC engine or DSP engine issues a business in the command transmission cycle of the first fetch (assuming that the control signal described later is busy (l) = l), and continues with the next cycle. Uses the internal instruction bus IBUS. As a result, the RISC engine and the DSP engine can use the internal instruction bus IBUS for two consecutive cycles by using the double fetch cycle.
内部データバス D B U S (ロー ド ' マルチ ス トア . マ ルチ） では、 バス使用権獲得後、 コマン ド送出と同時にビ ジーを発行し次のァービ ト レージョ ンを禁止する ことによ つて連続してバスを使用する。 ア ド レスおよびコマン ド送 出はシングル ト ラ ンス フ ァーと同じで、 連続する最後のサ ィ クルのコマン ド送出時以外でビジーが発行される。  In the internal data bus DBUS (Load 'Multi Store Multi), after acquiring the right to use the bus, a bus is issued at the same time as the command is issued and the next arbitration is prohibited, so that the bus is continuously operated. Use The address and command transmission are the same as in single transfer, and a busy is issued except when the command is transmitted in the last consecutive cycle.
内部システムバス S B U S (ロー ド ' マルチ、 ス トア ' マルチ） では、 内部データバス D B U Sや内部命令バス I B U S と同様に、 ビジーを発行する こ とによっ て、 プロ グ ラム用メモ リ I Mやデータ用メモ リ D Mへの読み書きの為 に、 連続してバスを使用する こ とができる。 Internal system bus SBUS (Load 'Multi, Store' In the case of multi), by issuing a busy signal as in the case of the internal data bus DBUS and the internal instruction bus IBUS, it is possible to read and write to the program memory IM and data memory DM continuously. You can use the bus.
図 4 A、 図 4 B及び図 4 Cは、 内部命令バス I B U S、 内部デ一夕バス D B U S及び内部システムバス S B U S を 使用 して、 R I S Cエンジンや D S Pエンジンとプロ ダラ ム用メモ リ I Mやデータ用メモ リ D Mとの リ ー ドサイ クル 及びライ トサイ クル、 及び、 内部システムバス S B U S を 使用 して、 マス夕一コ ン ト ローラ M C、 R I S Cエンジン や D S Pエンジンか ら、 ノ スコ ン ト ローラ B C、 ペリ フエ ラルパス I Fへのライ トサイ クル、 及び、 内部システムバ ス S B U S を使用 して、 マスターコ ン ト ローラ M Cとプロ グラム用メモリ I Mやデータ用メモ リ D Mとの リ ー ドサイ クル及びライ トサイ クルを示す図である。 特に、 図 4 Bは パス使用権を獲得後、 ビジ一を発行する こ とによって連続 してバスを使用する場合の リ ー ドサイ クルを示している。 また、 図 4 Cは、 内部命令バス I B U S、 内部データバス D B U S、 内部システムバス S B U S を使用 して、 プログ ラム用メモ リ I Mやデータ用メモ リ D Mからの連続リ ー ド サイ クルを示す図であるが、 こ こでは、 異なるプロセッサ が、 交代でバスを使用する場合の リ ー ドサイ クルを示して いる。  Figures 4A, 4B, and 4C use the internal instruction bus IBUS, the internal data bus DBUS, and the internal system bus SBUS to connect the RISC engine or DSP engine to the program memory IM or data. Using the read / write cycle with the memory DM and the internal system bus SBUS, the master controller MC, the RISC engine and the DSP engine, the NO controller BC, the peripheral Using the light cycle to the ferrule path IF and the internal system bus SBUS, the read cycle and the write cycle between the master controller MC and the program memory IM and the data memory DM are performed. FIG. In particular, Fig. 4B shows a read cycle in which the bus is used continuously by issuing a visit after acquiring the right to use the pass. Fig. 4C shows a continuous read cycle from the program memory IM and the data memory DM using the internal instruction bus IBUS, internal data bus DBUS, and internal system bus SBUS. However, this shows a read cycle where different processors take turns using the bus.
図 5 は、 内部データバス D B U S を使用 して、 R I S C エンジンや D S Pエンジンからデータ用メモ リ D Mへのラ イ トサイ クルを示す図であるが、 こ こでは、 ア ド レス送出 サイ クルで READ— BUSYが生成され、 ァービ ト レーショ ンで次の リー ド リ クエス トが禁止される。 また、 図 6 も、 内部データバス D B U S を使用 して、 R I S Cエンジンや D S Pエンジンからデ一夕用 メモ リ D Mへのライ トサイ ク ルを示す図であるが、 こ こでは、 バス使用権を獲得後、 ビ ジーを発行する こ とによって連続してバスを使用する場合 を示している。 尚、 連続ライ トの最後では、 リ ー ド ビジー を発行して、 次の リ ー ド リ クエス トが禁止する必要がある バスコ ン ト ローラ B Cへの連続書き込みでは、 1サイ ク ルの リ クエス 卜でコマン ド送出時に転送回数を知らせる。 また、 バスコ ン ト ローラ B Cからの連続データ転送時は、 バスコ ン ト ローラ B Cは常にバス使用の優先権を持ってい るため、 単に連続してリ クエス ト を発行する こ とによって 連続してバスを使用する こ とができる。 Fig. 5 is a diagram showing a write cycle from the RISC engine or DSP engine to the data memory DM using the internal data bus DBUS. In this example, the read cycle is performed in the address transmission cycle. BUSY is generated and the next read request is prohibited in arbitration. Figure 6 also shows This figure shows a write cycle from the RISC engine or DSP engine to the memory DM for overnight using the internal data bus DBUS.In this example, a bus is issued after the right to use the bus is acquired. In this case, the bus is used continuously. At the end of a continuous write, a read busy must be issued to prohibit the next read request. In a continuous write to the bus controller BC, one cycle request is issued. The number of transfers is notified when a command is sent using a command. In addition, during continuous data transfer from the bus controller BC, the bus controller BC always has the priority of using the bus. Can be used.
図 7 は、 内部システムバス S B U S を使用 して、 マス夕 一コ ン ト ローラ M C、 R I S Cエンジンや D S Pエンジン による、 外部のメモリか らの リ ー ドサイ クルを示す図であ る。 まず、 マスタ一コ ン ト ローラ M C、 R I S Cエンジン や D S Pエンジンは、 ァ一ビ ト レ一シヨ ンの後、 バスコ ン ドローラ B Cに対して、 コマン ド と共にア ド レスを送出す る。 バスコ ン ト ローラ B Cが外部のメモ リ からデータを受 ける と、 アービ ト レーショ ン （リ クエス ト） によって内部 システムバス S B U Sの使用権を獲得後 Ready信号を発 行し、 該当する R I S Cエンジンや D S Pエンジンは、 そ のデータを取り込む。  FIG. 7 is a diagram showing a read cycle from an external memory by the mass controller MC, RISC engine, or DSP engine using the internal system bus SBUS. First, the master controller MC, RISC engine or DSP engine sends an address together with a command to the bus controller BC after the arbitration. When the bus controller BC receives data from external memory, it obtains the right to use the internal system bus SBUS by arbitration (request), issues a Ready signal, and issues the corresponding RISC engine or DSP. The engine captures that data.
図 8 は、 内部システムバス S B U S を使用 して、 マス夕 一コ ン ト ローラ M C、 R I S Cエンジンや D S Pエンジン による、 外部のメモリからの リー ドサイ クルを示す図であ るが、 ア ド レスを送出する際に、 マスタ一コ ン ト ローラ M C > R I S Cエンジンや D S Pエンジンは、 転送データ数 n をバスコ ン ト ローラ B Cに通知する。 ノ スコ ン ト ローラ B Cが外部バスか らのレディ をまって連続転送する場合、 リ クエス トを発行し続けておき、 外部バスからのレディ に 応じて内部バスにデ一夕 を転送する こ とができる。 Figure 8 is a diagram showing a read cycle from an external memory by a mass controller MC, RISC engine or DSP engine using the internal system bus SBUS. When the master controller MC> RISC engine or DSP engine Notify n to the bus controller BC. In the case where the no controller BC transfers the ready from the external bus and transfers the data continuously, it keeps issuing the request and transfers the data to the internal bus in response to the ready from the external bus. Can be.
図 9 は、 内部システムバス S B U S を使用 して、 マス夕 一コ ン ト ローラ M Cが行う プログラム用メモ リ I Mへのラ イ トサイ クルを示す図である。 こ こでは、 プロ グラム用メ モ リ I Mへのライ トサイ クルでは、 ア ド レス送出サイ クル で RE— BUSYが生成され、 内部システムバス S B U S と内 部命令バス I B U S のァービ ト レーショ ンが禁止される。  FIG. 9 is a diagram showing a write cycle to the program memory IM performed by the mass controller MC using the internal system bus SBUS. Here, in a write cycle to the program memory IM, RE_BUSY is generated in the address transmission cycle, and arbitration of the internal system bus SBUS and the internal instruction bus IBUS is prohibited. You.
ぐ内部命令パス I B U Sへのアクセス〉  Internal instruction path IBUS access>
以下、 内部命令バス I B U Sへのアクセス制御の詳細を 説明する。 R I S Cエンジンや D S Pエンジンが共用する プロ グラム用メモ リ をアクセスする時に、 内部命令バス I B U Sの使用権を得る場合には、 ある時点での内部命令バ ス I B U S使用の優先順位を示すための 2 ビッ 卜の信号 i — priority(l:0)を用いる。 図 1 0 は、 し priority(l :0)によっ て 示される優先順位を説明する図である。 こ こに示した通 り i_priority(l:0)が更新される こ とによって、 ラウン ドロ ビ ンによるアービ ト レーショ ンが実現される。  The details of the access control to the internal instruction bus IBUS will be described below. When the right to use the internal instruction bus IBUS is obtained when accessing the program memory shared by the RISC engine and the DSP engine, two bits are used to indicate the priority of using the internal instruction bus IBUS at a certain point in time. Signal i — priority (l: 0) is used. FIG. 10 is a diagram for explaining the priority indicated by priority (l: 0). By updating i_priority (l: 0) as shown here, arbitration by round robin is realized.
各 R I S Cエンジンや D S Pエンジンは、 し busy(l:0)信 号をみて"使用可能 "の状態の時に、 内部命令バス I B U S の使用 リ クエス ト を発行し、 優先順位に従って内部命令バ ス I B U Sの使用権を獲得する。 し busy(0)信号は、 マスタ 一コ ン ト ローラ M Cによって出力される。 図 1 1 は、 内部 命令バス I B U S及び内部システムバス S B U S によるプ ロ グラム用メモリ のアクセス状況によって、 マスターコ ン ト ローラ M Cが生成する i busy(0)信号の生成アルゴリ ズ ムを示す表である。 こ こで、 （1st)又は（2nd)は、 リ クエス トが重なった場合の順番を示す。 例えば、 リ ー ド リ クエス 卜が重なった場合に、 最初に処理される リ ー ド リ クエス ト が Read(lst)であ り 、 次に処理される リ ー ド リ クエス トが Read(2nd)である。 Write Lastは、 連続書き込みの最後の ライ トサイ クルを意味する。 また、 し busy(l)信号は、 バス 権を獲得した R I S Cエンジンや D S P エンジンがコマン ドを送出する時、 内部命令バス I B U S を続けて使用する 場合に 1 、 内部命令バス I B U S を 1 サイ クルだけ使用す る場合には 0 とする。 Each RISC engine or DSP engine issues a request to use the internal instruction bus IBUS when it is in the “available” state upon seeing the busy (l: 0) signal, and according to the priority, the internal instruction bus IBUS is used. Acquire the right to use. The busy (0) signal is output by the master controller MC. Figure 11 shows the generation algorithm of the i busy (0) signal generated by the master controller MC according to the access status of the program memory by the internal instruction bus IBUS and the internal system bus SBUS. FIG. Here, (1st) or (2nd) indicates the order in which requests overlap. For example, when read requests overlap, the first processed read request is Read (lst), and the next processed read request is Read (2nd) It is. Write Last means the last write cycle of continuous writing. The busy (l) signal is 1 when the RISC engine or DSP engine that has acquired the bus right sends a command and the internal instruction bus IBUS is used continuously, and only 1 cycle of the internal instruction bus IBUS. If used, set to 0.
また、 プログラム用メモ リ は、 リ ー ド リ クエス トに対し てデータ レディ 信号 し ready を出力する。 このデ一タ レデ ィ 信号 し readyは、 ア ド レス送出 （コマン ド） に対するデ 一夕が準備完了である こ とを示す。 プロセッサは、 リ ー ド に対するデータ をプログラム用メモ リ か らのデータ レディ 信号である し ready を見て受け取る。 こ こでは、 データ レ ディ はア ド レス送出の次のサイ クルである。 プログラム用 メモ リ に対して内部システムバス S B U S と内部命令バス I B U Sから同時に リー ド リ クエス トが送出された場合、 プログラム用メモ リ では内部システムバス S B U Sか らの リー ドを行った後に内部命令バス I B U Sか らの リ ー ドを 行うため、 内部命令バス I B U S へのデータサイ クル （し ready) は 1 サイ クル遅れる。  The program memory outputs a data ready signal to the read request and outputs ready. This data ready signal ready indicates that data transmission for the address transmission (command) is ready. The processor receives the data for the read by seeing the data ready signal from the program memory and ready. Here, the data ready is the next cycle after sending the address. When a read request is sent to the program memory from the internal system bus SBUS and the internal instruction bus IBUS simultaneously, the program memory reads the internal system bus SBUS and then reads the internal instruction bus. The data cycle (and ready) to the internal instruction bus IBUS is delayed by one cycle to read from IBUS.
R I S Cエンジンや D S Pエンジンか らのバス使用 リ ク エス トは、 し request(3:0)の内の各 1 ビッ トの信号を各 R I S Cエンジンや D S Pエンジンが出力する。 すなわち R I S Cエンジン R E 0 は し request(0)、 R I S Cエンジン R E 1 は し request(l)、 D S Pエンジン D E O は i request(2), D S Pエンジン D E I は し request(3)を ドライブする。 図 1 2 は、 R I S Cエンジン R E 0 が出力する し request(O) の意味を説明する図である。 フェッチサイ クルは、 毎ク ロ ッ クで受け付けられるため、 各 R I S Cエンジンや D S P ェンジ.ンは平均で 4サイ クルに 1 回の割合で命令フェ ッチ を行う ことが出来る。 For requests to use the bus from the RISC engine or DSP engine, each RISC engine or DSP engine outputs a 1-bit signal in request (3: 0). That is, RISC engine RE 0 is request (0), RISC engine RE 1 is request (l), DSP engine DEO is i request (2), DSP engine DEI then drives request (3). FIG. 12 is a diagram for explaining the meaning of request (O) output from the RISC engine RE 0. Since a fetch cycle is accepted every clock, each RISC engine or DSP engine can execute an instruction fetch once every four cycles on average.
ダブル · フェッチサイ クルは、 分岐の夕一ゲッ トァ ド レ スの下位 4 ビッ トカ 8h以上、 即ち 1 回のフェツチサイ ク ルで、 一命令を 2バイ トと して、 4命令以下の命令コー ド しかフェッチできないような場合に用いられる。 この時 R I S Cエンジンや D S Pエンジンは最初のフェッチのコマ ン ド送出サイ クルで し busy(l) = l と して、 次のサイ クルも 続けて内部命令バス I B U S を使用する。 その結果、 R I S Cエンジンや D S Pエンジンはダブル · フェツチサイ ク ルにより内部命令バス I B U S を 2サイ クル連続で使用す ることができる。  In the double fetch cycle, the lower 4 bits of the get address at the end of the branch are 8h or more, that is, only one instruction code is 4 bytes or less in one fetch cycle. Used when fetching is not possible. At this time, the RISC engine and DSP engine are the first fetch command transmission cycle, and busy (l) = l, and the next cycle continues using the internal instruction bus IBUS. As a result, the RISC engine and the DSP engine can use the internal instruction bus IBUS for two consecutive cycles by a double fetish cycle.
バスの使用権は、 し busy(l:0) = "00" のときにァービ ト レ ーシヨ ンで決定される。 図 1 3 は、 内部命令バス I B U S のァ一ビ ト レ一ショ ンの規則を説明する図である。 この図 に示す様に、 次のサイクルの し priority(l:0)は、 バス使用 権を獲得した R I S Cエンジンや D S Pエンジンの次の R I S Cエンジンや D S Pエンジン （順序は、 RE0→RE1→ DE0→DE1→RE0) を指す。  The right to use the bus is determined by the erbitration when busy (l: 0) = "00". FIG. 13 is a diagram for explaining the rules of arbitration of the internal instruction bus IBUS. As shown in this figure, the priority (l: 0) of the next cycle is the RISC engine or DSP engine next to the RISC engine or DSP engine that has acquired the bus use right (the order is RE0 → RE1 → DE0 → DE1). → RE0).
R I S Cエンジンや D S Pエンジンは、 ァービ ト レーシ ヨ ン · サイクルでバス使用権獲得後、 次のサイクル （ア ド レス送出サイ クル） でア ド レスとともにプログラム用メモ リ に対するコマン ド し cmd を出力する。 図 1 4は、 コマン ド i cmdの意味を説明する図である。 プログラム用メモリ への書き込みは内部システムバス S B U S を介して行われ る。 After acquiring the right to use the bus in the arbitration cycle, the RISC engine or DSP engine issues a command to the program memory together with the address in the next cycle (address transmission cycle) and outputs cmd. FIG. 14 is a diagram for explaining the meaning of the command icmd. Program memory Writing to is performed via the internal system bus SBUS.
尚、 プロ グラム用メモ リ は、 プロセ ッサから送られてき たァ ド レスが、 プログラム用メモ リ の実装されているァ ド レス空間外のときデータサイ クルで、 バスエラ一し berr=l が返される。 このとき、 プログラム用メモ リ の出力 し data (12フ：0)の内容は無効である。  Note that the program memory is a data cycle when the address sent from the processor is outside the address space where the program memory is mounted. returned. At this time, the contents of the program memory output data (12f: 0) are invalid.
ぐ内部デ一夕バス D B U S へのアクセス〉 Access to the bus DBUS
以下、 内部データバス D B U Sへのアクセスの詳細を説 明する。 R I S Cエンジンや D S Pエンジンが共用するデ 一夕用メモ リ D Mへのアクセスする時に、 内部データバス D B U S の使用権を得る必要がある。 この場合、 ある時点 での内部デ一夕バス D B U S使用の優先順位を示すための 2 ピッ トの信号 d— priority(l:0)を用いる。 図 1 5 は、 d— pri ority(l:0)によっ て示される優先順位を説明する図である こ こに示した通 り 、 d_priority(l:0)が更新される こ とによ つて、 ラウン ド ロ ビンによるアービ ト レーショ ンが実現さ れる。  The details of the access to the internal data bus DBUS are described below. It is necessary to obtain the right to use the internal data bus DBUS when accessing the data memory DM shared by the RISC engine and the DSP engine. In this case, a two-bit signal d—priority (l: 0) is used to indicate the priority of using the internal bus DBUS at a certain point in time. FIG. 15 is a diagram illustrating the priority indicated by d—priority (l: 0). As shown here, d_priority (l: 0) is updated. Arbitration by round robin is realized.
各 R I S Cエンジンや D S Pエンジンは、 d_busy(3:0)信 号をみて"使用可能"の状態の時に、 内部デ一夕バス D B U S の使用 リ クエス ト を発行し、 優先順位に従って内部命令 バス I B U S の使用権を獲得する。 d_busy(3:2)は、 ァ ド レ ス送出サイ クルでのバスの使用状況に応じて、 バス使用権 を獲得したプロセッサが生成される。 どのプロセッサもバ スの使用権を獲得していない時にはマス夕一コ ン ト ローラ M Cが "00"を ドライ ブする。 図 1 6 は、 内部データバス D B U S及び内部システムバス S B U S によるデータ用メモ リ のアクセス状況によって、 マスターコ ン ト ローラ M Cカ 生成する d_busy(l:0)信号の生成アルゴリ ズムを示す表で ある。 こ こで、 d— busy(2)は、 将来の為の リザーブビッ ト であ り 、 内部リ ソースが追加された場合に使用される。 d_ busy(3)は、 バス権を獲得した R I S Cエンジンや D S P エンジンがコマン ドを送出する時、 内部データバス D B U S を続けて使用する場合に 1 、 内部データバス D B U S を 1サイ クルだけ使用する場合には 0 を ド ライ ブする。 Each RISC engine or DSP engine issues a request to use the internal bus DBUS when it is in the “available” state by seeing the d_busy (3: 0) signal, and according to the priority, the internal instruction bus IBUS. Acquire the right to use. In d_busy (3: 2), a processor that has acquired the bus use right is generated according to the bus use status in the address transmission cycle. When none of the processors has acquired the right to use the bus, the master controller MC drives "00". Figure 16 shows the master controller MC card depending on the access status of data memory via the internal data bus DBUS and internal system bus SBUS. 9 is a table showing a generation algorithm of a generated d_busy (l: 0) signal. Here, d—busy (2) is a reserved bit for the future, and is used when an internal resource is added. d_busy (3) is 1 if the RISC engine or DSP engine that has acquired the bus right uses the internal data bus DBUS continuously when sending a command, or 1 if the internal data bus DBUS is used for only one cycle. Drive 0 for
R I S Cエンジンや D S Pエンジンか らのバス使用 リ ク エス トは、 d— request(3:0)の内の各 1 ビッ トの信号を各 R I S Cエンジンや D S Pエンジンが出力する。 すなわち R I S Cエンジン R E 0 は d_request(0)、 R I S Cエンジン R E 1 は d_request(l)、 D S Pエンジン D E O は d— request (2)、 D S Pエンジン D E I は d— request(3)を ドライ ブする 図 1 7 は、 R I S Cエンジン R E 0が出力する d— request (0)の意味を説明する図である。  For requests to use the bus from the RISC engine or the DSP engine, each RISC engine or the DSP engine outputs a 1-bit signal in d—request (3: 0). That is, RISC engine RE 0 drives d_request (0), RISC engine RE 1 drives d_request (l), DSP engine DEO drives d-request (2), and DSP engine DEI drives d-request (3). FIG. 7 is a diagram for explaining the meaning of d—request (0) output by the RISC engine RE0.
図 1 8 は、 内部命令パス I B U S のァービ ト レ一ショ ン の規則を説明する図である。 この図に示す様に、 次のサイ クルの d_priority(l:0)は、 バス使用権を獲得した R I S C エンジンや D S Pエンジンの次の R I S Cエンジンや D S Pエンジン （順序は、 RE0→RE1→DE0→DE1→RE0) を指 す。  FIG. 18 is a diagram for explaining the rules of arbitration of the internal instruction path IBUS. As shown in this figure, d_priority (l: 0) of the next cycle is the RISC engine or DSP engine next to the RISC engine or DSP engine that has acquired the bus use right (the order is RE0 → RE1 → DE0 → DE1). → RE0).
各 R I S Cエンジンや D S Pエンジンは、 リー ド リ クェ ス 卜であれば d— busy(3:0) = "0000" のとき、 ライ ト リ クェ ス 卜であれば d_busy = "0000"¾るレ は d_busy = "0010"のと きに リ クエス ト を出力できる。 また、 各 R I S Cエンジン や D S Pエンジンは、 ァービ ト レ一ショ ン · サイ クルでバ ス使用権獲得後、 次のサイ クル （ア ド レス送出サイ クル） でア ド レス と と もにデータ用メモ リ に対するコマン ド d c md(3:0)を出力する。 図 1 9 は、 データ用メモ リ に対する コマン ド d— cmd(3:0)の意味を説明する図である。 Each RISC engine or DSP engine has d_busy = "0000" when d— busy (3: 0) = "0000" for a read request and d_busy = "0000" for a write request. Request can be output when d_busy = "0010". In addition, each RISC engine and DSP engine obtains the right to use the bus in the arbitration cycle, and then, in the next cycle (address sending cycle), stores the data memo together with the address. Command dc Outputs md (3 : 0). FIG. 19 is a view for explaining the meaning of the command d—cmd (3: 0) for the data memory.
尚、 データ用メモ リ は、 プロセッサから送られてきたァ ド レスが、 データ用メモリ の実装されているア ド レス空間 外のときデータサイ クルで、 バスエラー i一 berr=lが返され る。 このとき、 データ用メモ リ の出力 d_data(127:0)の内 容は無効である。 For data memory, if the address sent from the processor is outside the address space where the data memory is mounted, a bus error i-one berr = l is returned in the data cycle. . At this time, data memory output d_data (12 7: 0) the contents of invalid.
また、 データ用メモ リ は、 リ ー ド リ クエス トに対して、 デ一タ レディ 信号 d_readyを出力する。 このデータ レディ 信号 d_readyは、 ア ド レス送出 （コマン ド） に対するデー 夕が準備完了である こ とを示す。 プロセッサは、 リ ー ドに 対するデ一夕をプログラム用メモ リ からのデ一夕 レディ 信 号である d_readyを見て受け取る。 こ こでは、 データ レデ ィ はア ド レス送出の次のサイ クルである。 データ用メモ リ に対して内部システムバス S B U S と内部デ一夕バス D B U Sから同時に リ ー ド リ クエス トが送出された場合、 プロ グラム用メモリ では内部システムバス S B U Sからの リ ー ドを行った後に内部命令バス I B U Sからの リー ドを行う ため、 内部データバス D B U Sへのデータサイ クル （ d_re ady) は 1サイ クル遅れる。  In addition, the data memory outputs a data ready signal d_ready for a read request. The data ready signal d_ready indicates that data for the address transmission (command) is ready. The processor receives the data for the read by looking at the data ready signal d_ready from the program memory. Here, the data ready is the next cycle after sending the address. When a read request is sent to the data memory from the internal system bus SBUS and the internal data bus DBUS at the same time, the program memory reads after reading from the internal system bus SBUS. Since data is read from the internal instruction bus IBUS, the data cycle (d_re ady) to the internal data bus DBUS is delayed by one cycle.
く内部システムバス S B U Sへのアクセス〉  Access to internal system bus SBUS>
以下、 内部システムバス S B U Sへのアクセスの詳細を 説明する。 マスタ一コ ン ト ローラ M C と、 R I S Cェンジ ン R E 0 , R I S Cエンジン R E 1 と、 D S Pエンジン D E 0及び D S Pエンジン D E 1 の 5つのプロセッサは、 内 部システムバス S B U S を介して、 ノ スコ ン ト ローラ B C とペリ フエラルバス I F及びプロ グラム用メモリ I Mとデ —夕用メモ リ D Mに対して リ ー ドサイ クル及びライ トサイ クルを実行する こ とができる。 ただし、 バスコ ン ト ローラThe details of access to the internal system bus SBUS are described below. The master controller MC, the RISC engine RE0, the RISC engine RE1, the DSP engine DE0, and the DSP engine DE1 are connected to the five processors via the internal system bus SBUS. Read and write cycles for BC and Peripheral bus IF and program memory IM and data—evening memory DM Can run. However, the bus controller
B Cは、 直接プロ グラム用メモ リ I Mとデータ用メモ リ D Mに対してリ ー ドサイ クル及びライ トサイ クルを実行する こ とができる。 The BC can directly execute a read cycle and a write cycle on the program memory I M and the data memory D M.
従って、 内部システムバス S B U Sの効率の良いァービ ト レーシヨ ンは、 全体のスループッ ト を向上させる上で、 極めて重要となる。 こ こでは、 5 つのプロセッサか らマス ターコ ン ト ローラ M C (外部メモ リ空間） への リ ー ドサイ クルは、 スプリ ッ ト ' ト ラ ンザク ショ ンによって、 実効的 なバスの使用効率を向上させている。  Therefore, an efficient arbitration of the internal system bus SBUS is extremely important in improving the overall throughput. Here, the read cycle from the five processors to the master controller MC (external memory space) uses split 'transactions to increase effective bus utilization. ing.
特に重要なのは、 優先順位の設定である。 バスコ ン ト ロ ーラ B Cは、 常に最高の優先権を保持し続ける。 ペリ フエ ラルバス I Fは、 その次の優先権を保持し続ける。 マスタ 一コ ン ト ローラ M C、 R I S Cエンジン、 D S Pエンジン は、 ノ スコ ン ト ローラ B C とペリ フエラルバス I Fのいず れも内部システムバス S B U S の使用 リ クエス ト を行って いない場合にのみ、 内部システムバス S B U Sの使用 リ ク エス ト を発行できる。 図 2 0 は、 sys_priority(2:0)によつ て示される優先順位を説明する図である。  Of particular importance is the setting of priorities. The bus controller B C always keeps the highest priority. The Peripheral Bus IF will retain its next priority. The master controller MC, RISC engine, and DSP engine use the internal system bus only when neither the no-controller BC nor the peripheral bus IF requests the use of the internal system bus SBUS. A request to use SBUS can be issued. FIG. 20 is a diagram for describing the priority indicated by sys_priority (2: 0).
ゾ スコ ン ト ローラ B Cやペリ フエラルバス I F力、 らのバ ス使用 リ クエス トは、 sys_request_sl(l:0)の内の各 1 ビッ トの信号を各 R I S Cエンジンや D S Pエンジンが出力す る。 すなわちバスコ ン ト ロ一ラ B Cは sys_request— sl(0)、 ペリ フエラルバス I Fは sys_request_sl(l)を ドライ ブする 図 2 1 は、 バスコ ン ト ローラ B Cが出力する sys_request_ sl(0)の意味を説明する図である。 ペリ フエ ラルバス I Fは sys_request_sl(0)がアサ一ト されている場合には、 sys_requ est sl(0)を出力できない。 同様に、 マスターコ ン ト ローラ M C、 各 R I S Cエンジンや D S Pエンジンは、 sys— requ est— sl(0)又は sys— request— sl(0)がアサー ト されている場合 には、 sys_request(4:0)を出力できない。 As for bus use requests from the ZO Controller BC and the peripheral bus IF, each RISC engine or DSP engine outputs a 1-bit signal in sys_request_sl (l: 0). In other words, the bus controller BC drives sys_request-sl (0), and the peripheral bus IF drives sys_request_sl (l) .Figure 21 shows the meaning of sys_request_sl (0) output by the bus controller BC. FIG. The peripheral bus IF cannot output sys_request sl (0) when sys_request_sl (0) is asserted. Similarly, the master controller MC, each RISC engine or DSP engine cannot output sys_request ( 4 : 0) when sys-request-sl (0) or sys-request-sl (0) is asserted.
各 R I S Cエンジンや D S Pエンジンは、 ノ スコ ン ト 口 ーラ B C とペリ フエ ラルバス I Fのいずれも内部システム バス S B U Sの使用 リ クエス ト を行っていない場合、 sys— busy(8:0)信号 （バスコ ン ト ローラ B C、 ペリ フエラルバス I F , プログラム用メモ リ I M及びデータ用メモ リ D Mの ステータスを示す） を見て、 バスがビジーでなく 、 ァクセ スターゲッ トがビジーでなければ内部システムバス S B U S の使用 リ クエス ト を出し、 優先順位に従って使用権を獲 得する。  Each RISC engine or DSP engine uses the sys-busy (8: 0) signal (bus code) when neither the no-controller BC nor the peripheral bus IF requests the use of the internal system bus SBUS. Controller BC, the peripheral bus IF, the status of the program memory IM and the data memory DM), and if the bus is not busy and the access target is not busy, use the internal system bus SBUS. Submit quests and obtain usage rights according to priority.
こ こで、 sys_busy(0)信号は、 バスコ ン ト ローラ B Cが ド ライ ブする。 すなわち、 ノ スコ ン ト ローラ B Cが、 この s ys_busy(0)信号をアサー ト した場合、 他のプロセッサは、 バスコ ン ト ローラ B Cへのアクセスを目的にバス使用 リ ク エス トを発行する こ とができない。 具体的には、 バスコ ン ト ローラ B Cは、 マスターコ ン ト ローラ M C、 R I S Cェ ンジン、 D S Pエンジンか ら、 リ ー ドコマン ドやア ド レス を受ける と、 バスコ ン ト ローラ B Cは一旦それを内部のバ ッ フ ァ に保持し、 比較的低速な外部メモリ へのアクセス し リー ド結果を返す。 しかし、 リー ドコマン ドが連続して発 行され内部のバッ フ ァがいつ ぱいになる と、 sys— busy(O)信 号をアサー ト し、 それ以上の受付けを停止する。 図 2 2 は バスコ ン ト ローラ B Cが ド ライ ブする sys— busy(l)信号の 意味を説明する図である。  Here, the sys_busy (0) signal is driven by the bus controller BC. That is, when the no controller BC asserts the sys_busy (0) signal, the other processor issues a bus use request for the purpose of accessing the bus controller BC. Can not. Specifically, when the bus controller BC receives a read command or an address from the master controller MC, RISC engine, or DSP engine, the bus controller BC temporarily stores it in the controller. The buffer is kept in the buffer, and the external memory which is relatively slow is accessed and the read result is returned. However, when the read command is issued continuously and the internal buffer becomes full, it asserts the sys-busy (O) signal and stops further reception. FIG. 22 is a diagram for explaining the meaning of the sys-busy (l) signal driven by the bus controller BC.
また、 sys_busy(l)信号は、 マスタ一コ ン ト ローラ M C、 R I S Cエンジン、 D S Pエンジンが、 ノ スコン ト ローラ B Cへ後述するコマン ド を出力する と同時に 1 ク ロ ッ クだ けアサー トする。 これは、 ノ'スコ ン ト ローラ B Cから コマ ン ドに対する応答ステー トが返されるまでの間 （ 1 ク ロ ッ ク） 、 他のプロセッサか らノ スコ ン ト ローラ B Cヘアクセ スする こ とを禁止する為である。 図 2 3 は、 バスコ ン ト ロ ーラ B Cが ド ライ ブする sys— busy(l)信号の意味を説明す る図である。 The sys_busy (l) signal is output from the master controller MC, RISC engine, and DSP engine to the NOS controller. Outputs the command described later to BC and asserts for one clock at the same time. This prohibits other processors from accessing the controller BC until the controller BC returns a response state to the command (one clock). To do that. FIG. 23 is a diagram for explaining the meaning of the sys-busy (l) signal driven by the bus controller BC.
マスターコ ン ト ローラ M C と、 R I S Cエンジン R E 0 R I S Cェンジン R E 1 と、 D S Pエンジン D E 0 及び D S Pエンジン D E 1 との間のアービ ト レーショ ンは、 適 応型ラウン ドロ ビンで行われる。 この場合、 ある時点での 内部データバス D B U S使用の優先順位を示すための 3 ビ ッ トの信号 sys— priority(2:0)を用いる。 図 2 9 は、 sys— prio rity(2:0)によって示される優先順位を説明する図である。 こ こに示した通り、 sys— priority(2:0)が更新される こ とに よって、 ラウン ドロ ビンによるアービ ト レーショ ンが実現 される。  Arbitration between the master controller MC, the RISC engine RE0 RISC engine RE1, the DSP engine DE0 and the DSP engine DE1 is performed by an adaptive round robin. In this case, a 3-bit signal sys—priority (2: 0) is used to indicate the priority of using the internal data bus DBUS at a certain point in time. FIG. 29 is a diagram for explaining the priority indicated by sys-priority (2: 0). As shown here, arbitration by round robin is realized by updating sys-priority (2: 0).
sys— busy(3:2)信号は、 マスターコ ン ト ローラ M Cで ドラ イ ブされ、 データ用メモ リ D Mのステータスを示す。 すな わち、 マスターコ ン ト ローラ M C は、 内部デ一夕バス D B U S および内部システムバス S B U S を介して行われるデ 一夕用メモ リ D Mへのアクセス （コマン ド） をモニタ一し そのビジーステータスを出力する。 図 2 4 は、 内部データ バス D B U S及び内部システムバス S B U S によるデータ 用メモ リ のアクセス状況によって、 マスタ一コ ン ト ローラ M Cが生成する sys_busy(3:2)信号の生成ァルゴリ ズムを 示す表である。 図で、 Busy状態の時は、 リ ー ド · ァクセ ス も ライ ト · アクセス も どち ら も要求する こ とができない , また、 Ready Busy状態の時は、 ライ ト · アクセスは要求 する こ とができるが、 リ ー ド · アクセスは要求する こ とが できない。 尚、 sys_busy(3:2) = "ll"は、 データ用メモ リ D Mか らのデータ レディ が、 1 ク ロ ッ ク遅れる こ とを示すの で、 内部システムバス S B U S は Busy状態で使用禁止と なる。 The sys—busy (3: 2) signal is driven by the master controller MC and indicates the status of the data memory DM. That is, the master controller MC monitors the access (command) to the data memory DM via the internal data bus DBUS and the internal system bus SBUS, and monitors its busy status. Is output. Figure 24 is a table showing the algorithm for generating the sys_busy (3: 2) signal generated by the master controller MC according to the access status of data memory by the internal data bus DBUS and the internal system bus SBUS. . In the figure, in the busy state, neither read access nor write access can be requested, In the Ready Busy state, write access can be requested, but read access cannot be requested. Note that sys_busy (3: 2) = "ll" indicates that the data ready from the data memory DM is delayed by one clock, so the internal system bus SBUS must be disabled in the busy state. Become.
sys_busy(5:4)信号は、 マスターコ ン ト ローラ M Cで ドラ イ ブされ、 プログラム用メモリ のステータスを示す。 すな わち、 マスターコ ン ト ローラ M Cは、 内部命令バス I B U Sおよび内部システムバス S B U S を介して行われるプロ グラム用メモ リへのアクセス （コマン ド） をモニターし、 そのビジーステータスを出力する。 図 2 5 は、 内部命令バ ス I B U S及び内部システムバス S B U S によるプロダラ ム用メモ リ のアクセス状況によって、 マス夕一コ ン ト 口一 ラ M Cが生成する sys_busy(5:4)信号の生成ァルゴリ ズム を示す表である。 図で、 Busy状態の時は、 リ ー ド · ァク セスもライ ト · アクセス もどち ら も要求する ことができな い。 また、 Ready Busy状態の時は、 ライ ト · アクセスは 要求する ことができるが、 リ ー ド · アクセスは要求する こ とができない。  The sys_busy (5: 4) signals are driven by the master controller MC and indicate the status of the program memory. That is, the master controller MC monitors access (command) to the program memory via the internal instruction bus IBUS and the internal system bus SBUS, and outputs the busy status. Figure 25 shows the algorithm for generating the sys_busy (5: 4) signal generated by the MC according to the access status of the program memory by the internal instruction bus IBUS and the internal system bus SBUS. FIG. In the figure, in the Busy state, neither read access nor write access can be requested. In the Ready Busy state, write access can be requested, but read access cannot be requested.
sys_busy(6)信号は、 ペリ フエラルバス I Fで ド ライ ブさ れ、 ペリ フエラルバス I Fのステータスを示す。 図 2 6 は ペ リ フエラルバス I Fが生成する sys_busy(6)信号の意味 を示す図である。 図で、 Busy状態の時は、 ペリ フエラル バス I Fへのアクセス 目的でバス使用 リ クエス ト を要求す る こ とはできない。 もちろん、 ペリ フエラルバス I Fへの コマン ドも発行できない。 具体的に説明すれば、 ペリ フエ ラルバス I Fは、 マスターコ ン ト ローラ M C、 R I S Cェ ンジン、 D S Pエンジンから、 リ ー ドコマン ドやア ド レス を受ける と、 ペ リ フエラルバス I F は一旦それを内部のバ ッ フ ァに保持し、 比較的低速な周辺回路へのアクセス し結 果を返す。 しかし、 リ ー ドコマン ドが連続して発行され内 部のバッ フ ァがいつ ばいになる と、 sys_busy(6)信号をアサ 一 卜 し、 それ以上の受付けを停止する。 The sys_busy (6) signal is driven by the peripheral bus IF and indicates the status of the peripheral bus IF. Figure 26 shows the meaning of the sys_busy (6) signal generated by the peripheral bus IF. In the figure, in the Busy state, it is not possible to request a bus use for the purpose of accessing the peripheral bus IF. Of course, no command can be issued to the Peripheral Bus IF. More specifically, the peripheral bus IF is connected to the master controller MC and the RISC interface. When a read command or address is received from the engine or DSP engine, the peripheral bus IF temporarily stores it in an internal buffer, accesses relatively slow peripheral circuits, and returns the result. . However, when the read command is issued continuously and the internal buffer becomes too busy, it asserts the sys_busy (6) signal and stops further reception.
また、 sys— busy(7)信号は、 マスタ一コ ン ト ローラ M ：、 R I S Cエンジン、 D S Pエンジンが、 ペリ フエ ラルバス I Fへ後述するコマン ドを出力する と同時に 1 ク ロ ッ クだ けアサ一 卜する。 これは、 ペリ フエラルバス I Fから コマ ン ドに対する応答ステー トが返されるまでの間 （ 1 ク ロ ッ ク） 、 他のプロセッサからペリ フエラルバス I Fヘアクセ スする こ とを禁止する為である。 図 2 7 は、 ペリ フエ ラル バス I Fが ドライ ブする sys— busy(7)信号の意味を説明す る図である。  The sys-busy (7) signal is output from the master controller M :, RISC engine, and DSP engine to the peripheral bus IF at the same time as one clock. To remove. This is to prevent other processors from accessing the peripheral bus IF until the response state to the command is returned from the peripheral bus IF (one clock). FIG. 27 is a diagram for explaining the meaning of the sys—busy (7) signal driven by the peripheral bus IF.
sys_busy(8) 信号は、 バスの使用権を獲得したマス夕一 コ ン ト ローラ M C 、 R I S Cエンジンや D S Pエンジンが コマン ドを送出する時、 内部システムバス S B U S を続け て使用する場合に 1 、 内部システムバス S B U S を 1 サイ クルだけ使用する場合には 0 を ドライ ブする。 これによつ て、 連続してバスを使用する こ とができる。  The sys_busy (8) signal is used when the controller MC, RISC engine or DSP engine that has acquired the right to use the bus issues a command when the internal system bus SBUS is used continuously. Drive 0 when using only one cycle of system bus SBUS. This allows the bus to be used continuously.
この sys_busy(8)信号は、 マス夕一コ ン ト ローラ M C 、 R I S Cエンジン、 D S Pエンジンがバスコ ン ト ローラ B Cやペリ フエラルバス I Fのよ う に リ ー ド · アクセスを要 求し、 データのレディ を待つ場合に、 コマン ド送出サイ ク ルから最後のレディ を受け取るまでの間、 バス使用権を獲 得したプロセッサによって出力される。  The sys_busy (8) signal indicates that the mass controller MC, RISC engine, or DSP engine requires read access like the bus controller BC or the peripheral bus IF, and the data is ready. When waiting, this signal is output by the processor that has acquired the right to use the bus until the last ready is received from the command transmission cycle.
内部システムバス S B U S使用 リ クエス トは、 svs requ est(4:0)の内の各 1 ビッ 卜の信号をマスターコ ン ト ローラ M Cおよび各 R I S Cエンジンや D S Pエンジンが出力す る。 すなわち R I S Cエンジン R E 0 は sys_request(0)、 R I S Cエンジン R E 1 は sys— request(l)、 D S Pェンジ ン D E 0 は sys— request(2)、 D S Pエンジン D E 1 は sys_r equest(3)、 マスターコ ン 卜 ローラ M Cは sys— request(4)を ドライ ブする。 図 2 8 は、 R I S Cエンジン R E 0が出力 する sys_request(0)の意味を説明する図である。 The request for using the internal system bus SBUS is svs requ The master controller MC and each RISC engine and DSP engine output a 1-bit signal in est (4: 0). That is, RISC engine RE 0 is sys_request (0), RISC engine RE 1 is sys-request (l), DSP engine DE 0 is sys-request (2), DSP engine DE 1 is sys_request (3), master The controller MC drives sys-request (4). FIG. 28 is a view for explaining the meaning of sys_request (0) output by the RISC engine RE0.
バス使用権は、 図 2 9 に示す規則に従って決め られる。 また、 マスターコ ン ト ローラ M C、 R I S Cエンジンや D S Pエンジンは、 バス使用権獲得後、 次のサイ クルでア ド レスと ともにコマン ドを出力する。 図 3 0 は、 マスターコ ン ト ローラ M C、 R I S Cエンジンや D S Pエンジンが出 力する コマン ドの一覧である。 こ こで、 コマン ド発行元 S RCの Pxは、 コ ン ト ローラ M G、 R I S Cエンジンや D The right to use the bus is determined according to the rules shown in Figure 29. After acquiring the right to use the bus, the master controller MC, RISC and DSP engines output a command together with the address in the next cycle. Figure 30 is a list of commands output by the master controller MC, RISC and DSP engines. Here, the Px of the command issuer SRC is the controller MG, RISC engine or D
S Pエンジンのプロセッサ I Dであ り 、 アクセス先の BIU はパスコ ン ト ローラ B C、 DMはデータ用メモ リ D M、 IM はプロ グラム用メモ リ I M、 IPUはペリ フエラルバス I F を示す。 The processor ID of the SP engine, the access destination BIU indicates the pass controller BC, DM indicates the data memory DM, IM indicates the program memory IM, and IPU indicates the peripheral bus IF.
尚、 コマン ド sys_cmd(3:0)は、 転送データ数 （ロー ド マルチ、 ス トアマルチで BIUに対するコマン ド時に使 用） であ り 、 たとえば、 "0000"は 1 6 ロ ングワー ド、 "000 1"は 1 ロ ングワー ド、 "1111"は 1 5 ロ ングワー ドである。 また、 コマン ド sys— cmd(5:4)は、 データサイズ （00: ノ イ ト、 01:ワー ド、 10:ロ ングワー ド、 11:リ ザーブ） であ り、 sys_cmd(6)によって、 ロー ドス トア （0 : ス トア、 1 : ロー ド） を識別し、 sys_cmd(10:7)は、 アクセスのデス ティ ネーシヨ ン （BCからのコマン ドを除く） を示す。 更 に、 "0000"のとき、 コマン ドは NOP となる。 Note that the command sys_cmd (3: 0) is the number of data to be transferred (used when the BIU is commanded in load multi and store multi). For example, “0000” is 16 long words, “000 1 "Is one longword, and" 1111 "is fifteen longwords. The command sys—cmd (5: 4) is the data size (00: note, 01: word, 10: longword, 11: reserve). Identifies the store (0: store, 1: load), and sys_cmd (10: 7) indicates the destination of the access (excluding commands from BC). Change When "0000", the command is NOP.
尚、 マスターコ ン ト ローラ M Cは、 R I S Cエンジンや D S Pエンジンから送られてきたァ ド レスが、 実装されて いるァ ド レス空間外のとき、 あるいはリ ザーブのコマン ド が送られてきた時にデータサイ クルで、 バスエラ一 sys一 bi u— berr = l を返す。 同様に、 データ用メモ リ D Mは、 マスタ 一コ ン ト ローラ M C、 R I S Cエンジンや D S Pエンジン から送られてきたア ド レスが、 実装されているア ド レス空 間外の時にデータサイ クルで、 バスエラー sys_dm一 berr = l を返す。 また、 プログラム用メモ リ は、 マスターコ ン ト 口 ーラ M C、 R I S Cエンジンや D S Pエンジンから送られ てきたア ド レスが、 実装されているア ド レス空間外の時に データサイ クルで、 ノ、'スエラ一 sys— dm— berr=l を返す。 ま た、 ペリ フエラルバス I Fは、 マスタ一コ ン ト ローラ M C R I S Cエンジンや D S Pエンジンから送られてきたア ド レスが、 そのア ド レス空間外の時にデ一夕サイ クルで、 バ スエフ一 sys_ipu_berr=l を返す。 The master controller MC sends data when the address sent from the RISC engine or DSP engine is outside the installed address space, or when a reserve command is sent. In the cycle, return bus error- sys- bi-berr = l. Similarly, the data memory DM is used in the data cycle when the address sent from the master controller MC, RISC engine or DSP engine is outside the mounted address space. Returns bus error sys_dm one berr = l. In addition, the program memory is a data cycle when the address sent from the master controller MC, RISC engine or DSP engine is outside the address space in which it is mounted. 'Return sys-dm-berr = l. In addition, the peripheral bus IF uses a bus cycle when the address sent from the master controller MCRISC engine or DSP engine is out of the address space, and the bus control sys_ipu_berr = l return it.
上記のマルチプロセッサ · システムでは、 2つの R I S Cエンジンと 2つの D S Pエンジンを実装している。 その 他の構成要素は、 主にマス夕一コ ン ト ローラ M C、 パスコ ン ト ロ一ラ B C、 ペリ フエラルバス I F、 プログラム用メ モリ I M及びデータ用メモリ D Mである。 本発明によるマ ルチプロセッサ · システムでは、 要求される処理能力に応 じて、 この R I S Cエンジンや D S Pエンジンの個数を容 易に増減する こ とができる。  The above multiprocessor system implements two RISC engines and two DSP engines. Other components are mainly a mass controller MC, a pass controller BC, a peripheral bus IF, a program memory IM, and a data memory DM. In the multiprocessor system according to the present invention, the number of RISC engines and DSP engines can be easily increased or decreased according to the required processing capacity.
即ち、 適応型ラウン ド ロ ビンの分散アービ ト レーショ ン 方式を使用 したマルチプロセッサシステムにおいて、 予め 最大プロセッサ数に対応したァービ ト レ一ショ ン回路を各 プロセ ッサに搭載しておく こ とによ り 、 R I S Cエンジン や D S Pエンジンの個数を自由に変更する こ とができる様 になる。 また、 これによ り 、 実装されている R I S Cェン ジンや D S Pエンジンの中で、 実際に動作させたいェンジ ンの個数を自由に変更する ことができ、 きめの細かい省電 力の機能をアプリ ケーショ ンレベルで実装する こ とが可能 となる。 That is, in a multiprocessor system using the adaptive round robin distributed arbitration method, an arbitration circuit corresponding to the maximum number of processors is previously provided for each. By installing it in the processor, the number of RISC engines and DSP engines can be changed freely. In addition, this allows the number of engines to be actually operated in the installed RISC engine and DSP engine to be freely changed, and enables fine-grained power saving functions to be implemented in the application. It can be implemented at the case level.
以下、 プロセッサの個数を変更する方法を具体的に説明 する。 まず、 本発明によるマルチプロセ ッサ · システムを ハー ドウェア記述言語で記述してお く 。 この八一ドウエア 記述言語による ソーステキス トあるいはそれをコ ンパイル したオブジェク ト には、 本発明によって導入された有用な 特徴が含まれている。 また、 最終的に具体化した物理的な デバイスにも、 その特徴に対応する特徴が含まれている。 そして、 その特徴によって、 きめの細かい省電力の機能を アプリ ケーショ ンレベルで実装する ことが可能となる。  Hereinafter, a method of changing the number of processors will be specifically described. First, a multiprocessor system according to the present invention is described in a hardware description language. The source text in the 81st software description language or an object obtained by compiling the source text includes useful features introduced by the present invention. In addition, the physical device finally embodied also has features corresponding to those features. And, due to its features, it is possible to implement fine-grained power saving functions at the application level.
ハー ドウェア記述言語と して、 こ こでは V H D L を用い て、 R T L レベルで記述する。 図 3 1 は、 ハー ドウェア記 述言語によるマルチプロセッサ · システムの一般的な設計 手順を説明する図である。 まず、 ステッ プ S 1 では、 ハー ドウエア記述言語によるソーステキス ト を作成する。 次に ステッ プ S 2 では、 このソーステキス 卜 をコ ンパイルして オブジェク トコー ドを生成する。 そして、 ステッ プ S 3 で は、 このオブジェク トコー ドを用いて、 動作シミ ュ レ一シ ヨ ンを行う。 ステッ プ S 4で、 動作シミ ュ レーショ ンの結 果が、 要求仕様を満たしていなければ、 ソーステキス ト を 修正して再度コ ンパイル及び動作シミ ュ レーショ ンを行う， 動作シミ ュ レ一ショ ンの結果が要求仕様を満たしていれば. このオブジェク ト コー ドを用いて、 ステッ プ S 5 で、 実際 の物理的なデバイス を作成し、 最終的な動作シミ ュ レ一シ ョ ンを行う。 Here, we use VHDL as the hardware description language and describe it at the RTL level. Figure 31 is a diagram illustrating the general design procedure for a multiprocessor system using a hardware description language. First, in step S1, source text is created in a hardware description language. Next, in step S2, this source text is compiled to generate an object code. Then, in step S3, an operation simulation is performed using this object code. In step S4, if the result of the operation simulation does not satisfy the required specifications, the source text is corrected, and the compilation and the operation simulation are performed again. The operation simulation is performed. If the result of the above meets the required specifications. By using this object code, an actual physical device is created in step S5, and a final operation simulation is performed.
こ こで、 本件発明者は、 上記実施形態で詳し く 説明した ラウン ド ロ ビンの特徴に注目 した。 ラウン ド ロ ビンによる アービ ト レーシ ョ ンでは、 プロセッサの幾つかがが完全に 止まっても問題なく 機能する。 つま り 、 ァービ ト レ一ショ ンを行う回路に とって、 実際に機能しているプロセッサの 数は問題ではない。 ラウン ド ロ ビンを行う こ とのできるプ 口セッサの数の上限があるだけである。  Here, the present inventor paid attention to the features of the round robin described in detail in the above embodiment. In round robin arbitration, some of the processors will work without any problems. In other words, the number of processors actually functioning does not matter for the arbitration circuit. There is only an upper limit on the number of processors that can do round robin.
従って、 アービ ト レーショ ン回路には、 最大プロセッサ 数に対応するスケーラ ビリ ティ を実装する。 これによるハ 一ドウエアに対するォ一バーへッ ドは少ない。 なぜな ら、 プロセッサを区別して管理するための I Dのビッ ト数の違 い程度で済むからである。 こ こでは、 R I S Cエンジンや D S Pエンジンに対するプロセッサ I Dのピッ ト数を 3 と する。 即ち、 最大プロセッサ数を 8 とする。  Therefore, scalability corresponding to the maximum number of processors is implemented in the arbitration circuit. As a result, there is little overhead for hardware. The reason for this is that the number of ID bits for managing the processors separately is only required to be different. Here, the number of pits of the processor ID for the RISC engine and the DSP engine is three. That is, the maximum number of processors is eight.
V H D L のソーステキス トで、 この最大プロセッサ数を 定義しておく 。 図 3 2 は、 本発明の実施形態によるマルチ プロセッサシステムのソーステキス 卜の中のバーケージフ アイルである。 このフ ァイルでは、 デザイ ン全体で参照さ れるパラメ一夕 とその値を宣言する。 こ こで、 R I S Cェ ンジンの数に対応して RE— NUM という定数と、 D S Pェ ンジンの数に対応して DE— NUM という定数が定義される これらの定数には、 0から 8 の値を任意に指定する こ と力 できる。 この制限は、 アービ ト レーショ ン回路で管理でき る最大プロセッサ数による もの " ある。  This maximum number of processors is defined in the source text of VHDL. FIG. 32 is a package file in the source text of a multiprocessor system according to an embodiment of the present invention. This file declares the parameters and their values that will be referenced throughout the design. Here, a constant named RE-NUM is defined corresponding to the number of RISC engines, and a constant named DE-NUM is defined corresponding to the number of DSP engines. These constants have values from 0 to 8. Can be specified arbitrarily. This limitation is due to the maximum number of processors that can be managed by the arbitration circuit. "
図 3 2 は、 上記実施形態のものであ り 、 RE NUM と DE —NUMは共に 2 と記載されている。 しかし、 例えば、 R I S Cエンジンが 3個、 D S Pエンジンが 3個のマルチプロ セッサシステムを作成するには、 単に RE— NUM を 3 に、 また DE— NUM を 3 にして、 リ コ ンパイルするだけでよい 尚、 こ こでは、 マスターコン ト ローラ M C、 バスコ ン ト ロ ーラ B C、 ペリ フエラルバス I F、 プログラム用メモリ I M及びデータ用メモリ D Mのハ一 ドウエアは固定と してい る。 FIG. 32 shows the above embodiment, in which RE NUM and DE — Both NUM are listed as 2. However, for example, to create a multiprocessor system with three RISC engines and three DSP engines, simply recompile with RE-NUM set to 3 and DE-NUM set to 3. In this case, the hardware of the master controller MC, the bus controller BC, the peripheral bus IF, the program memory IM, and the data memory DM is fixed.
図 3 3 ( A , B ) は、 本発明の実施形態によるマルチプ 口セッサシステムのソーステキス トの中の実装部分のフ ァ ィル （MISC.VHD) の前半部分を説明する図である。 この ファイルでは、 デザイ ン自体に関する記述をする。 こ こで MISC という ENTITYの宣言でマルチプロセッサシステム 全体の入出力ポー トの名前と接続される信号のタイプが宣 言されている。  FIG. 33 (A, B) is a diagram illustrating the first half of the file (MISC.VHD) of the mounting part in the source text of the multi-processor system according to the embodiment of the present invention. This file describes the design itself. Here, the ENTITY declaration of MISC declares the names of the input / output ports of the entire multiprocessor system and the types of signals to be connected.
また、 RE というコンポーネン ト として R I S Cェンジ ンの宣言が行われる。 ここで、 GENERIC PARAMETER と してプロセッサ番号が引数となっている。 同様に、 DE と いう コンポーネン ト として D S Pエンジンの宣言が行われ る。 やはり、 GENERIC PARAMETER としてプロセッサ番 号が引数となっている。 尚、 R I S Cエンジンと D S Pェ ンジンの実装部分では、 内部システムバス S B U S、 内部 命令バス I B U S及び内部データバス D B U Sのそれぞれ の為の 8 プロセッサ対応のバスのァ一ビ 卜 レーショ ン論理 が組込まれている。  Also, the RISC engine is declared as a component called RE. Here, the processor number is an argument as GENERIC PARAMETER. Similarly, the DESP engine is declared as a component called DE. After all, the processor number is the argument as GENERIC PARAMETER. The RISC engine and the DSP engine are equipped with the integration logic of the bus for 8 processors for each of the internal system bus SBUS, internal command bus IBUS and internal data bus DBUS. .
更に、 SIGNAL文では、 MISC というデザイ ンの中で使 用する信号の名前とタイプを宣言する。 実装部分のフ アイ ルの、 ここまで説明した部分までは実際の RE NUMや DE _NU M の数値は現れてこない。 In addition, the SIGNAL statement declares the names and types of signals used in the design called MISC. Up to the part described so far in the file of the implementation part, the actual RE NUM and DE The value of _NU M does not appear.
次に、 GENERATE文で、 実際の R I S Cエンジンのィ ンスタ ンス と、 D S Pエンジンのイ ンスタ ンスが生成され る。 図 3 4 ( A , B ) は、 本発明の実施形態によるマルチ プロセッサシステムのソーステキス 卜の中の実装部分のフ アイ ル （MIS C.VHD) の後半部分を説明する図である。 即 ち、 FORループの中で、 ほぼ同一のコ ンポーネン トカ RE — NUM と DE_NUM の数だけ繰 り返し生成される。 こ こで 増分される変数 i は、 PROCES SOR— NUM、 即ち、 プロセ ッサ I D と して渡されると共に、 上述した通 り 、 し request といった各リ クエス ト信号の ドライ ブと して参照が行える よう に記述されている。 即ち、 例えば、 リ クエス ト信号 i _request[i]を ドライ ブする様に実装される。 従って、 ド ラ イ ブする リ クエス ト信号の配列の添え字のみが異なる同一 のコ ンポーネン 卜が繰り返し生成される。  Next, the GENERATE statement creates an actual RSC engine instance and a DSP engine instance. FIG. 34 (A, B) is a diagram illustrating the latter half of the file (MIS C. VHD) of the mounting part in the source text of the multiprocessor system according to the embodiment of the present invention. That is, in the FOR loop, almost the same number of component cards RE — NUM and DE_NUM are repeatedly generated. The variable i to be incremented here is passed as PROCES SOR-NUM, that is, the processor ID, and can be referred to as the drive of each request signal such as request as described above. It is described as follows. That is, for example, it is implemented to drive the request signal i_request [i]. Therefore, the same component that differs only in the suffix of the array of the request signal to be driven is repeatedly generated.
以上の様な設計方法によって、 静的にプロセッサ数を変 更する こ とが容易にできる。 即ち、 プロセッサエンジンと して用意しておいた R I S Cエンジンと D S Pエンジンを 組み合わせて 8 プロセッサエンジンまで容易に追加可能と なる。 例えば、 以下のような構成が容易に可能となる  With the above design method, it is easy to change the number of processors statically. In other words, it is possible to easily add up to eight processor engines by combining the RISC engine and the DSP engine prepared as processor engines. For example, the following configuration is easily possible
RE— NUM = 1、 DE_NUM = 0 一 > RE— NUM = 1, DE_NUM = 0 0>
( MC + BC + IM + DM + IPU + PU) + RE  (MC + BC + IM + DM + IPU + PU) + RE
RE_NUM = 2、 DE_NUM = 0 一〉  RE_NUM = 2, DE_NUM = 0 one>
( MC + BC + IM + DM + IPU + PU) + RE + RE  (MC + BC + IM + DM + IPU + PU) + RE + RE
RE— NUM = 3、 DE_NUM = 0 ―〉  RE— NUM = 3, DE_NUM = 0 ―〉
( MC + BC + IM + DM + IPU + PU) + RE + RE + RE (MC + BC + IM + DM + IPU + PU) + RE + RE + RE
RE NUM = 4、 DE NUM = 0 一 > (MC + BC + IM + DM + IPU + PU) + RE+ RE + RE + RE RE NUM = 4, DE NUM = 0 1> (MC + BC + IM + DM + IPU + PU) + RE + RE + RE + RE
RE— NUM = 8、 DE_NUM = 0 ―〉 RE— NUM = 8, DE_NUM = 0->
(MC + BC + IM + DM + IPU + PU) + RE+ RE + RE + RE + RE +RE+RE+RE  (MC + BC + IM + DM + IPU + PU) + RE + RE + RE + RE + RE + RE + RE + RE
RE— NUM = 0、 DE_NUM = 1 ―〉 RE— NUM = 0, DE_NUM = 1 ―〉
( MC + BC + IM + DM + IPU + PU) + DE  (MC + BC + IM + DM + IPU + PU) + DE
RE_NUM = 0、 DE_NUM = 2 ―〉  RE_NUM = 0, DE_NUM = 2 ―〉
( MC + BC + IM + DM + IPU + PU) + DE+ DE  (MC + BC + IM + DM + IPU + PU) + DE + DE
RE_NUM = 0、 DE_NUM = 3 一 >  RE_NUM = 0, DE_NUM = 3 one>
( MC + BC + IM + DM + IPU + PU) + DE+ DE + DE RE— NUM = 0、 DE一 NUM = 4 ―〉  (MC + BC + IM + DM + IPU + PU) + DE + DE + DE RE— NUM = 0, DE-NUM = 4->
( MC + BC + IM + DM + IPU + PU) + DE+ DE + DE + DE  (MC + BC + IM + DM + IPU + PU) + DE + DE + DE + DE
RE— NUM = 0、 DE— NUM = 8 — > RE—NUM = 0, DE—NUM = 8—>
( MC + BC + IM + DM + IPU + PU) + DE+ DE + DE + DE + DE +DE+DE+DE  (MC + BC + IM + DM + IPU + PU) + DE + DE + DE + DE + DE + DE + DE + DE
RE_NUM = 1, DE_NUM = 1 — > RE_NUM = 1, DE_NUM = 1 —>
( MC + BC + IM + DM + IPU + PU) + RE+ DE  (MC + BC + IM + DM + IPU + PU) + RE + DE
RE_NUM = 2、 DE_NUM = 1 — >  RE_NUM = 2, DE_NUM = 1 —>
( MC + BC + IM + DM + IPU + PU) + RE+ RE+ DE RE_NUM = 2、 DE_NUM = 2 ―〉  (MC + BC + IM + DM + IPU + PU) + RE + RE + DE RE_NUM = 2, DE_NUM = 2->
( MC + BC + IM + DM + IPU + PU) + RE+ RE+ DE+ DE RE_NUM = 3、 DE_NUM = 1 ―〉  (MC + BC + IM + DM + IPU + PU) + RE + RE + DE + DE RE_NUM = 3, DE_NUM = 1->
( MC + BC + IM + DM + IPU + PU) + RE+ RE+ RE+ DE このよう に して、 同一のソーステキス ト によって構成可 能なシステムの種類は、 膨大なものとなる。 (MC + BC + IM + DM + IPU + PU) + RE + RE + RE + DE Thus, the types of systems that can be configured with the same source text are enormous.
また、 本発明によるマルチプロセ ッサ · システムでは、 動的にプロセ ッサ数を変更する こ とが容易にできる。 即ち R I S Cエンジンと D S Pエンジンに予めパワーダウ ン用 の命令 （ STOP 命令） を実装してお く 、 この STOP 命令は プログラムで利用できる通常の命令であ り 、 その実行によ つて、 そのプロセッサの電力消費は最低限に抑え られる。 復帰にはマス夕一コ ン ト ローラ M C による割り込み命令な どを用いる。  Further, in the multiprocessor system according to the present invention, it is possible to easily change the number of processors dynamically. That is, a power-down instruction (STOP instruction) is mounted in the RISC engine and the DSP engine in advance. This STOP instruction is a normal instruction that can be used in a program. Is kept to a minimum. For recovery, an interrupt instruction from the mass controller MC is used.
この時、 停止したプロセッサの適応型ラウン ド ロ ビンの ァービ ト レーショ ン回路は、 バスの使用 リ クエス ト を発行 しないため、 アービ ト レーショ ンの優先順位は、 自動的に プロセッサの数が少なく なった状態に適応できる。  At this time, the arbitration circuit in the adaptive round robin of the stopped processor does not issue a request to use the bus, and the arbitration priority is automatically reduced to the number of processors. Can adapt to the situation.
以上、 本発明を実施例によ り詳細に説明したが、 当業者 にとつては、 本発明が本願中に説明した実施例に限定され る ものではないという こ とは明らかである。 本発明の装置 は、 特許請求の範囲の記載によ り定まる本発明の趣旨及び 範囲を逸脱する こ となく修正及び変更態様と して実施する こ とができる。 従って、 本願の記載は、 例示説明を目的と する ものであ り 、 本発明に対して何ら制限的な意味を有す る ものではない。  As described above, the present invention has been described in detail with reference to the examples. However, it is apparent to those skilled in the art that the present invention is not limited to the examples described in the present application. The device of the present invention can be implemented as a modified or changed embodiment without departing from the spirit and scope of the present invention defined by the description of the claims. Therefore, the description of the present application is intended for illustrative purposes and has no restrictive meaning to the present invention.
例えば、 上記実施例では、 プロセッサのタイ プと して R I S Cエンジンや D S Pエンジンが用い られているが、 更 に異なるタイ プのプロセッサを実装する こ と も極めて容易 である。 即ち、 SIMD型のプロセッサエンジン （ SE) やべ クタ一型のプロセッサエンジン （ VE) 、 グラフィ ッ クス 処理用のプロセッサエンジン （ GE) 等を加える こ とによ り 、 構成可能なシステムの種類をさ らに増やすこ とができ るため、 非常に幅広いアプリ ケーシ ョ ンに対応可能となる その場合、 例えば、 適当なグラ フィ ッ クス処理用のプロセ ッサエンジンの I P を入手して組み込めば良い。 そして、 GE— NUM と いう定数定義を追加し、 その数だけイ ンス夕 ンスを生成するコー ドを挿入する。 上記の場合では、 RE— NUM、 DE— NUM、 GE_NUM の総和力 8迄であればどのよ うな組み合わせでも可能である。 For example, in the above embodiment, a RISC engine or a DSP engine is used as a processor type, but it is extremely easy to implement a different type of processor. That is, by adding a SIMD type processor engine (SE), a vector type processor engine (VE), a graphics processing processor engine (GE), etc. In addition, the number of configurable systems can be increased to accommodate a very wide range of applications, such as the IP of a processor engine for the appropriate graphics processing. It is good to get and incorporate. Then, add a constant definition called GE—NUM, and insert the code that generates the number of instances. In the above case, any combination is possible as long as the total power of RE-NUM, DE-NUM, and GE_NUM is up to 8.
また、 上記実施例では、 マスターコ ン ト ローラ M Cおよ び各 R I S Cエンジンや D S Pエンジンとには、 非対称の マルチプロセッサシステムとなっている。 しかし、 各 R I S Cエンジンや D S Pエンジンのみからなる対称型のマル チプロセッサの実装も、 当業者であれば、 上記の開示から 本発明の実施例と して実装可能である こ とは明らかである 更に、 上記実施例では、 R I S Cエンジンや D S P ェン ジンのみの組み合わせであるが、 それ以外のエンジン、 例 えば S プログラム用メモ リ 、 D型のエンジン、 グラフイ ツ クスエンジン、 Vector型のエンジン、 あるいはカスタムェ ンジンと して特定のハー ドゥエアブロ ッ クをエンジンと し て組み込むこ ともできる。  Further, in the above embodiment, the master controller MC and each RISC engine and DSP engine are asymmetric multiprocessor systems. However, it is clear that those skilled in the art can also implement a symmetric multiprocessor including only each RISC engine or DSP engine as an embodiment of the present invention from the above disclosure. In the above embodiment, the combination of only the RISC engine and the DSP engine is used. However, other engines, for example, an S program memory, a D type engine, a graphics engine, a Vector type engine, or a custom engine are used. A specific hard air block can also be incorporated as an engine as an engine.
更に、 上記実施例では、 プロセッサエンジンの数は 4個 であるが、 同様の方法によ り、 エンジンの数を 8個まで、 16個まで、 32個まで、 という よ う に増やすこ とは、 当業 者にとって容易に可能である。  Further, in the above embodiment, the number of processor engines is four, but increasing the number of engines to 8, 16, or 32 in a similar manner is as follows. It is easily possible for those skilled in the art.
更に、 上記実施例では、 内部メモ リ を命令メモ リ とデー タメモリ の 2つと しているが、 同様の方法によ り 、 さ らに 数多く のメモ リ を搭載するよう に変更を加える こ とは、 当 業者にとって容易に可能である。 更に、 上記実施例では、 外部バスコ ン ト ローラは 1 つで あるが、 同様の方法によ り 、 複数の外部バスコ ン ト ローラ. を搭載するよう に変更を加える こ とは、 当業者にとって容 易に可能である。 Furthermore, in the above embodiment, the internal memory is two, the instruction memory and the data memory. However, it is not possible to change the internal memory to include more memory by the same method. It is easily possible for those skilled in the art. Further, in the above embodiment, the number of the external bus controller is one. However, it is possible for those skilled in the art to make a change to include a plurality of external bus controllers by the same method. It is easily possible.
更に、 上記実施例では、 内部ペ リ フエラルユニッ ト に夕 イ マおよび I/O を付けているが、 同様の方法によ り 、 様々 な周辺デバイスを搭載するよう に変更を加える こ とは、 当 業者にとって容易に可能である。  Furthermore, in the above embodiment, the internal peripheral unit is provided with an image and an I / O. However, it is not possible to change the peripheral device to include various peripheral devices in the same manner. It is easily possible for traders.
更に、 上記実施例では、 マスターコ ン ト ローラ、 R I S Cエンジン、 D S Pエンジンのアーキテクチャ例を示して いるが、 他のアーキテクチャのプロセ ッサに同様のバスァ ーキテクチヤを組み合わせる こ とは、 当業者にとって容易 に可能である。  Further, in the above embodiment, the example of the architecture of the master controller, the RISC engine, and the DSP engine is shown. However, it is easy for those skilled in the art to combine a processor with another architecture with a similar bus architecture. It is possible.
更に、 上記実施例では、 プログラム用メモ リ I M及びデ —夕用メモ リ D Mは、 ノーウェイ トでデータ転送が可能な ので、 内部命令バス I B U S と内部データバス D B U S は スプリ ッ ト ト ラ ンザク ショ ン · バスではなく 、 通常の接続 ト ラ ンザク ショ ン · ノ ス と している。 しかし、 高速小容量 のプログラム用メモリ及びデータ用メモ リ の代わ り に、 大 容量のプログラム用メモ リ及びデータ用メモリ を内部命令 バス I B U S、 内部デ一夕バス D B U S に接続し、 3本の バスのそれぞれをスプリ ッ ト ト ラ ンザク ショ ン · バス と し てもよい。 その場合、 R I S Cエンジン、 D S Pエンジン か らのバス使用要求は、 ラウン ド ロ ビンのァービ ト レーシ ヨ ン方式と し、 大容量のプログラム用メモ リ及びデータ用 メモ リ からのバス使用要求は、 それよ り も優先度の高い固 定の優先順位を持つァービ ト レーショ ン方式と してもよい , 産業上の利用可能性 Further, in the above embodiment, since the program memory IM and the data memory DM can transfer data in a no-way manner, the internal instruction bus IBUS and the internal data bus DBUS are used in the split transaction. · It is not a bus but a normal connection transaction nos. However, instead of high-speed small-capacity program memory and data memory, large-capacity program memory and data memory are connected to the internal instruction bus IBUS and internal data bus DBUS, and three buses are connected. Each of these may be a split transaction bus. In this case, the bus use request from the RISC engine and DSP engine shall be a round robin arbitration system, and the bus use request from a large-capacity program memory and data memory shall be An arbitration method having a fixed priority with a higher priority may be used. Industrial applicability
以上説明 したよう に、 本発明の実施形態による ラウ ン ド ロ ビンのァ一ビ ト レーショ ン方式を使用 したマルチプロセ ッサシステムでは、 予め最大プロセッサ数に対応したァー ビ ト レーシヨ ン回路を各プロセ ッサに搭載しておく こ とに よ り 、 R I S Cエンジンや D S Pエンジンの個数を自 由に 変更する こ とができる様になる。 また、 実装されている R 1 3 (3ェンジンゃ0 5 ?ェンジンの中で、 実際に動作させ たいエンジンの個数を自 由に変更する こ とができ、 きめの 細かい省電力の機能をアプリ ケ一ショ ン レベルで実装する こ とが可能となる。  As described above, in the multi-processor system using the round robin arbitration method according to the embodiment of the present invention, an arbitration circuit corresponding to the maximum number of processors is previously provided for each processor. The number of RISC engines and DSP engines can be changed freely by installing them in the engine. In addition, the number of engines to be actually operated can be freely changed among the mounted R13 (3 engines ゃ 0 5? Engines), and a fine-grained power saving function can be applied to the application. It can be implemented at one session level.

Claims

請求の範囲 The scope of the claims
1 . 共用バスと、 前記共用バスに接続された複数のプロセ ッサと、 前記複数のプロセ ッサから発行される前記共用 バスへのバス使用要求のラ ウ ン ド ロ ビンによるァ一ビ ト レーシヨ ンを行う アー ビ ト レーショ ン機構とからなるマ ルチプロセッサ · システムの設計をハー ドウエア記述言 語によって行う方法であって、 前記ハー ドウェア記述言 語による ソーステキス トは、 所定の最大プロセッサ数ま でサポー トする前記アービ ト レーショ ン機構の記述と、 前記プロセッサのイ ンスタ ンスを、 前記最大プロセッサ 数以下で任意に設定された数まで生成し、 前記マルチプ 口セッサ · システムに前記複数のプロセッサを実装する 記述を含むこ とを特徴とするマルチプロセッサ · システ ムの設計方法。  1. A shared bus, a plurality of processors connected to the shared bus, and round robin of a bus use request to the shared bus issued from the plurality of processors. A method of designing a multiprocessor system comprising an arbitration mechanism for performing a ration by a hardware description language, wherein the source text in the hardware description language is a predetermined maximum number of processors. A description of the arbitration mechanism to be supported and an instance of the processor are generated up to an arbitrarily set number equal to or less than the maximum number of processors, and the plurality of processors are provided to the multi-processor system. A method for designing a multiprocessor system that includes a description that implements a multiprocessor system.
2 . 前記複数のプロセッサは複数の異なるプロセッサか ら なる こ とを特徴とする請求項 1 に記載のマルチプロセッ サ · システムの設計方法。 2. The method for designing a multiprocessor system according to claim 1, wherein the plurality of processors are composed of a plurality of different processors.
3 . 前記複数のプロセ ッサには、 その動作を停止する命令 が実装されている こ とを特徴とする請求項 1 に記載のマ ルチプロセッサ · システムの設計方法。  3. The method for designing a multiprocessor system according to claim 1, wherein an instruction to stop the operation is implemented in the plurality of processors.
4 . 前記複数のプロセッサは、 複数のバスを共用する こ と を特徴とする請求項 1 に記載のマルチプロセッサ · シス テムの設計方法。  4. The method for designing a multiprocessor system according to claim 1, wherein the plurality of processors share a plurality of buses.
5 . 前記複数のプロセッサの各々 に、 アービ ト レーショ ン 機構が実装されている こ とを特徴とする請求項 1 に記載 のマルチプロセッサ · システムの設計方法。  5. The method of designing a multiprocessor system according to claim 1, wherein an arbitration mechanism is mounted on each of the plurality of processors.
6 . 前記ハー ドウェア記述言語は、 V H D Lである こ とを 特徴とする請求項 1 に記載のマルチプロセッサ · システ ムの設計方法。 6. The multiprocessor system according to claim 1, wherein the hardware description language is VHDL. How to design the system.
. 共用バス と、 前記共用バスに接続された複数のプロセ ッサと、 前記複数のプロセッサか ら発行される前記共用 バスへのバス使用要求のラウ ン ド ロ ピンによるァー ビ ト レ一シヨ ンを行う アービ ト レーショ ン機構とからなるマ ルチプロセッサ · システムであって、 前記複数のプロセ ッサの各々 に、 その動作を停止する命令が実装されてい る こ とを特徴とするマルチプロセッサ · システム。 A shared bus, a plurality of processors connected to the shared bus, and an arbitration by a round robin of a bus use request to the shared bus issued from the plurality of processors. A multiprocessor system comprising an arbitration mechanism for performing an operation, wherein an instruction to stop the operation is implemented in each of the plurality of processors. system.
. 共用バス と、 前記共用バスに接続された複数のプロセ ッサと、 前記複数のプロセッサから発行される前記共用 バスへのバス使用要求のラウン ド ロ ビンによるァ一 ビ ト レーショ ンを行う ァーピ ト レ一ショ ン機構とからな り 、 ハー ドウェア記述言語によって記述されたマルチプロセ ッサ · システムであって、 前記ハー ドウェア記述言語に よるソーステキス トは、 所定の最大プロセ ッサ数までサ ポー トする前記アービ ト レーショ ン機構の記述と、 前記 プロセッサのイ ンスタ ンスを、 前記最大プロセッサ数以 下で任意に設定された数まで生成し、 前記マルチプロセ ッサ · システムに前記複数のプロセッサを実装する記述 を含むこ とを特徵とするハー ドウェア記述言語によって 記述されたマルチプロセッサ · システム。 . A shared bus, a plurality of processors connected to the shared bus, and an arbiter for round-robining a bus use request to the shared bus issued from the plurality of processors by a round robin. A multi-processor system described in a hardware description language, the source text in the hardware description language supporting up to a predetermined maximum number of processors. A description of the arbitration mechanism to be ported, and an instance of the processor are generated up to an arbitrarily set number equal to or less than the maximum number of processors, and the plurality of processors are added to the multi-processor system. Multiprocessor system written in a hardware description language that includes a description that implements .
PCT/JP2001/004965 2001-06-12 2001-06-12 Mutiprocessor system, method for designing the same, and multiprocessor system described in hardware describing language WO2002101564A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2001/004965 WO2002101564A1 (en) 2001-06-12 2001-06-12 Mutiprocessor system, method for designing the same, and multiprocessor system described in hardware describing language

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2001/004965 WO2002101564A1 (en) 2001-06-12 2001-06-12 Mutiprocessor system, method for designing the same, and multiprocessor system described in hardware describing language

Publications (1)

Publication Number Publication Date
WO2002101564A1 true WO2002101564A1 (en) 2002-12-19

Family

ID=11737420

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2001/004965 WO2002101564A1 (en) 2001-06-12 2001-06-12 Mutiprocessor system, method for designing the same, and multiprocessor system described in hardware describing language

Country Status (1)

Country Link
WO (1) WO2002101564A1 (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07182172A (en) * 1993-11-05 1995-07-21 Microsoft Corp Method and system for control of connection of component
JPH09231253A (en) * 1996-02-26 1997-09-05 Fujitsu Ltd Verification data generating method for logic device
JP2000082019A (en) * 1998-09-07 2000-03-21 Hitachi Ltd Data transfer controller
JP2001160080A (en) * 1999-12-02 2001-06-12 Nec Corp Simulation method and device for system by object- oriented language and recording medium with its program recorded thereon

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07182172A (en) * 1993-11-05 1995-07-21 Microsoft Corp Method and system for control of connection of component
JPH09231253A (en) * 1996-02-26 1997-09-05 Fujitsu Ltd Verification data generating method for logic device
JP2000082019A (en) * 1998-09-07 2000-03-21 Hitachi Ltd Data transfer controller
JP2001160080A (en) * 1999-12-02 2001-06-12 Nec Corp Simulation method and device for system by object- oriented language and recording medium with its program recorded thereon

Similar Documents

Publication Publication Date Title
JP6969853B2 (en) Multi-core bus architecture with non-blocking high performance transaction credit system
JP3765586B2 (en) Multiprocessor computer system architecture.
US7523228B2 (en) Method for performing a direct memory access block move in a direct memory access device
US11204867B2 (en) PCIe controller with extensions to provide coherent memory mapping between accelerator memory and host memory
JP5787629B2 (en) Multi-processor system on chip for machine vision
US11803505B2 (en) Multicore bus architecture with wire reduction and physical congestion minimization via shared transaction channels
CN114756502A (en) On-chip atomic transaction engine
US8352656B2 (en) Handling atomic operations for a non-coherent device
JP2002140289A (en) Micro-controller dma operation with adjustable word size transfer and address array/increase
US20080022030A1 (en) Data processing system
JP2012038293A5 (en)
US20060036808A1 (en) Method and apparatus for redirection of operations between interfaces
US7996592B2 (en) Cross bar multipath resource controller system and method
US6738837B1 (en) Digital system with split transaction memory access
WO2002101564A1 (en) Mutiprocessor system, method for designing the same, and multiprocessor system described in hardware describing language
WO2001025941A1 (en) Multiprocessor computer systems with command fifo buffer at each target device
US12072824B2 (en) Multicore bus architecture with non-blocking high performance transaction credit system
JP4214521B2 (en) Information processing system and multiprocessor system
WO2011030498A1 (en) Data processing device and data processing method
WO2002101563A1 (en) Multiprocessor system and bus arbiter
WO2002101562A1 (en) Multiprocessor system and signal processor
Uchiyama et al. Chip Implementations
Reed A Prototype Implementation of a Split-transaction Bus with Enhanced Arbitration for System-on-chip Multiprocessors
JP2003330907A (en) Microcomputer system

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 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 NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA 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 ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

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

Ref country code: DE

Ref legal event code: 8642

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION UNDER RULE 69 EPC (EPO FORM 1205A DATED 17.03.2004)

NENP Non-entry into the national phase

Ref country code: JP

122 Ep: pct application non-entry in european phase