Model-Based Design and Partitioning for Heterogeneous Integrated Circuits

Abstract

Model-based implementation of a design for heterogeneous integrated circuits can include converting a model created as a data structure using a modeling system into a data flow graph, where the model represents a design for implementation in an integrated circuit having multiple systems, where the systems are heterogeneous; classifying nodes of the data flow graph for implementation in different ones of the multiple systems of the integrated circuit; and partitioning the data flow graph into multiple subgraphs based on the classification, where each subgraph corresponds to a different one of the multiple systems. From each subgraph, a portion of high-level language (HLL) program code can be generated. Each portion of the HLL program code can be specific to the system corresponding to the subgraph from which the portion of the HLL program code was generated.

Description

[Technical Field]

[0001] Reservation of Rights for Copyrighted Material A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

[0002] The present disclosure relates to integrated circuits (ICs), and more particularly to model-based design and partitioning for heterogeneous ICs. [Background technology]

[0003] ICs can be implemented to perform a variety of functions. Some ICs can be programmed to perform specified functions. One example of a programmable IC is a field programmable gate array (FPGA). FPGAs generally include an array of programmable tiles. Programmable tiles are collectively referred to as programmable logic. Examples of programmable tiles may include, but are not limited to, input / output blocks (IOBs), configurable logic blocks (CLBs), dedicated random access memory blocks (BRAMs), multipliers, digital signal processing blocks (DSPs), clock managers, delay locked loops (DLLs), etc.

[0004] A computer-based modeling environment is available in which a user can create a model of an electronic system. The user creates the model by inserting model blocks into the design environment using a graphical drag-and-drop paradigm. The user connects the model blocks to define data flow between them. The modeling environment can process the model to generate a register transfer level (RTL) representation of the model, which can be further processed for implementation in the programmable logic of an IC.

[0005] However, modern ICs have evolved to include multiple different types of systems on the same chip. These multiple different systems may include programmable logic, hardwired processors, etc. However, available modeling environments are limited to creating models that target programmable logic. Available modeling environments lack mechanisms for addressing other types of systems available on modern ICs. Summary of the Invention

[0006] In one aspect, a method can include converting a model created as a data structure using a modeling system into a data flow graph. The model represents a design for implementation in an IC having multiple systems, where the systems are heterogeneous. The method can include classifying nodes of the data flow graph for implementation in different ones of the multiple systems of the IC and partitioning the data flow graph into multiple subgraphs based on the classification. Each subgraph corresponds to a different one of the multiple systems. The method can also include generating a high-level language (HLL) program code portion from each subgraph. Each HLL program code portion is specific to the system corresponding to the subgraph from which the HLL program code portion was generated.

[0007] In another aspect, a system includes a processor configured to initiate operations. The operations can include converting a model created as a data structure using a modeling system into a data flow graph. The model represents a design for implementation in an IC having multiple systems, the systems being heterogeneous. The operations can include classifying nodes of the data flow graph for implementation in different ones of the multiple systems of the IC and partitioning the data flow graph into multiple subgraphs based on the classification. Each subgraph corresponds to a different one of the multiple systems. The operations can also include generating, from each subgraph, a portion of HLL program code that is specific to the system corresponding to the subgraph from which the HLL program code portion was generated.

[0008] In another aspect, a computer program product includes one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media. The program instructions are executable by computer hardware to initiate operations. The operations can include converting a model created as a data structure using a modeling system into a data flow graph. The model represents a design for implementation in an IC having multiple systems, the systems being heterogeneous. The operations can include classifying nodes of the data flow graph for implementation in different ones of the multiple systems of the IC and partitioning the data flow graph into multiple subgraphs based on the classification. Each subgraph corresponds to a different one of the multiple systems. The operations can also include generating, from each subgraph, a portion of HLL program code that is specific to the system corresponding to the subgraph from which the HLL program code portion was generated.

[0009] This summary section is provided merely to introduce some concepts, and is not intended to identify key or essential features of the claimed subject matter. Other features of the inventive arrangement will be apparent from the accompanying drawings and the detailed description that follows.

[0010] Configurations of the present invention are illustrated by way of example in the accompanying drawings. However, the drawings should not be construed as limiting the configuration of the present invention to only the particular implementations shown. Various aspects and advantages will become apparent upon review of the following detailed description and by reference to the drawings. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 illustrates an exemplary IC having multiple heterogeneous systems. [Figure 2] FIG. 1 illustrates an exemplary model created using the modeling system. [Figure 3] FIG. 1 illustrates an example of a data flow graph generated by the modeling system. [Figure 4] FIG. 2 illustrates an example of a subgraph corresponding to programmable logic of a target IC. [Figure 5] FIG. 2 illustrates an example of a subgraph corresponding to a processor system of a target IC. [Figure 6] FIG. 2 illustrates an example of a subgraph corresponding to a data processing engine array of a target IC. [Figure 7] FIG. 10 illustrates the generation of configuration data for a target IC from a subgraph. [Figure 8] FIG. 1 illustrates an exemplary method for implementing a model in a target IC having multiple heterogeneous systems. [Figure 9] FIG. 1 illustrates an example of a computer that can be used to execute a modeling environment including the model-based design tools described within this disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0012] While this disclosure concludes with claims defining novel features, it is believed that the various features described within this disclosure will be better understood by considering the description in conjunction with the drawings. The process(es), machine(s), product(s), and any variations thereof described herein are provided for illustrative purposes. The specific structural and functional details described within 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 variously the described features in nearly all appropriately detailed structures. Furthermore, the terms and phrases used within this disclosure are not limiting, but rather provide an understandable description of the described features.

[0013] The present disclosure relates to ICs, and more particularly to model-based design and partitioning for heterogeneous ICs. A heterogeneous IC refers to an IC that includes multiple different, or disparate, systems. In accordance with the inventive configurations described within this disclosure, systems, methods, and computer program products are provided that are capable of creating a model for an electronic system and implementing the model in an IC having multiple heterogeneous systems.

[0014] Generally, a modeling system refers to a computer-based modeling environment in which a user can create a model of an electronic system. The modeling system may include a model-based design tool that executes in cooperation with the modeling environment. The model-based design tool augments the functionality of the modeling environment so that the model can be realized in a specific IC, called a "target IC." A user can insert model blocks into the design environment provided by the modeling system. The model blocks can be inserted using a graphical drag-and-drop paradigm. The model blocks represent specific functions or behaviors that will ultimately be implemented by circuits in the target IC. A user can also connect the model blocks in the design environment to establish signal and / or data flow between the model blocks.

[0015] An example of a modeling environment is MATLAB used in combination with SIMULINK. Both MATLAB and SIMULINK are available from Mathworks, Inc. of Natick, Massachusetts. Such modeling environments can run additional applications as part of the modeling environment. For example, the modeling environment may run an application such as Model Composer, available from Xilinx, Inc. of San Jose, California. Model Composer is an example of a model-based design tool that facilitates the design and exploration of models intended for implementation in an IC. Using a model-based design tool, for example, a user has access to a library of model blocks corresponding to different cores or circuits that may be implemented in an IC.

