Patent Description:
Programmable integrated circuits are a type of integrated circuit that can be programmed by a user to implement a desired custom logic function. In a typical scenario, a logic designer uses computer-aided design tools to design a custom logic circuit. When the design process is complete, the computer-aided design tools generate configuration data. The configuration data is loaded into memory elements to configure the devices to perform the functions of the custom logic circuit.

Configuration data may be supplied to a programmable device in the form of a configuration bit stream. After a first configuration bit stream has been loaded onto a programmable device, the programmable device may be reconfigured by loading a different configuration bit stream in a process known as reconfiguration. An entire set of configuration data is often loaded during reconfiguration.

Programmable devices may be used for coprocessing in big-data or fast-data applications. For example, programmable devices may be used in application acceleration tasks in a datacenter and may be reprogrammed during datacenter operation to perform different tasks. However, the speed of reconfiguration of programmable devices is traditionally several orders of magnitude slower than the desired rate of virtualization in datacenters. Moreover, on-chip caching or buffering of prefetched configuration bit-streams to hide the latency of reconfiguration is undesirably expensive in terms of silicon real estate. Additionally, repeated fetching of configuration bit-streams from off-chip storage via the entire configuration circuit chain is energy intensive.

Situations frequently arise where it would be desirable to design and implement programmable devices with improved reconfiguration speed, reduced energy consumption, and parallel reconfiguration capabilities.

It is within this context that the embodiments herein arise.

<CIT> discloses an image data processing apparatus, an image data processing method and a computer readable medium. The image data processing apparatus includes a configuration selecting unit, a loading unit, and a controller. The configuration selecting unit determines types of image characteristics of individual processing units in image data and selects plural pieces of circuit configuration data for individual processing units. The loading unit predicts a predetermined number of pieces of circuit configuration data in descending order of the likelihood of being selected for the processing unit currently being processed, and loads, before selection of the circuit configuration data for the processing unit, the predetermined number of pieces of configuration data into a circuit configuration memory for a reconfigurable circuit. If the selected circuit configuration data has already been loaded, the controller causes the circuit configuration to be reconfigured. If the selected circuit configuration data has not been loaded, the controller causes the selected circuit configuration data to be loaded and the circuit configuration to be reconfigured.

<CIT> provides a virtualization platform for Network Functions Virtualization (NFV). The virtualization platform may include a host processor coupled to an acceleration coprocessor. The acceleration coprocessor may be a reconfigurable integrated circuit to help provide improved flexibility and agility for the NFV. The coprocessor may include multiple virtual function hardware acceleration modules each of which is configured to perform a respective accelerator function. A virtual machine running on the host processor may wish to perform multiple accelerator functions in succession at the coprocessor on a given data. In one suitable arrangement, intermediate data output by each of the accelerator functions may be fed back to the host processor. In another suitable arrangement, the successive function calls may be chained together so that only the final resulting data is fed back to the host processor.

Advantageous embodiments are subject to the dependent claims and are described below.

A host processor may be tasked to perform a pool of jobs/tasks. In order to improve the speed at which these tasks are performed, a coprocessor integrated circuit can be used to perform a subset of the pool of tasks. The host processor sends an acceleration request to the coprocessor. This acceleration request is received by a secure device manager in the coprocessor, which identifies one or more logic sectors that are available to perform one or more given tasks associated with the acceleration request.

During an execution phase, the secure device manager communicates with logic sector managers at each of the logic sectors to determine whether any of the logic sectors are already configured to carry out the given task. If it is determined that such a pre-configured sector exists, that sector may be selected and used to execute the given task.

If it is determined that such a pre-configured sector does not exist, the host processor may provide the logic sector manager of an available sector with a pointer to the location of the configuration bit stream required for performing the given task that is stored in a stacked memory die. However, in some cases, the required configuration bit stream may not be present in the stacked memory die. The logic sector manager may determine whether the required configuration data is present in the stacked memory die.

