Regularities in structures in programmable logic devices

Abstract

A programmable logic device having structural regularity is disclosed. For example, the programmable logic device can include a plurality of similar heterogeneous logic blocks. A user's design can be implemented in a first set of the heterogeneous logic blocks. The user's design can be moved or copied to a second set of the heterogeneous logic blocks. More specifically, routing, timing, and / or placement information associated with the implementation of the user's design in the first set of the heterogeneous logic blocks can be used to implement the user's design in the second set of the heterogeneous logic blocks.

Description

TECHNICAL FIELD

[0001] Aspects of the present invention generally relate to programmable logic devices, and more particularly to regularity of structures within programmable logic devices. BACKGROUND

[0002] Programmable logic devices (PLDs) are well-known general-purpose devices that can be programmed by a user to implement a variety of selected functions. One example of a PLD is a field programmable gate array (FPGA). An FPGA can include an array of configurable logic blocks, a plurality of input / output blocks, and block RAM elements that are selectively connected to one another through a programmable interconnect structure.

[0003] A user can capture a PLD design with one or more software design tools. The software design tools allow the user to specify the desired functionality and / or behavior of the PLD. The user's design can target or specify one or more particular logic blocks within the PLD to implement the desired functionality and / or behavior. Additionally, the software design tools can synthesize, place, and route the user's design, and generate an associated configuration file. The configuration file can be a bit-by-bit representation of the user's design that can be used to program the configurable elements within the PLD when the PLD is powered on.

[0004] In some cases, a user's PLD design can include a design core. The design core can implement, for example, a particular function or feature that can encompass several logic blocks, input / output blocks, RAM elements, etc. of the PLD. A design core, particularly a large and complex design core, can require a significant amount of design time to describe and implement through the software design tools. For example, inputting, synthesizing (e.g., verifying timing and / or operating frequency), placing, and routing a particular design core can take hours or days.

[0005] In some cases, a user can wish to "reposition" a design core. Repositioning a design core can include changing the location of the design core within the PLD, or in some cases, moving the design core entirely to a different PLD. Conventional methods can require the user to re-run the software design tools to specify the new design core location, synthesize, place, and route the updated design. Re-running the design tools, particularly when the design core is large and / or complex, can disadvantageously increase design time. Therefore, a more efficient method is needed to reposition all or part of a design within a PLD while providing predictable timing and / or maximum operating frequency. SUMMARY

[0006] This Summary is provided to introduce some concepts in a simplified form that are further described in the detailed description below. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0007] Aspects of the disclosure relate to configuration data reuse with respect to programmable logic devices. A programmable logic device can include a plurality of nearly identical heterogeneous logic blocks. Configuration data for a design implemented within a first heterogeneous logic block can be reused to implement the design within a second heterogeneous logic block. An example programmable logic device can include a plurality of heterogeneous logic blocks, each including a digital signal processing block, a programmable logic block, and a same configuration of a platform management controller coupled to each heterogeneous logic block. The platform management controller can be configured to implement a design core in the first heterogeneous logic block. The platform management controller can also implement the design core in the second heterogeneous logic block and receive a first bitstream to configure the first and second heterogeneous logic blocks. The system can also include a processing device configured to generate the bitstream.

[0008] An example system is disclosed that can include a programmable logic device including a plurality of heterogeneous logic blocks, each including a digital signal processing block, a programmable logic block, and a same configuration of a platform management controller coupled to each heterogeneous logic block. The platform management controller can be configured to implement a design core in the first heterogeneous logic block. Further, the platform management controller can implement the design core in the second heterogeneous logic block and can also include a processing device configured to generate a first bitstream and a second bitstream.

[0009] Example methods disclosed herein can be used to generate bitstreams for programmable logic devices. The methods can include generating a first bitstream including first configuration data to implement a first design in a first heterogeneous logic block of a programmable logic device. The first bitstream can include a first identifier to associate the first configuration data with the first heterogeneous logic block. The methods can include generating a second bitstream including the first configuration data to implement the first design in a second heterogeneous logic block of the programmable logic device. The second bitstream can include a second identifier to associate the first configuration data with the first heterogeneous logic block. BRIEF DESCRIPTION OF DRAWINGS

