Chiplet arrangement modeling and / or validation

Abstract

A method (600) is presented. The method (600) comprising obtaining (610) an engineering plan and a chiplet arrangement hardware model. The method (600) further comprises estimating (630) a microsystem hardware model based on the hardware requirements and a hardware data set describing hardware resources of the chiplet arrangement and simulating (640) the estimated microsystem hardware model by electrical simulations to provide one or more hardware capabilities. The method (600) further comprises obtaining (650) a chiplet arrangement environment model and estimating (660) a microsystem software model using the hardware capabilities and the software requirements. The method (600) further comprises simulating (670) the estimated microsystem software model on the chiplet arrangement environment model to provide one or more software capabilities and compiling (680) the estimated microsystem hardware model, the estimated microsystem software model, the one or more hardware capabilities, the one or more software capabilities to a microsystem model comprising one or more microsystem capabilities.

Description

[0001] Chiplet arrangement modeling and / or validation

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to chiplets. More precisely this disclosure relates to modeling of an architecture, an integration and a deployment a microservice of chiplet arrangements.

[0004] BACKGROUND

[0005] According to Moore’s law, every two years the number of transistors in an integrated circuit (IC) doubles. However, due to high costs, the pace of silicon manufacturing improvement is decelerating, and it is increasingly challenging to produce commercially viable chips on smaller and smaller scales. The current development of monolithic chips faces not only economical limitations but also challenges in terms of supply / demand, flexibility and competitiveness. Generally, from the early design phases, the chip is conceived without the possibility of future change or evolution, thereby hampering the reuse of hardware.

[0006] In response to this situation, chiplets have emerged as a promising solution. Generally, a chiplet is a modular semiconductor component that is configured to perform a specific function or subset of functions within larger integrated circuit. A chiplet may be combined with other chiplets to form a more complex integrated circuit, offering greater flexibility in design and manufacturing.

[0007] The concept of chiplets has been around for several 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 that were connected to the main processor through a bus interface. In recent years, chiplets have gained renewed interest due to advances in semiconductor packaging technology and the increasing complexity of modem electronic devices. By breaking down a complex system or system-on-chip (SoC) into smaller, more manageable components, chiplets offer several advantages.

[0008] To facilitate the use of chiplets, industry groups and standards bodies have developed interfaces and protocols for connecting and communicating between chiplets. Examples include the Chiplet Integration Interface (CII) from the Semiconductor Industry Association (SIA) and the Advanced Interface Bus (AIB) from the Open Compute Project (OCP). Chiplets are a promising approach to designing and manufacturing complex semiconductor devices, offering greater flexibility, efficiency, yield, scalability, optimized performance, and reliability.

[0009] The flexibility in design and manufacturing of chiplets facilitates provisioning of hardware that may be configured to perform a vast number of different tasks. However, a chiplet is a locked solution like creating PCBs serving a particular task or functionality. Although standardization work is progressing, the full potential of chiplets is yet to be exploited.

[0010] SUMMARY

[0011] An object of the present invention is to provide a new type of methodology for modelling, simulating and / or validating reconfigurable hardware and software solutions which is improved over prior art and which eliminates or at least mitigates the drawbacks discussed above. More specifically, an object of the invention is to provide a method, executable at design time and / or runtime, for modeling a microsystem and associated produced or consumed microservice of the microsystem for deployment on a chiplet arrangement. These objects are achieved by the technique set forth in the appended independent claims with preferred embodiments defined in the dependent claims related thereto.

[0012] In a first aspect, a method is presented. The method may be computer implemented. The method may be performed by a computer system. The method comprises: obtaining, optionally by a requirement obtainer, an engineering plan comprising hardware requirements and software requirements of a microsystem for producing and / or consuming one or more microservices; obtaining, optionally by a requirement obtainer, a chiplet arrangement hardware model describing an electrical environment of a chiplet arrangement, wherein the chiplet arrangement is controllable by an external communications interface and comprises at least one chiplet connected to a chiplet network, and wherein the at least one chiplet comprises at least one hardware resource; estimating a microsystem hardware model based on the hardware requirements and a hardware data set describing hardware resources of the chiplet arrangement; simulating, optionally by a validator, the estimated microsystem hardware model by electrical simulations based on the chiplet arrangement hardware model to provide one or more hardware capabilities, obtaining, optionally by a requirement obtainer, a chiplet arrangement environment model describing a software environment of the chiplet arrangement; estimating, optionally by a validator, a microsystem software model comprising the produced and / or consumed one or more microservices using the hardware capabilities and the software requirements; simulating, optionally by a validator, the estimated microsystem software model on the chiplet arrangement environment model to provide one or more software capabilities; compiling, optionally by a deployer, the estimated microsystem hardware model, the estimated microsystem software model, the one or more hardware capabilities, the one or more software capabilities to a microsystem model comprising one or more microsystem capabilities.

[0013] In one variant, the method further comprises validating, optionally by a validator, the hardware capabilities based on the hardware requirements, providing hardware validation data. This is beneficial as it enables, prior to deployment, a validation of the hardware side of the engineering plan.

[0014] In one variant, the method further comprises 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, the hardware requirements, the hardware data set and the hardware capabilities comprising models of hardware resources available on the chiplet arrangement; and simulating the estimated alternative microsystem hardware model by electrical simulations to provide one or more alternative hardware capabilities. This is beneficial as it enables providing a plurality of different hardware solutions providable by the chiplet arrangement for the engineering plan.

[0015] In one variant, providing alternative hardware capabilities and the estimated alternative microsystem hardware model for further processing is performed selectively based on the hardware validation data. This is beneficial as alternative models may only be provided if validation fails which will reduce modeling time. In one variant, the method further comprises validating the alternative hardware capabilities based on the hardware requirements providing alternative hardware validation data. This is beneficial as it enables providing a plurality of different hardware solutions providable by the chiplet arrangement for the engineering plan.

[0016] In one variant, the method further comprises, before estimating the microsystem software model, selecting one of the microsystem hardware model or the alternative microsystem hardware model as microsystem hardware model for further processing based on processing of the hardware validation data and the alternative hardware validation data. This is beneficial as it enables optimization of the microsystem from a hardware perspective.

[0017] In one variant, the method further comprises validating the software capabilities based on the software requirements, providing software validation data. This is beneficial as it enables, prior to deployment, a validation of the software side of the engineering plan.

[0018] In one variant, providing alternative hardware capabilities and the estimated alternative microsystem hardware model for further processing is performed selectively based on the software validation data. This is beneficial as a modeling time may be reduced by not modeling systems that fail to meet the software requirements.

[0019] In one variant, the method further comprises providing alternative software capabilities and an estimated alternative microsystem software model by: estimating the alternative microsystem software model using the hardware capabilities and the software requirements; and simulating the estimated alternative microsystem software model on the chiplet arrangement environment model to provide one or more alternative software capabilities. This is beneficial as it enables providing a plurality of different software solutions providable by the chiplet arrangement for the engineering plan.

[0020] In one variant, providing alternative software capabilities and the estimated alternative microsystem software model for further processing is performed selectively based on the software validation data. This is beneficial as alternative models may only be provided if validation fails which will reduce modeling time. In one variant, the method further comprises validating the alternative software capabilities based on the software requirements, providing alternative software validation data. This is beneficial as it enables providing a plurality of different hardware solutions providable by the chiplet arrangement for the engineering plan.

[0021] In one variant, the method further comprises before providing the estimated microsystem hardware model and the estimated microsystem software model as a microsystem model, selecting one of the microsystem software model or the alternative microsystem software model as microsystem software model for further processing based on processing of the software validation data and the alternative software validation data. This is beneficial as it enables optimization of the microsystem from a software perspective.

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

[0023] In one variant, the hardware requirements comprise at least one physical constraint, at least one connectivity constraint, and / or at least one availability constraint.

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

[0025] In one variant, the chiplet arrangement hardware model comprises hardware models of one or more chiplets of the chiplet arrangement.

[0026] In one variant, the chiplet arrangement hardware model comprises physical hardware devices of one or more chiplets of the chiplet arrangement.

[0027] In one variant, the method further comprises deploying the microsystem model on the chiplet arrangement.

[0028] In one variant, the method further comprises estimating a utilization of the chiplet arrangement based on the microsystem model and the microsystem capabilities.

[0029] In a second aspect, a computer system comprising processing circuitry configured to cause execution of the method of the first aspect is presented.

[0030] In a third aspect, a method for formal validation of a chiplet arrangement configured with a control plane is presented. The method may be computer implemented. The method comprising: obtaining, optionally by an obtainer, a mathematically defined chiplet arrangement hardware model comprising a mathematical description of an electrical environment of a chiplet arrangement, wherein the chiplet arrangement is controllable by an external communications interface and comprises at least one chiplet connected to a chiplet network, and wherein the at least one chiplet comprises at least one hardware resource; obtaining, optionally by an obtainer, a mathematically defined chiplet arrangement environment model comprising a mathematical definition of a software environment of the chiplet arrangement, wherein the software environment comprises a chiplet control plane configured with: a resource orchestrator configured to orchestrate instantiate one or more microsystems of the chiplet arrangement, each microsystem comprising at least one hardware resource and an addressable connection at the chiplet network, and a network manager configured to control communication between the microsystems and the external communications interface of the chiplet arrangement by exposing one or more microsystems as microservices at the external communications interface; obtaining, optionally by an obtainer, one or more mathematically defined chiplet arrangement requirements comprising one or more hardware requirements for the chiplet arrangement or software requirements for the software environment of the chiplet arrangement; validating, optionally by a validator, the chiplet arrangement environment model on the chiplet arrangement hardware model by mathematically proving that the chiplet arrangement environment model on the chiplet arrangement hardware model fulfills the chiplet arrangement requirements; and deploying, optionally by a deployer, the chiplet arrangement environment model on the chiplet arrangement.

[0031] In one variant, at least one of the chiplet arrangement hardware model and the chiplet arrangement environment model is a wholly mathematically defined model.

[0032] In one variant, the method, further comprises: obtaining one or more non- mathematically defined chiplet arrangement requirements comprising one or more hardware requirements for the chiplet arrangement; and validating that chiplet arrangement deployed with the chiplet arrangement environment model fulfills the non- mathematical chiplet arrangement requirements.

[0033] In one variant, the method further comprises: obtaining one or more non- mathematically defined chiplet arrangement requirements described in a natural language; and translating the non-mathematically defined chiplet arrangement requirements into mathematically defined chiplet arrangement requirements.

[0034] In a fourth aspect, a computer system comprising processing circuitry configured to cause execution of the method of the third aspect is presented.

[0035] In a fifth aspect, a computer implemented method for formal validation of a microsystem for a chiplet arrangement configured with a control plane is presented. The method comprising: obtaining, optionally by an obtainer, an engineering plan comprising mathematical definitions of hardware requirements and software requirements of a microsystem for producing and / or consuming one or more microservices; obtaining, optionally by an obtainer, a mathematically defined chiplet arrangement hardware model comprising a mathematical definition of an electrical environment of a chiplet arrangement, wherein the chiplet arrangement is controllable by an external communications interface and comprises at least one chiplet connected to a chiplet network, and wherein the at least one chiplet comprises at least one hardware resource; determining, optionally by an obtainer, a mathematically defined microsystem hardware model based on the hardware requirements and a hardware data set mathematically defining hardware resources of the chiplet arrangement; validating, optionally by a validator, the microsystem hardware model based on the chiplet arrangement hardware model to provide a mathematical definition of one or more hardware capabilities; obtaining, optionally by an obtainer, a mathematically defined chiplet arrangement environment model comprising a mathematical definition of a software environment of the chiplet arrangement; determining, optionally by an obtainer, a mathematical definition of a microsystem software model comprising the produced and / or consumed one or more microservices using the hardware capabilities and the software requirements; validating, optionally by a validator, the estimated microsystem software model on the chiplet arrangement environment model to provide a mathematical definition of one or more software capabilities; determining, optionally by an obtainer, based on the mathematically defined microsystem hardware model, the mathematically defined microsystem software model, the mathematically defined one or more hardware capabilities, and the mathematically defined one or more software capabilities, a microsystem model comprising one or more microsystem capabilities exposable as microservices at the external communications interface of the chiplet arrangement; and deploying, optionally by a deployer, the microsystem model on the chiplet arrangement.

[0036] In a sixth aspect, a computer system comprising processing circuitry configured to cause execution of the method of the fifth aspect is presented.

[0037] In a seventh aspect, a chiplet arrangement controllable by an external communications interface is presented. The chiplet arrangement comprises at least one chiplet connected to a chiplet network, and wherein the at least one chiplet comprises at least one hardware resource; and wherein the chiplet arrangement is provided with a chiplet control plane comprising: a resource orchestrator configured to instantiate one or more microsystems with a respective associated microservice of the chiplet arrangement, wherein each microsystem comprising 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 and the external communications interface of the chiplet arrangement by exposing microservices associated with the respective microsystems at the external communications interface.

[0038] The disclosed aspects, examples (including any preferred examples), and / or accompanying claims may be suitably combined with each other as would be apparent to anyone of ordinary skill in the art. Additional features and advantages are disclosed in the following description, claims, and drawings, and in part will be readily apparent therefrom to those skilled in the art or recognized by practicing the disclosure as described herein.

[0039] BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Embodiments of the invention will be described in the following; references being made to the appended diagrammatical drawings which illustrate non-limiting examples of how the inventive concept can be reduced into practice.

[0041] Fig. l is a schematic view of a chiplet arrangement according to some examples of the present disclosure;

[0042] Fig. 2 is a schematic view of a chiplet according to some examples of the present disclosure; Fig. 3 is a schematic view of a microsystem associated with a microservice according to some examples of the present disclosure;

[0043] Fig. 4 is a schematic view of a chiplet arrangement according to some examples of the present disclosure;

[0044] Fig. 5 is a schematic view of a control plane according to some examples of the present disclosure;

[0045] Fig. 6 is a schematic view of a microsystem model for a chiplet arrangement according to some examples of the present disclosure;

[0046] Fig. 7 is a schematic view of a method according to some examples of the present disclosure;

[0047] Fig. 8 is a schematic view of a method according to some examples of the present disclosure;

[0048] Fig. 9 is a schematic view of a computer system according to some examples of the present disclosure;

[0049] Fig. 10 is a hierarchical view of an exemplary chiplet arrangement environment model according to an example;

[0050] Fig. 11 is a SysML sequence diagram of dynamic instantiation of a microsystem according to some examples of the present disclosure.

[0051] Fig. 12 is a timeline graph of a lifecycle of a chiplet arrangement according to an example;

[0052] Fig. 13 is a schematic view of a computer program product according to an example;

[0053] Fig. 14 is a schematic view of a computer program being loaded onto a chiplet arrangement according to an example; and

[0054] Fig. 15 is a schematic view of a computer program being loaded onto a computer system according to an example.

[0055] DETAILED DESCRIPTION OF EMBODIMENTS

[0056] Hereinafter, certain embodiments will be described more fully with reference to the accompanying drawings. The invention may, however, 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 the scope of the invention, such as it is defined in the appended claims, to those skilled in the art.

[0057] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0058] The term “coupled” is defined as connected, although not necessarily directly, and not necessarily mechanically. Similarly, the term “connected”, or “operatively connected”, is defined as connected, although not necessarily directly, and not necessarily mechanically. Two or more items that are “coupled” or “connected” may be integral with each other. The terms “a” and “an” are defined as one or more unless this disclosure explicitly requires otherwise. The terms “substantially”, “approximately” and “about” are defined as largely, but not necessarily wholly as what is specified, as understood by a person of ordinary skill in the art. The terms “comprise” (and any forms thereof), “have” (and any forms thereof), “include” (and any form thereof) and “contain” (and any forms thereof) are open-ended linking verbs. As a result, a method that “comprises”, “has”, “includes” or “contains” one or more steps, possesses those one or more steps, but is not limited to possessing only those one or more steps.