[0016] According to the inventive configurations described within this disclosure, a modeling system may be used to create a model, where the model is intended for implementation in an IC having multiple heterogeneous systems. These different systems may include programmable logic as one of the systems. Furthermore, the different systems may operate in cooperation with one another. For purposes of illustration, examples of different systems that may be available in an IC may include, but are not limited to, programmable logic, a data processing engine (DPE) array, and / or a processor system. The processor system may include one or more hardwired processors. The hardwired processors may be dissimilar. One, more, or all of the systems of an IC may be interconnected by an on-chip interconnect. In one aspect, the different systems may be interconnected by an additional system called a network-on-chip (NoC). These systems may be included in an IC in varying combinations.

[0017] Typically, to program an IC with multiple heterogeneous systems, a developer or system designer must acquire knowledge and skills in different areas, such as hardware programming, software development, architecture exploration, and system partitioning. Software developers generally lack the training in these different areas necessary to implement models in an IC with multiple heterogeneous systems. Similarly, domain-specific application engineers, algorithm developers, and system designers may have little or no expertise in software development, hardware programming, and / or partitioning models for implementation in an IC with multiple heterogeneous systems. Furthermore, available modeling systems are limited to implementing models in homogeneous ICs. For example, available modeling systems are limited to implementing models in the programmable logic of an FPGA.

[0018] Disclosed within this disclosure are exemplary implementations of a modeling system having functionality that extends beyond creating models for implementation in programmable logic. In accordance with the inventive configurations described within this disclosure, systems, methods, and computer program products are provided that extend the functionality of a modeling system to create and implement models within modern ICs, including a variety of different types of systems.

[0019] In one or more exemplary implementations, systems, methods, and computer program products are provided that are capable of performing operations such as partitioning a model into different portions, each corresponding to a different system of a target IC. The model can be executed and simulated to verify functional correctness, verify design rule checks, verify port interface connections between various model blocks and / or target systems in the target IC, and verify the configuration of model blocks with respect to target hardware in the target IC. The inventive arrangements provide a modeling system that allows a user to explore different design solutions and / or algorithms, simulate the model, verify the functional correctness of the model, different portions of the model corresponding to different systems of the target IC, and / or observe the dynamic behavior of the model or portions of the model during simulation. These operations can be performed across different systems available in the IC.

[0020] Further aspects of the inventive arrangement are described in more detail below with reference to the figures. For simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Furthermore, where considered appropriate, reference numerals have been repeated among the figures to indicate corresponding, similar, or like features.

[0021] FIG. 1 illustrates an exemplary IC 100 having multiple heterogeneous systems. The IC 100 is an example of a programmable IC and adaptive system. In one aspect, the IC 100 is also an example of a system-on-chip (SoC). In the example of FIG. 1, the IC 100 is implemented on a single die provided in a single integrated package. In other examples, the IC 100 may be implemented using multiple interconnected dies, with the various programmable circuit resources shown in FIG. 1 being implemented across different interconnected dies.

[0022] As described above, IC 100 includes multiple heterogeneous systems. The systems include data processing engine (DPE) array 102, programmable logic 104, processor system 106, and network-on-chip (NoC) 108. IC 100 may also include one or more other systems, such as platform management controller (PMC) 110 and one or more hardwired circuit blocks 112.

[0023] The DPE array 102 is implemented as multiple interconnected programmable DPEs 116. The DPEs 116 may be arranged in an array and are hardwired. Each DPE 116 may include one or more cores 118 and a memory module 120 (abbreviated as "MM" in FIG. 1). In one aspect, each core 118 is capable of executing program code stored in a core-specific program memory contained within each respective core (not shown). Each core 118 can directly access the memory module 120 within the same DPE 116 and the memory module 120 of any other DPE 116 adjacent to the core 118 of the DPE 116 in the above, below, left, and right directions. For example, core 118-5 can directly read and / or write memory modules 120-5, 120-8, 120-6, and 120-2 (e.g., via respective memory interfaces not shown). Core 118-5 views each of memory modules 120-5, 120-8, 120-6, and 120-2 as a unified region of memory (e.g., as a portion of local memory accessible to core 118-5). This facilitates data sharing between different DPEs 116 in DPE array 102. In other examples, core 118-5 may be directly connected to memory modules 120 in other DPEs.

[0024] The DPEs 116 are interconnected by programmable DPE interconnect circuitry. The programmable DPE interconnect circuitry may include one or more different and independent networks. For example, the programmable DPE interconnect circuitry may include a streaming network ( White arrows) and the memory-mapped network formed from memory-mapped connections ( Black paint and arrows).

[0025] In one or more example implementations, some connections between circuit components described herein may be implemented using hardware and / or circuit elements conforming to the Advanced Microcontroller Bus Architecture (AMBA) eXtensible Interface (AXI) (hereinafter, “AXI”) protocol. AXI defines an embedded microcontroller bus interface for use in establishing on-chip connections between compliant circuit blocks and / or systems. The connections may be streaming (e.g., AXI-S) connections, memory-mapped (AXI-MM) connections, or control connections and / or interfaces (AXI-L). AXI is provided as an illustrative example of a bus interface that may be used to establish on-chip connections and is not intended as a limitation of the examples described within this disclosure. It should be appreciated that other similar and / or equivalent protocols, communication buses, bus interfaces, and / or interconnects may be used in place of AXI, and that the various example circuit blocks and / or signals provided within this disclosure will vary based on the particular protocol, communication bus, bus interface, and / or interconnect used.

[0026] Loading configuration data into the control registers of the DPEs 116 through memory-mapped connections allows each DPE 116 and its components to be controlled independently. The DPEs 116 can be enabled / disabled on a per-DPE basis. For example, each core 118 can be configured to access only the illustrated memory module 120 or a subset of the memory modules 120 to achieve isolation of one or more cores 118 operating as a cluster. Each streaming connection can be configured to establish logical connections between only selected ones of the DPEs 116 to achieve isolation of one or more DPEs 116 operating as a cluster. Because each core 118 can be loaded with program code specific to that core 118, each DPE 116 can implement one or more different kernels therein.

[0027] In other aspects, the programmable DPE interconnect circuit elements in the DPE array 102 may include additional independent networks, such as a debug network that is independent of (e.g., separate and distinct from) the streaming and memory-mapped connections, and / or an event broadcast network. In some aspects, the debug network is formed from and / or is part of the memory-mapped connections.