[0010] The example embodiments are illustrated by way of example and not intended to be limited by the figures of the accompanying drawings. In the figures and specification, like reference numerals designate like elements throughout the figures and specification.

[0011] Figure 1 A block diagram of an example programmable logic device is shown.

[0012] Figure 2 is a block diagram of a heterogeneous logic block.

[0013] Figure 3A and Figure 3B shows a block diagram illustrating example operations to replicate or move a design core within a programmable logic device having multiple heterogeneous logic blocks.

[0014] Figure 4 shows a block diagram of an example processing device.

[0015] Figure 5 shows an illustrative flow diagram depicting example operations for generating a bitstream. DETAILED DESCRIPTION

[0016] In the following description, numerous specific details are set forth (such as examples of specific components, circuits, and processes) to provide a thorough understanding of the present disclosure. The term“coupled” as used herein means coupled directly to or through one or more intervening components or circuits. Also, in the following description and for purposes of explanation, specific nomenclature and / or details are set forth to provide a thorough understanding of the example embodiments. However, it will be apparent to one skilled in the art that the example embodiments can be practiced without these specific details. In other instances, well-known circuits and devices are shown in block diagram form to avoid obscuring the present disclosure. Any of the signals provided over various buses described herein can be time-multiplexed onto a single physical bus line, and vice versa, and any of the signals provided over various buses can be digital signals present during one or more clocks cycles or analog signals present during one or more clock cycles. Further, the interconnection between circuit elements or software blocks can be shown as buses or as single signal lines. Each of the buses can alternatively be a single signal line, and each of the single signal lines can alternatively be buses, and lines or buses can be used to indicate any of the common or different signals. Example embodiments are not, therefore, to be limited to the specific circuitry and software described.

[0017] Repositioning and / or reusing some or all of the design of a programmable logic device can be costly in terms of design time. For example, a user can re-execute a software design tool to reposition the user’s design, compile, place, route, and generate new configuration data. Depending on the size and / or complexity of the user’s design, re-execution of the software design tool can take minutes, hours, or in some cases, days to complete.

[0018] Aspects of the present disclosure can reduce design time associated with repositioning and / or reusing existing designs by implementing programmable logic devices using a plurality of heterogeneous logic blocks. In one embodiment, the heterogeneous logic blocks can include a plurality of logic elements (including programmable logic, RAM) and one or more specialized compute blocks (e.g., digital signal processing blocks). The content and arrangement of each heterogeneous logic block can be substantially similar to one another. In this manner, a design that can be implemented within one of the heterogeneous logic blocks can be easily moved or copied in any of the other heterogeneous logic blocks. In some implementations, a design that spans two or more heterogeneous logic blocks can also be repositioned and / or copied to another two or more heterogeneous logic blocks.

[0019] Figure 1 A block diagram of an example programmable logic device (PLD) 100 is shown. The PLD 100 can include a processor system 110, a platform management controller (PMC) 120, a network-on-chip (NoC) controller 130, a NoC communication fabric 135, and a plurality of heterogeneous logic blocks 140-147. In some implementations, the PLD 100 can include fewer, more, or different logic elements or logic blocks than those described in the example. For simplicity, some logic blocks or elements can not be shown. For example, the PLD 100 can include input / output blocks, clock distribution blocks, and / or other logic blocks. Figure 1 A block diagram of an example programmable logic device (PLD) 100 is shown. The PLD 100 can include a processor system 110, a platform management controller (PMC) 120, a network-on-chip (NoC) controller 130, a NoC communication fabric 135, and a plurality of heterogeneous logic blocks 140-147. In some implementations, the PLD 100 can include fewer, more, or different logic elements or logic blocks than those described in the example. For simplicity, some logic blocks or elements can not be shown. For example, the PLD 100 can include input / output blocks, clock distribution blocks, and / or other logic blocks.