[0059] Hereinafter, certain embodiments will be described more fully with reference to the accompanying drawings. The invention may, however, 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 the scope of the invention, such as it is defined in the appended claims, to those skilled in the art.

[0060] Similarly, the term “connected”, or “operatively connected”, is defined as connected, although not necessarily directly, and not necessarily mechanically. Two or more items that are “coupled” or “connected” may be integral with each other. The terms “a” and “an” are defined as one or more unless this disclosure explicitly requires otherwise. The terms “substantially”, “approximately” and “about” are defined as largely, but not necessarily wholly what is specified, as understood by a person of ordinary skill in the art. The terms “comprise” (and any forms thereof), “have” (and any forms thereof), “include” (and any form thereof) and “contain” (and any forms thereof) are open-ended linking verbs. As a result, a method that “comprises”, “has”, “includes” or “contains” one or more steps, possesses those one or more steps, but is not limited to possessing only those one or more steps.

[0061] For the present disclosure, a chiplet is a, commonly, tiny integrated circuit (IC) that comprises a well-defined subset of functionality. It is designed to be combined with other chiplets to form a chiplet arrangement. The chiplet arrangement may (but is not required to) be provided on a common interposer in a single package. The chiplets of a chiplet arrangement are connected using a network structure exemplified by, but not limited to, current well known structures like AIB, PCIe, UIB (chiplet bus standard led by Intel), etc. It should be mentioned that chiplet to chiplet communication may be direct or indirect (i.e. via one or more other chiplets). Chiplets may be configured with substantially any hardware and, optionally, software functionality. A chiplet may comprise, or consist, of configurable hardware such as Complex Programmable Logic Devices (CPLDs) and / or Field Programmable Gate Arrays (FPGAs).

[0062] Chiplet arrangements have several benefits compared to e.g., large scale integrated circuits (ICs). As chiplet arrangements separate different functions into discrete chiplets, chiplet arrangements make it easier to isolate and fix defects during manufacturing. This may lead to higher overall yield rates and lower costs. By mixing and matching different chiplets, designers are able to create custom chiplet arrangements in the form of system on chips (SoCs) that are optimized for specific applications. This may result in more efficient, higher-performing devices. By working with smaller, more manageable constitutional components in the form of chiplets, designers are able to iterate more quickly, and test individual constitutional components more thoroughly before integrating them into a larger system of a chiplet arrangement 100. The designers are further able to add on-the-fly or remove the component s) from the SoC if needed. This, makes it comfortable for design engineers in scaling the performance and complexity of the overall system. Chiplets enable companies to take advantage of economies of scale and reuse existing chip designs, which reduces cost of new developments. Chiplets support a variety of applications ranging from high power (server in data centers) to battery-operated devices (smartwatch). The philosophy behind chiplet allows interoperability among different vendors of chiplets. This leads to improved performance when compared with a single monolithic chip solution.

[0063] The configurability of chiplets from a hardware perspective has historically been isolated from a corresponding software configurability. A software functionality of a chiplet is generally limited to the functionality provided by each of the different chiplets. Each chiplet is addressed using a hardware abstraction layer (HAL), generally specific for each chiplet. In order to allow full flexibility of a chiplet and also to increase utilization of resources of a SoC, the inventors behind the present disclosure have realized that a chiplet, or a collection of chiplets, may be shared and utilized using a plurality of microsystems and associated produced and / or consumed microservices of the plurality of microsystems.

[0064] Generally, microservices are a software architectural approach in which a large application is broken down into small, independent, and loosely coupled services that may be developed, deployed, and maintained separately. Each microservice typically performs a specific function (e.g. business function etc.) 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 the application, as well as increased 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 their own microservice. This approach may improve overall development speed and reduce the risk of conflicts or dependencies between teams. Overall, microservices may provide greater agility, scalability, and reliability in large and complex information systems / computer systems.

[0065] Historically, microservices have been designed to be deployed as independent, lightweight components that can be run on a distributed system of commodity hardware. This allows for greater scalability and fault tolerance than running a monolithic application on a single server or server cluster. One common hardware configuration for microservices are cloud-based infrastructures. 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 like Kubernetes. Alternatively, microservices may be 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 may be deployed on edge devices such as internet of things (loT) devices or embedded systems. This requires a lightweight runtime environment that can run on resource-constrained hardware.

[0066] It is generally agreed that microservices have evolved from service-oriented architecture (SOA), and are commonly considered equivalent to, or a subset of, SOA. Microservices and SOA share many attributes, such as nonfunctional requirements, that are provided by the architecture and that are key for this work. To exemplify, systems are able to discover services at run-time, without the need to have their address fixed at design time. This is usually achieved through some type of service registry, where service producers advertise their offerings enabling consumers to find them even in dynamic environments. Generally, the services communicate only through designed APIs, holding the concepts of information hiding and encapsulation. In this way, services do not share dependencies with each other and can be modified, internally, as needed without impacting the behavior of other services. Further to this, service exchanges commonly happen at run-time and may change based on present conditions. Therefore, services do not need to be aggregated pre-deployment, as in early binding, enabling application self-healing and optimization in the execution environment. These capabilities require more logic that can be added to each system or delegated to a mediator that will organize the network.

[0067] In Fig. 1, a simplified view of a chiplet arrangement 100 is shown. The chiplet arrangement 100 comprises a plurality of chiplets 110a, 110b, 110c, HOd, HOe. The chiplet arrangement 100 in Fig. 1 is disclosed to comprise a plurality of chiplets 110a, 110b, 110c, 1 lOd, 1 lOe, i.e. two or more chiplets, but the skilled person will appreciate that a chiplet arrangement 100 may sometimes include one single chiplet 110a, 110b, 110c, 1 lOd, 1 lOe. The chiplets 110a, 110b, 110c, 1 lOd, 1 lOe are connected by a chiplet network 120 enabling communication between the chiplets 110a, 110b, 110c, HOd, 1 lOe. The chiplet arrangement 100 is controllable by an external interface 150 enabling the chiplet arrangement 100 to control, be controlled by or otherwise interact with one or more external systems 10. The chiplets 110a, 110b, 110c, 1 lOd, 1 lOe of the chiplet arrangement 100 may all be arranged on a common interposer 130 and optionally form a chiplet package 140. In other examples of the present disclosure, the chiplet arrangement 100 may comprise a number of chiplets 110a, 110b, 110c, 1 lOd, 1 lOe arranged on different interposers 130 and / or forming different chiplet packages 140. Regardless of the arrangement or the number of chiplets 110a, 110b, 110c, 1 lOd, 1 lOe, the chiplets 110a, 110b, 110c, 1 lOd, 1 lOe are connected by the chiplet network 120. A chiplet arrangement 100 according to the present disclosure may be referred to as one or more of a multi-chip module (MCM), hybrid IC, 2.5D IC, or an advanced package.

[0068] The chiplet network 120 may be any suitable network or corresponding connection that enables communication between the chiplets 110a, 110b, 110c, 1 lOd, 1 lOe, and / or between chiplets 110a, 110b, 110c, 1 lOd, 1 lOe and the external interface 150. In some examples the chiplet network 120 may be a network configured according to one or more network standards such as UCIe, Bunch of Wires (BoW), OpenHBI, or OIF XSR. The chiplet network 120 is not necessarily formed of one physical or virtual network but may be a combination of one or more physical networks and / or one more virtual networks. This will be further explained in later sections.

[0069] In Fig. 1, the chiplet arrangement 100 is shown comprising five chiplets 110a, 110b, 110c, 1 lOd, 1 lOe. This is for illustrative examples only and the skilled person will appreciate that the chiplet arrangement 100 may comprise any number of chiplets 110a, 110b, 110c, 1 lOd, 1 lOe. In fact, as mentioned and as will be apparent after digestion of the complete disclosure, the teachings presented herein are applicable also to a single chiplet 110a, 110b, 110c, HOd, HOe.

[0070] The skilled person will appreciate that the chiplets 110a, 110b, 110c, 1 lOd, 1 lOe, chiplet arrangements 100 and other features presented herein may be presented in a simplified and / or condensed form in order to make the present disclosure as efficient as possible. For instance, the chiplet arrangement 100 of Fig. 1 will generally require some form of power distribution in order to provide and / or control power to the chiplets 110a, 110b, 110c, 1 lOd, 1 lOe. Such features and configurations are well known to the skilled person and need not be further explained.

[0071] In Fig. 2, an exemplary simplified block diagram of a chiplet 110 is shown. The chiplet 110 comprises at least one hardware resource 112a, 112b, 112c. The chiplet 110 of Fig. 2 is shown with three hardware resources 112a, 112b, 112c, but any number of hardware resources is applicable. At least one of the hardware resources 112a, 112b, 112c of the chiplet 110 is addressable at the chiplet network 120. To this end, a first hardware resource 112a may be a network interface hardware resource configured to connect the chiplet 110 to, and communicate via, the chiplet network 120. A second hardware resource 112b may be a computational hardware resource such as a CPU, a GPU or a microcontroller. A third hardware resource 112c may be a data storage unit, i.e. a memory hardware resource such as a volatile memory or a non-volatile memory. A chiplet 110 comprising a network interface hardware resource, a computational hardware resource and a memory hardware resource may be considered a minimum chiplet 110. However, not all hardware resources 112a, 112b, 112c may be addressable across the chiplet network 120, and from a perspective of the chiplet arrangement 100, a specific chiplet 110 may comprise only a computational hardware resource as an only addressable resource of that specific chiplet 110.

[0072] The chiplet 110 may comprise further hardware resources 112a, 112b, 112c such as, but not limited to, sensor hardware resources. Sensor hardware resources, i.e. data acquisition units, may be exemplified as a temperature sensor, a pressure sensor, a light sensor, an optical sensor, a voltage sensor, a fingerprint sensor etc. Additionally, or alternatively, the chiplet 110 may comprise hardware resources 112a, 112b, 112c in the form of peripheral hardware resources. Peripheral hardware resources may be exemplified as, but not limited to, an interrupt controller, a DMA controller, a digital / analog VO, a DAC, an ADC, a clock, a peripheral I / O device, a peripheral storage device, a peripheral display devices, a peripheral communication devices, etc. Additionally, or alternatively, the chiplet 110 may comprise hardware resources 112a, 112b, 112c in the form of a communication hardware resource. Communication hardware resources may be exemplified as, but not limited to, a PCIe interface or an UCIe interface. Additionally, or alternatively, the chiplet 110 may comprise hardware resources 112a, 112b, 112c in the form of an actuator hardware resource. Actuator hardware resources may be exemplified as, but not limited to, a loudspeaker, a buzzer, a soft-switch, a light source, a display etc.

[0073] 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 e.g. a vendor, supplier or designer of the hardware resource 112a, 112b, 112c. In some examples, some or all hardware resources 112a, 112b, 112c may be associated with a model of the hardware resource 112a, 112b, 112c that may be utilized in simulation of the hardware resource 112a, 112b, 112c.

[0074] The inventors behind the present disclosure have realized that, not only may microservices be deployed and executed by chiplets 110, the chiplets 110 themselves may be managed and controlled correspondingly to microservices. That is to say, hardware recourses 112 of a chiplet 110, or a plurality of chiplets 110, may be configured to form a microsystem 200, see Fig. 3.

[0075] In Fig. 3, a microsystem 200 according to the present disclosure is shown. The microsystem 200 provides behavior based on stored, or obtained data and computation thereupon. The resulting capabilities are externally exposed through one or more produced microservices 400. A microsystem 200 is composed of (e.g., comprises, configured with) one or more hardware resources 112 that execute one to several tasks and processes to form the functionality. A specific microsystem 200 may be associated with one or more hardware resources 112 from one specific chiplet 110 of the chiplet arrangement 100, or associated with hardware resources 112 from two or more chiplets 110 of the chiplet arrangement 100. As will be taught in later sections, microsystems 200 may be dynamically instantiated and subsequently re-worked at runtime. Thus enabling flexible use and reuse of engaged hardware resources 112. The microsystem 200 may comprise configurable or static software (program instructions) stored by and executable by the hardware resource(s) of the microsystem 200. It should be mentioned that microsystems 200 defined solely by the hardware resources 112 and that provide the desired functionality without requiring software. Orchestration of the microsystem(s) 200 is provided by a control plane 300. The orchestration by the control plane 300 of one or more microsystems 200 may comprise, but is not limited to, managing microsystems 200, coordinating the deployment of microsystems 200, scaling microsystems 200, and / or control operation of microsystems 200. The control plane 300 is advantageously further configured to orchestrate microservices 400 exposed at the external communications interface 150. The orchestration by the control plane 300 of one or more microservices 400 may comprise, but is not limited to, managing microservices 400, coordinating the deployment of microservices 400, scaling microservices 400, and / or control operation of microservices 400. The control plane 300 is further advantageously configured to orchestrate binding (association) between a specific microsystem 200 and one or more microservices 400.

[0076] Advantageously, the microservices 400 are registered at an external resource registry associated with the external system 10. The registration of the microservices 400 at the external resource registry of the external system 10 may be provide by the control plane 300. One or more microsystems 200 may be provided with software instructions enabling the one or more microsystems 200 to register (through the control plane 300) their associated microservices 400 at the external resource registry of the external system 10.

[0077] The control plane 300 may be formed as a, for the chiplet arrangement 100, centralized control plane and will generally be described as such. However, it should be emphasized that the present disclosure is applicable also, without limitation, to decentralized or distributed implementations of the control plane 300.

[0078] To exemplify the functionality of the control plane; the control plane 300 may be configured to discover and manage available hardware resources 112 and microsystems 200. This implies monitoring resource usage and availability, as well as allocating and deallocating resources as needed. The control plane 300 may, additionally, or alternatively, be configured to deploy and manage microservices 400 on the available hardware resources 112 by associated microsystem 200. This implies ensuring that each microservice 400 is deployed to an appropriate location and that it may communicate with other microservices 400 as needed. The control plane 300 may, additionally, or alternatively, be configured to provide service scaling. That is to say, as demand for a particular microservice 400 increases or decreases, the control plane 300 may be configured to scale the microservice 400 up or down accordingly. This may involve adding or removing instances of the microservice 400, and / or adjusting the microsystem allocated to each instance of the microservice 400. The control plane 300 may, additionally, or alternatively, be configured to provide health monitoring of the chiplet arrangement 100. This may comprise monitoring health of each microservice 400, and / or microsystem 200 and to detecting and advantageously respond to failures or other issues as they arise. This may involve performing automated health checks, restarting failed microsystems 200 and / or microservices 400 and / or triggering alert notifications when issues occur. The control plane 300 may, additionally, or alternatively, be configured to manage updates to the microservices 200 and / or microsystems 400, in order to ensure that new versions of the services are deployed and rolled out in a controlled and safe manner.

[0079] Using an SOA approach in providing the control plane 300, the control plane 300 may be created by a set of microsystems 200 with associated microservices 400. This is schematically shown in Fig. 4. It may be assumed that the control plane 300 is instantiated and executed locally at each chiplet arrangement 100.