[0028] The cores 118 may be directly connected to adjacent cores 118 via core-to-core cascade connections. In one aspect, the inter-core cascade connections are unidirectional and direct connections between the cores 118 as depicted. In another aspect, the inter-core cascade connections are bidirectional and direct connections between the cores 118. In general, the inter-core cascade connections generally allow results stored in the accumulation registers of a source core to be provided directly to the inputs of a target or load core. Activation of the inter-core cascade interface may also be controlled by loading configuration data into the control registers of each DPE 116.

[0029] In one exemplary implementation, the DPE 116 does not include a cache memory. By omitting a cache memory, the DPE array 102 is able to achieve predictable, e.g., deterministic, performance. Furthermore, because coherency is not required to be maintained between cache memories located in different DPEs 116, significant processing overhead is avoided. In a further example, the cores 118 do not have incoming interrupts. Thus, the cores 118 are able to operate without interrupts. Omitting incoming interrupts to the cores 118 also enables the DPE array 102 to achieve predictable, e.g., deterministic, performance.

[0030] The SoC interface block 122 acts as an interface connecting the DPE 116 to other resources of the IC 100. In the example of FIG. 1, the SoC interface block 122 includes multiple interconnected tiles 124 organized in a row. In particular embodiments, different architectures may be used to implement the tiles 124 within the SoC interface block 122, with each different tile architecture supporting communication with a different resource of the IC 100. The tiles 124 are connected such that data can be propagated bidirectionally from one tile to another. Each tile 124 can act as an interface for the row of DPEs 116 immediately above it.

[0031] The tiles 124 are connected to adjacent tiles, the DPE 116 immediately above, and the circuit elements below using streaming and memory-mapped connections as shown. The tiles 124 may also include a debug network that connects to a debug network implemented in the DPE array 102. Each tile 124 can receive data from another source, such as the processor system 106, the programmable logic 104, and / or another hardwired circuit block 112. For example, tile 124-1 can provide a portion of data, whether application or configuration, destined for the DPE 116 above in its row to such DPE 116, while sending data destined for DPEs 116 in other rows onto other tiles 124, e.g., 124-2 or 124-3, so that such tiles 124 can route data destined for DPEs 116 in their respective rows of DPEs accordingly.

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

[0033] Programmable logic 104 is circuitry that can be programmed to perform a specified function. As an example, programmable logic 104 may be implemented as a field programmable gate array type of circuitry. Programmable logic 104 may include an array of programmable circuit blocks. As defined herein, the term "programmable logic" refers to circuitry used to create reconfigurable digital circuits. Programmable logic is formed from many programmable circuit blocks, sometimes called "tiles," that provide basic functionality. Unlike hardwired circuitry, the topology of programmable logic 104 is highly configurable. Each programmable circuit block of programmable logic 104 generally includes programmable elements 126 (e.g., functional elements) and programmable interconnect 142. The programmable interconnect 142 provides the highly configurable topology of programmable logic 104. The programmable interconnect 142 may be configurable on a wire-by-wire basis to provide connectivity between programmable elements 126 of the programmable circuit blocks of the programmable logic 104, unlike connectivity between, for example, DPEs 116, which is configurable on a bit-by-bit basis (e.g., each wire carries a single bit of information).

[0034] Examples of programmable circuit blocks in programmable logic 104 include CLBs with lookup tables and registers. Unlike hardwired circuit elements, described below and sometimes referred to as hard blocks, these programmable circuit blocks have undefined functions at the time of manufacture. Programmable logic 104 may include other types of programmable circuit blocks that provide basic and defined functionality along with more limited programmability. Examples of these circuit blocks may include DPSs, phase-locked loops (PLLs), and BRAMs. These types of programmable circuit blocks, like others in programmable logic 104, are numerous and intermingled with other programmable circuit blocks in programmable logic 104. These circuit blocks may also generally have an architecture that includes programmable interconnects 142 and programmable elements 126 and are therefore part of the highly configurable topology of programmable logic 104.

[0035] Prior to use, the programmable logic 104, e.g., the programmable interconnects and programmable elements, must be programmed or "configured" by loading data, called a configuration bitstream, into internal configuration memory cells therein. Once the configuration bitstream is loaded, the configuration memory cells define how the programmable logic 104 is configured, e.g., its topology, and how it operates (e.g., the particular function it performs). The programmable logic 104 may have multiple connection points to the NoC 108.

[0036] The processor system 106 is implemented as hardwired circuit elements fabricated as part of the IC 100. The processor system 106 may be implemented as or include any of a variety of different processor types, each capable of executing program code. For example, the processor system 106 may be implemented as individual processors, e.g., single cores, capable of executing program code. In another example, the processor system 106 may be implemented as a multi-core processor. In yet another example, the processor system 106 may include one or more processors, modules, coprocessors, I / O interfaces, and / or other resources. The processor system 106 may be implemented using any of a variety of different types of architectures. Exemplary architectures that may be used to implement the processor system 106 may include, but are not limited to, an ARM processor architecture, an x86 processor architecture, a graphics processing unit (GPU) architecture, a mobile processor architecture, a DSP architecture, a combination of the above architectures, or any other suitable architecture capable of executing computer-readable instructions or program code. The processor system 106 may have multiple connection points to the NoC 108.

[0037] In one exemplary implementation, processor system 106 may be implemented as or include any of a variety of different processor types, each capable of executing program code. The processors may have different architectures and / or instruction sets. In one exemplary implementation, processor system 106 may include various processors, such as one or more real-time processing units (RPUs), one or more application processing units (APUs), and / or one or more GPUs, each capable of executing program code. Processor system 106 may also include various support circuits. Examples of support circuits may include, but are not limited to, on-chip memory (OCM), transceivers, peripherals, interconnects, direct memory access circuit(s), memory controllers, and / or multiplexed input / output circuits that couple to other systems of IC 100. Within processor system 106, the processors and support circuits may be interconnected by interconnects.

[0038] The NoC 108 is a programmable interconnect network for sharing data among endpoint circuits in the IC 100. The endpoint circuits may be disposed in the DPE array 102, the programmable logic 104, the processor system 106, and / or selected hardwired circuit blocks 112. The NoC 108 may include high-speed data paths with dedicated switching. In one example, the NoC 108 includes one or more horizontal paths, one or more vertical paths, or both horizontal and vertical paths. The configuration and number of regions shown in FIG. 1 are exemplary only. The NoC 108 is an example of a common infrastructure available within the IC 100 to connect selected components and / or subsystems.

[0039] Within the NoC 108, the nets to be routed through the NoC 108 are not known until a user circuit design is created for implementation within the IC 100. The NoC 108 can be programmed by loading configuration data into internal configuration registers, which define how elements within the NoC 108, such as switches and interfaces, are configured and operate to pass data from switch to switch and between NoC interfaces to connect endpoint circuits. The NoC 108 is fabricated as part of the IC 100 (e.g., is hardwired) and is not physically modifiable, but can be programmed to establish connectivity between different master and slave circuits of the user circuit design. The NoC 108 may not have data paths or routes implemented within it at power-on. However, once configured by the PMC 110, the NoC 108 may implement data paths or routes between endpoint circuits.