[0020] The processor system 110 can include one or more processing units and / or processors for use within the PLD 100. In some embodiments, the processor system 110 can include one or more processing cores (including ARM cores) and associated memory, cache memory, processor core interfaces, etc. The PMC 120 can include one or more logic blocks or circuit elements associated with platform management operations. In some embodiments, the PMC 120 can include power management logic, one or more bus interfaces (including JTAG, I2C, SE, eMMC, and other technically feasible bus interfaces). Further, the PMC 120 can include an interface for receiving configuration data within a bitstream. The configuration data can be used to configure configurable logic elements of the PLD to implement a user's design. The bitstream can include configuration data and other PLD-specific information. In some embodiments, the PMC 120 can be coupled to a bitstream storage device 150. The bitstream storage device 150 can include a bitstream 155, which in turn includes configuration data 157. In some embodiments, the bitstream storage device 150 can be a non-volatile memory having sufficient capacity to store the bitstream 155. In other embodiments, the bitstream storage device 150 can be a processing device configured to provide the bitstream 155 to the PLD 100. Further, the PMC 120 can be coupled to one or more logic blocks and / or elements within the PLD 100 via a configuration bus (not shown for simplicity) to configure the logic blocks and elements as described in the bitstream 155.

[0021] The NoC controller 130 can be coupled to the NoC fabric 135. Together, the NoC controller 130 and the NoC fabric 135 can form an addressable packetized data communication system that enables the transmission of data between one or more logic blocks and / or elements within the PLD 100. In some embodiments, the NoC controller 130 and / or the NoC fabric 135 can include programmable switches, programmable circuitry, and / or configuration registers (not shown for simplicity) to enable dynamic addressing and routing of data within the PLD 100.

[0022] Figure 1 The PLD 100 is shown to include heterogeneous logic blocks 140-147. The PLD 100 can include any technically feasible number of heterogeneous logic blocks. Each of the heterogeneous logic blocks 140-147 can be coupled to the NoC fabric 135 through a NoC interface (not shown for simplicity). As described in more detail below in connection with FIG. 2, the NoC fabric 135 can include a plurality of switches and / or routers that enable dynamic addressing and routing of data between the heterogeneous logic blocks 140-147. Figure 2 In more detail, the heterogeneous logic blocks 140-147 can include a plurality of functional and / or logic blocks of similar, identical, or approximately identical configuration. Figure 1The description of the heterogeneous logic blocks 140-147 in FIG. 1 is merely a logical representation and is not meant to imply or limit any implementation of the internal physical arrangement of circuitry, devices, etc. Thus, a design implemented within a heterogeneous logic block can be easily relocated to any other heterogeneous logic block due to its identical or similar configuration. Moreover, the NoC fabric 135 can provide access to data required to implement a design having any of the heterogeneous logic blocks 140-147.

[0023] Figure 2 is a block diagram of a heterogeneous logic block 200. The heterogeneous logic block 200 can be an example embodiment of any of the heterogeneous logic blocks 140-147 of FIG. 1. Figure 1 The heterogeneous logic block 200 can include programmable logic 210, a digital signal processing (DSP) block 220, memory 230, and a network-on-chip interface 240. In some implementations, the heterogeneous logic block 200 can include fewer logic blocks, more logic blocks, and / or different logic blocks than the logic blocks depicted in the example of FIG. 2 (not shown for simplicity). Examples of different logic blocks can include, but are not limited to, an Ethernet logic block, a soft-decision forward error correction (SD-FEC) block, a reference clock (RCLK) block, and other clock circuitry. Figure 2

[0024] The programmable logic 210 can include one or more arrays of one or more logic elements that can be configured to perform a variety of functions. For example, the programmable logic 210 can be configured to implement Boolean functions, mathematical functions, state machines, etc.