[0080] With reference to Fig. 4, an exemplary embodiment of a chiplet arrangement 100 comprising an advantageous control plane 300 will be presented. In Fig. 4, the control plane 300 comprises a resource orchestrator 410. The resource orchestrator 410 may be configured for orchestrating and coordinating the integration and instantiation of microsystems 400 and their produced and consumed microservices 200. A microsystem integration may be requested through the resource orchestrator 410 exposed as an associated microservice 410 at the external communications interface 150. Such integration requests may indicate which hardware resources 112 of the chiplet arrangement 100 to integrate and, if applicable, provide any suitable microsystem executable code. In addition, lifetime data ranging from the completion of the first service request to a maximum lifetime may be provided. The maximum lifetime may be determined by e.g. edge or cloud-located ServiceRegistry and SystemRegistry to which the microsystem may have to register. If necessary advanced security on-boarding schema may be deployed, this will be further explained in later sections. It should be mentioned that microsystems 200 of the chiplet arrangement 100 are not necessarily static. That is to say, the microsystems 200 may be formed in a static structure, a dynamic structure, a fluid structure, a flexible layout, an evolving compositions or combinations thereof. Orchestration of microsystems 200 may be dynamically renewed, updated, or changed through new requests to the resource orchestrator 410. The resource orchestrator may provide orchestration information to a network manager 440 of the control plane 300. This may be provided in order to configure suitable communication between integrated hardware resources 112. A service integration request will generally integrate and instantiate a microsystem 200 composed of a set of prescribed hardware resources 112 e.g. CPU, Timer, Memory, ADC, etc.

[0081] The resource orchestrator 410 may comprise a preconfigured microsystem 200 of the chiplet arrangement 200 associated with one or more preconfigured microservices 410 of the chiplet arrangement 100. That is to say, the resource orchestrator may be preconfigured. In Fig. 4, the resource orchestrator 410 is shown as a microservice 400. The skilled person will understand that this microservice 410 is associated with a specific microsystem 200. The microservice 400 will be exposed by the control plane 300 and the control plane 300 will provide an interface between the microservice 400 and a specific microsystem 200.

[0082] In Fig. 4 the control plane 300 is further shown comprising a resource scheduler 420. The resource scheduler 420 may be provided to ensure a timely availability of a desired microsystem 200. Scheduling of the hardware resources is advantageous in order to achieve a requested performance and obtain a maximum benefit out of a potential of the chiplet arrangement 100. The resource scheduler is advantageously configured to balance a strict real-time requirement with other types of priorities and / or policies. The skilled person will appreciate that such scheduling is dependent on application strategies, policies regulations, etc. A wide range of such scheduling algorithms are available and have been previously published1(references in

[0083] 1S. Singh and I. Chana, “A survey on resource scheduling in cloud computing: Issues and challenges, Journal of Grid Computing, no. DOI 10.1007 / sl0723-015-9359-2, pp. 217-264, 2016. footnote is hereby incorporated in full to give context to the embodiments of this disclosure). From this, resource scheduling may be considered an engineering optimization problem and will not be further detailed in the present disclosure.

[0084] It should be mentioned that the resource scheduler 420 may reside either internally or externally to the chiplet arrangement 100. In Fig. 4, the resource scheduler 420 is shown as internal to the chiplet arrangement 100 but this is one alternative, and other implementations may be considered depending on application.

[0085] As for the resource orchestrator 410, the resource scheduler 420 may be preconfigured. In Fig. 4, the resource scheduler 420 is shown as a microservice 400, but the skilled person will understand that this microservice 400 is associated with a specific microsystem 200.

[0086] The exemplary control plane 300 in Fig. 4 comprises a resource registry 430. The resource registry 430 may be configured to store data pertaining to the hardware resources 112 of the chiplet arrangement 100. Advantageously, the data comprises information indicating one or more of a resource ID of each hardware resource 112, a physical address of each hardware resource 112 of the chiplet arrangement 100 and / or an electrical address of each hardware resource 112 of the chiplet arrangement 100. The resource registry may comprise further data associated with hardware resources of the chiplet arrangement 100, such as resource specification, configurations data and / or meta data. This data is generally generated at design time and advantageously deployed to the resource registry 430 at a chiplet production time. It should be mentioned that the resource registry 430 is not required to comprise data associated with all hardware resources 112 of the chiplet arrangement 100.

[0087] In the chiplet arrangement 100 of Fig. 4, the control plane 300 further comprises a network manager 440. The network manager 440 is advantageously configured to dynamically configure network connections of the chiplet arrangement 100. That is to say, the network manager 440 is configured to create communication

[0088] Z.-H. ZHAN, X.-F. LIU, Y.-J. GONG, J. ZHANG, H. S.-H. CHUNG, and Y. LI, “Cloud computing resource scheduling and a survey of its evolutionary approaches,” ACM Computing Surveys, vol. 47, no. 4, July 2015.

[0089] M. Kumar, S. C. Sharma, A. Goel, and S. P. Singh, “A comprehensive survey for scheduling techniques in cloud computing,” Journal of Network and Computer Applications, vol. 143, pp. 1-33, 2019. channels suitable for the microsystems 200 of the chiplet arrangement. The network manager may be configured to interface with a variety of bus technologies, such as, but not limited to, PCI or UCIe. The network manager 440 may further be configured to communicate with a variety of components (hardware resources 112, chiplet network 120, external communications interface 150 etc.) of the chiplet arrangement 100. Advantageously, each chiplet 110 and instantiated microsystem 200 are identified at the external communications interface 150 exposing their 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 devices external to the chiplet arrangement 100. This may involve measures such as implementation of efficient protocols for transmitting data over the chiplet network 120, minimizing latency, and / or maximizing bandwidth. Further to this, implementation of error correction mechanisms, flow control mechanisms, and mechanisms for handling errors and exceptions may be provided in order to increase efficiency and reliability in communication.

[0090] As for the resource orchestrator 410, the network manager 440 may be preconfigured. The microservice 400 will be exposed by the control plane 300 and the control plane 300 will provide an interface between the microservice 400 and a specific microsystem 200. This is illustrated in Fig. 4 by the network manager 440 (the microservice 400 of the control plane) provide an external communications interface 150 on an application level (dotted line in Fig. 4). The physical connection of the external communications interface 150 is provided by a suitable hardware resource 112e which is comprised in a microsystem 230 (solid line in Fig. 4). In Fig. 4, the network manager 440 is shown as a microservice 400, but the skilled person will understand that this microservice 440 is associated with a specific microsystem 200.

[0091] As is clearly shown in Fig. 4, each microsystem 210, 220, 230 is specifically addressable at the chiplet network 120. As seen in Fig. 4, this means that each microsystem 200 is configured with a specific address at the chiplet network 120. As understood from the preceding disclosure, a microsystem 200 is a, from software of the control plane 300, virtual composition of hardware resources 112. The specific address of a microsystem 200 at the chiplet networkl20 may be a virtual address provided by e.g., the network manager 440, mapping it to at least one physical address at the chiplet network 120 provided by one or more hardware resources 112 of the microsystem 200.

[0092] The chiplet arrangement 100 of Fig. 4 is an exemplary chiplet arrangement 100 and the features described in reference to Fig. 4 are optional and may be freely combined with each other or any other features described herein.

[0093] It should be mentioned that the control plane 300 and / or the microservices 400, 410, 420, 430, 440 may be pre-configured and / or be instantiated or re-configured based on e.g. time scheduling or events.

[0094] With reference to Fig. 5, some further exemplary microservices 400 will be presented. In Fig. 5, the control plane 300 of the chiplet arrangement 100 comprises a resource monitor 450 associated with a specific microsystem 200 (not shown in Fig. 5). The resource monitor 450 may be configured to capture a status of a large variety of hardware resources 112 and their current and / or specified capabilities. Consequently, status types and capability types are advantageously part of the metadata registered for each hardware resource 112 in the resource registry 430. The transfer of such status data may be provided by electrical communication or / and through a monitoring microservice request. The resource monitor 450 may be configured to provide access to historical data. Historical data may be accessed in order to proceed with e.g., predictive maintenance, optimization etc. Advantageously, the historical data is available only for a limited time, generally determined by a capacity of a storage in relation to an amount of historic data that is generated. The resource monitor 450 advantageously resides in the chiplet arrangement 100 in order to enable appropriate monitoring of its hardware resources 112.

[0095] In Fig. 5, the control plane 300 of the chiplet arrangement 100 further comprise a resource security microservice 460 (labeled “resource security” in Fig. 5 for brevity) associated with a specific microsystem 200 (not shown in Fig. 5). Generally, some form of security is advantageous in most applications. Dependent on application requirements and hardware capabilities chiplet security measures of interest may comprise one or more of physical tampering detection, encryption of data transferred over the chiplet electrical communication (chiplet network 120 etc.), secure on-boarding of software, enabling e.g. over the air (OTA) software updates, secure on-boarding of hardware, 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 offered by the resource security microservice 460 may form part of the metadata registered in the resource registry 430.

[0096] In Fig. 5, the control plane 300 of the chiplet arrangement 100 further comprises a debugger 470 with an associated microsystem 200 (not shown in Fig. 5). The debugger 470 is advantageous in order to support e.g. test and validation of the chiplet arrangement 100, the control plane 300 and instantiated microsystems 200. The debugger 470 may be configured to trace the execution of software instructions in realtime, allowing developers to identify potential issues with hardware access, timing, and / or synchronization. The debugger 470 may be configured to monitor memory access in real-time, allowing developers to detect and diagnose issues with memory corruption, buffer overflows, or other memory-related issues. The debugger 470 may be configured to inspect values of hardware registers of one or more hardware resources 112 in real-time (runtime), allowing developers to diagnose issues related to hardware configuration or control. The debugger 470 may be configured to set breakpoints and / or watch points at specific points in program instructions or at memory addresses, allowing developers to halt execution and inspect the system state at critical points. The debugger 470 may be configured to provide detailed performance profiling information, allowing developers to identify performance bottlenecks and optimize code for better hardware utilization.

[0097] As mentioned, the above exemplified microservices 400 and associated microsystems 200 are provided for explanatory purposes and should in no way be construed as limiting. As indicated in Fig. 5, the control plane 300 may very well comprise other microservices 480 (labeled “other services” in Fig. 5 for brevity) with associated microsystems 200. The examples presented in reference to e.g. Figs. 4 and 5 may be freely combined with each other.

[0098] Generally, dynamic instantiation refers to an ability to create and configure instances of a design or component during run-time. In the present disclosure and associated architecture, it refers to an ability to dynamically create and configure instances of microsystems 200. The use of dynamic instantiation will allow for flexibility and scalability in system design, as it allows for the creation of customized microsystems 200 on demand and may further reduce costs by allowing for the reuse of existing chiplets 110. To this end, the chiplet arrangement 100 is advantageously configurable to host one or several microsystems 200. Each microsystem 200 is configured to produce and / or consume one or more microservices 400. Advantageously, such microsystems 200 are configured to instantiate dynamically during run-time. To enable such instantiating the chiplet arrangement 100 may be configured to expose its hardware resources 112 and their allocation to integrated microsystems and their current usage status / availability.

[0099] Consequently, in order to instantiate a microsystem 200, the chiplet arrangement 100 is advantageously configured to, in run-time (throughout a lifetime of the chiplet arrangement 100), dynamically integrate the chiplets 110 and necessary program instructions to form microsystems 200 and associated produced and / or consumed microservices 400 of the microsystems 200. In addition, the architecture allows for the usage of resources allocated to microsystems that are not in operation. This is provided by the control plane 300 of the present disclosure.

[0100] Microservices 400 are exposed on the chiplet network 120 and / or the external communications interface 150 through the network manager 440. The network manager 440 is advantageously configured to provide the chiplet arrangement 100 with an IP address making it reachable at the external communications interface 150. The network manager 440 is advantageously configured to provide capabilities to also communicate locally with other chiplets 110 in the same chiplet arrangement 100. The control plane 300 allows the orchestration and registry of the microservices 200. The control plane 300 is based on SOA principles; a well-established technology which, therefore, is only briefly covered here.

[0101] System of Systems (SoS) functionality refers to collective behavior and capabilities of a group of interconnected software systems, which together form a larger, more complex system. SoS functionality is concerned with how these individual systems work together to achieve a common goal or set of goals, and how they communicate and share information in order to achieve this. This comprises issues such as interoperability, data exchange, and system integration. SoS functionality is generally important in large-scale software systems, where multiple independent systems need to work together in order to achieve a common objective. As the skilled person appreciates, effective SoS functionality requires careful design and planning, as well as robust communication protocols and system interfaces to ensure that each system is able to interact effectively with the others.

[0102] To integrate the chiplet arrangement 100 into a SoS functionality, the foundational look-up, loosely coupled and late binding properties of the SOA are advantageously supported by the SoS functionality. Eclipse Arrowhead architecture is a commonly known SOA architecture example and reference implementation that may provide a basic control plane meeting SOA principles like look-up, late binding, loose coupling, and security measures e.g. authentication, authorization, etc., and optional security measures, interoperability measures etc. As an example, the basic control plane capabilities are provided in the Eclipse Arrowhead architecture reference implementation by the mandatory / highly recommended microsystems ServiceRegistry system (look-up), Orchestration system (late binding, loosely coupled) and Authorisation system (authorization, authentication). The SoS functionality may provide these features by (based on Eclipse Arrowhead terminology):

[0103] • a ServiceRegistry and an associated ServiceDiscovery microservice

[0104] • an Orchestration system and its associated Orchestration microservice, i.e. the resource orchestrator 410 and its associated microsystem 200.

[0105] • AA security (Authenticating, Authorisation) may be provided by an Authorization system and an associated microservice GetPublicKey.

[0106] • Additional control plane 300 services like e.g. on-boarding security, interoperability translators and adaptors, workflow management and execution2(reference in footnote is hereby incorporated in full to give context to the embodiments of this disclosure), autonomous SoS maintenance and re-engineering3(reference in footnote is hereby incorporated in full to give context to the embodiments of this disclosure).

[0107] 2“Workflow management solutions based on microservices,” Applied Sciences.

[0108] 3A. 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. A chiplet arrangement 100 configured with a control plane 300 as presented herein significantly increases resource utilization, package density (at least per function / service) and engineering efficiency. In general, monolithic hardware, each microsystem 200 of the present disclosure may be equated to one chiplet 110, one ASIC or even one PCB. Since hardware resources 112 may be shared between microsystems 200, resource efficiency is greatly increased, and as no extra footprint is required for additional microsystems 200, assuming there are available hardware resources 112, both physically and scheduling wise, many more services and functions may be provided in the same footprint. The, by software, reconfiguration of hardware as described herein may be described as a virtual re-organization of electrical connections of a chiplet arrangement 100. Additionally, associating a microservice 400 with a microsystem 200 increases engineering efficiency. Microservices 400 allow engineering teams to develop, deploy, and scale individual components independently, rather than e.g., working on a single large codebase. Each microservice 400 focuses on a specific functionality or set of functionalities, enabling smaller, more manageable code repositories. This autonomy reduces coupling between services and makes it easier to update or replace individual components without impacting the entire system. This is inherent to the SOA architecture which, as previously presented, provide late coupling and loose coupling from both a hardware (microsystem 200) and software (microservice 400) perspective. These advantages lead to faster iterations, improved maintainability, and more flexible responses to evolving requirements, all of which boost overall engineering efficiency.

[0109] The incredible flexibility of a chiplet arrangement 100 as present above present challenges for developers seeking to take advantage of this flexibility. For instance, late binding, i.e. association of resources at runtime rather than compile time, and loosely coupled services, i.e. individual components or modules operate independently and have little or no dependencies on each other, from a software perspective is well know. But when late binding and loosely coupled services are applied also to hardware as in the chiplet arrangement 100 presented herein, modeling, optimization, verification and validation of microsystems 200 (i.e. hardware / software combinations) becomes challenging. The inventors behind the present disclosure have identified this challenge and the following sections will provide a method for simulating (modeling) a requested service on a chiplet arrangement 100. The simulation may be utilized to provide a microsystem 200 for deployment on the chiplet arrangement 100. The simulation may be utilized to validate the hardware and / or software functionality of the requested service. The simulation may be utilized to optimize an implementation (i.e. the associated microsystem 200) of the requested service from a hardware and / or software perspective. The simulation may be utilized to determine a utilization and / or a workload the requested service adds to the chiplet arrangement 100. It should be mentioned that, although the method will be explained in a context of a requested service, the teachings may be amended and adapted also for other context such as simulation or optimization of a chiplet arrangement 100 hosting one or more microsystems 200.

