Message routing in integrated circuit chip devices

Abstract

Embodiments of this disclosure relate to message routing in an integrated circuit chip device. An integrated circuit chip device includes system circuitry; and monitoring circuitry for monitoring the system circuitry, the monitoring circuitry including units connected in a tree-based structure for routing communication through the integrated circuit chip device. The tree-based structure includes branches extending from a root unit, each branch including multiple units, each unit connected to a single unit above and a single unit below in the branch. Communication is routable between the root unit and a destination unit of a branch via intermediate units of that branch. Cross-links connect corresponding units of adjacent branches, and in response to an intermediate unit being deemed defective, each cross-link can be enabled to route communication between the root unit and a destination unit of one branch connected by the cross-link, via another branch connected by the cross-link, the intermediate unit and the destination unit being in the same branch.

Description

Technical Field

[0001] This disclosure relates to a communication protocol on an integrated circuit chip device, and more particularly to a mechanism for routing messages via circuitry of an integrated circuit chip device. Background Technology

[0002] In a System-on-Chip (SoC) device, multiple core devices of an embedded system are integrated onto a single chip. Traffic within the embedded system is typically transported via a bus between the core devices. It is well-known to incorporate monitoring functionality into the SoC to monitor traffic. For example, a monitoring unit can be associated with each core device to monitor traffic to and from that device. The monitoring unit generates data, such as collected trace data. Typically, the monitoring unit operates under the control of an off-chip analyzer and sends its data to that analyzer to detect any improper operation by the core devices.

[0003] The goal is to minimize the on-chip area of ​​a SoC dedicated to monitoring circuitry. An efficient configuration for the monitoring network is a tree-based topology. In this topology, a root cell connects the monitoring network to the chip's output port. Branches extend from the root cell through the SoC, each branch having multiple serially connected cells. Each cell can loop back through its branch to the root cell. This network is highly efficient for transmitting messages about monitoring circuitry around the SoC. However, in a tree-based topology, if a cell fails, the higher-connected cells in the failed cell's branch can no longer communicate with the root cell. In this scenario, the entire SoC may be discarded due to the failure of a single cell in the monitoring circuitry.

[0004] In a network of nodes with a tree-based topology, it is well known to prevent the failure of a single node by replicating the tree (in other words, by utilizing a second network of nodes with the same tree-based topology as the first network of nodes). If a node fails in the first network, a corresponding node in the second network can be used to replace the failed node. While effective, this redundant tree approach requires replicating an on-chip area dedicated to the network.

[0005] Therefore, there is a need for a SoC that is more robust to faults in the monitoring network while minimizing the on-chip area of ​​the SoC dedicated to the monitoring network. Summary of the Invention

[0006] According to a first aspect of this disclosure, an integrated circuit chip device is provided, including system circuit means; and monitoring circuit means for monitoring the system circuit means, the monitoring circuit means including units connected in a tree-based structure for routing communication through the integrated circuit chip device, the tree-based structure including branches extending from a root unit, each branch including a plurality of units, each unit being connected to a single unit above and a single unit below in the branch, whereby communication is routable between the root unit and a destination unit of the branch via intermediate units of the branch; and cross links connecting corresponding units of adjacent branches, each cross link being configured to: in response to an intermediate unit being deemed defective, be enabled to route communication between a destination unit in one branch of the branch connected to the root unit and the cross link via another branch connected to the cross link, the intermediate unit and the destination unit being in the same branch.

[0007] A defective intermediate cell may be adjacent to one of the cells connected by a cross link.

[0008] Each unit can be connected to the unit above it in the branch via a non-configurable link, and can also be connected to the unit below it in the branch via a non-configurable link.

[0009] Each cross-link can be configurable.

[0010] The cross link connecting the first unit of the first branch and the first unit of the second branch can be configured to route communication from the root unit to the first unit of the first branch, to the first unit of the second branch, and to the destination unit of the second branch; and to route communication from the destination unit of the second branch to the first unit of the second branch, to the first unit of the first branch, and to the root unit.

[0011] The first unit of the first branch can be configured to: in response to receiving a reconfiguration command from the root unit, reconfigure the first unit of the first branch to route communication received from the destination unit of the second branch through the cross link; and route communication received from the cross link to the root unit.

[0012] The first unit of the first branch can be configured to send a reconfiguration command to the first unit of the second branch on the cross link in response to receiving a reconfiguration command from the root unit.

[0013] The first unit of the second branch can be configured to: in response to receiving a reconfiguration command from the first unit of the first branch on the cross link, reconfigure the first unit of the second branch to route communication received from the cross link to the destination unit of the second branch, and route communication received from the destination unit via the cross link to the first unit of the first branch.

[0014] The cross-link can be configured to route communication from the root unit to the first unit of the second branch, to the first unit of the first branch, and to the destination unit of the first branch; and to route communication from the destination unit of the first branch to the first unit of the first branch, to the first unit of the second branch, and to the root unit.

[0015] The first unit of the second branch can be configured to: in response to receiving a reconfiguration command from the root unit, reconfigure the first unit of the second branch to route communication received by the destination unit of the first branch through the cross link, and route communication received from the cross link to the root unit.

[0016] The first unit of the second branch can be configured to send a reconfiguration command to the first unit of the first branch on the cross link in response to receiving a reconfiguration command from the root unit.

[0017] The first unit of the first branch can be configured to: in response to receiving a reconfiguration command from the first unit of the second branch on a cross link, reconfigure the first unit of the first branch to route communication received from the cross link to the destination unit of the first branch, and route communication received from the destination unit via the cross link to the first unit of the second branch.

[0018] Each unit may include a lower port and an upper port. The lower port has an input for receiving communication from the unit below and an output for sending communication to the unit below. The upper port has an input for sending communication to the unit above and an input for receiving communication from the unit above.

[0019] Each unit may include a multiplexer for selectively routing one of the lower port output and the upper port output to a cross link connected to that unit.

[0020] The multiplexer can be configured to select either the lower port output or the upper port output in response to a reconfiguration command received from the root unit.

[0021] Each unit may include a demultiplexer for selectively routing communication from a cross-link connected to the unit to one of the upper and lower port inputs.

[0022] The demultiplexer can be configured to select either the upper port input or the lower port input in response to a reconfiguration command received from the root unit.

[0023] Each unit may include a switch for selectively routing one of the communications received from the unit below and the communications received from the cross-link to the lower port input.

[0024] Each unit may include a gate connected to the lower port output to prevent communication from being sent to the lower unit in response to the lower unit being deemed defective.

[0025] The destination unit may include a local subsystem, and the destination unit may be configured to route communications to the local subsystem. Attached Figure Description

[0026] This disclosure will now be described by way of example with reference to the accompanying drawings. In the drawings:

[0027] Figure 1 This is a schematic diagram of an exemplary monitoring network on an integrated circuit chip device;

[0028] Figure 2 This is a schematic diagram of an exemplary monitoring network on an integrated circuit chip device;

[0029] Figure 3 This is a schematic diagram of an exemplary tree-based topology of a monitoring network on an integrated circuit chip device;

[0030] Figure 4 This is a flowchart illustrating the mechanism used to enable cross-links;

[0031] Figure 5 The illustration shows an example of a defective cell in a SoC;

[0032] Figure 6 This illustration shows another example of a defective cell in a SoC;

[0033] Figure 7 The diagram illustrates an example internal structure of a branch unit connected via a cross link;

[0034] Figure 8 The diagram illustrates a configuration for transmitting upstream and downstream messages via cross-links. Figure 7 Branching units;

[0035] Figure 9 This is a flowchart illustrating the mechanism used to identify a cell as a defective cell and bypass the defective cell in subsequent communications;

[0036] Figure 10 The illustration shows that Figure 3 An example of broadcasting event messages throughout the entire monitoring network;

[0037] Figure 11 The diagram illustrates the use of cross-links in... Figure 3 Examples of broadcast event messages throughout the monitoring network; and

[0038] Figure 12 The diagram illustrates the use of cross-links in... Figure 3Another example of broadcasting event messages throughout the entire monitoring network. Detailed Implementation

