Tracking a state of a programmable device

Abstract

Tracking a state of a programmable device can include determining, using a processing unit on the programmable device, tracking data for a device image for the programmable device in response to loading the device image, storing the tracking data for the device image in a memory by the processing unit, and recording, in the tracking data in the memory, an unload of the device image in response to unloading the device image.

Description

Technical Field

[0001] This disclosure relates to tracking the status of programmable devices such as programmable integrated circuits (ICs). Background Technology

[0002] Integrated circuits (ICs) can be implemented to perform a variety of functions. Some ICs can be programmed to perform specific functions. An example of a programmable IC is a field-programmable gate array (FPGA). An FPGA consists of programmable logic, which is typically implemented as an array of programmable blocks. These programmable blocks can include, for example, input / output blocks (IOBs), configurable logic blocks (CLBs), dedicated random access memory blocks (BRAMs), multipliers, and digital signal processing blocks (DSPs).

[0003] Other types of programmable ICs may include additional resources that can be used in conjunction with programmable logic. Examples of these additional resources may include, but are not limited to, hardwired circuitry such as processors, memory controllers, and transceivers, which, although hardwired differently from the programmable logic, can still be programmed to operate in one of several different operating states or modes.

[0004] The extensive programmability of modern devices, combined with the fact that these devices can be continuously reconfigured (e.g., completely reconfigured) and / or partially reconfigured over time, means that knowing the specific operational state of a device in real time at any given point may not be feasible. This makes activities such as debugging, application development for the device, and device management difficult. Summary of the Invention

[0005] In one aspect, a method may include: in response to loading a device image for a programmable device, determining trace data for the device image using a processing unit on the programmable device; storing the trace data for the device image in a memory via the processing unit; and in response to unloading the device image, recording the unloading of the device image in the trace data in the memory.

[0006] In another aspect, a device may include a plurality of programmable circuit resources and may include a processor configured to program the programmable circuit resources. The processor may initiate executable operations including: determining trace data for the device image in response to loading a device image for the device, wherein the device image includes programming data for one or more of the plurality of programmable circuit resources; storing the trace data for the device image in memory; and recording the unloading of the device image in the trace data in memory in response to unloading the device image.

[0007] This "Summary of the Invention" section is provided merely to introduce certain concepts and not to identify any key or essential features of the claimed subject matter. Other features of the invention will become apparent from the accompanying drawings and the following detailed description. Attached Figure Description

[0008] The arrangement of the invention is illustrated by way of example in the accompanying drawings. However, the drawings should not be construed as limiting the arrangement of the invention to the specific embodiments shown. Various aspects and advantages will become apparent after reading the following detailed description and referring to the accompanying drawings.

[0009] Figure 1 An example architecture of a programmable device is illustrated.

[0010] Figure 2 The diagram shows... Figure 1 Certain structural and functional aspects of programmable devices.

[0011] Figure 3 The diagram illustrates the combination. Figure 1 An example implementation of the Platform Management Controller (PMC) described.

[0012] Figure 4 Another example architecture of a programmable device is illustrated.

[0013] Figure 5 The diagram illustrates the use of bonding Figure 1 The example operation method of PMC is described. Detailed Implementation

[0014] Although this disclosure concludes with claims defining novel features, it is to be understood that a better understanding of the various features described herein will be achieved by considering this specification in conjunction with the accompanying drawings. The processes(s), machines(s), manufactures, and any variations thereof described herein are provided for illustrative purposes. Specific structural and functional details described in this disclosure should not be construed as limiting, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art to employ the described features differently with virtually any suitable detailed structure. Furthermore, the terminology and phrases used in this disclosure are not intended to be limiting, but rather to provide an understandable description of the described features.

[0015] This disclosure relates to tracking the state of a programmable device, such as a programmable integrated circuit (IC). According to the inventive arrangements described in this disclosure, the state of the programmable device (e.g., an IC) can be tracked over time. The programmable device includes a processor capable of tracking the state of the programmable device over time regarding the loading and / or unloading of device images therein. For example, as different device images are loaded into the programmable device over time, information related to each device image can be stored by the processor. When a device image is unloaded from the programmable device, the processor can store additional information related to the unloading of each device image. In one aspect, the processor is capable of storing information in real time as device images are loaded into and / or unloaded from the programmable device.

[0016] A history of different computing units and / or user-specified circuits implemented in a programmable device is created by storing information related to the loading and / or unloading of device images for that programmable device over time. This history, created by the programmable device itself rather than by an external system, can be read and used for debugging or other analytical purposes. In one aspect, the processor that creates the history in the programmable device is the same processor responsible for loading and unloading the device images. Thus, the history represents a complete picture of the different device images loaded into and unloaded from the programmable device over time.

[0017] In the case of conventional programmable devices, the effort to track the device state over time is typically performed by an external system. For example, a host system can use the programmable device as an accelerator. In this way, the host system can track any device image that the host system itself provides to the programmable device over time. However, modern programmable devices typically have multiple distinct and independent communication paths through which device images can be loaded. Some of these communication paths are not observable by the host system. Therefore, the host system cannot track each of these communication paths.

[0018] As an illustrative and non-limiting example, a programmable device may have a Peripheral Component Interconnect Fast (PCIe) connection to a host system, a Joint Test Action Group (JTAG) port to another system, and / or an Ethernet connection to yet another external system. The host system may only be able to track the device image provided to the programmable device via the PCIe connection. However, the programmable device may obtain the device image via JTAG or Ethernet without the host system's knowledge. In this example, any historical record created by the host system would be incomplete and inaccurate.

[0019] Given the number of times programmable devices can be reconfigured and / or reprogrammed using new device images, and the number of times modern devices can be loaded with multiple different device images simultaneously, tracking the state of device images over time is becoming increasingly important for debugging, performance analysis, and system development purposes.

[0020] Other aspects of the arrangement of the invention will now be described in more detail with reference to the accompanying drawings. For purposes of simplification and clarity, the elements shown in the drawings are not necessarily drawn to scale. For example, the dimensions of some elements may be enlarged relative to others for clarity. Furthermore, reference numerals are repeated in the drawings where deemed appropriate to indicate corresponding, similar, or analogous features.

[0021] Figure 1 The illustration depicts an example architecture for a programmable device 100. Programmable device 100 is an example of a programmable IC and an adaptive system. In one aspect, programmable device 100 is also an example of a system-on-a-chip (SoC). Figure 1 In one example, the programmable device 100 is implemented on a single die provided within a single integrated package. In other examples, the programmable device 100 can be implemented using multiple interconnect dies, wherein... Figure 1 The various programmable circuit resources illustrated in the diagram are implemented across different interconnect dies.

[0022] In the example, programmable device 100 includes a data processing engine (DPE) array 102, programmable logic (PL) 104, processor system (PS) 106, on-chip network (NoC) 108, platform management controller (PMC) 110, and one or more hardwired circuit blocks 112. A configuration frame interface (CFI) 114 is also included.

[0023] The DPE array 102 is implemented as multiple interconnected and programmable data processing engines (DPEs) 116. The DPEs 116 can be arranged in the array and hardwired. Each DPE 116 may include one or more cores 118 and memory modules. Figure 1(abbreviated as "MM") 120. In one aspect, each core 118 is capable of executing program code stored in a core-specific program memory contained within each corresponding core 118 (not shown). Each core 118 has direct access to memory modules 120 within the same DPE 116, and direct access to memory modules 120 of any other DPE 116 adjacent to core 118 of DPE 116 in the top, bottom, left, and right directions. For example, core 118-5 can directly read memory modules 120-5, 120-8, 120-6, and 120-2. Core 118-5 treats each of memory modules 120-5, 120-8, 120-6, and 120-2 as a uniform region of memory (e.g., as part of local memory accessible to core 118-5). This facilitates data sharing among different DPEs 116 in DPE array 102. In other examples, core 118-5 can be directly connected to memory module 120 in another DPE.

[0024] DPE 116 are interconnected via programmable interconnect circuitry. Programmable interconnect circuitry may include one or more distinct and independent networks. For example, programmable interconnect circuitry may include a stream network formed by stream connections (shaded arrows) and a memory-mapped network formed by memory-mapped connections (crossed shaded arrows). Memory-mapped connections transmit configuration data between DPE 116. The term "configuration data" in relation to DPE array 102 refers to data used for programming and / or configuring core 118, including program instructions stored in program memory and data written to control registers within DPE 116 to control their operation. Appropriate master circuitry (e.g., PS 106 and / or PMC 110) can be written to any addressable register (e.g., memory modules, program memory, and / or control registers) within DPE 116 via memory-mapped connections.

[0025] Streaming connections enable communication using packet-based data (e.g., as opposed to establishing connectivity based on each bit in the case of PL 104). Typically, application data is transmitted over the streaming connection. The term "application data" refers to data operated by or generated by core 118. Streaming connections can be programmed to operate as circuit-switched streaming connections, which enable point-to-point dedicated streams suitable for high-bandwidth communication within DPE 116, or as packet-switched streaming connections, where streams are shared to time-division multiplex multiple logical streams onto a single physical stream for medium-bandwidth communication.

