Addressing mechanism for system on chip

Abstract

Embodiments of the present disclosure relate to addressing mechanisms for a system on a chip. A method of reconfiguring an addressing mechanism in a system on a chip, the method comprising: sending a discovery message; receiving a discovery response from a cell, each discovery response identifying the cell and a number of individually addressable entities in those cells in a branch above the cell; in response to not receiving a response from one or more cells, determining that one of those cells is a defective cell; enabling a crosslink between a first cell in a same branch as the defective cell and a second cell in an adjacent branch; sending a further discovery message; receiving a further discovery response from the second cell, the further discovery response identifying the second cell, those cells in a branch above the second cell, the first cell, and those cells in a branch above the first cell; and reconfiguring an address of the crosslink.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a communication protocol on an integrated circuit chip device, and in particular to a mechanism for routing messages through circuitry of an integrated circuit chip device. BACKGROUND

[0002] In a system-on-chip (SoC) device, multiple core devices of an embedded system are integrated onto a single chip. Traffic in the embedded system is typically carried over a bus between the core devices. It is well known to incorporate monitoring functionality into the SoC to observe the traffic. For example, a monitoring unit can be associated with each core device for monitoring traffic to and from that core 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 the off-chip analyzer for detecting any improper operation of the core device.

[0003] It is desirable to minimize the on-chip area of the SoC dedicated to the monitoring circuitry. One efficient configuration of the monitoring network is a tree-based topology. In this topology, a root unit connects the monitoring network to an output port of the chip. Branches extend from the root unit through the SoC, each branch having multiple units connected in series. Each unit can route messages back and forth between its branch and the root unit. This network is very efficient for conveying messages of the monitoring circuitry around the SoC. However, in a tree-based topology, if one unit fails, then the units connected higher in the branch of the failed unit can no longer communicate with the root unit. In this situation, the entire SoC can be discarded due to the failure of a single unit of the monitoring circuitry.

[0004] In a network of nodes having a tree-based topology, it is well known to protect against failure of a single node by replicating the tree (in other words, by utilizing a second network of nodes having the same tree-based topology as the first network of nodes). If a node in the first network fails, then the failed node can be replaced with a corresponding node in the second network. Although efficient, this redundant tree approach requires duplicating the on-chip area dedicated to the network.

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

[0006] According to a first aspect of the disclosure, there is provided a method of reconfiguring an addressing mechanism in a system-on-chip, the system-on-chip 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 for routing communications through the system-on-chip, the tree-based structure comprising branches extending from a root cell, each branch comprising a plurality of cells, each cell being connected to a single cell above and a single cell below in the branch, whereby each cell routes communications to and from individual addressable entities above that cell in its branch, the tree-based structure further comprising cross-links connecting corresponding cells of adjacent branches. The method comprises: sending a discovery message; receiving a discovery response from a cell, each discovery response identifying the cell and a number of individual addressable entities in those cells above in the branch of that cell; in response to not receiving a response from one or more cells, determining one of those cells to be a defective cell; enabling a cross-link between a first cell in the same branch as the defective cell and a second cell in an adjacent branch; sending a further discovery message; receiving a further discovery response from the second cell, the further discovery response identifying the second cell, those cells above in the branch of the second cell, the first cell, and a number of individual addressable entities in those cells above in the branch of the first cell; and reconfiguring an address of the cross-link to cause subsequent communications with individual addressable entities in the branch of the defective cell to be routed via the adjacent branch and the cross-link, thereby bypassing the defective cell.

[0007] The method can further comprise reconfiguring an address of each of the intermediate cells of the adjacent branch between the second cell and the root cell to cause subsequent communications to be routed via the second cell.

[0008] The method can further comprise reconfiguring the root cell to prevent, for those communications for individual addressable entities of a destination cell, sending communications directly to the same branch as the defective cell, wherein the defective intermediate cell is located between the root cell and the destination cell.

[0009] The method can further comprise reconfiguring the root cell to, for those communications for individual addressable entities of a destination cell, send communications to individual addressable entities in the branch of the defective cell via the adjacent branch, wherein the defective intermediate cell is located between the root cell and the destination cell.

[0010] Each cell can operate in accordance with an addressing protocol in which each cell has an internal address that is the same as that of other cells in the tree-based structure as a base address, and in which each cell is configured to address other cells using an address derivable from its internal address relative to the location of the given other cell in the tree-based structure.

[0011] For each message sent from the root unit that includes a destination address of an individually addressable entity, the destination address is related to an internal address of the root unit, the method can include, at a next intermediate unit adjacent to the root unit: (i) receiving the message from the root unit; (ii) base resetting the message by adding an offset to the destination address to form a base reset address, the base reset address related to an internal address of the intermediate unit; and (iii) routing the base reset message to the individually addressable entity.

[0012] Each individually addressable entity can have an address index, and each unit can have one or more address indices.

[0013] The method can include determining the offset to be -m, where m is a number of address indices assigned to the next intermediate unit and a local subsystem directly connected to the next intermediate unit.

[0014] Each crosslink can have 0 address indices before determining that a unit is a defective unit.

[0015] Reconfiguring addresses of the crosslink can include assigning an address index to the crosslink.

[0016] The address index that can be assigned to the crosslink is 1.

[0017] The method can include determining, from the units that do not respond to the discovery message, a unit closest to the root unit in the branch as the defective unit.

[0018] The first unit can be adjacent to a defective unit, the defective unit being between the first unit and the root unit in the branch.