[0110] Verification and validation serve complementary roles but address different questions about a product’s correctness and suitability. Generally, verification assesses whether the system has been built correctly, and validation assesses whether the correct system has been built. Verification is concerned with ensuring that a system meets specified design, requirements, and technical standards. Verification may involve checking artifacts like requirements documents, design models, and code against established specifications or rules. In other words, verification sets out to answer a question of whether a product conform to its requirements and design. Validation, on the other hand, is concerned with determining whether a final product fulfills its intended purpose and meets e.g., user needs and requirements in a real -world operational context. Validation sets out to answer a question of whether a product does what the users actually need. In short, verification may be described as internally oriented, comparing a product against formalized specifications, while validation is externally oriented, evaluating the product’s suitability for its intended use. As used herein, validation and verification may be used interchangeably, and the skilled person appreciates that the scope of requirements will determine whether verification or validation is actually performed.

[0111] In Fig. 6, a simplified block diagram of providing a microsystem model 580 from a specific chiplet arrangement 100 is shown. The overview given with reference to Fig. 6 is an introduction to providing the microsystem model 580 and each step and feature will be further explained in coming sections. The flow is initiated by an engineering plan 510. The engineering plan 510 may be obtained as part of a service request. The engineering plan 510 specifies requirements of a service requested from the specific chiplet arrangement 100. In some examples, the engineering plan 510 specifies a services demanded by a user / operator of a chiplet arrangement 100. The specified service is a service that, assuming requirements are met, will be deployed and served on the specific chiplet arrangement 100. The requested service may be anything suitable for the chiplet arrangement 100 such as obtaining a temperature at specific intervals, identifying persons in video images, controlling a heating system based on a provided Al model, implementing autonomous drive in a vehicle etc. Based on the engineering plan 510, a microsystem hardware model 530 is provided. The microsystem hardware model 530 specifies one or more hardware resources 112, e.g. specific chiplets 110 of the chiplet arrangement 100 required for providing the requested service, or advantageously required hardware services. To this end, the microsystem hardware model 530 comprises a hardware resource indicator 532 indicating what hardware resources 112 or hardware services of the chiplet arrangement 110 the microsystem hardware model 530 comprises models of. The hardware resource indicator 532 may indicate specific hardware resources 112, but advantageously, to wholly enable dynamic instantiation of microsystems 200, the hardware resource indicator 532 indicate hardware services. For instance, if the service is identifying persons in video images, an image obtaining hardware resource, a processing hardware resource and a memory hardware resource may be required and specified by the hardware resource indicator 532. These microsystem hardware resources 112 may be from the same chiplet 110 or from different chiplets 110. The microsystem hardware model 530 is simulated using hardware simulation tools and the outcome of this simulation provides one or more hardware capabilities 534 of the microsystem hardware model 530. The hardware capabilities 534 are used to estimate a microsystem software model 560. The microsystem software model 560 comprises microsystem program instructions 562 (labeled “microsystem instructions” in Fig. 6 for brevity). The microsystem software model 560 is simulated on an environment 524 of the chiplet arrangement 100. Based on these simulations, a microsystem model 580 is provided. The microsystem model 580 comprises the microsystem hardware model 520, the microsystem software 560 and one or more microsystem capabilities 584 based on the hardware and software capabilities 534, 564, resulting from the simulations of the respective models 530, 560.

[0112] In Fig. 7, an exemplary method 600 according to the present disclosure is shown. The method 600 shown in Fig. 7 may be implemented as a computer implemented method or a partly computer implemented method where some tasks are wholly or partly manually performed. It should be mentioned that many of the features mentioned in reference to the method 600 are optional.

[0113] The method 600 comprises obtaining 610 the previously mentioned engineering plan 510. The service requested may be defined by specifying a functionality of the service, interfaces of the service, and how it interacts with other components, services and devices. The requested service may be described in broad, functional terms such as “control the ambient temperature within 1 % of a set value” but such broadly requested services will require some processing in order to provide an engineering plan 510. As mentioned, the engineering plan 510 generally comprises hardware requirements 512 and software requirements 514. Although the method 600 will be described with an engineering plan 510 comprising both software requirements 514 and hardware requirements 512, it should be mentioned that some services may be definable with solely hardware requirements 512 or software requirements 514. After reading the present disclosure, the skilled person will be clear on how to adjust the method 600 for only hardware requirements 512 or only software requirements 514 and this disclosure should not be construed as limited to hardware requirements 512 in combination with software requirements 514.

[0114] The engineering plan 510 and associated hardware requirements 512 and software requirements 514 describe, at some level, a functionality and requirements of a specific microsystem 200 for producing and / or consuming one or more microservices 400.

[0115] The engineering plan 510 may be obtained in any suitable way, compiled in any suitable format, but comprise at least an indication of a service requested by a specific chiplet arrangement 100. The engineering plan 510 is generally provided by a user, and advantageously considers chiplet resources and the desired functionality. The engineering plan may comprise specifications, code, configurations, and optionally test cases.

[0116] The hardware requirements 512 may be formatted freely and generally depend on the service (microservice 400) and / or functionality defined by the engineering plan 510. In some examples, the hardware requirements 512 may be provided in an XML or similar formats, but any data set suitable for describing parameters and limits may be utilized. There are many commonly known formats for defining software requirements 514 that may be employed in defining the DW requirements 514 such as, but not limited to, Service Description Language (SDL), Interface Definition Language (IDL), RESTful API Documentation, YAML or JSON Config Files, Domain-Specific Languages (DSLs) etc.

[0117] The hardware requirement 512 may provide requirements for any suitable hardware related parameter. In some examples, the hardware requirement 512 may be broken down into a set of hardware constraints. The constraints may comprise physical constraints, connectivity constraints, availability constraints etc. The physical constraints may comprise constraints relating to one or more of a physical size, a power consumption, a heat dissipation, manufacturing capabilities of the chiplets etc. The connectivity constraints may comprise constraints relating to one or more of a bandwidth, a latency, a reliability of inter-chiplet connections, a supply voltage, a supply current, etc. The availability constraints may comprise constraints relating to one or more of an availability and / or allocation of hardware resources such as, but not limited to, processing cores, memory blocks, I / O interfaces etc.

[0118] Correspondingly, the software requirements 514 may provide requirements for any suitable software related parameter. In some examples, the software requirement 514 may be broken down into a set of software constraints. The constraints may comprise one or more of compatibility constraints, performance constraints, security constraint etc. The compatibility constraints may be provided to ensure software compatibility with the hardware. The compatibility constraints may comprise constraints relating to one or more of instruction set architecture (ISA), memory access patterns, I / O protocols etc. The performance constraints may comprise constraints relating to one or more of processing speed, memory usage, overall efficiency etc. The security constraints may comprise constraints relating to one or more of secure boot, encryption, secure communication protocols etc.

[0119] The method 600 further comprises obtaining 620 a chiplet arrangement hardware model 522. The chiplet arrangement hardware model 522 is a model of the chiplets 110 of the chiplet arrangement 100. The chiplet arrangement hardware model 522 is not required to comprise hardware models of all chiplets 110 of the chiplet arrangement 100, it may suffice to obtain a chiplet arrangement hardware model 522 comprising hardware models of chiplets 110 deemed necessary to fulfill the engineering plan 510. Further to this, not all chiplets 110 of the chiplet arrangement 100 that are part of the chiplet arrangement hardware model 522 need to be modeled with the same accuracy. For instance, some chiplets 110 may be modeled as simple black boxes with e.g. impedances at ports while other chiplets 110 may be more accurately modeled with details of traces, components (e.g. semiconductors, passives etc.) or their respective physical locations.

[0120] The chiplet arrangement hardware model 522 describes an electrical environment of at least a part of the chiplet arrangement 100. The electrical environment may relate to any conditions and / or factors that influence the behavior and performance of electric circuitry of the chiplet arrangement 100, i.e. of the chiplets 110 and / or their interconnection. The electrical environment may comprise any suitable elements within and / or around the chiplet arrangement 100 that may impact operation of the chiplet arrangement 100. Non-limiting examples of data that the electrical environment may describe are voltage sources (presence and characteristics of voltage sources, such as voltage levels, waveforms, etc.), current sources (presence and characteristics of current sources, such as magnitude, direction, etc.), resistors, capacitors, inductances, circuit resistances, circuit capacitances (e.g. time constants), circuit inductances, operating frequencies, temperature, noise, interferences, etc.

[0121] The chiplet arrangement hardware model 522 may be provided in any suitable format and different chiplets 110 of the chiplet arrangement 100 may be modeled differently. In some examples, one or more chiplets 110 or parts of chiplets 110 may be modeled as Simulation Program with Integrated Circuit Emphasis (SPICE) models. Additionally, or alternatively, one or more chiplets 110 or parts of chiplets 110 may be modeled as FEM-models for electromagnetic simulations. Additionally, or alternatively, one or more chiplets 110 or parts of chiplets 110 may be modeled as system level simulink models. Additionally, or alternatively, one or more chiplets 110 or parts of chiplets 110 may be modeled as models for Quite Universal Circuit Simulator (Qucs). Additionally, or alternatively, one or more chiplets 110 or parts of chiplets 110 may be modeled as HSPICE models. Additionally, or alternatively, one or more chiplets 110 or parts of chiplets 110 may be modeled as models for OpenModelica.

[0122] As mentioned, the type of model(s) provided by the chiplet arrangement hardware model 522 may depend on the engineering plan 510. The type of model(s) provided by the chiplet arrangement hardware model 522 may, additionally or alternatively, depend on requirements relating to accuracy of the microsystem model 680, time requirements for preparing the microsystem model 680, processing requirements for preparing the microsystem model 680, etc.

[0123] The method 600 further comprises estimating 630 a microsystem hardware model 530. The microsystem hardware model 530 is estimated based on the engineering plan 510, and advantageously, if available, the hardware requirements 512 of the engineering plan 510 but also software requirements of the engineering plan 510, and a hardware data set 526 of the chiplet arrangement 100. The hardware data set 526 specifies hardware resources 112 of the chiplet arrangement 100, i.e. lists what hardware the chiplet arrangement 100 comprises. The hardware resources 112 listed in the hardware data set 526 may correspond to those hardware resources 112 in the resource registry 430. However, advantageously, the hardware data set 526 is a wider definition of hardware resources 112 not limited to those currently available to the control plane 300 of the chiplet arrangement 100. In some examples, the microsystem hardware model 522 and the microsystem hardware data set 526 describe the same or corresponding hardware resources 112 of the chiplet arrangement 100.

[0124] The microsystem hardware model 530 details (to a level) what specific hardware resources 112 of the chiplet arrangement 100 that the microsystem model 580 may require. The microsystem hardware model 530 may be estimated by mapping the hardware requirements 512 to hardware resources 112 of the chiplet arrangement 100. The microsystem hardware model 530 may be estimated by manually, automatically, or a combination thereof, picking specific hardware resources 112 of the hardware data set 526 that fulfill the hardware requirements 512. To exemplify, estimating the microsystem hardware model 530 may comprise selecting specific processing circuitry of the chiplet arrangement 100, specific persistent and non-persistent storage 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 comprise selecting one specific chiplet 110 of the chiplet arrangement 100 comprising hardware resources 112 in the form of suitable processing circuitry, suitable storage circuitry and suitable sensor circuitry. The microsystem hardware model 530 consequently comprises models of the hardware resources 112 relevant for the engineering plan 510, optionally including affected hardware resources 112 not directly connected to the hardware resources 112 relevant for the engineering plan 510.

[0125] As the microsystem hardware model 530 is estimated based on the engineering plan 510, the microsystem hardware model 530 may not only specify the actual hardware resources 112 that the microsystem model 580 will use, but also further hardware resources 112 that may be electrically affected by the added service of the engineering plan 510. This may include crosstalk between hardware resources 112, ripple induced or injected on supply lines etc.

[0126] It should me mentioned that in examples wherein one or more chiplets 110 of the chiplet arrangement 100 comprise configurable hardware, such as FPGAs and / or CPLDs, the hardware model 530 may be configured to specify configurations of the configurable hardware.

[0127] Specific chiplet arrangements 100 and / or specific hardware resources 112 may be manually (or automatically) selected as an initial microsystem hardware model 530. As will be explained in coming sections, the microsystem hardware model 530 may be iteratively selected and / or several microsystem hardware models 530 may be estimated.

[0128] The method 600 further comprises simulating 640 the estimated microsystem hardware model 530. The simulation is consequently a simulation of a hardware environment of the chiplet arrangement 100 and may be described as an electrical simulation or a hardware simulation. The hardware simulation may be provided using any suitable simulation tool or simulation tools. The hardware simulation is not necessarily provided by one simulation using one hardware simulation tool since different hardware simulation tools and methodologies may be adapted to simulate different aspects of the hardware.

[0129] The simulation may be performed by obtaining relevant hardware models from the chiplet arrangement hardware model 522 based on the microsystem hardware model 530. Depending on a desired accuracy of the simulation, the simulation may be expanded to not only include hardware resources 112 specified by the microsystem hardware resource indicator 532, but also further hardware resources 112 affected by those hardware resources 112 specified by the microsystem hardware resource indicator 532. To this end, and depending on a desired accuracy of the microsystem model 580, the hardware simulation may further comprise hardware resources 112 physically proximal to the hardware resources 112 specified by the microsystem hardware resource indicator 532.

[0130] The different hardware models from the chiplet arrangement hardware model 522 may be modeled together using e.g. virtual prototyping tools and techniques. Virtual prototyping allows creation of a functional software model of a system (the microsystem hardware model 530), which can be used for e.g. simulation and testing. Some non-limiting examples of virtual prototyping tools comprise Synopsys Virtualizer for creating virtual prototypes of systems, including those with microcontrollers and ASICs, and Cadence Virtual System Platform for creating virtual prototypes for systemlevel simulation and software development.

[0131] As mentioned, the hardware simulation may be performed using any suitable tool and is advantageously aligned with the hardware models obtained from the chiplet arrangement hardware model 522. Simulating 640 the microsystem hardware model 530 may comprise SPICE simulations. SPICE simulates behavior of electronic circuits, such as resistors, capacitors, inductors, transistors, and other components. Additionally, or alternatively, simulating 640 the microsystem hardware model 530 may comprise FEM simulations. FEM simulations enable modelling of complex geometries and simulation of electromagnetic fields, antennas, RF components, crosstalk etc. Simulating 640 the microsystem hardware model 530 may comprise HSPICE simulations. HSPICE simulations are commonly used for circuit simulations, especially in the field of semiconductor device modeling. For instance, in case of Hardware Description Language (HDL) Simulators for FPGA, Model Sim or Vivado may be configured to simulate VHDL / Verilog code. In case of simulators for ASICs (including RFIC and MMIC), suites such as Cadence or Synopsys may be employed. In case of microcontroller Simulators, e.g. Arduino, may be simulated using tools like Proteus or simulators within the Arduino IDE. Microprocessor simulators may be simulated using QEMU or other high-level simulators.