[0026] Configuration data is loaded into the control registers of DPE 116 via memory-mapped links, allowing independent control of each DPE 116 and its components. DPE 116 can be enabled / disabled on a per-DPE basis. For example, each core 118 can be configured to access the described memory module 120 or only a subset thereof to achieve isolation of core 118 or multiple cores 118 operating as a cluster. Each stream connection can be configured to establish logical connections only between selected DPEs 116 within DPE 116 to achieve isolation of DPE 116 or multiple DPEs 116 operating as a cluster. Because each core 118 can be loaded with core-specific program code, each DPE 116 can implement one or more different cores within it.

[0027] In other respects, the programmable interconnect circuitry within the DPE array 102 may include additional, separate networks, such as debug networks, which are independent (e.g., different from and separate) from stream connections and memory-mapped connections and / or event broadcast networks. In some respects, the debug network is formed by memory-mapped connections and / or is a part of a memory-mapped network.

[0028] Core 118 can be directly connected to adjacent Core 118 via a core-to-core cascading connection. In one aspect, a core-to-core cascading connection is a unidirectional and direct connection between Core 118, as shown in the figure. In another aspect, a core-to-core cascading connection is a bidirectional and direct connection between Core 118. Activation of the core-to-core cascading interface can also be controlled by loading configuration data into the control register of the corresponding DPE 116.

[0029] In the example implementation, DPE 116 does not include a cache memory. By omitting the cache memory, DPE array 102 can achieve predictable (e.g., deterministic) performance. Furthermore, significant processing overhead is avoided because it is not necessary to maintain consistency between cache memories located in different DPEs 116. In another example, core 118 has no input interrupts. Therefore, core 118 can operate uninterruptedly. Omitting input interrupts to core 118 also allows DPE array 102 to achieve predictable (e.g., deterministic) performance.

[0030] The SoC interface block 122 operates as an interface for connecting the DPE 116 to other resources of the programmable device 100. Figure 1In the example, SoC interface block 122 includes multiple interconnected blocks 124 organized in rows. In certain embodiments, different architectures can be used to implement blocks 124 within SoC interface block 122, with each different block architecture supporting communication with different resources of programmable device 100. Blocks 124 are connected so that data can propagate bidirectionally from one block to another. Each block 124 can operate as an interface for direct access to columns of DPE 116 above.

[0031] Using stream connections and memory-mapped connections as shown, block 124 is connected to adjacent blocks, the DPE 116 directly above it, and the circuitry below it. Block 124 may also include a debug network connected to a debug network implemented in the DPE array 102. Each block 124 is capable of receiving data from another source and / or another hardwired circuitry block 112, such as PS 106, PL 104. For example, block 124-1 is capable of providing data (whether application or configuration) addressed to DPE 116 in the upper column to such DPE 116, while sending data addressed to DPE 116 in other columns to other blocks 124 (e.g., 124-2 or 124-3), so that such blocks 124 can accordingly route data addressed to DPE 116 in their respective columns.

[0032] In one aspect, the SoC interface block 122 includes two different types of blocks 124. The first type of block 124 has an architecture configured to serve solely as an interface between DPE 116 and PL 104. The second type of block 124 has an architecture configured to serve as an interface between DPE 116 and NoC 108, and between DPE 116 and PL 104. The SoC interface block 122 may include a combination of the first and second types of blocks, or only the second type of blocks.

[0033] PL 104 is a circuit device that can be programmed to perform a specified function. As an example, PL 104 can be implemented as a circuit device of the field-programmable gate array (FPGA) type. PL 104 may include an array of programmable circuit blocks. As defined herein, the term "programmable logic" refers to a circuit device used to construct reconfigurable digital circuits. Programmable logic consists of a number of programmable circuit blocks, sometimes referred to as "blocks," which provide basic functionality. Unlike hardwired circuit devices, the topology of PL 104 is highly configurable. Each programmable circuit block of PL 104 typically includes programmable elements 126 (e.g., functional elements) and programmable interconnects 142. Programmable interconnects 142 provide the highly configurable topology of PL 104. For example, programmable interconnects 142 can be configured on a per-line basis to provide connectivity between programmable elements 126 of the programmable circuit blocks of PL 104, and unlike connectivity between DPEs 116, they are configurable on a per-bit basis (e.g., where each line transmits a single bit of information).

[0034] Examples of programmable circuit blocks in PL 104 include configurable logic blocks with lookup tables and registers. Unlike hard-wired circuit devices described below and sometimes referred to as hard blocks, these programmable circuit blocks have undefined functionality at the time of manufacture. PL 104 may include other types of programmable circuit blocks that also provide basic and defined functionality with more limited programmability. Examples of these circuit blocks may include digital signal processing blocks (DSPs), phase-locked loops (PLLs), and block random access memory (BRAMs). Like other programmable circuit blocks in PL 104, these types of programmable circuit blocks are numerous and intermingled with other programmable circuit blocks in PL 104. These circuit blocks may also have an architecture that typically includes programmable interconnects 142 and programmable elements 126, and are therefore part of the highly configurable topology of PL 104.

[0035] Before use, the PL 104 (e.g., programmable interconnects and programmable elements) must be programmed or "configured" by loading data, referred to as a configuration bitstream, into its internal configuration memory cells. Once the configuration bitstream is loaded, the configuration memory cells define how the PL 104 is configured (e.g., topology) and operated (e.g., performing specific functions). Within this disclosure, "configuration bitstream" is not equivalent to program code executable by a processor or computer.

[0036] PS 106 is implemented as a hardwired circuit device that is manufactured as part of programmable device 100. PS 106 can be implemented as or include any of a variety of different processor types, each capable of executing program code. For example, PS 106 can be implemented as a single processor, such as a single core capable of executing program code. In another example, PS 106 can be implemented as a multi-core processor. In yet another example, PS 106 may include one or more cores, modules, coprocessors, I / O interfaces, and / or other resources. PS 106 can be implemented using any of a variety of different types of architectures. Example architectures that can be used to implement PS 106 may include, but are not limited to, ARM processor architecture, x86 processor architecture, graphics processing unit (GPU) architecture, mobile processor architecture, DSP architecture, combinations of the foregoing architectures, or other suitable architectures capable of executing computer-readable instructions or program code.

[0037] NoC 108 is a programmable interconnect network for sharing data between endpoint circuits in programmable device 100. Endpoint circuits may be located in DPE array 102, PL 104, PS 106, and / or selected hardwired circuit block 112. NoC 108 may include high-speed data paths with dedicated switching. In one example, NoC 108 includes one or more horizontal paths, one or more vertical paths, or both horizontal and vertical paths. Figure 1 The arrangement and number of areas shown are merely an example. NoC 108 is an example of a general infrastructure within the programmable device 100 that can be used to connect selected components and / or subsystems.

[0038] Within NoC 108, the network to be routed through NoC 108 is unknown until the user circuit design is created for implementation within Programmable Device 100. NoC 108 can be programmed by loading configuration data into its internal configuration registers. This configuration data defines how components within NoC 108 (such as switches and interfaces) are configured and operated to pass data from switch to switch and between NoC interfaces to connect endpoint circuits. NoC 108 is manufactured as part of Programmable Device 100 (e.g., hardwired) and, while not physically modifiable, can be programmed to establish connections between different master and slave circuits in the user circuit design. NoC 108 does not implement any data paths or routes upon power-up. However, once configured by PMC 110, NoC 108 implements data paths or routes between endpoint circuits.

[0039] For illustrative purposes, NoC 108 may include NoC Master Unit (NMU) 128, NoC Slave Unit (NSU) 130, network 132, NoC Peripheral Interconnect (NPI) 134, and register 136. Each NMU 128 is an ingress circuit that connects endpoint circuits to NoC 108. Each NSU 130 is an egress circuit that connects NoC 108 to endpoint circuits. NMU 128 is connected to NSU 130 via network 132. In one example, network 132 includes a route 140 between NoC Packet Switch 138 (NPS) and NPS 138. Each NPS 138 performs NoC packet switching. NPS 138 are interconnected and connected to NMU 128 and NSU 130 via route 140 to implement multiple physical channels. NPS 138 also supports multiple virtual channels for each physical channel.

[0040] NPI 134 includes circuitry for programming NMU 128, NSU 130, and NPS 138. For example, NMU 128, NSU 130, and NPS 138 may include register 136 that defines their function. NPI 134 includes peripheral interconnects coupled to register 136 for programming NPI 134 to set up functionality. Register 136 in NoC 108 supports interrupts, Quality of Service (QoS), error handling and reporting, transaction control, power management, and address mapping control. Register 136 can be initialized to an available state before being reprogrammed (e.g., by writing to register 136 via a write request using PMC 110). Configuration data for NoC 108 can be stored in non-volatile memory (NVM), for example, as part of a device image, and provided to NPI 134 for programming NoC 108 and / or other endpoint circuitry. NPI 134 can also be used by PMC110 to program one or more hardwired circuit blocks in hardwired circuit block 112.

[0041] The endpoint circuits coupled to NMU 128 and NSU 130 can be hardened circuitry (e.g., hardwired circuit block 112), circuitry implemented in PL 104, components in PS 106, and / or circuitry devices in DPE array 102. A given endpoint circuit can be coupled to more than one NMU 128 or more than one NSU 130. In this example, the endpoint circuit is connected to other endpoint circuits via NoC 108. For example, the primary endpoint circuit is coupled to NMU 128. The endpoint circuit is coupled to NSU 130.