If it is determined that the required configuration data is stored in the stacked memory die, the required configuration bit stream is retrieved from the stacked memory die and is used to reconfigure the available sector. The configuration data stored on the stacked memory die may be unencrypted. The stacked memory die may act as an instruction cache from which configuration data are fetched by the logic sector managers for reconfiguring the logic sectors.

If it is determined that the required configuration data is not stored in the stacked memory die, the logic sector manager of the available sector sends a request to the host processor asking the host processor to provide the required configuration bit stream to the stacked memory die. The logic sector manager may then load the required configuration bit stream onto the available sector, thereby reconfiguring the available sector. In some scenarios, the logic sector manager receives the required configuration bit stream from the host processor directly through the secure device manager, in which case the required configuration bit stream may also be stored on the stacked memory die.

A coprocessor integrated circuit may perform steps for load balancing jobs/tasks received from a host processor. A host processor may send an nondeterministic job/task with a predetermined time budget to the coprocessor. Some tasks provided to the coprocessor may be deterministic in that they will take a predetermined amount of time to complete. In contrast, other tasks provided to the coprocessor may be nondeterministic in that it is not possible to predict the number of steps required to complete each task.

The coprocessor may analyze the received task and may allocate an initial number of logic sectors to attempt to complete the task within the required time budget. The coprocessor may monitor the duration for the task while the task is being performed by the initially allocated logic sectors. While monitoring the duration of the task, the coprocessor may determine that the initially allocated logic sectors will not be able to complete the job within the required time budget.

In response to determining that the time budget cannot be adhered to with just the initially allocated logic sectors, the coprocessor may introduce more parallelism by dynamically allocating additional sectors to help process the task. In particular, idle sectors or sectors handling less critical tasks may be recruited/borrowed and reconfigured to perform the time-sensitive task. In some embodiments, the maximum number of concurrently (e.g., simultaneously) running sectors may optionally be limited.

Further features of the invention, its nature and various advantages will be more apparent from the accompanying drawings and following detailed description.

Embodiments of the present invention relate to integrated circuits and, more particularly, to programmable integrated circuits.

Programmable integrated circuits use programmable memory elements to store configuration data. Configuration data may be generated based on source code corresponding to application-specific tasks to be performed in parallel on the programmable integrated circuit. During programming of a programmable integrated circuit, configuration data is loaded into the memory elements. The memory elements may be organized in arrays having numerous rows and columns. For example, memory array circuitry may be formed in hundreds or thousands of rows and columns on a programmable logic device integrated circuit.

During normal operation of the programmable integrated circuit, each memory element provides a static output signal. The static output signals that are supplied by the memory elements serve as control signals. These control signals are applied to programmable logic on the integrated circuit to customize the programmable logic to perform a desired logic function.

It may sometimes be desirable to configure or reconfigure the programmable integrated circuit as an accelerator circuit to efficiently perform parallel processing tasks. The accelerator circuit may include multiple columns soft processors of various types that are specialized for different types of parallel tasks. The accelerator circuit may be dynamically reconfigured to optimally assign and perform the parallel tasks.

An illustrative programmable integrated circuit such as programmable logic device (PLD) <NUM> is shown in <FIG>. As shown in <FIG>, programmable integrated circuit <NUM> may have input-output circuitry <NUM> for driving signals off of device <NUM> and for receiving signals from other devices via input-output pins <NUM>. Interconnection resources <NUM> such as global and local vertical and horizontal conductive lines and buses may be used to route signals on device <NUM>. Interconnection resources <NUM> include fixed interconnects (conductive lines) and programmable interconnects (i.e., programmable connections between respective fixed interconnects). Programmable logic <NUM> may include combinational and sequential logic circuitry. The programmable logic <NUM> may be configured to perform a custom logic function.