[0025] The DSP block 220 can include one or more configurable logic elements to implement various digital signal processing functions. In some embodiments, the DSP block 220 can include scalar units, vector units, memory interfaces, memory, etc. The memory 230 can provide flexible and dynamic storage of data within the heterogeneous logic block 200. The memory 230 can include static RAM, dynamic RAM, register memory, or any other technically feasible data storage element. The NoC interface 240 can be coupled to the programmable logic 210, the DSP block 220, and the memory 230. Moreover, the NoC interface 240 can be coupled to the NoC fabric 135 of FIG. 1. The NoC interface 240 can provide a packetized data communication interface to enable the heterogeneous logic block 200 to receive and transmit data over the NoC fabric 135. Thus, data can be transmitted and / or received between the programmable logic 210, the DSP block 220, and / or the memory 230 and any other component or logic block coupled to the NoC fabric 135. Figure 1

[0026] ​​As described above, heterogeneous logic block 200 can be an example embodiment of any of heterogeneous logic blocks 140-147. In some implementations, heterogeneous logic blocks 140-147 can all be similar, identical, or approximately identical to heterogeneous logic block 200. Multiple similar, identical, or approximately identical heterogeneous logic blocks can enable a user’s design to be easily relocated and / or replicated to other heterogeneous logic blocks. For example, a user’s design can be implemented in a first heterogeneous logic block, such as heterogeneous logic block 141. Because heterogeneous logic blocks 140-147 are substantially identical, the user’s design in heterogeneous logic block 141 can be replicated or relocated to any of the other heterogeneous logic blocks 140 or 142-147. Notably, NoC fabric 135 and NoC interface 240 can also enable design relocation and reuse by providing a means for easily transferring data to and from a user’s design independent of the physical location of the heterogeneous logic block within PLD 100. Furthermore, the “regularity” of similar, identical, or approximately identical heterogeneous logic blocks 140-147 can enable a user’s design to have a similar maximum operating frequency across different heterogeneous logic blocks.

[0027] Figure 3A A block diagram 300 depicting example operations for replicating or moving a design core within a PLD having multiple heterogeneous logic blocks is shown. For convenience, Figure 1 PLD 100 of FIG. 1 is used to illustrate the process, however the process can be used with any PLD having multiple similar, identical, or approximately identical heterogeneous logic blocks. A design core can be a portion of a user’s design that implements a particular function or feature, and can include a number of logic blocks, RAM elements, artificial intelligence (AI) engines, digital signal processors (DSPs), etc. Furthermore, a design core can include routing, timing, and placement information associated with the implementation of the design within a heterogeneous logic block. Those skilled in the art will recognize that routing and timing information in the context of a PLD device can refer to the routing and timing of signals within the PLD. Placement information can refer to the assignment and / or configuration of one or more operations to one or more logic blocks within the PLD. In the context of a PLD device, a design core can be a portion of a user’s design that implements a particular function or feature, and can include a number of logic blocks, RAM elements, AI engines, DSPs, etc. Furthermore, a design core can include routing, timing, and placement information associated with the implementation of the design within a heterogeneous logic block. Those skilled in the art will recognize that routing and timing information in the context of a PLD device can refer to the routing and timing of signals within the PLD. Placement information can refer to the assignment and / or configuration of one or more operations to one or more logic blocks within the PLD. Figure 3A In the example of FIG. 3, heterogeneous logic block 141 can include a design core 301 specified by a user. Design core 301 (sometimes referred to as an intellectual property (IP) core) can implement a particular function and / or feature.

