Patent Description:
An SoC refers to a type of integrated circuit (IC) that includes a processor capable of executing program code and one or more other subsystems. The processor is capable of operating in coordination with the other subsystem(s). A heterogeneous SoC refers to an IC that includes two or more processors. The processors may have different architectures, e.g., utilize different instruction sets. The processors may also operate independently of one another. For example, a first processor of such a heterogeneous SoC may execute a first operating system and application, while a second processor of the heterogeneous SoC may execute a second and different operating system and/or application.

<CIT> (XILINX INC) describes an OpenCL program compilation which may include generating, using a processor, a register transfer level (RTL) description of a first kernel of a heterogeneous, multiprocessor design and integrating the RTL description of the first kernel with a base platform circuit design. The base platform circuit design provides a static interface within a programmable integrated circuit to a host of the heterogeneous, multiprocessor design. A first configuration bitstream may be generated from the RTL description of the first kernel using the processor. The first configuration bitstream specifies a hardware implementation of the first kernel and supporting data for the configuration bitstream. The first configuration bitstream and the supporting data may be included within a binary container.

In one or more embodiments, there is provided a method according to the appended claims.

In some embodiments, the platform may include a first stage boot loader configured to initialize a processor system of the heterogeneous SoC.

In some embodiments, the platform may include, for a selected domain of the plurality of domains, a device tree for the operating system assigned to the selected domain. The device tree may be generated based upon the hardware resource selected from the plurality of hardware resources.

In some embodiments, each domain may be logically enforced within the heterogeneous SoC.

In some embodiments, the method may further include modifying at least one domain of the plurality of domains for the heterogeneous SoC using the hardware description file.

In some embodiments, the platform may include a plurality of artifacts for the plurality of domains for use by a software development environment. The method may further include generating executable program code for a selected domain of the plurality of domains using an artifact selected from the plurality of artifacts that corresponds to the selected domain.

In some embodiments, each domain may be assigned a portion of available random-access memory.

In one or more embodiments, there is provided a system according to the appended claims.

In some embodiments, the platform may include configuration data for configuring isolation circuits of the heterogeneous SoC.

In some embodiments, the processor may be configured to initiate operations that further include modifying at least one domain of the plurality of domains for the heterogeneous SoC using the hardware description file.

In some embodiments, the platform may include a plurality of artifacts for the plurality of domains for use by a software development environment. The processor may be configured to initiate operations further including generating executable program code for a selected domain of the plurality of domains using an artifact selected from the plurality of artifacts that corresponds to the selected domain.

In one or more embodiments, a computer program product includes a computer readable storage medium having program code stored thereon. The program code is executable by computer hardware to initiate operations. The operations may include receiving a hardware description file specifying a plurality of processors and a plurality of hardware resources available within a heterogeneous SoC and creating a plurality of domains for the heterogeneous SoC, wherein each domain includes a processor selected from the plurality of processors and a hardware resource selected from the plurality of hardware resources. The operations may include assigning an operating system to each domain and generating a platform that is configured to implement the plurality of domains within the heterogeneous SoC.

This Summary section is provided merely to introduce certain concepts and not to identify any key or essential features of the claimed subject matter. Other features of the inventive arrangements will be apparent from the accompanying drawings and from the following detailed description.

The inventive arrangements are illustrated by way of example in the accompanying drawings. The drawings, however, should not be construed to be limiting of the inventive arrangements to only the particular implementations shown. Various aspects and advantages will become apparent upon review of the following detailed description and upon reference to the drawings.

While the disclosure concludes with claims defining novel features, it is believed that the various features described within this disclosure will be better understood from a consideration of the description in conjunction with the drawings. The process(es), machine(s), manufacture(s) and any variations thereof described herein are provided for purposes of illustration. Specific structural and functional details described within this disclosure are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the features described in virtually any appropriately detailed structure. Further, the terms and phrases used within this disclosure are not intended to be limiting, but rather to provide an understandable description of the features described.

This disclosure relates to ICs and, more particularly, creating and isolating multiple domains within a heterogeneous SoC. In accordance with the inventive arrangements disclosed herein, different domains, e.g., software domains, are created for implementation within a heterogeneous SoC. Each domain, in effect, implements a subsystem of the heterogeneous SoC. The domains may be created using an application-level tool as opposed to a hardware design tool. Each domain for the heterogeneous SoC may be created to include various resources, whether hardware and/or software. Each domain, when implemented in the heterogeneous SoC, may be used to implement and/or execute one or more embedded applications by leveraging hardware isolation features available in the heterogeneous SoC. For purposes of description, the term "SoC" or "System-on-Chip" refers to a heterogeneous SoC within this disclosure.

In one or more embodiments, a hardware design tool (e.g., Electronic Design Automation (EDA) tool) may be used to generate a hardware description file for a design. The hardware description file, as generated by the hardware design tool, specifies the particular hardware resources of an SoC that are instantiated and, as such, are available for use by a given design to be implemented within the SoC. The hardware description file specifies which processors of the SoC are available for use and which peripheral devices of the SoC are available for use by the design. The hardware description file specifies the hardware resources of the SoC that may be used by embedded applications, e.g., the program code that is created to run or execute on the SoC. In this regard, an SoC may include more hardware resources than are defined within the hardware description file generated by the hardware design tool.

In one or more embodiments, the hardware description file may be exported from the hardware design tool and imported by a computer-based domain creation tool. The domain creation tool is capable of generating multiple domains based upon the hardware description file. The domain creation tool, for example, is capable of defining a plurality of domains where each domain includes a processor from the hardware description file. The domain creation tool is capable of assigning different hardware resources specified within the hardware description file to the different domains that are created.

The domain creation tool is capable of generating a platform that specifies the domains that have been created. The platform may include a variety of different software artifacts for the different domains. The domain creation tool is capable of generating configuration data that may be loaded into the SoC to implement the various domains. The configuration data, when loaded into the SoC, is capable of creating the domains and isolating the domains from one another. In another example, the domain creation tool is capable of generating one or more software artifacts tailored to the different domains. The software artifacts may be used to generate executable program code (e.g., embedded applications) intended for execution in particular ones of the domains.

In one or more embodiments, the domain creation tool is also capable of modifying the domains that are created from the hardware design system. For example, a software developer may utilize the domain creation tool to modify one or more of the different domains based upon the original hardware description file that was initially used to create the original domains. Thus, a new and/or different hardware description file need not be generated by the hardware design application to change and/or modify the domains of the SoC.

