JP5416257B2 - Multi-core LSI - Google Patents

Description

  The present invention relates to a multi-core LSI in which a plurality of CPUs are mounted on the same LSI.

  In a multi-core LSI with multiple CPUs mounted on the same LSI, when debugging software that allows multiple CPUs to operate independently, a shared bus is caused by program runaway (access to unintended areas, etc.) When CPU hangs up, it is difficult to identify which CPU hangs up by which access, and software debugging becomes difficult.

  The case where a certain CPU runs away and hangs up the shared bus while other CPUs operate normally corresponds to the above case. In this case, due to the hang-up of the shared bus, not only the CPU to be debugged but also other normal CPUs cannot access and stop. For this reason, in multi-core LSIs, software debugging cannot be performed effectively even if the conventional debugging technique of single-core LSIs (LSIs equipped with one CPU) is used.

  The following (1) and (2) are known as debugging techniques in a single core LSI.

  (1) If the system controller monitors the shared bus and the access is not completed even after a predetermined time has elapsed (that is, if the CPU runs away), it is detected and a pseudo response signal is output to the shared bus. At the same time as the access of the CPU being accessed is terminated, an interrupt process is put into the CPU. Thereafter, by analyzing the operation of the CPU and confirming in which part of the program the interrupt processing is performed, it is specified where the CPU has runaway in the program (prior art 1).

  (2) A WDT (watchdog timer) is known as a function for detecting a timeout for a certain processing period in software processing. In this case, the time-out is detected by the WDT and the CPU is interrupted to specify where the CPU has runaway in the program (prior art 2).

  Note that Patent Document 1 is known as a prior art document for detecting a timeout.

JP 2001-167067 A

  When the above prior art 1 is extended to a multi-core LSI, how to output a request signal for interrupt processing to each CPU and how to identify which CPU has hung up However, there is currently no effective method.

  Also, when the above prior art 2 is used for a multi-core LSI, if the shared bus hangs up in the first place, even if it is detected by WDT and other normal CPUs try to perform interrupt processing, Unless the CPU releases the bus right, the normal CPU cannot execute the interrupt process.

  As described above, conventionally, even if a shared bus hang-up occurs in a multi-core LSI, it is impossible to specify which CPU and which access caused the hang-up, so the program development efficiency is not good. There was a problem.

  In addition, if a certain CPU runs away and hangs up the shared bus, other normal CPUs cannot be accessed and other normal CPUs are also stopped. Therefore, there is a problem that the operational stability of the LSI is not good. there were.

  The present invention has been made to solve the above-described problems. First, it provides a multi-core LSI capable of improving operational stability, and secondly, further improves the efficiency of program development. The purpose is to provide a multi-core LSI that can be improved.

In order to solve the above-described problem, a first aspect of the present invention provides a plurality of CPUs connected to a first shared bus, one or more modules connected to a second shared bus, and the first A shared bus control unit connected between the shared bus and the second shared bus for arbitrating access to the module by the plurality of CPUs, and an access request signal for the CPU from the accessed module A system controller that monitors whether or not a response signal is output, and the system controller is configured to receive a predetermined time after the access request signal is output from the shared bus control unit to the second shared bus. If the response signal is not output from the accessed module, a pseudo response signal is output to the first shared bus via the shared bus control unit. The causes terminate the access of the CPU in for其's different interrupt processes其s executable CPU and other CPU in the access, executes the different interrupt process其s It is possible to issue an interrupt notification for this purpose .

  According to the first aspect of the present invention, the system controller outputs a response signal from the access destination module until a predetermined time elapses after the access request signal is output from the shared bus control unit to the second shared bus. If not, a pseudo response signal is output to the first shared bus via the shared bus control unit, and the access of the CPU being accessed is terminated. As a result, even when a response signal is not output from the access destination module due to the occurrence of a bug or the like, it is possible to prevent the accessing CPU from occupying the shared bus for a long time and stop the operation of the multicore LSI. The stability of operation can be improved.

1 is a configuration diagram of a multi-core LSI according to a first embodiment. FIG. 2 is a schematic configuration diagram of a system controller 9 in FIG. 1. FIG. 3 is a schematic configuration diagram of a logic circuit of a part that outputs a request signal for non-maskable interrupt processing in the control unit 9 g of FIG. 2. It is a figure explaining the specification of the interrupt control registers 9d and 9e of FIG. It is a figure explaining the example of a setting data setting to the interrupt control registers 9d and 9e of FIG. It is a figure explaining the outline | summary of operation | movement at the time of normal of the conventional multi-core LSI. It is a figure explaining the outline | summary of operation | movement at the time of timeout occurrence (at the time of bug occurrence) of the conventional multi-core LSI. It is another figure explaining the outline | summary of operation | movement at the time of normal time and time-out occurrence of the conventional multi-core LSI. FIG. 6 is a diagram for explaining the operation of the multi-core LSI according to the first embodiment.