[0028] Design core 301 can be moved (e.g., relocated) or replicated to form a design core 302 in heterogeneous logic block 144, as shown in block 305. Design core 302 can be a copy of design core 301. In some implementations, design core 302 can be a copy of design core 301 with some modifications. For example, design core 302 can be a copy of design core 301 with some modifications to the routing, timing, and / or placement information associated with the implementation of the design within a heterogeneous logic block. In some implementations, design core 302 can be a copy of design core 301 with some modifications to the logic blocks, RAM elements, AI engines, DSPs, etc. that implement the design core. Figure 3Ashown (design cores 301 and 302 are shown in dashed lines). Notably, since the heterogeneous logic blocks 140-147 are similar, identical, or nearly identical, the design core 301 can be easily moved or copied to other heterogeneous logic blocks. The work and effort expended by the user to execute the software design tool to design the design core 301 need not be replicated or repeated to implement the design core 302. Notably, routing, timing, and placement information associated with the design core 301 can be used (and in some cases reused) to implement the design core 302. For example, configuration data used to implement the design core 301 can be reused to configure and implement the design core 302 in the heterogeneous logic block 144.

[0029] As described above, a bitstream can include configuration data to configure all or a portion of the PLD 100. For example, a first bitstream can include configuration data to implement the design core 301 within the heterogeneous logic block 141. Since each of the heterogeneous logic blocks 140-147 of the PLD 100 are similar, identical, or nearly identical, the configuration data to implement the design core 301 within the heterogeneous logic block 141 can be similar, identical, or nearly identical to the configuration data to implement the design core 302 within the heterogeneous logic block 144. Thus, a second bitstream can include configuration data to implement the design core 301. However, the configuration data in the second bitstream can be "offset" to implement the design core 302 in the heterogeneous logic block 144 (instead of the heterogeneous logic block 141). In some implementations, a bitstream can include an identifier that indicates an offset of configuration data. In some implementations, the identifier can be a configuration data offset value, which can indicate a location or position of a design core (described by the configuration data) within the PLD 100. In some other implementations, the configuration data offset value can indicate a location or position of the design core within the bitstream. By simply changing the configuration data offset value, configuration data associated with the design core 301 can be moved from a first heterogeneous logic block to a second heterogeneous logic block.

[0030] It should be noted that in some implementations, relocating a design core from one heterogeneous logic block to another can involve re-routing some physical connections to the NoC fabric 135 (particularly when the design core is relocated between heterogeneous logic blocks on different sides of the NoC fabric 135, as shown in the example of FIG. 3B). For example, with reference to the example of FIG. 3B, the configuration data to implement the design core 301 in the heterogeneous logic block 141 can be offset to implement the design core 302 in the heterogeneous logic block 144. In this example, the configuration data to implement the design core 302 in the heterogeneous logic block 144 can be offset by 2 (since the design core 302 is two positions to the right of the design core 301 in the NoC fabric 135). Thus, the configuration data to implement the design core 302 in the heterogeneous logic block 144 can be offset by 2 from the configuration data to implement the design core 301 in the heterogeneous logic block 141. Figure 3A Figure 3A ​For each of the heterogeneous logic blocks 141 and 144, the distance to the NoC structure 135 may be different. Therefore, relocating the design core 301 to form the design core 302 may require incrementally rerouting some physical connections to the NoC structure 135. As a result, the physical connections from heterogeneous logic block 141 to the NoC structure 135 may differ from the physical connections from heterogeneous logic block 144 to the NoC structure 135.

[0031] Figure 3B Block diagram 310 illustrates another example operation for copying or moving a design core within a PLD having multiple heterogeneous logic blocks. Figure 3B In the example, design core 311 is implemented using heterogeneous logic blocks 141 and 143. In other words, design core 311 can be implemented using (e.g., across) both heterogeneous logic blocks 141 and 143. Heterogeneous logic blocks 144 and 146 (design cores 311 and 312 are shown in dashed lines) can be used to relocate or duplicate design core 311 to form design core 312. In some implementations, since design core 311 uses two heterogeneous logic blocks, design core 312 can use any two heterogeneous logic blocks of PLD 100. Flexible data routing provided by NoC controller 130 and NoC structure 135 allows for flexibility regarding which heterogeneous logic blocks 140–147 can be used to implement design core 312. For example, heterogeneous logic blocks 142 and 145 can be used to duplicate or relocate design core 311 to form design core 313 (shown in dashed lines). In this example, design core 311 can be a logical design core that can be split between any two similar, identical, or nearly identical heterogeneous logic blocks. Therefore, apart from the inter-block communication provided by the NoC controller 130 and the NoC architecture 135, the design core 311 does not require any dedicated inter-block communication.