Further aspects of the inventive arrangements are described below in greater detail with reference to the figures. For purposes of simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. Further, where considered appropriate, reference numbers are repeated among the figures to indicate corresponding, analogous, or like features.

<FIG> illustrates an example system <NUM> for use with one or more embodiments described herein. System <NUM> is an example of computer hardware that may be used to implement a computer, a server, a portable computer such as a laptop or a tablet computer, or other data processing system. A system or a device implemented using computer hardware is capable of performing the various operations described herein relating to creating and isolating multiple domains within an SoC and/or processing a circuit design for implementation within an SoC.

In the example of <FIG>, system <NUM> includes at least one processor <NUM>. Processor <NUM> is coupled to memory <NUM> through interface circuitry <NUM>. System <NUM> is capable of storing computer readable instructions (also referred to as "program code") within memory <NUM>. Memory <NUM> is an example of computer readable storage media. Processor <NUM> is capable of executing the program code accessed from memory <NUM> via interface circuitry <NUM>.

Memory <NUM> may include one or more physical memory devices such as, for example, a local memory and a bulk storage device. Local memory refers to non-persistent memory device(s) generally used during actual execution of program code. Examples of local memory include random-access memory (RAM) and/or any of the various types of RAM that are suitable for use by a processor during execution of program code (e.g., dynamic RAM or "DRAM" or static RAM or "SRAM"). A bulk storage device refers to a persistent data storage device. Examples of bulk storage devices include, but are not limited to, a hard disk drive (HDD), a solid-state drive (SSD), flash memory, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or other suitable memory. System <NUM> may also include one or more cache memories (not shown) that provide temporary storage of at least some program code in order to reduce the number of times program code must be retrieved from a bulk storage device during execution.

Memory <NUM> is capable of storing program code and/or data. For example, memory <NUM> is capable of storing various routines, programs, objects, components, logic, other suitable instructions, and/or other data structures. For purposes of illustration, memory <NUM> stores an operating system <NUM>, one or more application(s) <NUM>, and a hardware description file <NUM>. Memory <NUM> may also store a circuit design. In one or more embodiments, application(s) <NUM> may include a hardware design application (e.g., an electronic design automation or EDA application) and/or a domain creation application. The hardware design application is capable of generating a hardware system and storing the hardware system as hardware description file <NUM>. Hardware description file <NUM> may specify different hardware resources of the target SoC that have been instantiated and, as such, are available for use by a design to be implemented in the target SoC. Examples of hardware resources include, but are not limited to, processors (and/or processor cores), memories, peripherals, storage devices, and/or other hardware components of an SoC that have been instantiated and are available for use.

The domain creation application is capable of performing operations described herein relating to the creation and isolation of domains within an SoC. The hardware design application may also perform one or more operations of a design flow (e.g., synthesis, placement, routing, and/or bitstream generation) to implement a circuit design within the SoC.

System <NUM>, e.g., processor <NUM>, is capable of executing operating system <NUM> and application(s) <NUM> to perform the operations described within this disclosure. As such, operating system <NUM> and application(s) <NUM> may be considered an integrated part of system <NUM>. Further, it should be appreciated that any data used, generated, and/or operated upon by system <NUM> (e.g., processor <NUM>) are functional data structures that impart functionality when employed as part of the system.

Examples of interface circuitry <NUM> include, but are not limited to, a system bus and an input/output (I/O) bus. Interface circuitry <NUM> may be implemented using any of a variety of bus architectures. Examples of bus architectures may include, but are not limited to, Enhanced Industry Standard Architecture (EISA) bus, Accelerated Graphics Port (AGP), Video Electronics Standards Association (VESA) local bus, Universal Serial Bus (USB), and Peripheral Component Interconnect Express (PCle) bus.

System <NUM> further may include one or more I/O devices <NUM> coupled to interface circuitry <NUM>. I/O devices <NUM> may be coupled to system <NUM>, e.g., interface circuitry <NUM>, either directly or through intervening I/O controllers. Examples of I/O devices <NUM> include, but are not limited to, a keyboard, a display device, a pointing device, one or more communication ports, and a network adapter. A network adapter refers to circuitry that enables system <NUM> to become coupled to other systems, computer systems, remote printers, and/or remote storage devices through intervening private or public networks. Modems, cable modems, Ethernet cards, and wireless transceivers are examples of different types of network adapters that may be used with system <NUM>.

System <NUM> may include fewer components than shown or additional components not illustrated in <FIG> depending upon the particular type of device and/or system that is implemented. In addition, the particular operating system, application(s), and/or I/O devices included may vary based upon system type. Further, one or more of the illustrative components may be incorporated into, or otherwise form a portion of, another component. For example, a processor may include at least some memory. System <NUM> may be used to implement a single computer or a plurality of networked or interconnected computers each implemented using the architecture of <FIG> or an architecture similar thereto.

The inventive arrangements described within this disclosure are capable of creating a plurality of different domains within an SoC. System <NUM>, e.g., executing the domain creation application, is capable of receiving hardware description file <NUM>, which defines the hardware environment available for use by embedded software. Embedded software refers to program code that is intended to run or execute in a particular domain of the SoC.

System <NUM>, in executing the domain creation application, is capable of defining each of a plurality of different domains that may be implemented within the SoC. Each domain is assigned one of the available processors of the SoC from hardware description file <NUM>. In addition, system <NUM> is capable of specifying the particular operating system to be executed by the processor in each of the domains.

System <NUM>, in executing the domain creation application, is also capable of assigning different ones of the hardware resources from hardware description file <NUM> to different ones of the domains. System <NUM> is capable of generating software artifacts such as configuration data that, when loaded into the SoC, creates the domains and enforces isolation among the domains during operation of the SoC. For example, once a design to be implemented within the SoC is complete and is loaded into the SoC, circuitry within the SoC prevents one domain from accessing elements of the SoC assigned to other domains thereby ensuring independence and secure operation by the respective domains.

In conventional systems, a hardware design is created using design tools. The hardware design is unaware of the operating system assignments and the related settings for the processors of the design. The hardware design is output as a hardware description file to software developers. The hardware description file, however, was provided as a rigid block of hardware that the user (e.g., the software developer) is unable to alter. The software developers were unable to modify the resources available to any given processor.

