Chiplet arrangement modeling and / or verification

Abstract

A method (600) is proposed. Method (600) includes obtaining (610) an engineering plan and a chiplet layout hardware model. Method (600) further includes estimating (630) a microsystem hardware model based on hardware requirements and a hardware dataset describing the hardware resources of the chiplet layout, and simulating (640) the estimated microsystem hardware model by electronic simulation to provide one or more hardware capabilities. Method (600) further includes obtaining (650) a chiplet layout environment model, and estimating (660) a microsystem software model using hardware capabilities and software requirements. Method (600) further includes simulating (670) the estimated microsystem software model on the chiplet layout environment model to provide one or more software capabilities, and compiling (680) the estimated microsystem hardware model, the estimated microsystem software model, one or more hardware capabilities, and one or more software capabilities into a microsystem model including one or more microsystem capabilities.

Description

Technical Field

[0001] This disclosure relates to chiplets. More specifically, this disclosure relates to the architectural modeling, integration, and deployment of microservices deployed using chiplets. Background Technology

[0002] According to Moore's Law, the number of transistors in an integrated circuit (IC) doubles every two years. However, due to high costs, the pace of improvement in silicon manufacturing is slowing, and the commercial production of increasingly smaller chips is becoming increasingly challenging. Current development of monolithic chips faces not only economic constraints but also limitations related to supply and demand, flexibility, and competitiveness. Often, from the early design stages, the chip concept lacks the potential for future changes or development, thus hindering hardware reuse.

[0003] In response to this situation, chiplets have emerged as a promising solution. Typically, a chiplet is a modular semiconductor component configured to perform a specific function or subset of functions within a larger integrated circuit. Chipslets can be combined with other chiplets to form more complex integrated circuits, thus providing greater flexibility in design and manufacturing.

[0004] The concept of chiplets has existed for decades, with the first examples appearing in the 1980s. At that time, chiplets were primarily used for memory and I / O functions and were mounted on separate packages connected to the main processor via a bus interface. In recent years, chiplets have regained interest due to advancements in semiconductor packaging technology and the increasing complexity of modern electronic devices. By breaking down complex systems, or systems-on-a-chip (SoCs), into smaller, more manageable components, chiplets offer several advantages.

[0005] To facilitate chip adoption, industry organizations and standards bodies have developed interfaces and protocols for connecting and communicating between chips. Examples include the Semiconductor Industry Association's (SIA) Chipset Integration Interface (CII) and the Open Compute Project's (OCP) Advanced Interface Bus (AIB). Chipsets are a promising approach for designing and manufacturing complex semiconductor devices, offering greater flexibility, efficiency, yield, scalability, optimized performance, and reliability.

[0006] The design and manufacturing flexibility of chiplets facilitates the provision of hardware that can be configured to perform a wide variety of tasks. However, chiplets are a lock-in solution, such as creating a PCB that serves a specific task or function. Despite progress in standardization efforts, the full potential of chiplets has not yet been fully realized. Summary of the Invention

[0007] The purpose of this disclosure is to provide a novel method for modeling, simulating, and / or verifying reconfigurable hardware and software solutions, which outperforms existing technologies and eliminates or at least mitigates the aforementioned disadvantages. More specifically, the purpose of this disclosure is to provide a method for modeling microsystems and the associated production or consumption of microservices of such microsystems, executable at design time and / or runtime, for deployment on chiplet arrangements. These objectives are achieved by the techniques set forth in the appended independent claims and the preferred embodiments defined in the associated dependent claims.

[0008] In a first aspect, a method is proposed. This method can be computer-implemented. The method can be executed by a computer system. The method includes: optionally obtaining an engineering plan by a requirements acquirer, the engineering plan including hardware and software requirements for a microsystem for producing and / or consuming one or more microservices; optionally obtaining a chiplet layout hardware model by the requirements acquirer describing the electrical environment of the chiplet layout, wherein the chiplet layout is controllable by an external communication interface and includes at least one chiplet connected to a chiplet network, and wherein the at least one chiplet includes at least one hardware resource; estimating the microsystem hardware model based on the hardware requirements and a hardware dataset describing the hardware resources of the chiplet layout; optionally simulating the estimated model by a verifier using electronic simulation based on the chiplet layout hardware model. A microsystem hardware model to provide one or more hardware capabilities; optionally, a chiplet placement environment model describing the software environment of the chiplet placement is obtained by a requirements obtainer; optionally, a microsystem software model including one or more microservices produced and / or consumed is estimated by a verifier using hardware capabilities and software requirements; optionally, the verifier simulates the estimated microsystem software model on the chiplet placement environment model to provide one or more software capabilities; optionally, a deployer compiles the estimated microsystem hardware model, the estimated microsystem software model, one or more hardware capabilities, and one or more software capabilities into a microsystem model including one or more microsystem capabilities.

[0009] In one variant, the method further includes, optionally, having a verifier verify hardware capabilities based on hardware requirements, thereby providing hardware verification data. This is beneficial because it enables verification of the hardware side of the engineering plan prior to deployment.

[0010] In one variant, the method further includes providing alternative hardware capabilities and an estimated alternative microsystem hardware model for further processing by: estimating the alternative microsystem hardware model based on the estimated microsystem hardware model, hardware requirements, hardware dataset, and hardware capabilities including a model of available hardware resources on a chiplet layout; and simulating the estimated alternative microsystem hardware model via electronic simulation to provide one or more alternative hardware capabilities. This is advantageous because it enables the provision of multiple different hardware solutions based on the chiplet layout of the engineering plan.

[0011] In one variant, providing alternative hardware capabilities and estimated alternative microsystem hardware models for further processing is selectively performed based on hardware validation data. This is advantageous because alternative models are only provided if validation fails, which reduces modeling time.

[0012] In one variant, the method also includes verifying the capabilities of alternative hardware based on hardware requirements, thereby providing alternative hardware verification data. This is advantageous because it enables the provision of a variety of different hardware solutions through chiplet placement in the engineering plan.

[0013] In one variant, the method further includes selecting one of the microsystem hardware models or alternative microsystem hardware models as the microsystem hardware model for further processing, based on the processing of hardware verification data and alternative hardware verification data, prior to estimating the microsystem software model. This is advantageous because it enables optimization of the microsystem from a hardware perspective.

[0014] In one variant, the method also includes verifying software capabilities based on software requirements, thereby providing software verification data. This is beneficial because it enables verification of the software side of the engineering plan before deployment.

[0015] In one variant, providing alternative hardware capabilities and estimated alternative microsystem hardware models for further processing is selectively performed based on software verification data. This is advantageous because modeling time can be reduced by not modeling systems that do not meet the software requirements.

[0016] In one variant, the method further includes providing alternative software capabilities and an estimated alternative microsystem software model by: estimating the alternative microsystem software model using hardware capabilities and software requirements; and simulating the estimated alternative microsystem software model on a chiplet layout environment model to provide one or more alternative software capabilities. This is advantageous because it enables the provision of a variety of different software solutions based on the chiplet layout of the engineering plan.

[0017] In one variant, providing alternative hardware capabilities and estimated alternative microsystem software models for further processing is selectively performed based on software validation data. This is advantageous because alternative models are only provided if validation fails, which reduces modeling time.

[0018] In one variant, the method also includes verifying the capabilities of alternative software based on software requirements, thereby providing alternative software verification data. This is advantageous because it enables the provision of a variety of different hardware solutions through chiplet placement in the engineering plan.

[0019] In one variant, the method includes: prior to providing the estimated microsystem hardware model and the estimated microsystem software model as the microsystem model, selecting one of the microsystem software model or a candidate microsystem software model as the microsystem software model for further processing, based on the processing of software verification data and candidate software verification data. This is advantageous because it enables optimization of the microsystem from a software perspective.

[0020] In one variant, the software requirements include at least one compatibility constraint, at least one performance constraint, and / or at least one security constraint.

[0021] In one variant, hardware requirements include at least one physical constraint, at least one connectivity constraint, and / or at least one availability constraint.

[0022] In one variant, the chiplet layout environment model is a digital twin of the chiplet layout.

[0023] In one variant, the chiplet layout hardware model includes a hardware model of one or more chiplets in a chiplet layout.

[0024] In one variant, the chiplet layout hardware model includes a physical hardware device for one or more chiplets in a chiplet layout.

[0025] In one variant, the method also includes deploying a microsystem model on a chiplet arrangement.

[0026] In one variant, the method also includes estimating chiplet deployment utilization based on microsystem models and microsystem capabilities.

[0027] In a second aspect, a computer system including processing circuitry is proposed, the processing circuitry being configured to execute the method of the first aspect.

[0028] In a third aspect, a method for formal verification of a chiplet arrangement configured with a control plane is proposed. This method can be computer-implemented. The method includes: optionally obtaining a mathematically defined chiplet arrangement hardware model by a receiver, the mathematically defined chiplet arrangement hardware model including a mathematical description of the electrical environment of the chiplet arrangement, wherein the chiplet arrangement is controllable by an external communication interface and includes at least one chiplet connected to a chiplet network, and wherein the at least one chiplet includes at least one hardware resource; optionally obtaining a mathematically defined chiplet arrangement environment model by a receiver, the mathematically defined chiplet arrangement environment model including a mathematical definition of the software environment of the chiplet arrangement, wherein the software environment includes a chiplet control plane configured with: a resource orchestrator, configured to orchestrate one or more microsystems instantiated with the chiplet arrangement, each microsystem including at least one hardware resource. Addressable connectivity at the resource and chiplet network; and a network manager configured to control communication between the microsystems of the chiplet deployment and the external communication interface by exposing one or more microsystems as microservices at the external communication interface; optionally, one or more mathematically defined chiplet deployment requirements are obtained by the acquirer, the one or more mathematically defined chiplet deployment requirements including one or more hardware requirements of the chiplet deployment or software requirements of the software environment of the chiplet deployment; optionally, the chiplet deployment environment model on the chiplet deployment hardware model is verified by the verifier through mathematical proof that the chiplet deployment environment model on the chiplet deployment hardware model satisfies the chiplet deployment requirements; and optionally, the chiplet deployment environment model is deployed on the chiplet deployment by the deployer.

[0029] In one variant, at least one of the chiplet placement hardware model and the chiplet placement environment model is a fully mathematically defined model.

[0030] In one variant, the method further includes: obtaining one or more non-mathematically defined chiplet placement requirements, the one or more non-mathematically defined chiplet placement requirements including one or more hardware requirements for the chiplet placement; and verifying that the chiplet placement with the chiplet placement environment model deployed meets the non-mathematical chiplet placement requirements.

[0031] In one variant, the method further includes: obtaining one or more non-mathematically defined chiplet layout requirements described in natural language; and converting the non-mathematically defined chiplet layout requirements into mathematically defined chiplet layout requirements.

[0032] In the fourth aspect, a computer system including processing circuitry is proposed, which is configured to execute the method of the third aspect.

[0033] Fifthly, a computer implementation method for formal verification of a microsystem with a chiplet arrangement configured with a control plane is proposed. The method includes: optionally, an acquirer obtains an engineering plan including mathematical definitions of hardware and software requirements for a microsystem to produce and / or consume one or more microservices; optionally, the acquirer obtains a mathematically defined chiplet arrangement hardware model including mathematical definitions of the electrical environment of the chiplet arrangement, wherein the chiplet arrangement is controllable by an external communication interface and includes at least one chiplet connected to a chiplet network, and wherein the at least one chiplet includes at least one hardware resource; optionally, the acquirer determines the mathematically defined microsystem hardware model based on a hardware dataset of hardware requirements and the mathematically defined hardware resources of the chiplet arrangement; optionally, a verifier verifies the microsystem hardware model based on the chiplet arrangement hardware model to provide mathematical definitions of one or more hardware capabilities; optionally, the acquirer obtains a mathematical... A defined chiplet placement environment model, the mathematically defined chiplet placement environment model including a mathematical definition of the software environment of the chiplet placement; optionally, a acquirer uses hardware capabilities and software requirements to determine a mathematical definition of a microsystem software model including one or more microservices produced and / or consumed; optionally, a verifier verifies the estimated microsystem software model on the chiplet placement environment model to provide a mathematical definition of one or more software capabilities; optionally, a acquirer determines a microsystem model based on a mathematically defined microsystem hardware model, a mathematically defined microsystem software model, one or more mathematically defined hardware capabilities, and one or more mathematically defined software capabilities, the microsystem model including one or more microsystem capabilities that can be exposed as microservices at external communication interfaces of the chiplet placement; and optionally, a deployer deploys the microsystem model on the chiplet placement.

[0034] In the sixth aspect, a computer system including processing circuitry is proposed, the processing circuitry being configured to execute the method of the fifth aspect.

[0035] In a seventh aspect, a chiplet arrangement controllable by an external communication interface is proposed. The chiplet arrangement includes at least one chiplet connected to a chiplet network, wherein the at least one chiplet includes at least one hardware resource; and wherein the chiplet arrangement is provided with a chiplet control plane, the chiplet control plane including: a resource orchestrator configured to instantiate one or more microsystems having corresponding associated microservices of the chiplet arrangement, wherein each microsystem includes at least one hardware resource and a specific addressable connection at the chiplet network; and a network manager configured to control communication between the microsystems of the chiplet arrangement and the external communication interface by exposing the microservices associated with the corresponding microsystems at the external communication interface.

[0036] The disclosed aspects, examples (including any preferred examples), and / or appended claims may be suitably combined with each other, as will be apparent to those skilled in the art. Additional features and advantages are disclosed in the following specification, claims, and drawings, and will be apparent in part from this disclosure, or may be recognized by practice of this disclosure as described herein. Attached Figure Description

[0037] Embodiments of the invention will be described below with reference to the accompanying schematic diagrams, which illustrate non-limiting examples of how the inventive concept can be put into practice.

[0038] Figure 1 This is a schematic diagram of a chip arrangement based on some examples of this disclosure;

[0039] Figure 2 This is a schematic diagram of a small chip according to some embodiments of the present disclosure;

[0040] Figure 3 This is a schematic diagram of a microsystem associated with microservices according to some embodiments of this disclosure;

[0041] Figure 4 This is a schematic diagram of a chip arrangement based on some examples of this disclosure;

[0042] Figure 5 This is a schematic diagram of a control plane according to some embodiments of the present disclosure;

[0043] Figure 6 This is a schematic diagram of a microsystem model with chiplet arrangements based on some examples of this disclosure;

[0044] Figure 7 This is a schematic diagram of a method according to some embodiments of the present disclosure;

[0045] Figure 8 This is a schematic diagram of a method according to some embodiments of the present disclosure;

[0046] Figure 9 These are schematic diagrams of computer systems based on some examples of this disclosure;

[0047] Figure 10 It is a hierarchical diagram of the exemplary chiplet layout environment model based on the example;

[0048] Figure 11 This is a SysML sequence diagram of a dynamically instantiated microsystem according to some embodiments of the present disclosure;

[0049] Figure 12 This is a timeline diagram of the lifecycle of the chiplet layout based on the example;

[0050] Figure 13 This is a schematic diagram of a computer program product based on an example;

[0051] Figure 14 This is a schematic diagram of a computer program being loaded onto a chiplet arrangement, based on an example; and

[0052] Figure 15 This is a schematic diagram illustrating the loading of a computer program onto a computer system according to an example. Detailed Implementation

[0053] In the following description, certain embodiments will be described more fully with reference to the accompanying drawings. However, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey to those skilled in the art the scope of this disclosure (e.g., as defined in the appended claims).

[0054] Unless otherwise defined, all terms used herein, including technical and scientific terms, shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that the terms used herein should be interpreted in accordance with their meaning in the context of this specification and related art, and not in an ideal or overly formal sense, unless so expressly defined herein.