[0039] The following disclosure describes a monitoring network suitable for implementation on a SoC or MCM.

[0040] Figures 1 to 3 , Figures 5 to 8 ,as well as Figures 10 to 12 These are schematic diagrams of exemplary system architectures and components within those architectures. The structure is presented in the form of functional blocks. Some functional blocks that perform functions well-known in the art have been omitted in certain places in these diagrams. Figure 4 and Figure 9 These are flowcharts illustrating methods for routing messages by monitoring circuitry. Each flowchart depicts the order in which the methods of that flowchart can be executed. However, the flowcharts are not intended to constrain the described methods to be implemented in the depicted order. The steps of the method can be performed in alternative orders to those depicted in the flowcharts.

[0041] Figure 1 The illustration shows the general structure of an exemplary monitoring network for SoC 100. Monitoring circuitry 101 is arranged to monitor system circuitry 102. For example, for the purpose of detecting improper operation of core devices related to security or reliability issues. Figure 2 An exemplary system circuit including core devices and communication interfaces is illustrated. The core devices 201, 202, and 203 of the SoC are each connected to monitoring circuitry 101. Although Figure 2 The illustration shows three core devices, but any number of core devices can be appropriately integrated into a monitoring network. Exemplary core devices include a DSP (Digital Signal Processor), video processor, application processor or CPU (Central Processing Unit), graphics processor, system memory, bus, system interconnect, RTOS (Real-Time Operating System), software, data, custom circuitry, and a data engine. However, any component of the SoC is suitable as... Figure 2 The core devices on the chip are integrated into the monitoring network. These core devices can be emulators or simulators of other devices on the chip. For example, a core device can emulate a processor.

[0042] The monitoring circuitry may be able to manipulate and monitor the operation of the core device. The monitoring circuitry is connected to communication interface 204. Communication interface 204 can be configured to communicate with off-chip entities. For example, monitoring circuitry 101 can communicate with an off-chip analyzer via communication interface 204. Communication interface 204 can also be configured to communicate with other on-chip entities. For example, monitoring circuitry 101 can communicate with an on-chip analyzer via communication interface 204. Although... Figure 2The diagram illustrates a communication interface, but any number of communication interfaces can be integrated onto the SoC. The choice of communication interface to implement depends on the type of connectivity to be achieved. Exemplary communication interfaces include JTAG, parallel trace input / output, and a high-speed serial interface based on Aurora; and reuse of system interfaces such as USB, Ethernet, RS232, PCIe, and CAN.

[0043] Figure 3 An example SoC structure is illustrated. Routing units for routing messages through the SoC's monitoring circuitry are connected in a tree-based structure. In this example, ten routing units 301, 302, 303, 304, 305, 306, 307, 308, 309, and 310 are shown. Unit 301 is the root unit located at the bottom of the tree-based structure. The lower port 301a of the root unit 301 is connected to the communication interface 311. Different branches of the tree-based structure extend from the upper ports 301b, 301c, and 301d of the root unit 301. Therefore, the root unit 301 is located at the bottom of each branch of the tree-based structure. Each branch includes one or more units located above the root unit. The first branch extends from the upper port 301b. This first branch includes units 302, 305, and 308. The second branch extends from the upper port 301c. This second branch includes units 303, 306, and 309. The third branch extends from the upper port 301d. The third branch includes units 304, 307 and 310.

[0044] The units in the branch are connected in series. Each unit is connected to a single unit in the branch below it. Each unit is also connected to a single unit in the branch above it (if any). Each unit has a lower port through which it communicates with the unit in the branch below it. Each unit has an upper port through which it communicates with the unit in the branch above it. Both the lower and upper ports are bidirectional. For example, unit 302 has a lower port 302a, which is connected to the upper port 301b of the root unit 301. Unit 302 receives messages from the root unit 301 via the lower port 302a and sends messages to the root unit 301 via the lower port 302a. Unit 302 also has an upper port 302b, which is connected to the lower port 305a of unit 305. Unit 302 sends messages to unit 305 via the upper port 302b and receives messages from unit 305 via the upper port 302b.

[0045] Each unit can be directly connected to one or more local subsystems. Figure 3 In the illustrated example, unit 302 is directly connected to local subsystem 312. Unit 305 is also directly connected to a single local subsystem 313. Unit 308 is directly connected to two local subsystems 314 and 315. Note that, for ease of explanation, Figure 3 The local subsystems directly connected to units 303 and 306 are omitted. Each unit has local ports 302c, 305c, etc., which are connected to each local subsystem within its local subsystem. These one or more local ports are separate from and distinct from the unit's upper and lower ports. The local port can be bidirectional to allow communication between the unit and its local subsystem, as well as between the local subsystem and the unit.

[0046] The local subsystem includes one or more core devices. It may also include one or more analysis modules. It may also include one or more other routing units. For example, the local subsystem 312 of unit 302 has two core devices 316a and 316b and two analysis modules 317a and 317b. Each core device can be connected to its own analysis module. For example, analysis module 317a may be connected only to core device 316a. Similarly, analysis module 317b may be connected only to core device 316a. Alternatively, an analysis module may be connected to multiple core devices.

[0047] Analysis modules can be configured to passively or actively observe attached core devices. Analysis modules that passively observe core devices are limited to analyzing the core device's output. Conversely, analysis modules that actively observe core devices can analyze the core device's output and also control the core device to modify its operation. For example, an analysis module can control the core device to slow down its operation, stop its processor, and / or restart it.

[0048] Each analysis module 317a, 317b is connected to subsystem port 312a of the subsystem. Each subsystem port includes multiple individual ports, with one individual port for each analysis module. Therefore, subsystem port 312a includes a port for analysis module 317a and a separate port for analysis module 317b. Analysis modules 317a, 317b generate messages containing data related to the core devices 316a, 316b that the analysis modules are observing. For example, those messages may contain tracking data for the core device. The analysis modules output their messages to the connected branch unit 302 via their individual ports on subsystem port 312a. The analysis modules can receive configuration messages from the connected branch unit 302 via subsystem port 312a. For example, these configuration messages may instruct the analysis modules to change their monitoring of the core devices, such that they wish to detect and report different activities. For example, configuration messages may instruct the analysis modules to search for specific values ​​in the output of the core devices or to report when the core devices read from a specific address range in memory.

[0049] In an alternative configuration, the local subsystem can have multiple analysis modules and a subsystem port consisting of only a single port. In this case, the local subsystem also includes a routing unit that routes messages received at the port to individual analysis modules and vice versa.

[0050] refer to Figure 3 The tree-based topology described is used for routing communication as follows. Communication for a destination unit within a branch is routed to that destination unit via intermediate units within the branch between the root unit 301 and the destination unit. For example, a message intended for the analysis module 318 of subsystem 314 is routed from the root unit 301 via its upper port 301b to the lower port 302a of branch unit 302. Branch unit 302 routes the message from its upper port 302b to the lower port 305a of branch unit 305. Branch unit 305 routes the message from its upper port 305b to the lower port 308a of branch unit 308. Branch unit 308 outputs the message from its local port 308c to subsystem port 314a of subsystem 314. The message is then passed to the analysis module 318. Communication from the branch unit to the root unit 301 is routed downwards along the branch in a corresponding manner. Therefore, all major communication in the system is routed only upwards and downwards along the branches.

[0051] exist Figure 3 In the illustrated arrangement, root unit 301 routes data to external devices. The illustrated communication interface 311 is a USB port. The connection between communication interface 311 and root unit 301 is bidirectional. Root unit 301 outputs data received from monitoring circuitry to communication interface 311 for external transmission. This data may include trace data. This data may include event data. Communication interface 311 also sends messages received from external devices (e.g., external analyzers) to root unit 301. This data may include configuration messages for configuring one or more monitoring units in the monitoring unit. Root unit 301 routes messages upwards from communication interface 311 to addressing units in the branches.