[0032] like Figure 3A and Figure 3B As shown, without altering the original configuration data, the design core can be copied or relocated from a first group of one or more heterogeneous logic blocks to a second group of one or more heterogeneous logic blocks. Other arrangements of the design core and heterogeneous logic blocks are possible and are not shown for simplicity. Although shown as copying or moving the design core within a PLD, the design core can be copied or moved from the first PLD to other PLDs, particularly other PLDs with similar, identical, or nearly identical heterogeneous logic blocks (e.g., heterogeneous logic blocks in the first PLD). In other embodiments, the other PLDs can be vertically stacked and coupled together via silicon-based interconnects.

[0033] Figure 4A block diagram of an example processing device 400 is shown. The processing device 400 can receive user input and generate bitstreams to configure one or more PLDs. The processing device 400 may include an input / output interface 410, a bitstream interface 420, a processor 430, and a memory 440.

[0034] Input / output interface 410 may include hardware, software, and / or firmware to enable a user to provide data to and receive data from processing device 400. For example, input / output interface 410 may be coupled to one or more keyboards, mice, touchpads, or any other feasible devices to receive user input. Input / output interface 410 may also be coupled to one or more display devices to provide the user with textual or graphical information about the user's design and design process. In some embodiments, input / output interface 410 may include a network interface. The network interface enables user input and output data to be transmitted via a network (such as a wired or wireless network).

[0035] Bitstream interface 420 enables the transfer of bitstreams generated by software design tool modules (discussed in more detail below) to the PLD. Bitstream interface 420 can be coupled to bitstream storage device 450. In some embodiments, bitstream storage device 450 can be a memory device, such as flash memory, electrically erasable memory, or any other feasible memory device providing persistent data storage. The storage device can then be coupled to the PLD (e.g., ...). Figure 1 As shown), to allow the PLD to receive the bitstream. In another embodiment, the bitstream storage device 450 may be a processing device similar to the processing device 400. In such an embodiment, the bitstream storage device 450 can also receive and store the bitstream. The bitstream storage device 450 can then provide the bitstream to the PLD (e.g., via...). Figure 1 The PMC120 is used to complete the PLD configuration.

[0036] The memory 440 may include a non-transitory computer-readable storage medium (e.g., one or more non-volatile memory elements, such as EPROM, EEPROM, flash memory, hard disk drive, etc.) capable of storing software modules:

[0037] • Software (SW) design tool module 424, used to capture the user's design for the programmable logic device; and

[0038] • Operating system SW module 444, used to manage one or more operations of processing device 400.

[0039] Each software module includes instructions that, when executed by processor 430, cause processing device 400 to perform a corresponding function. The non-transitory computer-readable medium of memory 440 thus includes instructions for performing or facilitating Figure 5 all or part of the operations of

[0040] Processor 430 (coupled to input / output interface 410, bitstream interface 420, and memory 440) can be any one or more suitable processors capable of executing scripts or instructions of one or more software programs stored in processing device 400 (e.g., within memory 440).

[0041] Processor 430 can execute SW design tool module 442 to receive and capture a user’s design of one or more PLDs, and also generate a bitstream to configure the PLDs to implement the user’s design. Processor 430 can also execute SW design tool module 442 to relocate or replicate design cores from a first set of one or more heterogeneous logic blocks to a second set of one or more heterogeneous logic blocks. The first and second sets of one or more heterogeneous logic blocks can be located within a single PLD, or within two or more separate PLDs.

