Patent US8307116B2

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Active provider: Google · gemini-2.5-flash

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

✓ Generated

Defensive Disclosure: Scalable Bus-Based On-Chip Interconnection Networks (US8307116B2)

This defensive disclosure outlines derivative variations of the scalable bus-based on-chip interconnection networks described in US8307116B2. The aim is to preemptively establish prior art for potential incremental improvements, rendering them obvious or non-novel to a Person Having Ordinary Skill In The Art (POSITA) in semiconductor design and on-chip networks. The core inventive concept across claims 1, 8, and 14 revolves around a multinodal on-chip array with physical communication channels arranged in horizontal and vertical rows, where the number of channel rows equals the number of nodes in that row, supporting data routing from a first node to multiple destination nodes, and achieving any-to-any communication within a maximum of two hops.

Derivative Variations

1. Material & Component Substitution

Derivative 1.1: Optical Interconnect-Based On-Chip Network

  • Enabling Description: The physical communication channels (as described in claim 1 and 8) are implemented using on-chip optical waveguides composed of silicon nitride (SiN) or silicon-on-insulator (SOI) waveguides. Data routing between nodes utilizes wavelength-division multiplexing (WDM) to support multiple logical channels over a single physical waveguide. Each node's router (118) is augmented with an optical-electrical-optical (OEO) conversion interface, comprising microring resonators for wavelength-selective routing and silicon photonic modulators/detectors. Long-distance shared channels (405, 507, 509) and point-to-point channels (403) are realized with low-loss optical waveguides, potentially integrating active elements like semiconductor optical amplifiers for signal regeneration over large arrays (e.g., 256 nodes or more). The routing logic, still operating on a maximum of two hops, directs optical packets by assigning specific wavelengths or time slots, managed by the OEO interfaces at each node.
  • Claim Basis: This derivative builds upon the "physical communication channels" of claims 1, 8, and 14 by specifying optical materials and components, and adapting the routing mechanism to optical signaling while retaining the multinodal array, row-channel equality, multi-destination routing, and two-hop maximum.
graph TD
    A[Node 1 (OEO Interface)] -- WDM Channel 1 (λ1) --> B{Optical Router}
    A -- WDM Channel 1 (λ2) --> B
    B -- Optical Waveguide --> C[Node 2 (OEO Interface)]
    B -- Optical Waveguide --> D[Node 3 (OEO Interface)]
    subgraph On-Chip Network
        B
        C
        D
    end

Derivative 1.2: Carbon Nanotube (CNT) Interconnects with Memristor-Based Routing

  • Enabling Description: The physical communication channels (117, 801, 805, 807, 809, 811) are fabricated using arrays of single-walled carbon nanotubes (SWCNTs) offering superior electrical conductivity and thermal properties compared to conventional copper interconnects. The routing devices (118) at each node are realized using hybrid CMOS-memristor crossbar switches. Memristor arrays enable highly compact, non-volatile, and reconfigurable crossbar routing matrices with lower static power consumption. The routing device (118) identifies destination nodes (607(2), 607(3)) and configures memristor switch settings to establish direct paths or shared bus connections, fulfilling the "first node to two or more other destination nodes" requirement. The non-volatile nature of memristors could also store routing tables during low-power states. The two-hop maximum is maintained by dynamically reconfiguring memristor crossbars to bypass intermediate nodes.
  • Claim Basis: This derivative redefines the "physical communication channels" and "routing device" elements of claims 1, 8, and 14, using advanced materials (CNTs) and switching components (memristors) while preserving the fundamental network topology and routing characteristics.
graph TD
    A[Node 1 (CNT Interface)] -- CNT Interconnects --> R1{Memristor Router 118}
    R1 -- CNT Interconnects --> B[Node 2 (CNT Interface)]
    R1 -- CNT Interconnects --> C[Node 3 (CNT Interface)]
    subgraph Multinodal Array
        A
        B
        C
        R1
    end