[0052] Alternatively or additionally, root unit 301 can be connected to an on-chip analyzer. In this case, root unit 301 can route messages received from the monitoring circuitry to the on-chip analyzer. Root unit 301 can route messages received from the on-chip analyzer to the monitoring unit via the tree-based topology described above.

[0053] Typically, components on a SoC are arranged in a tiled array. In other words, components are arranged in a square grid. (Reference) Figure 3 The described tree-based monitoring network is constructed on-chip to fit the SoC components. Therefore, if the SoC components adopt this arrangement, the physical layout of the branch units adopts a similar approach. Figure 3The rules for splicing the branch units are shown. However, the physical layout of the branch units can be different so that if the SoC components are arranged differently, they can be accommodated, while still preserving the relative connection between the branch units and the routing mechanism of the tree-based topology.

[0054] As described above, the main communications related to the monitoring circuitry are transmitted around the upper and lower branches of the SoC in a tree-based topology. However, as described in the background section, if a branch cell fails, all those cells in that branch that are connected higher up than the failed cell can no longer communicate with the root cell via that branch. Figure 3 The network solved this problem.

[0055] Figure 3 The diagram illustrates cross links connecting branches above root unit 301. Each cross link connects a corresponding unit in an adjacent branch. Appropriately, each cross link connects only two units located in branches adjacent to each other. Units connected via cross links are at the same hierarchical level. Units connected via cross links can have the same number of intermediate units between themselves and the root unit in their respective branches.

[0056] Figure 3 The diagram illustrates four hierarchical levels. Level 0 includes root unit 301. Level 1 is the hierarchical level adjacent to and higher than level 0. Level 1 includes branch units 302, 303, and 304. Each of these branch units is directly connected to root unit 301. Branch unit 303 is adjacent to branch unit 302 and is at the same hierarchical level as branch unit 302. Branch units 302 and 303 are connected via cross link 319. Similarly, branch unit 303 is connected to branch unit 304 via cross link 320.

[0057] Level 2 is a hierarchical level adjacent to and higher than Level 1. Level 2 includes branch units 305, 306, and 307. Each of these branch units has an intermediate unit between it and the root unit in its branch. Branch unit 306 is adjacent to branch unit 305 and is at the same hierarchical level. Therefore, branch units 305 and 306 are connected via cross link 321. Similarly, branch unit 306 is connected to branch unit 307 via cross link 322.

[0058] Finally, level 3 is a hierarchical level adjacent to and higher than level 2. Level 3 includes branch units 308, 309, and 310. Each of these branch units has two intermediate units between it and the root unit in its branch. Corresponding branch units 308 and 309 are in adjacent branches and are connected by cross link 323. Corresponding branch units 309 and 310 are in adjacent branches and are connected by cross link 324.

[0059] Each branch unit has a cross-link port for each cross-link it connects to. Each cross-link is configurable. Specifically, the direction of the cross-link is configurable. For a cross-link connecting the first unit in the first branch to the second unit in the second branch, the cross-link can be configured as follows:

[0060] 1. Send upstream messages from the root unit to the second unit from the first unit, and send downstream messages from the second unit to the root unit and then to the first unit; or

[0061] 2. Send upstream messages from the root unit to the first unit from the second unit, and send downstream messages from the first unit to the root unit and then to the second unit.

[0062] In contrast, the direction of the link connecting the upper and lower ports of the branch unit within the branch is not configurable.

[0063] Initially, crosslinks were not used for primary communication routing messages related to monitoring circuitry around the SoC. However, if a branch unit is deemed defective, crosslinks are enabled to bypass the defective unit. (Reference) Figure 4 This will be described in further detail.

[0064] Figure 4 This is a flowchart illustrating a scenario utilizing cross-links. At step 401, messages are transmitted up and down only along branches of the SoC. At step 402, a decision is made regarding the existence of a defective branch cell in the SoC. If the answer is NO, the method returns to step 401, which still transmits messages up and down only along branches of the SoC. However, if the answer to step 402 is YES, the method proceeds to step 403. At step 403, in response to the cell being considered defective, a cross-link is enabled between the branch cell above the defective cell on the same branch as the defective cell and the corresponding cell in the adjacent branch. Then, at step 404, subsequent messages are routed from the root cell to the destination cell on the same branch as the defective cell via the adjacent branch and the enabled cross-link, thus bypassing the defective cell.

[0065] Figure 5 The illustration shows a first example of a cell being considered defective in a SoC. Figure 5 In Figure 4 At step 402 of the method, branch unit 303 is considered defective. Branch unit 303 is located in the second branch. Defective unit 303 prevents messages from traveling back and forth to the analysis module in the second branch, i.e., to and from the analysis module in the local subsystem 326. In response, cross link 321 is enabled. Cross link 321 is located between branch unit 305 in the first branch and branch unit 306 in the second branch. Branch unit 306 is adjacent to defective unit 303 in the same branch as defective unit 303. Defective unit 303 is located between branch unit 306 and root unit 301. Cross link 321 is enabled as follows.

[0066] In response to the detection of a defect in unit 303, root unit 301 sends a reconfiguration command to unit 305 in the first branch. Root unit 301 may have already received this reconfiguration command from an off-chip (or on-chip) analyzer that identified the defective unit. In response to receiving the reconfiguration command, unit 305 reconfigures itself to (i) route communication received at its lower port 305a to the destination unit in the second branch via cross-link 321 through cross-link port 305d, and (ii) route communication received at cross-link port 305d from cross-link 321 to root unit 301 via its lower port 305a.

[0067] In response to receiving the reconfiguration command, unit 305 also sends a reconfiguration command to unit 306 on cross-link 321. In response to receiving the reconfiguration command, unit 306 reconfigures itself to (i) route communications received at its upper port 306b to the root unit via cross-link 321 through cross-link port 306c, and (ii) route communications received at cross-link port 306c to the destination unit in the second branch via its upper port 306b.

[0068] Therefore, unit 305 configures the direction of cross-link 321 so that uplink 321a routes messages from unit 305 to unit 306, and downlink 321b routes messages from unit 306 to unit 305. This allows the cross-link to bypass defective unit 303, enabling units above defective unit 303 in the second branch to send and receive messages.

[0069] Figure 6 The illustration shows a second example of a cell being considered defective within a SoC. Figure 6 In Figure 4At step 402 of the method, branch unit 302 is considered defective. Branch unit 302 is located in the first branch. Defective unit 302 blocks message round-trip routes due to the analysis modules in the first branch, i.e., routing messages from the analysis modules in local subsystems 312, 313, 314, and 315. In response, cross-link 321 is enabled. Cross-link 321 is located between branch unit 305 in the first branch and branch unit 306 in the second branch. Branch unit 305 is adjacent to defective unit 302 in the same branch as defective unit 302. Defective unit 302 is located between branch unit 305 and root unit 301. Cross-link 321 is enabled as follows.

[0070] In response to the detection of a defect in unit 302, root unit 301 sends a reconfiguration command to unit 306 in the second branch. Root unit 301 may have already received this reconfiguration command from an off-chip (or on-chip) analyzer that identified the defective unit. In response to receiving the reconfiguration command, unit 306 reconfigures itself to (i) route communication received at its lower port 306a to the destination unit in the first branch via cross-link 321 through cross-link port 306c, and (ii) route communication received at cross-link port 306c from cross-link 321 to root unit 301 via its lower port 306a.

[0071] In response to receiving the reconfiguration command, unit 306 also sends a reconfiguration command to unit 305 on cross-link 321. In response to receiving the reconfiguration command, unit 305 reconfigures itself to (i) route communications received at its upper port 305b to the root unit via cross-link 321 through cross-link port 305d, and (ii) route communications received at cross-link port 305d to the destination unit in the first branch via its upper port 305b.

[0072] Therefore, unit 306 configures the direction of cross-link 321 so that uplink 321c routes messages from unit 306 to unit 305, and downlink 321d routes messages from unit 305 to unit 306. This allows the cross-link to bypass defective unit 302, enabling units above defective unit 302 in the first branch to send and receive messages.