Programmable integrated circuit <NUM> contains memory elements <NUM> that can be loaded with configuration data (also called programming data) using pins <NUM> and input-output circuitry <NUM>. Once loaded, the memory elements <NUM> may each provide a corresponding static control output signal that controls the state of an associated logic component in programmable logic <NUM>. Typically, the memory element output signals are used to control the gates of metal-oxide-semiconductor (MOS) transistors. Some of the transistors may be p-channel metal-oxide-semiconductor (PMOS) transistors. Many of these transistors may be n-channel metal-oxide-semiconductor (NMOS) pass transistors in programmable components such as multiplexers. When a memory element output is high, an NMOS pass transistor controlled by that memory element will be turned on to pass logic signals from its input to its output. When the memory element output is low, the pass transistor is turned off and does not pass logic signals.

A typical memory element <NUM> is formed from a number of transistors configured to form cross-coupled inverters. Other arrangements (e.g., cells with more distributed inverter-like circuits) may also be used. With one suitable approach, complementary metal-oxide-semiconductor (CMOS) integrated circuit technology is used to form the memory elements <NUM>, so CMOS-based memory element implementations are described herein as an example. In the context of programmable integrated circuits, the memory elements store configuration data and are therefore sometimes referred to as configuration random-access memory (CRAM) cells.

An illustrative system environment for device <NUM> is shown in <FIG>. Device <NUM> may be mounted on a board <NUM> in a system <NUM>. In general, programmable logic device <NUM> may receive configuration data from programming equipment or from other suitable equipment or device. In the example of <FIG>, programmable logic device <NUM> is the type of programmable logic device that receives configuration data from an associated integrated circuit <NUM>. With this type of arrangement, circuit <NUM> may, if desired, be mounted on the same board <NUM> as programmable logic device <NUM>.

Circuit <NUM> may be an erasable-programmable read-only memory (EPROM) chip, a programmable logic device configuration data loading chip with built-in memory (sometimes referred to as a "configuration device"), or another suitable device. When system <NUM> boots up (or at another suitable time), the configuration data for configuring the programmable logic device may be supplied to the programmable logic device from device <NUM>, as shown schematically by path <NUM>. The configuration data that is supplied to the programmable logic device may be stored in the programmable logic device in its configuration random-access-memory elements <NUM>.

System <NUM> may include processing circuits <NUM>, storage <NUM>, and other system components <NUM> that communicate with device <NUM>. The components of system <NUM> may be located on one or more boards such as board <NUM> or other suitable mounting structures or housings and may be interconnected by buses, traces, and other electrical paths <NUM>.

Configuration device <NUM> may be supplied with the configuration data for device <NUM> over a path such as path <NUM>. Configuration device <NUM> may, for example, receive the configuration data from configuration data loading equipment <NUM> or other suitable equipment that stores this data in configuration device <NUM>. Device <NUM> may be loaded with data before or after installation on board <NUM>.

It can be a significant undertaking to design and implement a desired logic circuit in a programmable logic device. Logic designers therefore generally use logic design systems based on computer-aided-design (CAD) tools to assist them in designing circuits. A logic design system can help a logic designer design and test complex circuits for a system. When a design is complete, the logic design system may be used to generate configuration data for electrically programming the appropriate programmable logic device.

As shown in <FIG>, the configuration data produced by a logic design system <NUM> may be provided to equipment <NUM> over a path such as path <NUM>. The equipment <NUM> provides the configuration data to device <NUM>, so that device <NUM> can later provide this configuration data to the programmable logic device <NUM> over path <NUM>. Logic design system <NUM> may be based on one or more computers and one or more software programs. In general, software and data may be stored on any computer-readable medium (storage) in system <NUM> and is shown schematically as storage <NUM> in <FIG>.

In a typical scenario, logic design system <NUM> is used by a logic designer to create a custom circuit design. The system <NUM> produces corresponding configuration data which is provided to configuration device <NUM>. Upon power-up, configuration device <NUM> and data loading circuitry on programmable logic device <NUM> is used to load the configuration data into CRAM cells <NUM> of device <NUM>. Device <NUM> may then be used in normal operation of system <NUM>.