[0019] The method can further include, in response to failing to enable the crosslink between the first unit and the second unit, determining that the first unit is also a defective unit. Enabling another crosslink between a third unit in the same branch as the defective unit and a fourth unit in an adjacent branch, the third unit being adjacent to the first unit, the first unit being between the third unit and the defective unit; sending another discovery message; receiving another discovery response from the fourth unit, the another discovery response identifying the fourth unit, units in the branch above the fourth unit, the third unit, and units in the branch above the third unit; reconfiguring addresses of the other crosslink to enable subsequent communications with individually addressable entities in the branch of the defective unit to be routed via the adjacent branch and the other crosslink, thereby bypassing the defective unit.

[0020] Each unit can be connected to a unit above in the branch by an unconfigurable link, and can be connected to a unit below in the branch by an unconfigurable link.

[0021] Each cross-link can be configurable. BRIEF DESCRIPTION OF DRAWINGS

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

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

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

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

[0026] Figure 4 is a flow diagram illustrating a mechanism for enabling cross-links;

[0027] Figure 5 illustrates an example of a defective cell in a SoC;

[0028] Figure 6 illustrates another example of a defective cell in a SoC;

[0029] Figure 7 illustrates an example internal structure of a branch cell connected by a cross-link;

[0030] Figure 8 illustrates a branch cell configured to transmit upstream and downstream messages over a cross-link; Figure 7

[0031] Figure 9 is a flow diagram illustrating a mechanism for determining that a cell is a defective cell and bypassing the defective cell in subsequent communications;

[0032] Figure 10 illustrates an example of broadcasting an event message throughout a monitoring network of Figure 3

[0033] illustrates an example in which an event message is broadcast throughout a monitoring network of Figure 11 Figure 3 illustrates another example in which an event message is broadcast throughout a monitoring network of

[0034] Figure 12 Figure 3 illustrates yet another example in which an event message is broadcast throughout a monitoring network of DETAILED DESCRIPTION

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

[0036] 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.

[0037] 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.

[0038] 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 2One communication interface is illustrated, but any number of communication interfaces can be integrated onto the SoC. The implemented communication interfaces are chosen depending on the type of connection to be made. Exemplary communication interfaces include JTAG, parallel trace input / output, and high-speed serial interfaces based on Aurora; as well as reuse of system interfaces such as USB, Ethernet, RS232, PCIe, and CAN.

[0039] Figure 3 An exemplary structure of a SoC is illustrated. Routing units for routing messages by the monitoring circuitry of the SoC 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 a root unit located at the bottom of the tree-based structure. A lower port 301a of root unit 301 is connected to a communication interface 311. Different branches of the tree-based structure extend from upper ports 301b, 301c, and 301d of root unit 301. Thus, 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. A first branch extends from upper port 301b. This first branch includes units 302, 305, and 308. A second branch extends from upper port 301c. This second branch includes units 303, 306, and 309. A third branch extends from upper port 301d. This third branch includes units 304, 307, and 310.

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

[0041] Each unit can be directly connected to one or more local subsystems. In the illustrated example, unit 302 is directly connected to a 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, 315. Note that, for ease of illustration, only a few local subsystems are shown. Figure 3 In the illustrated example, unit 302 is directly connected to a 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, 315. Note that, for ease of illustration, only a few local subsystems are shown.Figure 3 Local subsystems directly connected to units 303 and 306 are omitted. Each unit has local ports 302c, 305c, etc. that connect to each of its local subsystems. The one or more local ports are separate and distinct from the unit's upper and lower ports. The local ports can be bidirectional to allow communication both from the unit to the local subsystem and from the local subsystem to the unit.

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

[0043] An analysis module can be configured to passively or actively observe the attached core device. An analysis module that passively observes a core device is limited to analyzing the core device's output. In contrast, an analysis module that actively observes a core device can analyze the core device's output and also control the core device to modify its operation. For example, an analysis module can control a core device to slow the speed of the core device's operation or to stop the core device's processor and / or to restart the processor again.

[0044] Each analysis module 317a, 317b is connected to a subsystem port 312a of the subsystem. Each subsystem port includes multiple individual ports, one for each analysis module. Thus, subsystem port 312a includes a port for analysis module 317a and a separate port for analysis module 317b. Analysis modules 317a, 317b generate messages that include data about the core devices 316a, 316b that the analysis modules are observing. For example, those messages can contain trace data of the core devices. Analysis modules output their messages to the connected branch unit 302 via their individual ports of their subsystem port 312a. Analysis modules can receive configuration messages from the connected branch unit 302 via subsystem port 312a. For example, these configuration messages can instruct the analysis modules to alter their monitoring of the core devices so that they wish to detect and report different activity. For example, a configuration message can instruct an analysis module to search for a particular value in the output of a core device or to report when the core device reads from a particular range of addresses in memory.

[0045] In an alternative arrangement, the local subsystem can have multiple analysis modules and a subsystem port consisting of only a single port. In this case, the local subsystem further comprises a routing unit which routes messages received at the port to the individual analysis modules and vice versa.

[0046] With reference to Figure 3 The described tree-based topology routes communications as follows. A communication intended for a destination unit in a branch is routed to the destination unit via intermediate units in the branch between the root unit 301 and the destination unit. For example, a message intended for the analysis module 318 of the subsystem 314 is routed from the root unit 301 via its upper port 301b to the lower port 302a of the branch unit 302. The branch unit 302 routes the message from its upper port 302b to the lower port 305a of the branch unit 305. The branch unit 305 routes the message from its upper port 305b to the lower port 308a of the branch unit 308. The branch unit 308 outputs the message from its local port 308c to the subsystem port 314a of the subsystem 314. The message is then passed to the analysis module 318. Communications from a branch unit to the root unit 301 are routed down the branch in a corresponding manner. Thus, all major communications in the system are routed up and down the branches only.