[0073] Figure 5 and Figure 6 The example illustration shows the same cross-link 321 with two configurations, in which the uplink and downlink directions are opposite. The cross-link can be configured to use either configuration. The configuration used depends on which branch of the cross-link connects to has the defective unit.

[0074] Figure 7 The diagram illustrates an example of the internal structure of a branch unit. Figure 7 The diagram illustrates two branch units 701a and 701b at the same hierarchical level in adjacent branches. These two branch units are connected via a cross link 702. Each branch unit includes control modules 713a and 713b for controlling the routing of received messages. Each branch unit includes lower ports 703a and 703b, which have lower ingress points 704a and 704b for receiving upstream messages and lower egress points 705a and 705b for sending messages downstream. Each branch unit includes other ports 706a and 706b. These other ports include upper ports, which have upper ingress points 707a and 707b for receiving downstream messages and upper egress points 708a and 708b for sending upstream messages. These other ports may include one or more other local ports for communicating with a local subsystem, each local port having an ingress point for receiving messages from the local subsystem and an egress point for sending messages to the local subsystem.

[0075] Branch units include other components that enable them to route messages in either direction via cross-link 702. Each branch unit includes a cross-link port with ingress 714a, 714b and egress 715a, 715b. Each branch unit includes demultiplexers (DeMUX) 711a, 711b. The DeMUX is connected to the cross-link port and receives messages from another branch unit via cross-link 702. The DeMUX is configured to selectively output messages received on the cross-link to either cross-link ingress 714a or a downstream ingress 704a. The DeMUX selects its output in response to a reconfiguration command received from the root unit. Thus, for example, if the cross-link is enabled to route downstream messages from branch unit 701b to branch unit 701a and then to root unit 301, DeMUX 711a will selectively route messages received via cross-link 702 to cross-link ingress 714a. If cross-links are enabled to route upstream messages from root unit 301 to branch unit 701b and then to branch unit 701a, DeMUX 711a will selectively route messages received via cross-link 702 to the next entry point 704a.

[0076] DeMUX can output messages to reduced-width inlets 716a and 716b via gearboxes 717a and 717b. Gearboxes 717a and 717b are narrower when the width of a downstream message is greater than the width of an upstream message. Reduced-width inlets 716a and 716b route all messages to control modules 713a and 713b. Reduced-width inlets 716a and 716b do not have message FIFOs, event FIFOs, or routing control.

[0077] The branch unit includes message switches 712a and 712b, which are 2x2 switches that receive the following as inputs: (i) the outputs of DeMUX 711a and 711b, and (ii) upstream inputs from the branch unit below in the branch. The switches have the following outputs: (i) lower inlets 704a and 704b, and (ii) reduced inlets 716a and 716b. The downstream outputs of lower outlets 705a and 705b are gated by gates 709a and 709b.

[0078] Each branch unit also includes multiplexers MUX 710a and 710b. The MUX outputs messages to another branch unit on cross-link 702. The MUX selectively outputs from cross-link exits 715a and 715b or downstream exits 705a and 705b. The MUX selects its inputs in response to a reconfiguration command received from the root unit. Thus, for example, if cross-linking is enabled to route upstream messages from root unit 301 to branch unit 701a and then to branch unit 701b, MUX 710a selectively routes messages from cross-link exit 715a to cross-link 702. Conversely, if cross-linking is enabled to route downstream messages from branch unit 701a to branch unit 701b and then to root unit 301, MUX 710a selectively routes messages from downstream exit 705a to cross-link 702.

[0079] Therefore, the MUX of each branch unit on one side of the cross link outputs messages to the DeMUX of the branch unit on the other side of the cross link. And the DeMUX of each branch unit on one side of the cross link receives messages from the MUX of the branch unit on the other side of the cross link.

[0080] Figure 7 The diagram illustrates the message flow among branch units when they are configured to operate in the default state, where cross-links are not used for primary communication via a tree-based structure. The message flow is... Figure 7 The diagram above uses dashed lines. MUX 710a and 710b are configured to route messages from cross-link exits 715a and 715b to cross-link 702. DeMUX 711a and 711b are configured to route messages from cross-link 702 to reduced ingresses 716a and 716b. Message switches 712a and 712b are configured to route the outputs of DeMUX 711a and 711b to reduced ingresses 716a and 716b. In this configuration, cross-links are not enabled to route messages between the root unit and the destination unit via cross-links. In this configuration, cross-links are enabled, allowing any unit connected to a cross-link to reconfigure another unit. This allows cross-links to be configured in either direction.

[0081] Figure 8 The illustration shows how the cross link can bypass a defective branch unit that is in the same branch as unit 701a. Figure 7 The internal configuration of branch units 701a and 701b. Figure 8 The diagram shows... Figure 6 The illustrated scenario shows the internal configuration of branch units where branch unit 701a is equivalent to branch unit 305, and branch unit 701b is equivalent to branch unit 306. In this scenario, cross links 702 / 321 are enabled to route upstream messages from units 701b / 306 to units 701a / 305. Furthermore, cross links 702 / 321 are enabled to route downstream messages from units 701a / 305 to units 701b / 306. Figure 7 Compared to the default configuration, units 701b / 306 receive a reconfiguration command from root unit 301. In response to the reconfiguration command, it (i) configures MUX 710b to route messages from cross-link egress 715b to cross-link 702 / 321; and (ii) configures DeMUX 711b to route messages received from cross-link 702 / 321 to cross-link ingress 714b.

[0082] In response to the reconfiguration command, units 701b / 306 also send a reconfiguration command to units 701a / 305 via cross-link 702 / 321. Upon receiving this reconfiguration command, units 701a / 305 (i) configure MUX 710a to route messages from its lower egress 705a to cross-link 702 / 321; and (ii) configure DeMUX 711a to route messages received from cross-link 702 / 321 to lower ingress 704a. Units 701a / 305 may also configure their message switch 712a to route messages from cross-link 702 / 321 to lower ingress 704a via DeMUX 711a. This also prevents the input of defective unit 302 from being connected to lower ingress 704a, and thus avoids spurious outputs of defective unit 302 being routed through the system. Units 701a / 305 can also be configured with gate 709a to gate the output of lower outlet 705a to prevent messages from being output from units 701a / 305 to defective unit 302. This saves power because it avoids the defective component receiving and processing the message.

[0083] The methods described above can be used to bypass more than one defective unit. If two defective units are on the same branch and adjacent to each other, the same cross link can be used to bypass both defective units. If two defective units are on the same branch but not adjacent to each other, different cross links can be used to bypass the defective units, with each defective unit having a bypass route. If the defective units are on different branches, different cross links can be used to bypass the defective units, with each defective unit having a bypass route.

[0084] The following describes a method by which one or more branch units can be considered defective; and an addressing mechanism that can be used to enable branch units to bypass defective units when routing messages through a tree-based system.

[0085] The addressing mechanism protocol described below assigns an address to each individual addressable entity in the system. Based on the address of the individual addressable entity, communication to and from the individual addressable entity is routed through the system via intermediate branch units. Each branch unit routes communication to and from the individual addressable entities located above it in its branch. As described above, it can also route communication to and from individual addressable entities in adjacent branches via cross-links to bypass defective units.

[0086] Figure 9 This is a flowchart illustrating the mechanism for determining that a unit is defective and bypassing the defective unit in subsequent communications. At step 901, root unit 301 sends a discovery message. This can be a single discovery message sent to all branch units in a tree-based structure. Alternatively, a single discovery message can be sent from root unit 301 to each individual addressable entity in the system. For example, discovery messages can be sent sequentially to each individual addressable entity. Root unit 301 receives discovery responses from units in the system. Each discovery response identifies the number of individual addressable entities in that unit and those in the branches above it.

[0087] At step 902, an assessment is made regarding whether a discovery response has been received from each unit. For example, the root unit can be configured to wait a predetermined time T in response to a discovery request. If no response is received from the unit within that time T, the unit is considered unresponsive. If a discovery response is received from each unit, the answer to step 902 is YES. In this case, at step 903, the main communication of the monitoring network is transmitted as usual only within branches of the tree-based structure. If the answer to step 902 is NO, it indicates that one or more defective units exist in the same branch as one or more unresponsive units. It does not necessarily mean that every unresponsive unit is defective. For example, in Figure 6In the example, even if only cell 302 is defective, no response to the discovery request will be received from any cell in the first branch.