Embodiment 1 FIG.
<Overall configuration>
As shown in FIG. 1, the multi-core LSI 1 according to this embodiment includes a plurality of (for example, two) CPUs # 0 and # 1, and a shared bus control unit 3 that arbitrates accesses of the CPUs # 0 and # 1, An external bus that is an interface between the shared bus b1 to which these constituent elements # 0, # 1, and 3 are connected, one or more (eg, n) modules m1 to mn such as ROM and RAM, and the external bus gb The control unit 5, the interrupt controller 7 that causes the CPUs # 0 and # 1 to generate interrupt processing, the shared bus b2 to which the respective components m1 to mn, 3, and 5 are connected, and the shared bus b2 are monitored. And a system controller 9.

  Each of the shared buses b1 and b2 transmits data to an address bus to which an access destination address is transmitted, a command bus to which commands (for example, read, write, and response signals) are transmitted. And a CPU ID bus to which the IDs of the access source CPUs # 0 and # 1 are transmitted.

  Each of the CPUs # 0 and # 1 is a general one, and includes a debug function db, a primary cache L1, and various interrupt processing request signals from the system controller 9, NMI (non-maskable interrupt), It includes INT (maskable interrupt) and DBI (debug interrupt).

  The debug function db is a general debug function. For example, the CPU # 0 and # 1 execute program control, breakpoint control, CPU internal register display, and the CPU # in response to an external request signal. Functions necessary for debugging a program, such as a function of outputting the execution history of 0 and # 1 to the outside, are realized by communicating with an external device.

  The input signal NMI represents a request signal for non-maskable interrupt processing. The input signal DBI represents a request signal for debug interrupt processing (Debug Interrupt). The input signal INT represents a request signal for maskable interrupt processing. Each of the CPUs # 0 and # 1 executes various interrupt processes according to request signals input to the input units NMI, DBI, and INT.

  When the CPUs # 0 and # 1 access the external devices gd1 and gd2 connected to the modules m1 to mn or the external bus gb, as the access request signal, the address bus, command bus, and CPUID of the shared bus b1 are used. The address of the access destination, the read or write command, and the ID (CPUID) of the access source CPU # 0 or # 1 are output to the bus, respectively. Output the data.

  Each of the CPUs # 0 and # 1 starts access by outputting the access request signal to the shared bus b1, and ends the access when acquiring a response signal to the access request signal through the shared bus b1.

  The shared bus control unit 3 can also include a secondary cache L2. Hereinafter, the case where the secondary cache L2 is provided will be described.

  When the shared bus control unit 3 receives an access request signal from each CPU # 0 or # 1 through the shared bus b1, the shared bus control unit 3 accesses the secondary cache L2, and the data to be read is stored in the secondary cache L2. Make sure that If the access request signal command is read from the access source CPU # 0 or # 1, the stored data is output through the shared bus b1 and the access request signal is stored. When the command of the access request signal is a write, the response signal for the access request signal is written to the L2 cache and the response signal for the access request signal is output via the shared bus b1.

  Further, when the target data is not stored in the secondary cache, the shared bus control unit 3 outputs the access request signal received through the shared bus b1 to the shared bus b2.

  When shared bus control unit 3 receives a response signal and data to be read from each of modules m1 to mn or external bus control unit 5 from shared bus b2, it transmits the response signal and the data to be read to shared bus b1. Output to.

  When a pseudo response signal (to be described later) is input from the system controller 9 through the dedicated wiring 12, the shared bus control unit 3 outputs the pseudo response signal to the shared bus b1, and the CPU # 0 being accessed at that time Alternatively, # 1 is received and the access is forcibly terminated. The pseudo response signal is a response signal that the system controller 9 outputs instead when the access destination of the access request signal does not output a response signal.

  When each module m1 to mn receives an access request signal to itself through the shared bus b2, it outputs a response signal to the access request signal to the shared bus b2 and also outputs a response signal to the system controller 9 through the dedicated wiring 11. To do.

  The dedicated wiring 11 includes, for example, an OR circuit 11a, and the response signal output units of each of the modules m1 to mn and the external bus control unit 5 are connected to a plurality of input units of the OR circuit 11a. A response signal input section of the system controller 9 is connected to the output section of the circuit 11a by wiring. When the response signal is input to any of the plurality of input units, the OR circuit 11a outputs the response signal from the output unit.

  The external bus control unit 5 relays communication between the external devices gd1 and gd2 connected to the external bus gb and the CPUs # 0 and # 1n.

  When various interrupt processing request signals are input from the modules m1 to mn or an external device (not shown), the interrupt controller 7 receives the input signals NMI of the CPUs # 0 and # 1 via the system controller 9. , DBI, INT are output to cause each of the CPUs # 0, # 1 to execute various interrupt processes.

  The system controller 9 monitors an access request signal in the shared bus b2. The system controller 9 sends a response signal to the access request signal from the access destination of the access request signal to the shared bus b2 until a predetermined time elapses after the access request signal is output from the shared bus control unit 3 to the shared bus b2. Monitor whether or not is output.

  If the response signal is not output to the shared bus 2 until the predetermined time elapses, the system controller 9 causes a bug or the like when the predetermined time elapses (that is, when a timeout occurs). It is determined that the shared buses b1 and b2 are hung up, and the following processes (1), (2), and (3) are performed.

  That is, as a process (1), a pseudo response signal is output to the shared bus control unit 3 via, for example, the dedicated wiring 12, and the pseudo response signal is output from the shared bus control unit 3 to the shared bus b1 to be the access source CPU. # 0 or # 1 is acquired and the access is forcibly terminated.

  In the process (2), at least one of the CPU ID, the read or write command, and the address output by the accessing CPUs # 0 and # 1 at the time of the access is stored.

  In process (3), signals are output to the input signals MNI, DBI, and INT of the CPUs # 0 and # 1, and the CPUs # 0 and # 1 execute various interrupt processes. This makes it possible to estimate the location where the bug occurs.

  Further, when an end request signal is input from an external device, the system controller 9 outputs a pseudo response signal to the shared bus control unit 3, and the CPUs # 0 and # 0 that are being accessed even before the predetermined time elapses. 1 forcibly terminates the access.

