Multi-core LSI Bus Hangup Detection via Pseudo Response

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In multi-core LSI systems, identifying which CPU causes a shared bus hangup is difficult, leading to poor program development efficiency and operational stability, as normal CPUs stop accessing due to a hung bus, and existing debugging techniques are ineffective in multi-core environments.

Innovation Solution

A multi-core LSI architecture with a shared bus controller and system controller that outputs a pseudo response signal to terminate CPU access and execute interrupt processing when a response signal is not received within a predetermined time, allowing identification of the faulty CPU and preventing system shutdown.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If a shared bus is used for multi-core LSI, then device complexity is reduced and resource sharing is improved, but when one CPU causes a bus hangup, all other CPUs are affected and cannot access the bus, leading to poor operational stability

Engineering Contradiction:
Improvebus architectureVSAvoidoperational stability
Core Design Contradiction:
Device complexityVSReliability

Solution Approach 1:

The patent introduces a system controller that segments the bus monitoring function from the CPUs themselves. The system controller independently monitors each CPU's access requests and response signals, allowing it to identify which specific CPU is causing a hangup without affecting the other CPUs. This segmentation enables the bus to remain functional for normal CPUs even when one CPU misbehaves.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system controller acts as an intermediary between the CPUs and the shared bus. It receives access request signals from CPUs, forwards them to modules, and monitors the response signals. When a hangup is detected, the system controller can output pseudo response signals to terminate the problematic CPU's access while allowing other CPUs to continue normal operations, thus mediating the conflict between faulty and normal CPUs.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Ease of manufacture

If conventional debugging techniques are used in multi-core LSI, then single CPU debugging is possible, but when a bus hangup occurs, it is impossible to identify which CPU caused the hangup, leading to poor program development efficiency

Engineering Contradiction:
Improvedebugging capabilityVSAvoidprogram development efficiency
Core Design Contradiction:
Ease of manufactureVSProductivity

Solution Approach 1:

The system controller implements a feedback mechanism by monitoring the relationship between access request signals from CPUs and response signals from modules. When no response signal is received within a predetermined time after an access request, the system controller identifies the specific CPU that caused the hangup and can output pseudo response signals to terminate that CPU's access. This feedback loop enables precise identification of faulty CPUs during debugging.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The system controller provides self-service debugging functionality by automatically detecting bus hangups, identifying the culprit CPU, and terminating its access without external intervention. The controller monitors its own system state and takes corrective action autonomously, improving debugging efficiency by eliminating the need for external debuggers to manually trace through multiple CPUs.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS8370556B2Multi-core data processor
Publication Date: 2013.02.05 RENESAS ELECTRONICS CORP
  • US8370556B2 patent drawing
  • US8370556B2 patent drawing
  • US8370556B2 patent drawing

AI summary

A multi-core LSI with improved stability of operation. The multi-core LSI includes a plurality of CPUs coupled to a first shared bus, one or more modules coupled to a second shared bus, a shared bus controller coupled between the first shared bus and the second shared bus for arbitrating access to the module(s) by the CPUs, and a system controller that monitors whether or not a response signal to an access request signal of the CPUs is output from a module to be accessed, wherein the system controller outputs a pseudo response signal to the first shared bus via the shared bus controller to terminate access by the CPU while accessing if the response signal is not output from the module to be accessed after the access request signal is output to the second shared bus from the shared bus controller and before a predetermined time elapses.