[0047] In Figure 3 In the illustrated arrangement, the root unit 301 routes data off-chip. The illustrated communication interface 311 is a USB port. The connection between the communication interface 311 and the root unit 301 is bidirectional. The root unit 301 outputs data received from the monitoring circuitry to the communication interface 311 for transmission off-chip. The data can comprise trace data. The data can comprise event data. The communication interface 311 also sends messages received from off-chip devices (e.g. an off-chip analyser) to the root unit 301. The data can comprise configuration messages for configuring one or more of the monitoring units. The root unit 301 routes messages from the communication interface 311 up the branches to the addressed units.

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

[0049] Typically, components on a SoC are arranged in a tiled array. In other words, the components are arranged in a square grid. With reference to Figure 3 The described tree-based monitoring network construction fits on a chip with the SoC components. Thus, if the components of a SoC take this arrangement, the physical layout of the branch units takes the form as Figure 3The illustrated rule stitching arrangement. However, the physical layout of the branch units can take a different arrangement in order to fit them if the SoC components take a different arrangement, while still preserving the relative connections between the branch units and the routing mechanism of the tree-based topology.

[0050] As described above, the main communication relating to the monitoring circuitry is passed around the branches of the tree-based topology on the SoC. However, as described in the background section, if one branch unit fails, then all those units in that branch which are connected higher up than the failed unit are no longer able to communicate with the root unit via that branch. Figure 3 The network of Figure 3 solves this problem.

[0051] Figure 3 Figure 3 illustrates the cross-links connecting the branches above the root unit 301. Each cross-link connects corresponding units of adjacent branches. Suitably, each cross-link connects only two units, which are in branches adjacent to each other. The units connected by a cross-link are at the same hierarchical level as each other. The units connected by a cross-link can have the same number of intermediate units between them and the root unit in their respective branches.

[0052] Figure 3 Figure 3 illustrates four hierarchical levels. Level 0 comprises the root unit 301. Level 1 is the hierarchical level adjacent to and higher than level 0. Level 1 comprises branch units 302, 303 and 304. Each of these branch units is directly connected to the root unit 301. Branch unit 303 is adjacent to and at the same hierarchical level as branch unit 302. Branch units 302 and 303 are connected by a cross-link 319. Likewise, branch unit 303 is connected to branch unit 304 by a cross-link 320.

[0053] Level 2 is the hierarchical level adjacent to and higher than level 1. Level 2 comprises branch units 305, 306 and 307. Each of these branch units has one intermediate unit between it and the root unit in its branch. Branch unit 306 is adjacent to and at the same hierarchical level as branch unit 305. Therefore, branch units 305 and 306 are connected by a cross-link 321. Likewise, branch unit 306 is connected to branch unit 307 by a cross-link 322.

[0054] Finally, level 3 is a hierarchical level adjacent to and above 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 crosslink 323. Corresponding branch units 309 and 310 are in adjacent branches and are connected by crosslink 324.

[0055] Each branch unit has a crosslink port for each crosslink it is connected to. Each crosslink is configurable. In particular, the direction of the crosslink is configurable. For a crosslink connecting a first unit in a first branch to a second unit in a second branch, the crosslink is configurable to:

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

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

[0058] In contrast, the direction of the links connecting the upper and lower ports of branch units within a branch is not configurable.

[0059] Initially, the crosslinks are not used for the main communication routing messages in relation to the monitoring circuitry around the SoC. However, if a branch unit is deemed to be defective, the crosslinks are enabled to bypass the defective unit. Reference is made to Figure 4 This is further described.

[0060] Figure 4 is a flowchart illustrating a scenario in which crosslinks are utilized. At step 401, messages are communicated up and down only along branches of the SoC. At step 402, a decision is made as to whether there is a defective branch unit in the SoC. If the answer is NO, the method returns to step 401, which communicates 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 unit being deemed defective, a crosslink is enabled between a branch unit above the defective unit in the same branch as the defective unit and a corresponding unit in an adjacent branch. Then, at step 404, subsequent messages are routed from the root unit to a destination unit in the same branch as the defective unit via the adjacent branch and the enabled crosslink. The defective unit is thereby bypassed.

[0061] Figure 5 a first example in which a unit is deemed defective in the SoC. In this example, the root unit is in a first branch and the destination unit is in a second branch.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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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 of FIG. 1, branch unit 302 is deemed to have a defect. Branch unit 302 is in the first branch. Defective unit 302 prevents messages from traversing the ring due to the analysis module in the first branch, i.e., from the analysis module in local subsystems 312, 313, 314, and 315. In response, crosslink 321 is enabled. Crosslink 321 is 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 between branch unit 305 and root unit 301. Crosslink 321 is enabled as follows.

[0066] In response to detecting that unit 302 has a defect, root unit 301 sends a reconfiguration command to unit 306 in the second branch. Root unit 301 can have 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 communications received at its lower port 306a over crosslink 321 to a destination unit in the first branch via crosslink port 306c, and (ii) route communications received at crosslink port 306c from crosslink 321 to root unit 301 via its lower port 306a.

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

[0068] Thus, unit 306 configures the direction of crosslink 321 so that uplink 321c routes messages from unit 306 to unit 305, and downlink 321d routes messages from unit 305 to unit 306. Thus, the crosslink is enabled to bypass defective unit 302, thereby enabling units above defective unit 302 in the first branch to send and receive messages.

[0069] Figure 5 and Figure 6 The example of FIG. 1 illustrates the same crosslink 321 having two configurations, with the uplink direction and the downlink direction opposite in the two configurations. The crosslink is configurable to adopt either configuration. The configuration adopted depends on which branch of the branches that the crosslink connects has a defective unit.