<Configuration of system controller 9>
As shown in FIG. 2, the system controller 9 includes an address register 9a, a command register 9b, a CPUID register 9c, interrupt control registers 9d and 9e provided for each of the CPUs # 0 and # 1, a counter 9f, And a control unit 9g.

  The address register 9a is connected to the address bus q1 of the shared bus b2, the command register 9b is connected to the command bus q2 of the shared bus b2, and the CPUID register 9c is connected to the CPUID bus q3 of the shared bus b2. The registers 9d and 9e are connected to the data bus q4 of the shared bus b2.

  Each of the registers 9a, 9b, and 9c stores the address, command, and CPUID of the access request signal output from the shared bus control unit 3 to the shared bus b2 according to the control of the control unit 9f.

  The controller 9g monitors whether or not an access request signal command (read or write command) has been output to the command bus q2 of the shared bus b2. When the control unit 9g detects that the access request signal command is output to the command bus q2 of the shared bus b2, the control unit 9g determines that the access request signal is output from the shared bus control unit 3 to the shared bus b2, and counts In 9f, the timing of a predetermined time is started.

  Then, the control unit 9g determines whether or not a response signal has been input to the shared bus b2 from the access destination to the shared bus b2 through the dedicated wiring 11 until the counter 9f finishes counting the predetermined time. Whether or not a response signal to the access request signal is output is monitored.

  When the response signal is input to the control unit 9g through the dedicated wiring 11 before the counter 9f finishes counting the predetermined time, the response signal for the access request signal is output from the access destination to the shared bus b2. (I.e., no bug has occurred) and the counting of the predetermined time by the counter 9 is stopped.

  On the other hand, when the counter 9f finishes measuring a predetermined time before the response signal is input to the control unit 9g through the dedicated wiring 11 (that is, when a timeout occurs), a bug or the like occurs and the shared bus It is determined that b1 and b2 are hung up, and the following processes (1), (2), and (3) are performed.

  That is, as the process (1), the control unit 9g outputs, for example, a pseudo response signal to the shared bus control unit 3 via the dedicated wiring 12, and outputs the pseudo response signal from the shared bus control unit 3 to the shared bus b1. The CPUs # 0 and # 1 that are being accessed are acquired and the access is forcibly terminated.

  Further, as the process (2), the control unit 9g acquires the address of the access request signal, the read or write command, and the CPUID from the shared bus b2, and stores them in the registers 9a, 9b, and 9c, respectively. The stored address, command, and CPUID are useful for specifying which access of which CPU # 0, # 1 caused a bug or the like.

  Further, as the process (3), the control unit 9g applies to the CPUs # 0 and # 1 in accordance with the CPUID stored in the CPUID register 9c and the setting data stored in the interrupt control registers 9d and 9e in advance. Interrupt processing request signals NMI, DBI, and INT are output to cause the CPUs # 0 and # 1 to execute various interrupt processing.

  By changing the setting data stored in the interrupt control registers 9d and 9e, it is possible to change the type of interrupt processing to be executed by the CPUs # 0 and # 1 when a bug occurs. The setting data stored in the interrupt control registers 9d and 9e can be changed by, for example, externally requesting interrupt processing to the input units NMI, DBI, and INT of the CPU # 0 or # 1 via the interrupt controller 7 and the system controller 9. A signal is output, and the interrupt processing is performed by the CPU # 0 or # 1.