Derivative 1.3: Heterogeneous Processing Nodes with Specialized Accelerators

  • Enabling Description: Each processing node (104) in the multinodal array (102) is not homogeneous but comprises a heterogeneous mix of compute units optimized for specific tasks. For example, some nodes may include custom Tensor Processing Units (TPUs) for AI inference, others Digital Signal Processors (DSPs) (as suggested in the parent patent, detailed description of node 104 configurations), and others general-purpose CPU cores. The core/node controller (116) intelligently dispatches data and tasks, leveraging the network's two-hop maximum to efficiently route data 202 from any source accelerator to any destination accelerator, potentially involving multiple destinations via shared communication channels (405). This enables flexible and high-performance processing of complex workloads. The routing device (118) within each node is aware of the functional capabilities of its local subnodes (301) and other nodes, routing based on data type and required processing capabilities.
  • Claim Basis: This elaborates on the "plurality of nodes" of claims 1, 8, and 14, specifying their internal composition and extending the "processing arrangement" concept to include specialized hardware accelerators, while maintaining the network's two-hop routing and multi-destination capabilities.
classDiagram
    class Node {
        +NodeID
        +Router 118
        +Core/Node Controller 116
        +Resource Pool
    }
    class ResourcePool {
        +CPU_Core
        +GPU_Slice
        +AI_Accelerator
        +DSP_Unit
    }
    Node "1" *-- "1" ResourcePool : contains
    Node "1" -- "N" Node : Connected by channels

2. Operational Parameter Expansion

Derivative 2.1: Wafer-Scale Integrated (WSI) On-Chip Network

  • Enabling Description: The multinodal array (102) is implemented on a full semiconductor wafer, integrating hundreds to thousands of processing nodes (104) on a single substrate. The physical communication channels (303) extend across this large-scale array, maintaining the horizontal and vertical row structure where the number of channel rows equals the number of nodes in that respective row. Routing devices (118) are optimized for ultra-low latency and high-throughput communication between distant nodes on the wafer, ensuring the "maximum of two hops" criterion is met even for worst-case node-to-node communication. This involves longer physical channels (403) and potentially multi-level signaling to overcome signal degradation across greater distances.
  • Claim Basis: This derivative expands the "multinodal array" and "plurality of nodes" of claims 1, 8, and 14 to an extreme physical scale (wafer-scale integration), requiring adaptations in channel implementation to preserve the two-hop routing and multi-destination features.
graph TD
    A[Node 1] --- C1(Horizontal Channel Row) --- B[Node 2]
    A --- C2(Vertical Channel Row) --- E[Node N]
    B --- C3(Vertical Channel Row) --- F[Node N+1]
    subgraph Wafer-Scale Array (Hundreds to Thousands of Nodes)
        A
        B
        E
        F
        C1
        C2
        C3
    end

Derivative 2.2: Cryogenic On-Chip Network for Quantum Processors

  • Enabling Description: The entire multinodal on-chip network (100), including processing nodes (104), routing devices (118), and communication channels (117), operates at cryogenic temperatures (e.g., milliKelvin range) suitable for interfacing with superconducting quantum processors or cryo-CMOS control electronics. The physical communication channels are designed with superconducting interconnects (e.g., niobium alloys) to minimize thermal noise and achieve near-zero resistance for high-fidelity data transfer. Routing logic is adapted to handle quantum state information or classical control signals for quantum bits, maintaining the two-hop maximum for rapid state transfer or measurement readouts across the array. The multi-destination routing is crucial for fan-out of control signals to multiple qubits.
  • Claim Basis: This derivative specifies an extreme operational temperature and material choice for the "multinodal array," "nodes," and "physical communication channels" of claims 1, 8, and 14, while preserving the core architectural and routing principles in a specialized environment.
stateDiagram-v2
    state "Cryogenic Environment (mK)" as CryoEnv {
        Node_QC : Quantum Control Node
        Router_SC : Superconducting Router
        Channel_SJ : Superconducting Jct. Channel
        Node_QC --> Router_SC
        Router_SC --> Channel_SJ
        Channel_SJ --> Node_QC_Remote : 2-Hop Max
    }

Derivative 2.3: Dynamically Reconfigurable Channel Bandwidth

  • Enabling Description: The physical communication channels (117, 801) are equipped with dynamic bandwidth allocation capabilities. Each channel can be electronically reconfigured to present different logical bandwidths depending on traffic demands. This involves mechanisms like programmable impedance matching networks or dynamic grouping of parallel wires (e.g., split subchannels 809, 811) for flexible bandwidth provisioning. For instance, a single physical channel might split into multiple lower-bandwidth subchannels (as described in FIG. 8c) or coalesce into a single high-bandwidth channel on demand. The routing device (118) and core/node controller (116) monitor network congestion and latency, dynamically adjusting channel bandwidths (e.g., doubling the bandwidth for a critical path) to optimize data flow and ensure the two-hop maximum latency for high-priority data packets 409, 501.
  • Claim Basis: This extends the "physical communication channels" of claims 1, 8, and 14 by adding dynamic reconfigurability to their bandwidth, enhancing their ability to efficiently route data, including to "two or more other destination nodes" (claim 1) and supporting the method of "routing the retrieved data" (claim 8) under varying load conditions.