[0055] The term “coupled” is defined as a connection, although not necessarily a direct connection and not necessarily a mechanical connection. Similarly, the terms “connected” or “operably connected” are defined as a connection, although not necessarily a direct connection and not necessarily a mechanical connection. Two or more “coupled” or “connected” items may be integral with each other. Unless expressly required otherwise in this disclosure, the terms “a” and “an” are defined as one or more. The terms “basically,” “generally,” and “about” are defined as substantially but not necessarily fully specified, as understood by one of ordinary skill in the art. The terms “comprising” (and any form thereof), “having” (and any form thereof), “including” (and any form thereof), and “containing” (and any form thereof) are open-ended conjunctions. Thus, a method that “comprising,” “having,” “including,” or “containing” one or more steps has, but is not limited to, having only that one or more steps.

[0056] In the following description, certain embodiments will be described more fully with reference to the accompanying drawings. However, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey to those skilled in the art the scope of this disclosure (e.g., as defined in the appended claims).

[0057] Similarly, the term "connection" or "operably connected" is defined as a connection, although not necessarily a direct connection and not necessarily a mechanical connection. Two or more "coupled" or "connected" items may be integral with each other. Unless otherwise expressly required by this disclosure, the terms "a" and "an" are defined as one or more. The terms "substantially," "generally," and "approximately" are defined as largely but not necessarily fully specified, as understood by one of ordinary skill in the art. The terms "comprising" (and any form thereof), "having" (and any form thereof), "including" (and any form thereof), and "containing" (and any form thereof) are open-ended conjunctions. Thus, a method that "comprising," "having," "including," or "containing" one or more steps has, but is not limited to, having only those one or more steps.

[0058] For the purposes of this disclosure, a chiplet is typically a micro-integrated circuit (IC) comprising a well-defined subset of functions. It is designed to be combined with other chiplets to form a chiplet arrangement. The chiplet arrangement may (but is not required to) be situated on a common interposer layer within a single package. Chipslets in a chiplet arrangement are interconnected via network structures exemplified by, for example, but not limited to, currently known structures such as AIB, PCIe, and UIB (Intel-led chiplet bus standard). It should be noted that chiplet-to-chiplet communication can be direct or indirect (i.e., via one or more other chiplets). A chiplet can be configured with virtually any hardware (and optionally, software) functionality. A chiplet may include or be composed of configurable hardware such as complex programmable logic devices (CPLDs) and / or field-programmable gate arrays (FPGAs).

[0059] Chipsetting offers several advantages over large-scale integrated circuits (ICs). Because chipsetting separates different functions into discrete chips, it makes it easier to isolate and fix defects during manufacturing. This can result in higher overall yields and lower costs. By mixing and matching different chiplets, designers can create custom chipsetting arrangements in the form of System-on-Chip (SoC) optimized for specific applications. This can lead to more efficient, higher-performance devices. By using smaller, more manageable chiplet components, designers can iterate faster and test individual components more thoroughly before integrating them into a larger system of chipsets. Designers can also dynamically add or remove components from the SoC if needed. This allows design engineers to easily scale the performance and complexity of the entire system. Chipsets enable companies to leverage economies of scale and reuse existing chip designs, reducing the cost of new development. Chipsets support a wide range of applications, from high-power (servers in data centers) to battery-powered devices (smartwatches). The philosophy behind chiplets allows for interoperability between different chiplet vendors. This can lead to improved performance compared to a single monolithic chip solution.

[0060] From a hardware perspective, chiplet configurability has historically been separate from its corresponding software configurability. The software functionality of a chiplet is typically limited to the capabilities provided by each individual chiplet. Each chiplet is addressed using a hardware abstraction layer (HAL) typically specific to that chiplet. To allow for full flexibility in chiplets and also improve the resource utilization of the SoC, the inventors of this disclosure have realized that chiplets or collections of chiplets can be shared and utilized using multiple microsystems and the associated production and / or consumption of microservices by those microsystems.

[0061] Microservices are typically a software architectural approach where large applications are broken down into small, independent, and loosely coupled services that can be developed, deployed, and maintained independently. Each microservice typically performs a specific function (e.g., business logic) and communicates with other microservices via lightweight mechanisms such as HTTP messaging protocols (MQTT, CoAP, etc.). This approach allows for faster and more efficient development, deployment, and scaling of applications, as well as improved resilience and fault tolerance. Microservices also enable teams to work independently on different parts of the application, with each team responsible for developing and maintaining its own microservice. This approach can improve overall development speed and reduce the risk of conflict or dependencies between teams. Overall, microservices can provide greater flexibility, scalability, and reliability in large and complex information systems / computer systems.

[0062] Historically, microservices have been designed to be deployed as independent, lightweight components capable of running on distributed systems on commodity hardware. This allows for greater scalability and fault tolerance compared to running monolithic applications on a single server or server cluster. A common hardware configuration for microservices is cloud-based infrastructure. A common choice is to deploy microservices in the cloud using services such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP). These cloud providers offer a variety of services and tools for running and managing microservices, including container orchestration platforms such as Kubernetes. Alternatively, microservices can also run on virtual machines (VMs) using hypervisors such as VMware or Hyper-V. This allows for greater flexibility in deploying and scaling microservices across different hardware configurations. In some cases, microservices can be deployed on edge devices such as Internet of Things (IoT) devices or embedded systems. This requires a lightweight runtime environment capable of running on resource-constrained hardware.

[0063] Microservices are generally considered to have evolved from Service-Oriented Architecture (SOA) and are often viewed as an equivalent or subset of SOA. Microservices and SOA share many attributes provided by that architecture and critical to its operation, such as non-functional requirements. For example, a system can discover services at runtime without fixing their addresses at design time. This is typically achieved through some type of service registry where service producers advertise their services, allowing consumers to find them even in dynamic environments. Services often communicate only through designed APIs, embodying the concept of information hiding and encapsulation. In this way, services do not share dependencies with each other and can be modified internally as needed without affecting the behavior of other services. Furthermore, service exchange typically occurs at runtime and can change based on the current state. Therefore, services do not need to be aggregated before deployment as early as binding, enabling self-healing and optimization of the application within the execution environment. These capabilities require more logic that can be added to each system or delegated to intermediaries that will organize the network.

[0064] Figure 1 A simplified diagram of chiplet arrangement 100 is shown. Chiplet arrangement 100 includes multiple chips 110a, 110b, 110c, 110d, and 110e. Figure 1The disclosed chiplet arrangement 100 includes multiple chips 110a, 110b, 110c, 110d, and 110e, i.e., two or more chips. However, those skilled in the art will understand that the chiplet arrangement 100 may sometimes include a single chiplet 110a, 110b, 110c, 110d, and 110e. Chips 110a, 110b, 110c, 110d, and 110e are connected via a chiplet network 120, thereby enabling communication between chips 110a, 110b, 110c, 110d, and 110e. The chiplet arrangement 100 can be controlled by an external interface 150, thereby enabling the chiplet arrangement 100 to control, be controlled by, or otherwise interact with one or more external systems 10. Chipsets 110a, 110b, 110c, 110d, and 110e of chipset arrangement 100 may all be arranged on a common interposer layer 130 and optionally form a chip package 140. In other examples of this disclosure, chipset arrangement 100 may include multiple chips 110a, 110b, 110c, 110d, and 110e arranged on different interposers 130 and / or forming different chipset packages 140. Regardless of the arrangement or number of chips 110a, 110b, 110c, 110d, and 110e, chips 110a, 110b, 110c, 110d, and 110e are connected via chipset network 120. Chipset arrangement 100 according to this disclosure may be referred to as one or more of a multi-chip module (MCM), hybrid IC, 2.5D IC, or advanced package.

[0065] Chiplet network 120 can be any suitable network or corresponding connection capable of enabling communication between chips 110a, 110b, 110c, 110d, and 110e and / or between chips 110a, 110b, 110c, 110d, and 110e and external interface 150. In some examples, chiplet network 120 can be a network configured according to one or more network standards such as UCIe, Bundle Wire (BoW), OpenHBI, or OIF XSR. Chiplet network 120 is not necessarily formed by a single physical or virtual network, but can be a combination of one or more physical networks and / or one or more virtual networks. This will be further explained in later sections.

[0066] exist Figure 1The diagram illustrates a chiplet arrangement 100 comprising five chips 110a, 110b, 110c, 110d, and 110e. This is for illustrative purposes only, and those skilled in the art will understand that the chiplet arrangement 100 may include any number of chips 110a, 110b, 110c, 110d, and 110e. Indeed, as will be apparent from the above and upon reading the full disclosure, the teachings presented herein also apply to individual chips 110a, 110b, 110c, 110d, and 110e.

[0067] Those skilled in the art will understand that the chiplets 110a, 110b, 110c, 110d, 110e, chiplet arrangement 100, and other features presented herein may be presented in a simplified and / or abbreviated form to make this disclosure as efficient as possible. For example, Figure 1 The small chip arrangement 100 typically requires some form of power distribution to provide power and / or control power to chips 110a, 110b, 110c, 110d, and 110e. These features and configurations are known to those skilled in the art and do not require further explanation.

[0068] exist Figure 2 The diagram shows an exemplary simplified block diagram of chip 110. Chip 110 includes at least one hardware resource 112a, 112b, 112c. Figure 2 Chip 110 is shown as having three hardware resources 112a, 112b, and 112c, but any number of hardware resources are applicable. At least one of the hardware resources 112a, 112b, and 112c of chip 110 is addressable at chip network 120. For this purpose, the first hardware resource 112a may be a network interface hardware resource configured to connect chip 110 to and communicate via chip network 120. The second hardware resource 112b may be a computing hardware resource such as a CPU, GPU, or microcontroller. The third hardware resource 112c may be a data storage unit, i.e., a memory hardware resource such as volatile or non-volatile memory. Chip 110, including network interface hardware resources, computing hardware resources, and memory hardware resources, can be considered as a minimum chip 110. However, not all hardware resources 112a, 112b, and 112c can be addressed through the chiplet network 120, and from the perspective of the chiplet arrangement 100, a particular chiplet 110 may only include computing hardware resources as the only addressable resources of that particular chiplet 110.

[0069] Chip 110 may include additional hardware resources 112a, 112b, and 112c, such as, but not limited to, sensor hardware resources. Sensor hardware resources (i.e., data acquisition units) may be exemplified as temperature sensors, pressure sensors, light sensors, optical sensors, voltage sensors, fingerprint sensors, etc. Additionally or alternatively, chip 110 may include hardware resources 112a, 112b, and 112c in the form of peripheral hardware resources. Peripheral hardware resources may be exemplified as, but not limited to, interrupt controllers, DMA controllers, digital / analog I / O, DACs, ADCs, clocks, peripheral I / O devices, peripheral storage devices, peripheral display devices, peripheral communication devices, etc. Additionally or alternatively, chip 110 may include hardware resources 112a, 112b, and 112c in the form of communication hardware resources. Communication hardware resources may be exemplified as, but not limited to, PCIe interfaces or UCIe interfaces. Additionally or alternatively, chip 110 may include hardware resources 112a, 112b, and 112c in the form of actuator hardware resources. Actuator hardware resources can be exemplified as, but are not limited to, speakers, buzzers, soft switches, light sources, displays, etc.

[0070] It should be mentioned that each hardware resource 112a, 112b, 112c may be associated with one or more properties (e.g., capabilities, specifications, etc.). These properties may be provided by, for example, the vendor or supplier of the hardware resources 112a, 112b, 112c. In some examples, some or all of the hardware resources 112a, 112b, 112c may be associated with a model of the hardware resources 112a, 112b, 112c, which can be used for the simulation of the hardware resources 112a, 112b, 112c.

[0071] The inventors of this disclosure have realized that the chiplet 110 can not only deploy and execute microservices, but also that the chiplet 110 itself can be managed and controlled in correspondence with the microservices. That is, the hardware resources 112 of one or more chiplets 110 can be configured to form a microsystem 200, see [link to relevant documentation]. Figure 3 .

[0072] exist Figure 3The diagram illustrates a microsystem 200 according to this disclosure. Microsystem 200 provides behavior based on stored or acquired data and its computations. The resulting capabilities are exposed externally through one or more produced microservices 400. Microsystem 200 comprises one or more hardware resources 112 (e.g., including or configured with one or more hardware resources 112), which perform one or more tasks and processes to form a function. A particular microsystem 200 may be associated with one or more hardware resources 112 from a particular chiplet 110 in a chiplet arrangement 100, or with hardware resources 112 from two or more chiplets 110 in the chiplet arrangement 100. As will be taught later, microsystem 200 can be dynamically instantiated and subsequently reused at runtime. This enables flexible use and reuse of the occupied hardware resources 112. Microsystem 200 may include configurable or static software (program instructions) stored and executable by the hardware resources of microsystem 200. It should be mentioned that the microsystem 200 is defined solely by hardware resources 112 and can provide the desired functionality without the need for software.

[0073] The orchestration of microsystem 200 is provided by control plane 300. The orchestration of one or more microsystems 200 by control plane 300 may include, but is not limited to, managing microsystem 200, coordinating the deployment of microsystem 200, scaling microsystem 200, and / or controlling the operation of microsystem 200. Control plane 300 is also advantageously configured to orchestrate microservices 400 exposed at external communication interface 150. The orchestration of one or more microservices 400 by control plane 300 may include, but is not limited to, managing microservices 400, coordinating the deployment of microservices 400, scaling microservices 400, and / or controlling the operation of microservices 400. Control plane 300 is also advantageously configured to orchestrate bindings (associations) between a specific microsystem 200 and one or more microservices 400.

[0074] Advantageously, microservice 400 registers with an external resource registry associated with external system 10. This registration of microservice 400 with the external resource registry of external system 10 can be provided by control plane 300. One or more microsystems 200 may provide software instructions enabling them to register their associated microservice 400 with the external resource registry of external system 10 (via control plane 300).

[0075] For the chiplet arrangement 100, the control plane 300 can be configured as a centralized control plane, and will generally be described as such. However, it should be emphasized that this disclosure also applies to, but is not limited to, decentralized or distributed implementations of the control plane 300.

[0076] To illustrate the functionality of the control plane, control plane 300 can be configured to discover and manage available hardware resources 112 and microsystems 200. This means monitoring resource usage and availability, and allocating and releasing resources as needed. Control plane 300 can be additionally or alternatively configured to deploy and manage microservices 400 on available hardware resources 112 by associating with microsystems 200. This means ensuring that each microservice 400 is deployed in the appropriate location and can communicate with other microservices 400 as needed. Control plane 300 can be additionally or alternatively configured to provide service scaling. That is, as the demand for a particular microservice 400 increases or decreases, control plane 300 can be configured to scale the microservice 400 up or down accordingly. This can involve adding or removing instances of microservice 400, and / or adjusting the microsystems allocated to each instance of microservice 400. Control plane 300 can be additionally or alternatively configured to provide health monitoring of chiplet arrangement 100. This can include monitoring the health of each microservice 400 and / or microsystem 200, and detecting and responding effectively to failures or other issues. This may involve performing automated health checks, restarting failed microsystems 200 and / or microservices 400, and / or triggering alert notifications when problems occur. The control plane 300 may be additionally or alternatively configured to manage updates to microservices 200 and / or microsystems 400 to ensure that new versions of services are deployed and rolled out in a controlled and secure manner.

[0077] A control plane 300 is provided by using an SOA approach, which can be created by a set of microsystems 200 with associated microservices 400. Figure 4 This is illustrated schematically. It can be assumed that control plane 300 is locally instantiated and executed at each of the 100 chiplets.