[0070] Figure 7 An example internal structure of a branch unit is illustrated. In Figure 7 In the example, two branch units 701a, 701b are illustrated at the same hierarchical level of adjacent branches. The two branch units are connected by a crosslink 702. Each branch unit includes a control module 713a, 713b for controlling the routing of received messages. Each branch unit includes a lower port 703a, 703b having a lower ingress 704a, 704b for receiving upstream messages and a lower egress 705a, 705b for sending messages downstream. Each branch unit includes other ports 706a, 706b. The other ports include an upper port having an upper ingress 707a, 707b for receiving downstream messages and an upper egress 708a, 708b for sending upstream messages. The other ports can include one or more other local ports for communicating with local subsystems, each local port having an ingress for receiving messages from a local subsystem and an egress for sending messages to a local subsystem.

[0071] The branch units include other components to enable them to route messages in either direction over the crosslink 702. Each branch unit includes a crosslink port having an ingress 714a, 714b and an egress 715a, 715b. Each branch unit includes a demultiplexer (DeMUX) 711a, 711b. The DeMUX is connected to the crosslink port and receives messages from another branch unit via the crosslink 702. The DeMUX is configured to selectively output messages received on the crosslink to either the crosslink ingress 714a or the lower ingress 704a. The DeMUX selects the output in response to a reconfiguration command received from the root unit. Thus, for example, if the crosslink is enabled to route a downstream message from branch unit 701b to branch unit 701a to the root unit 301, then DeMUX 711a selectively routes messages received over the crosslink 702 to the crosslink ingress 714a. Whereas if the crosslink is enabled to route an upstream message from the root unit 301 to branch unit 701b to branch unit 701a, then DeMUX 711a selectively routes messages received over the crosslink 702 to the lower ingress 704a.

[0072] The DeMUX can output messages to a reduced ingress 716a, 716b via a gearbox 717a, 717b. The gearbox 717a, 717b is narrower implementation when the width of downstream messages is greater than the width of upstream messages. The reduced ingress 716a, 716b routes all messages to the control module 713a, 713b. The reduced ingress 716a, 716b has no message FIFO, event FIFO, or routing control.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] Figure 8 illustrates when the cross-link is enabled to bypass a defective branch unit that is in the same branch as the unit 701a Figure 7 the internal configuration of the branch units 701a, 701b. Figure 8 illustrates Figure 6 the internal configuration of the branch units of the illustrated scenario, in which the branch unit 701a is equivalent to the branch unit 305 and the branch unit 701b is equivalent to the branch unit 306. In this scenario, the cross-link 702 / 321 is enabled to route upstream messages from the unit 701b / 306 to the unit 701a / 305. Also, the cross-link 702 / 321 is enabled to route downstream messages from the unit 701a / 305 to the unit 701b / 306. As with Figure 7 the default configuration of the branch units 305, 306, the unit 701b / 306 receives a reconfiguration command from the root unit 301. In response to the reconfiguration command, it (i) configures the MUX 710b to route messages from the cross-link egress 715b to the cross-link 702 / 321; and (ii) configures the DeMUX 711b to route messages received from the cross-link 702 / 321 to the cross-link ingress 714b.

[0078] In response to the reconfiguration command, the unit 701b / 306 also sends a reconfiguration command to the unit 701a / 305 over the cross-link 702 / 321. In response to receiving the reconfiguration command, the unit 701a / 305 (i) configures the MUX 710a to route messages from its lower egress 705a to the cross-link 702 / 321; and (ii) configures the DeMUX 711a to route messages received from the cross-link 702 / 321 to the lower ingress 704a. The unit 701a / 305 can also configure its message switch 712a to route messages from the cross-link 702 / 321 to the lower ingress 704a via the DeMUX 711a. This also prevents the input of the defective unit 302 from being connected to the lower ingress 704a, and thus avoids the false output of the defective unit 302 from being routed through the system. The unit 701a / 305 can also configure its gate 709a to gate the output of the lower egress 705a, so as to prevent messages from being output from the unit 701a / 305 to the defective unit 302. This saves power, as it avoids the defective component from receiving and processing messages.

[0079] More than one defective unit can be bypassed using the method described above. If two defective units are in the same branch and adjacent to each other, the same cross-link can be utilized to bypass both defective units. If two defective units are in the same branch but not adjacent to each other, different cross-links can be utilized to bypass the defective units, with one bypass route for each defective unit. If the defective units are in different branches, different cross-links can be utilized to bypass the defective units, with one bypass route for each defective unit.

[0080] A method by which one or more branch units can be deemed to have a defect is described below; as is an addressing mechanism that can be used to cause branch units to bypass defective units when routing messages through a tree-based system.

[0081] The addressing mechanism protocol described below allocates an address to each individually addressable entity in the system. Communications to and from an individually addressable entity are routed through the system via intermediate branch units in accordance with the address of the individually addressable entity. Each branch unit routes communications to and from individually addressable entities in its branch that are located above the unit. As described above, it can also route communications to and from individually addressable entities in adjacent branches via cross-links to bypass defective units.

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

[0083] At step 902, an assessment is made as to whether a discovery response has been received from each unit. For example, the root unit can be configured to wait for a predetermined time T for a response to the discovery request. If no response is received from a unit within this time T, the unit is deemed to be unresponsive. If a discovery response is received from each unit, the answer to step 902 is YES. If this is the case, at step 903, the main communications of the monitoring network are transmitted as normal only within the branches of the tree-based structure. If the answer to step 902 is NO, this indicates that there is one or more defective units in the same branch as one or more unresponsive units. It does not necessarily indicate that each unresponsive unit has a defect. For example, in the example of Figure 1, the root unit 301 can receive a discovery response from the branch unit 302 but not from the branch unit 303. This indicates that there is a defective unit in the same branch as the branch unit 302 but not in the same branch as the branch unit 303. The root unit 301 can then send a discovery request to the branch unit 303. If the branch unit 303 responds to the discovery request, this indicates that the branch unit 303 does not have a defect. If the branch unit 303 does not respond to the discovery request, this indicates that the branch unit 303 has a defect. Figure 6In the example of Figure 3, even if only unit 302 has a defect, no response to the discovery request is received from any of the units in the first branch.