In accordance with the inventive arrangements described herein, system <NUM> allows the user (e.g., the software developer) to specify and create different domains based upon the hardware description file. System <NUM>, for example, is capable of using the existing hardware description file and allocate boundaries that include the assigned hardware resources and operating system to run the processor that is also allocated to the various domains that are created. The domains may be modified using the original (and unchanged) hardware description file.

<FIG> illustrates an example of a heterogeneous SoC <NUM>. In the example of <FIG>, SoC <NUM> includes a processor system <NUM> and programmable circuitry <NUM>. Processor system <NUM> is a hardwired region of SoC <NUM> that includes two or more processors that are configured to execute program code. In one or more embodiments, programmable circuitry <NUM> may be implemented as field programmable gate array (FGPA) circuitry and/or programmable logic. Due to the inclusion of programmable circuitry <NUM>, SoC <NUM> may also be referred to as a programmable SoC.

In general, the functionality of programmable circuitry <NUM> is not established until configuration data is loaded into configuration memory cells (not shown) of SoC <NUM>. A set of configuration bits may be used to program programmable circuitry <NUM>. The configuration bit(s) typically are referred to as a "configuration bitstream" or "bitstream. " In general, programmable circuitry is not operational or functional without first loading a configuration bitstream into SoC <NUM>. The configuration bitstream effectively implements a particular circuit design or circuit structures and connections within programmable circuitry <NUM>. The circuit design specifies, for example, functional aspects of the programmable circuit blocks and physical connectivity among the various programmable circuit blocks of programmable circuitry <NUM>.

Circuitry that is "hardwired" or "hardened," i.e., not programmable, is manufactured as part of SoC <NUM>. Unlike programmable circuitry <NUM>, hardened circuitry or hardened circuit blocks are not implemented after the manufacture of SoC <NUM> through the loading of a configuration bitstream. Hardened circuitry is generally considered to have dedicated circuit blocks and interconnects, for example, that are functional without first loading a configuration bitstream into SoC <NUM>.

Processor system <NUM> includes a variety of different processors. In one aspect, the different processors of processor system <NUM> are physically distinct instances, but have same architectures (use same instruction sets). In another aspect, the different processors of processor system <NUM> are physically distinct instances and utilize two or more different architectures (e.g., utilize different instruction sets). In the example of <FIG>, processor system <NUM> includes an application processing unit (APU) <NUM>, a real-time processing unit (RPU) <NUM>, and/or processor <NUM>.

APU <NUM> may include one or more cores. For purposes of discussion within this disclosure, a core is considered a "processor" that is configured to execute program code. RPU <NUM> may include one or more cores. In one or more embodiments, RPU <NUM> is capable of executing real-time applications. Examples of real-time applications include, but are not limited to, automotive, mass storage, mobile baseband, medical, and/or industrial applications. Both APU <NUM> and RPU <NUM> may be directly connected to programmable circuitry <NUM> through isolation circuits <NUM>-<NUM> and <NUM>-<NUM>, respectively.

As noted, in one aspect, the different processors (e.g., including cores) may have different architectures. In one example, processor <NUM> is implemented as a hardened version of the MicroBlaze™ processor from Xilinx, Inc. of San Jose, CA. APU <NUM> may be implemented as a multicore processor from Arm Ltd. of Cambridge, UK such as the ARM CORTEX-A9. RPU <NUM> may be implemented as an ARM CORTEX-R5 processor also available from Arm Ltd. The example processor architectures described herein are provided for purposes of illustration. One skilled in the art will appreciate that other architectures may be used for implementing processors in SoC <NUM> such as an x86 processor architecture and so forth.

Processor system <NUM> further may include an input/output (I/O) subsystem <NUM>, interconnect <NUM>, a memory controller <NUM>, and on-chip memory (OCM) <NUM>. In the example of <FIG>, interconnect <NUM> is coupled to RPU <NUM>, OCM <NUM>, APU <NUM>, processor <NUM>, I/O subsystem <NUM>, and memory controller <NUM>. As pictured, interconnect <NUM> may be connected to such elements through intervening isolation circuits <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM>, respectively.

In one or more embodiments, interconnect <NUM> is implemented as an on-chip interconnect. An example of an on-chip interconnect is an AMBA eXtensible Interface (AXI) bus. An AMBA AXI bus is an embedded microcontroller bus interface for use in establishing on-chip connections between circuit blocks and/or systems. Other example implementations of an interconnect may include, but are not limited to, buses, cross-bars, network on chips (NoCs), switches, and so forth.

I/O subsystem <NUM> includes a plurality of I/O devices such as I/O devices <NUM> and <NUM>. I/O subsystem <NUM> may include more than two I/O devices. Each of I/O devices <NUM> and <NUM> is coupled to a multiplexer I/O (MIO) <NUM>. MIO <NUM> is configurable to provide processor system <NUM> and/or programmable circuitry <NUM> with access to nodes external to SoC <NUM> and to the various I/O devices of SoC <NUM>. MIO <NUM> may be configured on a per pin basis and may facilitate concurrent access to I/O devices <NUM> and/or <NUM> by processor system <NUM> and/or programmable circuitry <NUM>.

In the example of <FIG>, instances of isolation circuit <NUM> are included within SoC <NUM>. In one or more embodiments, each of isolation circuits <NUM> is configurable to regulate or control access to hardware resources in SoC <NUM>. Each isolation circuit <NUM>, for example, may be configured, through the loading of configuration data, to allow only selected hardware resources to access other hardware resources. The configuration data may also specify implementation options for elements within processor system <NUM>. As such, the configuration data may specify and/or implement the different domains within SoC <NUM>.

For example, isolation circuit <NUM>-<NUM> is in the signal path between RPU <NUM> and interconnect <NUM> and is capable of regulating which hardware resources of SoC <NUM> is/are permitted to interact with RPU <NUM>. Isolation circuit <NUM>-<NUM> is in the signal path between OCM <NUM> and interconnect <NUM> and is capable of regulating which hardware resources of SoC <NUM> is/are permitted to interact with OCM <NUM>. Isolation circuit <NUM>-<NUM> is in the signal path between APU <NUM> and interconnect <NUM> and is capable of regulating which hardware resources of SoC <NUM> is/are permitted to interact with APU <NUM>. Isolation circuit <NUM>-<NUM> is in the signal path between processor <NUM> and interconnect <NUM> and is capable of regulating which hardware resources of SoC <NUM> is/are permitted to interact with processor <NUM>.