[0042] Network 132 includes multiple physical channels. These physical channels are implemented by programming NoC 108. Each physical channel includes one or more NPS 138s and an associated route 140. The NPS 138s are coupled to each other to form a matrix of switches. NMU 128 is connected to NSU 130 via at least one physical channel and optionally one or more virtual channels. Connections through network 132 use a master-slave arrangement. In one example, the most basic connection on network 132 involves a single master device connected to a single slave device. However, in other examples, more complex structures can be implemented.

[0043] NoC 108 can be programmed and / or used as part of a larger boot or programming process, or programmed independently of other resources of the programmable device 100. Typically, programming NoC 108 may include: PMC 110 receiving NoC configuration data at boot time and loading the configuration data therein at boot time. NoC 108 can also be programmed at runtime. NoC programming data may be part of the device image.

[0044] PMC 110 is responsible for managing programmable device 100. PMC 110 is a subsystem within programmable device 100 that manages other programmable circuit resources across the entire programmable device 100. PMC 110 maintains a safe and reliable environment, boots programmable device 100, and manages programmable device 100 during normal operation. For example, PMC 110 provides unified and programmable control over different programmable circuit resources of programmable device 100 (e.g., DPE array 102, PL 104, PS 106, and NoC 108) for power-on, boot / configuration, security, power management, security monitoring, debugging, and / or error handling. PMC 110 operates as a dedicated platform manager that decouples PS 106 from PL 104. Thus, PS 106 and PL 104 can be managed, configured, and / or powered on and / or powered off independently of each other.

[0045] In one respect, PMC 110 can operate as a root-of-trust for the entire programmable device 100. As an example, PMC 110 is responsible for authenticating and / or verifying a device image containing configuration data for any programmable resources within the programmable resources of the programmable device 100, which can be loaded into the programmable device 100. PMC 110 can also protect the programmable device 100 from tampering during operation. By operating as a root of trust for the programmable device 100, PMC 110 can monitor the operation of PL 104, PS 106, and / or any other programmable circuit resources that may be included in the programmable device 100. The root of trust capabilities performed by PMC 110 are distinct from and separate from any operations performed by PS 106 and PL 104 and / or by PS 106 and / or PL 104.

[0046] In one respect, PMC 110 operates on a dedicated power supply. Thus, PMC 110 is powered by a separate and independent power supply from PS 106 and PL 104. This power independence allows PMC 110, PS 106, and PL 104 to protect each other from electrical noise and glitches. Furthermore, while PMC 110 continues to operate, one or both of PS 106 and PL 104 can be powered off (e.g., suspended or placed in sleep mode). This capability allows any part of the programmable device 100 that has been powered off (e.g., PL 104, PS 106, NoC 108, etc.) to be woken up and restored to an operational state more quickly without requiring a complete power-on and boot process for the entire programmable device 100.

[0047] PMC 110 can be implemented as a processor with dedicated resources. PMC 110 may include multiple redundant processors. The processors of PMC 110 are capable of executing firmware. The use of firmware supports the configurability and segmentation of global features of programmable device 100, such as reset, clock, and protection, to provide flexibility in creating separate processing domains, which are different from the "power domain" that can be specific to a subsystem. A processing domain may involve a mixture or combination of one or more different programmable circuit resources of programmable device 100 (e.g., where a processing domain may include different combinations or devices from DPE array 102, PS 106, PL 104, NoC 108 and / or other hardwired circuit blocks 112).

[0048] Hardwired circuit block 112 includes a dedicated circuit block manufactured as part of programmable device 100. Although hardwired, hardwired circuit block 112 can be configured to implement one or more different operating modes by loading configuration data into a control register. Examples of hardwired circuit block 112 may include input / output (I / O) blocks, transceivers for sending and receiving signals to and from circuitry and / or systems outside programmable device 100, memory controllers, etc. Examples of different I / O blocks may include single-ended I / O and pseudo-differential I / O. Examples of transceivers may include high-speed differential clock transceivers. Other examples of hardwired circuit block 112 include, but are not limited to, cryptographic engines, digital-to-analog converters (DACs), analog-to-digital converters (ADCs), etc. Typically, hardwired circuit block 112 is a dedicated circuit block.

[0049] CFI 114 is an interface through which configuration data, such as configuration bitstreams, can be provided to PL 104 for implementing various user-specified circuits and / or circuit devices. CFI 114 is coupled to and accessible by PMC 110 to provide configuration data to PL 104. In some cases, PMC 110 may first configure PS 106, such that once PS 106 is configured by PMC 110, configuration data can be provided to PL 104 via CFI 114. In one aspect, CFI 114 has a built-in Cyclic Redundancy Check (CRC) circuit (e.g., a 32-bit CRC circuit). Thus, any data loaded into and / or read back via CFI 114 can be checked for integrity by examining the value of the code appended to the data.

[0050] Figure 1 The various programmable circuit resources illustrated in the diagram can initially be programmed as part of the boot process of the programmable device 100. During runtime, the programmable circuit resources can be reconfigured. In one aspect, the PMC 110 is capable of initially configuring the DPE array 102, PL 104, PS 106, and NoC 108. At any point during runtime, the PMC 110 can reconfigure all or part of the programmable device 100. In some cases, once PS 106 is initially configured by the PMC 110, PL 104 and / or NoC 108 can be configured and / or reconfigured.

[0051] Figure 2 The illustrations show some structural and functional aspects of the programmable device 100. Figure 2The example illustrates how programmable device 100 can be used for partial reconfiguration. Partial reconfiguration is a process in which a region of a specific programmable circuit resource within programmable device 100, referred to as a reconfigurable partition (e.g., a processing domain), can be dynamically reconfigured over time by loading different programming data into programmable device 100 for that region. As defined herein, the term "reconfigurable partition" refers to a group of programmable circuit resources (e.g., blocks and / or sites of programmable device 100) of programmable device 100, in which one or more reconfigurable modules can be placed (e.g., implemented). In this respect, a reconfigurable partition refers to a physical region of programmable device 100 that can be loaded with one or more different reconfigurable modules. As defined herein, the term "reconfigurable module" refers to programming data used to program a group of resources on a programmable device, such as programmable device 100 within a specific reconfigurable partition.

[0052] For a reconfigurable partition, multiple reconfigurable modules can specify user applications different from those previously implemented in the reconfigurable partition. The multiple reconfigurable modules do not specify new and / or different circuit arrangements for the programmable circuit resources of the programmable device 100, either outside the reconfigurable partition or in different reconfigurable partitions. Therefore, one or more reconfigurable partitions can be repeatedly and independently modified through partial reconfiguration, while other programmable reconfigurable partitions of the programmable device 100 continue to operate without interruption.

[0053] exist Figure 2 In the example, programmable device 100 is configured to implement multiple reconfigurable partitions 202-1 and 202-2. The specific number of reconfigurable partitions is for illustrative purposes and not for limitation. Programmable device 100 can be configured to implement more reconfigurable partitions than shown. Furthermore, programmable device 100 can be configured with a single, larger partition.

[0054] exist Figure 2 In the example, programmable device 100 may initially be configured to implement a platform. The platform is a circuit arrangement of programmable device 100 that is connected to different reconfigurable partitions 202 on programmable device 100 and provides interfaces to reconfigurable modules therein to communicate with other parts outside the reconfigurable partitions of programmable device 100 and / or resources outside the programmable device.

[0055] In one aspect, the platform is implemented as a static circuit device. A static circuit device refers to the programmable circuit resources of the programmable device 100 that are not modified or altered like the circuitry and / or systems in the reconfigurable partition 202. Therefore, the platform can operate continuously, while the programmable circuit resources in the reconfigurable partition 202 can be dynamically changed over time (e.g., during runtime). For example, the platform can provide general infrastructure such as connectivity to a memory controller for connecting to external memory, infrastructure for connecting to other networks, host systems, etc., which can be used by user applications implemented in the reconfigurable partition 202. These connections can remain active, in the static circuit device and as part of the platform, while one or more or all of the reconfigurable partitions 202 undergo reconfiguration.

[0056] Each reconfigurable partition 202 may have one or more associated reconfigurable modules implemented therein. Specific reconfigurable modules (which specify user applications) that can be loaded into a reconfigurable partition may change over time. Each reconfigurable partition 202 may be reprogrammed to perform different functions and / or operations over time based on the specific reconfigurable modules(s) implemented therein.

[0057] exist Figure 2 In the example, each reconfigurable partition includes a portion of DPE array 102, a portion of PL 104, and one or more hardwired circuit blocks 112. As shown, reconfigurable partition 202-1 includes a portion of DPE array 102 (e.g., one or more DPEs 116) shown as DPE array 102-1, one or more circuit blocks implemented in PL 104-1, one or more components of PS 106 (e.g., one or more real-time processors of PS 106) shown as PS 106-1, and one or more hardwired circuit blocks 112-1. Reconfigurable partition 202-2 includes a different portion of DPE array 102 (e.g., one or more other DPEs 116) shown as DPE array 102-2, one or more other circuit blocks implemented in PL 104-2, one or more other components of PS 106 (e.g., one or more application processors of PS 106) shown as PS 106-2, and one or more other hardwired circuit blocks 112-2.

[0058] It should be understood that although NoC 108 is illustrated outside of reconfigurable partition 202, portions of NoC 108 can be used to connect DPE arrays 102-1, PL 104-1, PS 106-1, and HCB 112-1, while other portions of NoC 108 can be used to connect DPE arrays 102-2, PL 104-2, PS 106-2, and HCB 112-2, and still other portions of NoC 108 are part of the platform. Data paths through NoC 108 corresponding to different reconfigurable partitions can remain isolated from each other.