[0084] At step 904, one or more unresponsive units are identified as having a defect. The unresponsive unit in the hierarchy level closest to the root unit can be deemed to have a defect. In other words, the unresponsive unit with the fewest intermediate units between it and the root unit can be deemed to have a defect. Suitably, this is the only unresponsive unit deemed to have a defect at this stage.

[0085] At the next step 905, a cross-link is enabled between a first unit in the same branch as the defective unit and a second unit in an adjacent branch. Suitably, the first unit is adjacent to the defective unit in the same branch as the defective unit. The defective unit is located between the first unit and the root unit in the branch. With reference to the example of Figure 3, the enabled cross-link can 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. Figure 6

[0086] At the next step 906, the root unit 301 sends a further discovery message. As with the discovery message of step 901, the further discovery message can be a single discovery message sent to all branch units in the tree-based structure. Alternatively, a single discovery message can be sent from the root unit 301 to each individually addressable entity in the system. The root unit 301 receives discovery responses from the units in the system. Each discovery response identifies the number of individually addressable entities in that unit and those units in the branch above that unit. If the cross-link of step 905 has been successfully enabled, the discovery response from the second unit corresponds to the discovery response from the second unit to the discovery request of step 901. In particular, the discovery response from the second unit will identify a greater number of individually addressable entities to which it can route messages compared to the discovery response from the second unit to the discovery request of step 901. 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 in: (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.

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

[0088] 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, then it indicates that there are other defective units elsewhere in the system. For example, in the example of Figure 6 , unit 308 can have a defect. The process from step 904 to 907 is repeated. In this iteration, the next non-responsive unit to be considered defective is the non-responsive unit at the hierarchical level closest to the root unit, excluding non-responsive units already considered defective.

[0089] 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 is not successfully enabled. In this case, if the answer to step 907 is NO, then at the next iteration of step 904, the root unit can determine that the first unit also has a defect. Referring to Figure 6 , this can mean that both units 302 and 305 in the first branch have defects. At step 905, a cross-link is enabled between a third unit in the same branch as the defective units and a fourth unit in an adjacent branch. The third unit is adjacent to the first unit. The first unit is between the third unit and the defective units. Referring to Figure 6 If both units 302 and 305 are considered defective, then a cross-link 323 is enabled. The cross-link 323 is between branch units 308 and 309. Branch unit 308 is adjacent to the defective unit 305 in the first branch.

[0090] The iterative loop from step 904 to step 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-responsive units, the method proceeds to steps 908, 909, and 910. At step 908, the address of each successfully enabled cross-link is reconfigured so as to cause subsequent communications with individually addressable entities in the branch of the defective unit to be routed via the adjacent branch and the enabled cross-link, thereby bypassing the defective unit.

[0091] At step 909, the address of each intermediate cell in the adjacent branch between the second cell and the root cell is reconfigured to cause subsequent communications with the separately addressable entities in the branch of the defective cell to be routed via the second cell. In Figure 6 In the example, this requires reconfiguring the address of cell 303 of the second branch so as to cause cell 303 to route messages intended for cell 305 and cells located above it in the first branch to cell 306 and crosslink 321 through the second branch.

[0092] At step 910, the root cell 301 is reconfigured in two ways. First, the root cell 301 is reconfigured to prevent it from sending communications directly to the same branch as the defective cell for those communications for a separately addressable entity of a destination cell where the defective intermediate cell is between the root cell and the destination cell. The root cell 301 is also reconfigured to send communications to the separately addressable entity in the branch of the defective cell via the adjacent branch for those communications for a separately addressable entity of a destination cell where the defective intermediate cell is between the root cell and the destination cell.

[0093] The method then proceeds to step 911 where the message is passed within the branch and through the enabled crosslink to bypass the defective cell.

[0094] An addressing protocol that can be used in conjunction with the method described above is described below. The addressing protocol makes use of a base address reset mechanism. In the base address reset mechanism, each cell considers itself to have the same internal address as other cells in the tree-based structure. This internal address is referred to hereinafter as the base address. Each cell is configured to address other cells using an address that is derivable from the internal address of that cell given the location of the other cell in the tree-based structure. Each cell through which a message passes on its way to a destination cell base address resets the destination address of the message.

[0095] Thus, for example, a root cell sends a message that includes a destination address of a separately addressable entity. The destination address is relative to the internal address of the root cell. The root cell sends the message to the branch to which it is connected. An intermediate cell adjacent to the root cell on the branch receives the message. The intermediate cell base address resets the message by adding an offset to the destination address to form a base address reset destination address. The base address reset destination address is relative to the internal address of the intermediate cell. The intermediate cell then routes the base address reset message to the separately addressable entity.

[0096] The base address reset mechanism can make use of address indices. For example, each separately addressable entity of a monitoring system can have an address index. Each branch cell can have one or more address indices. Reference is made toFigure 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 (illustrated as 2 at port 308c on Figure 3 ), and two address indices assigned to the two analysis modules of local subsystem 315 (illustrated as 2 at port 308b on Figure 3 ). No address indices are assigned to crosslink 323 (illustrated as 0 at port 308d). The internal address index of branch unit 308 itself is 1. Thus, when responding to the discovery request of step 901, branch unit 308 reports a total index number of 5 (= 2 + 2 + 0 + 1). Branch unit 305 has two address indices assigned to the two analysis modules of local subsystem 313, and five address indices assigned to branch unit 308 connected to the upper port of unit 305. No address indices are assigned to crosslink 321. The internal address index of branch unit 305 itself is 1. Thus, when responding to the discovery request of step 901, branch unit 305 reports a total index number of 8 (= 2 + 5 + 0 + 1). Branch unit 302 has two address indices assigned to the two analysis modules of local subsystem 312, and eight address indices assigned to branch unit 305 connected to the upper port of unit 302. No address indices are assigned to crosslink 319. The internal address index of branch unit 303 is 1. Thus, when responding to the discovery request of step 901, branch unit 303 reports a total index number of 11 (= 2 + 8 + 0 + 1).

[0097] 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 analysis module 325a of local subsystem 315 of branch unit 308, it applies an address index of 10 to the message, which is according to the address of analysis module 325a of root unit 301. Root unit 301 routes the message to its upper port 301b. The root unit base resets the address by adding an offset of -n, where n is the number of address indices assigned to the root unit itself. n = 1. Thus, the destination address of the base-reset message is 9.

[0098] Branching unit 302 receives the message. According to branching unit 302, the address of branching unit 302 is 0, the addresses of local subsystems 312 are 1-2, and the addresses of branching unit 305 are 3-11. From the perspective of branching unit 302, branching unit 302 base- resets the destination address of the message so that it is the address of analysis module 325a. The branching unit base- resets the address by adding the offset of -m, where m is the number of address indices assigned to the branching unit itself and the local subsystem directly connected to it (i.e., local subsystems 312). Thus, in this example, branching unit 302 subtracts 3, so the base-reset destination address is 6. Branching unit 302 routes the base-reset message to its upper port 302b, and from there to branching unit 305.

[0099] Branching unit 305 receives the message. According to branching unit 305, the address of branching unit 305 is 0, the addresses of local subsystems 313 are 1-2, and the addresses of branching unit 308 are 3-8. From the perspective of branching unit 305, branching unit 305 base- resets the destination address of the message so that it is the address of analysis module 325a. As described above, branching unit 305 subtracts 3, so the base-reset destination address is 3. Branching unit 305 routes the base-reset destination address to its upper port 305b, and from there to branching unit 308.

[0100] Branching unit 308 receives the message. According to branching unit 308, the address of branching unit 308 is 0, the addresses of local subsystems 314 are 1-2, and the addresses of local subsystems 315 are 3-4. As described above, branching unit 308 subtracts 3, so the base-reset destination address is 0. Branching unit 308 routes the base-reset message to its upper port 308b, and from there to local subsystem 315.

[0101] Analysis module 325a considers itself to have an address index of 0, and thus identifies itself as the destination unit for the received message.

[0102] Each crosslink in the system has an address index of 0 before it is determined that a unit in the system has a defect. By assigning an address index to the crosslink, 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.

[0103] 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).