After device <NUM> is initially loaded with a set of configuration data (e.g., using configuration device <NUM>), device <NUM> may be reconfigured by loading a different set of configuration data. Sometimes it may be desirable to reconfigure only a portion of the memory cells on device <NUM> via a process sometimes referred to as partial reconfiguration. As memory cells are typically arranged in an array, partial reconfiguration can be performed by writing new data values only into selected portion(s) in the array while leaving portions of array other than the selected portion(s) in their original state.

Partial reconfiguration may be a particularly useful feature when developing an acceleration framework. For example, consider a scenario in which a system such as system <NUM> includes a host processor <NUM> that is coupled to other network components via paths <NUM> (see, e.g., <FIG>). As shown in <FIG>, host processor <NUM> is coupled to a coprocessor (e.g., an accelerator circuit) such as coprocessor <NUM> (sometimes referred to herein as accelerator circuit <NUM>, or accelerator <NUM>) via path <NUM>. Accelerator circuit <NUM> may be a programmable integrated circuit such as device <NUM> of <FIG> or alternatively, multiple accelerator circuits may be in a programmable integrated circuit. Accelerator circuit <NUM> may include various processing nodes (e.g., processing cores, processor cores) such as cores P1-P4 to help accelerate the performance of host processor <NUM>. Cores P1-P4 may be soft processor cores or soft processors that are configurable (e.g., programmable). In some instances, processor cores such as cores P1-P4 may be implemented as logic sectors in accelerator circuit <NUM>.

Configured as such, accelerator circuit <NUM> may sometimes be referred to as a "hardware accelerator. " As examples, the processing cores on the coprocessor may be used to accelerate a variety of functions, which may include but are not limited to: encryption, Fast Fourier transforms, video encoding/decoding, convolutional neural networks (CNN), firewalling, intrusion detection, database searching, domain name service (DNS), load balancing, caching network address translation (NAT), and other suitable network packet processing applications, just to name a few.

For instances in which cores P1-P4 are implemented as logic sectors in accelerator circuit <NUM>, each logic sector may be managed using logic sector managers, which may in turn be managed using a secure device manager. As shown in <FIG>, accelerator circuit <NUM> may include multiple logic sectors <NUM> (sometimes referred to as sectors <NUM>). Each logic sector may be managed by a respective one of logic sector managers (LSM) <NUM>. Logic sector managers <NUM> may be managed by secure device manager <NUM>. Hard processing controller <NUM> may receive configuration data (e.g., configuration bit streams) and/or accelerator requests from a host processor (e.g., host processor <NUM> of <FIG>). Secure device manager <NUM> may receive the configuration data, the accelerator requests, and commands from hard processing controller <NUM>. Hard processing controller <NUM> may, for instance, be a microprocessor. Secure device manager <NUM> may provide commands, configuration data, and acceleration requests to logic sector managers <NUM> over a bus <NUM>.

In some instances, the configuration data and accelerator requests may optionally be compressed and encrypted. Thus, secure device manager <NUM> may include decompression engine <NUM> and decryption engine <NUM> for decompressing and decrypting data received from the host processor through hard processing controller <NUM>.

Logic sectors <NUM> are individually configurable/programmable. This allows each of logic sectors <NUM> to independently process different tasks in parallel. The parallel processing enabled by logic sectors <NUM> may be utilized to perform application acceleration (e.g., in a datacenter) for a variety of tasks or jobs simultaneously by reconfiguring different subsets of the logic sectors to perform said tasks.

In order to efficiently manage application acceleration as new tasks are issued to accelerator circuit <NUM> from the host processor, it may be necessary to perform real-time reconfiguration on any of logic sectors <NUM> that will be used to process a given newly received task. In other words, reconfiguration of logic sectors <NUM> may be performed while accelerator circuit <NUM> is running and may be performed without interrupting the operation of accelerator circuit <NUM>.