[0059] Figure 2 This is provided for illustrative purposes and not for limitation. In this regard, some reconfigurable partitions may exclude any portion of DPE array 102, any portion of PL 104, any portion of PS 106, and / or any hardwired circuit block 112. In any case where the programmable device 100 implements multiple reconfigurable partitions, each reconfigurable partition may be logically isolated from one another.

[0060] In one aspect, each reconfigurable module loaded into the reconfigurable partition is designated as a device image 204 (e.g., a file of configuration data). Each device image 204 may include one or more segments. Each segment corresponds to a different portion of the programmable device 100, which is used or included in the reconfigurable partition in which the reconfigurable module is to be implemented. For example, a reconfigurable module using at least a portion of each of the DPE array 102, PL 104, PS 106, NoC 108, and hardwired circuit block 112 will include: a segment corresponding to DPE array 102, a segment corresponding to PL 104, a segment corresponding to PS 106, a segment corresponding to NoC 108, and a segment corresponding to hardwired circuit block 112, wherein each segment contains programming and / or configuration data for programming the corresponding programmable circuit resource or a portion thereof included in the reconfigurable partition.

[0061] refer to Figure 2 For example, device image 204-1 will include segments for programming DPE array 102-1, segments for programming PL 104-1, segments for programming PS 106-1, and segments for programming hardwired circuit block 112-1. Similarly, device image 204-2 will include segments for programming DPE array 102-2, segments for programming PL 104-2, segments for programming PS 106-2, and segments for programming hardwired circuit block 112-2.

[0062] In one aspect, each device image 204 can be created to include one or more identifiers (IDs). Examples of IDs in each device image may include a static partition ID, a reconfigurable partition ID, and a reconfigurable module ID. The static partition ID specifies a particular platform compatible with a given device image. Each static partition ID can be unique and thus uniquely identifies a particular platform (e.g., where different platforms offer different connectivity, different resources, and / or support different numbers of reconfigurable partitions). The reconfigurable partition ID specifies a particular reconfigurable partition in a programmable device, which the device image can be used to configure (e.g., to implement the reconfigurable partition of the device image therein). The reconfigurable module ID specifies a particular reconfigurable module. The reconfigurable partition ID can uniquely identify a particular reconfigurable partition implemented by a given platform. The reconfigurable module ID can uniquely identify a particular reconfigurable module.

[0063] For example, when reconfigurable modules are created, each is designed (e.g., using design tools) for operation on a specific platform. As noted, a static partition ID (which may also be referred to as a platform ID because it indicates a specific platform) is a unique identifier for that platform. Each reconfigurable module may include a platform-specific static partition ID (e.g., a platform ID) that the reconfigurable module is designed to operate with. The reconfigurable module will also include a reconfigurable module ID that is unique to that module. A device image that includes reconfigurable modules will include both the static partition ID and the reconfigurable module ID.

[0064] The PMC 110 can load a device image (e.g., a "platform device image") that specifies a platform. The platform device image will include a static partition ID that uniquely identifies the platform from other platforms. The platform device image may also include a list of one or more reconfigurable partitions (e.g., reconfigurable partition IDs) implemented by the platform, and one or more reconfigurable modules (reconfigurable module IDs) compatible with each corresponding reconfigurable partition (which may be implemented in each corresponding reconfigurable partition). When loading the platform device image, the PMC 110 can extract recorded information and store / maintain that information as trace data for the platform.

[0065] Thus, when loading a device image specifying a reconfigurable module, the PMC 110 can verify the compatibility of the device image with the platform. For example, a device image for a reconfigurable module may specify: a static partition ID for a specific platform, in which the device image is intended for use with that specific platform; a reconfigurable partition ID, indicating a specific reconfigurable partition implemented by the platform in which the reconfigurable module is to be implemented; and a reconfigurable module ID, uniquely identifying the specific reconfigurable module specified by the device image. For example, the PMC 110 can compare the platform's static partition ID with the device image's static partition ID to ensure that the device image being loaded is compatible with the platform currently implemented in the programmable device 100. The PMC 110 can also check whether the device image's reconfigurable partition ID corresponds to a reconfigurable partition implemented by the platform, and whether it corresponds to a specific reconfigurable partition to be reconfigured using the device image. The PMC 110 can also check whether the device image's reconfigurable module ID is a reconfigurable module ID compatible with the platform's reconfigurable partition ID, for example, listed in association with a specific reconfigurable partition to be configured by the device image.

[0066] As an illustrative and non-limiting example, if a host system (e.g., a computer system in which programmable device 100 operates as an accelerator) attempts to load a device image into programmable device 100, which is designed and intended to operate on a platform different from the platform currently loaded in programmable device 100, then PMC 110 is able to reject the device image, generate an error code, and store the error code in a Programming Access Trace Data (PATD) register.

[0067] Therefore, in one aspect, when PMC 110 loads another device image, PMC 110 checks whether the device image is compatible with a specific platform implemented therein and a specific reconfigurable partition of that platform. For example, when PMC 110 loads device image 204-1, PMC 110 may check whether the static partition ID of device image 204-1 matches the static partition ID of the platform implemented in programmable device 100. PMC 110 further checks whether the reconfigurable partition ID specified in device image 204-1 matches the reconfigurable partition ID of a specific reconfigurable partition (e.g., 202-1) in which device image 204-1 is to be implemented. PMC 110 may further check whether the reconfigurable module ID of device image 204-1 matches the allowed reconfigurable module ID of reconfigurable partition 202-1.

[0068] Similarly, PMC 110 can check whether the static partition ID of device image 204-2 matches the static partition ID of the platform implemented in programmable device 100. PMC 110 further checks whether the reconfigurable partition ID specified in device image 204-2 matches the reconfigurable partition ID of a specific reconfigurable partition (e.g., 202-2) in which device image 204-2 is to be implemented. PMC 110 can further check whether the reconfigurable module ID of device image 204-2 matches the allowed reconfigurable module ID of reconfigurable partition 202-2.

[0069] Figure 3 An example implementation of the PMC 110 is illustrated. Figure 3 In the example, PMC 110 includes a PMC processing unit 302 (separate from and different from PS 106). The PMC processing unit 302 may include one or more processors, such as processor 304 and processor 306. The PMC processing unit 302 also includes one or more ROMs 308, one or more RAMs 310, and local registers 312. The ROMs 308 and RAMs 310 are accessible only by the processors (e.g., processors 304, 306) within the PMC processing unit 302.

[0070] In one aspect, each of processors 304 and 306 is implemented as a redundant processor (e.g., a triple-redundant processor) capable of operating synchronously using appropriate voting circuitry. In another aspect, processor 304 is dedicated to accessing ROM(s) 308 (e.g., executing code stored in ROM(s) 308), while processor 306 is dedicated to executing code stored in RAM(s) 310. In yet another aspect, each processor 304, 306 has ROM 308 and RAM 310, such that each processor 304, 306 has an independent and dedicated ROM 308 and an independent and dedicated RAM 310. Figure 3 This is provided for illustrative purposes and not for limitation. In this respect, the PMC processing unit 302 may include a single processor.

[0071] Error correction coding (ECC) circuitry can be used to protect RAM 310. Processors 304 and 306 can be used to power on and configure programmable device 100 by first executing trusted code stored in ROM(s) 308. While executing the trusted code stored in ROM(s) 308, processors 304 and 306 can then load firmware from the master boot device into RAM(s) 310. Local register 312 is a configuration register for PMC processing unit 302 and can only be accessed by PMC processing unit 302.

[0072] One aspect of enabling PMC 110 to operate as the root of trust for programmable device 100 is the use of code stored in ROM(s)308 to load firmware into RAM(s)310. For example, processor 304 is capable of executing code from ROM(s)308 to initiate operations such as authentication and verification of any firmware loaded into programmable device 100 for execution by processor(s)306 and / or any device image loaded into programmable device 100. Therefore, any device image used to configure and / or program any part of programmable device 100 can first be authenticated and / or verified by PMC 110.

[0073] After booting, processors 304 and 306, under the control of the firmware, can use various components included in the PMC 110 to perform various functions. For example, processors 304 and 306 can perform power management, voltage and temperature monitoring, security and safety event response, and error management. Processors 304 and 306 can also control the configuration of the programmable device 100 by controlling the loading and unloading of device images. In one aspect, any device image loaded into the programmable device 100 is loaded or unloaded under the control of the PMC 110.

[0074] PMC processing unit 302 is connected to switch 314. PMC processing unit 302 can communicate with other components within PMC 110 and programmable device 100 via switch 314. Switch 314 may include multiple memory-mapped switches and / or multiple flow switches. Switch 314 is connected to PMC shared RAM 316, global register 318, multiple I / O interfaces 320 (e.g., 320-1, 320-2, 320-3, and 320-4), secure flow switch 322, slave boot interface (SBI) 324, secure accelerator 326, analog system 328, real-time clock (RTC) 330, power management and reset 332, error management 334, configuration frame unit (CFU) 336, and SelectMap interface 338. SBI 324 is connected to JTAG port 340.

[0075] The PMC shared RAM 316 can be used to store configuration data (e.g., device image) for the programmable device 100 during processing and serves as general-purpose data processing RAM for the PMC 110. Global register 318 is a configuration register accessible to any (e.g., all) master device within the PMC 110. Global register 318 may include general-purpose registers, power control registers, error management registers, and a service interrupt request interface.