[0104] 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.

[0105] 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.

[0106] 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 address indices up to 15 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 of the second branch.

[0107] Thus, as an example, in the re-indexed addressing mechanism, a message can be routed from the root unit 301 to the analysis module 501 of the local subsystem 326 as follows. The root unit 301 applies an address index of 14 to the message, which is according to the address of the analysis module 501 of the root unit 301. The root unit 301 routes the message to its upper port 301b and applies an offset of -1. The branch unit 302 receives the message with index 13. The branch unit 302 routes the message to its upper port 302b and applies an offset of -3. The branch unit 305 receives the message with index 10. The branch unit 305 routes the message to its crosslink port 305d and applies an offset of -8. The branch unit 306 receives the message with index 2. The branch unit 306 routes the message to its upper port 306b and applies an offset of -1. The branch unit 309 receives the message with index 1. The branch unit 309 routes the message to its local subsystem port 502 and applies an offset of -1. The local subsystem 326 receives the message with index 0. The analysis module 501 considers itself to have an address index of 0 and thus identifies itself as the destination address of the received message.

[0108] Generally, messages are transmitted within the tree-based system described above as follows: configuration messages in the upstream direction, which are used to configure the analysis modules to monitor the system circuitry; and messages in the downstream direction, which contain monitoring data generated by the analysis modules from monitoring of the system circuitry. In addition to these messages, event messages are also transmitted in the system. The analysis modules are configured to generate event messages in response to particular activity being detected by the core device that they are monitoring. For example, the analysis modules can be configured to generate event messages in response to their associated core device reading a particular range of addresses from memory. Suitably, the activity that causes the analysis modules to generate event messages can be configured during runtime.

[0109] Event messages propagate throughout the system. Other analysis modules respond to the receipt of event messages by taking action. The action can depend on the content of the event message. The event message may, for example, indicate a security or reliability problem. In response, the analysis modules can stop the operation of their associated core devices. As another example, in response to the event, they can adjust the activities of their associated core devices that they are monitoring. Event messages generated at analysis modules in the system are broadcast to all other units in the system. In other words, event messages are cross-triggered throughout the system.

[0110] Figure 10 Figures illustrate the broadcast of event messages throughout the monitoring network of Figure 3 Each branch unit forwards the event message through the system and to one or more local subsystems of itself. The event message is generated by an analysis module 325a in a local subsystem 315 of branch unit 308. Analysis module 325a sends the event message to branch unit 308. Branch unit 308 routes the event message upstream to analysis module 325b, to another local subsystem 314 of itself, and downstream to branch unit 305. Branch unit 308 does not send the event message back to the analysis module 325a that generated the event message. Branch unit 305 routes the event message to a local subsystem 313 of itself and downstream to branch unit 302. Branch unit 302 routes the event message to a local subsystem 312 of itself and downstream to root unit 301. Root unit 301 routes the event message upstream to the second branch and the third branch and downstream to communication interface 311 and 1005. In particular, root unit 301 routes the event message upstream to branch unit 303 and branch unit 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 an analysis module in local subsystem 326. Corresponding routing is imposed on the third branch.