Further, isolation circuit <NUM>-<NUM> is in the signal path between interconnect <NUM> and I/O subsystem <NUM> (e.g., in the signal path to each of the I/O devices). Isolation circuit <NUM>-<NUM> is capable of regulating which hardware resources of SoC <NUM> is/are permitted to interact with I/O subsystem <NUM>, e.g., on a per I/O device basis. Isolation circuit <NUM>-<NUM> is in the signal path between interconnect <NUM> and memory controller <NUM> and is capable of regulating which hardware resources of SoC <NUM> is/are permitted to interact with memory controller <NUM> and/or access (e.g., read and/or write) particular regions of memory (not shown) coupled to memory controller <NUM>. Further, isolation circuits <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> are in the signal path between programmable circuitry <NUM> and RPU <NUM>, interconnect <NUM>, and APU <NUM>, respectively. Isolation circuit <NUM>-<NUM> is capable of regulating access of circuits in programmable circuitry <NUM> to RPU <NUM> and/or access of RPU <NUM> to circuits in programmable circuitry <NUM>. Isolation circuit <NUM>-<NUM> is capable of regulating access of circuits in programmable circuitry <NUM> to interconnect <NUM> and/or interconnect <NUM> to circuits in programmable circuitry <NUM>. Isolation circuit <NUM>-<NUM> is capable of regulating access of circuits in programmable circuitry <NUM> to APU <NUM> and/or APU <NUM> to circuits in programmable circuitry <NUM>.

In general, isolation circuits <NUM> may be programmed to implement different domains within SoC <NUM>. Isolation circuits <NUM> may be programmed to permit only those hardware resources belonging to the same domain to communicate with one another. In particular embodiments, isolation circuits <NUM> implement a logical separation of hardware resources of SoC <NUM> into different domains. For example, isolation circuits <NUM> may permit access or deny access based upon the address being accessed and/or the identifier of the circuit attempting to access another hardware resource.

As an illustrative and non-limiting example, different ones of the I/O devices <NUM> and/or <NUM> may be assigned to a particular one of the processors. For instance, a first domain may be created that includes APU <NUM>, memory controller <NUM> (e.g., a particular region of RAM), and I/O device <NUM>. A second domain may be created that includes RPU <NUM>, I/O device <NUM>, memory controller <NUM> (e.g., a second and different region of RAM) and OCM <NUM>. In this example, isolation circuits <NUM> enforce domain isolation and, for example, prevent RPU <NUM> from accessing I/O device <NUM> and prevent APU <NUM> from accessing I/O device <NUM>. Isolation circuits <NUM> further prevent APU <NUM> from accessing the second region of RAM and prevent RPU <NUM> from accessing the first region of RAM.

In one or more embodiments, particular ones of isolation circuits <NUM> may be implemented as a memory protection unit. For example, isolation circuits <NUM>-<NUM> and <NUM>-<NUM> may be implemented as memory protection units. In one or more other embodiments, particular ones of isolation circuits <NUM> may be implemented as processor protection units. For example, isolation circuits <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> may be implemented as processor protection units.

<FIG> is an example of isolation circuit <NUM>. The example of <FIG> may be a memory protection unit. For purposes of illustration, <FIG> utilizes AXI interface terminology. It should be appreciated that isolation circuit <NUM> of <FIG> may be implemented to work with any of a variety of different bus and/or interconnect protocols.

In the example of <FIG>, address range check circuit <NUM> checks whether the address of a received transaction is within the region defined by a start address and an end address, which may be stored in configuration registers of isolation circuit <NUM> (e.g., by virtue of writing configuration data to the configuration registers). Further, master ID (identifier) circuit <NUM> is capable of checking whether the master ID of the incoming transaction is allowed based upon configuration data stored in the configuration registers of isolation circuit <NUM>.

Isolation circuit <NUM> may disallow any transaction that does not meet the check performed by address range check circuit <NUM> and master ID circuit <NUM>. Isolation circuit <NUM> may also poison the transaction (e.g., exert the "poison" signal). Depending upon the configuration of isolation circuit <NUM>, an interrupt may be generated in the case where a transaction does not meet the checks performed and/or the poison signal is asserted.

<FIG> is another example of isolation circuit <NUM>. The example of <FIG> may be a processor protection unit. For purposes of illustration, <FIG> utilizes AXI interface terminology. It should be appreciated that isolation circuit <NUM> of <FIG> may be implemented to work with any of a variety of different bus and/or interconnect protocols.

In the example of <FIG>, a master ID list, stored within isolation circuit <NUM>, is used to define the masters that are allowed to access peripherals. An aperture permission list, stored within isolation circuit <NUM>, specifies permissions on peripheral addresses that masters can access. Master ID check circuit <NUM> checks that the AXI master ID of a received transaction is in the aperture permission list. Permissions are based on master ID. The AXI slave entry comes from a corresponding bit in the permission field. Address range circuit <NUM> is capable of checking that the address range accessed by the master, per the configuration data, is allowed. If the requirements are not met, the transaction is poisoned, and an interrupt is optionally generated.

Referring to both <FIG>, an error response signal, e.g., the poison signal, may be generated in response to determining that a transaction is illegal (e.g., the transaction fails one or both checks performed by isolation circuit <NUM>). The error signal causes a data abort or an interrupt signal to be generated.

<FIG> illustrates an example of creating and isolating multiple domains within a heterogeneous SoC. In the example of <FIG>, hardware design application <NUM> generates a hardware description file <NUM>. Hardware description file <NUM> specifies the different hardware resources of the SoC that are available for use. Domain creation application <NUM> receives hardware description file <NUM>. Based upon user inputs <NUM> specifying domains, e.g., which processors are included in each respective domains, the operating system to be executed by each processor, peripherals and/or memory to be available to each processor in each domain, domain creation application <NUM> outputs a platform <NUM> that specifies the domains. Platform <NUM> includes one or more software artifacts. The software artifacts include configuration data. The software artifacts may include a first stage boot loader, and/or other software artifacts that may be used in building embedded applications for the different domains of the SoC. For example, the software artifacts may include drivers for the peripherals included in each of the different domains.

<FIG> illustrates an example of multiple domains for a heterogeneous SoC <NUM>. In the example of <FIG>, domains <NUM>, <NUM>, <NUM>, and <NUM> are shown. In an aspect, each of the resources shown within domains <NUM>, <NUM>, <NUM>, and <NUM> (with the exception of the operating systems) is specified as being available within the hardware description file. Each of domains <NUM>, <NUM>, and <NUM> utilizes an operating system. In an embodiment which does not fall under the scope of the claims, domain <NUM> may not use an operating system and support one or more bare-metal and/or standalone application(s).