flowchart TD
    Start(Monitor Traffic) --> Congestion?
    Congestion? -- Yes --> Reconfigure(Adjust Channel Bandwidth)
    Reconfigure --> Optimize(Optimize Data Flow)
    Congestion? -- No --> Maintain(Maintain Current Bandwidth)
    Optimize --> End(Achieve 2-Hop Max)
    Maintain --> End

3. Cross-Domain Application

Derivative 3.1: Automotive Advanced Driver-Assistance Systems (ADAS) Processor

  • Enabling Description: The multinodal on-chip network is deployed within a System-on-Chip (SoC) for autonomous driving and ADAS applications. The plurality of nodes (104) includes specialized processing units for sensor fusion (Lidar, Radar, Camera), path planning, and real-time control (e.g., drive-by-wire). The two-hop maximum routing guarantees extremely low latency for safety-critical data paths, such as routing processed sensor data from an image processing node to a path planning node, and then to an actuator control node. Shared communication channels (405) are used for broadcasting critical environmental awareness data (e.g., detected obstacles, lane markings) to multiple decision-making and control nodes simultaneously, ensuring real-time responsiveness and redundancy in a vehicular environment.
  • Claim Basis: This applies the core system (claim 1), method (claim 8), and computer-accessible medium (claim 14) to a specific real-world domain (automotive ADAS), leveraging the described multinodal architecture and efficient routing for safety-critical tasks.
graph LR
    Sensor_Fusion(Sensor Fusion Node) --> Path_Planning(Path Planning Node)
    Path_Planning --> Actuator_Control(Actuator Control Node)
    Sensor_Fusion -- Shared Channel --> Perception(Perception Node)
    Perception -- Shared Channel --> Risk_Assessment(Risk Assessment Node)
    subgraph ADAS SoC
        Sensor_Fusion
        Path_Planning
        Actuator_Control
        Perception
        Risk_Assessment
    end

Derivative 3.2: High-Performance Computing (HPC) Node Interconnect

  • Enabling Description: The multinodal array (102) forms the basis of an HPC processor node, where individual nodes (104) are high-performance CPU cores or specialized accelerators (e.g., GPU components, FPGA fabrics). The on-chip network functions as a low-latency, high-bandwidth interconnect for cache-coherent data sharing and message passing between these cores. The "maximum of two hops" routing ensures efficient communication for tightly coupled parallel workloads, minimizing synchronization overheads. Shared communication channels (405) are utilized for broadcasting cache invalidation messages or global synchronization barriers across relevant subsets of cores, a common requirement in shared-memory parallel programming models. This replaces traditional off-chip interconnects for intra-node communication, boosting performance.
  • Claim Basis: This positions the multinodal network (claims 1, 8, 14) as a crucial component within a high-performance computing system, demonstrating its utility for inter-core communication with low latency and multi-destination capabilities.
graph TD
    C1(Core 1) -- Data/Msg --> Router1(Router)
    C2(Core 2) -- Data/Msg --> Router1
    Router1 -- Channel 1 --> C3(Core 3)
    Router1 -- Shared Channel --> C4(Core 4)
    C1 -- Cache Coherence --> C2
    subgraph HPC Node (Multi-core)
        C1
        C2
        C3
        C4
        Router1
    end

Derivative 3.3: Biomedical Implantable Device for Neural Processing

  • Enabling Description: The multinodal on-chip network is integrated into a low-power, implantable biomedical device, such as a neural interface processor. The nodes (104) are specialized units for acquiring neural signals (e.g., spike detection, local field potential analysis), filtering, feature extraction, and real-time stimulation control. The network's efficient routing (maximum two hops) allows for immediate response to neural events, routing detected activity from a sensor interface node to an analysis node and then to a stimulation delivery node. The capability to route data to "two or more other destination nodes" is used for distributing processed neural features to multiple analysis algorithms or for coordinating distributed stimulation patterns. The entire system is optimized for ultra-low power consumption to maximize battery life within the implantable form factor.
  • Claim Basis: This adaptation highlights the application of the disclosed on-chip network (claims 1, 8, 14) in a medical device, leveraging its efficiency for real-time biological data processing and control in a power-constrained environment.