[0076] In one aspect, global register 318 includes a PATD register 320. The PATD register 320 is capable of storing trace data over time, corresponding to different device images loaded and unloaded from programmable device 100 by PMC processing unit 302. For example, PMC processing unit 302 can store information related to each device image loaded into programmable device 100 in PATD register 320. When PMC processing unit 302 loads new and / or different device images into programmable device 100, existing information stored in PATD register 320 can be moved to memory allocated for storing trace data. This memory can be PMC shared RAM 316, another memory within programmable device 100 (e.g., BRAM allocated in PL 104), or RAM external to programmable device 100. After existing or older trace data is moved out of PATD register 320, new trace data can be stored therein, overwriting previous trace data.

[0077] I / O interface 320 can be coupled to multiplexed input / output (MIO) 342. MIO 342 is also connected to SelectMap 338, PS 106, and PL 104. MIO 342 enables the selective connection of I / O signals from programmable device 100 to SelectMap 338, PS 106, PL 104, and / or I / O interface 320. Examples of I / O interface 320 include, but are not limited to, I2C and one or more flash interfaces such as Serial Peripheral Interface (SPI), SD / eMMC, and Universal Serial Bus (USB). MIO 342 provides connectivity to I / O pins of programmable device 100, which can provide a variety of different functions depending on the configuration. For example, MIO 342 can be configured to connect signals to SelectMap 338 for configuration, or to I / O interface 320, such as a flash interface and / or a USB interface.

[0078] The secure flow switch 322 ensures that the data stream provided to the secure accelerator 326 for processing (which may transmit device images) is secure. The SBI 324 facilitates slave device booting of the programmable device 100. Although not shown, the SBI 324 can be connected to the SelectMap 338 and NoC 108.

[0079] Security accelerator 326 may include an encryption / decryption block 346 capable of performing encryption and / or decryption, an authentication block 348 capable of performing authentication, and a hash block 350 capable of generating hashes on received data. In one example, encryption / decryption block 346 is a symmetric-key cryptographic engine capable of performing Advanced Encryption Standard (AES) (AES-GCM) using Galois Counter Mode (GCM). In one example, authentication block 348 is capable of performing public-key cryptography. For example, authentication block 348 is capable of implementing the Elliptic Curve Digital Signature Algorithm and / or Rivest-Shamir-Adleman. Hash block 350 is capable of performing the secure hash algorithm 3 / 394. Security accelerator 326 may also include a True Random Number Generator (TRNG) circuit 352 capable of generating random numbers, and may include a battery-powered RAM (BBRAM) circuit block 354. Specific circuit blocks included in security accelerator 326 are provided for illustrative and not limiting purposes. In one respect, only blocks 346, 348, and 350 of the security accelerator 326 are accessible via the security flow switch 322, while blocks 352 and 354 are accessible via switch 314.

[0080] The analog system 328 may include: a system monitor capable of monitoring voltage and temperature from one or more remote system monitor circuits, which may be located at various locations around the programmable device 100 and / or in different subsystems; (multiple) system oscillators capable of generating clock signals for the PMC 110; an electronic fuse controller capable of maintaining and / or managing electronic fuse circuitry on the programmable device 100; a bandgap circuitry capable of generating one or more reference voltages for analog devices in the programmable device 100, such as DACs and / or ADCs that may be implemented on the programmable device 100 as hardwired and programmable circuit blocks; one or more phase-locked loops (PLLs) capable of generating clock signals for the PMC 110, NoC 108, NPI 134, and PS 106; and a power-on reset (POR) circuit.

[0081] The RTC 330 is a clock circuit capable of operating on a high-accuracy crystal oscillator. The RTC 330 can be used to measure the current time and generate alarms at specific times for various operating system and device management functions within the programmable device 100. The power management and reset circuitry 332 implements the logic and interfaces required to control the power islands and power domains, and implements resets for other circuit blocks on the programmable device 100. The power management and reset circuitry 332 is further connected to the PS 106 to control the power domains and islands implemented in the PS 106.

[0082] Error management circuitry 334 is capable of receiving, recording, and responding to errors from other programmable resources (e.g., subsystems) within programmable device 100. For example, error management circuitry 334 is capable of capturing errors from across programmable device 100. Error management circuitry 334 can be programmed by PMC 110 to generate certain events (e.g., interrupts) in response to specific received errors and / or combinations of errors. PMC 110 is capable of handling errors in response to events generated by error management circuitry 334.

[0083] CFU 336 is coupled to CFI 114 and is capable of configuring and reading back configuration data, which is provided or loaded into the configuration register of PL 104 via CFI 114. For example, PMC 110 transmits PL programming data (e.g., configuration bitstream) to CFI 114 via CFU 336 to configure PL 104.

[0084] The secure flow switch 322 can be used to stream configuration data (e.g., a device image) to the programmable device 100. For example, the device image can be pushed to the SelectMap interface 338 via MIO 342. The device image can also be received via JTAG port 340. In either case, the device image is pushed to the SBI 324, which can generate an interrupt to the PMC processing unit 302. The PMC processing unit 302 can then transfer the device image from the SBI 324 to the PMC shared RAM 316 via the secure flow switch 322 for further processing.

[0085] The task of PMC 110, which serves as the root of trust for programmable device 100, is to load a device image that programs various parts of programmable device 100 to operate. For example, to enable operation of any of DPE 102, PL 104, PS 106, and / or NoC 108, PMC 110 must first load the device image used to program such components. After being loaded and before using the device image to program any programmable circuit resources of programmable device 100, PMC 110 is able to authenticate and / or verify the device image. PMC processing unit 302 can push data to PL 104 via CFU 336 to CFI 114, to PS 106, to NPI 134 and / or NoC 108, and to DPE array 102 for programming the corresponding programmable circuit resources of programmable device 100.

[0086] For example, to create a processing domain (e.g., a reconfigurable partition) (which includes one or more DPEs 116, one or more circuit blocks implemented in PL 104, one or more hardwired circuit blocks 112, and communicates via NoC 108), PMC 110 must load one or more device images into programmable device 100 and use the device images to program the corresponding programmable circuit resources. For each different reconfigurable partition implemented in programmable device 100 (where multiple partitions can exist simultaneously at any given time), each reconfigurable partition may require loading a device image.

[0087] The PMC 110 can continuously load and unload device images over time. Furthermore, device images can be loaded via any of a variety of different paths. For example, one or more device images can be loaded into the PMC 110 via one or more of I / O interfaces 320-1, 320-2, 320-3 and / or 320-4, SelectMap 338, JTAG port 340, and / or received by another controller (e.g., a PCIe interface) implemented in the PS 106 connected to the host system. In another example, device images can be received via I / O interfaces implemented using one or more hardwired circuit blocks 112 (e.g., a memory controller connected to off-chip RAM, an Ethernet interface, etc.). In each case, the task of the PMC 110 is to authenticate and verify the device image using the security accelerator 326 before programming the various parts of the programmable device 100 with the device image.

[0088] Figure 3It is provided for illustrative purposes. In this respect, the PMC 110 may include fewer components than shown (e.g., processor and memory together with PATD register 320) or Figure 3 Additional components not shown. Furthermore, the PMC 110 may have a different architecture than that shown.

[0089] Table 1 below illustrates the different types of information that can be collected by the processor in PMC 110 (e.g., processors 304 and / or 306 in PMC processing unit 302) as part of processing the device image for programmable device 100. In one aspect, the information shown in Table 1 can be stored by the processor in PATD register 320 each time the device image is loaded. Data determined when the device image is unloaded can be stored later, for example, written to PATD register 320 or to memory allocated to store trace data unloaded from PATD register 320.

[0090] Table 1

[0091]

[0092]

[0093]

[0094] The specific fields and sizes described in Table 1 are provided for illustrative purposes. The number of bits and example fields are not intended to limit the trace data stored in PATD register 320. In some cases, a particular combination of fields stored in PATD register 320 in Table 1 may vary (e.g., fewer than shown). In other cases, the trace data stored in PATD register 320 may include any combination of fields from Table 1 (including all such fields) and other information described within this disclosure.

[0095] In one aspect, the "Release Request" field indicates the specific agent (e.g., entity) attempting to load the reconfigurable module. Multiple agents may attempt to load the reconfigurable module. Access to load the reconfigurable module is arbitrated so that only one agent or requester can do so at a time. The Release Request field indicates that one agent requests access to load the reconfigurable module while another agent already has access. For example, an agent with access can be configured to poll the register to determine if another agent has requested access. The agent with access can relinquish access when it is safe to do so in order to grant access to the requesting agent. In some cases, certain agents (such as Single Event Monitors (SEMs)) may have permanent access to the configuration store and are notified by polling the Release Request field that another agent needs access. The Release Request field can also provide a mechanism to force the release of access if an agent becomes suspended. In the case of high-priority events, the Release Request field can also be used to allow one agent to "cut in the queue" before another agent.

[0096] The "Access Termination Code" field is related to the Release Request field because it records a code indicating the reason why the agent lost access to the configuration storage. As an example, if agent A has access but does not respond to a request from PMC 110 asking whether agent A is still active or responsive, PMC 110 can determine that agent A is suspended. PMC 110 can then terminate agent A's access.