[0042] Processor 430 can execute operating system SW module 444 to manage one or more operations of processing device 400. For example, processor 430 can execute operating system SW module 444 to receive and output user data through input / output interface 410. Processor 430 can also execute operating system SW module 444 to write out a bitstream generated by execution of SW design tool module 442. The bitstream can be written out to bitstream storage device 450.

[0043] Figure 5 An illustrative flowchart depicting example operations 500 for generating a bitstream is shown. Although described here as being performed by processor 430 of Figure 4 processing device 400, operations 500 can be performed by any technically feasible processor, processing device, state machine, computer, server, etc.

[0044] Processor 430 can capture a PLD design of a first set of heterogeneous logic blocks (502). In some implementations, the PLD design can target a PLD that includes a plurality of similar, identical, or approximately identical heterogeneous logic blocks (e.g., heterogeneous logic blocks 140-147 of PLD 100). Processor 430 can execute software design tool module 442 to capture a user’s design. Further, execution of SW design tool module 442 can associate all or part of the user’s design with the first set of one or more heterogeneous logic blocks. In some implementations, the user’s design can include a design core to be implemented within the first set of heterogeneous blocks.

[0045] The processor 430 can generate configuration data for the first set of heterogeneous logic blocks (504). For example, the processor 430 can execute the SW design tool module 442 to process (e.g., compile and / or place and route) and generate configuration data for a PLD design associated with the first set of heterogeneous logic blocks.

[0046] The processor 430 can generate a first bitstream including the configuration data associated with the first set of heterogeneous logic blocks (506). The first bitstream can include configuration data offset values to associate the configuration data with the first set of heterogeneous logic blocks. The first bitstream can be used to configure one or more PLDs as described above with respect to Figure 1 .

[0047] The processor 430 can copy or move the design associated with the first set of heterogeneous logic blocks to a second set of heterogeneous logic blocks (508). For example, the processor 430 can execute the SW design tool module 442 to enable a user to copy or move the design from the first set of heterogeneous logic blocks to a second set of one or more heterogeneous logic blocks. In some implementations, a design core included in the first set of heterogeneous logic blocks can be copied or moved to the second set of heterogeneous logic blocks.

[0048] The processor 430 can reuse the configuration data associated with the first set of heterogeneous logic blocks for the second set of heterogeneous logic blocks (510). Since the design implemented within the second set of heterogeneous logic blocks is based on (e.g., copied and / or moved from) the first set of heterogeneous logic blocks, and since the heterogeneous logic blocks are similar, identical, or approximately identical, the configuration data can be reused.

[0049] Next, the processor 430 can generate a second bitstream including configuration data for the second set of heterogeneous logic blocks (512). In some implementations, the second bitstream can include the configuration data (determined in 510) and configuration data offset values to associate the configuration data with the second set of heterogeneous logic blocks. The second bitstream can be used to configure one or more PLDs as described above with respect to Figure 1 .

[0050] Those skilled in the art will appreciate that information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that can be referenced throughout the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0051] Moreover, those skilled in the art will appreciate that the functions explained herein can be implemented using software functioning in connection with a programmable computer, a general -purpose computer, a dedicated computer, or a specified computing device. As used herein the term "computer" includes any processor-based or digitally operated device that includes functionally similar components such as a central processing unit (CPU), memory, input / output interfaces, and peripheral devices. As used herein, the term "memory" includes one or more devices (e.g., random access memory (RAM), read-only memory (ROM), magnetic disk storage mediums, optical storage mediums, flash memory devices, etc.) that enable storage and retrieval of information such as computer program instructions, one or more operating systems, application programs, data structures, program modules, program logic and / or input data. The memory can be computer readable media used for storage of data like bitstream, program code, and / or other items during the execution of the program. Further, those skilled in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0052] The methods, sequences or algorithms described in connection with the aspects disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM lockers, flash lockers, ROM lockers, EPROM lockers, EEPROM lockers, registers, hard disk, removable disks, CD-ROM, or any other form of storage medium known in the art. An example storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor.