sequenceDiagram
    participant NeuralSensor as Neural Sensor Node
    participant Filter as Filtering Node
    participant FeatureExtract as Feature Extraction Node
    participant StimControl as Stimulation Control Node

    NeuralSensor->>Filter: Raw Neural Data (Hop 1)
    Filter->>FeatureExtract: Filtered Data (Hop 1)
    FeatureExtract->>StimControl: Processed Features (Hop 1)
    FeatureExtract->>AnalysisLog: Log Features (Hop 1)
    StimControl->>NeuralSensor: Stimulation Command (Hop 1)

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Adaptive Routing Optimization

  • Enabling Description: An AI-driven "network orchestrator" (e.g., a dedicated processing node or a software agent running on the core/node controller 116) continuously monitors network traffic patterns, congestion, and latency across the multinodal array (102) using real-time data from IoT sensors embedded within routers (118) and channels. A deep reinforcement learning (DRL) agent within the orchestrator dynamically adjusts routing tables, reconfigures split subchannels (809, 811), and allocates bandwidth (as in derivative 2.3) to optimize data flow and consistently enforce the "maximum of two hops" for all critical communications, even under highly variable loads. This goes beyond static routing algorithms by adaptively learning and applying optimal routing policies based on current and predicted network states.
  • Claim Basis: This enhances the "routing device" and "processing arrangement" (claims 1, 8, 14) with AI capabilities for dynamic optimization, maintaining the core routing features like two-hop maximum and multi-destination routing under intelligent control.
graph TD
    A[IoT Sensors (Router Telemetry)] --> B{Network Orchestrator (DRL Agent)}
    B -- Control Signals --> C[Routing Devices 118]
    C -- Data Flow --> D[Communication Channels 117]
    D -- Feedback --> A
    subgraph On-Chip Network
        C
        D
    end
    B -- Optimize for --> E[2-Hop Max, Throughput]

Derivative 4.2: Blockchain-Enabled Secure On-Chip Communication

  • Enabling Description: The multinodal on-chip network is equipped with hardware-accelerated blockchain functionality for secure data routing and integrity verification. Each processing node (104) includes a lightweight hardware module that generates cryptographic hashes of data packets 607, 609 and verifies blockchain entries for routing decisions or data transfers. The "first physical communication channel configured to route data from a first node to two or more other destination nodes" (claim 1) is used to broadcast transaction records (e.g., data transfers, access requests) that are immutably recorded on a distributed on-chip ledger. This ensures tamper-proof communication paths and verifiable data provenance within the network, while maintaining the two-hop routing for rapid and secure data exchange in trusted execution environments.
  • Claim Basis: This integrates blockchain technology with the "routing data" method (claim 8) and the "multinodal array" (claim 1), ensuring secure and verifiable operations of the described on-chip network.
sequenceDiagram
    participant NodeA as Node A (Source)
    participant NodeB as Node B (Router)
    participant NodeC as Node C (Dest 1)
    participant NodeD as Node D (Dest 2)
    participant BlockchainLedger as On-Chip Blockchain Ledger

    NodeA->>NodeB: Data Packet (P1)
    NodeB->>NodeC: P1 (Route 1)
    NodeB->>NodeD: P1 (Route 2)
    NodeB->>BlockchainLedger: Record(P1_Route1_Hash)
    NodeB->>BlockchainLedger: Record(P1_Route2_Hash)
    NodeC->>NodeC: Verify P1 Hash
    NodeD->>NodeD: Verify P1 Hash

Derivative 4.3: Real-time QoS Management with IoT Sensors and Predictive Analytics

  • Enabling Description: The multinodal on-chip network incorporates an array of distributed IoT-like micro-sensors (e.g., temperature, voltage, current, error rate monitors) integrated directly into communication channels (303) and routers (118). The core/node controller (116) aggregates this real-time sensor data. Predictive analytics algorithms, possibly running on a dedicated node, forecast potential congestion hotspots, link failures, or performance degradation. Based on these predictions, the routing devices (118) implement proactive QoS adjustments, such as rerouting traffic, reserving bandwidth, or dynamically adjusting priority levels, to guarantee the "maximum of two hops" latency for latency-sensitive traffic (e.g., real-time control loops) and ensure reliable multi-destination data delivery.
  • Claim Basis: This enhances the "physical communication channels" and "routing device" (claims 1, 8, 14) with sensor integration and predictive intelligence for dynamic QoS management, ensuring the network's efficiency and reliability under varying conditions.