[0097] The "Rollback" field indicates that a device image loading failure has occurred, and in response, the PMC 110 uses a known good image as a rollback or fault protection. The Rollback field indicates that a known good rollback device image was used to configure some parts of the programmable device 100. The "Interrupted Function" field tracks whether the request to load the device image interrupted another operation. Examples of operations that could be interrupted, as indicated in the Interrupted Function field, include, but are not limited to, SEM operations, security monitor operations, etc. The Interrupted Function field can help determine the cause of the device image loading failure.

[0098] The "Access Denied - Unknown Master Device" field is initially set to 0. In response to PMC 110 determining that the requesting master device (e.g., a master device requesting partial reconfiguration) is not permitted to make such a request, for example, if the requesting master device is not specified on the list of allowed master devices maintained by PMC 110 (referred to as the "whitelist"), PMC 110 sets this field to 1. In this respect, PMC 110 can track successful and unsuccessful requests from master devices based on whether the "Access Denied - Unknown Master Device" field is set to 0 or 1. In the case of a successful request, additional details related to the loading of the PDI are also tracked, as described herein and illustrated in other fields within Table 1. It should also be understood that other information related to the requesting master device, not illustrated in Table 1, may be stored.

[0099] Figure 4 Another example architecture of the programmable device 100 is illustrated. Figure 4 The example illustration shows a simplified architecture of the PMC 110. Furthermore, Figure 4 The example illustrations depict several different methods, such as communication paths, through which a device image can be loaded into the programmable device 100. In one aspect, the specific communication path through which the device image is loaded into the programmable device 100 can be detected and stored as part of the trace data.

[0100] exist Figure 4 In the example, PMC 110 includes a processor 402, a PATD register 320, a memory 404, and optionally one or more dedicated circuits 406, each connected to a switch 408. PMC 110 may also include I / O interfaces 410, 412, and / or 414. PS 106 includes a PCIe interface 416. HBC 112 includes a memory controller 418 connected to off-chip memory 420.

[0101] In this example, the device image can be loaded into the programmable device 100 via any of a variety of communication paths. For example, device image 422 can be loaded into the programmable device 100 via I / O interfaces 410, 412, or 414. Device image 424 can be loaded into the programmable IC 100 via an interface implemented using one or more HBCs 112. For example, device image 424 can be loaded into the programmable device 100 via an Ethernet port. Device image 426 can be stored in off-chip memory 420 and loaded into the programmable device 100 via memory controller 418. In another example, device image 426 can be provided to the programmable device 100 from a host computing system via PCIe interface 416.

[0102] In one respect, due to the loading and / or unloading of the PMC 110 control device image, the PMC 110, such as processor 402 (or reference 402), Figure 3 The processors (multiple) 304 and / or 306 may record in the PATD register 320 the specific communication path (e.g., I / O interface) through which the device image is loaded into the programmable device 100. In one aspect, the code specifying the particular I / O interface may be stored in association with any other trace data corresponding to the particular device image being loaded.

[0103] Figure 5 An example operation method 500 for a PMC 110 is illustrated. Method 500 can be executed by a processor within the PMC 110 (e.g., PMC processing unit 302, and more specifically, one or both of processors 304, 306, or 402). For illustrative purposes, an implementation of the PMC 110 is shown. Figure 5 The processor that performs these operations is called a "processing unit".

[0104] Furthermore, although generally described in the context of partial reconfiguration of the programmable device 100 Figure 5 However, it should be understood that method 500 can be executed with the programmable device 100 completely reconfigured. Furthermore, method 500 can be executed in other types of programmable devices that include programmable logic and have a separate entity responsible for loading and / or unloading device images (e.g., configuration data).

[0105] In block 502, the processing unit monitors device image events for the programmable device. In one aspect, the processing unit can monitor the occurrence of interrupts indicating that a device image should be loaded. For example, the availability of the device image at a slave interface (such as a JTAG port) of the programmable device may cause an interrupt to be generated and provided to the processing unit. In another aspect, the processing unit can monitor the receipt of requests (e.g., signals) for the device image to be loaded. These requests may originate from another circuitry within the programmable device or from another circuitry outside the programmable device (e.g., a host system).

[0106] In block 504, the processing unit determines whether a device image event for the programmable device has been detected. In response to the detection of a device image event for the programmable device, method 500 proceeds to block 506. In response to the detection that no device image event for the programmable device is detected, method 500 loops back to block 502 and can continue monitoring for device image events.

[0107] In block 506, the processing unit determines whether the detected device image event is a load event requesting the loading of a specific device image or an unload event requesting the unloading of a specific device image already loaded in the programmable device. In response to determining that the detected device image event is a load event, method 500 continues to block 512. In response to determining that the detected device image event is an unload event, method 500 continues to block 508.

[0108] Continuing with box 512, the processing unit loads the device image into memory within the PMC for processing. For example, the processing unit can load a device image, referred to as the "current device image," from an external source and store it in the PMC's shared memory for further processing. Alternatively, before obtaining any trace data from the current device image, the processing unit may have to decrypt, authenticate, and / or verify the current device image. The processing unit can provide the current device image to one or more security accelerators, such as encryption / decryption block 346, authentication block 348, and / or hash block 350, to ensure that the current device image can be securely used to program the programmable circuit resources of the programmable device.

[0109] In block 514, the processing unit, in response to the load operation performed in block 512, determines the trace data for the current device image. In one aspect, the processing unit can determine one or more of the information items listed in Table 1. For example, the current device image may specify a reconfigurable module. In this case, the processing unit can extract the static partition ID, the reconfigurable partition ID, and the reconfigurable module ID from the current device image. The device image may also specify a device ID, which indicates a specific type or model of programmable device with which the device image is intended to be used.

[0110] In one aspect, the processing unit can determine coordinates within the PL (e.g., the area region in Table 1), which are used by the device image. The current device image may include configuration data for the PL. The processing unit can determine which portions or coordinates of the PL are configured by the configuration data in the current device image.

[0111] As discussed, some of the information specified in Table 1 is extracted from the current device image. Other information specified in Table 1 may not be available from the device image. For example, the processing unit can determine the trace data used for the current device image, which indicates or specifies the source from which the current device image was obtained. For example, the processing unit can determine the master device ID. The master device ID specifies the physical port of NoC 108 through which access arrives.

[0112] In another example, the processing unit is able to determine the Programming Access ID (e.g., refer to Table 1). The Programming Access ID indicates the entity requesting partial reconfiguration (e.g., agent and / or master device). For example, in a data center, a host system (e.g., a server) may request that a device image be loaded into a programmable device. In this case, the processing unit captures the server's Programming Access ID from the request (e.g., where the request is an example of a device image event). In another example, an application implemented in a programmable device (e.g., a circuit device) may request that a device image be loaded. In this case, the processing unit captures the requesting circuit's Programming Access ID. The Programming Access ID specifies the specific agent making the request. In the illustration, if two agents are connected to the same port of NoC 108, requests from both agents will have the same master device ID. However, each request will have a different Programming Access ID.

[0113] In another example, the processing unit may determine the communication path and / or source from which it obtains the device image. As an illustrative and non-limiting example, the processing unit may store an identifier as part of trace data, indicating the specific I / O interface through which it loads the current device image. Examples of I / O interfaces through which the device image can be loaded include, but are not limited to, SelectMAP, PCIe, DDR (e.g., off-chip) memory, flash memory (QSPI / OSPI) (e.g., corresponding to I / O interface 320), JTAG, and / or any other I / O interface connected to the PMC110 via NoC 108, such as CAN, Ethernet, USB, PS, etc.

[0114] The processing unit is also capable of generating one or more trace data items corresponding to the device images(s) that have been loaded into the programmable device. In one aspect, as each device image is loaded, the processing unit increments a count (e.g., the access event count in Table 1) that specifies the number of device images that have been loaded into the programmable device since its last reset. The count may be contained in a portion of the PATD register, which is incremented each time the register is written to. In response to a reset of the programmable device (e.g., a hard reset where power is cycled off and on again) or a soft reset, the processing unit clears the count.

[0115] In one aspect, unloading a device image is achieved by loading a device image designated as an "unload device image". For example, an unload device image is a device image that clears (e.g., overwrites with blank or deletes previously configured data) a reconfigurable partition. In response to the loading of a device image and in response to the loading of an unload device image, the processing unit can increment a counter. The processing unit can also track the loading of unload device images to determine which reconfigurable partitions are available (cleared or unloaded) at any given time.

[0116] In block 516, the processing unit moves the existing contents of the PATD register (corresponding to the previously processed device image) to the allocated trace memory for long-term storage. In one aspect, memory within the programmable device is allocated for trace data storage. The memory may be within the PMC shared RAM 316, or it may be one or more BRAMs and / or URAMs located in PL 104. In another aspect, the memory may be external to the programmable device. For example, the memory allocated for trace data storage may be within external RAM (e.g., off-chip memory 420) that the processing unit can read and / or write to.

[0117] In block 518, the processing unit stores the trace data for the current device image, as determined in block 514, in the PATD register. Since previous trace data has been stored in a different memory allocated for trace data, the processing unit can overwrite the contents of the PATD register with the trace data for the current device image. As noted, the access event count can be incremented.

[0118] In block 520, the processing unit determines the compatibility of the device image with the current state of the programmable device. In one aspect, as part of or prior to block 520, the processing unit is capable of performing a device ID check. For example, the processing unit is capable of comparing the device ID of the device image with the device ID of the programmable device to ensure that they match. This operation prevents the programmable device from being programmed using a device image intended for use with different programmable devices.