[0078] refer to Figure 4 This will present an exemplary embodiment of a chiplet arrangement 100, including a favorable control plane 300. Figure 4In this context, the control plane 300 includes a resource orchestrator 410. The resource orchestrator 410 can be configured to orchestrate and coordinate the integration and instantiation of the microsystem 400 and its producing and consuming microservices 200. Microsystem integration can be requested by the resource orchestrator 410, which is exposed as the associated microservice 410 at the external communication interface 150. This integration request can indicate which hardware resources 112 of the chiplet layout 100 should be integrated, and, if applicable, provide any suitable microsystem executable code. Additionally, lifecycle data, ranging from the completion of the first service request to the maximum lifecycle, can be provided. The maximum lifecycle can be determined by the edge or cloud ServiceRegistry and SystemRegistry that the microsystem may need to register with. Advanced security deployment schemes can be deployed if needed, which will be further explained in later sections. It should be noted that the microsystem 200 of the chiplet layout 100 is not necessarily static. That is, the microsystem 200 can be configured as a static structure, a dynamic structure, a fluid structure, a flexible layout, an evolving structure, or a combination thereof. The orchestration of microsystem 200 can be dynamically updated, upgraded, or changed through new requests to resource orchestrator 410. The resource orchestrator can provide orchestration information to network manager 440 of control plane 300. This functionality can be provided to configure appropriate communication between integrated hardware resources 112. Service integration requests typically integrate and instantiate microsystem 200 consisting of a defined set of hardware resources 112 (e.g., CPU, timers, memory, ADC, etc.).

[0079] Resource orchestrator 410 may include pre-configured microsystems 200 of chiplet arrangement 200, which are associated with one or more pre-configured microservices 410 of chiplet arrangement 100. That is, the resource orchestrator can be pre-configured. Figure 4 In the diagram, resource orchestrator 410 is shown as microservice 400. Those skilled in the art will understand that microservice 410 is associated with a specific microsystem 200. Microservice 400 will be exposed through control plane 300, and control plane 300 will provide the interface between microservice 400 and the specific microsystem 200.

[0080] exist Figure 4 In this diagram, control plane 300 is also shown to include resource scheduler 420. Resource scheduler 420 can be provided to ensure the timely availability of the desired microsystem 200. Scheduling hardware resources is advantageous in order to achieve the requested performance and obtain the maximum benefit from the potential of the chiplet arrangement 100. The resource scheduler is advantageously configured to balance stringent real-time requirements with other types of priorities and / or strategies. Those skilled in the art will understand that such scheduling depends on application strategies, policies, regulations, etc. A wide range of such scheduling algorithms are available and have been previously published. 1(All references in the footnotes are incorporated herein to provide context for embodiments of this disclosure.) 1 S. Singh and I. Chana, "A survey on resource scheduling in cloud computing: Issues and challenges", Journal of Grid Computing, No. DOI 10.1007 / s10723-015-9359-2, pp.217–264, 2016. "Cloud computing resources cheduling and a survey of its evolutionary approaches" by Z.-H.ZHAN, "Acomprehensive survey for scheduling techniques in cloud computing" by M. Kumar, SC Sharma, A. Goel, and SP Singh, Journal of Network and Computer Applications, vol. 143, pp. 1–33, 2019). Therefore, resource scheduling can be viewed as an engineering optimization problem, and will not be discussed further in this disclosure.

[0081] It should be mentioned that the resource scheduler 420 can reside either inside or outside the chiplet arrangement 100. Figure 4 In this diagram, the resource scheduler 420 is shown inside the chiplet arrangement 100, but this is only an alternative and other implementations may be considered depending on the application.

[0082] For resource orchestrator 410, resource scheduler 420 can be pre-configured. Figure 4 In this context, resource scheduler 420 is shown as microservice 400, but those skilled in the art will understand that microservice 400 is associated with a specific microsystem 200.

[0083] Figure 4An exemplary control plane 300 includes a resource registry 430. The resource registry 430 can be configured to store data associated with the hardware resources 112 of the chiplet arrangement 100. Advantageously, this data includes information indicating one or more of the following: a resource ID for each hardware resource 112, a physical address for each hardware resource 112 of the chiplet arrangement 100, and / or an electronic address for each hardware resource 112 of the chiplet arrangement 100. The resource registry may include additional data associated with the hardware resources of the chiplet arrangement 100, such as resource specifications, configuration data, and / or metadata. This data is typically generated at design time and advantageously deployed to the resource registry 430 during chiplet production. It should be noted that the resource registry 430 does not need to include data associated with all hardware resources 112 of the chiplet arrangement 100.

[0084] exist Figure 4 In the chiplet arrangement 100, the control plane 300 also includes a network manager 440. The network manager 440 is advantageously configured to dynamically configure the network connectivity of the chiplet arrangement 100. That is, the network manager 440 is configured to create communication channels suitable for the microsystem 200 of the chiplet arrangement. The network manager can be configured to interface with various bus technologies, such as, but not limited to, PCI or UCIe. The network manager 440 can also be configured to communicate with various components of the chiplet arrangement 100 (hardware resources 112, chiplet network 120, external communication interface 150, etc.). Advantageously, each chiplet 110 and the microsystem 200 are identified at the external communication interface 150, thereby exposing its associated microservices 400. The network manager is advantageously configured to ensure efficient and reliable communication between internal devices of the chiplet arrangement 100 and between internal devices of the chiplet arrangement 100 and external devices. This may involve measures such as implementing efficient protocols for sending data through the chiplet network 120, minimizing latency, and / or maximizing bandwidth. In addition, implementations of error correction mechanisms, flow control mechanisms, and mechanisms for handling errors and exceptions can be provided to improve efficiency and reliability in communication.

[0085] For resource orchestrator 410, network manager 440 can be pre-configured. Microservice 400 will be exposed through control plane 300, and control plane 300 will provide the interface between microservice 400 and specific microsystem 200. Figure 4 This is illustrated in the diagram, whereby the network manager 440 (microservice 400 in the control plane) provides an external communication interface 150 at the application level. Figure 4 (The dashed line in the diagram). The physical connection of the external communication interface 150 is provided by suitable hardware resources 112e included in the microsystem 230. Figure 4 (The solid line in the middle). Figure 4In this context, network manager 440 is shown as microservice 400, but those skilled in the art will understand that microservice 440 is associated with a specific microsystem 200.

[0086] like Figure 4 As explicitly shown, each microsystem 210, 220, and 230 can be specifically addressed at chiplet network 120. For example... Figure 4 As shown, this means that each microsystem 200 is configured with a specific address at the chiplet network 120. As understood from the foregoing disclosure, from the software perspective of the control plane 300, the microsystem 200 is a virtual combination of hardware resources 112. The specific address of the microsystem 200 at the chiplet network 120 can be a virtual address provided, for example, by a network manager 440, which maps it to at least one physical address at the chiplet network 120 provided by one or more hardware resources 112 of the microsystem 200.

[0087] Figure 4 The chiplet arrangement 100 is an exemplary chiplet arrangement 100, and references Figure 4 The features described are optional and can be freely combined with each other or with any other features described herein.

[0088] It should be mentioned that the control plane 300 and / or microservices 400, 410, 420, 430, and 440 can be pre-configured and / or instantiated or reconfigured based on, for example, time scheduling or events.