<Configuration of control unit 9b>
FIG. 3 is a diagram showing the logic circuit 10a of the part that controls the output of the interrupt request signal NMI of the CPUs # 0 and # 1 in the controller 9g.

  The logic circuit 10a includes an OR circuit 13a, AND circuits 14a and 15a, and an output circuit 16.

  The output circuit 16 has one input unit t1 and two output units t2 and t3. The CPUID (# 0 or # 1) in the CPUID register 9c is input to the input unit t1, and the CPUID is ## In the case of 0, “0” and “1” are output from the output units t2 and t3, respectively. On the other hand, when the CPU ID is # 1, “1” and “0” are output from the output units t2 and t3, respectively. Is output.

  The AND circuit 14a has one output unit t4 and three input units t5 to t7. The input unit t5 has a bit value (“0” or a bit value of a predetermined bit position (for example, b5) in the interrupt control register 9b. "1") is input, the output from the output unit t2 of the output circuit 16 is input to the input unit t6, and the output of the counter 9f is input to the input unit t7. The counter 9f outputs “0” until the counter 9f finishes measuring the predetermined time, and outputs “1” when the counter 9f finishes measuring the predetermined time (that is, when time-up occurs). .

  The AND circuit 15a has one output unit t8 and three input units t9 to t11. The input unit t9 has a bit value (“0” or “0” or a predetermined bit position (for example, b0) in the interrupt control register 9b). “1”) is input, the output from the output unit t3 of the output circuit 16 is input to the input unit t10, and the output of the counter 9f is input to the input unit t11.

  The OR circuit 13a has one output unit t12 and three input units t13 to t15, and the output of the output unit t12 is output to the input unit NMI of the CPU # 0, and the input units t13 and t14 have respective outputs. The outputs from the output units t4 and t8 of the AND circuits 14a and 15a are input, and a request signal for non-maskable (NMI) interrupt processing from the interrupt controller 7 is input to the input unit t15 (note that the NMI interrupt “1” is input when there is a processing request signal input, and “0” is input when there is no NMI interrupt processing request signal input).

  Similarly, the logic circuit 10b that controls the output of the interrupt processing request signal NMI of the CPU # 1 includes an OR circuit 13b, AND circuits 14b and 15b, and an output circuit 16.

  The AND circuit 14b includes one output unit t16 and three input units t17 to t19. The input unit t17 has a bit value (“0”) of a predetermined bit position (for example, b3) in the interrupt control register 9e. Or “1”) is input, the output of the output unit t3 of the output circuit 16 is input to the input unit t18, and the output of the counter 9f is input to the output unit t19.

  The AND circuit 15b includes one output unit t20 and three input units t21 to t23. The input unit t21 receives a bit value (“0”) of a predetermined bit position (for example, b0) in the interrupt control register 9e. Or “1”) is input, the output of the output unit t2 of the output circuit 16 is input to the output unit t22, and the output of the counter 9f is input to the output unit t23.

  The OR circuit 13b has one output unit t24 and three input units t25 to t27. The output of the output unit t24 is output to the interrupt processing request signal NMI of the CPU # 1, and each input unit t25, Outputs of the output units t16 and t20 of the AND circuits 14b and 15b are input to t26, respectively, and an output of a non-maskable (NMI) interrupt processing request signal from the interrupt controller 7 is input to the input unit t27.

The logic circuit of the part that controls the output of the interrupt processing request signal to the input part INT of CPU # 0 is omitted in the figure, but the following (1a) to (4a) are changed in the logic circuit 10a. It is configured by configuring other parts in the same manner.
(1a) The output of the output unit t12 of the OR circuit 13a is input to the interrupt processing request signal INT of the CPU # 0.
(2a) The bit value at the bit position b4 of the interrupt control register 9d is input to the input unit t5 of the AND circuit 14a.
(3a) The bit value at the bit position b1 of the interrupt control register 9d is input to the input unit t9 of the AND circuit 15a.
(4a) A request signal for maskable (INT) interrupt processing from the interrupt controller 7 is input to the input section t15 of the OR circuit 13a (in addition, if there is an input of a request signal for INT interrupt processing, “1 ”Is input, and“ 0 ”is input when no request signal for INT interrupt processing is input).

Although the logic circuit of the part that controls the output of the interrupt processing request signal to the interrupt processing request signal INT of the CPU # 1 is not shown, in the logic circuit 10b, the following (1b) to (4b) It is configured by changing and configuring the other parts in the same way.
(1b) The output of the output unit t24 of the OR circuit 13b is input to the interrupt processing request signal INT of the CPU # 1.
(2b) The bit value at the bit position b4 of the interrupt control register 9e is input to the input unit t17 of the AND circuit 14b.
(3b) The bit value at the bit position b1 of the interrupt control register 9e is input to the input part t21 of the AND circuit 15b.
(4b) A request signal for maskable (INT) interrupt processing from the interrupt controller 7 is input to the input section t27 of the OR circuit 13b.

The logic circuit of the part that controls the output of the interrupt signal request signal DBI of CPU # 0 is not shown, but in the logic circuit 10a, the following (1c) to (4c) are changed and other parts are changed. Are configured in the same manner.
(1c) The output of the output unit t12 of the OR circuit 13a is input to the interrupt request signal DBI of the CPU # 0.
(2c) The bit value at the bit position b5 of the interrupt control register 9d is input to the input unit t5 of the AND circuit 14a.
(3c) The bit value at the bit position b2 of the interrupt control register 9d is input to the input unit t9 of the AND circuit 15a.
(4c) A request signal for debug (DBI) interrupt processing from the interrupt controller 7 is input to the input unit t15 of the OR circuit 13a (Note that if there is an input of a request signal for DBI interrupt processing, “1 ”Is input, and“ 0 ”is input when there is no DBI interrupt processing request signal input).