[0119] In one aspect, the current state of the programmable device includes the specific platform implemented therein. The current device image may specify reconfigurable modules to be used as a part of a partial reconfiguration process for the programmable device. In this case, the current device image includes a reconfigurable partition ID, a reconfigurable module ID, and a static partition ID. Therefore, in one aspect, determining the compatibility of the current device image with the current state of the programmable device includes determining the compatibility of the current device image with a platform already implemented in the programmable device. For example, in response to loading a device image specifying a platform, the processing unit may store trace data for that platform (e.g., in the PATD register and move the data to an allocated trace data memory). The trace data for the platform may include a static partition ID. The trace data for the platform may be stored along with an identifier that distinguishes the trace data for the platform from trace data for other device images that do not specify a platform.

[0120] Therefore, the processing unit can compare one or more trace data items for the current device image with stored trace data for the platform. In one aspect, the processing unit can compare the platform's static image ID with a static image ID read from the current device image. The processing unit determines whether the two static image IDs match. Based on the comparison of the two static image IDs and whether they match, the processing unit determines whether the device image is compatible with the platform.

[0121] On the other hand, the processing unit can perform additional checks. For example, the processing unit can check whether the device image has the correct header by performing authentication. In some cases, the processing unit may need to initially decrypt the device image and / or header. Alternatively, the processing unit can perform a hash operation on the header(s) and / or NPI data included in the device image. Any errors detected from such an operation can also be stored in the PATD register.

[0122] In box 522, in response to determining that the current device image is platform compatible, for example, if two static image IDs match, method 500 continues to box 528. In response to determining that the current device image is platform incompatible, for example, if two static image IDs do not match, method 500 continues to box 524.

[0123] In block 524, the processing unit generates an error code indicating that the current device image is incompatible with the platform. The processing unit stores the error code as part of the trace data used for the device image in the PATD register. In block 526, the processing unit rejects the device image. For example, the processing unit does not use the current device image to program any programmable circuit resources of the programmable device. The processing unit may also delete the current device image from the PMC shared memory. Despite deletion, the processing unit maintains trace data within the PATD and offloads the trace data to allocated memory, as described. Specific items in the data indicate that the device image was not used to program the programmable resources of the programmable device.

[0124] In block 528, the processing unit uses the device image to configure the programmable circuit resources included in the programmable device, provided that the device image is compatible with the current state of the SoC. Following block 528, method 500 may continue to block 530.

[0125] On the other hand, as part of loading the device image, the processing unit is able to receive any error codes that may be generated by other circuit blocks within the programmable device and record such error codes as part of the trace data. For example, if the CRC circuitry of CFI 114 generates an error, the processing unit can record the error code by setting the CFI CRC error bit in the trace data shown in Table 1. The processing unit can use hash block 350 to check any data loaded into NPI 134. In response to an error detected in the programming of NPI 134 based on hash block 350, the processing unit can record the error code by setting the NPI error bit in the trace data shown in Table 1. The recording of errors, as described herein, provides information in cases where the device image is rejected or where an error occurs when programming the programmable circuit resources of the programmable device using the device image.

[0126] In block 508, the processing unit unloads the device image specified in the device image event from the programmable device. For example, the processing unit can clear the configuration memory unit of the programmable device, which stores configuration data of the device image to be unloaded. As noted, in one aspect, as a device image event, the processing unit receives an unloaded device image used to overwrite (e.g., clear) a specific reconfigurable partition.

[0127] In block 510, in response to unloading, the processing unit records the unloading of the device image in trace data in memory. For example, the processing unit updates the trace data for the device image unloaded in response to the unloading operation. In one aspect, if the PATD register still stores the trace data for the device image unloaded in block 508, the processing unit updates the trace data in the PATD register. For example, the processing unit may use the time when the device image was unloaded (e.g., the unloading time in Table 1) to update the trace data and increment the access event count.

[0128] On the other hand, if the tracking data for the device image used to be unloaded in block 508 is stored in a different memory, the processing unit can initiate a write operation to update the tracking data in such memory. As noted, for example, the processing unit can update the tracking data in the memory to store the time when the device image was unloaded and increment the access event count. In one aspect, the processing unit can determine the time by reading the RTC included in the PMC and writing the time to the PATD or the memory storing the tracking data.

[0129] In box 530, the processing unit is able to create unique identifiers corresponding to the device images(s) loaded into the programmable device. For example, the processing unit is able to determine an identifier for each active device image within the programmable device. The active device image in the programmable device is the device image currently used to program one or more programmable circuit resources in the programmable device. The processing unit is able to generate a unique hash of the identifier for each active device image. For the purposes of box 530, the processing unit may also generate a unique identifier for unloaded device images. The resulting unique identifiers may be stored in the PATD register and / or used as part of trace data. After box 530, method 500 may loop back to box 502 to continue processing.

[0130] For example, the unique identifier generated in box 530 could be a hash of all activity (e.g., successful programming) IDs of the device image already in use. The unique identifier can be used to quickly determine whether the state of the programmable device has changed by comparing it to previously generated unique identifiers. In the illustration, consider the scenario where, via JTAG, an entity can simply determine whether a programmable device has been fully or partially reprogrammed and / or reconfigured by polling a register that stores the unique identifier. When the register is polled for the first time, the unique identifier read from the register can be compared to any other value read from the register in the future. In response to detecting a difference or change in the value from one poll to another of the register, the entity can continue to examine the trace data in more detail to determine what changes have been made. This technique reduces the bandwidth required for the entity to detect differences in the programmable device. In response to detecting a change, the entity only needs to query the trace data in more detail.

[0131] For purposes such as debugging and error analysis, trace data collected by the PMC can be read at any time. For example, external systems of a computer system can read trace data from memory at any point during the operation of the programmable device. Because the trace data is generated by the programmable device itself using the PMC, which operates as the root of trust of the device, the trace data provides a complete and accurate state map of the programmable device at each point in time covered by the trace data.

[0132] For the purpose of illustration, specific terms are set forth to provide a thorough understanding of the various inventive concepts disclosed herein. However, the terminology used herein is for the purpose of describing specific aspects of the inventive arrangement only and is not intended to be limiting.

[0133] As defined herein, unless the context clearly indicates otherwise, the singular forms “a,” “one,” and “the” are intended to include the plural forms as well.

[0134] As defined herein, the term “approximately” means close to correct or precise, a value or quantity that is close but not precise. For example, the term “approximately” may mean that the listed characteristic, parameter, or value is within a predetermined quantity of a precise characteristic, parameter, or value.

[0135] As defined herein, unless otherwise expressly indicated, the terms “at least one,” “one or more,” and “and / or” are open-ended expressions used in operation to combine and separate the two. For example, each of the expressions “at least one of A, B, and C,” “at least one of A, B, or C,” “one or more of A, B, and C,” “one or more of A, B, or C,” and “A, B, and / or C” means “A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together.”

[0136] As defined herein, the term "automatic" means without user intervention. As defined herein, the term "user" means human.

[0137] As defined herein, the term "computer-readable storage medium" means a storage medium that contains or stores program code for use by or in connection with an instruction execution system, apparatus, or device. As defined herein, a "computer-readable storage medium" is not itself a transient propagating signal. A computer-readable storage medium can be, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. Various forms of memory described herein are examples of computer-readable storage media. A non-exhaustive list of more specific examples of computer-readable storage media may include: portable computer disks, hard disks, RAM, read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), electrically erasable programmable read-only memory (EEPROM), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, etc.

[0138] As defined herein, the term “if” means “when” or “in response to” or “responsive to” depending on the context. Therefore, the phrase “if determined” or “if [the stated condition or event] is detected” can be interpreted as meaning “when determined” or “in response to determined” or “when [the stated condition or event] is detected” or “in response to the detection of [the stated condition or event]” or “in response to the detection of [the stated condition or event]” depending on the context.

[0139] As defined herein, the term "in response to" and similar language as described above (e.g., "if," "when," or "at...") imply a propensity to respond to or react to an action or event. A response or reaction is performed automatically. Therefore, if a second action is performed "in response to" a first action, a causal relationship exists between the occurrence of the first action and the occurrence of the second action. The term "in response to" indicates a causal relationship.

[0140] As defined herein, the terms "an embodiment," "an embodiment," "one or more embodiments," "a particular embodiment," or similar language refer to a specific feature, structure, or characteristic described in connection with that embodiment, including at least one embodiment described in this disclosure. Therefore, the appearance of the phrases "in an embodiment," "in one embodiment," "in one or more embodiments," "in a particular embodiment," and similar language throughout this disclosure may, but not necessarily all, refer to the same embodiment. Within this disclosure, the terms "embodiment" and "arrangement" are used interchangeably.

[0141] As defined herein, the term "processor" refers to at least one hardware circuit. Hardware circuitry can be configured to implement instructions contained in program code.

[0142] As defined herein, the term “output” means storing in a physical storage element (e.g., a device), writing to a display or other peripheral output device, sending or transmitting to another system, exporting, etc.

[0143] As defined herein, the term “real-time” means a level of processing response that the user or system perceives as sufficiently immediate for a particular process or determination to be performed, or a level of processing response that enables the processor to keep up with certain external processes.

[0144] As defined herein, the term “basic” means that the described feature, parameter, or value does not need to be precisely achieved, but rather means that deviations or variations, including, for example, tolerances, measurement errors, measurement accuracy limitations, and other factors known to those skilled in the art, may occur in a quantity that does not preclude the effect that the feature is intended to provide.