[0088] At step 904, one or more unresponsive cells are identified as defective. The unresponsive cell closest to the root cell in the hierarchy can be considered defective. In other words, the unresponsive cell with the fewest intermediate cells between itself and the root cell can be considered defective. Appropriately, this is the only unresponsive cell considered defective at this stage.

[0089] In the next step 905, a cross link is enabled between the first cell in the same branch as the defective cell and the second cell in the adjacent branch. Appropriately, the first cell is adjacent to the defective cell in the same branch. The defective cell is located between the first cell and the root cell in the branch. (See reference) Figure 6 For example, the enabled cross link might be cross link 321, because this cross link connects units 305 and 306, and unit 305 is adjacent to defective unit 302 in the same branch as defective unit 302.

[0090] At the next step 906, root unit 301 sends another discovery message. Similar to the discovery message in step 901, this additional discovery message could be a single discovery message sent to all branch units in the tree-based structure. Alternatively, a single discovery message could be sent from root unit 301 to each individually addressable entity in the system. Root unit 301 receives discovery responses from units in the system. Each discovery response identifies the number of individually addressable entities in that unit and those in the branches above it. If the cross-link in step 905 has been successfully enabled, the discovery response from the second unit corresponds to the second unit's discovery response to the discovery request in step 901. Specifically, compared to the second unit's discovery response to the discovery request in step 901, the second unit's discovery response will identify a greater number of individually addressable entities to which it can route the message. If the cross-link of step 905 has been successfully enabled, the number of individually addressable entities identified by the second unit in its discovery response will be the total number of individually addressable entities among: (i) the second unit, (ii) the units in the branch above the second unit, (iii) the first unit, and (iv) any accessible units in the branch above the first unit.

[0091] Optionally, at step 907, the root unit evaluates whether it has received a discovery response from every defect-free unit in the system. For example, the root unit can be configured to wait a predetermined time T in response to a discovery request. If no response is received from a unit within that time T, the unit is considered unresponsive. If the answer is YES, all defective units have been successfully bypassed. If the answer is NO, there are still defective units in the system.

[0092] If the number of individually addressable entities identified in the discovery response of the second unit at step 906 is greater than the corresponding number identified at step 901, then the cross-link is successfully enabled. In this case, if the answer to step 907 is NO, it indicates that there are other defective units elsewhere in the system. For example, in Figure 6 In the example, cell 308 may be defective. Repeat the process from steps 904 to 907. In this iteration, the next unresponsive cell to be considered defective is the unresponsive cell at the hierarchical level closest to the root cell, excluding unresponsive cells that have already been considered defective.

[0093] If the number of individually addressable entities identified in the discovery response of the second unit at step 906 is the same as the corresponding number identified at step 901, then the cross-link has not been successfully enabled. In this case, if the answer at step 907 is NO, then at the next iteration in step 904, the root unit can determine that the first unit is also defective. (See reference...) Figure 6 This could mean that units 302 and 305 in the first branch are defective. At step 905, a cross-link is enabled between the third unit in the same branch as the defective unit and the fourth unit in the adjacent branch. The third unit is adjacent to the first unit. The first unit is located between the third unit and the defective unit. (Reference) Figure 6 If both units 302 and 305 are considered defective, then cross link 323 is enabled. Cross link 323 is located between branch units 308 and 309. Branch unit 308 is adjacent to the defective unit 305 in the first branch.

[0094] The iterative loop from steps 904 to 907 continues until a discovery response is received from all non-defective units in the system. Once a defective unit has been identified from the set of non-responding units, the method proceeds to steps 908, 909, and 910. At step 908, the address of each successfully enabled cross-link is reconfigured so that subsequent communication with individual addressable entities in the defective unit's branch is routed via adjacent branches and enabled cross-links, thereby bypassing the defective unit.

[0095] At step 909, the address of each intermediate unit in the adjacent branch between the second unit and the root unit is reconfigured to enable subsequent communication via the second unit to individual addressable entities in the branch of the defective unit. Figure 6 In the example, this requires reconfiguring the address of unit 303 in the second branch so that unit 303 routes messages intended for unit 305 in the first branch and the unit located above in the first branch to unit 306 and cross link 321 via the second branch.

[0096] At step 910, root unit 301 is reconfigured in two ways. First, root unit 301 is reconfigured to prevent it from directly sending communication to the same branch as the defective unit, where the defective intermediate unit is located between the root unit and the destination unit, for those communications for individually addressable entities of the destination unit. Root unit 301 is also reconfigured to send communication to individually addressable entities in the branch of the defective unit via adjacent branches, where the defective intermediate unit is located between the root unit and the destination unit, for those communications for individually addressable entities of the destination unit.

[0097] Then, the method proceeds to step 911, where the message is within the branch and transmitted via an enabled cross-link to bypass the defective unit.

[0098] The following describes an addressing protocol that can be used in conjunction with the method described above. This addressing protocol utilizes a base address reset mechanism. In this mechanism, each unit assumes it has the same internal address as other units in the tree-based structure. This internal address is referred to below as the base address. Each unit is configured to address other units using an address that is derived from its internal address given the position of other units in the tree-based structure. Each unit along the path of a message routes to its destination unit, and each unit performs a base address reset on the destination address of that message.

[0099] Therefore, for example, the root unit sends a message that includes the destination address of a separate addressable entity. This destination address is related to the root unit's internal address. The root unit sends the message to the branch it is connected to. An intermediate unit adjacent to the root unit on that branch receives the message. This intermediate unit base-resets the message by adding an offset to the destination address to form a base-reset destination address. The base-reset destination address is related to the intermediate unit's internal address. The intermediate unit then routes the base-reset message to the separate addressable entity.

[0100] The base address reset mechanism can utilize address indexes. For example, each individual addressable entity in a monitoring system can have an address index. Each branch unit can have one or more address indexes. (Reference) Figure 3 As an example, each analysis module has a single address index. Branch unit 308 has two address indices assigned to the two analysis modules of local subsystem 314 (in... Figure 3 The diagram shows port 308c (illustrated as 2), and the two address indices (in the two analysis modules assigned to the local subsystem 315) at port 308c. Figure 3 The address index at port 308b is shown as 2). No address index is assigned to cross link 323 (shown as 0 at port 308d). The internal address index of branch unit 308 is 1. Therefore, in response to the discovery request in step 901, branch unit 308 reports a total index count of 5 (=2+2+0+1). Branch unit 305 has two address indexes assigned to the two analysis modules of local subsystem 313, and five address indexes assigned to branch unit 308 connected to the upper port of unit 305. No address index is assigned to cross link 321. The internal address index of branch unit 305 is 1. Therefore, in response to the discovery request in step 901, branch unit 305 reports a total index count of 8 (=2+5+0+1). Branch unit 302 has two address indexes assigned to the two analysis modules of local subsystem 312, and eight address indexes assigned to branch unit 305 connected to the upper port of unit 302. No address index is assigned to cross link 319. The internal address index of branch unit 303 is 1. Therefore, when responding to the discovery request in step 901, branch unit 303 reports a total index count of 11 (=2+8+0+1).

[0101] Upstream messages in the system can be routed by index. Consider the case where the base address is 0. In other words, each unit considers its own internal address to be 0. As an upstream message propagates through the system, the address index of the message is adjusted. For example, if root unit 301 sends a message to the analysis module 325a of the local subsystem 315 of branch unit 308, it applies address index 10 to the message, which is based on the address of the analysis module 325a of root unit 301. Root unit 301 routes the message to its upstream port 301b. The root unit resets the base address by adding an offset of -n, where n is the number of address indices assigned to the root unit itself. n = 1. Therefore, the destination address of the message after the base address reset is 9.