Although the logic circuit of the part that controls the output to the request signal DBI of the interrupt processing of CPU # 1 is not shown, other parts are changed by changing the following (1d) to (4d) in the logic circuit 10b. Are configured in the same manner.
(1d) The output of the output part t24 of the OR circuit 13b is input to the interrupt processing request signal DBI of the CPU # 1.
(2d) The bit value at the bit position b5 of the interrupt control register 9e is input to the input unit t17 of the AND circuit 14b.
(3d) The bit value at the bit position b2 of the interrupt control register 9e is input to the input unit t21 of the AND circuit 15b.
(4d) The output of the request signal for the debug (DBI) interrupt processing from the interrupt controller 7 is input to the input unit t27 of the OR circuit 13b.

  Each AND circuit 14a, 15a, 14b, 15b outputs "1" from its output unit only when "1" is input to all its input units. Each of the OR circuits 13a and 13b outputs "1" from its output unit only when "1" is input to one or more of its input units. When “1” is input to the interrupt processing request signal NMI, each CPU # 0, # 1 executes non-maskable interrupt processing, and “1” is input to the interrupt processing request signal INT. Then, the maskable interrupt process is executed, and when “1” is input to the request signal DBI of the interrupt process, the debug interrupt process is executed.

  With this configuration, for example, the bit values of the bit positions b5 to b3 and b2 to b0 of the interrupt control register 9d are set to 001,000, and the bit values of the bit positions b5 to b3 and b2 to b0 of the interrupt control register 9e are set. When 00 is set to 001,000 (mode 1), the following operation is performed. That is, when the CPU ID register 9c stores # 0 as the CPU ID and the counter 9f finishes measuring the predetermined time and outputs “1”, “1” is output only from the output unit t24 of the OR circuit 13b, and the output is The CPU # 1 is input to the interrupt request signal NMI of the CPU # 1, and the non-maskable interrupt process is executed by the CPU # 1. On the other hand, when # 1 is stored as the CPUID in the CPUID register 9c and the counter 9f finishes measuring the predetermined time and outputs “1”, “1” is output only from the output part t12 of the OR circuit 13a, and its output Is input to the interrupt signal request signal NMI of the CPU # 0, and the non-maskable interrupt process is executed by the CPU # 0.

<Specifications of interrupt control registers 9d and 9e>
The interrupt control registers 9d and 9e are configured to store 32-bit data as shown in FIG. For example, 0 is fixedly set in the bit positions b31 to b6 of the interrupt control registers 9d and 9e. Each bit position b31 to b6 cannot be read (R) and written (W). In the bit positions b5 to b3, any bit string of 000,001,010,100 is stored. Each bit position b5 to b3 can be read (R) and written (W).

  The interrupt process executed when 000,001,010 or 100 is stored in bit positions b5 to b3 and the CPU that executes the interrupt process are as shown in the function column of FIG. The interrupt processing executed when 000,001,010 or 100 is stored in bit positions b2 to b0 and the CPU that executes the interrupt processing are also as shown in the function column of FIG.

<Example of setting data to interrupt control registers 9d and 9e>
FIG. 5 shows examples of bit values (setting data) set in the bit positions b5 to b3 and b2 to b0 of the interrupt control registers 9d and 9e, types of interrupt processing executed in the case of each setting, and The correspondence table | surface with CPU which performs an interruption process is shown.

  In mode 1, as described above, 001,000 is set in the bit positions b5 to b3 and b2 to b0 of the interrupt control register 9d, and 001 is set to the bit positions b5 to b3 and b2 to b0 of the interrupt control register 9e. , 000 is set. In this mode, when the counter 9f finishes counting the predetermined time, if it occurs during the access of the CPU # 0, a non-maskable interrupt request signal is output only to the CPU # 0 (the other CPU # 1 is interrupted). On the other hand, if it occurs during the access of CPU # 1, a non-maskable interrupt request signal is output only to CPU # 1 (an interrupt request signal is output to other CPU # 0) do not do.).

  In mode 2, 010,000 is set to the bit positions b5 to b3 and b2 to b0 of the interrupt control register 9d, and 010,000 is set to the bit positions b5 to b3 and b2 to b0 of the interrupt control register 9e. Is done. In this mode, when the counter 9f finishes counting the predetermined time, if it occurs during the access of the CPU # 0, a maskable interrupt request signal is output only to the CPU # 0 (the other CPU # 1 has an interrupt). On the other hand, if it occurs during the access of CPU # 1, a maskable interrupt request signal is output only to CPU # 1 (an interrupt request signal is output to other CPU # 0) do not do.).

  In mode 3, 100,000 is set to each bit position b5 to b3 and b2 to b0 of the interrupt control register 9d, and 100,000 is set to each bit position b5 to b3 and b2 to b0 of the interrupt control register 9e. Is done. In this mode, when the counter 9f finishes counting the predetermined time, if it occurs during the access of the CPU # 0, a debug interrupt request signal is output only to the CPU # 0 (the other CPU # 1 has an interrupt). On the other hand, if it occurs due to access by CPU # 1, a debug interrupt request signal is output to CPU # 1 (no interrupt request signal is output to other CPU # 0). .

  In mode 4, 001,001 is set in the bit positions b5-b3, b2-b0 of the interrupt control register 9d, and 001,001 is set in the bit positions b5-b3, b2-b0 of the interrupt control register 9e. Is done. In this mode, when the counter 9f finishes counting the predetermined time, a non-maskable interrupt request is issued to all the CPUs # 0 and # 1 regardless of whether the access is caused by the access from the CPU # 0 or the access from the CPU # 1. Output a signal.

  In mode 5, 010 and 010 are set to the bit positions b5 to b3 and b2 to b0 of the interrupt control register 9d, and 010 and 010 are set to the bit positions b5 to b3 and b2 to b0 of the interrupt control register 9e. Is done. In this mode, when the counter 9f finishes measuring the predetermined time, a maskable interrupt request is issued to all the CPUs # 0 and # 1 regardless of whether the access is caused by the access of the CPU # 0 or the access of the CPU # 0. Output a signal.

  In mode 6, 100 and 100 are set to the bit positions b5 to b3 and b2 to b0 of the interrupt control register 9d, and 100 and 100 are set to the bit positions b5 to b3 and b2 to b0 of the interrupt control register 9e. Is done. In this mode, when the counter 9f finishes counting the predetermined time, a debug interrupt request is issued to all the CPUs # 0 and # 1 regardless of whether the access is caused by the access from the CPU # 0 or the access from the CPU # 1. Output a signal.

  In mode 7, 001,010 is set to each bit position b5 to b3, b2 to b0 of the interrupt control register 9d, and 001,010 is set to each bit position b5 to b3, b2 to b0 of the interrupt control register 9e. Is done. In this mode, when the counter 9f finishes measuring the predetermined time, if it occurs due to the access of CPU # 0, a non-maskable interrupt request signal is output to CPU # 0 and a maskable interrupt is sent to the other CPU # 1. When a request signal is output and, on the other hand, the CPU # 1 generates an access, a non-maskable interrupt request signal is output to the CPU # 1, and a maskable interrupt request signal is output to the other CPU # 0.

  In mode 8, 100 and 010 are set to the bit positions b5 to b3 and b2 to b0 of the interrupt control register 9d, and 100 and 010 are set to the bit positions b5 to b3 and b2 to b0 of the interrupt control register 9e. Is done. In this mode, when the counter 9f finishes measuring the predetermined time, if it occurs due to the access of CPU # 0, a debug interrupt request signal is output to CPU # 0, and a maskable interrupt is sent to the other CPU # 1. When a request signal is output, on the other hand, when the CPU # 1 is accessed, the CPU # 1 also outputs a debug interrupt request signal, and outputs a maskable interrupt request signal to the other CPU # 0.