[0053] In the foregoing specification, example embodiments have been described with reference to specific examples thereof. However, it will be evident that various modifications and changes can be made to the specification without departing from the broader scope of the disclosure as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

1. An apparatus comprising: a plurality of heterogeneous logic blocks, each of the heterogeneous logic blocks comprising a same configuration of programmable logic blocks; and a platform management controller coupled into each of the heterogeneous logic blocks and configured to: receive configuration data for a design core and a configuration data offset value; implement the design core in a first heterogeneous logic block of the plurality of heterogeneous logic blocks using the configuration data; and implement the design core in a second heterogeneous logic block of the plurality of heterogeneous logic blocks using the configuration data and the configuration data offset value. an on-chip packetized data communication interface configured to transmit and receive data.

3. The apparatus of claim 1, wherein the design core implemented in the second heterogeneous logic block reuses at least one of placement, routing, or timing information of the design core implemented in the first heterogeneous logic block.

2. The device of claim 1, wherein the first and second heterogeneous logic blocks further comprise:

4. The apparatus of claim 1, wherein the configuration data comprises a first portion for configuring the first heterogeneous logic block and a second portion for configuring the second heterogeneous logic block.

5. The apparatus of claim 4, wherein the first portion of the configuration data comprises a first identifier for identifying the first heterogeneous logic block and the second portion of the configuration data comprises a second identifier for identifying the second heterogeneous logic block.

6. The apparatus of claim 1, wherein the design core spans two or more of the plurality of heterogeneous logic blocks.

7. A system comprising: a processing device configured to generate first configuration data; and a first programmable logic device comprising: a plurality of heterogeneous logic blocks, each of the heterogeneous logic blocks comprising a same configuration of programmable logic blocks; and a platform management controller coupled into each of the heterogeneous logic blocks and configured to: receive the first configuration data for a design core and a configuration data offset value; implement the design core in a first heterogeneous logic block of the plurality of heterogeneous logic blocks using the first configuration data; and implement the design core in a second heterogeneous logic block of the plurality of heterogeneous logic blocks using the first configuration data and the configuration data offset value.

8. The system of claim 7, wherein the first and second heterogeneous logic blocks further comprise an on-chip packetized data communication interface configured to transmit and receive data.

9. The system of claim 7, wherein the design core implemented in the second heterogeneous logic block reuses at least one of placement, routing, or timing information of the design core implemented in the first heterogeneous logic block.

10. The system of claim 7, wherein the first configuration data comprises a first portion for configuring the first heterogeneous logic block and a second portion for configuring the second heterogeneous logic block. ​ ​ ​ 11. The system of claim 10, wherein the first portion of the first configuration data includes a first identifier to identify the first heterogeneous logic block and the second portion of the first configuration data includes a second identifier to identify the second heterogeneous logic block.

12. The system of claim 7, wherein the design core spans two or more of the plurality of heterogeneous logic blocks.

13. The system of claim 7, further comprising: a second programmable logic device comprising: a plurality of heterogeneous logic blocks that are the same as the heterogeneous logic blocks of the first programmable logic device; and a second platform management controller coupled to each of the heterogeneous logic blocks of the second programmable logic device, the second platform management controller configured to implement the design core in a third heterogeneous logic block using second configuration data.

14. A method comprising: generating a first bitstream comprising first configuration data to implement a first design in a first heterogeneous logic block of a programmable logic device, wherein the first bitstream includes a first identifier to associate the first configuration data with the first heterogeneous logic block; and generating a second bitstream comprising the first configuration data to implement the first design in a second heterogeneous logic block of the programmable logic device, wherein the second bitstream includes a second identifier to associate the first configuration data with the second heterogeneous logic block, wherein the first heterogeneous logic block and the second heterogeneous logic block each include a same configuration of programmable logic blocks.

15. The method of claim 14, wherein the first configuration data includes a design core to configure at least a portion of the first heterogeneous logic block and a portion of the second heterogeneous logic block to implement a function. ​

Images