[0132] The above simulation tools are given as examples, and further electrical simulation tools such as, PLECS, HOMER Pro, OrCAD PSpice, Sonnet, ADS (Advanced Design System) by Keysight, Proteus, NI Multisim, EMTP-RV (Electromagnetic Transients Program), PowerWorld Simulator, Tanner Tools (Tanner EDA), Xyce, QuickField, TINA-TI (Texas Instruments), Elmer, SaberRD (Saber), etc. are well within the scope of the present disclosure. The skilled person will know which simulation tool(s) are suitable depending on application and / or purpose.

[0133] If more than one hardware simulation tool is utilized, co-simulation may be employed. Co-simulation involves the use of multiple simulation tools in parallel, where each tool simulates a part of the system. During the simulation, the hardware simulation tools exchange data. In order to allow sharing of data between the hardware simulation tools, a data exchange service is generally provided. The data exchange service may be a service using Inter-Process Communication (IPC), network sockets, or file-based communication for data exchange between different simulation tools.

[0134] Outputs from the hardware simulation may vary depending on the type of simulation performed and specific goals of the simulation. The output from the hardware simulation may be exemplified by, but not limited to: waveforms e.g. timedomain waveforms (voltage and / or current waveforms over time) or frequency-domain waveforms (signals represented in frequency domain); AC and / or DC analysis results e.g. steady-state analysis (information about behavior of circuitry at a stable state, may include DC operating points) or AC analysis (frequency response, gain, phase shift, and other AC characteristics); transient analysis results e.g. transient response (behavior over time in response to changes, such as input signal transitions) or rise and fall times (slew rate, duration for signals to transition between specific voltage levels); S- Parameters (Scattering parameters that describe how electrical signals are 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 signals); thermal analysis results (information regarding temperature distribution and thermal behavior) etc. The simulation result may be comprise results from software sweeping one or more parameters of the microsystem hardware model 530 and / or statistical measures of the simulated data.

[0135] The outputs from the hardware simulation are processed to obtain one or more hardware capabilities 534. The hardware capabilities 534 generally comprise data corresponding, at least to a degree, to the hardware requirements 512. That is to say, if the hardware requirements 512 specify a maximum current consumption, the hardware capabilities 534 advantageously comprise data indicating a maximum current consumption of the microsystem hardware model 530. The hardware capabilities 534 may comprise more or fewer hardware metrics than the hardware requirements 512.

[0136] Optionally, in some examples, the method 600 may comprise validating 645 the microsystem hardware model 530. Validation of the microsystem hardware model 530 may comprise determining whether the hardware capabilities 534 provided by the hardware simulation meet requirements specified in the engineering plan 510. In examples wherein the engineering plan comprises one or more test cases, the validation of the microsystem hardware model 530 advantageously comprises determining whether the microsystem hardware model 530 passes the one or more test cases or not. A result of the validation of the microsystem hardware model 530 may be provided as hardware validation data.

[0137] In some examples, the method 600 may comprise repeating the estimating 630 of the microsystem hardware model 530 if the microsystem hardware model 530 fails the validation. In such examples, one or more alternative microsystem hardware models 530 may be estimated 630 and simulated 640 based on the microsystem hardware capabilities 534 of the initial microsystem hardware model. This will provide alternative microsystem hardware capabilities 534 that in turn may be validated 645 to determine whether they meet the requirements of the engineering plan 510 or not.

[0138] Additionally, or alternatively, the method 600 may comprise providing one or more alternative microsystem hardware models 530 regardless of validation of the microsystem hardware model 530 (if performed).

[0139] Due to the general flexibility of a chiplet arrangement 100 in the allocating hardware resources 112 for a microsystem 200, the above iterative approach enables several different hardware configuration to be evaluated. This makes it possible to select a microsystem hardware model 530 that best meet certain requirements. To this end, even if no validation is performed, several different microsystem hardware models 530 may be estimated and simulated. The hardware capabilities 534 may be compared to optimize on certain design parameters for the chiplet arrangement 100 such as current consumption, heat dissipation etc.

[0140] Regardless if an iterative approach is adopted or not, the method 600 comprises obtaining 650 a chiplet arrangement environment model 524 of the chiplet arrangement 100 and deployed software. The chiplet arrangement environment model 524 may describe a software environment of the chiplet arrangement 100 in any suitable way. The chiplet arrangement environment model 524 may comprise a software software design description. In some examples, the chiplet arrangement environment model 524 is a digital twin of the chiplet arrangement 100. The chiplet arrangement environment model 524 will be further explained in reference to Fig. 10.

[0141] The method 600 further comprises estimating 660 a microsystem software model 560 based the hardware capabilities 534 and the software requirements 514. The microsystem software model 560 comprises the produced and / or consumed microservices 400 of the microsystem 200. The microsystem software model 560 may be modeled, in e.g. SysML, UML, Modelica, Matlab, etc. Advantageously, the microsystem software model 560 is modeled to a level of detail that enables machine generation of microsystem program instructions 562, i.e. program code. The microsystem program instructions 562 are configured to control the hardware resources 112 of the chiplet arrangement 100 indicated by the hardware resource indicator 532. The microsystem program instructions 562 are, in some examples, configured to control the hardware resources 112 of the chiplet arrangement 100 to provide the service specified in the engineering plan 510.

[0142] It should me mentioned that in examples wherein one or more chiplets 110 of the chiplet arrangement 100 comprise configurable hardware, such as FPGAs and / or CPLDs, the software model 560 may be configured to model configurations of the configurable hardware.

[0143] The method 600 further comprises simulating 670 the estimated microsystem software model 560. Based on the microsystem software model 560, the specific microsystem 200 and associated services (produced and / or consumed microservices 400) may be manually or automatically coded to executable code. Thereby, microsystem 200 functionality simulation and validation may be made on any hardware including hardware similar (with regards to e.g. CPU, memory, I / O etc.) to hardware of the intended chiplet arrangement 100. Such validation may be made using containers, Virtual Machine (VM), Docker, Kubernetis or other approaches and tools. Simulation of the microsystem software model 560 may be based on the chiplet arrangement environment model 524 and the microsystem software model 560. To exemplify, in some examples, the chiplet arrangement environment model 524 may be a physical chiplet arrangement 100 having deployed thereon a software environment. In such examples, simulating the microsystem software model 560 may comprise executing the estimated microsystem program instructions 562 on the chiplet arrangement 100. In some examples, a chiplet arrangement 100 may not be physically available and in those cases, simulating the microsystem software model 560 may comprise executing the estimated microsystem program instructions 562 on hardware similar to that of the chiplet arrangement running a software similar to software specified by the chiplet arrangement environment model 524.

[0144] The output(s) from the software simulation are processed to obtain one or more software capabilities 564. The software capabilities 564 may be any suitable capability covering any suitable capability within any suitable applications and specific needs within any field including real time control, state machine execution, etc. Some nonlimiting exemplary software capabilities 564 comprise data filtering and / or analytics, application of AI / ML algorithms to data, clustering of data using AI / ML, signal processing of various kinds, digital control, closed loop control, workflow management, event handling, interrupt handling, functionality, QoS, status estimation / reporting, monitoring, resilience monitoring and / or mitigation, etc. The software capabilities 564 generally comprise data corresponding, at least to a degree, to the software requirements 514. That is to say, if the software requirements 514 specify a maximum memory usage, the software capabilities 564 advantageously comprise data indicating a maximum memory consumption of the microsystem software model 560. The software capabilities 564 may comprise more or fewer software metrics than the software requirements 514.

[0145] Optionally and corresponding to the microsystem hardware model 530, in some examples, the method 600 may comprise validating 675 the microsystem software model 560. Validation of the microsystem software model 560 may comprises determining whether the software capabilities 564 provided by the software simulation meet requirements specified in the engineering plan 510. In examples wherein the engineering plan comprise one or more test cases, the validation of the microsystem software model 560 advantageously comprise determining whether the microsystem software model 560 passes the one or more test cases or not. A result of the validation of the microsystem software model 560 may be provided as software validation data.

[0146] In some examples, the method 600 may comprise repeating the estimating 660 of the microsystem software model 560 if the microsystem software model 560 fails the validation. In such examples, 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 that in turn may be validated 675 to determine whether they meet the requirements of the engineering plan 510 or not.

[0147] Additionally, or alternatively, the method 600 may comprise repeating the estimating 630 of the microsystem hardware model 530 if the microsystem software model 560 fails the validation. As outlined above, this means that a fault in validation of the microsystem software model 560 may cause estimation of an alternative microsystem hardware model 530. Additionally, or alternatively, the method 600 may comprise providing one or more alternative microsystem software models 560 regardless of validation of the microsystem software model 560 (if performed).

[0148] The above iterative approach enables several different microsystem software models 560 each based on respectively different microsystem hardware models 530 and / or comprising respectively different microsystem program instructions 562. This allows for selection of a microsystem software models 560 that best meets certain requirements. To this end, even if no validation is performed, several different microsystem software models 560 may be estimated and simulated. The software capabilities 564 may be compared to optimize on certain design parameters for the chiplet arrangement 100 such as current memory utilization, latency, bandwidth, etc.

[0149] The method 600 further comprises compiling 680 the microsystem hardware model 530 with associated hardware capabilities 534 and the microsystem software model 560 with associated software capabilities as a microsystem model 580 comprising microsystem capabilities 584. Compiling 680 may comprise one or more of a lexical analysis, a syntax analysis, a 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 microsystem model 580 comprising microsystem capabilities 584 may be in a format that is configured for deployment on the chiplet arrangement 100. In some examples, the compiling 680 may be described as integrating the microsystem hardware model 530 with associated hardware capabilities 534 and microsystem software model 560 with associated software capabilities into a microsystem model 580 comprising microsystem capabilities 584. The compiling and integrating may be used interchangeably and the choice of word will generally depend on the format and levels of the microsystem hardware model 530, the microsystem software model 560, the microsystem model 580, the hardware capabilities 534, the software capabilities and the microsystem capabilities 584.

[0150] Optionally, in some examples, the method 600 may comprise validating 685 the microsystem model 580. Validation of the microsystem model 580 may comprise validating the effect that the microsystem model 580 has on the chiplet arrangement 100. Validating the microsystem model 580 may comprise determining a utilization of hardware resources 112 of the chiplet arrangement 100. In some examples, validating the microsystem model 580 may comprise determining a change in utilization of hardware resources 112 of the chiplet arrangement 100 with and without the microsystem model 580.

[0151] Although not indicated in Fig. 7, the compiling 680 of the microsystem model 580 may also be iterative, either based on validation 685 outcome or not, such that alternative microsystem models 580 may be provided based on alternative microsystem hardware models 530 and / or alternative microsystem software models 560.

[0152] It should be mentioned that, validation 685 of the microsystem model 580 may result in the engineering plan 510 having to be reworked, and / or a different chiplet arrangement 100 being targeted with the engineering plan 510. This is also applicable if the validation 645 of the microsystem hardware model 530 or the validation 675 of the software model 560 fails.

[0153] Optionally, in some examples, the method 600 may comprise deploying 682 the microsystem model 580 on the chiplet arrangement 100.

[0154] The features of the method 600 have been explained in a specific order for the sake of explanation. The different features of the method 600 may be performed in any suitable order and several of the features may be performed in parallel.

[0155] The method 600 described herein allows for modeling of a microsystem 200 for a specific chiplet arrangement 100. In some examples, the method 600 may further provide a validated microsystem 200, with regards to hardware and / or software validated, for a specific chiplet arrangement 100. In some examples, the method 600 may provide, based on the engineering plan 510, a microsystem 200 adapted with regards to hardware and / or software for a specific chiplet arrangement 100.

[0156] The microsystem model 580 may be described as the microsystem recipe that may dynamically instantiated on a chiplet arrangement 100 at runtime. As indicated above, dynamic allocation of resources for the instantiation of more than one microsystem 200 at runtime is possible due to the combined use of the resource scheduler 420 and network manager 440. As explained above, during design time, shared usage of a given resource for two microsystems 200 may be simulated and optionally tested and / or validated. However, there may be certain limitations in terms of network availability and latency. To exemplify, assume a microsystem A that uses resource 1 and 2 and microsystem B that uses resource 2 and 3. If the microsystems do not need to use the resource 2 continuously, time slots may be used to schedule when the resource 2 will be available for the microsystems A and B. The network needs to be configured according to this schedule and changed at runtime. In the same way, for a given microsystem 200, the allocation of a resource may be changed and updated at runtime, if the hardware and software limitations allow it. The method 600 presented in reference to Fig. 6 allows for simulation of such complex functioning and may provide feasibility of the given microsystem 200.

[0157] An arrangement with, at runtime, reconfigurable hardware and software, such as e.g., the chiplet arrangement 100 configured with a control plane 300 as introduced herein, may be reconfigured, updated or otherwise changed to provide any suitable service, functionality or feature during its lifetime. That means that the chiplet arrangement 100 may be reconfigured / re-organised at runtime, either in hardware but not in the software that the hardware is using, either in software but not in the hardware that the software is using, or both in the hardware and the software. Validating such a system, i.e., a system that is reconfigurable at runtime in both hardware and / or software, presents a unique set of challenges that may be addressed, at least partly, by the methodologies previously described. For instance, the method 600 introduced in reference to Fig. 7 may facility deployment of microsystems 200 that fulfill specific requirement. However, when it comes to validation of a complete chiplet arrangement 100 for use in e.g., safety critical systems, poses a new set of challenges. The dynamic nature of such systems means that a behavior of such a chiplet arrangement 100 may change during operation, making it challenging to predict and test all possible states and interactions. The sheer complexity introduced by the multitude of possible configurations makes validation and qualification very challenging. The control plane 300 enables hardware 110, 112 and software component 400 to operate at multiple modes and / or with multiple configurations, and when combined, they create an exponential number of potential states for the chiplet arrangement 100. This vast state space may be impractical to exhaustively test using traditional validation techniques. Further to this, the unpredictability of interactions between reconfigurable hardware and software components presents further challenges. Changes in hardware configuration may affect software behavior and vice versa, sometimes in non-intuitive ways. These interactions may even cause emergent behaviors of the chiplet arrangement 100 that were not anticipated during a design phase, e.g., at an initial planning stage, a conceptualization stage, a preliminary design phase, etc. For instance, a change in hardware configuration may introduce timing variations that impact software execution, potentially leading to race conditions or deadlocks that are challenging to detect without thorough testing under those specific configurations. Generally, reproducing and diagnosing issues becomes more complicated in systems that are reconfigurable at runtime, such as the chiplet arrangement 100. Since the chiplet arrangement 100 is able change during runtime, an issue observed under a particular configuration may not reoccur consistently, making it difficult to isolate the root cause. Such inconsistency may hamper an ability to perform effective debugging and validation since traditional methods often rely on the assumption that the system behavior is deterministic and repeatable under the same conditions. Consequently, a testing process may become more resource-intensive and time-consuming compared to systems that are comparably static. Developing test cases that cover a representative subset of configurations requires careful planning but may still leave gaps in coverage. Additionally, managing and maintaining the test environment to support hardware reconfiguration adds logistical complexity. Hardware changes (reconfigurations) of the system under test (the chiplet arrangement 100) might necessitate physical modifications of test equipment or the use of specialized test equipment, further complicating the validation process.

[0158] Specifically in a realm of safety-critical systems, reconfigurability of hardware and software at runtime such as that enabled by the chiplet arrangement 100 and control plane 300 presented herein, will be challenging to get approved for such use. As used herein, safety-critical applications are those in which failures or malfunctions may lead to considerable harm, such as loss of life, (severe) injuries, environmental damage, substantial property loss, etc. One example is aviation systems, where flight control software and avionics are generally required to operate flawlessly to ensure the safety. In the medical field, devices like pacemakers, insulin pumps, and life-support machines are generally considered critical system, as any malfunction may directly impact patient health. Further, nuclear power plants rely on safety-critical control systems that monitor and regulate nuclear reactions to prevent catastrophic events. Automotive systems for vehicle safely such as anti-lock braking systems (ABS), electronic stability control, airbag deployment mechanisms, etc. are generally classified as safety-critical systems. Additionally, railway signaling and control systems, industrial process control systems in e.g., chemical plants or oil refineries, space exploration equipment, military defense systems, control systems for electrical grids and water treatment facilities generally require high levels of reliability and are considered safety-critical systems. A safety- critical system is generally subject to stringent standards and regulations in order to ensure safe and reliable operation under substantially all conditions.