[0040] The PMC 110 is responsible for managing the IC 100. The PMC 110 is a system within the IC 100 that can manage other programmable circuit resources throughout the IC 100. The PMC 110 can maintain a safe and secure environment, boot the IC 100, and manage the IC 100 during normal operation. For example, the PMC 110 can provide unified and programmable control over power-on, boot / configuration, security, power management, safety monitoring, debugging, and / or error handling for the different programmable circuit resources of the IC 100 (e.g., the DPE array 102, the programmable logic 104, the processor system 106, and the NoC 108). The PMC 110 acts as a dedicated platform manager that isolates the processor system 106 from the programmable logic 104. Thus, the processor system 106 and the programmable logic 104 can be managed, configured, and / or powered up and / or down independently of each other.

[0041] In one aspect, PMC 110 can act as a root-of-trust for the entire IC 100. As an example, PMC 110 can be responsible for authenticating and / or validating device images containing configuration data for any of IC 100's programmable resources that may be loaded therein. PMC 110 can further protect IC 100 from tampering during operation. By operating as a root-of-trust for IC 100, PMC 110 can monitor the operation of programmable logic 104, processor system 106, and / or any other programmable circuit resources that may be included in IC 100. The root-of-trust capabilities performed by PMC 110 are separate and distinct from processor system 106 and programmable logic 104, and / or operations performed by processor system 106 and / or programmable logic 104.

[0042] Hardwired circuit blocks 112 include dedicated circuit blocks fabricated as part of IC 100. While hardwired, hardwired circuit blocks 112 can be configured to implement one or more different operating modes by loading configuration data into control registers. Examples of hardwired circuit blocks 112 may include input / output (I / O) blocks, transceivers for sending and receiving signals to circuits and / or systems external to IC 100, memory controllers, etc. Examples of different I / O blocks may include single-ended and pseudo-differential I / O. An example of a transceiver may include a high-speed differentially clocked transceiver. Other examples of hardwired circuit blocks 112 include, but are not limited to, an encryption engine, a digital-to-analog converter (DAC), an analog-to-digital converter (ADC), etc. Generally, hardwired circuit blocks 112 are application-specific circuit blocks.

[0043] 1 may be initially programmed as part of the boot process for IC 100. During runtime, the programmable circuit resources may be reconfigured. In one aspect, PMC 110 may initially configure DPE array 102, programmable logic 104, processor system 106, and NoC 108. At any point during runtime, PMC 110 may reconfigure all or a portion of IC 100. In some cases, processor system 106, once initially configured by PMC 110, may configure and / or reconfigure programmable logic 104 and / or NoC 108.

[0044] 2 shows an example model 200 created using a modeling system. Within this disclosure, the term "modeling system" refers to a computer or other data processing system configured to run a modeling environment and model-based design tools. One example of a computer and / or data processing system that can be used as a modeling system is described with respect to FIG. 9.

[0045] The model-based design tool of the modeling system provides high-level design abstractions as model block libraries for the target IC. Each model block may have a corresponding built-in HLL software model that is executable. The HLL software model of a model block may be specified in C and / or C++ program code, as MATLAB scripts, or other high-level program code and / or scripts. Thus, models implemented as data structures may be constructed from the model blocks. The models are executable within the modeling environment to accelerate simulation and ensure functionally correct, bit-accurate simulation results for the hardware generated from the model.

[0046] Model 200 includes multiple model blocks. Connections between the model blocks are shown as arrows. The connections represent data flow or signals exchanged between the model blocks. A user can create model 200 within a graphical programming environment provided by the modeling system using a drag-and-drop paradigm, which differs from other techniques for creating circuit designs in which users must write structured, complex program code in a text-based language.

[0047] Model 200 may be executed by a modeling system that allows model 200 to be interactively simulated. Results from the simulation may be viewed on the scope and graphical display of the modeling system to verify the functional correctness and dynamic behavior of any hardware generated from model 200 at an early stage of development (e.g., prior to the generation of such hardware). Through simulation, model 200 may be refined to ensure that any hardware generated from model 200 will meet established design specifications. Furthermore, simulation of model 200 facilitates design rule checking, verification of port interface connections, and verification of block configurations with target hardware.

[0048] For purposes of explanation, model 200 represents an electronic system that would be implemented in an IC having multiple heterogeneous systems. An example of such an IC is IC 100 of Figure 1. Thus, by way of example, different model blocks of model 200 may be implemented in DPE array 102, programmable logic 104, and / or processor system 106.

[0049] FIG. 3 shows an exemplary dataflow graph 300 generated by a modeling system. Dataflow graph 300 may be implemented as a data structure. For example, the modeling system can convert a model of an electronic system, such as model 200 of FIG. 2, into a dataflow graph such as dataflow graph 300 of FIG. 3. In one aspect, each model block of the model corresponds to one or more nodes in dataflow graph 300. Model connections are represented as directed edges in dataflow graph 300.

[0050] In one aspect, a modeling system generates a dataflow graph by first creating an initial dataflow graph that represents the model node-by-node for the nodes. The modeling system can transform and / or optimize the initial dataflow graph in various manners. In one exemplary implementation, the modeling system can sort or order the nodes of the initial dataflow graph based on node dependencies. Based on the sorted nodes, the modeling system can generate an intermediate dataflow graph representation for further processing and optimization.

[0051] The modeling system may also classify the nodes of the dataflow graph into different groups, with each group corresponding to one of the systems of the target IC. The classification may be performed on the intermediate dataflow graph. In one aspect, as part of the classification, the modeling system may automatically label each node for implementation in a specific system of the target IC. In the example of FIG. 3, the nodes of the dataflow graph 300 have different shapes (e.g., labels) that correspond to different systems of the target IC. Each different shape corresponds to a specific system of the target IC.

[0052] For example, rectangular shaped nodes represent functions that are implemented in software and that are to be executed by one or more of the processors of processor system 106. Each rectangular shaped node represents one or more nodes from the model that perform control or processor-specific operations that may be implemented in software.

[0053] The oval-shaped nodes represent functions to be implemented in programmable logic 104. Each oval-shaped node represents one or more nodes from a model that represent computationally intensive or accelerated operations to be implemented using programmable logic 104. The pentagon-shaped nodes represent functions to be implemented by a DPE in DPE array 102. For example, each pentagon-shaped node may be implemented in program code executed by a core of a particular DPE in DPE array 102. Each pentagon-shaped node represents one or more nodes from a model.

[0054] In one aspect, the modeling system is capable of automatically classifying nodes of a dataflow graph based on one or more attributes of the particular model block(s) from which each node of the dataflow graph is derived. Examples of attributes used by the modeling system to classify nodes of a dataflow graph may include, but are not limited to, functionality, connectivity, implementation characteristics, portability, power constraints, application context, or other hardware requirements. Some nodes may also have an attribute that designates the node as a control node.