[0089] refer to Figure 5 This will present some additional exemplary microservices. Figure 5 In the middle, the control plane 300 of the chiplet arrangement 100 includes a specific microsystem 200 ( Figure 5 (Not shown) Associated resource monitor 450. Resource monitor 450 can be configured to capture the status of a wide variety of hardware resources 112 and their current and / or specified capabilities. Thus, the status type and capability type are advantageously part of the metadata registered in resource registry 430 for each hardware resource 112. This status data can be transmitted via electrical communication and / or by monitoring microservice requests. Resource monitor 450 can be configured to provide access to historical data. Historical data can be accessed for predictive maintenance, optimization, etc. Advantageously, historical data is only available for a limited time, which is typically determined by the capacity of the storage device associated with the amount of historical data generated. Resource monitor 450 advantageously resides in chiplet arrangement 100 in order to be able to properly monitor its hardware resources 112.

[0090] exist Figure 5 In the process, the control plane 300 of the chiplet arrangement 100 also includes a connection to a specific microsystem 200. Figure 5 The associated resource security microservice 460 (not shown in the image) is related to (for simplicity) Figure 5 (This is marked as "Resource Security"). Generally, some form of security is beneficial in most applications. Depending on application requirements and hardware capabilities, chip security measures of interest may include one or more of the following: physical tamper detection, encryption of data transmitted via chip electrical communication (chip network 120, etc.), secure software deployment, enabling over-the-air (OTA) software updates, secure hardware deployment, etc. Such security issue detection and actions are advantageously initiated and monitored by the Resource Security microservice 460. Advantageously, any available security issue detection and action types provided by the Resource Security microservice 460 can form part of the metadata registered in the Resource Registry 430.

[0091] exist Figure 5 In the middle, the control plane 300 of the chiplet arrangement 100 also includes an associated microsystem 200 ( Figure 5 Debugger 470 (not shown). Debugger 470 advantageously supports, for example, testing and verification of chiplet placement 100, control plane 300, and instantiated microsystem 200. Debugger 470 can be configured to trace the execution of software instructions in real time, allowing developers to identify potential problems with hardware access, timing, and / or synchronization. Debugger 470 can be configured to monitor memory access in real time, allowing developers to detect and diagnose memory corruption, buffer overflows, or other memory-related problems. Debugger 470 can be configured to examine the values ​​of hardware registers of one or more hardware resources 112 in real time (runtime), allowing developers to diagnose problems related to hardware configuration or control. Debugger 470 can be configured to set breakpoints and / or watchpoints at specific points in program instructions or at memory addresses, allowing developers to pause execution at critical points and examine the system state. Debugger 470 can be configured to provide detailed performance analysis information, allowing developers to identify performance bottlenecks and optimize code for better hardware utilization.

[0092] As described above, the microservices 400 and associated microsystems 200 illustrated above are for illustrative purposes only and should not be construed as limiting in any way. Figure 5 As shown, the control plane 300 likely includes other microservices 200 with associated microsystems 480 (for simplicity, in...). Figure 5 (This is marked as "Other Services"). See, for example... Figure 4 and Figure 5 The examples presented can be freely combined with each other.

[0093] Generally, dynamic instantiation refers to the ability to create and configure instances of a design or component at runtime. In this disclosure and related architecture, it refers to the ability to dynamically create and configure instances of microsystem 200. The use of dynamic instantiation will allow for flexibility and scalability in system design because it allows for the creation of customized microsystems 200 as needed and can further reduce costs by allowing the reuse of existing chiplets 110. To this end, chiplet arrangement 100 is advantageously configurable to host one or more microsystems 200. Each microsystem 200 is configured to produce and / or consume one or more microservices 400. Advantageously, such microsystems 200 are configured to be dynamically instantiated at runtime. To achieve this instantiation, chiplet arrangement 100 can be configured to expose its hardware resources 112 and their allocation to integrated microsystems, as well as their current usage status / availability.

[0094] Therefore, in order to instantiate the microsystem 200, the chiplet arrangement 100 is advantageously configured to dynamically integrate the chiplets 110 and necessary program instructions during runtime (throughout the entire lifecycle of the chiplet arrangement 100) to form the microsystem 200 and the associated production and / or consumption of microservices 400 by the microsystem 200. Additionally, this architecture allows the use of resources allocated to non-running microsystems. This is provided by the control plane 300 of this disclosure.

[0095] Microservice 400 is exposed on chiplet network 120 and / or external communication interface 150 via network manager 440. Network manager 440 is advantageously configured to provide IP addresses to chiplet arrangement 100, thereby making it accessible at external communication interface 150. Network manager 440 is also advantageously configured to provide the ability to communicate locally with other chipsets 110 within the same chiplet arrangement 100. Control plane 300 allows for the orchestration and registration of microservice 200. Control plane 300 is based on SOA principles, a mature technology, and therefore will only be briefly described here.

[0096] A System of Systems (SoS) function refers to the collective behavior and capabilities of a group of interconnected software systems that together form a larger, more complex system. SoS function focuses on how these individual systems work together to achieve a common goal or a set of goals and how they transmit and share information to achieve this. This includes issues such as interoperability, data exchange, and system integration. SoS function is often important in large software systems where multiple independent systems need to work together to achieve common objectives. As those skilled in the art will understand, effective SoS function requires careful design and planning, as well as robust communication protocols and system interfaces, to ensure that each system can interact effectively with other systems.

[0097] To integrate chiplet placement 100 into the SoS functionality, the SoS functionality advantageously supports the fundamental lookup, loose coupling, and delayed binding properties of SOA. The Eclipse Arrowhead architecture is a well-known example and reference implementation of an SOA architecture that provides a basic control plane conforming to SOA principles, such as lookup, delayed binding, loose coupling, and security measures (e.g., authentication, authorization, etc.), as well as optional security and interoperability measures. As an example, the basic control plane functionality in the Eclipse Arrowhead architecture reference implementation is provided by a mandatory / strongly recommended microsystem ServiceRegistry system (lookup), an Orchestration system (delayed binding, loose coupling), and an Authorisation system (authorization, authentication). The SoS functionality can provide these characteristics (based on Eclipse Arrowhead terminology) through the following:

[0098] •ServiceRegistry and associated ServiceDiscovery microservices

[0099] • The Orchestration system and its associated Orchestration microservices, namely the resource orchestrator 410 and its associated microsystems 200.

[0100] • AA security (authentication, authorization) can be provided by the authorization system and the associated microservice GetPublicKey.

[0101] • Additional control plane 300 services, such as online security, interoperability converters and adapters, workflow management and execution. 2 (All references in the footnotes are incorporated herein to provide context for embodiments of this disclosure.) 2 "Workflow management solutions based on microservices," Applied Sciences, autonomous SoS maintenance and redesign 3 (All references in the footnotes are incorporated herein to provide context for embodiments of this disclosure.) 3 A. N. Lam, O. Haugen, and J. Delsing, “Dynamical orchestration and configuration services in industrial IoT systems: An autonomic approach,” IEEE Open Journal of the Industrial Electronics Society, vol. 3, pp. 128–145, 2022).

[0102] The chiplet arrangement 100 with control plane 300 proposed herein significantly improves resource utilization, packaging density (at least per function / service), and engineering efficiency. Generally, for monolithic hardware, each microsystem 200 of this disclosure can be equivalent to a chiplet 110, an ASIC, or even a PCB. Since hardware resources 112 can be shared among microsystems 200, resource efficiency is greatly improved, and since additional microsystems 200 do not require additional space, assuming the existence (physically and schedulably) available hardware resources 112, more services and functions can be provided within the same footprint. The software reconfiguration of hardware as described herein can be described as a virtual reorganization of the electrical connections of chiplet arrangement 100. Furthermore, associating microservices 400 with microsystems 200 improves engineering efficiency. Microservices 400 allow engineering teams to independently develop, deploy, and scale individual components, rather than working on a single large codebase. Each microservice 400 focuses on a specific function or set of functions, resulting in a smaller, more manageable codebase. This autonomy reduces coupling between services and makes it easier to update or replace individual components without affecting the entire system. This is inherent to SOA architecture, which, as mentioned earlier, provides delayed and loose coupling from both hardware (microsystems 200) and software (microservices 400) perspectives. These advantages lead to faster iteration, improved maintainability, and more flexible responses to changing requirements, all of which improve overall engineering efficiency.

[0103] The incredible flexibility of the chiplet arrangement 100 described above presents challenges for developers seeking to leverage this flexibility. For example, from a software perspective, delayed binding (i.e., associating resources at runtime rather than compile time) and loosely coupled services (i.e., individual components or modules operating independently with minimal dependencies on each other) are well-known. However, when delayed binding and loosely coupled services are also applied to hardware, as in the chiplet arrangement 100 presented in this paper, modeling, optimizing, verifying, and validating the microsystem 200 (i.e., the hardware / software combination) becomes challenging.

[0104] The inventors behind this disclosure have recognized this challenge, and the following sections provide a method for simulating a requested service on a chiplet arrangement 100 (modeling the requested service on the chiplet arrangement 100). Simulation can be used to provide a microsystem 200 for deployment on the chiplet arrangement 100. Simulation can be used to verify the hardware and / or software functionality of the requested service. Simulation can be used to optimize the implementation of the requested service (i.e., the associated microsystem 200) from a hardware and / or software perspective. Simulation can be used to determine the increased utilization and / or workload of the requested service on the chiplet arrangement 100. It should be mentioned that although this method will be illustrated in the context of the requested service, these teachings can also be modified and adapted for other contexts, such as simulating or optimizing a chiplet arrangement 100 hosting one or more microsystems 200.

[0105] Verification and validation serve complementary roles, but they address different questions regarding the correctness and suitability of a product. Generally, verification assesses whether the system has been correctly constructed, while validation assesses whether the system has been correctly constructed. The purpose of verification is to ensure that the system conforms to specified design, requirements, and technical standards. Verification can involve examining artifacts such as requirements documents, design models, and code against established specifications or rules. In other words, verification aims to answer the question of whether the product meets its requirements and design. On the other hand, the purpose of validation is to determine whether the final product fulfills its intended purpose and meets, for example, the needs and requirements of users in a real-world operational context. Validation aims to answer the question of whether the product meets the actual needs of users. In short, verification can be described as internally oriented, comparing the product against formal specifications, while validation is externally oriented, assessing the product's suitability for its intended use. As used herein, verification and validation are used interchangeably, and those skilled in the art will understand that the scope of requirements will determine whether verification or validation is actually performed.

[0106] exist Figure 6 The diagram shows a simplified block diagram of a microsystem model 580 provided from a specific chiplet arrangement 100. (Reference) Figure 6The given overview introduces the provision of microsystem model 580, and each step and feature will be further described in subsequent sections. This process is initiated by engineering plan 510. Engineering plan 510 can be obtained as part of a service request. Engineering plan 510 specifies the requirements for the services requested from a specific chiplet arrangement 100. In some examples, engineering plan 510 specifies the services required by the user / operator of chiplet arrangement 100. The specified services refer to those that will be deployed and serviced on the specific chiplet arrangement 100, assuming the requirements are met. The requested services can be anything suitable for chiplet arrangement 100, such as obtaining temperature at specific time intervals, identifying people in video images, controlling a heating system based on a provided AI model, enabling autonomous driving in a vehicle, etc. Based on engineering plan 510, microsystem hardware model 530 is provided. Microsystem hardware model 530 specifies one or more hardware resources 112, such as a specific chip 110 in chiplet arrangement 100 required to provide the requested service or advantageously required hardware services. To this end, the microsystem hardware model 530 includes a hardware resource indicator 532 that indicates which hardware resources 112 or hardware services of the chiplet arrangement 110 are included in the microsystem hardware model 530. The hardware resource indicator 532 may indicate a specific hardware resource 112, but advantageously, for full realization of the dynamic instantiation of the microsystem 200, the hardware resource indicator 532 indicates a hardware service. For example, if the service is recognizing a person in a video image, the hardware resource indicator 532 may need to specify image acquisition hardware resources, processing hardware resources, and memory hardware resources. These microsystem hardware resources 112 may come from the same chiplet 110 or from different chiplets 110. A hardware simulation tool is used to simulate the microsystem hardware model 530, and the result of this simulation provides one or more hardware capabilities 534 of the microsystem hardware model 530. The hardware capabilities 534 are used to estimate the microsystem software model 560. The microsystem software model 560 includes microsystem program instructions 562 (labeled "microsystem instructions" for brevity). The microsystem software model 560 is simulated on the environment 524 of the chiplet layout 100. Based on these simulations, a microsystem model 580 is provided. The microsystem model 580 includes a microsystem hardware model 520, a microsystem software model 560, and one or more microsystem capabilities 584 based on hardware capabilities 534 and software capabilities 564, which are generated by simulating the corresponding models 530 and 560.

[0107] exist Figure 7 An exemplary method 600 according to this disclosure is shown in the figure. Figure 7The method 600 shown can be implemented as a computer-implemented method or a partially computer-implemented method (with some tasks performed entirely or partially manually). It should be noted that many of the features mentioned in method 600 are optional.

[0108] Method 600 includes obtaining the aforementioned engineering plan 510. A requested service can be defined by specifying its functionality, its interface, and how it interacts with other components, services, and devices. The requested service can be described using broad functional terms such as “controlling the ambient temperature to within 1% of the set value,” but such a broadly requested service will require some form of processing to provide the engineering plan 510. As previously mentioned, the engineering plan 510 typically includes hardware requirements 512 and software requirements 514. Although method 600 will be described using an engineering plan 510 that includes both software requirements 514 and hardware requirements 512, it should be noted that some services can be defined using only hardware requirements 512 or software requirements 514. After reading this disclosure, those skilled in the art will clearly understand how method 600 can be adapted to either hardware requirements 512 or software requirements 514, and this disclosure should not be construed as limited to a combination of hardware requirements 512 and software requirements 514.

[0109] Engineering plan 510 and associated hardware requirements 512 and software requirements 514 describe to some extent the functionality and requirements of a specific microsystem 200 for producing and / or consuming one or more microservices 400.

[0110] Engineering plan 510 may be obtained in any suitable manner and compiled in any suitable format, but must at least include instructions for the services requested by the specific chiplet layout 100. Engineering plan 510 is typically provided by the user and takes into account chiplet resources and desired functionality. Engineering plan may include specifications, code, configuration, and optional test cases.

[0111] Hardware requirements 512 can be freely formatted and are typically dependent on the service (microservice 400) and / or function defined by engineering plan 510. In some examples, hardware requirements 512 may be provided in XML or a similar format, but any dataset suitable for describing parameters and constraints can be used. Many generally known formats exist for defining software requirements 514, which can be used to define DW requirements 514, such as, but not limited to, Service Description Language (SDL), Interface Definition Language (IDL), RESTful API documentation, YAML or JSON configuration files, Domain Specific Language (DSL), etc.

[0112] Hardware requirement 512 can specify any suitable hardware-related parameters. In some examples, hardware requirement 512 can be broken down into a set of hardware constraints. These constraints can include physical constraints, connectivity constraints, availability constraints, etc. Physical constraints can include constraints related to one or more of physical size, power consumption, heat dissipation, and chiplet manufacturing capabilities. Connectivity constraints can include constraints related to one or more of bandwidth, latency, reliability of inter-chip connections, supply voltage, supply current, etc. Availability constraints can include constraints related to one or more of the availability and / or allocation of hardware resources (e.g., but not limited to processing cores, memory blocks, I / O interfaces, etc.).

[0113] Accordingly, Software Requirement 514 can specify requirements for any suitable software-related parameters. In some examples, Software Requirement 514 can be broken down into a set of software constraints. These constraints can include one or more of the following: compatibility constraints, performance constraints, security constraints, etc. Setting compatibility constraints can be used to ensure software compatibility with hardware. Compatibility constraints can include constraints related to one or more of the following: instruction set architecture (ISA), memory access mode, I / O protocol, etc. Performance constraints can include constraints related to one or more of the following: processing speed, memory usage, overall efficiency, etc. Security constraints can include constraints related to one or more of the following: secure boot, encryption, secure communication protocols, etc.

[0114] Method 600 also includes obtaining a chiplet layout hardware model 522. The chiplet layout hardware model 522 is a model of the chips 110 of the chiplet layout 100. The chiplet layout hardware model 522 does not need to include hardware models of all chips 110 in the chiplet layout 100; it is sufficient to obtain a hardware model of the chiplet layout 522 that includes the chips 110 deemed necessary for implementing the engineering plan 510. Furthermore, not all chips 110 in the chiplet layout 100 that are part of the chiplet layout hardware model 522 need to be modeled with the same level of precision. For example, some chips 110 can be modeled as simple black boxes, such as impedance at ports, while others can be modeled more accurately with details of traces, components (e.g., semiconductors, passive devices, etc.), or their corresponding physical locations.

[0115] Hardware model 522 for chiplet placement describes the electrical environment of at least a portion of chiplet placement 100. The electrical environment may relate to any conditions and / or factors affecting the behavior and performance of the circuitry (i.e., chiplet 110) and / or its interconnections within and / or around chiplet placement 100 that may affect the operation of chiplet placement 100. Non-limiting examples of data that can describe the electrical environment include voltage sources (the presence and characteristics of voltage sources, such as voltage level, waveform, etc.), current sources (the presence and characteristics of current sources, such as current amplitude, direction, etc.), resistors, capacitors, inductors, circuit resistance, circuit capacitance (e.g., time constant), circuit inductance, operating frequency, temperature, noise, interference, etc.

[0116] The chiplet placement hardware model 522 can be provided in any suitable format, and the different chipsets 110 of the chiplet placement 100 can be modeled differently. In some examples, one or more chipsets 110 or portions of chipset 110 can be modeled as an Integrated Circuit Emphasis Simulation Program (SPICE) model. Alternatively or additionally, one or more chipsets 110 or portions of chipset 110 can be modeled as an FEM model for electromagnetic simulation. Alternatively or additionally, one or more chipsets 110 or portions of chipset 110 can be modeled as a system-level Simulink model. Alternatively or additionally, one or more chipsets 110 or portions of chipset 110 can also be modeled as a General Purpose Circuit Simulator (Qucs) model. Alternatively or additionally, one or more chipsets 110 or portions of chipset 110 can be modeled as an HSPICE model. Alternatively or additionally, one or more chipsets 110 or portions of chipset 110 can be modeled as an OpenModelica model.

[0117] As previously mentioned, the type of model provided by the chiplet-based hardware model 522 may depend on the engineering plan 510. The type of model provided by the chiplet-based hardware model 522 may additionally or alternatively depend on the accuracy requirements of the microsystem model 680, the time requirements for preparing the microsystem model 680, the processing requirements for preparing the microsystem model 680, etc.

[0118] Method 600 also includes estimating a microsystem hardware model 530. The microsystem hardware model 530 is estimated based on engineering plan 510 and advantageously on the hardware requirements 512 and software requirements of engineering plan 510, as well as a hardware dataset 526 of chiplet arrangement 100 (if available). Hardware dataset 526 specifies the hardware resources 112 of chiplet arrangement 100, i.e., lists which hardware is included in chiplet arrangement 100. The hardware resources 112 listed in hardware dataset 526 may correspond to hardware resources 112 in resource registry 430. However, advantageously, hardware dataset 526 is a broader definition of hardware resources 112, and is not limited to the resources currently available in the control plane 300 of chiplet arrangement 100. In some examples, microsystem hardware model 522 and microsystem hardware dataset 526 describe the same or corresponding hardware resources 112 of chiplet arrangement 100.

[0119] The microsystem hardware model 530 details (to a certain extent) which specific hardware resources 112 of the chiplet arrangement 100 the microsystem model 580 might require. The microsystem hardware model 530 can be estimated by mapping hardware requirements 512 to hardware resources 112 of the chiplet arrangement 100. The microsystem hardware model 530 can be estimated manually, automatically, or in combination to select specific hardware resources 112 from the hardware dataset 526 that satisfy hardware requirements 512. For example, estimating the microsystem hardware model 530 may include selecting specific processing circuitry of the chiplet arrangement 100, specific persistent and non-persistent memory circuitry of the chiplet arrangement 100, and specific sensor circuitry of the chiplet arrangement 100. In some examples, estimating the microsystem hardware model 530 may include selecting a specific chiplet 110 in the chiplet arrangement 100 that includes hardware resources 112 in the form of suitable processing circuitry, suitable memory circuitry, and suitable sensor circuitry. Therefore, the microsystem hardware model 530 includes a model of the hardware resources 112 associated with the engineering plan 510, and optionally includes affected hardware resources 112 that are not directly connected to the hardware resources 112 associated with the engineering plan 510.

[0120] Since the microsystem hardware model 530 is estimated based on the engineering plan 510, it can specify not only the actual hardware resources 112 that the microsystem model 580 will use, but also additional hardware resources 112 that may be affected by the additional service power of the engineering plan 510. This can include crosstalk 112 between hardware resources, ripple caused or injected on the supply line, etc.

[0121] It should be mentioned that, in an example where one or more chiplets 110 of chiplet arrangement 100 include configurable hardware (such as FPGA and / or CPLD), hardware model 530 can be configured to specify the configuration of the configurable hardware.

[0122] A specific chiplet arrangement 100 and / or a specific hardware resource 112 can be manually (or automatically) selected as the initial microsystem hardware model 530. As will be explained in later sections, the microsystem hardware model 530 can be selected iteratively, and / or several microsystem hardware models 530 can be estimated.

[0123] Method 600 also includes the microsystem hardware model 530 estimated by simulation 640. Therefore, this simulation is a simulation of the hardware environment of the chiplet arrangement 100 and can be described as an electronic simulation or a hardware simulation. Any suitable one or more simulation tools can be used to provide the hardware simulation. Hardware simulation is not necessarily provided by a single simulation using a single hardware simulation tool, as different hardware simulation tools and methods can be employed to simulate different aspects of the hardware.

[0124] Simulations can be performed by obtaining a relevant hardware model based on the chiplet-based hardware model 522 of the microsystem hardware model 530. Depending on the desired simulation accuracy, the simulation can be extended to include not only the hardware resources 112 specified by the microsystem hardware resource indicator 532, but also other hardware resources 112 affected by those hardware resources 112 specified by the microsystem hardware resource indicator 532. Therefore, and depending on the desired accuracy of the microsystem model 580, the hardware simulation can also include hardware resources 112 that are physically close to the hardware resources 112 specified by the microsystem hardware resource indicator 532.

[0125] Different hardware models in the chiplet layout hardware model 522 can be modeled together using, for example, virtual prototyping tools and techniques. Virtual prototyping techniques allow for the creation of functional software models (microsystem hardware model 530) of systems that can be used for, for example, simulation and testing. Some non-limiting examples of virtual prototyping tools include the Synopsys Virtualizer for creating virtual prototypes of systems, including systems with microcontrollers and ASICs, and the Cadence Virtual Systems Platform for creating virtual prototypes of system-level simulations and software development.

[0126] As previously mentioned, hardware simulation can be performed using any suitable tool and is advantageously consistent with the hardware model obtained from the chiplet layout hardware model 522. The simulation 640 microsystem hardware model 530 may include SPICE simulation. SPICE can simulate the behavior of electronic circuits such as resistors, capacitors, inductors, transistors, and other components. Additionally or alternatively, the simulation microsystem hardware model 530 may include FEM simulation. FEM simulation is capable of modeling complex geometries and simulating electromagnetic fields, antennas, RF components, crosstalk, etc. The simulation 640 microsystem hardware model 530 may include HSPICE simulation. HSPICE simulation is commonly used for circuit simulation, particularly in the field of semiconductor device modeling. For example, in the case of a hardware description language (HDL) simulator for FPGAs, ModelSim or Vivado can be configured to simulate VHDL / Verilog code. In the case of simulators for ASICs (including RFICs and MMICs), suites such as Cadence or Synopsys can be used. In the case of microcontroller simulators, such as Arduino, simulation can be performed using tools such as Proteus or the simulator in the Arduino IDE. You can use QEMU or other advanced simulators to emulate a microprocessor simulator.

[0127] The simulation tools listed above are provided as examples only, and other electronic simulation tools such as PLECS, HOMERPro, OrCADPSpice, Sonnet, Keysight's ADS (Advanced Design System), Proteus, NI Multisim, EMTP-RV (Electromagnetic Temporal Program), PowerWorld Simulator, Tanner Tools (Tanner EDA), Xyce, QuickField, TINA-TI (Texas Instruments), Elmer, SaberRD (Saber), etc., are within the scope of this disclosure. Those skilled in the art will determine which simulation tools are appropriate depending on the application and / or purpose.

[0128] If more than one hardware emulation tool is used, cooperative emulation can be employed. Cooperative emulation involves using multiple emulation tools in parallel, with each tool emulating a portion of the system. During the simulation, the hardware emulation tools exchange data. To allow data sharing between hardware emulation tools, a data exchange service is typically provided. This data exchange service can be a service that uses inter-process communication (IPC), network sockets, or file-based communication to exchange data between different emulation tools.

[0129] The output of a hardware simulation can vary depending on the type of simulation performed and the specific objective of the simulation. The output of a hardware simulation can be, for example, but not limited to: waveforms, such as time-domain waveforms (voltage and / or current waveforms varying over time) or frequency-domain waveforms (signals represented in the frequency domain); AC and / or DC analysis results, such as steady-state analysis (information about the behavior of a circuit in a steady state, which may include the DC operating point) or AC analysis (frequency response, gain, phase shift, and other AC characteristics); transient analysis results, such as transient response (behavior over time in response to changes, such as input signal transitions) or rise and fall times (slew rate, the duration for which a signal transitions between specific voltage levels); S-parameters (scattering parameters describing how an electrical signal is scattered or transmitted through a network); power dissipation and / or loss analysis (information about power consumption, dissipation, and losses in various components of the circuit); harmonic analysis (identification and analysis of harmonic components in a signal); thermal analysis results (information about temperature distribution and thermal behavior), etc. Simulation results may include results from software scanning of one or more parameters of the microsystem hardware model 530 and / or statistical measurements of the simulation data.

[0130] The output of the hardware simulation is processed to obtain one or more hardware capabilities 534. Hardware capabilities 534 typically include data that corresponds at least to some extent to hardware requirement 512. That is, if hardware requirement 512 specifies a maximum current consumption, hardware capabilities 534 may advantageously include data indicating the maximum current consumption of the microsystem hardware model 530. Hardware capabilities 534 may include more or fewer hardware metrics than hardware requirement 512.

[0131] Optionally, in some examples, method 600 may include verifying 645 the microsystem hardware model 530. Verification of the microsystem hardware model 530 may include determining whether the hardware capabilities 534 provided by hardware simulation meet the requirements specified in engineering plan 510. In examples where the engineering plan includes one or more test cases, verification of the microsystem hardware model 530 advantageously includes determining whether the microsystem hardware model 530 passes one or more test cases. The results of the verification of the microsystem hardware model 530 may be provided as hardware verification data.

[0132] In some examples, if the microsystem hardware model 530 fails verification, method 600 may include repeating the estimation 630 of the microsystem hardware model 530. In such an example, 630 may be estimated and 640 simulated based on the microsystem hardware capabilities 534 of the initial microsystem hardware model, along with one or more alternative microsystem hardware models 530. This will provide alternative microsystem hardware capabilities 534, which can then be verified 645 to determine whether they meet the requirements of engineering plan 510.

[0133] Additionally or alternatively, method 600 may include providing one or more alternative microsystem hardware models 530, regardless of how the microsystem hardware model 530 has been verified (if it has been performed).

[0134] Due to the general flexibility of chiplet arrangement 100 in allocating hardware resources 112 to microsystem 200, the iterative method described above can evaluate several different hardware configurations. This allows for the selection of the microsystem hardware model 530 that best suits specific requirements. Therefore, even without performing verification, several different microsystem hardware models 530 can be estimated and simulated. Hardware capabilities 534 can be compared to optimize some design parameters of chiplet arrangement 100, such as current consumption and heat dissipation.

[0135] Regardless of whether an iterative approach is used, method 600 includes obtaining a chiplet layout environment model 524 of the 650-chiplet layout 100 and the deployed software. The chiplet layout environment model 524 can describe the software environment of the chiplet layout 100 in any suitable manner. The chiplet layout environment model 524 may include a software design description. In some examples, the chiplet layout environment model 524 is a digital twin of the chiplet layout 100. (See reference...) Figure 10 Further explanation of the chiplet layout environment model 524.

[0136] Method 600 also includes estimating a microsystem software model 560 based on hardware capabilities 534 and software requirements 514. The microsystem software model 560 includes microservices 400 produced and / or consumed by the microsystem 200. The microsystem software model 560 can be modeled using SysML, UML, Modelica, Matlab, etc. Advantageously, the microsystem software model 560 is modeled to a level of detail that enables a machine to generate microsystem program instructions 562 (i.e., program code). The microsystem program instructions 562 are configured to control hardware resources 112 of the chiplet arrangement 100, as indicated by hardware resource indicator 532. In some examples, the microsystem program instructions 562 are configured to control hardware resources 112 of the chiplet arrangement 100 to provide services specified in engineering plan 510.

[0137] It should be mentioned that, in an example where one or more chiplets 110 of chiplet arrangement 100 include configurable hardware (such as FPGA and / or CPLD), software model 560 can be configured to model the configuration of the configurable hardware.

[0138] Method 600 also includes simulating the estimated microsystem software model 560 of 670. Based on the microsystem software model 560, a specific microsystem 200 and associated services (production and / or consumption microservices 400) can be manually or automatically encoded into executable code. Thus, the microsystem 200 can be functionally simulated and verified against any hardware, including hardware similar to the expected chiplet arrangement 100 (e.g., CPU, memory, I / O, etc.). This verification can be performed using containers, virtual machines (VMs), Docker, Kubernetes, or other methods and tools. Simulation of the microsystem software model 560 can be based on a chiplet arrangement environment model 524 and the microsystem software model 560. For example, in some examples, the chiplet arrangement environment model 524 can be a physical chiplet arrangement 100 on which a software environment is deployed. In these examples, simulating the microsystem software model 560 can include executing the estimated microsystem program instructions 562 on the chiplet arrangement 100. In some examples, chiplet arrangement 100 may not be physically available, and in these cases, the simulated microsystem software model 560 may include executing the estimated microsystem program instructions 562 on hardware similar to that of the chiplet arrangement, which runs software similar to that specified by the chiplet arrangement environment model 524.

[0139] The output of the software simulation is processed to obtain one or more software capabilities 564. Software capabilities 564 can be any suitable capability (covering any suitable capability within any suitable application) and any domain-specific requirement, including real-time control, state machine execution, etc. Some non-limiting exemplary software capabilities 564 include data filtering and / or analysis, applying AI / ML algorithms to data, clustering data using AI / ML, various types of signal processing, digital control, closed-loop control, workflow management, event handling, interrupt handling, functionality, QoS, state estimation / reporting, monitoring, resilient monitoring and / or mitigation, etc. Software capabilities 564 typically include data that corresponds at least to some extent to software requirement 514. That is, if software requirement 514 specifies a maximum memory usage, software capabilities 564 advantageously include data indicating the maximum memory consumption of the microsystem software model 560. Software capabilities 564 may include more or fewer software metrics than software requirement 514.

[0140] Optionally, and corresponding to the microsystem hardware model 530, in some examples, method 600 includes verifying the microsystem software model 560. Verification of the microsystem software model 560 may include determining whether the software capabilities 564 provided by software simulation meet the requirements specified in engineering plan 510. In examples where the engineering plan includes one or more test cases, verification of the microsystem software model 560 advantageously includes determining whether the microsystem software model 560 passes one or more test cases. The results of the verification of the microsystem software model 560 may be provided as software verification data.

[0141] In some examples, if the microsystem software model 560 fails validation, method 600 may include repeating the estimation 660 of the microsystem software model 560. In such an example, one or more alternative microsystem software models 560 may be estimated 630 and simulated 640 based on the microsystem software capabilities 564 of the initial microsystem software model 560. This will provide alternative microsystem software capabilities 564, which can then be validated 675 to determine whether they meet the requirements of engineering plan 510.

[0142] Additionally or alternatively, if the verification of the microsystem software model 560 fails, method 600 may include repeating the estimation 630 of the microsystem hardware model 560. As described above, this means that the verification failure of the microsystem software model 560 may result in the estimation of an alternative microsystem hardware model 530.

[0143] Additionally or alternatively, method 600 may include providing one or more alternative microsystem software models 560, regardless of how the microsystem software models 560 have been validated (if any).

[0144] The iterative method described above can implement several different microsystem software models 560, each based on a different microsystem hardware model 530 and / or including different microsystem program instructions 562. This allows for the selection of the microsystem software model 560 that best suits specific requirements. Therefore, even without performing verification, several different microsystem software models 560 can be estimated and simulated. Software capabilities 564 can be compared to optimize some design parameters of the chiplet layout 100, such as current memory utilization, latency, and bandwidth.

[0145] Method 600 further includes compiling a microsystem hardware model 530 with associated hardware capabilities 534 and a microsystem software model 560 with associated software capabilities into a microsystem model 580 including microsystem capabilities 584. Compilation 680 may include one or more of the following: lexical analysis, syntax analysis, semantic analysis, code generation, etc., of the microsystem hardware model 530 with associated hardware capabilities 534 and the microsystem software model 560 with associated software capabilities. The output of the microsystem model 580 including microsystem capabilities 584 may be in a format configured for deployment on chiplet arrangement 100. In some examples, compilation 680 may be described as integrating the microsystem hardware model 530 with associated hardware capabilities 534 and the microsystem software model 560 with associated software capabilities into a microsystem model 580 including microsystem capabilities 584. Compilation and integration are used interchangeably, and the choice of terms usually depends on the format and level of the microsystem hardware model 530, microsystem software model 560, microsystem model 580, hardware capability 534, software capability, and microsystem capability 584.

[0146] In some examples, method 600 may optionally include verifying microsystem model 580. Verification of microsystem model 580 may include verifying the impact of microsystem model 580 on chiplet arrangement 100. Verifying microsystem model 580 may include determining the utilization rate of hardware resources 112 of chiplet arrangement 100. In some examples, verifying microsystem model 580 may include determining the change in the utilization rate of hardware resources 112 of chiplet arrangement 100 with and without microsystem model 580.

[0147] although Figure 7 Although not explicitly stated, the compilation 680 of the microsystem model 580 may also be iterative, based on the results of verification 685, or may not be based on the results of verification 685, so that alternative microsystem model 580 may be provided based on alternative microsystem hardware model 530 and / or alternative microsystem software model 560.

[0148] It should be mentioned that the verification 685 of the microsystem model 580 may require a redesign of the engineering plan 510, and / or the engineering plan 510 may need to be adapted for different chiplet layouts 100. This also applies if the verification 645 of the microsystem hardware model 530 or the verification 675 of the software model 560 fails.

[0149] In some examples, method 600 may optionally include deploying a microsystem model 580 on chiplet arrangement 100.

[0150] For ease of explanation, the features of method 600 have been described in a specific order. The different features of method 600 can be executed in any suitable order, and several features can be executed in parallel.

[0151] The method 600 described herein allows modeling of a microsystem 200 for a specific chiplet arrangement 100. In some examples, method 600 may further provide a validated microsystem 200, wherein the hardware and / or software has been validated for a specific chiplet arrangement 100. In some examples, method 600 may provide a microsystem 200 based on an engineering plan 510 that is suitable for a specific chiplet arrangement 100 in terms of hardware and / or software.

[0152] Microsystem model 580 can be described as a microsystem scheme that can be dynamically instantiated on chiplet placement 100 at runtime. As described above, due to the combined use of resource scheduler 420 and network manager 440, resources can be dynamically allocated at runtime to instantiate multiple microsystems 200. As described above, during design time, two microsystems 200 can be simulated sharing a given resource, and testing and / or verification can be optionally performed. However, there may be certain limitations in terms of network availability and latency. For example, suppose microsystem A uses resources 1 and 2 and microsystem B uses resources 2 and 3. If microsystems do not need to continuously use resource 2, time slots can be used to schedule when resource 2 will be available to microsystems A and B. The network needs to be configured according to this scheduling and changed at runtime. In the same way, for a given microsystem 200, resource allocation can be changed and updated at runtime if hardware and software constraints allow. Reference Figure 6 The presented method 600 allows for the simulation of such complex functions and can provide feasibility for a given microsystem 200.

[0153] An arrangement of reconfigurable hardware and software at runtime (e.g., the chiplet device 100 configured with a control plane 300 described herein) can be reconfigured, updated, or otherwise modified during its lifecycle to provide any suitable service, function, or feature. This means that the chiplet arrangement 100 can be reconfigured / reorganized at runtime in hardware but not in software in which the hardware is used, or in software but not in hardware in which the software is used, or in both hardware and software. Validating such a system (i.e., a system reconfigurable in both hardware and / or software at runtime) faces a set of unique challenges that can be at least partially addressed by the methods described previously. For example, refer to... Figure 7The introduced method 600 can facilitate the deployment of microsystems 200 that meet specific needs. However, a series of new challenges arise when it is necessary to validate a complete chiplet arrangement 100 for, for example, a safety-critical system. The dynamic nature of such a system means that the behavior of such chiplet arrangement 100 can change during operation, making it challenging to predict and test all possible states and interactions. The enormous complexity introduced by the numerous possible configurations makes validation and qualification extremely challenging. The control plane 300 enables hardware 110, 112 and software components 400 to operate in multiple modes and / or multiple configurations, and when combined, they create an exponential number of possible states for chiplet arrangement 10. Exhaustive testing of such a large state space using conventional validation techniques may be impractical. Furthermore, the unpredictability of interactions between reconfigurable hardware and software components presents further challenges. Changes in hardware configuration can sometimes affect software behavior in non-intuitive ways, and vice versa. These interactions may even lead to emergent behaviors in chiplet arrangement 100 that were not anticipated during the design phase (e.g., in the initial planning phase, conceptualization phase, preliminary design phase, etc.). For example, changes in hardware configuration can introduce timing variations that affect software execution, potentially leading to race conditions or deadlocks that are difficult to detect without thorough testing of these specific configurations. Generally, reproducing and diagnosing problems becomes more complex in runtime-reconfigurable systems (such as chiplet arrangement 100). Because chiplet arrangement 100 can be changed at runtime, problems observed under a particular configuration may not be consistently reproducible, making it difficult to pinpoint the root cause. This inconsistency can hinder the ability to effectively debug and verify, as traditional methods often rely on the assumption that system behavior is deterministic and repeatable under identical conditions. Therefore, the testing process can be more resource- and time-consuming compared to relatively static systems. Developing test cases covering a representative subset of configurations requires careful planning, but coverage blind spots may still exist. Furthermore, managing and maintaining the test environment to support hardware reconfiguration adds to the complexity of operational coordination. Hardware changes (reconfiguration) to the system under test (chiplet arrangement 100) may require physical modifications to the test equipment or the use of dedicated test equipment, further complicating the verification process.

[0154] Specifically, in the field of safety-critical systems, obtaining approval for the reconfigurability of hardware and software at runtime, such as that implemented by the chiplet arrangement 100 and control plane 300 proposed in this paper, for such applications will be a challenge. As used in this paper, safety-critical applications are those where failure or malfunction could lead to significant harm (such as personal injury, (serious) injury, environmental damage, significant property damage, etc.). An example is aviation systems, where flight control software and avionics typically require perfect operation to ensure safety. In the medical field, devices such as pacemakers, insulin pumps, and life support equipment are generally considered critical systems because any malfunction could directly impact a patient's health. Furthermore, nuclear power plants rely on safety-critical control systems to monitor and regulate nuclear reactions to prevent catastrophic events. Automotive safety systems such as anti-lock braking systems (ABS), electronic stability control systems, airbag deployment mechanisms, etc., are generally classified as safety-critical systems. Additionally, railway signaling and control systems, industrial process control systems in chemical plants or refineries, space exploration equipment, military defense systems, control systems for power grids, and water treatment facilities typically require high reliability and are considered safety-critical systems. Safety-critical systems typically need to comply with strict standards and regulations to ensure safe and reliable operation under almost all conditions.

[0155] General verification methods relying on empirical testing and / or simulation may fail to detect all problems or even test all configurations, especially in the context of chiplet arrangement 100. For chiplet arrangement 100, formal verification methods offer substantial benefits by ensuring that the complete state space of chiplet arrangement 100 and control plane 300 conforms to specifications, standards, and regulations. Formal methods provide a mathematical framework for specifying and verifying the behavior of a system under all possible configurations. They enable exhaustive analysis of the state space of chiplet arrangement 100, providing mathematical proofs, for example, that certain safety properties are preserved regardless of how the hardware and software are reconfigured at runtime. By proving the correctness of chiplet arrangement 100 through mathematical verification, formal methods reduce the reliance on large amounts of empirical testing, which may be impractical or insufficient for systems with numerous configurations.

[0156] Furthermore, formal methods can improve the reproducibility and diagnosability of problems. For example, if the behavior of chiplet placement 100 is specified mathematically, any deviation from the expected behavior can be precisely traced in the formal model. This precision aids in debugging and allows for more efficient problem-solving. It also contributes to consistent performance, as formal verification ensures that real-time constraints and resource usage requirements are met across all configurations. Specifically, the benefits of formal methods can become particularly pronounced for safety-critical applications of chiplet placement 100. Formal methods typically increase confidence in the reliability and security of chiplet placement 100 by ensuring that all possible behaviors (e.g., specified requirements, specifications, etc.) have been considered and verified. This comprehensive verification can be crucial for ensuring and communicating compliance with regulatory standards, thereby increasing stakeholder trust in the operation of chiplet placement 100.

[0157] Formal approaches typically consist of three distinct components: formal specification, formal verification, and formal development. These components will be briefly described below.

[0158] Formal specifications can be described as precise mathematical descriptions of the properties and behavior of a system. Providing formal specifications eliminates or significantly reduces the risk of ambiguity that may be inherent in natural language specifications. Formal specifications can be provided using formal languages ​​(such as Z-notation). 4、5 ( 4 JMSpivey; "The Z Notation: A Reference Manual" (Second Edition); Prentice Hall, 1992, the contents of which are incorporated herein by reference in their entirety and for all purposes. 5 J. Woodcock, J. Davies; “Using Z: Specification, Refinement, and Proof”; Prentice Hall, 1996, the contents of which are incorporated herein by reference in their entirety and for all purposes), Vienna Development Method (VDM). 6 ( 6 CB Jones, “Systematic Software Development Using VDM (Second Edition)”; Prentice Hall, 1990, the contents of which are incorporated herein by reference in their entirety and for all purposes; Method B 7 ( 7 JRAbrial; "The B-Book: Assigning Programs to Meanings"; Cambridge University Press, 1996, the contents of which are incorporated herein by reference in their entirety and for all purposes. 8( 8 D. Jackson; “Software Abstractions: Logic, Language, and Analysis”; MIT Press, 2006 (the contents of which are incorporated herein by reference in their entirety and for all purposes) or TLA+ 9 ( 9 L. Lamport; “Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers”; Addison-Wesley, 2002, the contents of which are incorporated herein by reference in their entirety and for all purposes) provides that formal languages ​​can also often be used for verification. For example, Hardware Description Languages ​​(HDLs) (such as Verilog and VHDL) and assertion languages ​​(such as SystemVerilog Assertions (SVA)) can be used to formally define system behavior and constraints. Formal languages ​​are typically based on the mathematical foundations of set theory and logic. They use mathematical structures to define data types, functions, and system states. Formal languages ​​aim to achieve unambiguity and support abstraction by using their precise mathematical structures, which allows, for example, developers to abstract away implementation details and focus on what the system should do, rather than how it does it.

[0159] Formal verification can be described as the process of using mathematical proofs to demonstrate that a system conforms to its formal specifications. Formal verification can include theorem proving, which involves creating logical proofs that some properties within the system hold true; and model checking, which involves automatically exploring almost all possible states of the system to verify properties such as safety (no bad things happen) and activity (good things eventually happen). Techniques such as equivalence checking, property checking, and model checking can be used to ensure that designs conform to specifications and function correctly in almost all possible scenarios, thereby essentially eliminating the need for exhaustive simulations.

[0160] Formal development can be described as systematically translating a formal specification into an executable program, ensuring the correctness of each step. Formal development can use refinement techniques to progressively introduce implementation details while maintaining consistency with the formal specification. Tools such as High-Level Synthesis (HLS) can be used to refine high-level formal descriptions into concrete implementations, while maintaining correctness throughout the development process.

[0161] In some examples, references can be implemented at least in part based on formal methods. Figure 7The method 600 is described. For example, obtaining 610 an engineering plan 510 can be provided as previously described, but in some examples, the engineering plan 510 may include one or more mathematical definitions of the hardware requirements 512 and / or software requirements 514 of the microsystem 200. Furthermore, obtaining 620 a chiplet layout hardware model 522a may be at least partially mathematically defined a chiplet layout hardware model 522. The mathematical definition portion of the chiplet layout hardware model 522 may include a mathematical definition of at least a portion of the electrical environment of the chiplet layout 100. The hardware dataset 526 may be configured to mathematically define at least a portion of the hardware resources 112 of the chiplet layout 100. Based on the mathematically defined hardware requirements 512 and the hardware dataset 526, a 630 mathematically defined microsystem hardware model 530 can be determined. It should be noted that... Figure 7 Method 600 instructs the estimation of a microsystem hardware model 530. A mathematically defined microsystem hardware model 530 can also be considered as being estimated, but given a mathematical definition provided by a formal method, determination better describes this step. Accordingly, the microsystem hardware model 530 does not need to be simulated 640 (although simulation can be performed) to provide hardware capabilities 534, but the microsystem hardware model 530 can be verified 640 to provide a mathematical definition of at least a portion of one or more hardware capabilities 534. In examples where not all models, requirements, and / or data are fully mathematically defined, hardware capabilities 534 can be provided through a combination of simulation and formal (mathematical) verification. For example, an engineering plan 510 and a chiplet layout environment model 524 that is at least partially mathematically defined can be obtained. The chiplet layout environment model 524 that is at least partially mathematically defined may include a mathematical definition of at least a portion of the software environment of the chiplet layout 100. Additionally, when using a formal method, a microsystem software model 560 can be determined rather than estimated 660. To this end, at least a portion of the mathematical definition of the microsystem software model 560 can be determined. The mathematically defined microsystem software model 560 can also be verified 670 instead of simulated 670, although, like the microsystem hardware model 530, it is likely to be at least partially simulated. Verification 670 of the mathematically defined microsystem software model 560 can provide mathematical definitions of at least a portion of one or more software capabilities 564. Based on the mathematically defined microsystem hardware model 530, the mathematically defined microsystem software model 560, the mathematically defined one or more hardware capabilities 534, and the mathematically defined one or more software capabilities 564, a microsystem model 580 can be determined. In some examples, determining the microsystem model 580 may include compiling the at least partially mathematically defined microsystem software model 560, hardware capabilities 534, and software capabilities 564. Subsequently, the microsystem model 580 can be deployed on the chiplet arrangement 100.

[0162] refer to Figure 7 The presented method 600 involves providing a microsystem 200 for optional, at least partially, deployment at a chiplet arrangement 100 according to the method. The provided microsystem 200 may be a validated microsystem, optionally validated by a formal method. However, when a chiplet arrangement 100 configured with a control plane 300 is provided, a corresponding method may be applied. As previously mentioned, to adequately validate the chiplet arrangement 100 and the control plane 300, a large state space must be covered. Furthermore, for safety-critical applications, it may be necessary to ensure the chiplet arrangement 100 meets requirements across the entire state space. As an example, the chiplet arrangement 100 may be validated at, for example, four different ambient temperatures (-40°C, 0°C, 25°C, and 75°C), but there is a risk that internal temperature compensation of one or more chipsets 110 may cause the behavior of the chiplet arrangement 100 to change at temperatures other than those explicitly tested. It should be mentioned that, given the reconfigurability of the microsystem 200 as defined herein, formal verification can cover a variety of different configurations of the hardware resources 112 of the chiplet arrangement 100, each of which can have a different software model 560 (typically with general software capabilities 564), providing a larger state space compared to traditional monolithic hardware configurations. For example, in another example, the chiplet arrangement 100 can be verified using three different temperature sensing hardware resources 112, each reporting temperature using a different time base. However, the chiplet arrangement 100 may likely include additional temperature sensing hardware resources 112 that report temperature using a different time base than the verified temperature sensing hardware resources 112. These two examples can be combined, thereby further increasing the verification space. Formal verification can provide a tool for effectively verifying the substantially complete state space (at least a mathematically definable state space) of the chiplet arrangement 100.

[0163] to this end, Figure 8 A method 1000 for (at least partially) formally verifying a chiplet arrangement 100 configured with a control plane 300 is shown. Method 1000 may be wholly or partially computer-implemented. Method 1000 may be executed using any suitable hardware and / or software.

[0164] Method 1000 includes obtaining a chiplet layout hardware model 522 that is at least partially mathematically defined. In other words, the hardware model 522 is likely a reference... Figure 6The corresponding hardware model 522 is described, but it has one or more mathematical definitions. That is, the chiplet arrangement hardware model 522, which is at least partially mathematically defined, includes a mathematical description of at least a portion of the electrical environment of the chiplet arrangement 100. The chiplet arrangement 100 can be any suitable chiplet arrangement 100, such as those referenced... Figure 1 The small chip arrangement is described as 100.

[0165] In some examples, the chiplet layout hardware model 522 can be an informal chiplet layout hardware model 522, i.e., a non-mathematically defined chiplet layout hardware model 522, or a subset of the chiplet layout hardware model 522 can be an informal chiplet layout hardware model 522. Such a non-mathematically defined chiplet layout hardware model 522 can be described using, for example, one or more natural languages ​​instead of formal languages. In such an example, method 1000 may include converting the non-mathematically defined chiplet layout hardware model 522, or one or more non-mathematically defined portions of the chiplet layout hardware model 522, into a mathematically defined chiplet layout hardware model 522, or a portion thereof.

[0166] Method 1000 also includes obtaining a chiplet layout environment model 524 that is at least partially mathematically defined. In other words, the chiplet layout environment model 524 is likely a reference... Figure 6 The introduced chiplet layout environment model 524 has one or more mathematical definitions. That is, the chiplet layout environment model 524, which is at least partially mathematically defined, includes the mathematical definition of the software environment of the chiplet layout 100. This software environment includes references... Figure 3 The chip control plane 300 is introduced.

[0167] In some examples, the chiplet placement environment model 524 can be an informal chiplet placement environment model 524, i.e., a non-mathematically defined chiplet placement environment model 524, or a subset of the chiplet placement environment model 524 can be an informal chiplet placement environment model 524. Such a non-mathematically defined chiplet placement environment model 524 can be described using, for example, one or more natural languages ​​instead of formal languages. In these examples, method 1000 can include converting the non-mathematically defined chiplet placement environment model 524, or one or more non-mathematically defined portions of the chiplet placement environment model 524, into a mathematically defined chiplet placement environment model 524, or a portion thereof.

[0168] Method 1000 also includes obtaining chiplet placement requirements with one or more mathematical definitions (1030). Chiplet placement requirements will refer to... Figure 9Further explanation includes one or more hardware requirements 512 for chiplet arrangement 100 or software requirements 514 for the software environment of chiplet arrangement 100. Hardware requirements 512 and / or software requirements 514 are likely to be referenced. Figure 6 The corresponding hardware requirement 512 and software requirement 514 are introduced, but have one or more mathematical definitions.

[0169] Furthermore, chiplet placement requirements can be informal chiplet placement requirements, i.e., non-mathematically defined chiplet placement requirements, or a subset of chiplet placement requirements can be informal chiplet placement requirements. Such non-mathematically defined chiplet placement requirements can be described using one or more natural languages ​​instead of formal languages. Correspondingly, hardware requirement 512 and / or software requirement 514 can be informal hardware requirement 512 or software requirement 514, or a subset of hardware requirement 512 and / or software requirement 514 can be informal hardware requirement 512 or software requirement 514. Such non-mathematically defined hardware requirement 512 and / or software requirement 514 can be described using, for example, one or more natural languages ​​instead of formal languages. In these examples, method 1000 may include converting one or more non-mathematically defined portions of non-mathematically defined chiplet layout requirements, hardware requirements 512 and / or software requirements 514, or chiplet layout requirements, hardware requirements 512 and / or software requirements 514 into mathematically defined chiplet layout requirements, hardware requirements 512 and / or software requirements 514, or a portion of mathematically defined chiplet layout requirements, hardware requirements 512 and / or software requirements 514.

[0170] Method 1000 also includes verifying the performance of the chiplet placement environment model 524 on the chiplet placement hardware model 522. Verification 1040 is performed by mathematically proving that at least some mathematically defined parts or the entire chiplet placement environment model 524 meets chiplet placement requirements on at least some mathematically defined parts or the entire chiplet placement hardware model 522. Verification 1040 can be described as a formal verification of the chiplet placement environment model 524.

[0171] In some examples, method 1000 may optionally include deploying 1050 chiplet layout environment model 524 on chiplet layout 100.

[0172] Figure 9 A block diagram of an example computer system 900 (or simply system 900) for implementing the techniques described herein is shown. Although it may not be referenced... Figure 9 The example system 900 specifically mentions some features, but these can be adjusted. Figure 9 The system 900 is configured to provide any of the features, functions, or effects described herein. Specifically, Figure 9System 900 can be configured to provide reference verification of any features, functions, or effects described in microsystem 400 and / or chiplet arrangement 100. System 900 can be fully integrated or partially integrated. In some examples, system 900 can be wholly or partially integrated in server systems and / or distributed systems. In some examples, system 900 is wholly or partially integrated in chiplet arrangement 100. The partitioning and allocation of system 900 should include functions and / or services as well as physical hardware and system components.

[0173] The following sections will describe the various features, services, functions, and devices associated with System 900. It should be noted that these features, services, functions, and devices can be freely combined and are not considered essential. Although features, services, functions, and devices may be described as isolated boxes, this categorization of features, services, functions, and devices is purely for illustrative and explanatory purposes and should not be construed as limiting the implementation of the teachings presented herein.

[0174] System 900 includes or is operatively connected to one or more processors 910 or other computing resources. Processor 910 as used herein can be any suitable processor, processing circuitry, controller, or control circuitry. Computing device 900 also includes or is operatively connected to one or more memories 920. Memory 920 can be one or more non-transitory computer-readable media 810. Non-volatile computer-readable media as used herein can be any suitable non-volatile computer-readable storage media, such as, but not limited to, hard disks, solid-state drives (SSDs), optical discs (such as CDs, DVDs, and Blu-ray discs), flash drives, USB drives, memory cards (such as SD cards and microSD cards), magnetic tape, ROM (read-only memory), EPROM (erasable programmable read-only memory), EEPROM (electrically erasable programmable read-only memory), RAM (random access memory) (when it is part of a persistent storage system), network-attached storage (NAS) devices, and one or more combinations thereof. Memory 920 can include (store) instructions executable by processor 910. When executed, these instructions enable the processor 910 to perform specific operations, functions, and features. These operations, features, and functions will be described below with reference to the general-purpose system 900.

[0175] System 900 includes a requirement acquirer 930. The requirement acquirer 930 is configured to acquire, receive, or otherwise obtain one or more requirements associated with chiplet arrangement 100 and / or microsystem 400. In some examples, the requirement acquirer 930 may be configured to acquire engineering plans 510, such as those referenced herein. Figure 6The engineering plan 510 is described. In some examples, the requirement deriver 930 may be configured to obtain one or more hardware requirements 512 and / or one or more software requirements 514. The requirement deriver 930 may directly obtain one or more hardware requirements 512 and / or one or more software requirements 514. In some examples, one or more hardware requirements 512 and / or one or more software requirements 514 may be obtained from the engineering plan 510. Additionally or alternatively, in some examples, the requirement deriver 930 may be configured to obtain one or more chiplet placement requirements 516. Chiplet placement requirements 516 may correspond to the engineering plan 510, but generally involve requirements for chiplet placement 100 as a whole, rather than requirements for a specific function or microsystem 400. Chiplet placement requirements 516 may include one or more hardware requirements 512 and / or one or more software requirements 514 for chiplet placement 100. In some examples, the requirement deriver 930 may be configured to provide a reference Figure 7 Method 600 describes one or more features, such as, but not limited to, obtaining 610 engineering plans 510.

[0176] Similar to the hardware requirement 512 of the microsystem 400, the hardware requirement 512 of the chiplet layout 100 can specify any suitable hardware-related parameters. Correspondingly, the software requirement 514 of the chiplet layout can specify any suitable software-related parameters, just like the software requirement 514 of the microsystem 400.

[0177] System 900 also includes model acquirer 940. Model acquirer 940 is configured to acquire, receive, or otherwise obtain one or more models associated with chiplet arrangement 100 and / or microsystem 400.

[0178] In some examples, the model acquirer 940 is configured with a chiplet layout model acquirer 941, which is configured to acquire, receive, or otherwise obtain one or more models associated with the chiplet layout 100. The chiplet layout model acquirer 941 may be configured with a hardware model acquirer 942, which is configured to acquire, receive, or otherwise obtain one or more hardware models 522 of the chiplet layout 100. The hardware model 522 of the chiplet layout 100 may be a reference... Figure 6 The hardware model 522 is described. Additionally or alternatively, in some examples, the chiplet arrangement model acquirer 941 may be configured with a software model acquirer 944, which is configured to acquire, receive, or otherwise obtain one or more software models 524 of the chiplet arrangement 100. The software model 524 of the chiplet arrangement 100 may be a reference... Figure 6The environment model 524 is introduced. In some examples, the model acquirer 940 can be configured to provide a reference. Figure 7 Method 600 describes one or more features, such as, but not limited to, obtaining a 620 chiplet layout hardware model 522 and / or obtaining a 660 chiplet layout software model 524.

[0179] In some examples, model acquirer 940 is configured with microsystem model acquirer 945, which is configured to acquire, receive, or otherwise obtain one or more models associated with microsystem 400. Microsystem model acquirer 945 may be configured with hardware model estimator 946, which is configured to estimate, determine, or otherwise obtain one or more microsystem hardware models 530. Hardware model estimator 946 may be configured to estimate microsystem hardware models 530, as referenced... Figure 7 The estimation of the microsystem hardware model 530 in method 600 is outlined in the summary. Additionally or alternatively, in some examples, the microsystem model acquirer 945 may be configured with a software model acquirer 948, which is configured to acquire, receive, or otherwise obtain one or more software models 524 of the microsystem 400. The software model 524 of the microsystem 400 may be a reference... Figure 6 The environment model 524 is introduced.

[0180] System 900 may also include a verifier 960. Verifier 960 may include a chiplet placement verifier 961 and / or a microsystem verifier 965. Chiplet placement verifier 961 may be configured to verify chiplet placement 100 according to any suitable verification process to provide one or more hardware capabilities 535 and / or software capabilities 565 associated with chiplet placement 100. These hardware capabilities 535 and software capabilities 565 may correspond to a reference... Figure 6 The microsystem 400 is described, along with associated hardware capabilities 534 and software capabilities. In some examples, the chiplet placement verifier 961 is configured to verify at least a portion of the chiplet placement 100 using one or more formal methods, i.e., mathematically proving that at least a portion of the chiplet placement 100 satisfies at least a portion of chiplet placement requirement 516, hardware requirement 512, and / or software requirement 514. In some examples, the verifier 960 may be configured to provide a reference. Figure 7Method 600 describes one or more of the features, such as, but not limited to, estimating 630 microsystem hardware model 522, estimating 660 microsystem software model 524, simulating 640 microsystem hardware model 522, simulating 670 microsystem software model 524, verifying 645 microsystem hardware model 522, verifying 675 microsystem software model 524, compiling 680 microsystem model 580, and / or verifying 685 microsystem model 580. As previously described, by configuring the verifier 960 for the metrics to be verified, the verifier 960 can be configured to perform verification without limitation or loss of compatibility.

[0181] Accordingly, the microsystem verifier 965 can be configured to verify at least a portion of the microsystem 400 using one or more formal methods, i.e., mathematically proving that at least a portion of the microsystem 400 satisfies at least a portion of the engineering plan 510, hardware requirements 512, and / or software requirements 514. Additionally or alternatively, the microsystem verifier 965 can be configured to use one or more informal methods (such as reference...) Figure 7 The outlined method is used to verify at least a portion of the microsystem 400.

[0182] Chipset Placement Verifier 961 can be configured to verify chipset placement 100 according to any suitable verification process to provide one or more hardware capabilities 535 and / or software capabilities 565 associated with chipset placement 100. These hardware capabilities 535 and software capabilities 565 may correspond to a reference... Figure 6 The microsystem 400 is described, along with its associated hardware and software capabilities.

[0183] In some examples, system 900 may include converter 970. Converter 970 is configured to convert one or more informal requirements or models into corresponding formally defined requirements or models. In other words, converter 970 is configured to formalize informal data. Converter 970 may be configured to convert informal requirements or models wholly or partially. In some examples, informal requirements or models are provided in natural language. For example, suppose converter 970 is configured to convert informal requirements from natural language into formal requirements. Converter 970 may interpret the requirements to ensure they are fully understood and then identify the boundaries and scope of the requirements. This may involve determining the boundaries of the system constrained by the requirements (e.g., microsystem 400 or chiplet layout 100). That is, converter 970 may determine what is within the system (inputs, outputs, processes) and what is outside the system (external systems, users). Understanding the interactions between the system and its environment helps define clear interfaces and responsibilities. One or more functional requirements may be extracted from the informal requirements. This may include operations, data manipulation, and responses to certain inputs or events. Based on the functional requirements, data variables and state variables may be defined. This can include identifying data elements (such as variables, constants, and data structures) and the state of the system at any given time. Based on this, the requirement can be formalized using a formal specification language such as Z notation, VDM, or TLA+. This means transforming the identified components into mathematical structures. This can include defining sets to represent sets of entities, defining relations to model the relationships between entities, and defining functions or operations to represent the system behavior.

[0184] In some examples, system 900 may include deployer 980. Deployer 980 may include chiplet deployer 981, microsystem deployer 985, and / or microservice deployer 989. Chiplet deployer 981 may be configured to deploy software configurations at chiplet arrangement 100, such as software configurations including complete software configurations, which include, for example, a control plane 300 having one or more microsystems 200 and associated microservices 400. Microsystem deployer 985 may be configured to deploy one or more microsystems 200 and / or microsystem models 580 at chiplet arrangement 100. Microservice deployer 989 may be configured to deploy one or more microservices 400 and / or microservice models at chiplet arrangement 100. In some examples, deployer 980 may be configured to compile microsystem hardware model 530, microsystem software model 560, and / or microsystem model 580. Deployer 980 may be configured to provide, for example, references herein. Figures 3 to 5 The control plane 300 refers to any deployment. In some examples, the model deployer 980 can be configured to provide a reference. Figure 7Method 600 describes one or more features, such as, but not limited to, compiling 680 microsystem model 580 and / or deploying 682 microsystem model 580.

[0185] As a specific example, consider the natural language requirement: "If a user provides a valid username and password, the system should allow the user to log in. Upon successful login, the user can access their account dashboard." Transformer 970 can formalize this requirement to provide a formal requirement using Z notation. The transformer defines a given set of "USERNAME" and "PASSWORD" and a state schema that includes mapping "known_users" from usernames to passwords, and a set "logged_in" representing currently logged-in users. Operations such as "login" can specify precise preconditions and postconditions. The "login" operation can accept inputs of "username?" and "password?" and produce the output "success!". The formal specification can stipulate that if the provided credentials match the credentials in "known_users", the user is added to "logged_in", and "success!" is true. Otherwise, "logged_in" remains unchanged, and "success!" is false.

[0186] As mentioned above, Figure 9 The system 900 presented can be configured to operate in one or more forms. For example, consider a simple counter that increments upon receiving a signal and resets after reaching its maximum value, i.e., an increment operation. This functionality can be implemented as a microservice 400 on a chiplet layout 100. For such functionality, the requirement generator 930 can obtain requirements such as:

[0187] 1. The system maintains a state variable counter, which is a natural number (non-negative integer).

[0188] 2. The counter has an upper limit defined by the constant MAX_VALUE.

[0189] 3. Upon receiving an increment signal, the system increments the counter by one.

[0190] 4. If the counter reaches MAX_VALUE, the next increment will reset the counter to zero.

[0191] 5. The system should always ensure that 0 ≤ counter ≤ MAX_VALUE

[0192] The converter 970 can formalize these requirements using a formal specification language such as Z-notation or a formal method such as the B-method, but assumes the use of mathematical notation. The converter 970 can mathematically define the constant MAX_VALUE. Where MAX_VALUE > 0 and MAX_VALUE = 10, the state variable counter. Where 0 ≤ counter ≤ MAX_VALUE, and the initial state is counter = 0. This can be represented, for example, in Python as:

[0193]

[0194] The model acquirer 940 can be implemented in the form of, for example, Ada, Pascal, or even pseudocode. One implementation of this incremental process can be shown below:

[0195] CONSTANT MAX_VALUE := 10;

[0196] VARIABLE counter :INTEGER := 0;

[0197] PROCEDURE Increment IS

[0198] BEGIN

[0199] IF counter < MAX_VALUE THEN

[0200] counter := counter + 1;

[0201] ELSE

[0202] counter := 0;

[0203] END IF;

[0204] END PROCEDURE;

[0205] This implementation directly reflects the formal specification and should ensure that the code precisely reflects the expected behavior. Verifier 960 can verify the implementation, which involves proving that the implementation maintains the system's invariant (0 ≤ counter ≤ MAX_VALUE) and adheres to the specified behavior under all possible conditions, i.e., maintaining this invariant after each execution of the increment process. Assume that the invariant holds before the increment is executed, i.e., 0 ≤ counter ≤ MAX_VALUE. Verifier 960 can consider two cases based on the value of the counter before the process execution:

[0206] Case 1: Counter <MAX_VALUE

[0207] Before incrementing:

[0208] The counter is greater than or equal to 0 (because the counter is a natural number and the invariant holds true).

[0209] The counter < MAX_VALUE.

[0210] During increment:

[0211] The condition counter < MAX_VALUE is true.

[0212] The counter is updated to counter + 1.

[0213] After increment:

[0214] counter' = counter + 1.

[0215] Since counter < MAX_VALUE, then counter + 1 ≤ MAX_VALUE.

[0216] Therefore, 0 ≤ counter' ≤ MAX_VALUE.

[0217] Conclusion: The invariant still holds after the operation.

[0218] Case 2: counter = maximum value

[0219] Before increment:

[0220] counter = MAX_VALUE.

[0221] During increment: <00​​​​​​​​​​​​​​​​​​​​​​​​If the counter equals MAX_VALUE, then the counter' equals 0. From an implementation perspective, when the counter equals MAX_VALUE, the counter is reset to zero, which meets the requirements.

[0231] Therefore, this implementation correctly implements the increment operation defined in the formal specification.

[0232] The above examples are relatively simple, but the corresponding methods can be applied when it is ensured that, for example, the compiled code does not cause memory leaks or cause hardware overheating.

[0233] exist Figure 10 The example software architecture of chiplet layout environment model 524 is shown in the figure. Figure 10 The chiplet layout environment model 524 in the example is a non-restrictive example and is used to illustrate some hierarchical concepts of the chiplet layout environment model 524. Figure 10 The hierarchical structure described herein is one known to those skilled in the art, and each level will be described only briefly and generally. Although the hierarchical structure is described sequentially, one or more levels may be omitted without affecting the others. Figure 10 In the chiplet layout environment model 524, there are models of both coupled hardware and software.

[0234] Hardware models can be described using chip-based architecture modeling. Architecture modeling can include package-level integration design, which can include heterogeneous integration. Heterogeneous integration can include electronic design automation (EDA), which can include one or more of multi-chip module design, system-on-a-chip (SoC) design, or integrated circuit (IC) design. Package-level integration design can refer to the process of designing and organizing the integration of various hardware components within a system at the package level. In this context, packaging is a higher-level abstraction that encapsulates multiple hardware components, such as integrated circuits, modules, or subsystems, into a single unit. Package-level integration design can involve defining structures, connections, and interfaces at a higher level of abstraction. Heterogeneous integration can refer to the design and integration of different types of components, technologies, or materials within a single hardware system. This approach can involve combining various elements with different properties, functions, or manufacturing processes to achieve improved overall system performance or capabilities. EDA is a class of software tools that can be used to design and model electronic systems and integrated circuits (ICs). EDA tools are typically used throughout the entire electronic design process, from conceptualization and schematic capture to simulation, placement, and verification. These tools facilitate the efficient design, analysis, and manufacture of electronic systems.

[0235] Corresponding to the hierarchical structure of hardware, software models can be described through distributed system design. Distributed system design can include SOA design, which can include microservice architecture modeling. Microservice architecture modeling can include cloud-native architecture, and cloud-native architecture can include modular software design. SOA design is an architectural approach that builds software applications as a collection of services. As mentioned earlier, in SOA, services are self-contained, loosely coupled, and independent modules that encapsulate specific business functions. These services communicate through well-defined, standardized interfaces. One goal of SOA is to enhance flexibility, scalability, and maintainability by promoting modular and reusable design. Microservice architecture modeling can involve designing and representing software systems based on the principles of microservice architecture. As mentioned earlier, microservices are an architectural style that builds applications as a collection of small, independent services, each focusing on a specific business capability. These services are designed to be loosely coupled, independently deployable, and scalable. Modeling a system using microservice architecture involves capturing various aspects of the structure, communication, and behavior of the individual services. Cloud-native architecture is a method for designing and building software applications that leverages the capabilities and advantages of cloud computing platforms. It is characterized by principles that enable applications to fully utilize the dynamic, scalable, and distributed nature of the cloud environment. Modeling software using cloud-native architecture involves considering various aspects that conform to cloud-native principles. Modular software design is a method of breaking down a software system into smaller, independent, and interchangeable modules or components. Each module encapsulates a specific set of functionalities, and these modules interact with each other through well-defined interfaces. The goal of modular design is to improve the maintainability, reusability, and flexibility of software development. Modeling software using modular design involves focusing on all aspects of the organization, communication, and interaction between these discrete software modules.

[0236] refer to Figure 11 This will illustrate an exemplary process of the dynamic instantiation of the microsystem 200. Figure 11 A sequence diagram of the System Modeling Language (SysML) is shown. As is known to those skilled in the art, a SysML diagram is a diagram that illustrates the interactions of system components or stakeholders over time. Figure 11 In this diagram, interactions between system components or stakeholders are shown as a series of events, with arrows indicating the control flow between them. The events are organized chronologically, proceeding from top to bottom. The sequence begins with receiving an integration request, which is... Figure 11 The arrow in the upper left corner indicates this. Process 700 will be explained below.

[0237] (1) Resource orchestrator 410 receives service requests with microsystem model 580. Microsystem model 580 includes data required to instantiate new microsystem 200 and its microservices 400. This data may indicate, for example, scheduling conditions, program instructions, configuration parameters, policies, security certificates, etc.

[0238] (2) The resource orchestrator 410 queries the resource registry 430 to find available hardware resources 112 that match the microsystem model 580. The resource orchestrator 410 checks the list of available resources and selects those that meet the requirements of the specific microsystem model 580. This part of the process 700 ensures that the selected hardware resources 112 are available and meet the requirements of the microsystem model 580, thereby enabling their composability.

[0239] (3) After determining which hardware resource 112 will meet the requirements of the microsystem model 580, the resource orchestrator 410 requests the resource scheduler 420 to allocate the scheduled time and time slot. This may include tasks such as resource scheduling and prioritization.

[0240] (4) The operation results of resource scheduler 420 provide microsystem deployment data. The microsystem deployment data is provided to network manager 440. Network manager 440 is configured to deploy and orchestrate communication integration between hardware resources 112 based on the microsystem deployment data, and to begin execution of the instantiated microsystem 200. This deployment will be configured for the requested lifecycle in a persistent resource scheme.

[0241] (5) The microsystem 200 can be deployed in response to the configuration of resources using parameters indicated in the microsystem model 580, and program instructions are executed by the processing circuit (hardware resource 112 in the form of processing circuit). Advantageously, deployment is performed in response to the scheduling of hardware resource 112 and the establishment of chiplet network 120 for it.

[0242] (6) Advantageously, the instantiated microsystem 200 is tested before it is determined to be ready for use. Tests can be performed to ensure that the overall operation of the microsystem conforms to the service request and the microsystem model 580.

[0243] (7) If the test result is positive, then set up the microsystem 200 and send a registry update to the resource registry 430 to list and store information about the microsystem 200, the microservice instance, and the hardware resources 112 used for the task.

[0244] (8) When the microsystem 200 is online, microservice operations can begin.

[0245] like Figure 11As illustrated in process 700, the operation and utilization of microsystem 200 can begin in response to the deployed microsystem 200 reaching a static state. In the stable state, microsystem 200 is configured as needed and provides the software required for its use. Once the intended microsystem 200 is instantiated, the microservices 400 associated with microsystem 200 are exposed and available on external communication interface 150 and / or chiplet network 120. As can be seen from the above, the architecture capable of exposing hardware capabilities as a set of microservices 400 can be dynamically updated and expanded according to the current needs of chiplet deployment 100. The operation of available microservices 400 can include management across multiple dimensions, such as functionality, security, maintenance, evolution, refactoring, and deployment.

[0246] Figure 12 The lifecycle of chiplet placement 100 is illustrated. At time point T0, the design of chiplet placement 100 is initiated. Time point T0 can be defined by the initial concept, problem statement, and preliminary proof of concept of chiplet placement 100. The design phase of the chiplet placement lasts from time point T0 to time point T1. This design phase can be referred to as the design time. At the end of the design time, the hardware configuration of chiplet placement 100 is set, and chiplet placement 100 enters the runtime phase (referred to as runtime) until its lifecycle ends at time point T2. Figure 12 As shown, the dynamic instantiation process 700 of the microsystem 200 can be executed at any point during runtime. That is, the microsystem 200 can be dynamically instantiated at any point during the runtime of the chiplet arrangement 100. Furthermore, a reference is provided. Figure 6 The method 600 for the microsystem model described herein can be executed at any point in time during the lifecycle of the chiplet layout 100. That is, method 600 can be executed at design time and / or runtime.

[0247] Figure 13 A computer program product 800 is shown. The computer program product 800 includes a computer program 820 and a non-transitory computer-readable medium 810. The computer program 820 can be stored on the computer-readable medium 810. Figure 13In this context, computer-readable medium 810 is exemplified as an old-fashioned 5.25” floppy disk, but can be represented as any suitable non-transitory computer-readable medium, such as, but not limited to, hard disk drives (HDDs), solid-state drives (SSDs), optical discs (e.g., CD-ROMs, DVD-ROMs, CD-RWs, DVD-RWs), USB flash drives, magnetic tapes, memory cards, read-only memory (ROMs), network attached storage (NAS), cloud storage, etc. Computer program 820 includes instructions 825, such as program instructions or software code, which, when executed by the processing circuitry, cause the processing circuitry to execute or induce the execution of references. Figure 6 The methods introduced are all or a subset of 600.

[0248] Instruction 825 can be executed by any suitable processing circuit, and Figure 14 In this process, computer program 820 is loaded onto the chiplet arrangement.

[0249] Figure 15 An exemplary computer system 900 is shown. The computer system 900 may be... Figure 9 The computer system described in the text. Figure 15 The computer system 900 includes processing circuitry 910 and is operatively connected to or includes a data storage device 920 (volatile or non-volatile). The processing circuitry 910 can be configured to cause execution or performance. Figure 6 The method 600 described herein may be all or part thereof. A computer program 620 may be loaded onto a data storage device 920, and a processing circuit 910 may be configured to execute the instructions 825 of the computer program 620.

[0250] Modifications and other variations of the described embodiments will occur to those skilled in the art, taking advantage of the teachings presented in the foregoing description and associated drawings. Therefore, it should be understood that the embodiments are not limited to the specific exemplary embodiments described in this disclosure, and that modifications and other variations are intended to be included within the scope of this disclosure. For example, while embodiments of the invention have been described with reference to chiplets and chiplet arrangements, those skilled in the art will understand that embodiments of the invention can be equivalently applied to any suitable computer system, and are not specific to chiplets.

[0251] As an example only, one can envision a computer system that can be controlled by an external communication interface. This computer system includes multiple hardware resources, each providing at least one dedicated hardware function. The hardware resources are connected via a hardware network. The computer system provides a control plane configured to orchestrate one or more microsystems, each microsystem including at least one hardware resource and addressable connectivity at the network. The control plane is also configured to expose one or more microsystems as microservices at the external communication interface.

[0252] Furthermore, while specific terminology may be used herein, it is for general and descriptive purposes only and not for limiting purposes. Therefore, those skilled in the art will recognize that various variations of the described embodiments will still fall within the scope of the appended claims. Moreover, although individual features may be included in different claims (or embodiments), they may be advantageously combined, and including different claims (or embodiments) does not imply that feature combinations are infeasible and / or disadvantageous. Additionally, singular references do not exclude plural references. Finally, the reference numerals in the claims are provided only as clarifying examples and should not be construed as limiting the scope of the claims in any way.

Claims

1. A computer implementation method (600), comprising: Obtain (610) an engineering plan (510) that includes hardware requirements (512) and software requirements (514) for a microsystem (200) to produce and / or consume one or more microservices (400). Obtain (620) a chiplet arrangement hardware model (522) describing the electrical environment of the chiplet arrangement (100), wherein the chiplet arrangement (100) is controllable by an external communication interface (150) and includes at least one chiplet (110) connected to a chiplet network (120), and wherein the at least one chiplet (110) includes at least one hardware resource (112). The microsystem hardware model (530) is estimated (630) based on the hardware requirements (512) and the hardware dataset (526) describing the hardware resources (112) of the chiplet arrangement (100). Based on the chiplet layout hardware model (522), the estimated microsystem hardware model (530) is simulated (640) by electronic simulation to provide one or more hardware capabilities (534). Obtain (650) a chiplet arrangement environment model (524) that describes the software environment of the chiplet arrangement (100); The hardware capabilities (534) and the software requirements (514) are used to estimate (660) a microsystem software model (560) including one or more microservices (400) produced and / or consumed. The estimated microsystem software model (560) is simulated (670) on the chiplet layout environment model (524) to provide one or more software capabilities (564). The estimated microsystem hardware model (530), the estimated microsystem software model (560), the one or more hardware capabilities (534), and the one or more software capabilities (564) are compiled (680) into a microsystem model (580), the microsystem model (580) including one or more microsystem capabilities (584) that can be exposed as microservices (400) at the external communication interface (150) of the chiplet arrangement (100); and The microsystem model (580) is deployed (682) on the chiplet arrangement (100).

2. The method according to claim 1, further comprising: Based on the hardware requirements (512), the hardware capabilities (534) are verified (645) to provide hardware verification data.

3. The method (600) according to claim 1 or 2, further comprising: The alternative hardware capabilities (534) and the estimated alternative microsystem hardware model (530) are provided for further processing in the following manner: The alternative microsystem hardware model (530) is estimated (630) based on the estimated microsystem hardware model (530), the hardware requirements (512), the hardware dataset (526), ​​and the hardware capabilities (534) including the model of available hardware resources (112) on the chiplet arrangement (100). as well as The estimated alternative microsystem hardware model (530) is simulated (640) by electronic simulation to provide one or more alternative hardware capabilities (534).

4. The method (600) according to claims 2 and 3, wherein, Providing alternative hardware capabilities (534) and estimated alternative microsystem hardware models (530) for further processing is selectively performed based on the hardware verification data.

5. The method (600) according to claim 3 or 4, further comprising: Based on the hardware requirements (512), the alternative hardware capabilities (534) are verified (645) to provide alternative hardware verification data.

6. The method according to claims 2 and 5, further comprising: Before estimating the microsystem software model (560) described in (660), Based on the processing of the hardware verification data and the alternative hardware verification data, one of the microsystem hardware model (530) or the alternative microsystem hardware model (530) is selected as the microsystem hardware model (530) for further processing.

7. The method (600) according to any one of claims 1 to 6, further comprising: Based on the software requirements (514), the software capabilities (564) are verified (675) to provide software verification data.

8. The method (600) according to claims 3 and 7, wherein, Providing the alternative hardware capabilities (534) and the estimated alternative microsystem hardware models (530) for further processing is selectively performed based on the software verification data.

9. The method according to any one of claims 1 to 8, further comprising: The alternative software capabilities (564) and the estimated alternative microsystem software model (560) are provided in the following manner: The hardware capabilities (534) and software requirements (514) are used to estimate (660) the alternative microsystem software model (560); and The estimated alternative microsystem software model (560) is simulated (670) on the chiplet layout environment model (524) to provide one or more alternative software capabilities (564).

10. The method (600) according to claims 7 and 9, wherein, Providing the alternative software capabilities (564) and the estimated alternative microsystem software model (560) for further processing is selectively performed based on the software verification data.

11. The method (600) according to claim 9 or 10, further comprising: Based on the software requirements (514), the alternative software capabilities (564) are verified (675) to provide alternative software verification data.

12. The method according to claims 7 and 11, further comprising: Before providing the estimated microsystem hardware model (530) and the estimated microsystem software model (560) as the microsystem model (580), Based on the processing of the software verification data and the alternative software verification data, one of the microsystem software model (560) or the alternative microsystem software model (560) is selected as the microsystem software model (560) for further processing.

13. The method (600) according to any one of claims 1 to 12, wherein, The software requirement (514) includes at least one compatibility constraint, at least one performance constraint and / or at least one security constraint.

14. The method (600) according to any one of claims 1 to 13, wherein, The hardware requirements (512) include at least one physical constraint, at least one connectivity constraint and / or at least one availability constraint.

15. The method (600) according to any one of claims 1 to 14, wherein, The chiplet layout environment model (524) is a digital twin of the chiplet layout (100).

16. The method (600) according to any one of claims 1 to 15, wherein, The chiplet arrangement hardware model (522) includes a hardware model of one or more chipslets (110) of the chiplet arrangement (100).

17. The method (600) according to any one of claims 1 to 16, wherein, The chiplet layout hardware model (522) includes the physical hardware device of one or more chipslets (110) of the chiplet layout (100).

18. The method (600) according to any one of claims 1 to 18, further comprising: The utilization rate of the chiplet arrangement (100) is estimated (685) based on the microsystem model (580) and the microsystem capability (584).

19. A computer system (900) including processing circuitry (910) configured to perform the method (600) according to any one of claims 1 to 19.

20. A method (1000) for formal verification of a chiplet arrangement (100) configured with a control plane (300), the method (1000) comprising: Obtain a mathematically defined chiplet layout hardware model (522) (1010), the mathematically defined chiplet layout hardware model (522) including a mathematical description of the electrical environment of the chiplet layout (100), wherein the chiplet layout (100) is controllable by an external communication interface (150) and includes at least one chiplet (110) connected to a chiplet network (120), and wherein the at least one chiplet (110) includes at least one hardware resource (112). Obtain a mathematically defined chiplet layout environment model (524) (1020), wherein the mathematically defined chiplet layout environment model (524) includes a mathematical definition of the software environment of the chiplet layout (100), wherein the software environment includes a chiplet control plane configured with the following items: A resource orchestrator (410) is configured to orchestrate one or more microsystems (200) that instantiate the chiplet arrangement (100), each microsystem (200) including at least one hardware resource (112) and addressable connections at the chiplet network (120), and A network manager (440) is configured to control communication between the microsystems (200) of the chiplet arrangement (100) and the external communication interface (150) by exposing one or more microsystems (200) as microservices (400) at the external communication interface (150); Obtain (1030) one or more mathematically defined chiplet layout requirements (516), the one or more mathematically defined chiplet layout requirements (516) including one or more hardware requirements (512) of the chiplet layout (100) or software requirements (514) of the software environment of the chiplet layout (100). The chiplet placement environment model (524) on the chiplet placement hardware model (522) is verified (1040) by mathematically proving that it satisfies the chiplet placement requirements (516); and Deploy (1050) the chiplet arrangement environment model (524) on the chiplet arrangement (100).

21. The method (1000) according to claim 20, wherein, At least one of the chiplet layout hardware model (522) and the chiplet layout environment model (524) is a fully mathematically defined model (522, 524).

22. The method (1000) according to claim 20 or 21, further comprising: Obtain (1030) one or more non-mathematically defined chiplet layout requirements (516), said one or more non-mathematically defined chiplet layout requirements (516) including one or more hardware requirements (512) of said chiplet layout (100); and Verify (1040) that the chiplet layout (100) with the chiplet layout environment model (524) deployed meets the non-mathematical chiplet layout requirements (516).

23. The method (1000) according to any one of claims 20 to 23, further comprising: Obtain (1030) one or more non-mathematically defined chiplet layout requirements described in natural language (516); as well as The non-mathematically defined chiplet layout requirement (516) is transformed (1035) into a mathematically defined chiplet layout requirement (516).

24. A computer implementation method (600) for formal verification of a microsystem (400) comprising a chiplet arrangement (100) with a control plane (300), the method (600) comprising: Obtain (610) an engineering plan (510) that includes mathematical definitions of hardware requirements (512) and software requirements (514) for a microsystem (200) for producing and / or consuming one or more microservices (400); Obtain (620) a mathematically defined chiplet layout hardware model (522), the mathematically defined chiplet layout hardware model (522) including a mathematical definition of the electrical environment of the chiplet layout (100), wherein the chiplet layout (100) is controllable by an external communication interface (150) and includes at least one chiplet (110) connected to a chiplet network (120), and wherein the at least one chiplet (110) includes at least one hardware resource (112). Based on the hardware requirements (512) and the hardware dataset (526) of the hardware resources (112) of the chiplet arrangement (100) mathematically defined, the microsystem hardware model (530) is determined. Based on the chiplet layout hardware model (522), the microsystem hardware model (530) is verified to provide mathematical definitions of one or more hardware capabilities (534); Obtain a mathematically defined chiplet layout environment model (524), wherein the mathematically defined chiplet layout environment model (524) includes the mathematical definition of the software environment of the chiplet layout (100); The hardware capabilities (534) and the software requirements (514) are used to determine the mathematical definition of a microsystem software model (560) including one or more microservices (400) produced and / or consumed; The estimated microsystem software model (560) is verified (675) on the chiplet layout environment model (524) to provide mathematical definitions of one or more software capabilities (564); A microsystem model (580) is determined (680) based on the mathematically defined microsystem hardware model (530), the mathematically defined microsystem software model (560), one or more mathematically defined hardware capabilities (534), and one or more mathematically defined software capabilities (564), the microsystem model (580) including one or more microsystem capabilities (584) that can be exposed as microservices (400) at the external communication interface (150) of the chiplet arrangement (100); and The microsystem model (580) is deployed (682) on the chiplet arrangement (100).

Images