As illustrated, domain <NUM> includes processor <NUM>, General Equipment Model (GEM) interface <NUM>, Serial Peripheral Interface (SPI) <NUM>, watchdog timer (WDT) <NUM>, Quad Serial Peripheral Interface (QSPI) <NUM>, and programmable logic Intellectual Property (PL IP) <NUM>. Programmable logic IP refer to an IP or a core that is implemented in programmable circuitry. Domain <NUM> includes processor <NUM>, a timing trigger and control (TTC) interface <NUM>, WDT <NUM>, Universal Asynchronous Receiver-Transmitter (UART) <NUM>, and PL IP <NUM>. Domain <NUM> includes processor <NUM>, GEM interface <NUM>, Secure Digital Input Output (SDIO) <NUM>, Universal Serial Bus (USB) <NUM>, SPI <NUM>, Inter-Integrated circuit (I2C) interface <NUM>, I2C interface <NUM>, UART <NUM>, QSPI <NUM>, WDT <NUM>, and Peripheral Component Interconnect Express (PCIe) <NUM>. Domain <NUM> includes a processor <NUM> (e.g., without an operating system), TTC interface <NUM>, WDT <NUM>, UART <NUM>, and PLIP <NUM>.

<FIG> illustrates an example method <NUM> of creating and isolating multiple domains within an SoC. Method <NUM> is performed by a computing system as described herein in reference to <FIG> executing a domain creation application.

In block <NUM>, the system loads, or receives, a hardware description file. The hardware description file may be obtained from a hardware design application in which a hardware designer instantiates hardware resources that will be available in the SoC. The hardware description file specifies the hardware resources that have been instantiated and that are available for a design. The hardware description file further may include additional details relating to the listed hardware resources.

In block <NUM>, the system creates a domain. For example, a user may provide a user input requesting the creation of a domain. In one or more embodiments, the system provides a graphical user interface (GUI) through which the user may request creation of a domain. In one or more other embodiments, the system provides a command line interface through which a user may provide a command to create a domain. In response to a request to do so, the system creates a domain for the SoC.

In block <NUM>, the system determines a processor for the domain. For example, subsequent to the command to create a domain, the system may receive a further user input specifying a processor listed in the hardware description file to assign to the domain. In particular embodiments, the processor may be specified as part of the command, e.g., as a parameter or argument of the command, to create the domain. In response to receiving a user input specifying a processor, the system creates a domain and assigns the processor to the domain. For example, the system creates a data structure in memory that associates the processor with the domain.

In block <NUM>, the system determines the operating system for the domain. For example, the system may receive a further user input specifying a particular operating system to be used for the domain. In one or more embodiments, the command to create the domain may include or specify the operating system as a further parameter or argument of the command. Examples of different types of operating systems that may be selected for use in the domain include, but are not limited to, Linux, a Real-time Operating System (RTOS) such as Free RTOS, or any other operating system that is suitable for execution by a processor or an embedded processor. In other embodiments which do not fall under the scope of the claims, a domain may not include an operating system and support one or more bare-metal and/or standalone applications.

In conventional embedded system development techniques, software developers were restricted to utilizing the particular operating system associated with a processor based upon the hardware design. In accordance with the inventive arrangements described within this disclosure, the software developer is free to choose different operating systems. The software developer may experiment with different operating system/processor pairings and/or different operating system configurations (e.g., different address space mappings, different drivers, etc. per block <NUM> below).

In block <NUM>, the system is capable of adding one or more resources to the domain created in blocks <NUM> and <NUM>. In one or more embodiments, the system adds resource(s) to the domain by assigning the resource(s) to the domain. The resources may be hardware resources selected from the hardware description file. Examples of hardware resources can include, but are not limited to, memories and devices (e.g., memory controllers, I/O devices, and/or other peripherals). The resources may also include software resources for the selected operating system. Examples of software resources can include, but are not limited to, drivers, physical address space mappings, and/or firmware.

In one or more embodiments, the system is capable of pruning properties of hardware resources added to the domain. For example, the system is capable of modifying properties of hardware resources by altering the configurable registers of such hardware resources, e.g., altering the configuration data written to the registers. As an illustrative and nonlimiting example, the system is capable of changing the clock frequency of a UART.

Within block <NUM>, additional properties may also be added to the domain and/or attached to resources added to the domain. For example, Quality of Service (QoS) settings may be specified for particular hardware resources added to the domain. Isolation settings may also be specified for the domain and/or for particular hardware resources added to the domain. Clock frequencies may be specified for the hardware resources of the domain. The system, in response to receiving such properties, assigns the properties to the domain and/or to the relevant hardware resources of the domain.

In block <NUM>, the system is capable of generating configuration data that implements the domain. The configuration data is capable of isolating the domain within the SoC. The configuration data, for example, may be data that is loaded into configuration registers for the particular isolation circuits used to regulate access to the particular hardware resources assigned to the domain. If, for example, the domain includes APU <NUM>, the configuration data generated in block <NUM> may be for isolation circuits <NUM>-<NUM> and/or <NUM>-<NUM>. As noted, the isolation circuits of the SoC to create the domains and enforce isolation between the domains once configured.

In block <NUM>, the system determines whether there are more resources to be added to the domain. For example, the user may provide an input indicating that the domain is complete. In another example, the user may provide an input indicating that additional resources are to be added to the domain. In response to determining that more resources are to be added to the domain, method <NUM> loops back to block <NUM> to add more resources to the domain. In response to determining that no further resources are to be added to the domain, method <NUM> continues to block <NUM>.

In block <NUM>, the system configures the operating system of the domain. For example, the system is capable of partitioning RAM (e.g., off-chip RAM accessible via the memory controller) for the domain. As an example, for the current domain being configured, the operating system may be Linux. The version of Linux used for the current domain may be able to access up to <NUM> GB of RAM. The user may provide an input specifying that of the available RAM specified in the hardware description file, the domain created in blocks <NUM> and <NUM> is to be allocated <NUM> GB of RAM. During further iterations of method <NUM> when configuring a different domain, further portions of RAM may be allocated to such other domains having different processors and/or operating systems.