[0102] Branch unit 302 receives the message. According to branch unit 302, its address is 0, the addresses of local subsystem 312 are 1-2, and the addresses of branch unit 305 are 3-11. From branch unit 302's perspective, it performs a base address reset on the message's destination address so that it is the address of analysis module 325a. The branch unit performs the base address reset by adding an offset of -m, where m is the number of address indices allocated to the branch unit itself and the local subsystem directly connected to it (i.e., local subsystem 312). Therefore, in this example, branch unit 302 subtracts 3, resulting in a base address reset destination address of 6. Branch unit 302 routes the base address reset message to its upstream port 302b, and from that upstream port 302b, it routes it to branch unit 305.

[0103] Branch unit 305 receives the message. According to branch unit 305, its address is 0, the addresses of local subsystem 313 are 1-2, and the addresses of branch unit 308 are 3-8. From the perspective of branch unit 305, it performs a base address reset on the message's destination address, making it the address of analysis module 325a. As mentioned above, branch unit 305 subtracts 3, therefore the base address reset destination address is 3. Branch unit 305 routes the base address reset destination address to its upstream port 305b, and from that upstream port 305b, it routes to branch unit 308.

[0104] Branch unit 308 receives the message. According to branch unit 308, its address is 0, the addresses of local subsystem 314 are 1-2, and the addresses of local subsystem 315 are 3-4. As described above, branch unit 308 subtracts 3, therefore the destination address after base address reset is 0. Branch unit 308 routes the base address reset message to its upper port 308b, and from that upper port 308b, it routes it to local subsystem 315.

[0105] The analysis module 325a considers its own address index to be 0, and therefore identifies itself as the destination unit of the received message.

[0106] Before a unit in the system is determined to be defective, each cross-link in the system has 0 address indices. By assigning address indices to that cross-link, it is possible to... Figure 9The cross-link is enabled at step 905. For example, an address index of 1 can be assigned to the cross-link. A branch unit located above the faulty unit that is connected to an adjacent branch via the cross-link can respond to the assignment of an address index to the cross-link by reconfiguring its DeMUX, MUX, message exchange, and gates, as described above. If the cross-link is not successfully enabled, the root unit cancels the assignment of an address index to the cross-link. Then, as described above, the next cross-link above the faulty cross-link is enabled.

[0107] Now, targeting Figure 5 Examples of defects Figure 9 The implementation methods of steps 908, 909, and 910 are described below. Figure 5 In this process, branch unit 303 is considered defective. Subsequent communication is routed to the second branch via branch units 302 and 305 of the first branch and cross link 321. At step 908, cross link 321 is reconfigured by allocating the address index consumed by branch unit 306 in the second branch and the unit above branch unit 306 to the address of cross link 321. Branch unit 306 has one address index, and there are three address indices above branch unit 306. Therefore, cross link 321 is allocated an address index of 4 via branch unit 305. Thus, the number of address indices used for redundant link 321 has been reduced from 0 (e.g., ...). Figure 3 (As shown) changed to 4 (as shown) Figure 5 (As shown).

[0108] At step 909, branch unit 305 is reconfigured by additionally allocating the address index consumed by cross-link 321 to its address. Branch unit 305 has one address index, local subsystem 313 has two address indexes, the unit above branch unit 305 in the first branch has five address indexes, and the cross-link has four indexes. Therefore, the number of address indexes for branch unit 305 has been increased from 8 (e.g., ...). Figure 3 (As shown) changed to 12 (as shown) Figure 5 (As shown). Therefore, branch unit 302 routes the message with 12 address indices to branch unit 305.

[0109] At step 909, branch unit 302 is reconfigured by additionally allocating the address index consumed by branch unit 305 to its address. Therefore, the number of address indexes for branch unit 302 has been increased from 11 (e.g., ...). Figure 3 (As shown) changed to 15 (as shown) Figure 5 (As shown). Therefore, root unit 301 routes messages with 15 address indices to branch unit 302.

[0110] At step 910, the root unit 301 is reconfigured in two ways. First, the upper port 301b of the root unit 301 is reconfigured to send messages with up to 15 address indices to the branch unit 302 in the first branch. Second, the upper port 301c of the root unit 301 is reconfigured to no longer send any messages to the branch unit 303 in the second branch.

[0111] Therefore, as an example, in a reindexed addressing mechanism, a message might be traced from root unit 301 to analysis module 501 of local subsystem 326, as follows: Root unit 301 applies address index 14 to the message, which is based on the address of analysis module 501 of root unit 301. Root unit 301 routes the message to its upstream port 301b and applies an offset of -1. Branch unit 302 receives the message with index 13. Branch unit 302 routes the message to its upstream port 302b and applies an offset of -3. Branch unit 305 receives the message with index 10. Branch unit 305 routes the message to its cross-link port 305d and applies an offset of -8. Branch unit 306 receives the message with index 2. Branch unit 306 routes the message to its upstream port 306b and applies an offset of -1. Branch unit 309 receives the message with index 1. Branch unit 309 routes the message to its local subsystem port 502 and applies an offset of -1. Local subsystem 326 receives the message with index 0. Analysis module 501 considers its own address index to be 0, and therefore identifies itself as the destination address of the received message.

[0112] Typically, messages transmitted within the tree-based system described above include: upstream configuration messages for configuring the analysis module to monitor system circuitry; and downstream messages containing monitoring data generated by the analysis module's monitoring of the system circuitry. In addition to these messages, event messages are also transmitted in the system. The analysis module is configured to generate event messages in response to a core device it is monitoring detecting a specific activity. For example, the analysis module may be configured to generate an event message in response to its associated core device reading a specific address range from memory. Appropriately, the activity of the analysis module generating event messages can be configured during runtime.

[0113] Event messages propagate throughout the system. Other analytics modules respond to the receipt of an event message by taking action. This action can depend on the content of the event message. For example, the event message might indicate a security or reliability issue. In response, an analytics module might halt the operation of its associated core device. As another example, in response to the event, they might adjust the activity of their monitored associated core device. Event messages generated at analytics modules within the system are broadcast to all other units in the system. In other words, event messages are cross-triggered throughout the system.

[0114] Figure 10 The illustration shows that Figure 3 Event messages are broadcast throughout the entire monitoring network. Each branch unit forwards event messages through the system and to one or more of its own local subsystems. Event messages are generated by analysis module 325a in local subsystem 315 of branch unit 308. Analysis module 325a sends event messages to branch unit 308. Branch unit 308 routes event messages upstream to analysis module 325b, to its other local subsystem 314, and then downstream to branch unit 305. Branch unit 308 does not send event messages back to analysis module 325a, which generated the event messages. Branch unit 305 routes event messages to its local subsystem 313 and downstream to branch unit 302. Branch unit 302 routes event messages to its local subsystem 312 and downstream to root unit 301. Root unit 301 routes event messages upstream to second and third branches and downstream to communication interfaces 311 and 1005. Specifically, root unit 301 routes the event message upstream to branch units 303 and 304. Branch unit 303 routes the event message to branch unit 306. Branch unit 306 routes the event message to branch unit 309. Branch unit 309 routes the event message to the analysis module in local subsystem 326. The corresponding route is applied to the third branch.

[0115] Each branch unit receives and propagates the event message, causing a one-cycle delay. Figure 10 The numbers in the circles next to each cell indicate the number of cycles required for an event message to reach each cell in the tree-based network. Therefore,

[0116] It takes one cycle for the event message to reach branch unit 308;

[0117] The event message takes two cycles to reach branch unit 305, local subsystem 314 and analysis module 325b;

[0118] The event message takes three cycles to reach branch unit 302 and local subsystem 313.

[0119] The event message takes four cycles to reach root unit 301 and local subsystem 312;

[0120] The event message takes 5 cycles to reach branch units 303 and 304 and communication interfaces 311 and 1005;

[0121] The event message takes 6 cycles to reach branch units 306 and 307 and local subsystem 1004;

[0122] The event message takes 7 cycles to reach branch units 309 and 310 and local subsystem 1003; and

[0123] The event message takes eight cycles to reach local subsystems 326, 1001, and 1002.