The selection of which of logic sectors <NUM> are to be used for a given task may be determined by identifying which sectors are idle (e.g., not presently performing a task) and by identifying which sectors are handling lower-priority tasks (e.g., tasks without a fixed time budget) compared to the priority of the given task. Some or all of logic sectors <NUM> that are identified as being idle or as performing less critical tasks may then be selected, and if necessary, reconfigured to perform operations of the given task. Reassignment of logic sectors <NUM> that are working on a lower-priority task than the given task in need of sector assignment may be performed based on a load-balancing mechanism. It should be noted that those logic sectors <NUM> that are identified as already being configured to perform the given task may be given selection priority over any sectors that would need to be reconfigured to perform said task.

Configuration data received by accelerator circuit <NUM> may be stored in memory on the same circuit package as accelerator circuit <NUM>. As shown in <FIG>, coprocessor <NUM> and one or more in-package stacked memory elements <NUM> (sometimes referred to as memory element <NUM> or memory die <NUM>) are integrated as part of an IC package <NUM>.

In some instances, memory die <NUM> is mounted on accelerator circuit <NUM> directly. Memory die <NUM> may be connected to accelerator circuit <NUM> through through-silicon vias (TSVs) that pass through one or more silicon layers of the circuit die of accelerator circuit <NUM>. These TSVs may allow memory die <NUM> to load configuration data onto sectors <NUM> of accelerator circuit <NUM> up to three orders of magnitude faster than traditional reconfiguration techniques.

Configuration data from the host processor may be loaded onto memory die <NUM> after undergoing processing/routing through secure device manager <NUM> of accelerator circuit <NUM> (e.g., after undergoing decompression and decryption). The configuration data may include one or more sector-level reconfiguration bit streams. When one of sectors <NUM> is selected to perform a task, if that sector needs to be reconfigured to perform the task (e.g., because the sector is presently configured to perform a different task), then secure device manager <NUM> may provide the selected sector with a pointer to the location of the necessary configuration bit stream (e.g., persona) required to perform that task in memory die <NUM>.

In some scenarios, the memory die <NUM> may not already have the necessary configuration bit stream stored when said bit stream is needed by the selected sector. In this case, secure device manager <NUM> may retrieve the necessary configuration bit stream from external memory and may load the retrieved bit stream onto the selected sector and onto memory die <NUM>.

Accelerator circuit <NUM> and memory elements <NUM> described above in connection with <FIG> may perform steps for receiving and storing configuration bit streams from a host processor during a pre-fetch phase of an instruction cycle (see, e.g., illustrative steps of <FIG>).

At step <NUM>, a pre-fetch phase may be initiated by a host processor (e.g., host processor <NUM> of <FIG>) for a set of anticipated configuration bit streams (e.g., corresponding to processing tasks). These configuration bit streams may be provided to a coprocessor (e.g., accelerator circuit <NUM> of <FIG>).

At step <NUM>, a secure device manager within the coprocessor (e.g., secure device manager <NUM> of <FIG>) may receive the configuration bit streams from the host processor and may perform decompression and decryption operations on the received bit streams.

At step <NUM>, logic sector managers within the coprocessor (e.g., logic sector managers <NUM> of <FIG>) may be used to load selected bit streams into each logic sector to configure each logic sector with a corresponding function or "persona" (e.g., to configure each logic sector to perform a particular task).

At step <NUM>, all available decompressed and decrypted configuration bit streams may be stored into one or more in-package stacked memory elements (e.g., memory elements <NUM> of <FIG>).

By storing decompressed and decrypted configuration bit streams in in-package stacked memory elements in this way, these bit streams may be readily accessed for reconfiguring logic sectors with greater speed and power efficiency compared to traditional methods in which configuration bit streams are only retrieved from off-chip storage.

Accelerator circuit <NUM> and memory elements <NUM> described above in connection with <FIG> may perform steps for managing sectors to perform a pool of jobs/tasks received from a host processor (see, e.g., illustrative steps of <FIG>).