graph TD
    A[Channel Sensors] --> C(Data Aggregator)
    B[Router Sensors] --> C
    C --> D{Predictive Analytics Engine}
    D -- Forecast --> E[QoS Manager (Core/Node Controller 116)]
    E -- Adjust --> F[Routing Devices 118]
    F -- Control --> G[Communication Channels 117]
    subgraph On-Chip Network
        C
        D
        E
        F
        G
    end

5. The "Inverse" or Failure Mode

Derivative 5.1: Fault-Tolerant Reconfigurable Network with Graceful Degradation

  • Enabling Description: The multinodal array (102) includes redundant physical communication channels (303) and routing devices (118), which are typically in a "dark silicon" low-power state. Upon detection of a fault (e.g., broken channel, faulty router) via embedded self-test circuits or IoT sensors (as in Derivative 4.3), the network orchestrator (as in Derivative 4.1) dynamically reconfigures the routing topology to bypass the failed components, activating redundant channels or re-routing traffic through alternative paths. If a two-hop path is no longer possible for certain destinations due to extensive failures, the system gracefully degrades, allowing for a higher but bounded hop count (e.g., three or four hops) to maintain functionality rather than complete network failure. Multi-destination routing (405) can be re-established over degraded paths.
  • Claim Basis: This describes an enhanced "system for routing data" (claim 1) with fault tolerance and graceful degradation mechanisms, which directly impacts the "plurality of physical communication channels" and their ability to route data under fault conditions, potentially relaxing the "maximum of two hops" for severe failures while preserving connectivity.
stateDiagram-v2
    Full_Op: Full Operation (Max 2 Hops)
    Fault_Detected: Fault Detected
    Reconfig_Attempt: Reconfiguration Attempt
    Graceful_Deg: Graceful Degradation (3+ Hops)
    Critical_Fail: Critical Failure

    Full_Op --> Fault_Detected: Event: Channel/Router Fault
    Fault_Detected --> Reconfig_Attempt: Initiate Reconfig
    Reconfig_Attempt --> Full_Op: Success (2 Hops Maintained)
    Reconfig_Attempt --> Graceful_Deg: Partial Success (3+ Hops)
    Graceful_Deg --> Critical_Fail: Event: Further Failures

Derivative 5.2: Low-Power Sleep/Wake-Up Network

  • Enabling Description: The multinodal on-chip network implements granular power gating and dynamic voltage and frequency scaling (DVFS) for individual processing nodes (104), routing devices (118), and communication channels (117). In a "low-power" or "limited-functionality" mode, non-essential nodes and their associated communication channels are power-gated or operate at reduced voltage/frequency. The core/node controller (116) manages this, selectively waking up components as needed. For instance, only a subset of channels required for minimal intra-cluster communication might remain active, leading to a temporary increase in hop count for inter-cluster traffic but significantly reducing power consumption. When high-performance data routing (e.g., two-hop maximum, multi-destination) is required, the relevant network segments are rapidly powered up and reconfigured.
  • Claim Basis: This derivative adds a power management dimension to the "system for routing data" (claim 1) and "method for routing data" (claim 8), affecting how "physical communication channels" and "nodes" operate, particularly in non-peak performance states.
graph TD
    A[High Performance Mode] -- Lower Power Request --> B{Power Manager (Core/Node Controller)}
    B -- Power Down --> C[Inactive Nodes/Channels]
    B -- DVFS --> D[Active Nodes/Channels (Reduced Freq/Volt)]
    D -- Data Routing --> E[Limited Functionality (Higher Hops)]
    E -- Performance Request --> A
    C -- Wake Up --> A

Derivative 5.3: Debug and Diagnostic Mode with Limited Bandwidth

  • Enabling Description: The multinodal on-chip network includes a dedicated debug and diagnostic mode that is activated during testing or post-deployment analysis. In this mode, a portion of the physical communication channels (303) or dedicated sideband channels is repurposed for transmitting diagnostic data (e.g., internal router states, buffer occupancies, error logs) from each node (104) to a central debug unit, even if the primary data paths are experiencing issues. This diagnostic traffic operates at a "limited-functionality" bandwidth and might involve a higher hop count for data gathering, but ensures observability. The primary data routing capabilities (e.g., multi-destination, two-hop maximum) are temporarily suspended or operate in a degraded state to prioritize diagnostic information flow.
  • Claim Basis: This focuses on a specialized operational mode of the "multinodal on-chip network" (claims 1, 8, 14), where the behavior of "physical communication channels" and "routing devices" is altered to prioritize diagnostic data over high-performance application data, illustrating flexible operational parameters.