[0124] For this tree-based topology where messages are passed up and down branches, the highest latency for routing event messages across the entire network was observed between components at the top of the hierarchy in different branches. Therefore, although local subsystem 326 is physically close to local subsystem 315, which generates the event message, it observed a maximum latency of 8 cycles for the event message to arrive at it. This is problematic because the analysis module physically closest to the analysis module that generates the event message is typically the one that needs to respond to the event message most urgently, thus requiring the most urgent reception of the event message.

[0125] Figure 11 The illustration shows that Figure 3 Event messages are broadcast throughout the entire monitoring network, which, in addition to routing event messages within branches, also utilize cross-links to route event messages between branches. Cross-links are used with their default configuration, in which the branch units they connect to are such as... Figure 7 The configuration is shown. The way each branch unit routes event messages depends on how it receives event messages. Specifically:

[0126] 1. If a branch unit receives an event message directly from the analysis module, it routes the event message upstream, downstream, and across all its cross-links. It also routes the event message to all its local subsystems. It does not route the event message back to the analysis module from which it received the message.

[0127] 2. If a branch unit receives an event message from a cross-link, it routes the event message upstream, downstream, and via its other cross-link (if the branch unit has a cross-link). It also routes the event message to all its local subsystems. It does not route the event message back to the cross-link from which it received the event message.

[0128] 3. If a branch unit receives an event message from a unit above it in its branch, the branch unit routes the event message upstream (if it has ports to other units besides the one from which it received the event message) and downstream. It also routes the event message to all its local subsystems. It does not route the event message on one or more of its cross-links. It does not route the event message back to the unit from which it received the event message.

[0129] 4. If a branch unit receives an event message from a unit located below it in its branch, the branch unit routes the event message downstream (if any other units exist from which the branch unit received the event message) and upstream. It also routes the event message to all its local subsystems. It does not route the event message on one or more of its cross-links. It does not route the event message back to the unit from which it received the event message.

[0130] exist Figure 11 In the example, with Figure 10 Similarly, the event message is generated by the analysis module 325a in the local subsystem 315 of branch unit 308. Following the rules described above, the analysis module 325a sends the event message to branch unit 308. Branch unit 308 receives the event message from the analysis module 325a, thus following rule 1 above. Branch unit 308 routes the event message upstream to the analysis module 325b, to its other local subsystem 314, and downstream to branch unit 305, then via cross-link 323 to branch unit 309. Branch unit 308 does not send the event message back to the analysis module 325a that generated the event message. (See reference...) Figure 10 As described, branch units 305 and 302 route event messages. Branch unit 309 receives event messages on cross link 323, thus following rule 2 above. Branch unit 309 routes event messages upstream to local subsystem 326, downstream to branch unit 306, and on its other cross link 324 to branch unit 310 in adjacent branch 3. Branch unit 310 receives event messages from cross link 324, thus following rule 2 above. Branch unit 310 routes event messages to its local subsystems 1001 and 1002, and downstream to unit 307. Branch units 306, 303, 307, and 304 receive event messages from units above them in the branch, thus following rule 3 above. Therefore, these branch units route event messages downstream and to their local subsystems (if these branch units have local subsystems).

[0131] This method of using cross-links to transmit event messages reduces the latency caused when cross-links trigger those cells that are physically close to the cell that generated the event message. Figure 11 The numbers in the circles next to each cell indicate the number of cycles required for an event message to reach each cell in the tree-based network. (This is in contrast to using...) Figure 10 The method requires 8 cycles for comparison, while event messages require 3 cycles to reach the physically nearest local subsystem 326. Compared to using... Figure 10 The method requires 8 cycles for comparison, and event messages require 4 cycles to reach local subsystems 1001 and 1002. Therefore, regarding Figure 11 The described method reduces the propagation latency of event messages between physically close subsystems. The longest propagation latency has also been reduced from 8 cycles to 6 cycles.

[0132] Figure 12 The diagram illustrates the application of the rules described above in... Figure 3 Another example of broadcasting an event message throughout the monitoring network. The event message is generated by analysis module 501 in local subsystem 326 of branch unit 309. Branch unit 309 receives the event message from analysis module 501, thus following rule 1 above. Branch unit 309 routes the event message upstream to analysis module 1201, downstream to branch unit 306, then via its cross link 323 to branch unit 308, and via its cross link 324 to branch unit 310. Branch unit 309 does not send the event message back to analysis module 501, which generated the event message. Branch units 308 and 310 receive the event message on the cross links, thus following rule 2 above. Branch unit 308 routes the event message to its local subsystems 314 and 315, and downstream to branch unit 305. Branch unit 308 does not have another cross link to route the event message to. Branch unit 310 routes event messages to its local subsystems 1001 and 1002, and downstream to branch unit 307. Branch unit 310 has no other cross-link to route event messages to. Branch units 305, 306, 307, 302, 303, and 304 receive event messages from the units above them in the branch, thus following rule 3 above. Therefore, these branch units route event messages downstream and to their local subsystems (if these branch units have local subsystems).

[0133] The event message may include an event code. The event code identifies an event that the analysis module that generated the event message has detected. Additionally, the event message may include a flag. For example, if a branch unit receives the event message directly from the analysis module (i.e., rule 1 above), it may set a flag to transmit downstream with the event message to one or more units below it in the branch. It does not set a flag to transmit the event message to units in the branch that are not below it. If a branch unit receives a flagged event message from a unit above it in the branch (i.e., rule 3 above), it: (i) routes the flagged event message to one or more adjacent branch units below it in its branch; and (ii) routes the unflagged event message to one or more adjacent units above it in the branch and their local subsystems.

[0134] The way root unit 301 responds to a received event message can depend on whether a tag is set. If root unit 301 receives an event message for which a tag is set, it can respond by simply routing the event message to its downstream port 301a. The event message is sent from its downstream port 301a to one or more communication interfaces 311, 1005. One or more communication interfaces can route the event message off-chip, for example, to an off-chip analyzer. Alternatively, one or more communication interfaces can route the event message to another on-chip module, such as an on-chip analyzer. If root unit 301 receives an event message for which no tag is set, it takes no action. In other words, root unit 301 does not route the event message to any other unit. This prevents the event message from being broadcast indefinitely around the system. Because the tag is set only in the branch from which the event originated, one or more communication interfaces receive the event message from root unit 301 only once.

[0135] The tag can be a single bit of the event message. For example, the event code can be an 8-bit code, while the tag can be an additional single bit. For example, bits 0-7 can be the event code, while bit 8 can be the tag. Alternatively, the tag can form part of the event code.

[0136] If cross-links are already enabled to route communication between branches to bypass defective units, then for event message propagation purposes, the cross-link is treated as either an uplink or a downlink. Figure 5Taking the defective system as an example, if the event is generated by the analysis module 501 of the local subsystem 326, then branch unit 309 forwards the event message downstream to branch unit 306, and also via cross links 323 and 324, and forwards it back to the analysis module 1201 in the local subsystem 326. Branch unit 306 has already received the event message from upstream, so it operates according to rule 3. Since branch unit 306 considers cross link 321 as a downlink to branch unit 305, branch unit 306 routes the event message downstream to branch unit 305 via cross link 321. Then, branch unit 305 routes the event message upstream to branch unit 308, downstream to branch unit 302, and then to its local subsystem 313.

[0137] Again Figure 6 Taking a defective system as an example, if an event is generated by the analysis module 325a of local subsystem 315, then branch unit 308 forwards the event message downstream to branch unit 305, routes it to local subsystem 314 via cross link 323, and then routes it to the analysis module 325b in local subsystem 315. Branch unit 305 has already received the event message from upstream, so it operates according to rule 3. Since branch unit 305 considers cross link 321 as a downlink to branch unit 306, branch unit 305 routes the event message downstream to branch unit 306 via cross link 321. Then, branch unit 306 routes the event message upstream to branch unit 309 and downstream to branch unit 303.