[0055] For purposes of explanation, consider a node in a dataflow graph that represents a filter model block from a model. As part of the design process in a modeling system, the filter model block may have one or more attributes assigned to it that specify any of various operational parameters and / or requirements for the model block. Examples of attributes may include, but are not limited to, a desired operational or clock frequency, a desired data throughput for the model block, a power constraint (e.g., defining a maximum power consumption limit), etc. The attributes of the model block may be carried over and assigned to the node in the dataflow graph that represents the model block. In some cases, attributes are assigned to individual model blocks, and in other cases, attributes are assigned to an entire subsystem of the model, e.g., a group of two or more model blocks.

[0056] The modeling system can store in memory one or more system preferences that specify how model blocks and / or subsystems of the model should be implemented. By performing a comparison of attribute(s) of the model block(s) and / or subsystem(s) with the corresponding system preferences, the modeling system can automatically classify nodes of the data flow graph. That is, the modeling system can create nodes of the data flow graph from one or more model blocks of the model and classify the nodes based on attributes of the model block(s) represented by the nodes.

[0057] Consider an example in which a modeling system stores a system preference that defines a clock frequency threshold as 500 MHz for a filter model block. The modeling system can compare a clock frequency attribute that specifies a desired clock frequency for the model block in the model with the system preference for the filter model block. In response to determining that the clock frequency attribute of the model block is less than or equal to the system preference, the modeling system can classify a node of the data flow graph representing the filter model block as intended for implementation in programmable logic. In response to determining that the clock frequency attribute of the model block is greater than the system preference, the modeling system can classify a node of the data flow graph representing the filter model block as intended for implementation in a DPE array.

[0058] The modeling system can perform similar analyses with respect to other system preferences and other attributes of nodes carried over from the underlying model block(s), related to power, data throughput, etc. For example, for a model block that can be implemented in either programmable logic or a DPE array, corresponding nodes in the dataflow graph that have a data throughput attribute greater than the relevant system preference can be classified as nodes to be implemented in the DPE array, and nodes that have a data throughput attribute less than or equal to the relevant system preference can be classified as nodes to be implemented in the programmable logic. Similarly, for a model block that can be implemented in either programmable logic or a DPE array, corresponding nodes that have a power consumption attribute (e.g., a power constraint) greater than the relevant system preference can be classified as nodes to be implemented in the DPE array, and nodes that have a power consumption attribute less than or equal to the relevant system preference can be classified as nodes to be implemented in the programmable logic.

[0059] Generally, DPE arrays are capable of achieving higher data throughput, higher operating frequencies, and lower power consumption than programmable logic. These properties of DPE arrays and programmable logic can be used by the modeling system when performing classification of nodes in a dataflow graph.

[0060] In another example, nodes representing some model blocks may be classified by the modeling system in a predetermined manner for implementation in a processing system, programmable logic, or DPE array. For example, a node may represent a model block with a "control" attribute. The node may be automatically classified as a node intended for implementation in a processor system.

[0061] Although different examples are described in which the modeling system automatically classifies nodes of a dataflow graph, in other exemplary implementations, a user may manually specify the particular system in which a given model block will be implemented. In that case, any such manual instructions may override any automatic decisions made by the modeling system. The modeling system may classify the nodes in a manner consistent with the manually specified instructions.

[0062] 4-6 illustrate an example of partitioning a dataflow graph into multiple subgraphs. Each of FIGS. 4-6 illustrates an example subgraph generated from the example dataflow graph of FIG. 3. Each of the subgraphs illustrated in FIGS. 4-6 corresponds to a different one of the systems of the target IC. For example, the modeling system may cluster the nodes of a given dataflow graph S (e.g., dataflow graph 300) into subgraphs S1, S2, and S3 based on the classification of nodes and open edges implemented to maintain functional characteristics and interconnections between nodes. The modeling system may generate one subgraph for each different system of the target IC represented in the dataflow graph.

[0063] 4 illustrates an exemplary subgraph 400. The subgraph 400 includes each of the nodes classified as intended for implementation in programmable logic. When creating the subgraph 400, connectivity between the nodes included in the subgraph is preserved. For nodes in the subgraph 400 that connect to nodes not included in the subgraph 400, such nodes are connected to ports of the subgraph 400. For example, node N18 is connected to ports E17-18. Node N20 is connected to ports E19-20 and E20-21.

[0064] 5 illustrates an exemplary subgraph 500. The subgraph 500 includes each of the nodes classified as intended for implementation in a processor system. When creating the subgraph 500, connectivity between the nodes included in the subgraph is preserved. For nodes in the subgraph 500 that connect to nodes not included in the subgraph 500, such nodes are connected to one or more ports of the subgraph 500. For example, node N5 is connected to port N6, which in turn is connected to ports E1-5, E2-5, and E3-5 to maintain connectivity with nodes N1, N2, and N3 in other subgraphs.

[0065] 6 illustrates an exemplary subgraph 600. Subgraph 600 includes each of the nodes classified as intended for implementation in a DPE array. In creating subgraph 600, connectivity between the nodes included in the subgraph is preserved. For nodes in subgraph 600 that connect to nodes not included in subgraph 600, such nodes are connected to port(s) of subgraph 400. For example, node N14 is connected to nodes N15 and N16, and is connected to port E13-14 to maintain connectivity with node N13 in another subgraph. Node N21 is connected to port E20-21 to maintain connectivity with node N20 in another subgraph.

[0066] In one aspect, each of the resulting subgraphs 400, 500, and 600 can be independently processed and optimized to generate different components of a heterogeneous system. When interconnected, each subgraph and resulting hardware implementation still represents the functional characteristics and implementation details of the original model. Thus, the specific output product of individual nodes, and therefore the target hardware (e.g., the system of the target IC), can change dynamically based on the classification and partitioning performed on the dataflow graph.

[0067] Once the sub-graph is generated, various hardware implementation tools may be used to generate the configuration data needed to implement the model within the target IC. The hardware implementation tools may include, for example, hardware and software compilers, various libraries (e.g., DPE array libraries and / or IP libraries for programmable logic), linkers, etc.

[0068] In one aspect, the modeling system can process each of the different subgraphs to generate HLL program code (e.g., source code). For example, referring to subgraph 400, which corresponds to a portion of the model to be implemented in programmable logic, the modeling system can generate, from subgraph 400, HLL program code that is hardware synthesizable. Hardware synthesizable program code refers to syntactically correct HLL program code that can be processed by hardware implementation tools capable of performing high-level synthesis. Hardware synthesizable program code can be specified as source code in an HLL, such as C, C++, or other alternative HLL.