As part of block <NUM>, the system is further capable of determining the devices that have been added to the domain and including a driver for each particular device. For example, if the domain includes a UART (e.g., UART0), another UART (e.g., UART1), and a USB interface, the system is capable of selecting drivers for each particular type (and instance) of device selected for inclusion in the domain and for the particular operating system that has been selected for the domain. Referring to the prior example where Linux is the operating system for the domain, the system chooses the Linux version of the driver for each device added to the domain.

As part of block <NUM>, the system further may generate an image file for the operating system of the domain. Continuing with the prior example, the system generates a Linux image file that is configured to access only <NUM> GB of RAM and which includes Linux drivers for each of the devices included in the domain.

In block <NUM>, the system determines whether to add another domain for the SoC. For example, the user may provide a user input requesting the creation of another domain. The user input may be provided via any of the mechanisms described herein whether through a GUI, wizard, and/or a command line. The user may also provide an input indicating that no further domains are to be created. If another domain is to be added, method <NUM> loops back to block <NUM> where further domain is created and processing continues. If no further domains are to be created, method <NUM> continues to block <NUM>.

In block <NUM> the system is capable of generating a platform. The platform includes one or more software artifacts that support the domains created for the SoC. In one or more embodiments, the platform includes a first stage boot loader type of software artifact. The first stage boot loader is a program that may be loaded into the SoC at boot time. For example, the first stage boot loader may be included in a boot image that may be loaded into the SoC. The system is capable of generating the first stage boot loader and include the configuration data generated in block <NUM> for each of the domains created.

The boot sequence of the SoC is capable of running the first stage boot loader in response loading the first stage boot loader and/or the boot image into the SoC. The first stage boot loader, in response to execution within the SoC, is capable of performing a variety of different functions. In one aspect, the first stage boot loader is capable of initializing the hardware resources and configuration registers within the processor system of the SoC.

In another aspect, the first stage boot loader is capable of configuring the architecture of the SoC. For example, the first stage boot loader is capable of configuring the processor system of the SoC by writing configuration data for the processor system to the appropriate configuration registers of the SoC. The configuration data specifies operational settings for the various hardware resources included in the processor system to implement each of the domains concurrently. Further, the configuration data includes the configuration data for the isolation circuits in the processor system. As such, the first stage boot loader, when loaded into the heterogeneous SoC, implements the domains and isolates the domains that have been defined.

In another aspect, the first stage boot loader is capable of loading a configuration bitstream that may be included in the boot image into configuration memory of the SoC. Loading a configuration bitstream as described implements physical circuitry within the programmable circuitry of the SoC that is defined by the configuration bitstream.

In one or more embodiments, a software artifact generated by the system includes a processor initialization file. In particular embodiments, the processor initialization file may be a "C configuration file. " The processor initialization file may include system initialization code for the processor system. The processor initialization file may include register sequences such as, for example, mask_write, mask_poll, and mask_read. The processor initialization file may be generated based upon user input specifying the processor system configuration. The processor initialization file is included in the first stage boot loader application. When a user creates a domain and assigns hardware resources to the domain such as memory, a UART, etc., the isolation circuitry needs to be reconfigured. The configuration register sequence for the isolation circuitry will change. These changes, e.g., the configuration register sequence for the isolation circuitry, may be part of the processor initialization file.

In one or more embodiments, the platform includes one or more operating system type software artifacts. For example, the system is capable of generating one or more operating system artifacts for each of the domains that have been created for the platform. In creating the operating system artifacts, any settings and/or properties specified within block <NUM>, for example, for resources added to the domains are honored.

An example of an operating system artifact that may be generated as part of block <NUM> is a device tree. The system is capable of generating a device tree for the operating system of each of the domains that have been created and that utilize a device tree. The device tree that is generated honors the settings, address ranges, and/or properties specified in block <NUM>. The device tree for a given domain will only include the hardware resources allocated or assigned to that domain. As such, the operating system will only "see" the devices listed in the device tree, which corresponds to the devices available in the domain.

In one or more embodiments, the platform includes software artifacts such as one or more data structures and/or files that specify information about the configuration of the SoC and the domains included therein. The platform, or particular software artifacts, is loaded into an application development environment (e.g., an application executing in a computing system). The application development environment is configured to develop applications and/or programs that are intended to run on the domains of the SoC. In that case, when a software developer uses the application development environment to create a program for a domain, the software artifacts specifying information about the configuration may be imported and used for application development purposes.

A software artifact that is imported into an application development environment is a linker script. The system is capable of generating a linker script for each of the domains and outputting the linker scripts and software artifacts. In general, each linker script controls operation of the linker for generating executable applications for a particular domain of the SoC. For example, the linker script for a particular domain is capable of mapping input files into an output file and controlling the memory layout of the output file given the established properties of the domain, e.g., addressable memory of the domain and the like. In using the linker scripts, for example, the application being assembled is unable to see any portions of memory that are not available to the domain executing the application being developed. The application is only able to see or access those portions of memory (e.g., RAM) that are assigned to the domain.

For example, when a software developer opens the application development environment and loads the platform, the software developer may specify a particular domain of the platform for which an application is to be developed. The application development environment is capable of making any software artifacts for the specified domain available to the software developer. As an illustrative and nonlimiting example, each different operating system will utilize particular driver calls based upon the operating system of the domain and the devices that are included in the domain. In developing an application for a domain that uses FreeRTOS, for example, the software development environment may translate particular statements (e.g., "print" statements) directed to a particular device into driver calls for that device. If for example an application for a domain attempts to write data via UARTO, and UART0 is part of the domain, the application development environment is capable of replacing statements accessing UARTO, e.g., "print" statements, with device driver calls for UART0. If the application includes statements that attempt to access a device that is not included in the domain, then a build of the application will fail. For example, if the application includes a print statement directed to a UARTO, but UART0 is not included in the domain, a build operation of the application will fail.

In other cases, if a software developer knows the address of a device that is not in the domain for which an application is being developed and writes program code to access that address (e.g., manually specifies such address), when the application is executed in the SoC, the isolation circuit(s) included therein will reject such transactions directed to hardware resources that are not part of the domain of the application.

The inventive arrangements allow a software developer to try different combinations of processors, devices, and/or operating systems without having to utilize hardware development tools to redefine domains for a given heterogeneous SoC. Using tool as described herein, a software developer is capable of defining domains and also redefining domains while using the same hardware description file generated from the hardware design application. The ability to specify domains at the software level rather than at the hardware level (e.g., using a hardware design application) allows the software developer to modify and/or redefine domains in significantly less time than would otherwise be the case. Each time the software developer makes a modification to the domain(s), the domain creation tool is capable of outputting an updated version of the platform.