[0145] The terms first, second, etc., may be used in this document to describe individual elements. Because these terms are used only to distinguish one element from another unless otherwise indicated or clearly indicated by the context, the elements should not be limited by these terms.

[0146] A computer program product may include one or more computer-readable storage media having computer-readable program instructions (e.g., firmware) thereon for causing a processor to perform aspects of the arrangements of the invention described herein. The computer-readable program instructions for performing operations of the arrangements of the invention described herein may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​and / or procedural programming languages.

[0147] Certain aspects of the invention have been described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions (e.g., program code).

[0148] These computer-readable program instructions may be provided to a processor to produce a machine, such that the instructions, which execute via the processor, create means for implementing the functions / actions specified in one or more boxes of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a processor to operate in a particular manner, such that the computer-readable storage medium containing the instructions includes an article of writing comprising instructions that implement aspects of the operations specified in one or more boxes of a flowchart and / or block diagram.

[0149] In some alternative implementations, the operations indicated in the boxes may not occur in the order shown in the figures. For example, depending on the functionality involved, two boxes shown consecutively may be executed substantially simultaneously, or the boxes may sometimes be executed in reverse order. In other examples, the boxes may typically be executed in ascending numerical order, while in other examples, one or more boxes may be executed in a variable order, wherein the results are stored and utilized in subsequent boxes or other boxes that do not immediately follow. It should also be noted that each box in the block diagram and / or flowchart illustration, and combinations of boxes in the block diagram and / or flowchart illustration, may be implemented by a hardware-based dedicated system that performs the specified function or action or implements a special purpose of hardware and computer instructions.

[0150] All devices or steps that can be found in the following claims, plus the corresponding structures, materials, actions, and equivalents of the functional elements, are intended to include any structures, materials, or actions used to perform functions in combination with other claimed elements as expressly claimed.

[0151] A method may include: in response to loading a device image for a programmable device, determining trace data for the device image using a processing unit on the programmable device; storing the trace data for the device image in a memory via the processing unit; and in response to unloading the device image, recording the unloading of the device image in the trace data in the memory.

[0152] On the other hand, memory resides on programmable devices.

[0153] On the other hand, the memory is located outside the programmable device.

[0154] On the other hand, multiple device images are loaded into the programmable device simultaneously. The method may include: creating a unique identifier corresponding to each device image loaded into the programmable device; and storing the unique identifier in memory.

[0155] In another aspect, the method may include: counting the number of device images loaded into the programmable device since the programmable device has been reset by a processing unit.

[0156] On the other hand, the device image specifies a reconfigurable module that is loaded as a portion of the programmable device for partial reconfiguration. The device image includes a reconfigurable partition identifier and a reconfigurable module identifier. Methods may include storing the reconfigurable partition identifier and the reconfigurable module identifier as a portion of trace data.

[0157] On the other hand, the platform circuit device has already been implemented in the programmable device using the programmable circuit resources of the programmable device. In this case, the method may include: detecting the compatibility between the device image and the platform circuit device based on a comparison between trace data for the device image and trace data for the platform circuit device.

[0158] On the other hand, the method may include: in response to determining incompatibility based on detection, generating an error code and storing the error code as part of the trace data.

[0159] On the other hand, the method may include: rejecting the device image in response to determining incompatibility based on detection.

[0160] On the other hand, the method may include: determining the identifier of the master device for which the device image is requested to be loaded, and storing the identifier as a portion of the trace data for the device image.

[0161] An apparatus may include a plurality of programmable circuit resources and may include a processor configured to program the programmable circuit resources. The processor may initiate executable operations including: determining trace data for the device image in response to loading a device image for the apparatus, wherein the device image includes programming data for one or more of the plurality of programmable circuit resources; storing the trace data for the device image in memory; and recording the unloading of the device image in the trace data in memory in response to unloading the device image.

[0162] On the other hand, the memory is on the device.

[0163] On the other hand, the memory is located outside the device.

[0164] On the other hand, multiple device images are loaded into the device simultaneously. The processor can be configured to initiate an operation that also includes: creating unique identifiers corresponding to the multiple device images loaded into the device; and storing the unique identifiers in memory.

[0165] On the other hand, the processor is configured to initiate an operation that also includes counting the number of device images loaded into the device since the device has been reset.

[0166] On the other hand, the device image specifies a reconfigurable module that is loaded as part of a partial reconfiguration of the device. The device image may include a reconfigurable partition identifier and a reconfigurable module identifier. The processor may be configured to initiate an operation that further includes storing the reconfigurable partition identifier and the reconfigurable module identifier as part of the trace data.

[0167] On the other hand, the platform circuitry has been implemented in the device using a selected programmable circuitry resource from a plurality of programmable circuitry resources. The processor can be configured to initiate an operation that further includes: detecting compatibility between the device image and the platform circuitry based on a comparison of trace data for the device image and trace data for the platform circuitry.

[0168] On the other hand, the processor is configured to initiate an operation that also includes: in response to determining incompatibility based on detection, generating an error code and storing the error code as trace data.

[0169] On the other hand, the processor is configured to initiate an operation that also includes rejecting the device image in response to determining incompatibility based on detection.

[0170] On the other hand, the processor is configured to initiate an operation that also includes: determining the identifier of the master device requesting the loading of the device image, and storing the identifier as a portion of the trace data for the device image.

[0171] The description of the inventive arrangements provided herein is for illustrative purposes and is not intended to be exhaustive or limited to the disclosed forms and examples. The terminology used herein is chosen to explain the principles of the inventive arrangements, practical applications or improvements to technologies found in the market, and / or to enable others skilled in the art to understand the inventive arrangements disclosed herein. Modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described inventive arrangements. Therefore, in indicating the scope of such features and embodiments, reference should be made to the following claims, not to the foregoing disclosure.

Claims

1. A method for processing data, comprising: In response to loading a device image for a programmable device, a processing unit on the programmable device is used to determine trace data for the device image; The device image specifies a reconfigurable module that is loaded as part of a partial reconfiguration of the programmable device, and the device image includes a reconfigurable partition identifier and a reconfigurable module identifier. The processing unit stores the tracking data for the device image in a memory, wherein the reconfigurable partition identifier and the reconfigurable module identifier are stored as a portion of the tracking data. as well as In response to unloading the device image, the unloading of the device image is recorded in the tracking data in the memory.

2. The method of claim 1, wherein multiple device images are simultaneously loaded into the programmable device, the method comprising: Create a unique identifier corresponding to the device image loaded into the programmable device; as well as The unique identifier is stored in the memory.

3. The method according to claim 1, further comprising: The processing unit counts the number of device images loaded into the programmable device since the programmable device has been reset.

4. The method of claim 1, wherein the platform circuitry has been implemented in the programmable device using the programmable circuitry resources of the programmable device, the method further comprising: The compatibility between the device image and the platform circuitry is detected by comparing the tracking data used for the device image with the tracking data used for the platform circuitry.

5. The method according to claim 4, further comprising: In response to determining incompatibility based on the detection, perform one or more of the following: Generate an error code and store the error code as part of the trace data; or The device image is rejected.

6. The method according to claim 1, further comprising: The identifier of the master device requesting the loading of the device image is determined, and the identifier is stored as a portion of the tracking data for the device image.

7. An electronic device, comprising: Multiple programmable circuit resources; as well as A processor is configured to program the plurality of programmable circuit resources, wherein the processor initiates executable operations, the executable operations including: In response to loading a device image for the electronic device, trace data for the device image is determined, wherein the device image includes programming data for one or more of the plurality of programmable circuit resources; The device image specifies a reconfigurable module that is loaded as part of a partial reconfiguration of the electronic device, and the device image includes a reconfigurable partition identifier and a reconfigurable module identifier. The tracking data used for the device image is stored in memory, wherein the reconfigurable partition identifier and the reconfigurable module identifier are stored as portions of the tracking data; and In response to unloading the device image, the unloading of the device image is recorded in the trace data in the memory.

8. The electronic device of claim 7, wherein a plurality of device images are simultaneously loaded into the electronic device, wherein the processor is configured to initiate an operation, the operation further comprising: Create a unique identifier corresponding to the plurality of device images loaded into the electronic device; as well as The unique identifier is stored in the memory.

9. The electronic device of claim 7, wherein the processor is configured to initiate an operation, the operation further comprising: The number of device images loaded into the electronic device since the electronic device was reset is counted.

10. The electronic device of claim 7, wherein the platform circuitry has been implemented in the electronic device using a selected programmable circuit resource from the plurality of programmable circuit resources, wherein the processor is configured to initiate an operation, the operation further comprising: The compatibility between the device image and the platform circuitry is detected by comparing the tracking data used for the device image with the tracking data used for the platform circuitry.

11. The electronic device of claim 10, wherein the processor is configured to initiate an operation, the operation further comprising: In response to determining incompatibility based on the detection, an error code is generated and the error code is stored as part of the trace data.

12. The electronic device of claim 10, wherein the processor is configured to initiate an operation, the operation further comprising: In response to determining incompatibility based on the detection, the device image is rejected.

13. The electronic device of claim 7, wherein the processor is configured to initiate an operation, the operation further comprising: The identifier of the master device requesting the loading of the device image is determined, and the identifier is stored as a portion of the tracking data for the device image.

Images