[0069] In one aspect, the modeling system converts subgraph 400 into an abstract syntax tree (AST) as an intermediate representation. The modeling system is capable of generating hardware synthesizable program code by performing operations such as creating an AST that is functionally equivalent to subgraph 400. In doing so, the modeling system traverses or examines each node of the subgraph in dependency order and applies HLL constructs, such as types, expressions, statements, symbols, declarations, and directives, to the AST. The modeling system is also capable of processing and optimizing the AST by adding hardware directives, enabling parallel programming, and performing other known optimizations that result in improved data throughput for hardware implemented in programmable logic. The modeling system may also perform other operations to generate hardware synthesizable program code that conforms to known standards used by high-level synthesis tools to ensure high-quality results. From the resulting AST, the modeling system generates hardware synthesizable program code.

[0070] Referring to subgraph 500 corresponding to the portion of the model to be implemented in a processor system, the modeling system can generate program code from subgraph 500 that is compatible and executable by one or more of the various processors included in the processor system. The program code may be specified in an HLL, such as C, C++, or another HLL, as source code. The modeling system can create an AST that is functionally equivalent to subgraph 500. The modeling system may do so by traversing, e.g., examining, each node in the subgraph in dependency order using AST constructs such as types, expressions, statements, and declarations. The modeling system can also modify the AST to meet the memory requirements, performance, and efficiency of the target processor of the processor system. The modeling system can generate an HLL targeted to the specific processor of the processor system of the target IC on which the program code will execute.

[0071] Referring to subgraph 600 corresponding to the portion of the model to be implemented in the DPE array, the modeling system can generate HLL source code from subgraph 600 that defines or specifies a further dataflow graph. The further dataflow graph is referred to herein as a "DPE array graph." In one aspect, the HLL used to specify the DPE array graph may include a markup language suitable for implementing the dataflow graph. The DPE array graph is a dataflow graph that targets the DPE array and thus may be mapped onto the DPE array of the target IC. That is, the DPE array graph has nodes corresponding to kernels that may be mapped to particular cores of DPEs in the DPE array, with edges that map onto the DPE's memory and / or the DPE's data channels (e.g., streaming interconnect). The kernels may be from a library of program code optimized for execution by the cores of the DPE or user-specified program code.

[0072] For example, the modeling system can convert each node in a subgraph, representing a self-contained DPE library kernel, an imported (e.g., user-specified) kernel, or a further subgraph, into a computational node in the DPE array graph. The computational node maps onto a specific DPE (e.g., a core of the DPE). The modeling system can further classify each edge in the subgraph as a window connection, a streaming connection, a cascade connection, or a real-time parameter interface based on the functionality of the edge and any user-specified attributes for the node. A "window connection" refers to a connection that conveys a fixed or predeterministic amount of data between DPEs in a DPE array. A window connection may be implemented using DPE-local memory and buffers. A "stream connection" refers to a connection that transfers a variable amount of data between DPEs. A stream connection may be implemented using a stream interconnect (e.g., an AXI-S connection available across the DPE array). A "cascade connection" refers to a direct core-to-core connection between DPEs in a DPE array. A "real-time parameter interface" refers to a connection that sends and / or receives signals / data between a PS and a DPE. The real-time parameter connection may be implemented as a memory-mapped connection (e.g., an AXI-MM connection) using internal DPE buffers. The modeling system can translate the classified edges into dataflow connectors that connect computational nodes in the DPE array graph. In one or more example implementations, the DPE array graph may be specified using an HLL such as C or C++ extended to include custom constructs for use in defining the dataflow graph.

[0073] 7 illustrates the generation of configuration data for a target IC from a subgraph. The configuration data can be loaded into the target IC to configure it to implement the model originally created in the modeling system.

[0074] 7, the HLL program code generated from the subgraph 400, which corresponds to the portion of the model to be implemented in programmable logic, is processed by an implementation tool capable of performing high-level synthesis 702. The implementation tool generates one or more RTL kernels 704 with the correct connectivity. In one aspect, the RTL kernels 704 can be placed and routed.

[0075] The HLL program code generated from subgraph 500 corresponding to the portion of the model to be implemented by a processor system is represented as HLL kernel 706. HLL kernel 706, which may be compiled program code, targets the particular processor(s) of the processor system (e.g., RTP, APU, GPU, etc.) on which such HLL program code will execute. The DPE array graph generated from subgraph 600 corresponding to the portion of the model to be implemented in a DPE array is shown as DPE array graph 708.

[0076] A linker 710 can link the RTL kernel 704, the HLL kernel 706, and the DPE array graph 708 and generate configuration data 712 from the linked portions. The linker 710 can establish logical connections between address spaces and / or components for various systems of the target IC. The configuration data 712 can be loaded into the target IC to implement therein an electronic system that is functionally equivalent to the original model created in the modeling system. The configuration data 712 can include, for example, one or more configuration bitstreams that configure programmable logic, one or more binary digits of compiled program code for execution by a processor of the processor system, and configuration data for the DPE array.

[0077] Within the exemplary implementations described herein, the described model processing uses three different systems of the target IC; however, it should be appreciated that fewer or more systems may be incorporated into the described processing based on the particular target IC used and the particular model being created. For example, the target IC may include a processor system, programmable logic, and a DPE array, while the model being created may only use a processor system and a DPE array, a processor system and programmable logic, or any combination of systems. Thus, the classification, partitioning, HLL program code generation, and / or DPE array graph generation performed will vary and depend on the target IC being processed and the original model, as not all systems may be required or used by the model. If the target IC includes additional systems not described herein, the exemplary classification and partitioning described herein may be adapted to such additional systems.

[0078] 8 illustrates an exemplary method 800 for implementing a model in a target IC having multiple heterogeneous systems. Method 800 may be performed by a system such as the exemplary computer described with respect to FIG. 9. The system may execute the modeling system described herein. The system may further execute one or more hardware implementation tools. The IC in which the model is to be implemented includes multiple heterogeneous systems.

[0079] At block 802, the system may convert a model created as a data structure using a modeling system into a data flow graph. The model represents a design for implementation in an IC having multiple heterogeneous systems. At block 804, the system may classify nodes of the data flow graph for implementation in different ones of the multiple systems of the IC. At block 806, the system may partition the data flow graph into multiple subgraphs based on the classification performed at block 804, each subgraph corresponding to a different one of the multiple systems. At block 808, the system may generate a portion of HLL program code from each subgraph, each portion of HLL program code specific to the system corresponding to the subgraph from which the portion of HLL program code was generated.

[0080] These and other implementations can each optionally include one or more of the following features, alone or in combination. Some example implementations include all of the following features in combination.

[0081] In one aspect, a first system of the plurality of systems is programmable logic, and a portion of the HLL program code for the first system is hardware synthesizable.

[0082] In another aspect, a second system of the plurality of systems is a hardwired processor system having a hardwired processor configured to execute program code, and portions of the HLL program code for the second system are executable by the hardwired processor, and the HLL program code for the processor is functionally correct.