The application developer, for example, may modify the platform through the GUI and/or via the command line interface. The application developer, for example, may adjust memory partitioning among the domains, change the operating system of a domain, and/or reassign devices among the domains. Upon completing the modifications and/or in response to a command to generate the platform, the domain creation application generates the updated platform implementing the modifications. The updated platform is generated based upon the original hardware description file as opposed to a modified hardware description file regenerated in the hardware design application.

The resulting platform, e.g., the first stage boot loader, may be included within a boot image. The boot image may also include one or more configuration bitstreams and/or other executable program code for execution in the domains. As discussed, the executable program code (e.g., operating systems and/or applications for the domains) may be created using the inventive arrangements described herein and/or using software artifacts generated using the inventive arrangements described herein.

The boot image may be loaded into a target SoC and used to configure the target SoC. In response to loading the boot image, the first stage boot loader may be run as described. Further, the programmable circuitry may be configured by loading a configuration bitstream from the boot image. The executable program code (e.g., operating systems and/or applications) that may be included in the boot image may be loaded into appropriate memory regions or partitions for the respective domains and executed.

<FIG> illustrates an example architecture <NUM> for an IC. In one aspect, architecture <NUM> may be implemented within a programmable IC. For example, architecture <NUM> may be used to implement a field programmable gate array (FPGA). Architecture <NUM> may also be representative of an SoC type of IC (e.g., a heterogeneous SoC).

As shown, architecture <NUM> includes several different types of programmable circuit, e.g., logic, blocks. For example, architecture <NUM> may include a large number of different programmable tiles including multi-gigabit transceivers (MGTs) <NUM>, configurable logic blocks (CLBs) <NUM>, random-access memory blocks (BRAMs) <NUM>, input/output blocks (IOBs) <NUM>, configuration and clocking logic (CONFIG/CLOCKS) <NUM>, digital signal processing blocks (DSPs) <NUM>, specialized I/O blocks <NUM> (e.g., configuration ports and clock ports), and other programmable logic <NUM> such as digital clock managers, analog-to-digital converters, system monitoring logic, and so forth.

In some ICs, each programmable tile includes a programmable interconnect element (INT) <NUM> having standardized connections to and from a corresponding INT <NUM> in each adjacent tile. Therefore, INTs <NUM>, taken together, implement the programmable interconnect structure for the illustrated IC. Each INT <NUM> also includes the connections to and from the programmable logic element within the same tile, as shown by the examples included at the top of <FIG>.

For example, a CLB <NUM> may include a configurable logic element (CLE) <NUM> that may be programmed to implement user logic plus a single INT <NUM>. A BRAM <NUM> may include a BRAM logic element (BRL) <NUM> in addition to one or more INTs <NUM>. Typically, the number of INTs <NUM> included in a tile depends on the height of the tile. As pictured, a BRAM tile has the same height as five CLBs, but other numbers (e.g., four) also may be used. A DSP tile <NUM> may include a DSP logic element (DSPL) <NUM> in addition to an appropriate number of INTs <NUM>. An IOB <NUM> may include, for example, two instances of an I/O logic element (IOL) <NUM> in addition to one instance of an INT <NUM>. The actual I/O pads connected to IOL <NUM> may not be confined to the area of IOL <NUM>.

In the example pictured in <FIG>, a columnar area near the center of the die, e.g., formed of regions <NUM>, <NUM>, and <NUM>, may be used for configuration, clock, and other control logic. Horizontal areas <NUM> extending from this column may be used to distribute the clocks and configuration signals across the breadth of the programmable IC.

Some ICs utilizing the architecture illustrated in <FIG> include additional logic blocks that disrupt the regular columnar structure making up a large part of the IC. The additional logic blocks may be programmable blocks and/or dedicated circuitry. For example, two or more processor blocks depicted as PROC <NUM> and PROC <NUM> span several columns of CLBs and BRAMs.

In one aspect, PROC <NUM> and/or PROC <NUM> may be implemented as dedicated circuitry, e.g., as hardwired processors, that are fabricated as part of the die that implements the programmable circuitry of the IC. PROC <NUM> and/or PROC <NUM> may represent any of a variety of different processor types and/or systems ranging in complexity from an individual processor, e.g., a single core capable of executing program code, to an entire processor system having one or more cores, modules, co-processors, interfaces, or the like.

In another aspect, PROC <NUM> and/or PROC <NUM> may be omitted from architecture <NUM> and replaced with one or more of the other varieties of the programmable blocks described. Further, such blocks may be utilized to form "soft processor(s)" in that the various blocks of programmable circuitry may be used to form processors that can execute program code as is the case with PROC <NUM> and/or PROC <NUM>.

The phrase "programmable circuitry" refers to programmable circuit elements within an IC, e.g., the various programmable or configurable circuit blocks or tiles described herein, as well as the interconnect circuitry that selectively couples the various circuit blocks, tiles, and/or elements according to configuration data that is loaded into the IC. For example, circuit blocks shown in <FIG> that are external to PROC <NUM> such as CLBs <NUM> and BRAMs <NUM> are considered programmable circuitry of the IC.

As discussed herein, PROC <NUM> is capable of executing a first operating system, while PROC <NUM> is capable of executing a second and different operating system. Further, the devices available to each of PROC <NUM> and PROC <NUM> may be different and defined by the domains created by a first stage boot loader executed within architecture <NUM> at boot time.

In general, the functionality of programmable circuitry is not established until configuration data is loaded into the IC. A set of configuration bits may be used to program programmable circuitry of an IC such as an FPGA. The configuration bit(s) typically are referred to as a "configuration bitstream. " In general, programmable circuitry is not operational or functional without first loading a configuration bitstream into the IC. The configuration bitstream effectively implements a particular circuit design within the programmable circuitry. The circuit design specifies, for example, functional aspects of the programmable circuit blocks and physical connectivity among the various programmable circuit blocks.

Circuitry that is "hardwired" or "hardened," i.e., not programmable, is manufactured as part of the IC. Unlike programmable circuitry, hardwired circuitry or circuit blocks are not implemented after the manufacture of the IC through the loading of a configuration bitstream. Hardwired circuitry is generally considered to have dedicated circuit blocks and interconnects, for example, that are functional without first loading a configuration bitstream into the IC, e.g., PROC <NUM> and/or PROC <NUM>.