<Description of operation of multi-core LSI 1>
First, as a reference for understanding the features of the present invention, an outline of the operation of a conventional multi-core LSI having, for example, two CPUs # 0 and # 1 will be described with reference to FIGS.

  Here, a case will be described where processing A by CPU # 0, processing B by CPU # 1, processing C by CPU # 0, and processing D by CPU # 1 are performed in this order.

  The process A is a process of reading the data DA stored in the module at the address AA. The process B is a process for writing the data DB into the module at the address AB. Process C is a process of writing data DC to the module of address AC. The process D is a process for reading the data DD stored in the module at the address AD.

  First, the normal operation will be described with reference to FIG. First, the process A is executed by the CPU # 0. That is, the CPU # 0 outputs # 0 as the CPUID, Read as the command (Read), and AA as the address (T1 in FIG. 6) as an access request signal to the shared bus. When the access request signal is acquired by the module at address AA (T2 in FIG. 6), the data DA to be read and the response signal r1 to the access request signal are output from the module to the shared bus (FIG. 6). T3), when the response signal r1 is acquired by the CPU # 0 together with the data DA, the process A ends, and the next process B is similarly executed by the CPU # 1. When the response signal r2 to the access request signal for the process B is output from the module at the address AB (T4 in FIG. 6), the process B is completed and the next process C is executed in the same manner. When the response signal r3 to the access request signal a3 is output, the process C is finished and the next process D is executed in the same manner (see FIG. 8A).

  In such a conventional multi-core LSI, as shown in FIG. 7 and FIG. 8B, for example, when the process B is executed by the CPU # 1, the response signal r2 to the access request signal at that time is a bug or the like. If it is not output from the access destination module for some reason, the process B cannot be completed, the next process C cannot be executed, and the operation stops. In this way, if a process including a bug or the like is executed and a response signal is not output from the access destination, the CPU (for example, # 1) that executed the process occupies the shared bus for a long time, and other CPUs that have no problem ( For example, # 0) cannot execute the next process, and the operation of the multi-core LSI stops.

  In the conventional multi-core LSI, when the operation is stopped as described above, since there are a plurality of CPUs, which CPU # 0, # 1 has stopped the operation as easily as in the single-core LSI ( That is, it is difficult to specify whether a bug or the like has occurred.

  Next, based on FIG. 1 and FIG. 9, the operation of the multi-core LSI 1 according to this embodiment will be described.

  As described above, the case where the process A by the CPU # 0, the process B by the CPU # 1, the process C by the CPU # 0, and the process D by the CPU # 1 are performed in this order will be described. The contents of each process A, B, C, D are the same as described above.

  First, the process A is executed by the CPU # 0. In other words, the CPU # 0 outputs # 0 as the CPU ID, read as the command, and AA as the address as an access request signal to the shared bus b1 (S1 in FIG. 9).

  The access request signal output to the shared bus b1 is acquired by the shared bus control unit 3 and output to the shared bus b2. The access request signal output to the shared bus b2 is acquired by the module (for example, m1) at the address AA, and the command (read) is acquired by the system controller 9. Then, the system controller 9 starts counting a predetermined time by the counter 9f by acquiring the above command (here, counting from 15 to 0) (S2 in FIG. 9).

  Before the counter 9f finishes counting the predetermined time, the response signal to the access request signal and the data DA to be read are output to the shared bus b2 from the module m1 at the address AA and to the system controller 9 through the dedicated wiring 11. When the response signal is output (S3 in FIG. 9), the system controller 9 to which the response signal is input determines that there is no hang-up of the shared buses b1 and b2 due to a bug or the like, and counts a predetermined time by the counter 9f. Is canceled (S4 in FIG. 9).

  The response signal and the data DA output from the module m1 at the address AA to the shared bus b2 are acquired by the shared bus control unit 3 and output to the shared bus b1, and are acquired by the accessing CPU # 0 to process A. Ends.

  Then, the next process B is executed by CPU # 1. That is, similarly to the process A, an access request signal is output from the CPU # 1 to the shared bus b1 (S5 in FIG. 9). The access request signal is acquired by the shared bus control unit 3 and output to the shared bus b2, and is acquired by the module (eg, m2) of the address AB, and the command (write) is acquired by the system controller 9. . The system controller 9 starts counting a predetermined time by the counter 9f by acquiring the above command (S6 in FIG. 9).

  Then, before the response signal to the access request signal and the data DA to be read are output to the shared bus b2 from the module m2 at the address AB and before the response signal is output to the system controller 9 through the dedicated wiring 11, the counter 9f When the predetermined time has been counted (S7 in FIG. 9), a signal to that effect (timeout signal) is output from the counter 9g (S8 in FIG. 9), and due to the output, the system controller 9 causes a bug or the like. It is determined that the shared buses b1 and b2 are hung up.

  Based on this determination, a pseudo response signal is output from the system controller 9 to the shared bus control unit 3 through, for example, the dedicated wiring 12 (S9 in FIG. 9), and the pseudo response signal is output from the shared bus control unit 3 to the common bus b1. Is obtained by the accessing CPU # 1, and the process B is forcibly terminated. Then, the next process C is executed by the CPU # 0 (S12 in FIG. 9).

  Also, by the above determination, the address (AB), command (write) and CPUID (# 1) of the access request signal are acquired from the shared bus b2 by the system controller 9, and each register 9a of the system controller 9 is obtained. , 9b, 9c (S10 in FIG. 9).

  Then, according to the CPUID stored in the CPUID register 9c and the setting data stored in the interrupt control registers 9d and 9e in advance by the system controller 9, NMI, DBI which are interrupt input signals of the CPUs # 0 and # 1 , INT, an interrupt processing request signal is output (S11 in FIG. 9). Then, various interrupt processes are executed on the CPUs # 0 and # 1 by this interrupt request signal. Similarly, the following processes C and D are sequentially executed.

  As described above, in the multi-core LSI 1 according to this embodiment, the access request module receives the access request from the access-destination module until a predetermined time elapses after the access request signal is output to the shared bus b2, as compared with the conventional multi-core LSI. When a response signal to the signal is not output, a pseudo response signal is output from the system controller 9, and the access of the CPUs # 0 and # 1 being accessed is forcibly terminated by the pseudo response signal, and the next processing is performed. Since it is executed, it is possible to prevent the operation of the multi-core LSI 1 from stopping.

  In addition to the pseudo response signal, various interrupt processing request signals are output from the system controller 9 to the CPUs # 0 and # 1, so that the execution locations of the interrupt processing by the CPUs # 0 and # 1 are confirmed. Thus, when the shared buses b1 and b2 hang up due to the occurrence of a bug or the like, it is possible to specify which access of which CPU # 0 and # 1 caused the hangup.

<Main effects>
According to the multi-core LSI 1 configured as described above, the system controller 9 allows the access destination modules m1 to mn until a predetermined time elapses after the access request signal is output from the shared bus control unit 3 to the shared bus b2. Alternatively, if no response signal is output from the external bus control unit 9, a pseudo response signal is output to the shared bus b1 via the shared bus control unit 3, and the access of the CPU # 0 or # 1 being accessed is terminated. . As a result, even when a response signal is not output from the access destination module due to the occurrence of a bug or the like, the accessing CPU # 0 or # 1 occupies the shared buses b1 and b2 for a long time and the operation of the multicore LSI 1 is stopped Can be prevented, and the operation stability of the multi-core LSI can be improved.

  Further, the system controller 9 does not output a response signal from the access destination modules m1 to mn or the external bus control unit 9 until a predetermined time elapses after the access request signal is output from the shared bus control unit 3 to the shared bus b2. In this case, the CPU # 0 or # 1 that is being accessed is further caused to execute an interrupt process. As a result, by checking the execution location of the interrupt processing by the CPU # 0 or # 1, when a bug or the like occurs and the shared bus b1 or b2 hangs up, which CPU # 0 or # 1 It is possible to identify which access caused a bug and improve program development efficiency.

  Further, the system controller 9 causes the accessing CPU # 0 or # 1 to execute non-maskable interrupt processing, maskable interrupt processing, or debug interrupt processing as the interrupt processing. Thereby, the priority of an interruption process can be set according to the kind of interruption process.

  Further, the system controller 9 does not output a response signal from the access destination modules m1 to mn or the external bus control unit 9 until a predetermined time elapses after the access request signal is output from the shared bus control unit 3 to the shared bus b2. In this case, all CPUs # 0 and # 1 are caused to execute an interrupt process. As a result, by checking not only the CPU in which the bug etc. has occurred but also the execution location of the interrupt processing by a normal CPU, when the bug etc. occurs and the shared buses b1, b2 hang up, which CPU # It is possible to more easily identify which access of 0 and # 1 caused a bug and the like, and improve program development efficiency.

  In the system controller 9, as the above-described interrupt processing, the CPU # 0 or # 1 that is being accessed is caused to execute non-maskable interrupt processing, and the other CPU # 1 or # 0 is caused to execute maskable interrupt processing. Can be set as follows. As a result, the priority of interrupt processing can be changed depending on whether the CPU has a bug or the like or is a normal CPU.

  Further, in the system controller 9, as the above-described interrupt processing, the CPU # 0 or # 1 being accessed executes debug interrupt processing, and the other CPU # 1 or # 0 executes maskable interrupt processing. I can do it. As a result, the priority of interrupt processing can be changed depending on whether the CPU has a bug or the like or is a normal CPU.

  In the system controller 9, no response signal is output from the access destination modules m 1 to mn or the external bus control unit 5 until a predetermined time elapses after the access request signal is output from the shared bus control unit 3 to the shared bus b 2. In this case, at least one of the CPU ID, the read / write command, and the address output by the accessing CPU # 0 or # 1 at the time of the access (in the description of operation, for example, the case where all three are stored is described). Saved). Thus, when a bug or the like occurs and the shared buses b1 and b2 hang up, it is further determined which access of which CPU # 0 and # 1 caused the bug or the like by the stored CPUID, command or address. It can be easily identified and program development efficiency can be improved.

  When the system controller 9 receives an end request signal from a predetermined external device, the system controller 9 sends a pseudo response signal to the shared bus b1 via the shared bus control unit 3 even before the predetermined time by the counter 9f elapses. The access is terminated by the CPU # 0 or # 1 being accessed. Thus, the access of the CPU # 0 or # 1 being accessed can be forcibly terminated even by the end request signal from the predetermined external device even before the predetermined time has elapsed.

Embodiment 2. FIG.
The above-described multi-core LSI configuration is effective even when the shared buses b1 and b2 are packet transaction or split transaction bus configurations.

  In these bus configurations, for example, when CPU # 0 accesses a memory or the like via the shared bus b1, when issuing an access command to the memory, the bus right of the shared bus b1 is secured and the access command is issued. Then, the bus right of the shared bus b1 is once released. Therefore, the other CPU # 1 can access the shared bus b1 after the bus right is released.

  In this case, even if the memory access to the CPU # 0 is an illegal address access and the shared bus b1 or b2 hangs up, the CPU # 1 accesses the shared buses b1 and b2. It is possible to However, even in such a case, for example, in the case of an SMP (Symmetric Multi Processing) configuration, the processing of CPU # 0 is not completed because CPU # 0 is stopped waiting for a response from the memory. This also has an effect on the processing to be executed.

  When the system controller 9 issues a pseudo response signal to the memory access by the CPU # 0, the CPU # 0 recovers from the stopped state, and the CPU # 0 reissues the memory access by designating a correct address. This makes it possible to maintain system stability as a whole multi-core LSI. In addition, since it is found from the stored CPUID, command, or address that such illegal memory accesses frequently occur, it is easier to determine which CPU # 0, # 1 caused a bug or the like. It can be identified and program development efficiency can be improved.

  The present invention can be used in a multi-core LSI in which a plurality of CPUs are mounted on the same LSI, and is effective not only during debugging by a debugger but also during normal operation.

  1 multi-core LSI, 3 shared bus control unit, 5 external bus control unit, 7 interrupt controller, 9 system controller, 9a address register, 9b command register, 9c CPUID register, 9d, 9e interrupt control register, 9f counter, 9g control unit, 10a Logic circuit for controlling the output of a request signal for interrupt processing to the input unit NMI of CPU # 0, 10b Logic for the portion controlling the output of a request signal for interrupt processing to the input unit NMI of CPU # 1 Circuit, 11, 12 dedicated wiring, 13a, 13b OR circuit, 14a, 14b, 15a, 15b AND circuit, # 0, # 1 CPU, b1, b2 shared bus, gb external bus, m1-mn module, L1 primary cache L2 secondary cache, q1 address bus, q2 command bus, 3 data bus, q4 CPUID bus.

Claims (4)

A plurality of CPUs connected to the first shared bus;
One or more modules connected to the second shared bus;
A shared bus control unit that is connected between the first shared bus and the second shared bus and arbitrates access to the modules of the plurality of CPUs;
A system controller that monitors whether a response signal to the CPU access request signal is output from the access destination module;
The system controller, when the response signal is not output from the access destination module until a predetermined time has elapsed after the access request signal is output from the shared bus control unit to the second shared bus, The accessing CPU that outputs a pseudo response signal to the first shared bus via the shared bus control unit, terminates the access of the CPU being accessed, and can execute different interrupt processing. And a multi-core LSI, each of which can issue an interrupt notification for executing the different interrupt processing .   The multi-core LSI according to claim 1, wherein the system controller causes the accessing CPU to execute a non-maskable interrupt process, a maskable interrupt process, or a debug interrupt process as the interrupt process.   3. The system controller according to claim 2, wherein the system controller causes the accessing CPU to execute a debug interrupt process and causes the other CPUs to execute a maskable interrupt process as the interrupt process. Multi-core LSI.   The system controller may further include a case where the response signal is not output from the access destination module until a predetermined time elapses after the access request signal is output from the shared bus control unit to the second shared bus. 4. The storage device according to claim 1, wherein at least one of a CPU ID, a read / write command, and an address output by the accessing CPU at the time of the access is stored. Multi-core LSI.

Images