[0083] In another aspect, a third system of the plurality of systems is a data processing engine array, and a portion of the HLL program code for the third system specifies a DPE array graph including a plurality of computational nodes connected by data flow connectors.

[0084] In another aspect, a method may include linking portions of HLL program code for a system of an IC and generating, from the linked portions of the HLL program code, configuration data that is loadable into the IC to implement the design in the IC.

[0085] The nodes of the dataflow graph may be classified based at least in part on the data throughput of the node, the power constraint corresponding to the node, the operating frequency of the node, and / or whether the node of the dataflow graph is designated as a control node.

[0086] In another aspect, connectivity between nodes of the dataflow graph is maintained across subgraphs during partitioning.

[0087] The example implementations described within this disclosure ensure that, through partitioning and linking, the functional characteristics of the original model are preserved and implemented in each respective system in the resulting hardware. The generated designs for each system of the target IC can be verified independently and also verified as a whole, for example, across the systems of the target IC.

[0088] In another exemplary implementation, the modeling system can capture data at ports of model blocks of the model during simulation of the model. This data captured at the ports of the model blocks can be used by the system to generate test benches for verifying the generated hardware design. For example, verification can include verifying HLL code for subgraphs corresponding to programmable logic using C simulation or RTL simulation. Verification can include verifying HLL code for subgraphs corresponding to processor systems using software emulation. Verification can include verifying DPE array graphs using a software-based DPE array simulator. Linked designs, such as configuration data, can be verified using different ones of the emulators in combination as described.

[0089] FIG. 9 illustrates an example of a computer 900. The computer 900 may be used in a standalone capacity, for example, as a user computing device, as a server, as part of a computing cluster (e.g., two or more interconnected computers), or as a cloud computing node. The example of FIG. 9 is not intended to suggest a limitation on the scope of use or functionality of the example implementations described herein. The computer 900 is an example of a system and / or computer hardware capable of performing various operations described within this disclosure. The computer 900 is capable of, for example, executing a modeling system and one or more hardware-implemented tools (e.g., placer(s), router(s), configuration bitstream generator(s), linker, etc.) as described herein.

[0090] The computer 900 may be operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of computing systems, environments, and / or configurations that may be suitable for use with the computer 900 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0091] The computer 900 may be described in the general context of computer system executable instructions, such as program modules, that are executable by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer 900 may be practiced as a stand-alone computer system, such as a server, or in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may reside in both local and remote computer system storage media, including memory storage devices.

[0092] 9, components of computer 900 may include, but are not limited to, a processor 902, a memory 904, and a bus 906 that couples various system components including memory 904 to processor 902. Processor 902 may be implemented as one or more processors.

[0093] Bus 906 represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, a Peripheral Component Interconnect (PCI) bus, and a PCI Express (PCIe) bus.

[0094] The computer 900 typically includes a variety of computer system readable media, which may include both computer readable volatile and nonvolatile media, and computer readable removable and non-removable media.

[0095] The memory 904 may include computer-readable media in the form of volatile memory, such as random access memory (RAM) 908 and / or cache memory 910. The computer 900 may also include other removable / non-removable, volatile / non-volatile computer storage media. By way of example, a storage system 912 may be provided for reading from and writing to a non-removable, non-volatile magnetic and / or solid-state medium (not shown, commonly referred to as a “hard drive”). Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive may be provided for reading from or writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical medium. In such cases, each may be connected to the bus 906 by one or more data media interfaces. The memory 904 is an example of at least one computer program product having a set (e.g., at least one) of program modules configured to perform the functions of embodiments of the present invention.

[0096] A program / utility 914 having a set (at least one) of program modules 916 may be stored in memory 904. By way of example, the program modules 916 may represent an operating system, one or more application programs, other program modules, and program data. The program modules 916 generally perform the functions and / or methodologies of the example implementations described within this disclosure. For example, one or more of the program modules may perform various operations described within this disclosure, including, but not limited to, those described with respect to a modeling system and / or hardware-implemented tools.

[0097] The programs / utilities 914 are executable by the processor 902. The programs / utilities 914, as well as any data items used, generated, and / or operated on by the computing node 900, are functional data structures that, when employed by the computing node 900, provide functionality. A "data structure," as defined within this disclosure, is a physical implementation of a data model's organization of data in physical memory. Thus, a data structure is formed from specific electrical or magnetic structural elements in memory. The data structure imposes a physical organization on data stored in memory for use by application programs executed using the processor.

[0098] The computer 900 may also communicate with one or more external devices 920, such as a keyboard, pointing device, display 922, one or more devices that allow a user to interact with the computer 900, and / or any device (e.g., a network card, modem, etc.) that allows the computer 900 to communicate with one or more other computing devices. Such communication may occur via an input / output (I / O) interface 918. Additionally, the computer 900 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), via a network adapter 924. As shown, the network adapter 924 communicates with other components of the computer 900 via a bus 906. It should be understood that other hardware and / or software components, not shown, may be used with the computer 900. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data archive storage systems, and the like.

[0099] Computer 900 is an example of a data processing system. As defined herein, "data processing system" means one or more hardware systems configured to process data, each of which includes at least one processor and memory programmed to initiate operations.

[0100] Computer 900 may include fewer components than those shown, or additional components not shown in FIG. 9, depending on the particular type of device and / or system in which it is implemented. The particular operating system and / or application(s) included may vary according to the device and / or system type, as may the types of I / O devices included. Furthermore, one or more of the illustrated components may be incorporated into or otherwise form a portion of another component. For example, a processor may include at least some memory.

[0101] For purposes of explanation, specific nomenclature is 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 particular aspects of the inventive configurations only and is not intended to be limiting.

[0102] As defined herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0103] As defined herein, the terms "at least one," "one or more," and "and / or" are open-ended expressions that are both conjunctive and disjunctive in operation unless otherwise specified. For example, the phrases "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" each mean A only, B only, C only, A and B together, A and C together, B and C together, or A, B, and C together.

[0104] As defined herein, the term "automatically" means without human intervention. As defined herein, the term "user" means a human being.

[0105] 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 transitory, propagating signal. A computer-readable storage medium may be, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. The 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 diskettes, hard disks, RAM, read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), electronically erasable programmable read-only memory (EEPROM), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, etc.

[0106] As defined herein, the term "if" can mean "when" or "upon" or "in response to" or "responsive to," depending on the context. Thus, the phrase "when it is determined" or "when the stated condition or event] is detected" can be interpreted to mean "upon determining" or "in response to determining," or "upon detecting the stated condition or event," or "in response to detecting the stated condition or event," or "in response to detecting the stated condition or event," depending on the context.

[0107] The term "in response to," as defined herein, and similar phrases as explained above, e.g., "when," "when," or "upon," means to readily respond or react to an action or event. The response or reaction is performed automatically. Thus, when a second action is performed "in response to" a first action, there is a causal relationship between the occurrence of the first action and the occurrence of the second action. The term "in response to" indicates a causal relationship.