[0138] Because the enabled cross-link used to bypass the defective unit is treated as an uplink / downlink, the branch unit attached to that cross-link maintains the tag set when routing event messages downstream via the cross-link. Figure 5 For example, if the event is generated by the analysis module 501 of the local subsystem 326, then when the event message is routed downstream to branch unit 306, branch unit 309 sets a flag for the event message. Branch unit 306 maintains the flag set when the event message is routed downstream to branch unit 305 via cross link 321. Branch unit 305 maintains the flag set when the event message is routed downstream to branch unit 302. Furthermore, branch unit 302 maintains the flag set when the event message is routed downstream to root unit 301. Because the flags are set, root unit 301 routes the event message downstream to one or more communication interfaces 311 to which it is connected.

[0139] Figures 1 to 3 , Figures 5 to 8 ,as well as Figures 10 to 12 Each component of the SoC shown can be implemented in dedicated hardware. Alternatively, Figures 1 to 3 , Figures 5 to 8 ,as well as Figures 10 to 12 Each component of the SoC shown can be implemented in software. Some components can be implemented in software, while others can be implemented in dedicated hardware.

[0140] The described SoC is suitably incorporated into a computation-based device. The computation-based device can be an electronic device. Suitably, the computation-based device includes one or more processors for processing computer-executable instructions to control the operation of the device to implement the methods described herein. The computer-executable instructions can be provided using any computer-readable medium such as memory. The methods described herein can be executed by software in a machine-readable form on a tangible storage medium. Software can be provided at the computation-based device to implement the methods described herein.

[0141] The above description portrays system circuitry and monitoring circuitry as being included on the same SoC. In alternative implementations, system circuitry and monitoring circuitry are included on two or more integrated circuit chips within the MCM. In an MCM, integrated circuit chips are typically stacked or positioned adjacently on an interpolator substrate. Some system circuitry may reside on one integrated circuit chip, while others may reside on different integrated circuit chips within the MCM. Similarly, monitoring circuitry may be distributed across more than one integrated circuit chip within the MCM. Therefore, the methods and apparatus described above in the context of SoC are also applicable to the context of MCM.

[0142] The applicant hereby separately discloses each individual feature described herein, as well as any combination of two or more such features, so that such features or combinations can be performed entirely based on this specification, given the common general knowledge of those skilled in the art, regardless of whether such features or combinations solve any of the problems disclosed herein and without being limited to the scope of the claims. The applicant notes that various aspects of the invention can consist of any such individual features or combinations of features. In view of the foregoing description, it will be apparent to those skilled in the art that various modifications can be made within the scope of the invention.

Claims

1. An integrated circuit chip device comprising: a system circuitry arrangement; and a monitoring circuitry arrangement for monitoring the system circuitry arrangement, the monitoring circuitry arrangement comprising cells connected in a tree-based structure, the cells for routing communications through the integrated circuit chip device, the tree-based structure comprising: branches extending from a root cell, each branch comprising the root cell, a destination cell, and a plurality of intermediate cells positioned between the root cell and the destination cell, wherein each intermediate cell of the plurality of intermediate cells is connected to a single cell above in the branch and a single cell below in the branch, whereby a communication between the root cell and the destination cell of one of the branches, via the plurality of intermediate cells of the respective branch, is routable; and cross-links connecting intermediate cells of adjacent different branches such that each intermediate cell of the plurality of intermediate cells is connected to at least one additional intermediate cell of an adjacent different branch, wherein each cross-link of the cross-links is configured to, responsive to an intermediate cell of the plurality of intermediate cells being deemed defective, route a communication between the root cell and the destination cell of one of the branches, via the other of the branches, wherein the defective intermediate cell and the destination cell are in the same branch.

2. The integrated circuit chip device of claim 1, wherein the defective intermediate cell is adjacent to one of the cells to which the cross-link connects.

3. The integrated circuit chip device of claim 1 or 2, wherein each intermediate cell of the plurality of intermediate cells is connected to the cell above in the branch by a non-configurable link, and each intermediate cell of the plurality of intermediate cells is connected to the cell below in the branch by a non-configurable link.

4. The integrated circuit chip device of claim 1 or 2, wherein each cross-link is configurable.

5. The integrated circuit chip device of claim 4, wherein a cross-link connecting a first cell of a first branch and a first cell of a second branch is configurable to route a communication from the root cell to the first cell of the first branch, to the first cell of the second branch, to a destination cell of the second branch; and to route a communication from the destination cell of the second branch to the first cell of the second branch, to the first cell of the first branch, to the root cell.

6. The integrated circuit chip device of claim 5, wherein the first cell of the first branch is configured to, responsive to receiving a reconfiguration command from the root cell, reconfigure the first cell of the first branch to route a communication received for the destination cell of the second branch through the cross-link, and to route a communication received from the cross-link to the root cell.

7. The integrated circuit chip device of claim 6, wherein the first cell of the first branch is configured to send a reconfiguration command to the first cell of the second branch over the crosslink in response to receiving the reconfiguration command from the root cell.

8. The integrated circuit chip device of claim 7, wherein the first cell of the second branch is configured to reconfigure the first cell of the second branch to route communications received from the crosslink to the destination cell of the second branch and to route communications received from the destination cell over the crosslink to the first cell of the first branch in response to receiving the reconfiguration command from the first cell of the first branch over the crosslink.

9. The integrated circuit chip device of claim 5, wherein the crosslink is configurable to route communications from the root cell to the first cell of the second branch, to the first cell of the first branch, to a destination cell of the first branch; and to route communications from the destination cell of the first branch to the first cell of the first branch, to the first cell of the second branch, to the root cell.

10. The integrated circuit chip device of claim 9, wherein the first cell of the second branch is configured to reconfigure the first cell of the second branch to route communications received for the destination cell of the first branch through the crosslink and to route communications received from the crosslink to the root cell in response to receiving a reconfiguration command from the root cell.

11. The integrated circuit chip device of claim 10, wherein the first cell of the second branch is configured to send a reconfiguration command to the first cell of the first branch over the crosslink in response to receiving the reconfiguration command from the root cell.

12. The integrated circuit chip device of claim 11, wherein the first cell of the first branch is configured to reconfigure the first cell of the first branch to route communications received from the crosslink to the destination cell of the first branch and to route communications received from the destination cell over the crosslink to the first cell of the second branch in response to receiving the reconfiguration command from the first cell of the second branch over the crosslink.

13. The integrated circuit chip device of claim 1 or 2, wherein each of the plurality of intermediate cells comprises: a lower port having an input for receiving communications from the cell below and an output for sending communications to the cell below; and an upper port having an input for sending communications to the cell above and an input for receiving communications from the cell above. ​ 14. The integrated circuit chip apparatus of claim 13, wherein each of the plurality of intermediate cells comprises a multiplexer to selectively route one of the output of the lower port and the output of the upper port onto a crosslink connected to the respective intermediate cell.

15. The integrated circuit chip apparatus of claim 14, wherein the multiplexer is configured to select the output of the lower port or the output of the upper port in response to a reconfiguration command received from the root cell.

16. The integrated circuit chip apparatus of claim 13, wherein each of the plurality of intermediate cells comprises a de-multiplexer to selectively route communications from a crosslink connected to the cell to one of the input of the upper port and the input of the lower port.

17. The integrated circuit chip apparatus of claim 16, wherein the de-multiplexer is configured to select the input of the upper port or the input of the lower port in response to a reconfiguration command received from the root cell.

18. The integrated circuit chip apparatus of claim 13, wherein each of the plurality of intermediate cells comprises a switch to selectively route one of communications received from a cell below and communications received from the crosslink to the lower port input.

19. The integrated circuit chip apparatus of claim 13, wherein each of the plurality of intermediate cells comprises a gate connected to the output of the lower port to prevent communications from being sent to a cell below in response to the cell below being deemed defective.

20. The integrated circuit chip apparatus of claim 19, wherein the destination cell comprises a local subsystem, and wherein the destination cell is configured to route the communications to the local subsystem.

21. The integrated circuit chip apparatus of claim 20, wherein the root cell is configured to: receive a request to route the communications to the local subsystem; and in response to the request, reconfigure the plurality of intermediate cells to route the communications to the local subsystem.

Images