[0159] General validation relying on e.g., empirical testing and / or simulation, may not detect all issues or even test all configuration, especially in the context of the chiplet arrangement 100. For the chiplet arrangement 100, employing formal validation methods may provide substantial benefits in ensuring compliance with specifications, standards and regulations for a complete state space of the chiplet arrangement 100 and control plane 300. Formal methods provide a mathematical framework for specifying and verifying system behavior across all possible configurations. They enable an exhaustive analysis of the state space of the chiplet arrangement 100, providing mathematical prof that e.g., certain safety properties are being held regardless of how the hardware and software are reconfigured at runtime. By proving the correctness of the chiplet arrangement 100 through mathematical verification, formal methods reduce the reliance on extensive empirical testing, which may be impractical or insufficient for systems with a vast number of configurations.

[0160] Additionally, formal methods may enhance reproducibility and diagnosability of issues. For instance, if a behavior of the chiplet arrangement 100 is specified mathematically, any deviations from the expected behavior may be traced back precisely within the formal model. This precision aids in debugging and allows for more efficient resolution of problems. It also contributes to consistent performance, as formal verification can ensure that real-time constraints and resource utilization requirements are met under all configurations. Specifically for safety-critical applications of the chiplet arrangement 100, benefits of formal methods may become particularly pronounced. Formal methods generally provide a higher level of confidence in a reliability and safety of the chiplet arrangement 100 by ensuring that all possible behaviors, e.g., stated requirements, specification, etc., have been considered and verified. This comprehensive validation may be important for ensuring, and conveying, that regulatory standards are met increasing a stakeholders' trust in operation of the chiplet arrangement 100.

[0161] Formal methods generally comprise three distinct components, formal specification, formal verification and formal development. These components will be briefly explained in the following.

[0162] A formal specification may be described as a precise mathematical description of a system's properties and behaviors. A formal specification is provided to eliminate, or significantly reduce a risk of ambiguities that may be inherent in natural language specifications. A formal specification may be provided in a formal language such as Z notation4,5, Vienna Development Method (VDM)6, B-Method7, Alloy8, or TLA+9, these formal languages may generally also be used for validation. For example, Hardware Description Languages (HDLs) such as Verilog and VHDL, along with assertion languages like SystemVerilog Assertions (SVA), may be used to formally define system behavior and constraints. Formal languages are generally grounded on a mathematical foundation in set theory and logic. They use mathematical constructs to define data types, functions, and system states. Formal languages aim for unambiguity by utilizing theses precise mathematical constructs with support for abstraction which allow e.g., developers to abstract away implementation details and focus on what the system should do, rather than how it should be done.

[0163] 4J. M. Spivey; “The Z Notation: A Reference Manual” (2nd ed.); Prentice Hall, 1992 which is hereby incorporated by reference in full and for all purposes.

[0164] 5J. Woodcock, J. Davies; "Using Z: Specification, Refinement, and Proof'; Prentice Hall, 1996 which is hereby incorporated by reference in full and for all purposes.

[0165] 6C. B. Jones "Systematic Software Development Using VDM (2nded.)"; Prentice Hall, 1990 which is hereby incorporated in full by reference and for all purposes.

[0166] 7J-R Abrial; “The B-Book: Assigning Programs to Meanings”; Cambridge University Press, 1996 which is hereby incorporated by reference in full and for all purposes.

[0167] 8D. Jackson; “Software Abstractions: Logic, Language, and Analysis”; MIT Press, 2006 which is hereby incorporated by reference in full and for all purposes.

[0168] 9L. Lamport; ’’Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers”; Addison-Wesley, 2002 which is hereby incorporated by reference in full and for all purposes. A formal verification may be described as a process of using mathematical proofs to demonstrate that a system conforms to its formal specification. Formal verification may comprise theorem proving, i.e., creating logical proofs that certain properties hold within the system, model checking, i.e., automatic exploration of substantially all possible states of a system to verify properties like safety (nothing bad happens) and liveness (something good eventually happens). Techniques such as equivalence checking, property checking, and model checking may be applied to ensure that a design meets specifications and function correctly across substantially all possible scenarios, substantially eliminating the need for exhaustive simulations.

[0169] Formal development may be described as a methodical transformation of a formal specification into an executable program, ensuring correctness at each step. Formal development may use refinement techniques to progressively introduce implementation details while maintaining alignment with the formal specification. Tools like High-Level Synthesis (HLS) may be utilized to refine high-level formal descriptions into concrete implementations while maintaining correctness throughout the development process.

[0170] The method 600 introduced with reference to Fig. 7 may, in some examples, be implemented based at least in part on formal methods. For example, obtaining 610 the engineering plan 510 may be provided as previously described, but the engineering plan 510 may, in some examples, comprise one or more mathematical definitions of the hardware requirements 512 and / or software requirements 514 of the microsystem 200. Further to this, the obtained 620 chiplet arrangement hardware model 522 a may be an at least partly mathematically defined chiplet arrangement hardware model 522. The mathematically defined portion(s) of the chiplet arrangement hardware model 522 may comprise a mathematical definition of at least a part of the electrical environment of the chiplet arrangement 100. The hardware data set 526 may be configured to mathematically define, at least part of, the hardware resources 112 of the chiplet arrangement 100. Based on the mathematically defined hardware requirements 512 and hardware data set 526, a mathematically defined microsystem hardware model 530 may be determined 630. It should be noted that the method 600 of Fig. 7 indicates that the microsystem hardware model 530 is estimated 630, also the mathematically defined microsystem hardware model 530 may be considered estimated 630, but given the mathematical definition provided by the formal method, determining may better describe this step. Correspondingly, the microsystem hardware model 530 is not required to be simulated 640 (although it may be) to provide the hardware capabilities 534, but the microsystem hardware model 530 may be validated 640 to provide a mathematical definition of at least part of one or more hardware capabilities 534. In examples wherein not all models, requirements and / or data are wholly mathematically defined, the hardware capabilities 534 may be provided by a combination of simulation and formal (mathematical) validation. As with e.g., the engineering plan 510, and at least partly mathematically defined chiplet arrangement environment model 524 may be obtained 650. The at least partly mathematically defined chiplet arrangement environment model 524 may comprise a mathematical definition of at least part of the software environment of the chiplet arrangement 100. Also, the microsystem software model 560 may be determined 660 rather than estimated 660 when formal methods are employed. To this end, a mathematical definition of at least part of the microsystem software model 560 may be determined 660. The mathematically defined microsystem software model 560 may also be validated 670 rather than simulated 670, although, as with the microsystem hardware model 530, it may very well be at least partly simulated. The validation 670 of the mathematically defined microsystem software model 560 may provide a mathematical definition of at least part 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 may be determined 680.

[0171] Determining 680 the microsystem model 580 may, in some examples, comprise compiling the at least partly mathematically defined microsystem software model 560, hardware capabilities 534, and software capabilities 564. The microsystem model 580 may thereafter be deployed on the chiplet arrangement 100.

[0172] The method 600 presented in reference to Fig. 7 is concerned with providing a microsystem 200 for deployment at a chiplet arrangement 100, optionally according to, at least partly methods. The provided microsystem 200 may be a validated microsystem, optionally a microsystem 200 validated by formal methods. However, the corresponding methodology may be applied when providing a chiplet arrangement 100 configured with the control plane 300. As previously indicated, in order to fully validate the chiplet arrangement 100 with the control plane 300, a vast state space will have to be covered. Further to this, for safety critical applications, some plausibility that the chiplet arrangement 100 complies with requirements across the entire state space may be required. As an example, the chiplet arrangement 100 may be validated at e.g., four different ambient temperatures, -40°C, 0°C, 25°C and 75°C, but there may be a risk that internal temperature compensation of one or more chiplets 110 may cause changes in a behavior of the chiplet arrangement 100 at other temperatures than the ones explicitly tested. It should be mentioned that, given the reconfigurability of microsystems 200 as defined herein, the formal verification may cover microsystems reconfigurable into a plurality of different configurations of the hardware resources 112 of the chiplet arrangement 100, where each configuration may have different software models 560 (generally with common software capabilities 564) providing significantly larger state space compared to historic, monolithic hardware configurations. For instance, in another example, the chiplet arrangement 100 may be validated using three different temperature sensing hardware resources 112, each using a different time bases for reporting temperature. However, the chiplet arrangement 100 may very well comprise further temperature sensing hardware resources 112 reporting temperature at time bases different that the validated temperature sensing hardware resources 112. These two examples may be combined, increasing the validation space even further. Formal verification may provide a tool to effectively validate substantially the complete state space of the chiplet arrangement 100, at least a state space that is mathematically definable.

[0173] To this end, Fig. 8 presents a method 1000 for, at least partly, formal validation of a chiplet arrangement 100 configured with a control plane 300. The method 1000 may be a wholly or partly computer implemented method. The method 1000 may be performed using any suitable hardware and / or software.

[0174] The method 1000 comprises obtaining 1010 an at least partly mathematically defined chiplet arrangement hardware model 522. In other words, the hardware model 522 may very well be the corresponding hardware model 522 introduced in reference to Fig. 6 but with one or more mathematical definitions. That is to say, the at least partly mathematically defined chiplet arrangement hardware model 522 comprises a mathematical description of at least a part of an electrical environment of a chiplet arrangement 100. The chiplet arrangement 100 may be any suitable chiplet arrangement 100, such as the chiplet arrangement 100 introduced with reference to Fig. 1.

[0175] In some examples, the chiplet arrangement hardware model 522 may be a non- formal chiplet arrangement hardware model 522, i.e., a non-mathematically defined chiplet arrangement hardware model 522, or a subset of the chiplet arrangement hardware model 522 may be a non-formal chiplet arrangement hardware model 522. Such a non-mathematically defined chiplet arrangement hardware model 522 may be described using e.g., one or more natural languages rather than a formal language. In such examples, the method 1000 may comprise translating 1015 the non-mathematically defined chiplet arrangement hardware model 522, or one or more non-mathematically defined parts of the chiplet arrangement hardware model 522, to a mathematically defined chiplet arrangement hardware model 522 or a part of a mathematically defined chiplet arrangement hardware model 522.

[0176] The method 1000 further comprises obtaining 1020 an at least partly mathematically defined chiplet arrangement environment model 524. In other words, the chiplet arrangement environment model 524 may very well be the corresponding chiplet arrangement environment model 524 introduced in reference to Fig. 6 but with one or more mathematical definitions. That is to say, the at least partly mathematically defined chiplet arrangement environment model 524 comprises a mathematical definition of a software environment of the chiplet arrangement 100. The software environment comprises a chiplet control plane 300 as introduced with reference to Fig. 3.

[0177] In some examples, the chiplet arrangement environment model 524 may be a non-formal chiplet arrangement environment model 524, i.e., a non-mathematically defined chiplet arrangement environment model 524, or a subset of the chiplet arrangement environment model 524 may be a non-formal chiplet arrangement environment model 524. Such a non-mathematically defined chiplet arrangement environment model 524 may be described using e.g., one or more natural languages rather than a formal language. In such examples, the method 1000 may comprise translating 1025 the non-mathematically defined chiplet arrangement environment model 524, or one or more non-mathematically defined parts of the chiplet arrangement environment model 524, to a mathematically defined chiplet arrangement environment model 524 or a part of a mathematically defined chiplet arrangement environment model 524.

[0178] The method 1000 further comprises obtaining 1030 one or more mathematically defined chiplet arrangement requirements. The chiplet arrangement requirements will be further explained in reference to Fig. 9 but comprise one or more hardware requirements 512 for the chiplet arrangement 100 or software requirements 514 for the software environment of the chiplet arrangement 100. The hardware requirements 512 and / or the software requirements 514 may very well be the corresponding hardware requirements 512 and the software requirements 514 introduced in reference to Fig. 6 but with one or more mathematical definitions.

[0179] Also the chiplet arrangement requirements may be non-formal chiplet arrangement requirements, i.e., non-mathematically defined chiplet arrangement requirements, or a subset of the chiplet arrangement requirements may be non-formal chiplet arrangement requirements. Such non-mathematically defined chiplet arrangement requirements may be described using e.g., one or more natural languages rather than a formal language. Correspondingly, the hardware requirements 512 and / or the software requirements 514 may non-formal hardware requirements 512 or software requirements 514, or a subset of the hardware requirements 512 and / or the software requirements 514 may non-formal hardware requirements 512 or software requirements 514. Such non-mathematically defined hardware requirements 512 and / or the software requirements 514 may be described using e.g., one or more natural languages rather than a formal language. In such examples, the method 1000 may comprise translating 1035 the non-mathematically defined chiplet arrangement requirements, hardware requirements 512 and / or the software requirements 514, or one or more non- mathematically defined parts of the chiplet arrangement requirements, hardware requirements 512 and / or software requirements 514, to mathematically defined chiplet arrangement requirements, hardware requirements 512 and / or software requirements 514 or part of mathematically defined chiplet arrangement requirements, hardware requirements 512 and / or software requirements 514.

[0180] The method 1000 further comprises validating 1040 the chiplet arrangement environment model 524 on the chiplet arrangement hardware model 522. The validating 1040 is performed by mathematically proving that at least some of the mathematically defined parts, or the whole, chiplet arrangement environment model 524 on at least some of the mathematically defined parts, or the whole, chiplet arrangement hardware model 522 fulfills the chiplet arrangement requirements. The validating 1040 may be described as formal validation of the chiplet arrangement environment model 524.

[0181] The method 1000 may, optionally, in some examples, further comprise deploying 1050 the chiplet arrangement environment model 524 on the chiplet arrangement 100.

[0182] Fig. 9 shows a block diagram of an example computer system 900, or system 900 for short, for implementing the techniques described herein. Although some features may be not specifically mentioned in reference to the example system 900 of Fig. 9, the system 900 of Fig. 9 may be adapted to provide any feature, functionality or effect described herein. Specifically, the system 900 of Fig. 9 may be configured to provide any feature, functionality or effect described in reference to validating a microsystem 400 and / or a chiplet arrangement 100. The system 900 may be a wholly or partly integrated system 900. In some examples, the system 900 may be wholly or partly integrated in a server system and / or a distributed system. In some examples, the system 900 is wholly or partly integrated in a chiplet arrangement 100. The dividing and allocation of the system 900 is to comprise functionality and / or services, as well as physical hardware and system components.

[0183] In the following, different features, services, functionality and devices associated with the system 900 will be described. It should be mentioned that these features, services, functionality and devices may be freely combined and that none of them are to be considered essential. Although the features, services, functionality and devices may be described as isolated blocks, this division if the features, services, functionality and devices is purely for explanatory and illustrative purposes and should not be construed as limiting to the implementation of the teachings presented herein.