At step <NUM>, a host processor (e.g., host processor <NUM> of <FIG>) may be tasked to perform a pool of jobs/tasks. In order to improve the speed at which these tasks are performed (e.g., to accelerate the tasks), a coprocessor (e.g., accelerator circuit <NUM> of <FIG>) may be used to perform at least a subset of the pool of tasks.

At step <NUM>, the host processor sends an acceleration request to the coprocessor. This acceleration request may be received by a secure device manager (e.g., secure device manager <NUM> of <FIG>), which may identify one or more logic sectors (e.g., of logic sectors <NUM> of <FIG>) that are available to perform one or more given tasks (e.g., current jobs) associated with the acceleration request.

At step <NUM>, during an execution phase of the instruction cycle, the secure device manager communicates with logic sector managers (e.g., logic sector managers <NUM> of <FIG>) at each of the logic sectors to determine whether any of the logic sectors are already configured to carry out the given task. Depending on whether a sector exists that is pre-configured to carry out the given task, the process may proceed to either step <NUM> or step <NUM>.

At step <NUM>, if such a pre-configured sector exists, that sector may be selected and used to execute the given task.

At step <NUM>, if such a pre-configured sector does not exist, the host processor may provide a logic sector manager of an available sector with a pointer to the location of the configuration bit stream required for performing the given task that is stored in a stacked memory die (e.g., memory die <NUM> of <FIG>). Configuration data stored on the stacked memory die may be unencrypted. However, it is possible that the required configuration bit stream will not be present in the stacked memory die. Thus, the logic sector manager may check to determine whether the required configuration data is present in the stacked memory die. If the required configuration data is present in the stacked memory die, then the process may proceed to step <NUM>. Otherwise, the process may proceed to step <NUM>.

At step <NUM>, if the required configuration data is stored in the stacked memory die (e.g., if there is a cache hit), the required or desired configuration bit stream may be retrieved from the stacked memory die and may be used to reconfigure the available sector (e.g., by loading the required configuration bit stream onto the available sector). The configuration image stored in the stacked memory die may not be encrypted. The stacked memory die may act as an instruction cache from which configuration data (e.g., bit streams) are fetched by the logic sector managers for reconfiguring the logic sectors.

At step <NUM>, if the required configuration data is not stored in the stacked memory die (e.g., if there is a cache miss), the logic sector manager of the available sector sends a request to the host processor asking the host processor to provide the required configuration bit stream to the stacked memory die. The logic sector manager may then load the required configuration bit stream onto the available sector, thereby reconfiguring the available sector. In some scenarios, the logic sector manager receives the required configuration bit stream from the host processor directly through the secure device manager, in which case the required configuration bit stream may also be stored on the stacked memory die.

Accelerator circuit <NUM> described above in connection with <FIG> may perform steps for load balancing jobs/tasks received from a host processor (see, e.g., illustrative steps of <FIG>).

At step <NUM>, a host processor (e.g., host processor <NUM> of <FIG>) may send an nondeterministic job/task with a predetermined (e.g., fixed) time budget to a coprocessor (e.g., accelerator circuit <NUM> of <FIG>). Some tasks provided to the coprocessor may be deterministic in that they will take a predetermined amount of time to complete. In contrast, other tasks provided to the coprocessor may be nondeterministic in that it is not possible to predict the number of steps required to complete each task (e.g., due to iterative conditional loops). Thus, the amount of processing power, and therefore the number of logic sectors, required to perform a nondeterministic task given a fixed time budget may need to be dynamically controlled in order to ensure that the task can be completed within the time budget.

At step <NUM>, the coprocessor may analyze the received task and may allocate an initial number of logic sectors (e.g., logic sectors <NUM> of <FIG>) to attempt to complete the task within the required time budget.

At step <NUM>, the coprocessor may monitor the duration for the task while it is being performed by the initially allocated logic sectors. While monitoring the duration of the task, the coprocessor may determine that the initially allocated logic sectors will not be able to complete the job within the required time budget.