[0111] When each branch unit receives and propagates the event message, a period of delay is incurred. Figure 10 The number of periods required for the event message to reach each of the units in the tree-based network is illustrated by the numbers in the circles next to each unit. Thus,

[0112] The event message reaches branch unit 308 in 1 period;

[0113] The event message reaches branch unit 305, local subsystem 314, and analysis module 325b in 2 periods;

[0114] The event message reaches branch unit 302 and local subsystem 313 in 3 periods.

[0115] It takes 4 cycles for the event message to reach root unit 301 and local subsystem 312;

[0116] It takes 5 cycles for the event message to reach branch units 303 and 304 and communication interfaces 311 and 1005;

[0117] It takes 6 cycles for the event message to reach branch units 306 and 307 and local subsystem 1004;

[0118] It takes 7 cycles for the event message to reach branch units 309 and 310 and local subsystem 1003; and

[0119] It takes 8 cycles for the event message to reach local subsystems 326, 1001 and 1002.

[0120] For such tree-based topologies in which messages are passed up and down the branches, the highest latency in routing event messages throughout the network is observed between components at the top of the hierarchy in different branches. Thus, although local subsystem 326 is physically close to local subsystem 315 from which the event message was generated, it observes the highest latency of 8 cycles for the event message to reach it. This is problematic because, generally, the analysis module that is physically closest to the analysis module that generated the event message is the analysis module that needs to respond to the event message most urgently, and thus needs to receive the event message most urgently.

[0121] Figure 11 Figures 1 and 2 illustrate the event message being broadcast throughout the monitoring network of Figure 3 Figures 1 and 2 illustrate the event message being broadcast throughout the monitoring network of Figure 7 Figures 1 and 2 illustrate the event message being broadcast throughout the monitoring network of

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

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

[0124] 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.

[0125] 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.

[0126] 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).

[0127] 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 number of cycles required for an event message to reach each cell in the tree-based network is illustrated by the numbers in the circles next to each cell. In comparison to the method using Figure 10 , 8 cycles, an event message requires 3 cycles to reach the physically closest local subsystem 326. In comparison to the method using Figure 10 , 8 cycles, an event message requires 4 cycles to reach local subsystems 1001 and 1002. Thus, the method described in relation to Figure 11 reduces the propagation delay of event messages between physically close subsystems. The longest propagation delay has also been reduced from 8 cycles to 6 cycles.

[0128] Figure 12 illustrates another example in which an event message is broadcast throughout the monitoring network of Figure 3 using the rules stated above. The event message is generated by the analysis module 501 in the local subsystem 326 of the branch cell 309. The branch cell 309 receives the event message from the analysis module 501, thus following rule 1 described above. The branch cell 309 routes the event message upstream to the analysis module 1201, downstream to the branch cell 306, through its crosslink 323 to the branch cell 308 and through its crosslink 324 to the branch cell 310. The branch cell 309 does not send the event message back to the analysis module 501 that generated the event message. The branch cells 308 and 310 receive the event message on the crosslinks, thus following rule 2 described above. The branch cell 308 routes the event message to its local subsystems 314 and 315 and downstream to the branch cell 305. The branch cell 308 has no other crosslink to route the event message to. The branch cell 310 routes the event message to its local subsystems 1001 and 1002 and downstream to the branch cell 307. The branch cell 310 has no other crosslink to route the event message to. The branch cells 305, 306, 307, 302, 303 and 304 receive the event message from the cell above them in the branch, thus following rule 3 described above. Thus, these branch cells route the event message downstream and to their local subsystems if they have local subsystems.

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

[0130] The manner in which the root unit 301 responds to receiving an event message can depend on whether a flag is set. If the root unit 301 receives an event message for which a flag is set, it can respond by routing the event message to only its lower port 301a. The event message is sent from its lower port 301a to one or more communication interfaces 311, 1005. The one or more communication interfaces can route the event message off-chip, e.g., to an off-chip analyzer. Alternatively, the one or more communication interfaces can route the event message to another on-chip module, e.g., an on-chip analyzer. If the root unit 301 receives an event message for which a flag is not set, it does not take any action. In other words, the root unit 301 does not route the event message to any other unit. This can prevent the event message from being broadcast indefinitely around the system. Since a flag is only set in the branch in which the event originated, the one or more communication interfaces only receive the event message from the root unit 301 once.

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

[0132] If a cross-link has been enabled to route communications between branches to bypass a defective unit, for the purposes of event message propagation, the cross-link is treated as either an uplink or a downlink. For example, if the cross-link is an uplink, then the event message is routed from the root unit to the defective unit via the cross-link, and then from the defective unit to the one or more units in the branch below the defective unit. If the cross-link is a downlink, then the event message is routed from the one or more units in the branch below the defective unit to the defective unit via the cross-link, and then from the defective unit to the one or more units in the branch above the defective unit. 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.

[0133] 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.

[0134] 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.

[0135] 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 , and Figures 10 to 12 Each component of the SoC shown in FIG. 1 can be implemented in software. Some components can be implemented in software while other components can be implemented in dedicated hardware.

[0136] The described SoC is suitably incorporated within a computing-based device. The computing-based device can be an electronic device. Suitably, the computing-based device comprises one or more processors for processing computer-executable instructions to control the operation of the device in order to implement the methods described herein. The computer-executable instructions can be provided using any computer-readable media such as memory. The methods described herein can be performed by software in machine-readable form on a tangible storage medium e.g. in executable program code. The software can be provided on a computer-readable medium such as a non-transitory computer-readable medium.