In some instances, hardwired circuitry may have one or more operational modes that can be set or selected according to register settings or values stored in one or more memory elements within the IC. The operational modes may be set, for example, through the loading of a configuration data into the IC. Despite this ability, hardwired circuitry is not considered programmable circuitry as the hardwired circuitry is operable and has a particular function when manufactured as part of the IC.

<FIG> is intended to illustrate an example architecture that may be used to implement an IC that includes programmable circuitry, e.g., a programmable fabric. For example, the number of logic blocks in a column, the relative width of the columns, the number and order of columns, the types of logic blocks included in the columns, the relative sizes of the logic blocks, and the interconnect/logic implementations included at the top of <FIG> are purely illustrative. In an actual IC, for example, more than one adjacent column of CLBs is typically included wherever the CLBs appear, to facilitate the efficient implementation of a user circuit design. The number of adjacent CLB columns, however, may vary with the overall size of the IC. Further, the size and/or positioning of blocks such as PROC <NUM> within the IC are for purposes of illustration only and are not intended as limitations.

For purposes of explanation, specific nomenclature is set forth to provide a thorough understanding of the various inventive concepts disclosed herein. The terminology used herein, however, is for the purpose of describing particular aspects of the inventive arrangements only and is not intended to be limiting.

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.

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 explicitly stated otherwise. For example, each of the expressions "at least one of A, B, and C," "at least one of A, B, or C," "one or more of A, B, and C," "one or more of A, B, or C," and "A, B, and/or C" means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B and C together.

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

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 a transitory, propagating signal per se. 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 foregoing. The various forms of memory, as described herein, are examples of computer readable storage media. A non-exhaustive list of more specific examples of a computer readable storage medium may include: a portable computer diskette, a hard disk, a RAM, a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an electronically erasable programmable read-only memory (EEPROM), a static random-access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, or the like.

As defined herein, the term "if" means "when" or "upon" or "in response to" or "responsive to," depending upon the context. Thus, the phrase "if it is determined" or "if [a stated condition or event] is detected" may be construed 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 "responsive to detecting [the stated condition or event]" depending on the context.

As defined herein, the term "responsive to" and similar language as described above, e.g., "if," "when," or "upon," means responding or reacting readily to an action or event. The response or reaction is performed automatically. Thus, if a second action is performed "responsive to" a first action, there is a causal relationship between an occurrence of the first action and an occurrence of the second action. The term "responsive to" indicates the causal relationship.

As defined herein, the terms "one embodiment," "an embodiment," "one or more embodiments," "particular embodiments," or similar language mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment described within this disclosure. Thus, appearances of the phrases "in one embodiment," "in an embodiment," "in one or more embodiments," "in particular embodiments," and similar language throughout this disclosure may, but do not necessarily, all refer to the same embodiment. The terms "embodiment" and "arrangement" are used interchangeably within this disclosure.

As defined herein, the term "processor" means at least one hardware circuit. The hardware circuit may be configured to carry out instructions contained in program code. The hardware circuit may be an integrated circuit. Examples of a processor include, but are not limited to, a central processing unit (CPU), an array processor, a vector processor, a digital signal processor (DSP), a programmable logic array (PLA), an ASIC, and a controller.

As defined herein, the term "output" means storing in physical memory elements, e.g., devices, writing to display or other peripheral output device, sending or transmitting to another system, exporting, or the like.

As defined herein, the term "real-time" means a level of processing responsiveness that a user or system senses as sufficiently immediate for a particular process or determination to be made, or that enables the processor to keep up with some external process.

As defined herein, the term "substantially" means that the recited characteristic, parameter, or value need not be achieved exactly, but that deviations or variations, including for example, tolerances, measurement error, measurement accuracy limitations, and other factors known to those of skill in the art, may occur in amounts that do not preclude the effect the characteristic was intended to provide.

The terms first, second, etc. may be used herein to describe various elements. These elements should not be limited by these terms, as these terms are only used to distinguish one element from another unless stated otherwise or the context clearly indicates otherwise.

A computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the inventive arrangements described herein. Within this disclosure, the term "program code" is used interchangeably with the term "computer readable program instructions. " Computer readable program instructions described herein may be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a LAN, a WAN and/or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge devices including edge servers.

Computer readable program instructions for carrying out operations for the inventive arrangements described herein may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language and/or procedural programming languages. Computer readable program instructions may include state-setting data. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a LAN or a WAN, or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some cases, electronic circuitry including, for example, programmable logic circuitry, an FPGA, or a PLA may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the inventive arrangements described herein.

Certain aspects of the inventive arrangements are 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, may be implemented by computer readable program instructions, e.g., program code.

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, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the operations specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operations to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart 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 inventive arrangements. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified operations.

In some alternative implementations, the operations noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. In other examples, blocks may be performed generally in increasing numeric order while in still other examples, one or more blocks may be performed in varying order with the results being stored and utilized in subsequent or other blocks that do not immediately follow. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, may be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements that may be found in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed.

Claim 1:
A method performed by a system, comprising:
receiving (<NUM>) a hardware description file (<NUM>, <NUM>) specifying a plurality of processors (<NUM>, <NUM>, <NUM>) and a plurality of hardware resources available within a heterogeneous System-on-Chip, SoC, (<NUM>), wherein the plurality of processors (<NUM>, <NUM>, <NUM>) are configured to execute program code and are available for use by a design for the heterogeneous SoC (<NUM>), and wherein the plurality of hardware resources are available for use by embedded applications;
creating (<NUM>) a plurality of domains (<NUM>, <NUM>, <NUM>, <NUM>) for the heterogeneous SoC (<NUM>), by including in each domain a processor from the plurality of processors (<NUM>, <NUM>, <NUM>) and assigning different hardware resources selected from the plurality of hardware resources to each of the different domains that are created;
assigning (<NUM>) an operating system to each domain;
generating (<NUM>) a platform comprising configuration data that, when loaded onto the heterogeneous SoC, implements the plurality of domains within the heterogeneous SoC (<NUM>) and implements logical separation between the plurality of domains,
using the platform to build the embedded applications for different domains of the plurality of domains within the heterogeneous SoC (<NUM>),
wherein the platform includes a plurality of files for the plurality of domains for use by a software development environment, wherein the plurality of files includes a linker script for each of the domains.