[0108] As defined herein, the term "processor" means at least one hardware circuit capable of executing instructions. The instructions may be contained in program code. The circuit may be an integrated circuit or embedded in an integrated circuit.

[0109] The term "real-time" as defined herein means a level of processing responsiveness that a user or system perceives as being sufficiently immediate for a particular process or decision to occur, or that allows the processor to keep up with some external process.

[0110] The term "substantially," as defined herein, means that the recited property, parameter, or value need not be achieved exactly, but that deviations or variations, including, for example, tolerances, measurement errors, measurement accuracy limits, and other factors known to those skilled in the art, may occur in amounts that do not interfere with the effect the property is intended to provide.

[0111] Terms such as first, second, etc. may be used herein to describe various elements, but unless otherwise stated or the context clearly indicates otherwise, these elements should not be limited by these terms as they are only used to distinguish one element from another.

[0112] A computer program product may include one or more computer-readable storage media having computer-readable program instructions thereon for causing a processor to perform aspects of the inventive arrangements described herein. Within this disclosure, the term “program code” is used interchangeably with the term “computer-readable program instructions.” The computer-readable program instructions described herein may be downloaded from the computer-readable storage media to a respective computing / processing device or to an external computer or external storage device via a network, e.g., the Internet, a LAN, a WAN, and / or a wireless network. The network may include copper transmission cables, optical transmission fiber, wireless transmission, edge devices including routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0113] Computer-readable program instructions for performing operations for the inventive arrangements described herein may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, or source or object code written in any combination of one or more programming languages, including object-oriented and / or procedural programming languages. The computer-readable program instructions may include state-setting data. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a LAN or WAN, or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some cases, electronic circuitry, including, for example, programmable logic circuitry, FPGAs, or PLAs, may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to implement aspects of the inventive arrangements described herein.

[0114] Certain aspects of the inventive arrangements have been described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products. It will be understood that each block of 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.

[0115] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions executing via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0116] The computer-readable program instructions may also be loaded into a computer, other programmable apparatus, or other device to cause a series of operations to be performed on the computer, other programmable data processing apparatus, or other device to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0117] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various aspects of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified operations.

[0118] In some alternative implementations, the actions noted in the blocks may occur out of the order noted in the figures. For example, depending on the functionality involved, two blocks shown in succession may be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order. In other examples, the blocks may be executed generally in numerical order, while in still other examples, one or more blocks may be executed in a varying order, with the results stored and utilized in another subsequent or non-immediately following block. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or acts or a combination of dedicated hardware and computer instructions.

[0119] The corresponding structure, material, acts, and equivalents of all means or step and functional elements that may appear in the following claims are intended to include any structure, material, or act for performing a function in combination with other claimed elements as specifically claimed.

[0120] The description of the inventive configurations provided herein is for illustrative purposes only and is not intended to be exhaustive or limited to the forms and examples disclosed. The terminology used herein has been chosen to explain the principles, practical applications, or technical improvements of the inventive configurations over commercially available technology, and / or to enable others skilled in the art to understand the inventive configurations disclosed herein. Modifications and variations may become apparent to those skilled in the art without departing from the scope and spirit of the inventive configurations described. Accordingly, reference should be made to the following claims, rather than to the above disclosure, as indicating the scope of such features and implementations.

Claims

1. converting a model created as a data structure using a modeling system into a data flow graph, the model representing a design for implementation in an integrated circuit having a plurality of systems, the systems being heterogeneous; classifying nodes of the data flow graph for implementation in different ones of the systems of the integrated circuit; partitioning the data flow graph into a plurality of subgraphs based on the classification, each subgraph corresponding to a different one of the plurality of systems; generating a high level language (HLL) program code portion from each subgraph, each HLL program code portion being specific to the system corresponding to the subgraph from which said portion of HLL program code was generated; Including, a first system of the plurality of systems is a data processing engine array, and the portion of the HLL program code for the first system specifies a data flow graph including a plurality of computational nodes connected by data flow connectors; method.

2. a second system of the plurality of systems is programmable logic, and the portion of the HLL program code for the second system is hardware synthesizable; The method of claim 1.

3. a third system of the plurality of systems is a hardwired processor system having a hardwired processor configured to execute program code, and the portion of the HLL program code for the third system is executable by the hardwired processor; 3. The method according to claim 1 or 2.

4. linking the portions of the HLL program code for the system on the integrated circuit; generating, from the linked portions of the HLL program code, configuration data loadable into the integrated circuit for implementing the design within the integrated circuit; The method of any one of claims 1 to 3, further comprising:

5. the nodes of the data flow graph are classified based at least in part on the data throughput of the nodes; 5. The method according to any one of claims 1 to 4.

6. the nodes of the dataflow graph are classified based at least in part on whether the nodes are control nodes; 6. The method according to any one of claims 1 to 5.

7. The node of the data flow graph is a power constraint corresponding to said node; or The operating frequency of the node are classified at least in part based on at least one of 7. The method according to any one of claims 1 to 6.

8. connectivity between the nodes of the dataflow graph is maintained across the subgraphs during the partitioning.

8. The method according to any one of claims 1 to 7.

9. 1. A system comprising: a processor configured to initiate an operation, the operation comprising: converting a model created as a data structure using a modeling system into a data flow graph, the model representing a design for implementation in an integrated circuit having a plurality of systems, the systems being heterogeneous; classifying nodes of the data flow graph for implementation in different ones of the systems of the integrated circuit; partitioning the data flow graph into a plurality of subgraphs based on the classification, each subgraph corresponding to a different one of the plurality of systems; generating a high level language (HLL) program code portion from each subgraph, each HLL program code portion being specific to the system corresponding to the subgraph from which said portion of HLL program code was generated; Including, A system wherein a first system of the plurality of systems is a data processing engine array, and the portion of the HLL program code for the first system specifies a data flow graph including a plurality of computational nodes connected by data flow connectors.

10. a second system of the plurality of systems is programmable logic, and the portion of the HLL program code for the second system is hardware synthesizable; The system of claim 9.

11. a third system of the plurality of systems; 11. The system of claim 9 or 10, a hardwired processor system having a hardwired processor configured to execute program code, wherein the portion of the HLL program code for the third system is executable by the hardwired processor.

12. the processor: linking the portions of the HLL program code for the system on the integrated circuit; generating, from the linked portions of the HLL program code, configuration data loadable into the integrated circuit for implementing the design within the integrated circuit; 12. A system according to any one of claims 9 to 11, configured to initiate an operation comprising:

13. 13. The system of claim 9, wherein the nodes of the data flow graph are classified based at least in part on at least one of a data throughput of the node, whether the node is a control node, a power constraint corresponding to the node, or an operating frequency of the node.

Images