[0184] The system 900 comprises or is operatively connected to one or more processors 910 or other computational resource. A processor 910 as used herein may be any suitable processer, processing circuitry, controller or control circuitry. The computing device 900 further comprises or is operatively connected to one or more memories 920. The memories 920 may be one or more non-transitory computer- readable media 810. Non-transitory computer readable media as used herein may be any suitable non-volatile computer readable storage such as, but not limited to, one or more and / or combinations of hard drives, solid-state drives (SSDs), optical discs such as CDs, DVDs, and Blu-ray discs, flash drives, USB drives, memory cards like SD cards and microSD cards, magnetic tapes, ROM (Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), RAM (Random Access Memory) when part of a persistent storage system, network-attached storage (NAS) devices, etc. The memory 920 may comprise (store) instructions executable by the processor(s) 910. These instructions, when executed, may cause the processor(s) 910 to perform specific operations, functions and features. In the following, these operations, features and functions will be described in reference to the general system 900.

[0185] The system 900 comprises a requirement obtainer 930. The requirement obtainer 930 is configured to obtain, receive or otherwise acquire one or more requirements associated with a chiplet arrangement 100 and / or a microsystem 400. In some examples, the requirement obtainer 930 may be configured to obtain an engineering plan 510, such as the engineering plan 510 introduced herein with reference to e.g., Fig. 6. In some examples, the requirement obtainer 930 may be configured to obtain one more hardware requirements 512 and / or one or more software requirements 514. The one more hardware requirements 512 and / or one or more software requirements 514 may be obtained directly by the requirement obtainer 930. In some examples, the one 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 obtainer 930 may be configured to obtain one or more chiplet arrangement requirements 516. The chiplet arrangement requirements 516 may correspond to the engineering plan 510 but are generally concerned with requirements for the chiplet arrangement 100 as a whole rather than a specific functionality or microsystem 400. The chiplet arrangement requirements 516 may comprise one more hardware requirements 512 and / or one or more software requirements 514 for the chiplet arrangement 100. In some examples, the requirement obtainer 930 may be configured to provide one or more of the features described in reference to the method 600 of Fig. 7 such as, but not limited to, obtaining 610 the engineering plan 510.

[0186] As with the hardware requirements 512 for a microsystem 400, the hardware requirements 512 for a chiplet arrangement 100 may provide requirements for any suitable hardware related parameter. Correspondingly, the software requirements 514 for the chiplet arrangement may, as the software requirements 514 for the microsystem 400, provide requirements for any suitable software related parameter.

[0187] The system 900 further comprises a model obtainer 940. The model obtainer 940 is configured to obtain, receive or otherwise acquire one or more models associated with a chiplet arrangement 100 and / or a microsystem 400.

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

[0189] In some examples, the model obtainer 940 is configured with a microsystem model obtainer 945 configured to obtain, receive or otherwise acquire one or more models associated with a microsystem 400. The microsystem model obtainer 945 may be configured with a hardware model estimator 946 configured to estimate, determine or otherwise obtain one or more microsystem hardware models 530. The hardware model estimator 946 may be configured to estimate a microsystem hardware model 530 as outlined in reference to e.g., the estimating 630 of a microsystem hardware model 530 of the method 600 in Fig. 7. Additionally, or alternatively, in some examples, the microsystem model obtainer 945 may be configured with a software model obtainer 948 configured to obtain, receive or otherwise acquire one or more software models 524 of the microsystem 400. The software model 524 of the microsystem 400 may be the environment model 524 introduced in reference to Fig. 6.

[0190] The system 900 may further comprise a validator 960. The validator 960 may comprise a chiplet arrangement validator 961 and / or a microsystem validator 965. The chiplet arrangement validator 961 may be configured to validate a chiplet arrangement 100 according to any suitable validation procedure to provide one or more hardware capabilities 535 and / or software capabilities 565 associated with the chiplet arrangement 100. These hardware capabilities 535 and software capabilities 565 may correspond to the hardware capabilities 534 and software capabilities associated with a microsystem 400 as introduced in reference to Fig. 6. In some examples, the chiplet arrangement validator 961 is configured to validate at least a portion of the chiplet arrangement 100 using one or more formal methods, i.e., mathematically prove that at least a part of the chiplet arrangement 100 fulfills at least a part of the chiplet arrangement requirements 516, the hardware requirements 512 and / or the software requirements 514. In some examples, the validator 960 may be configured to provide one or more of the features described in reference to the method 600 of Fig. 7 such as, but not limited to, estimating 630 the microsystem hardware model 522, estimating 660 the microsystem software model 524, simulating 640 the microsystem hardware model 522, simulating 670 the microsystem software model 524, validating 645 the microsystem hardware model 522, validating 675 the microsystem software model 524, compiling 680 the microsystem model 580, and / or validating 685 the microsystem model 580. As mentioned, by configuration of the metrics the validator 960 uses for validation, the validator 960 may be configured to perform verification without limitation or loss of compatibility.

[0191] Correspondingly, the microsystem validator 965 may be configured to validate at least a portion of the microsystem 400 using one or more formal methods, i.e., mathematically prove that at least a part of the microsystem 400 fulfills at least a part of the engineering plan 510, the hardware requirements 512 and / or the software requirements 514. Additionally, or alternatively, the microsystem validator 965 may be configured to validate least a portion of the microsystem 400 using one or more non- formal methods such as those outlined in reference to Fig. 7.

[0192] The chiplet arrangement validator 961 may be configured to validate a chiplet arrangement 100 according to any suitable validation procedure to provide one or more hardware capabilities 535 and / or software capabilities 565 associated with the chiplet arrangement 100. These hardware capabilities 535 and software capabilities 565 may correspond to the hardware capabilities 534 and software capabilities associated with a microsystem 400 as introduced in reference to Fig. 6.

[0193] In some examples, the system 900 may comprise a translator 970. The translator 970 is configured to translate one or more non-formal requirements or models to corresponding formally defined requirements or models. In other words, the translator 970 is configured to formalize non-formal data. The translator 970 may be configured to translate the non-formal requirements or models in full or in part. In some examples, the non-formal requirements or models are provided in a natural language. To exemplify, assume that the translator 970 is configured to translate a non-formal requirement from natural language into a formal requirement. The translator 970 may interpret the requirement to make sure it is well-understood, and then identify boundaries and scope of the requirement. This may involve determining what boundaries of a system (e.g., a microsystem 400 or a chiplet arrangement 100) subject to the requirements. That is to say, the translator 970 may determine what lies within the system (inputs, outputs, processes) and what lies outside it (external systems, users). Understanding interactions between the system and its environment helps in defining clear interfaces and responsibilities. From the non-formal requirements, one or more functional requirements may be extracted. This may comprise operations, data manipulations, and responses to certain inputs or events. From the functional requirements, data and state variables may be defined. This may comprise identifying data elements (such as variables, constants, and data structures) together with the system's state at any given time. Based on this, the requirement may be formalized using a formal specification language like Z notation, VDM, or TLA+. This means translating identified components into mathematical constructs. This may comprise defining sets to represent collections of entities, relations to model associations between entities, and functions or operations to represent system behaviors.

[0194] In some examples, the system 900 may comprise a deployer 980. The deployer 980 may comprise a chiplet arrangement deployer 981, a microsystem deployer 985 and / or a microservice deployer 989. The chiplet arrangement deployer 981 may be configured to deploy a software configuration at a chiplet arrangement 100, such as a software configuration comprising a full software configuration comprising e.g., the control plane 300 with one or more microsystems 200 and associated microservice 400. The microsystem deployer 985 may be configured to deploy one or more microsystems 200 and / or microsystem models 580 at the chiplet arrangement 100. The microservice deployer 989 may be configured to deploy one or more microservices 400 and / or microservice models at the chiplet arrangement 100. The deployer 980 may, in some examples, be configured to compile microsystem hardware models 530, microsystem software models 560 and / or microsystem models 580. The deployer 980 may be configured to provide any deployment mentioned herein such as in reference to the control plane 300 in Figs. 3-5. In some examples, the model deployer 980 may be configured to provide one or more of the features described in reference to the method 600 of Fig. 7 such as, but not limited to, compiling 680 the microsystem model 580 and / or deploying 682 the microsystem model 580.

[0195] As a specific example, consider a natural language requirement reading “The system shall allow a user to log in if they provide a valid username and password. Upon successful login, the user gains access to their account dashboard". The translator 970 may formalizing this requirement to provide a formal requirement using Z notation. The translator defines given sets for 'USERNAME' and 'PASSWORD' and a state schema that comprises mapping ' known users' from usernames to passwords and a set 'logged in' representing currently logged-in users. Operations like 'Login' may be specified with precise preconditions and postconditions. The 'Login' operation may accept inputs 'username?' and 'password?', and produce an output ' success!' . The formal specification may state that if the provided credentials match those in ' known users' , the user is added to 'logged in', and ' success!' is true. Otherwise, 'logged in' remains unchanged, and 'success!' is false.

[0196] As explained, the system 900 presented in Fig. 9 may be configured to operate in according with one or more formal methods. By way of example, consider a a simple counter that increments upon receiving a signal and resets after reaching a maximum value, an Increment operation. This functionality may be implemented as a microservice 400 on a chiplet arrangement 100. For such a functionality, the requirement obtainer 930 may obtain requirements such as:

[0197] 1. The system maintains a state variable counter, which is a natural number (nonnegative integer).

[0198] 2. The counter has an upper limit defined by a constant MAX VALUE.

[0199] 3. Upon receiving an increment signal, the system increases the counter by one.

[0200] 4. If the counter reaches MAX VALUE, the next increment resets the counter to zero.

[0201] 5. The system shall always ensure that 0 < counter < MAX_VALUE The translator 970 may formalize these requirements using a formal specification language like Z notation or a formal method like the B-Method, but assume that a mathematical notation is used. The translator 970 may mathematically define a constant MAX VALUE e N where MAX VALUE > 0 and MAX VALUE = 10, a state variable counter E N, where 0 < counter < MAX_VALUE having an initial state as counter=0. This may be expressed in e.g., python as:

[0202] Increment =

[0203] [ counter E N A 0 < counter < MAX_VALUE ] — >

[0204] ( ( counter < MAX VALUE A counter1= counter + 1 ) V ( counter = MAX_VALUE A counter1= 0 ) ) The model obtainer 940 may obtain a formal implementation of the functionality in e.g., Ada, Pascal, or even pseudocode. An implementation of this increment procedure may look like:

[0205] CONSTANT MAX VALUE := 10;

[0206] VARIABLE counter : INTEGER := 0;

[0207] PROCEDURE Increment IS

[0208] BEGIN

[0209] IF counter < MAX VALUE THEN counter := counter + 1;

[0210] ELSE counter := 0;

[0211] END IF;

[0212] END PROCEDURE;

[0213] This implementation directly mirrors the formal specification, and should ensure that the code reflects the intended behavior precisely. The validator 960 may validate the implementation which involves proving that the implementation maintains the system's invariants (0 < counter < MAX VALUE) and adheres to the specified behavior under all possible conditions, i.e., that this invariant is maintained after each execution of the Increment procedure. Assume the invariant holds before the execution of Increment, i.e., 0 < counter < MAX VALUE. The validator 960 may consider two cases based on the value of counter before the procedure executes: Case 1 : counter < MAX_VALUE

[0214] Before Increment: counter > 0 (since counter is a natural number and the invariant holds), counter < MAX VALUE.

[0215] During Increment:

[0216] The condition counter < MAX VALUE is true. counter is updated to counter + 1.

[0217] After Increment: counter' = counter + 1.

[0218] Since counter < MAX_VALUE, counter + 1 < MAX_VALUE. Therefore, 0 < counter' < MAX VALUE.

[0219] Conclusion, the invariant holds after the operation.

[0220] Case 2: counter = MAX_VALUE

[0221] Before Increment: counter = MAX VALUE.

[0222] During Increment:

[0223] The condition counter < MAX VALUE is false. counter is set to 0.

[0224] After Increment: counter' = 0.

[0225] Therefore, 0 < counter' < MAX VALUE.

[0226] Conclusion, the invariant holds after the operation.

[0227] For both cases, the invariant 0 < counter < MAX VALUE is preserved, and it has been formally verified that the implementation maintains the system's integrity according to the formal specification. However, the validator 960 may further be configured to prove that the Increment operation behaves as specified.

[0228] If counter < MAX VALUE, then counter' = counter + 1. From the implementation, when counter < MAX VALUE, counter is incremented by one, which matches the requirements.

[0229] If counter = MAX VALUE, then counter' = 0. From the implementation, when counter = MAX VALUE, counter is reset to zero, which also aligns with the requirements.

[0230] Thus, the implementation correctly implements the Increment operation as defined in the formal specification.

[0231] The above example is simplistic, but corresponding methodology may be applied when ensuring that e.g., the compiled code does not provide memory leaks or cause excessive heating of the hardware.

[0232] In Fig. 10, an exemplary software architecture of a chiplet arrangement environment model 524 is shown. The chiplet arrangement environment model 524 in Fig. 10 is one non-limiting example and is provided to present a conceptual idea of some hierarchies of the chiplet arrangement environment model 524. The hierarchies in Fig. 10 are hierarchies known to the skilled person and each hierarchy will only be briefly and generally explained. Although the hierarchies are described in an order, any one or more of the hierarchies may be left out without affecting other hierarchies. In Fig. 10, the chiplet arrangement environment model 524 comprises models of both the hardware and the software that are coupled.

[0233] The hardware models may be described by chiplet-based architecture modeling that may comprise package-level integration design, that may comprise heterogeneous integration that may comprise electronic design automation (EDA) that may comprise one or more of multi-chip module design, system on chip (SoC) design or integrated circuit (IC) design. Package-level integration design may refer to a process of designing and organizing integration of various hardware components within a system at package level. A package, in this context, is a higher-level abstraction that encapsulates multiple hardware components, such as integrated circuits, modules, or subsystems, into a cohesive unit. Package-level integration design may involve defining structures, connectivity, and interfaces at a higher level of abstraction. Heterogeneous Integration may refer to design and integration of diverse types of components, technologies, or materials within a single hardware system. This approach may involve combining various elements with different properties, functionalities, or manufacturing processes to achieve improved overall system performance or capabilities. EDA is a category of software tools that may be used for designing and modeling electronic systems and integrated circuits (ICs). EDA tools are generally utilized throughout an entire electronic design process, from conceptualization and schematic capture to simulation, layout, and verification. These tools facilitate the efficient design, analysis, and manufacturing of electronic systems.

[0234] Corresponding to the hierarchical view of the hardware, the software models may be described by a distributed system design that may comprise SOA design, that may comprise microservices architecture modeling, that may comprise cloud-native architecture that may comprise modular software design. SOA design is an architectural approach that structures software applications as a collection of services. As mentioned, in SOA, services are self-contained, loosely coupled, and independent modules that encapsulate a specific business functionality. These services communicate with each other over generally well-defined, standardized interfaces. One goal of SOA is to enhance flexibility, scalability, and maintainability by promoting a modular and reusable design. Microservices architecture modeling may involve designing and representing a software system based on the principles of microservices architecture. As mentioned, microservices are an architectural style that structures an application as a collection of small, independent services, each focused on a specific business capability. These services are designed to be loosely coupled, independently deployable, and scalable. Modeling a system using microservices architecture involves various aspects that capture the structure, communication, and behavior of the individual services. Cloud-native architecture is an approach to designing and building software applications that leverage capabilities and advantages of cloud computing platforms. It may be characterized by principles that enable applications to fully exploit the dynamic, scalable, and distributed nature of cloud environments. Modeling software using a cloud-native architecture involves considering various aspects that align with cloudnative principles. Modular software design is an approach that may involve 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 enhance maintainability, reusability, and flexibility in software development. Modeling software with a modular design involves various aspects that focus on the organization, communication, and interaction between these discrete software modules.