At step <NUM>, in response to determining that the time budget cannot be adhered to with just the initially allocated logic sectors, the coprocessor may introduce more parallelism by dynamically allocating additional sectors to help process the task. In particular, idle sectors or sectors handling less critical tasks may be recruited/borrowed and reconfigured to perform the time-sensitive task.

By prioritizing time-critical tasks in this way, the overall efficiency of the coprocessor may be advantageously increased compared to traditional coprocessor methods that lack load balancing functionality.

At step <NUM>, the maximum number of concurrently (e.g., simultaneously) running sectors may optionally be limited. This limitation may help the coprocessor meet power savings criteria or other operational constraints. The steps of <FIG> and <FIG> can be used together and are not mutually exclusive.

The embodiments thus far have been described with respect to integrated circuits. The methods and apparatuses described herein may be incorporated into any suitable circuit. For example, they may be incorporated into numerous types of devices such as programmable logic devices, application specific standard products (ASSPs), and application specific integrated circuits (ASICs). Examples of programmable logic devices include programmable arrays logic (PALs), programmable logic arrays (PLAs), field programmable logic arrays (FPLAs), electrically programmable logic devices (EPLDs), electrically erasable programmable logic devices (EEPLDs), logic cell arrays (LCAs), complex programmable logic devices (CPLDs), and field programmable gate arrays (FPGAs), just to name a few.

The programmable logic device described in one or more embodiments herein may be part of a data processing system that includes one or more of the following components: a processor; memory; IO circuitry; and peripheral devices. The data processing can be used in a wide variety of applications, such as computer networking, data networking, instrumentation, video processing, digital signal processing, or any suitable other application where the advantage of using programmable or reprogrammable logic is desirable. The programmable logic device can be used to perform a variety of different logic functions. For example, the programmable logic device can be configured as a processor or controller that works in cooperation with a system processor. The programmable logic device may also be used as an arbiter for arbitrating access to a shared resource in the data processing system. In yet another example, the programmable logic device can be configured as an interface between a processor and one of the other components in the system. In one embodiment, the programmable logic device may be one of the family of devices owned by ALTERA/INTEL Corporation.

Claim 1:
A system, comprising:
a host processor (<NUM>) tasked to perform a job and configured to generate a corresponding acceleration request for accelerating the job;
a coprocessor (<NUM>) configured to receive the acceleration request from the host processor (<NUM>); and
a memory die (<NUM>) connected to the coprocessor (<NUM>), wherein the coprocessor (<NUM>) comprises a plurality of logic sectors (<NUM>), wherein the logic sectors (<NUM>) are individually configurable;
wherein:
the memory die (<NUM>) is stacked on the coprocessor (<NUM>) and both are provided in the same circuit package;
the coprocessor (<NUM>) further comprises a logic sector manager (<NUM>) configured to retrieve a configuration bit stream from the memory die (<NUM>) and to configure a selected one of the plurality of logic sectors (<NUM>) with the retrieved configuration bit stream, and
the coprocessor (<NUM>) further comprises a secure device manager (<NUM>) configured to provide, if a required configuration bit stream for configuring the selected one of the plurality of logic sectors (<NUM>) is not available in the memory die (<NUM>), the required configuration bit stream to the logic sector manager (<NUM>) to facilitate said configuration of the selected one of the plurality of logic sectors (<NUM>) by the logic sector manager (<NUM>),
wherein, if the required configuration data is not stored in the memory die (<NUM>), the logic sector manager sends a request to the host processor (<NUM>) asking the host processor (<NUM>) to provide the required configuration bit stream to the memory die (<NUM>), and
wherein the logic sector manager (<NUM>) is configured to receive a pointer from the host processor (<NUM>), and to determine whether the required configuration bit stream is stored in the memory die (<NUM>) based on the pointer, and the logic sector manager (<NUM>) is configured to receive the configuration bit stream from the memory die (<NUM>) through the through-silicon vias if the required configuration bit stream is stored in the memory die (<NUM>), and to receive required configuration bit stream from the host processor (<NUM>) if the required configuration bit stream is not stored in the memory die (<NUM>).