flowchart TD
    Start(Normal Operation) --> Switch(Switch to Diagnostic Mode)
    Switch --> Collect(Collect Diagnostic Data from Nodes)
    Collect --> RouteDebug(Route Diagnostic Data via Limited Bandwidth Channels)
    RouteDebug --> Analyze(Analyze at Debug Unit)
    Analyze -- Issues Resolved --> Resume(Resume Normal Operation)
    Switch --> Primary(Primary Data Routing Suspended/Degraded)

Combination Prior Art Scenarios

Here are three scenarios combining US8307116B2 with existing open-source standards:

  1. Combination with OpenCores Wishbone Bus:

    • Scenario: A multinodal on-chip network (US8307116B2, claims 1, 8, 14) where each processing node (104) internally utilizes the OpenCores Wishbone Bus standard for connecting its subnodes (301), local peripherals, and dedicated resources (106). The node's router (118) acts as a gateway, translating Wishbone transactions to the on-chip network's packet format for inter-node communication and ensuring the two-hop maximum for external communication. The Wishbone bus provides a standardized, flexible, and open-source interface for the internal architecture of each node, while the patent's network provides efficient inter-node communication.
    • Contribution to Obviousness: A POSITA would find it obvious to integrate a well-known, open-source on-chip bus standard like Wishbone within individual processing nodes to manage internal component communication. The patent describes nodes as having "logic for executing program or software instructions, as well as other functional blocks," and the Wishbone bus simply provides a standardized way to connect these internal blocks, without altering the novel aspects of the inter-node network or its two-hop routing.

  2. Combination with RISC-V Instruction Set Architecture (ISA):

    • Scenario: A multinodal on-chip network (US8307116B2, claims 1, 8, 14) where all processing nodes (104) are implemented as RISC-V-compliant CPU cores. The method of retrieving (claim 8) and routing data involves RISC-V instructions generated by applications (1122) and executed on these cores. The core/node controller (116) or node processor (617) leverages RISC-V's extensible nature to implement custom instructions for efficient packet injection and reception from the on-chip network, optimizing the data path for the two-hop maximum. The computer-accessible medium (claim 14) stores instructions compiled for the RISC-V architecture.
    • Contribution to Obviousness: Given the open-source nature and increasing adoption of RISC-V for custom silicon, a POSITA would find it obvious to implement the processing nodes (104) using RISC-V cores. This is a choice of processor architecture within the nodes and does not invent around the network topology, routing principles, or two-hop maximum of the patent. Integrating RISC-V implies adopting an existing, widely available, and documented standard for the processing elements, which directly aligns with the patent's descriptions of "microprocessor (μP), a microcontroller (μC), a digital signal processor (DSP)" as possible node configurations.

  3. Combination with OpenMP / MPI (Message Passing Interface) for Software Layer:

    • Scenario: A method (US8307116B2, claim 8) for routing data across a multinodal on-chip network that specifically supports parallel programming models using OpenMP (for shared-memory parallelism within a node or a cluster of nodes) and/or MPI (for distributed-memory parallelism across the entire array). The routing device (118) and core/node controller (116) are optimized to efficiently handle message-passing primitives (e.g., MPI_Send, MPI_Recv) and shared-memory synchronization (e.g., atomic operations, barriers) over the physical communication channels (117), including multi-destination calls (e.g., MPI_Bcast) that directly map to the patent's shared communication channels (405). The system is designed to minimize latency for these operations, ensuring that MPI/OpenMP communication within the on-chip network adheres to the "maximum of two hops."
    • Contribution to Obviousness: A POSITA familiar with parallel programming on multi-core architectures would readily understand the need for efficient software-level communication mechanisms like OpenMP and MPI. Integrating these standard programming models with an underlying on-chip network is a standard practice to enable application development. The patent provides the hardware infrastructure; adopting these software standards for data exchange is an obvious layer of implementation, especially when optimizing for low-latency features like the two-hop maximum already claimed.

This defensive disclosure aims to robustly cover foreseeable variations and integrations, thereby strengthening the public domain against future incremental patent assertions in the field of on-chip interconnection networks.

Generated 6/11/2026, 6:37:59 AM