[0137] The above description describes the system circuitry and the monitoring circuitry as being comprised on the same SoC. In an alternative implementation, the system circuitry and the monitoring circuitry are comprised on two or more integrated circuit chips of an MCM. In an MCM, the integrated circuit chips are typically stacked or positioned adjacent on an interposer substrate. Some system circuitry can be located on one integrated circuit chip while other system circuitry can be located on a different integrated circuit chip of the MCM. Likewise, the monitoring circuitry can be distributed over more than one integrated circuit chip of the MCM. Thus, the methods and apparatus described above in the context of a SoC are also applicable in the context of an MCM.

[0138] The applicant hereby discloses separately each feature referred to, or recited separately in any combination of two or more of such features, and each of the individual features disclose separately, or in any combination of two or more of such features, can be implemented in the practice of this application, without regard to whether such feature is literally disclosed or claimed in the same claim as any other feature. The applicant reserves the right to disclaim any feature recited in the claims, alone or in any combination or subcombination of features, as inappropriate to the practice of this application. It will be apparent to those skilled in the art that various modifications can be made in the present application without departing from the scope of the application.

Claims

1. A method of reconfiguring an addressing mechanism in a system-on-chip, the system-on-chip comprising system circuitry and monitoring circuitry for monitoring the system circuitry, the monitoring circuitry comprising cells connected in a tree-based structure, the cells for routing communications through the system-on-chip, the tree-based structure comprising branches extending from a root cell, each branch comprising a plurality of cells, each cell connected to a single cell above it in the branch and a single cell below it in the branch, whereby each cell routes communications to and from individual addressable entities above it in the cells of its branch, the tree-based structure further comprising cross-links connecting corresponding cells of adjacent branches, the method comprising: sending a discovery message; receiving a discovery response from the cells, each discovery response identifying the cell and a number of individual addressable entities in those cells of the branch above the cell; in response to not receiving a response from one or more cells, determining one of those cells to be a defective cell; enabling a cross-link between a first cell in the same branch as the defective cell and a second cell in an adjacent branch; sending a further discovery message; receiving a further discovery response from the second cell, the further discovery response identifying the second cell, a number of individual addressable entities in those cells of the branch above the second cell, the first cell, and a number of individual addressable entities in those cells of the branch above the first cell; and reconfiguring addresses of the cross-link to cause subsequent communications with individual addressable entities in the branch of the defective cell to be routed via the adjacent branch and the cross-link, thereby bypassing the defective cell.

2. The method of claim 1, further comprising: reconfiguring addresses of each of the cells of the adjacent branch between the second cell and the root cell to cause the subsequent communications to be routed via the second cell.

3. The method of claim 1 or 2, further comprising: reconfiguring the root cell to prevent communications being sent directly to the same branch as the defective cell for those communications for individual addressable entities of a destination cell, wherein the defective cell is between the root cell and the destination cell.

4. The method of claim 1 or 2, further comprising: reconfiguring the root cell to send communications to individual addressable entities in the branch of the defective cell via the adjacent branch for those communications for individual addressable entities of a destination cell, wherein the defective cell is between the root cell and the destination cell.

5. The method of claim 1 or 2, wherein each cell operates in accordance with an addressing protocol, wherein each cell has an internal address that is the same as other cells in the tree-based structure as a base address, and wherein each cell is configured to address other cells using an address derivable with respect to its internal address given the location of the given other cell in the tree-based structure.

6. The method of claim 5, wherein for each message sent from the root unit that includes a destination address of an individually addressable entity, the destination address is related to an internal address of the root unit, the method comprising: at a next intermediate unit adjacent to the root unit: (i) receiving the message from the root unit; (ii) base- resetting the message by adding an offset to the destination address to form a base-reset address, the base-reset address related to an internal address of the intermediate unit; and (iii) routing the base-reset message to the individually addressable entity.

7. The method of claim 1 or 2, wherein each individually addressable entity has an address index, and each unit has one or more address indices. determining the offset to be -m, where m is the number of address indices assigned to the next intermediate unit and to the local subsystem directly connected to the next intermediate unit.

8. The method of claim 6, comprising:

9. The method of claim 7, wherein each crosslink has 0 address indices prior to determining that a unit is a defective unit. allocating an address index to the crosslink.

10. The method of claim 9, wherein reconfiguring the address of the crosslink comprises:

11. The method of claim 10, wherein the crosslink is allocated an address index of 1. from the units that do not respond to the discovery message, determining the unit closest to the root unit in the branch to be the defective unit.

12. The method of claim 1 or 2, comprising:

13. The method of claim 12, wherein the first unit is adjacent to the defective unit, the defective unit being between the first unit and the root unit in the branch.

14. The method of claim 13, further comprising: in response to failing to enable the crosslink between the first unit and the second unit, determining that the first unit is also a defective unit; enabling another crosslink between a third unit in the same branch as the defective unit and a fourth unit in an adjacent branch, the third unit being adjacent to the first unit, the first unit being between the third unit and the defective unit; sending another discovery message; receiving another discovery response from the fourth unit, the another discovery response identifying the fourth unit, those units in the branch above the fourth unit, the third unit, and those units in the branch above the third unit; and reconfiguring addresses of the another crosslink to enable subsequent communications with individually addressable entities in the branch of the defective unit to be routed via the adjacent branch and the another crosslink, thereby bypassing the defective unit.

15. The method of claim 1 or 2, wherein each unit is connected to the units above and below in the branch by non-configurable links.

16. The method of claim 1 or 2, wherein each crosslink is configurable. ​

Images