[0235] With reference to Fig. 11, an exemplary process 700 of dynamic instantiation of a microsystem 200 will be explained. Fig. 11 shows a Systems Modeling Language (SysML) sequence diagram. As is known to the skilled person, a SysML diagram is a type of diagram that shows the interactions between system components or actors over time. In Fig. 11, interactions between system components or actors are shown as a series of events, with arrows indicating the flow of control between them. The events are organized along a timeline, with time progressing from top to bottom. The sequence is started by obtaining an integration request; this is indicated by the arrow at the upper left corner of Fig. 11. The process 700 will be explained in the following. (1) The resource orchestrator 410 receives the service request with a microsystem model 580. The microsystem model 580 comprises data required to instantiate a new microsystem 200 and its microservice 400. Such data may be indicative of e.g. scheduling conditions, program instructions, configuration parameters, policies, a security certificate, etc.

[0236] (2) The resource orchestrator 410 queries the resource registry 430 for available hardware resources 112 that match the microsystem model 580. The resource orchestrator 410 examines the list of available resources and selects the ones that fulfill the requirements for that specific microsystem model 580. This portion of the process 700 is provided to ensure that the selected hardware resources 112 are available and meet the requirements of the microsystem model 580, thereby making possible their composability.

[0237] (3) After determining a selection of hardware resources 112 that will conform to the requirements of the microsystem model 580, the resource orchestrator 410 requests to the resource scheduler 420 the assignation of scheduled time and slots. This may comprise tasks such as resource scheduling, prioritization, etc.

[0238] (4) The result of the operations of the resource scheduler 420 provides microsystem deployment data. The microsystem deployment data is provided to the network manager 440. The network manager 440 is configured to, based on the microsystem deployment data, deploy a communication integration between the orchestrated hardware resources 112 and commence execution of the instantiated microsystem 200. This deployment will be configured to last for the lifetime requested in the resource recipe.

[0239] (5) The microsystem 200 may be deployed in response to the resources being configured with the parameters indicated in the microsystem model 580 and the program instructions are executed by a processing circuit (hardware resource 112 in the form of a processing circuit). Advantageously, the deployment is performed in response to the hardware resources 112 have been scheduled and the chiplet network 120 has been set up for them.

[0240] (6) The instantiated microsystem 200 is advantageously tested before being determined to be ready for use. Tests may be performed in order to ensure that overall operation of the microsystem is in accordance with the service request and microsystem model 580.

[0241] (7) If the test results are positive, the microsystem 200 is set and a registry update is sent to the resource registry 430 to list and store the information about the microsystem 200, microservices instances, and the hardware resources 112 used for this task.

[0242] (8) Responsive the microsystem 200 being on-boarded, microservice operation may start.

[0243] As exemplified with the process 700 in Fig. 11, operation and utilization of a microsystem 200 may commence responsive to the deployed microsystem 200 reaching a stationary state. At the stationary state, the microsystem 200 is configured as required and provided with necessary software for use of the microsystem, Once the intended microsystem(s) 200 are instantiated, the microservice(s) 400 associated with the microsystem(s) 200 are exposed on the external communications interface 150 and / or the chiplet network 120 and available for use. From the above, an architecture that enables hardware capabilities to be exposed as a set of microservices 400 that may be dynamically updated and extended given current needs of the chiplet arrangement 100. The operation of the available microservices 400 may comprise management of a number of dimensions, such as functionality, security, maintenance, evolution, reengineering and deployment.

[0244] In Fig. 12, a lifecycle of a chiplet arrangement 100 is shown. At a starting point TO in time, design of the chiplet arrangement 100 is initiated. The starting point TO may be defined by a first conceptual idea of the chiplet arrangement 100, a problem statement, a first proof of concept etc. A design phase of the chiplet arrangement lasts from the starting point TO to a first point T1 in time. The design phase may be referred to as design time. At the end of the design time, the hardware of the chiplet arrangement 100 is set and the chiplet arrangement 100 at a runtime phase (runtime for short) until an end of the lifecycle at a second point T2 in time. As shown in Fig. 12, the process 700 of dynamic instantiation of a microsystem 200 may be performed at any time during runtime. That is to say, a microsystem 200 may be dynamically instantiated at any point in time during runtime of the chiplet arrangement 100. Further, the method 600 of providing a microsystem model introduced with reference to Fig. 6 may be performed at any point in time during the lifecycle of the chiplet arrangement 100. That is to say, the method 600 may be performed at design time, and / or at runtime.

[0245] In Fig. 13, a computer program product 800 is shown. The computer program product 800 comprises a computer program 820 and a non-transitory computer readable medium 810. The computer program 820 may be stored on the computer readable medium 810. The computer readable medium 810 is, in Fig. 13, exemplified as a vintage 5,25” floppy disc, but may be embodied 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-ROM, DVD-ROM, CD-RW, DVD-RW), USB flash drives, magnetic tapes, memory cards, Read-Only Memories (ROM), network-attached storage (NAS), cloud storage etc. The computer program 820 comprises instructions 825 e.g. program instruction, software code, that, when executed by processing circuitry cause the processing circuitry to perform, or cause performance of, the complete, or a subset of, the method 600 introduced with reference to Fig. 6.

[0246] The instructions 825 may be executed by any suitable processing circuitry and in Fig. 14, the computer program 820 is loaded onto the chiplet arrangement.

[0247] In Fig. 15, an exemplary computer system 900 is shown. The computer system 900 may be the computer system introduced in Fig. 9. The computer system 900 in Fig. 15 comprises processing circuitry 910 and is operatively connected to, or comprises, a data storage device 920 (volatile or non-volatile). The processing circuitry 910 may be configured to cause, or to perform, the whole, or part of the method 600 introduced in reference to Fig. 6. The computer program 620 may be loaded onto the data storage device 920 and the processing circuitry 910 may be configured to execute the instructions 825 of the computer program 820.

[0248] Modifications and other variants of the described embodiments will come to mind to one skilled in the art having benefit of the teachings presented in the foregoing description and associated drawings. Therefore, it is to be understood that the embodiments are not limited to the specific example embodiments described in this disclosure and that modifications and other variants 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, persons skilled in the art will appreciate that the embodiments of the invention can equivalently be applied to any suitable computer system and not specifically to chiplets.

[0249] As a mere example, it is conceivable to provide a computer system controllable by an external communications interface. The computer system comprises a plurality of hardware resource, each providing at least one dedicated hardware functionality. The hardware resources are connected by a hardware network. The computer system is provided with a control plane configured to orchestrate one or more microsystems, each microsystem comprising at least one hardware resource and an addressable connection at the network. The control plane is further configured to expose one or more microsystems as microservices at the external communications interface.

[0250] Furthermore, although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation. Therefore, a person skilled in the art would recognize numerous variations to the described embodiments that would still fall within the scope of the appended claims. Furthermore, although individual features may be included in different claims (or embodiments), these may possibly advantageously be combined, and the inclusion of different claims (or embodiments) does not imply that a combination of features is not feasible and / or advantageous. In addition, singular references do not exclude a plurality. Finally, reference signs in the claims are provided merely as a clarifying example and should not be construed as limiting the scope of the claims in any way.

Claims

CLAIMS1. A computer implemented method (600) comprising: obtaining (610) an engineering plan (510) comprising hardware requirements (512) and software requirements (514) of a microsystem (200) for producing and / or consuming one or more microservices (400); obtaining (620) a chiplet arrangement hardware model (522) describing an electrical environment of a chiplet arrangement (100), wherein the chiplet arrangement (100) is controllable by an external communications interface (150) and comprises at least one chiplet (110) connected to a chiplet network (120), and wherein the at least one chiplet (110) comprises at least one hardware resource (112); estimating (630) a microsystem hardware model (530) based on the hardware requirements (512) and a hardware data set (526) describing hardware resources (112) of the chiplet arrangement (100); simulating (640) the estimated microsystem hardware model (530) by electrical simulations based on the chiplet arrangement hardware model (522) to provide one or more hardware capabilities (534), obtaining (650) a chiplet arrangement environment model (524) describing a software environment of the chiplet arrangement (100); estimating (660) a microsystem software model (560) comprising the produced and / or consumed one or more microservices (400) using the hardware capabilities (534) and the software requirements (514); simulating (670) the estimated microsystem software model (560) on the chiplet arrangement environment model (524) to provide one or more software capabilities (564); compiling (680) the estimated microsystem hardware model (530), the estimated microsystem software model (560), the one or more hardware capabilities (534), the one or more software capabilities (564) to a microsystem model (580) comprising one or more microsystem capabilities(584) exposable as microservices (400) at the external communications interface (150) of the chiplet arrangement (100); and deploying (682) the microsystem model (580) on the chiplet arrangement (100).

2. The method of claim 1, further comprising: validating (645) the hardware capabilities (534) based on the hardware requirements (512) providing hardware validation data.

3. The method (600) of claim 1 or 2, further comprising: providing alternative hardware capabilities (534) and an estimated alternative microsystem hardware model (530) for further processing by: estimating (630) the alternative microsystem hardware model (530) based on the estimated microsystem hardware model (530), the hardware requirements (512), the hardware data set (526) and the hardware capabilities (534) comprising models of hardware resources (112) available on the chiplet arrangement (100); and simulating (640) the estimated alternative microsystem hardware model (530) by electrical simulations to provide one or more alternative hardware capabilities (534).

4. The method (600) of claim 2 and 3, wherein providing alternative hardware capabilities (534) and the estimated alternative microsystem hardware model (530) for further processing is performed selectively based on the hardware validation data.

5. The method (600) of claim 3 or 4, further comprising: validating (645) the alternative hardware capabilities (534) based on the hardware requirements (512) providing alternative hardware validation data.

6. The method of claim 2 and 5, further comprising, before estimating (660) the microsystem software model (560), selecting one of the microsystem hardware model (530) or the alternative microsystem hardware model (530) as microsystem hardware model (530) for further processing based on processing of the hardware validation data and the alternative hardware validation data.

7. The method (600) of any one of claims 1 to 6 further comprising: validating (675) the software capabilities (564) based on the software requirements (514) providing software validation data.

8. The method (600) of claim 3 and 7, wherein providing alternative hardware capabilities (534) and the estimated alternative microsystem hardware model (530) for further processing is performed selectively based on the software validation data.

9. The method of any one of claims 1 to 8, further comprising: providing alternative software capabilities (564) and an estimated alternative microsystem software model (560) by: estimating (660) the alternative microsystem software model (560) using the hardware capabilities (534) and the software requirements (514); and simulating (670) the estimated alternative microsystem software model (560) on the chiplet arrangement environment model (524) to provide one or more alternative software capabilities (564).

10. The method (600) of claim 7 and 9, wherein providing alternative software capabilities (564) and the estimated alternative microsystem software model (560) for further processing is performed selectively based on the software validation data.

11. The method (600) of claim 9 or 10 further comprising:validating (675) the alternative software capabilities (564) based on the software requirements (514) providing alternative software validation data.

12. The method of claim 7 and 11, further comprising, before providing the estimated microsystem hardware model (530) and the estimated microsystem software model (560) as a microsystem model (580), selecting one of the microsystem software model (560) or the alternative microsystem software model (560) as microsystem software model (560) for further processing based on processing of the software validation data and the alternative software validation data.

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

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

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

16. The method (600) of any one of claims 1 to 15, wherein the chiplet arrangement hardware model (522) comprises hardware models of one or more chiplets (110) of the chiplet arrangement (100).

17. The method (600) of any one of claims 1 to 16, wherein the chiplet arrangement hardware model (522) comprises physical hardware devices of one or more chiplets (110) of the chiplet arrangement (100).

18. The method (600) of any one of claims 1 to 18 further comprising:estimating (685) a utilization of the chiplet arrangement (100) based on the microsystem model (580) and the microsystem capabilities (584).

19. A computer system (900) comprising processing circuitry (910) configured to cause execution of the method (600) of any one of claims 1 to 19.

20. A method (1000) for formal validation of a chiplet arrangement (100) configured with a control plane (300), the method (1000) comprising: obtaining (1010) a mathematically defined chiplet arrangement hardware model (522) comprising a mathematical description of an electrical environment of a chiplet arrangement (100), wherein the chiplet arrangement (100) is controllable by an external communications interface (150) and comprises at least one chiplet (110) connected to a chiplet network (120), and wherein the at least one chiplet (110) comprises at least one hardware resource (112); obtaining (1020) a mathematically defined chiplet arrangement environment model (524) comprising a mathematical definition of a software environment of the chiplet arrangement (100), wherein the software environment comprises a chiplet control plane () configured with: a resource orchestrator (410) configured to orchestrate instantiate one or more microsystems (200) of the chiplet arrangement (100), each microsystem (200) comprising at least one hardware resource (112) and an addressable connection at the chiplet network (120), and a network manager (440) configured to control communication between the microsystems (200) and the external communications interface (150) of the chiplet arrangement (100) by exposing one or more microsystems (200) as microservices (400) at the external communications interface (150); obtaining (1030) one or more mathematically defined chiplet arrangement requirements (516) comprising one or more hardware requirements (512) forthe chiplet arrangement (100) or software requirements (514) for the software environment of the chiplet arrangement (100); validating (1040) the chiplet arrangement environment model (524) on the chiplet arrangement hardware model (522) by mathematically proving that the chiplet arrangement environment model (524) on the chiplet arrangement hardware model (522) fulfills the chiplet arrangement requirements (516); and deploying (1050) the chiplet arrangement environment model (524) on the chiplet arrangement (100).

21. The method (1000) of claim 20 wherein at least one of the chiplet arrangement hardware model (522) and the chiplet arrangement environment model (524) is a wholly mathematically defined model (522, 524).

22. The method (1000) of claim 20 or 21, further comprising: obtaining (1030) one or more non-mathematically defined chiplet arrangement requirements (516) comprising one or more hardware requirements (512) for the chiplet arrangement (100); and validating (1040) that chiplet arrangement (100) deployed with the chiplet arrangement environment model (524) fulfills the non-mathematical chiplet arrangement requirements (516).

23. The method (1000) of any one of claim 20 to 23, further comprising: obtaining (1030) one or more non-mathematically defined chiplet arrangement requirements (516) described in a natural language; and translating (1035) the non-mathematically defined chiplet arrangement requirements (516) into mathematically defined chiplet arrangement requirements (516).

24. A computer implemented method (600) for formal validation of a microsystem (400) for a chiplet arrangement (100) configured with a control plane (300), the method (600) comprising: obtaining (610) an engineering plan (510) comprising mathematical definitions of hardware requirements (512) and software requirements (514) of a microsystem (200) for producing and / or consuming one or more microservices (400); obtaining (620) a mathematically defined chiplet arrangement hardware model (522) comprising a mathematical definition of an electrical environment of a chiplet arrangement (100), wherein the chiplet arrangement (100) is controllable by an external communications interface (150) and comprises at least one chiplet (110) connected to a chiplet network (120), and wherein the at least one chiplet (110) comprises at least one hardware resource (112); determining () a mathematically defined microsystem hardware model (530) based on the hardware requirements (512) and a hardware data set (526) mathematically defining hardware resources (112) of the chiplet arrangement (100); validating () the microsystem hardware model (530) based on the chiplet arrangement hardware model (522) to provide a mathematical definition of one or more hardware capabilities (534); obtaining (650) a mathematically defined chiplet arrangement environment model (524) comprising a mathematical definition of a software environment of the chiplet arrangement (100); determining () a mathematical definition of a microsystem software model (560) comprising the produced and / or consumed one or more microservices (400) using the hardware capabilities (534) and the software requirements (514); validating (675) the estimated microsystem software model (560) on the chiplet arrangement environment model (524) to provide a mathematical definition of one or more software capabilities (564);determining (680), 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) comprising one or more microsystem capabilities(584) exposable as microservices (400) at the external communications interface (150) of the chiplet arrangement (100); and deploying (682) the microsystem model (580) on the chiplet arrangement (100).

Images