Method for determining hardware computing architectures by dynamically controlling a plurality of evaluation tools

Abstract

A method for determining a hardware architecture of an integrated circuit is proposed, comprising the following steps: determining (120) a plurality of candidate architecture configurations of different hierarchical scales, each configuration being defined by a number of configuration instances; evaluating (140) the configurations using multi-level evaluation tools, the evaluation of a configuration by a tool comprising iterative execution such that each iteration corresponds to the evaluation of one of the instances of said configuration, the evaluation (140) providing an output relative to the execution of the evaluation tools; determining (160) at least one optimized configuration from said output;The method includes an interruption (146) of at least one iterative execution of a tool associated with a configuration, in response to the verification of a stopping criterion defined such that the total number of iterations of the iterative execution is strictly less than the number of instances of the candidate configuration. Figure for the abstract: [Fig.1];

Description

Title of the invention: Method for determining hardware computing architectures by dynamically controlling a plurality of evaluation tools. Technical field

[0001] The present invention relates generally to electronic systems, and in particular to a method for determining hardware computing architectures by dynamically controlling a plurality of evaluation tools.

[0002] Computing hardware architectures are classically used as basic elements for the design of systems on a chip.

[0003] A system-on-a-chip, also called a SoC (or System-on-Chip, according to the corresponding Anglo-Saxon expression), is a complete system embedded on an integrated circuit that includes a multitude of electrical or electronic components. Such an integrated circuit implements characteristic functionalities associated with a specific application or application domain, as well as generic elements, such as processor cores, memory elements, or input / output devices. An integrated circuit comprises a hardware device that is generally associated with software configured to control the hardware device and, in particular, to implement the characteristic functionalities. The hardware device includes, especially for so-called high-performance SoCs, a multi-core hardware architecture (i.e., composed of several processing cores) and is produced from assembled hardware components.The hardware design process involves developing the hardware architecture of the various basic components and configuring them using well-known Computer-Aided Design (CAD) tools, following a design flow. A design flow comprises a set of steps implemented using a variety of tools. Such tools enable the actual design (e.g., transforming a high-level architectural description into a lower-level one) as well as evaluating possible architectural configurations. These tools are also used to validate the complete design of a system-on-a-chip (SoC).

[0004] With the increasing complexity of integrated circuits, such a design flow leads to an increase in the design space for exploration, which can lead to multiple iterations at each stage in the design flow, a complexification of tools and difficulties in linking the different tools, as well as an increase in the cost of the necessary resources (computing resources, human resources, etc.).

[0005] Various design processes and tools have been proposed to try to improve the design flow of computing hardware architectures. Known processes use manual or semi-automatic design flows, employing various evaluation tools and simulators in a static or dynamic manner, to perform an exploration of the design space and defined architecture configurations by applying an optimization algorithm, as described for example in the article “An Automatic Design Space Exploration Framework for Multicore Architecture Optimizations” by H. Calborean et al., 9th RoEduNet, vol. 14, 2010, or as described for example in the article “Multilevel simulation-based co-design of next generation HPC microprocessors” by L. Zaourar et al., International Workshop PMPBS (PMBS), Super Computing, St. Louis, United States, 2021.

[0006] However, such methods do not allow for fully automatic or dynamic control of the various simulation tools within a design flow, and consequently, do not enable optimal use of a wide range of parameters and sub-parameters in the architectural configurations to be evaluated. Therefore, known methods cannot determine the best possible configurations from the available evaluation tools. Furthermore, the rigidity of the control of the simulation tools in such methods prevents a multi-level view of integrated circuit design.

[0007] There is therefore a need for a process capable of optimizing the determination of the computing hardware architectures to be used for the multi-level and multi-scale design of an integrated circuit. Summary of the invention

[0008] To this end, a method for determining the hardware architecture of an integrated circuit is proposed. The determination method is implemented by computer and comprises:

[0009] - the determination of a plurality of candidate architectural configurations corresponding to different hierarchical scales of the integrated circuit architecture to be designed, each candidate configuration being defined by a set of configuration elements including at least one configuration element, each candidate configuration being associated with a number of instances of the candidate configuration, each configuration instance corresponding to a combination of values ​​of the configuration elements;

[0010] - the evaluation of the plurality of candidate configurations using at least two assessment tools chosen from a plurality of assessment tools capable of performing a multi-level architectural design analysis, each candidate configuration being evaluated by at least one of the chosen assessment tools, the assessment of a candidate configuration by an evaluation tool comprising the iterative execution of the evaluation tool to evaluate one or more instances of the candidate configuration, the iterative execution of the tool comprising a number of iterations, each iteration corresponding to the evaluation of an instance of the candidate configuration by the evaluation tool, the evaluation step providing an evaluation output relating to the execution of each of the at least two of the selected evaluation tools;

[0011] - the determination of at least one optimized configuration of an architecture hardware of an integrated circuit from said evaluation output.

[0012] The method includes an automatic control of at least two of the selected evaluation tools, including the control of at least one iterative execution of each evaluation tool for the evaluation of at least one candidate configuration.

[0013] The method further includes interrupting the iterative execution of an evaluation tool associated with a candidate configuration, in response to the verification of a stopping criterion, the stopping criterion being defined such that the total number of iterations of the iterative execution is strictly less than the number of instances of the candidate configuration.

[0014] In embodiments, the evaluation step may include resuming the iterative execution of a chosen evaluation tool, after an interruption, in response to the verification of a defined resumption criterion such that the total number of iterations of the iterative execution is strictly greater than the number of iterations implemented up to the interruption.

[0015] Advantageously, the plurality of candidate configurations includes at least a first candidate configuration and a second candidate configuration, the second candidate configuration being a sub-configuration of the first candidate configuration, the evaluation tools chosen including at least a first evaluation tool for evaluating the first candidate configuration and a second evaluation tool for evaluating the second candidate configuration.

[0016] The stopping criterion for the interruption of the iterative execution of the second evaluation tool can be checked in response to the interruption of the iterative execution of the first evaluation tool.

[0017] In some embodiments, the evaluation of an instance of a candidate configuration by an evaluation tool may include:

[0018] - an analysis of an instance of the architecture configuration, using the tool evaluation, in response to the reception of input values ​​associated with the configuration instance, and

[0019] - the determination of a set of output quantity values ​​relating to the result analysis of the configuration instance by the evaluation tool.

[0020] Advantageously, the evaluation step may include, for each candidate configuration to be evaluated, the translation of at least part of the candidate configuration into input quantity values ​​and the generation of an input file associated with one of the evaluation tools chosen to evaluate the candidate configuration, the input file including the input quantity values.

[0021] In embodiments, the plurality of candidate configurations may include at least a first candidate configuration and a second candidate configuration, the chosen evaluation tools including at least a first evaluation tool for evaluating the first candidate configuration and a second evaluation tool for evaluating the first candidate configuration. Each iteration of an iterative execution of an evaluation tool may provide at least one output magnitude value, the iterative execution of the first evaluation tool for evaluating the first candidate configuration including, in response to an iteration of execution of the first evaluation tool, the storage of at least one output magnitude value, and the triggering of at least one iteration of execution of the second evaluation tool for evaluating the second candidate configuration.

[0022] According to some embodiments, at least one value of input quantities of the input file of the second evaluation tool can be defined from the translation of at least one stored value of output quantities.

[0023] Advantageously, the evaluation step may include the simultaneous triggering of at least one execution iteration of at least two tools from among the selected evaluation tools.

[0024] In embodiments, the stopping criterion can be defined as a function of an evaluation of at least one objective function and / or constraint relative to at least one optimization criterion, the at least one optimization criterion being chosen from among a calculation performance criterion, an energy consumption criterion and / or a surface area criterion of the integrated circuit to be designed.

[0025] The stopping criterion can be defined as a function of the execution time of at least one of the execution iterations of an evaluation tool considered, the stopping criterion being satisfied if the execution time reaches a predefined maximum execution time.

[0026] An evaluation tool for the plurality of evaluation tools can be an evaluation tool chosen from an architecture configuration simulator, an architecture compilation tool, a consumption evaluation tool, a tool based on the exploitation of a database and a tool based on the exploitation of a memory of candidate configuration data.

[0027] Another object of the invention is an integrated circuit hardware architecture obtained by implementing the determination method.

[0028] The invention further provides a method for designing an integrated circuit comprising an implementation of an integrated circuit from the hardware architecture of an integrated circuit.

[0029] The invention also provides a computer program product comprising programming code instructions capable of being implemented by a computer, the computer being capable of implementing the method of determining a hardware architecture of an integrated circuit.

[0030] The method for determining computing hardware architectures according to the embodiments of the invention allows for the optimization of the determination of computing hardware architectures to be used for the design of an integrated circuit. In particular, the method allows for the efficient and automatic optimization of the evaluation (or estimation) of the hardware architecture configurations to be analyzed.

[0031] Embodiments of the invention thus provide a fast, flexible, and efficient solution for determining complex system-on-chip architecture configurations. Such a solution has the advantage of being 'multi-objective' and 'multi-level', meaning that it allows optimization, through co-simulation or co-emulation, with simulators run either simultaneously or sequentially, in the same evaluation of architecture configuration(s). This solution also has the advantage of being 'multi-scale', in that it is applicable at different scales within the integrated circuit architecture (it is applicable to the complete system, to the system architecture including interconnections between basic elements, or even to the microarchitecture of the basic elements of the integrated circuit).The evaluation of the architectural configurations to be analyzed can be carried out using executions and different combinations of these diverse and varied evaluation tools, functional or extra-functional for example.

[0032] This results in a non-intrusive solution adapted to various existing conventional circuit design flow processes (for example, for RTL code generation, logic synthesis, placement and routing, etc.). In particular, the method for determining computing hardware architectures according to embodiments is adaptable to any design flow. Such a method does not require modifying steps typically implemented in a conventional circuit design flow and allows for the improvement of evaluation phases in the various stages of the process. Furthermore, such a method requires little confidential information from a conventional design flow, such as information from the RTL (Register Transfer Level) code. Description of the figures

[0033] Other features, details and advantages of the invention will become apparent from the description made with reference to the accompanying drawings given by way of example.

[0034] [Fig. 1] The [Fig. 1] is a flowchart representing the steps of the process of determining hardware architectures of integrated circuits, according to embodiments of the invention.

[0035] [Fig.2] The [Fig.2] is a table representing lists of sets of parameters and sub-parameters to be optimized in an integrated circuit architecture, according to embodiments of the invention.

[0036] [Fig.3] The [Fig.3] is a flowchart representing the functional blocks associated with the evaluation step of the process for determining hardware architectures of integrated circuits, according to embodiments of the invention.

[0037] [Fig.4] The [Fig.4] is a flowchart representing sub-steps associated with the evaluation step of the process for determining hardware architectures of integrated circuits, according to embodiments of the invention.

[0038] [Fig.5] The [Fig.5] is a flowchart representing sub-steps associated with the evaluation step of the process for determining hardware architectures of integrated circuits, according to embodiments of the invention.

[0039] [Fig.6] The [Fig.6] is a diagram representing an overall structure of a hardware architecture design flow for an integrated circuit, according to embodiments of the invention. Detailed description

[0040] Fig. 1 represents a method for determining a hardware architecture of an integrated circuit, according to certain embodiments of the invention.

[0041] The hardware architecture of an integrated circuit determined by such a method makes it possible to generate a hardware description file for an integrated circuit (e.g., a SoC). The hardware description file for the integrated circuit can be a Python script describing the different blocks of the circuit, or can be written in a hardware description language, for example, and without limitation, in VHDL or Verilog. Such a hardware description file will then be used to design the integrated circuit according to an existing integrated circuit design method. The integrated circuit is capable of performing all types of calculations, and in particular complex calculations.

[0042] The integrated circuit can be used or defined for many different applications and technical fields. The integrated circuit can be used, for example and without limitation, in telecommunications systems, imaging systems, industrial systems (such as cybersecurity systems, or systems associated with manufacturing processes, for example), systems specific to the banking or tax sectors, or in computing systems, such as systems high-performance computing (HPC) or embedded systems (such as avionics or automotive systems), etc.

[0043] As shown in [Fig. 1], the process for determining integrated circuit hardware architectures includes an initial step 120 of determining a plurality of N candidate architecture configurations Gn of the integrated circuit (also simply called "candidate configurations"). The index "n" associated with the different generated candidate configurations is thus an integer between 1 and N, and the value of N is an integer greater than or equal to 2. The candidate configurations are determined in particular from a multi-criteria hardware architecture exploration (or design) space.

[0044] In step 140 of the design process, the candidate configurations Gn are evaluated using a plurality M of configuration evaluation tools Om. The index 'm' associated with the different evaluation tools Om used is thus an integer between 1 and M, and the value of M is an integer greater than or equal to 2. In particular, each candidate configuration Gn is evaluated by executing at least one evaluation tool Om chosen from the plurality M of evaluation tools Om.

[0045] As used herein, the term "evaluation tool" refers to any computer tool, or a sub-part of a computer tool, configured to analyze an architectural configuration, the analysis of the configuration corresponding to an evaluation of the configuration.

[0046] An evaluation tool can be a simulation or compilation tool.

[0047] At step 160 of the design process, the results of the evaluation of Candidate configurations (Gn) are used to determine one or more optimized Gopt configurations of the computing architecture according to various optimization criteria. The use of optimized Gopt configurations allows the determination of the desired hardware architecture of the integrated circuit under consideration.

[0048] The method for determining (also called "estimate method" or "design method") hardware architecture of integrated circuit, according to the embodiments of the invention, thus makes it possible to determine a hardware architecture of integrated circuit from the exploration space, adapted to an efficient execution of complex or specific calculations by the integrated circuit.

[0049] Advantageously, the process of designing integrated circuit hardware architectures can include a plurality of iterations, called 'optimization iterations', of steps 120, 140 and 160. In particular, at each optimization iteration of the design process, the number N of candidate configurations generated and the number M and nature of the evaluation tools used can be different.

[0050] The exploration space for multi-criteria hardware architectures corresponds to a representation (also called a 'mathematical representation') of an architecture design optimization problem. The exploration space comprises a set of elements for defining (or describing or modeling) an integrated circuit hardware architecture. In particular, such a set of elements may include parameters of the integrated circuit to be designed (for example, structural parameters related to the components and / or resources of the circuit), circuit optimization objectives defined by objective functions of the integrated circuit to be designed, and / or constraint functions of the integrated circuit to be designed. An objective function is a function that defines an optimization criterion (i.e., a criterion for determining the best solution to an optimization problem).Examples of objective functions include, for example, performance and / or energy consumption and / or circuit sizing.

[0051] The integrated circuit may be, for example, a heterogeneous high-performance computing processor comprising a plurality of computing cores and / or computing accelerators, and various constituent elements (or integrated circuit components such as memories). In such an example, the parameters of the integrated circuit to be designed may include the types of computing cores, the number of computing cores for each type of core, the memory hierarchy, the bandwidth and prefetching (or preloading) of the memories, and / or the interconnection between the different computing resources (for example, a Network-on-Chip, or NoC), etc.

[0052] In embodiments, the objective functions of the integrated circuit to be designed may include, for example, maximizing the computing performance of the integrated circuit, minimizing the energy consumption of the integrated circuit, and / or minimizing the area (or size) of the integrated circuit. In particular, computing performance may be associated, for example, with a time-related parameter such as latency or the execution frequency of calculations; performance may also be related to peak computing power, for example, the number of computing elements in the integrated circuit and their size, and / or to the memory footprint of the hardware architecture, for example, the number of storage elements in the integrated circuit and their size.

[0053] The constraints of the integrated circuit to be designed may be, for example, design constraints relating to predetermined circuit parameters and / or objectives, or even known physical constraints.

[0054] The exploration space may include a set P of parameters to be optimized (also called parameters to be explored or decision variables) of the integrated circuit to be designed.

[0055] For certain parameters to be optimized in set P, the exploration space may also include a set Lp of subparameters to be optimized, associated with the parameter under consideration of the integrated circuit to be designed. The exploration space may also include one or more sets Lpq of subparameters associated with any subparameter of a set Lp, for example.

[0056] Thus, the exploration space, comprising the set P and various sets denoted L, can be structured hierarchically according to the dependencies between parameters and subparameters. The set P and / or the set(s) L can, for example, be implemented as matrices, arrays, lists, or vectors. The exploration space may further include a set F of objective functions and / or constraint functions of the integrated circuit to be designed.

[0057] By way of non-limiting example, Figure 2 represents a table comprising lists of sets P and L, for parameters Pp and sub-parameters \q to be optimized, for an integrated circuit comprising a plurality of computing cores.

[0058] As illustrated in [Fig.2], a list P can thus include the number of cores of the integrated circuit, the type of each core of the integrated circuit, the parameters of the cache memory hierarchy of the integrated circuit, the memory bandwidth of the integrated circuit, the type of interconnect network NoC of the integrated circuit, and / or the presence or absence of a memory prefetching mechanism of the integrated circuit, etc.

[0059] A list Lp can include, as with the list L3 associated with the parameter "P3: memory hierarchy parameters":

[0060] - an instruction cache corresponding to a cache memory storing only instructions,

[0061] - a data cache corresponding to a cache memory storing only data,

[0062] - the size of the level 3 cache (or SLC meaning System Level Cache according to the Anglo-Saxon expression), and / or

[0063] - the size of the last level cache (or LLC meaning Last Level Cache according to the Anglo-Saxon expression), etc.

[0064] An Lp list may include, as for the L5 list associated with the parameter "P5: NoC / Interconnection" of the P list, a topology of the NoC interconnection network, a routing algorithm, a number of routers, the position and / or type of each router.

[0065] Similarly, for the sub-parameters "^3i: level 1 instruction cache", "k32: level 1 data cache", or even "^33: level 2 instruction cache" of the L3 list associated with the parameter "P3: memory hierarchy parameters" For example, an Lpq list can include a number of subparameters. Such an Lpq list might include the cache line size, associativity, cache size for data or instructions, exclusivity, replacement policy, write buffer size, and / or prefetching, etc. For the subparameter "^35: level 3 cache size" of the L3 list, for example, an Lpq list might include a system-level cache slice (#SLC slice), SLC slice parameters, latency, and / or SLC bandwidth, etc.

[0066] Each candidate configuration is associated with a set of configuration instances (also called "configuration versions"). A candidate configuration is defined by a set of configuration elements (comprising at least one configuration element), each of which can take:

[0067] - either a single value,

[0068] - or a plurality of possible values, in which case the candidate configuration has several configuration instances, each corresponding to the set of configuration elements defined for the candidate configuration, but with different combinations of configuration element values ​​for each configuration instance, with the element values ​​being chosen from the possible values ​​associated with the different elements.

[0069] As used here, the term "configuration element" (or "element of a configuration") refers to a parameter relative to the set P, or to a subparameter relative to the set Lp or any other set Lpq. Each element of a candidate configuration Gn can be associated with a single value or with a plurality of possible values ​​(in which case the configuration element is a 'variable'). A "value" associated with a configuration element can be, for example, of a numeric data type or a string.

[0070] For example, and without limitation, an element of a candidate configuration Gn can be associated with the parameter Pb relating to the number of cores of the integrated circuit. In this case, the configuration element can be the number of cores and be associated with a unique integer value. In this simplified example, assuming that the candidate configuration has only one configuration element, the candidate configuration has a single configuration instance corresponding to the unique possible value for the configuration element in question.

[0071] Alternatively, the configuration element associated with the Pi parameter could correspond to the number of cores but be associated with a list of possible core numbers (i.e., possible values). In this simplified example, assuming that the candidate configuration has a single configuration element, the candidate configuration has several configuration instances, each corresponding to one of the different possible values ​​for the configuration element in question.

[0072] A candidate configuration Gn is thus associated with a number Hn of configuration instances, denoted Gnh, which are different variations of the candidate configuration with different combinations of values ​​for the configuration elements (among the possible values ​​defined for each configuration element). The index 'h' associated with the different configuration instances is an integer between 1 and Hn, and the value of Hn is greater than or equal to 1.

[0073] In the case where a candidate configuration Gn includes a number Hn equal to 1, the candidate configuration Gn consists of only one instance of configuration Gn i, and each element of the candidate configuration Gn is associated with a unique value.

[0074] In the case where a candidate configuration Gn comprises a number Hn of instances strictly greater than 1, the candidate configuration Gn consists of a plurality of configuration instances Gn h, and at least one element of the candidate configuration Gn is associated with a plurality of possible values. Each instance Gnh of the same candidate configuration Gn therefore corresponds to the candidate configuration Gn defined by its set of configuration elements, but with different combinations of values ​​for the configuration elements from one instance to another.

[0075] For example, and without limitation, a candidate configuration may comprise a set of elements, each corresponding to a unique value (i.e., characteristic of the parameter or subparameter represented), and an element associated with a plurality of X possible values. The number of instances of such a candidate configuration may then be equal to X.

[0076] Thus, in some embodiments, a candidate configuration Gn may comprise a first instance of configuration Gn i and a second instance of configuration Gn 2. The first and second instances may comprise the same set of elements corresponding to the same fixed unique values. The first and second instances differ in that the first instance Gn i comprises a first value of a variable and the second instance Gn 2 comprises a second value of this variable, for the same element of the candidate configuration Gn. The first and second values ​​of this variable are distinct from each other.

[0077] A candidate configuration Gn, determined at a step 120 of the design process (during a given optimization iteration of the process, for example), may include configuration elements corresponding, for example, to a subset of the elements P, some of whose parameters are defined according to a fixed value, and / or subsets of the elements L, some of whose subparameters are also defined according to a fixed value. Advantageously, a candidate configuration Gn may also include one or more configuration elements corresponding to variables to be evaluated, for one or more parameters Pp and / or subparameters \q (i.e., a list L corresponding to Lp or Lpq). In this case, a configuration element, each corresponding to a plurality of values ​​to be evaluated, is defined according to a given (or determined) list denoted V.For example, and without limitation, an element of a candidate configuration Gn can be defined by a list V of discrete values ​​defined in step 120 of the design process.

[0078] The candidate configurations Gn can thus be determined in step 120 of the determination process by applying an optimization algorithm performing operations research applied to the architecture exploration space. Operations research (also called 'combinatorial optimization' or 'decision support') can be applied to analyze complex situations and / or determine one or more solutions to the design problem of a hardware architecture to be optimized. An optimization algorithm can be any algorithm or mathematical model capable of determining different decision variables (i.e., parameters and subparameters) and different objective and / or constraint functions of an exploration space. Thus, each candidate configuration Gn (or configuration instance Gn h) corresponds to a subset of the architecture exploration space.

[0079] In particular, each candidate configuration Gn of the set of candidate configurations generated is a configuration of architecture different from each of the other configurations generated, during the same optimization iteration and during previous optimization iterations.

[0080] Advantageously, the architectural "scale" (also called the "hierarchical level" of the architecture) relative to the determined candidate configurations can differ between at least two of the N configurations generated at a step 120, during the same optimization iteration of the determination process. In other words, at least two configurations generated at a step 120 can have two different architectural scales.

[0081] As used herein, the term “scale” (or the expression “architectural scale”), associated with a candidate configuration, refers to a “hierarchical scale” relating to the hierarchical content (parameters and / or sub-parameters) of the architecture characterizing the configuration under consideration.

[0082] As used here, the term "level" (also called "design level" or "flow level") refers to the architectural description in terms of design flow. For example, for the circuit to be designed, the term "level" refers to the 'system level', the 'behavioral level', the 'RTL level', the 'logic level', the 'physical level', etc. In the remainder of this description, the term "level" will be used particularly in relation to the analysis of candidate configuration(s) considered by a specific evaluation tool.

[0083] A "candidate configuration," defined according to a hierarchical scale and relative to an optimization iteration, can correspond to a "candidate sub-configuration" of a candidate configuration, defined according to another hierarchical scale and relative to any previous optimization iteration and / or to the same optimization iteration. Thus, a candidate sub-configuration can include all the parameters and / or sub-parameters, as well as their associated values, of a given candidate configuration, defined according to a given hierarchical scale. A candidate sub-configuration can, however, correspond to a 'lower' scale in the hierarchical content of the architecture, and include additional parameters and / or sub-parameters, associated with given values.

[0084] For example, and without limitation, initial optimization iterations of the design process can be performed to determine one or more initial candidate configurations associated with the evaluation of certain parameter values ​​Pp. One or more subsequent iterations can then be performed to determine one or more candidate configurations, derived from candidate configuration(s) evaluated during any previous optimization iteration, associated, for example, with the evaluation of certain subparameter values ​​\q of a list Lp. The process can be continued similarly by associating one or more subsequent candidate configurations with the evaluation of certain subparameter values ​​\q of a given list Lpq.

[0085] In certain embodiments, during a single optimization iteration, at a given step 120, a plurality of determined candidate configurations Gn may comprise a first candidate configuration Gi and a second candidate configuration G2, the first and second candidate configurations corresponding to two distinct hierarchical scales in the architecture of the integrated circuit to be designed. The first candidate configuration Gi may comprise parameters and / or subparameters relating to a first hierarchical scale in the architecture of the integrated circuit to be designed, and the second Candidate configuration G2 may include parameters and / or sub-parameters relating to a second hierarchical scale in the architecture.

[0086] Advantageously, the second candidate configuration G2 can correspond to a "sub-candidate configuration" of the first candidate configuration Gb

[0087] In certain embodiments, the evaluation of one or more candidate configuration(s) Gn can further be associated with two distinct design levels relating to the architectural description in terms of the design flow of the integrated circuit to be designed. The evaluation of a first candidate configuration Gi can correspond to an evaluation, according to a first level of description, for example at the system level of the architecture, and the evaluation of a second candidate configuration G2 can correspond to an evaluation according to a second level of description, for example at the micro-architecture level of the integrated circuit to be designed. The first and second levels can also correspond to an RTL level and a synthesis level, for example.

[0088] In some embodiments, the first candidate configuration Gi may be associated with the evaluation of certain parameter values ​​Pp and the second candidate configuration G2 may be associated with the evaluation of certain sub-parameter values ​​of a list Lp. For example, the first candidate configuration Gi may include at least:

[0089] - a fixed value (p2) associated with the parameter P2 relating to the core type, and

[0090] - a list of integers Hi {pj associated with the parameter Pi relating to the number of cores of the Integrated circuit to be optimized.

[0091] The first candidate configuration Gi thus comprises a number Hi of configuration instances, each associated with the same value p2 and with one of the different possible values ​​from the list {pj.

[0092] Each instance, among the number Hi of instances, represents a configuration having the same core type (p2) for different determined numbers of cores. The evaluation of the first candidate configuration Gi then corresponds to the evaluation of different numbers of cores {pj} according to the same core type. The evaluation of the first candidate configuration Gi can also correspond to a comparison of the analysis results of the instances according to the different numbers of cores {pj} according to the same core type.

[0093] The second candidate configuration G2 may include at least:

[0094] - a fixed value (denoted p3) associated with the parameter P3 relating to the parameter of the memory hierarchy, and

[0095] - a list of H2 data associated with the parameter ^31 of the integrated circuit to be optimized.

[0096] The second candidate configuration G2 thus comprises at least an H2 number of instances representing a configuration with a given memory hierarchy parameter, and the evaluation of the second candidate configuration G2 then corresponds to the evaluation of different {p3i} values. The evaluation of the second candidate configuration G2 may further correspond to a comparison of the analysis results of the instances as a function of the different {p3i} values.

[0097] Figure 3 illustrates the evaluation step 140 of the candidate configurations Gn of the determination process, according to certain embodiments of the invention.

[0098] The evaluation step 140 includes an initialization block 142 for the piloting (also called control) of the execution of the evaluation tools Om.

[0099] An evaluation tool Om can be configured to receive as input a set of predefined input quantities Em, and to output one or more output quantities Sm corresponding to the results of the tool's analysis. For example, output quantities Sm can be traces of the evaluation tool Om.

[0100] Advantageously, in order to evaluate an instance of a candidate configuration Gn, an evaluation tool Om therefore receives values ​​for the different input quantities Em, these values ​​being associated with the instance of configuration considered.

[0101] In some embodiments, in response to the analysis of an instance of a given candidate configuration Gn, the evaluation tool Om is capable of outputting one or more output values ​​Sm corresponding to the evaluation (or analysis) results of the configuration instance. The number of input values ​​Em and / or output values ​​Sm depends on the evaluation tool Om, and may also depend on the design level and / or scale associated with the candidate configuration Gn under consideration.

[0102] For example and without limitation, an evaluation tool Om can be a functional instruction set simulator, a memory hierarchy simulator, a high-level architecture simulator, such as: VPSim, GEM5, Virtualizer or Vista, or RTL level, or ModelSim level or Questa, the Open source computer tool DRAMSys or DRAMPower specific to memory hierarchy, or tools such as Arm fast Model, McPat, etc.

[0103] Alternatively, an evaluation tool Om can be, for example, an architecture synthesis tool such as the "Design Compiler" tool from Synopsys, which gives more precise and elaborate results.

[0104] In the case where an evaluation tool Om is of the VPSim simulator type, possible input quantities Em of the VPSim simulator can be parameters related to the hardware architecture of the integrated circuit, such as the 'number of cores' or the 'type of cores'. In the case where an evaluation tool Om is of the GEM5 simulator type, Possible input quantities Em of the GEM5 simulator can be parameters related to the micro-architecture of the integrated circuit, such as sub-parameters associated with the micro-architecture of the cores (e.g., sub-parameters 'data pre-read', 'size and number of registers', etc.).

[0105] An example of an output quantity Sm provided by an evaluation tool can be an estimate of the computational performance of the integrated circuit (in terms of computation execution time), or a result of interconnect or memory access evaluations, expressed for example in number, time or energy consumption.

[0106] In the case where an evaluation tool Om is of the VPSim simulator type, an output quantity Sm of the VPSim simulator can be the execution time of an application on a configuration or more generally another metric related to the architecture, such as the number of successful cache accesses (or cache hits), or the number of cache misses, for example.

[0107] It should be noted that the evaluation tools Om can each be associated with operating parameters, such as the execution time tm (or execution duration), or a maximum exploration time limit tmax_m (or maximum execution duration), for example, for the evaluation of a candidate configuration (or configuration instance) by the tool. The maximum exploration time limit tmax_m can be associated with a predefined value and can, in particular, affect the value(s) of the output parameter(s) Sm associated with the tool.

[0108] In some embodiments, several evaluation tools Om, associated with distinct operating quantities, can be provided to evaluate the same output quantity Sm. For example, a VPSim simulator and a GEM5 simulator can each provide an estimate of the integrated circuit's computational performance. For the GEM5 simulator, the performance estimate can be obtained with a very long analysis time, thus slowing down the overall exploration of configurations. For a VPSim simulator-type evaluation tool Om, the performance estimate can be obtained with a very short analysis time, thus accelerating the overall exploration of configurations. A performance estimate provided by the VPSim simulator can be described as less precise (or more approximate) compared to an estimate provided by the GEM5 simulator (which is then described as a more detailed estimate).Other output quantities can be provided by a VPSim simulator and / or a GEM5 simulator, such as the number of accesses to certain resources, the type of access, etc.

[0109] The initialization block 142 can be configured to select (or choose or define) from a set of available tools, the plurality of M evaluation tools Om. Such a selection can be made based on tool selection criteria and / or candidate configurations Gn. The selection of an evaluation tool can be made, in particular, based on a given design level and / or the hierarchical scale relative to at least one of the N candidate configurations Gn, or to each of them. Specifically, an evaluation tool can be selected to analyze one or more candidate configurations, whether of the same scale or different hierarchical scales, at the same level or at different design levels.

[0110] In embodiments, the plurality of assessment tools Om may include at least one first assessment tool Oi and a second assessment tool O2, the first and second assessment tools being configured to analyze at least one, or each, of the candidate configurations of distinct scales and / or according to distinct design levels.

[0111] In one embodiment, the first evaluation tool Oi can be selected to analyze the first candidate configuration Gi of the plurality of N generated configurations, while the second evaluation tool O2 can be selected to analyze the second candidate configuration G2.

[0112] The first evaluation tool Oi can be adapted to analyze at least the configurations defined according to a first architectural scale, in accordance with a first design level. The second evaluation tool O2 can be adapted to analyze at least the configurations defined according to a second architectural scale, in accordance with a second design level.

[0113] For example, and without limitation, the first evaluation tool Oi could be the VPsim tool configured to evaluate architecture-related parameters such as the number of cores, core types, etc. The second evaluation tool O2 could be the GEM5 tool configured to evaluate micro-architecture parameters (NoC parameters, memory hierarchy), or the ARM Fast model for evaluating the coherence protocol, etc.

[0114] The selection of the first evaluation tool Oi and the second evaluation tool O2 can be performed in response to the detection of the respective scales and / or levels of each of the generated candidate configuration evaluations, Gi and G2. Such detection may, for example, correspond to the identification of the design level and / or hierarchical scale of a configuration (based on the type of parameters and / or subparameters used, for example). This detection may also correspond to the identification of the design level and / or hierarchical scale of the configuration elements corresponding to the variables to be evaluated in the candidate configurations under consideration.

[0115] Those skilled in the art will readily understand that the invention is not limited to a first evaluation tool of the GEM5 type and a second evaluation tool of the VPSim type, and that other types of evaluation tools can be used, such as, for example, Virtualizer, Vista, or any other functionally leveled simulator. RTL-level simulator-type evaluation tools, such as ModelSim / Questa, can be used, for example, for more precise evaluation. Other simulators, such as McPat, can be used for evaluating surface area, energy consumption, or thermal aspects.Functional simulator-type evaluation tools can be used to simulate RTL code, and post-synthesis or post-physical implementation (or Layout, relating to a post-implementation obtained after placement and routing, for example) evaluation tools can be used to simulate, for example, the netlist generated by the circuit compilation, potentially with technological information allowing the provision of energy consumption. Other evaluation tools such as Cadence: First Encounter Design Exploration and Prototyping, Synopses: Fusion Compiler, or Synopses: IC Compiler IF can be used to simulate a circuit, with a circuit description fairly close to the end of the design flow.

[0116] Advantageously, during a single optimization iteration, each candidate configuration Gn can be associated with a number Jn of evaluation tools Om from among the M tools. Each number Jn, associated with each given candidate configuration Gn, is an integer between 1 and M.

[0117] The initialization block 142 can be configured to perform, for each of the candidate configurations Gn, a translation (also called 'transformation' or 'conversion') of at least a part of the candidate configuration Gn into a number Jn of target input files that are understandable (i.e., readable and / or decipherable) by each of the Jn evaluation tools Om considered (i.e., intended to evaluate the candidate configuration). The input file of an evaluation tool is a description file having a structure adapted to the evaluation tool and comprising a set of values ​​for the associated input quantities Em.

[0118] Advantageously, for a given candidate configuration Gn and an associated evaluation tool Om, the initialization block 142 can be configured to perform a translation of this configuration into a number Hn of understandable target input files, each relative to a configuration instance to be evaluated.

[0119] An input file for an evaluation tool Om can be generated from the translation of one or more selected configuration elements (parameters and / or subparameters) of the candidate configuration Gn under consideration into values ​​of Input values ​​Em (target input values) of the evaluation tool Om to which the configuration (or instance) is intended to be applied. Translating at least part of each candidate configuration into input value values ​​allows the candidate configuration to be adapted to the target format of the input file of the evaluation tool to which it is applied.

[0120] In embodiments, such a translation can be performed using one or more RT translation registers associated with the Om evaluation tools. The RT translation register(s) can include, for each Om evaluation tool, transcription elements corresponding to the target format of the evaluation tool in question, such as a Python script, a JSON file, or an XML file, for example. The selection of transcription elements to be used can be made based on the candidate configuration Gn to be evaluated and the Om evaluation tool to which it is to be applied. For example, and without limitation, the selection of a transcription element can be made based on the type of configuration elements considered, or on the detected hierarchical architecture scale.Thus, a transcription element associated with a selected evaluation tool Om can be applied to each candidate configuration Gn to which an evaluation tool is to be applied, generating an input file in a format suitable for the given evaluation tool Om. For example, and without limitation, for a VPSim simulator-type evaluation tool, the input files can be determined using a Python script (as a transcription element) to generate a hardware platform suitable for the VPSim simulator (e.g., in terms of number of cores, type, memory parameters, NoC parameters, etc.). The dynamic (or automatic) population of the Python script feeds the VPSim simulator by transcribing the parameters and sub-parameters of one or more given configurations.

[0121] The translation operations implemented by the initialization block 142 make it possible to improve the efficiency of the evaluation of the different candidate architectures and thus to obtain optimized architectures more quickly, with better flexibility, and automatically.

[0122] The initialization block 142 may include the steps of receiving (or determining) the candidate configurations Gn to be evaluated, selecting an evaluation tool Om for each candidate configuration Gn to be evaluated, and for each evaluation tool Om selected for a candidate configuration Gn:

[0123] - select the configuration elements (corresponding to values ​​of the parameters and / or sub-parameters) to be translated into target input quantity values ​​Em associated with the evaluation tool selected for the candidate configuration Gn,

[0124] - determine at least one transcription element associated with the Om assessment tool considered, and

[0125] - apply the transcription element to the selected configuration elements candidate Gn, which provides the target input quantity values ​​Em associated with the evaluation tool selected for the configuration.

[0126] For example and without limitation, for each evaluation tool Om, the elements of a candidate configuration Gn to be translated can be identified from a parameter / tool ​​correspondence table.

[0127] In some embodiments, the translations implemented by the initialization block 142 can be specific to each optimization iteration (i.e. to the determined candidate configurations Gn and the selected evaluation tools Om).

[0128] In embodiments, the evaluation step 140 includes a control block 144 configured to implement automatic or dynamic control (also called "control") of the evaluation tools Om used to evaluate the candidate configurations Gn.

[0129] As used here, the term "piloting" refers to the implementation of a plurality of actions on one or more evaluation tools in response to a specific condition. An action associated with an evaluation tool refers to an action executed by the piloting block 144, using an input file from the evaluation tool. Such a specific condition may be, for example and without limitation, a command, the sending of a request, the detection of a setpoint, or the implementation of a specific action, etc.

[0130] In particular, the control block 144 is configured to trigger (or implement), for each evaluation tool Om among the M selected tools, one or more executions of the evaluation tool in question to evaluate each of the candidate configurations Gn considered by a selected tool. In particular, the control block 144 can be configured to trigger the executions of the evaluation tools in question to evaluate the configuration instances in question. The executions of the different evaluation tools can be triggered independently of each other or be interdependent. The executions of the different evaluation tools can also be triggered simultaneously (i.e., in parallel), synchronously, successively (one after the other), and / or sequentially (i.e., according to a predefined sequence).

[0131] The order of triggering the different evaluation tools and / or the specific evaluation order of each of the candidate configurations can be predefined, for example by using a trigger file.

[0132] The initialization block 142 can be configured to generate the trigger (or control) file for the execution of the various Om evaluation tools considered, for example according to the different levels and / or different scales of the configurations.

[0133] In particular, the control block 144 can be configured to trigger, for a given evaluation tool, one or more iterations of the evaluation tool's execution (this execution is then referred to as "iterative execution"). Thus, at each execution iteration, an execution of the evaluation tool is triggered to analyze (or evaluate) a specific configuration instance of a candidate configuration. The execution of the evaluation tool is repeated a number of times (each repetition corresponding to an iteration) until a condition, called the "stopping condition," is met (i.e., satisfied).

[0134] During an iteration of execution of the evaluation tool applied to an instance of a candidate configuration Gn, the evaluation tool Om can be configured to analyze a specific element or value of a variable to be evaluated from a list V associated with the evaluated candidate configuration.

[0135] In some embodiments, the control block 144 can be configured to trigger a first series of executions of the first evaluation tool Oi (the first series of executions corresponds to a number of execution iterations of the first evaluation tool Oi). During the first series of executions, the first evaluation tool Oi is applied to at least one candidate configuration (for example, the candidate configuration Gi) defined according to a first hierarchical scale, in accordance with a first level of design.

[0136] The control block 144 can further be configured to trigger a second series of executions of the second evaluation tool O2 (the first series of executions corresponds to a number of execution iterations of the second evaluation tool O2). During the second series of executions, the second evaluation tool Oi is applied to at least one candidate configuration (for example, the candidate configuration G2) defined according to the first hierarchical scale or according to a second hierarchical scale, in accordance with the first level of concept or a second level of design.

[0137] According to some embodiments, the second series of executions can be triggered based on the first series of executions. For example, and without limitation, the second series of executions of the second evaluation tool O2 can be triggered in response to the completion of all executions of the first series of executions of the first evaluation tool Oi. Alternatively, at least one execution iteration of the second evaluation tool O2 can be triggered sequentially, or synchronous, with respect to an execution iteration of the evaluation tool Op In implementation examples, an execution iteration of the evaluation tool O2 can be triggered each time an execution of the first series of executions finishes, or each time an execution of the first series of executions starts.

[0138] In some embodiments, the control block 144 can further be configured to store the analysis results of at least one tool from among the M selected evaluation tools Om, by placing them in memory. In particular, such storage can be implemented at each execution iteration or following several iterations (for example, the last iteration) of a series of executions. Furthermore, such storage can include the storage of at least one output quantity Sm delivered at the output of a considered tool Om.

[0139] In embodiments, the control block 144 can be configured to use analysis results from the first evaluation tool Oi for an execution or series of executions of the second evaluation tool O2.

[0140] For example and without limitations, the control block 144 can be configured to inject (or transmit) at least one output quantity Si delivered at the output of the first evaluation tool Oi, at each execution iteration or after several execution iterations (for example after the last iteration of the series of executions implemented), into the input file of the second evaluation tool O2 as value(s) of input quantity(ies) E2.

[0141] The control block 144 can further be configured to inject element values ​​of the candidate configuration Gi applied to the first evaluation tool Oi, depending on the analysis results of the first evaluation tool Ob obtained at each execution iteration or after several execution iterations of the first series of executions, into the input file of the second evaluation tool O2 as input quantity value(s) E2.

[0142] Such injections can be applied, for example, to each execution iteration of the second evaluation tool or to the first execution iteration of the second series of executions of the second evaluation tool.

[0143] Advantageously, such elements to be injected (i.e. at least part of an analyzed candidate configuration and / or at least one output quantity delivered at the output of an evaluation tool) can in particular be extracted from the elements stored by the control block 144.

[0144] Advantageously, the control block 144 can be configured to implement a translation of the elements to be injected (at least one stored output value Si and / or the result of an analysis of at least one evaluated instance of the first candidate configuration Gi by said first evaluation tool Oi) into the format of the target input file of the second O2 evaluation tool, that is to say in value(s) of input quantity(ies) E2 of the target input file of the second O2 evaluation tool.

[0145] Figure 4 schematically represents an example of piloting at least two evaluation tools Oi and O2, by the control block 144 in the evaluation step 140 of the candidate configurations Gn of the determination process, according to certain embodiments of the invention.

[0146] As illustrated in [Fig. 4], the control block 144 can be configured to trigger one or more executions 144-1 of the first evaluation tool Ob and to store and translate 144-2 elements from the execution results of this evaluation tool Op. The control block 144 can then trigger one or more executions 144-3 of the second evaluation tool O2, using the previously stored and translated elements. The triggering of executions 144-3 can also be performed in response to the translation and / or storage 144-2 of the result elements to be injected.

[0147] In some embodiments, the plurality of evaluation tools Om may include a third evaluation tool O3. The third evaluation tool O3 may be configured to analyze, according to an equivalent design level, candidate configurations defined on an architectural scale similar to the configurations analyzed by the first evaluation tool Oi, for example. For instance, and without limitation, the third evaluation tool O3 may be selected to analyze the first candidate configuration Gi of the plurality of N generated configurations. The control block 144 may advantageously be configured to further trigger one or more executions of the third evaluation tool O3, simultaneously with the triggering of the executions 144-1 of the first evaluation tool Oi.The 144 control block can thus be configured to store and translate elements from the execution results of the O3 evaluation tool, and then to trigger the 144-3 executions of the second O2 evaluation tool, using the previously stored and translated elements from the analysis results of the first Oi evaluation tool and the third O3 evaluation tool.

[0148] According to some embodiments, the execution time ti of an iteration of the first evaluation tool Oi to analyze a configuration may differ from the execution time t3 of an iteration of the third evaluation tool O3 to analyze the same and / or a different configuration. For example, the execution time ti may be significantly shorter than the execution time t3. Thus, in some embodiments, the control block 144 may be configured to trigger the executions 144-3 of the second evaluation tool O2, in response to the translation and / or to storage 144-2 of the result elements to be injected, from the analysis results of the evaluation tool with the longest execution time.

[0149] Evaluation step 140 includes a stopping block 146 (also called 'iteration stopping management block') of the selected evaluation tools Om.

[0150] The stop block 146 can be configured to stop the execution iterations of at least one of the tools of the M evaluation tools Om selected, in response to the verification of a stop criterion.

[0151] Such a stoppage of the execution iterations of an evaluation tool (or interruption of execution) induces, during the piloting of the evaluation tools Om, a failure to evaluate at least one instance of a candidate configuration Gn programmed to be evaluated by the evaluation tool Om (i.e. the instance or instances which have not been evaluated due to the stoppage of the iterations).

[0152] It should be noted that, for a candidate configuration Gn, stopping the execution iterations of an evaluation tool Om, to evaluate a number Hn of configuration instances, results in the total number of iterations H;, actually implemented, being strictly less than the number Hn of iterations planned when the iterative execution in question was triggered.

[0153] This results in a failure to analyze the unanalyzed (i.e. unprocessed) instances, following the cessation of execution iterations.

[0154] Unanalyzed candidate configuration instances Gn can then be considered useless for determining optimized architecture configurations Gopt. Such an analysis failure (also called "execution bypass") improves the efficiency of evaluating different candidate architectures and allows for faster obtaining of optimized architectures without superfluous configuration analysis, potentially by testing more relevant candidate configurations. Interrupting an evaluation tool Om, which induces an analysis failure of certain candidate configuration instances Gn, is possible by verifying at least one stopping criterion (also called an "interruption criterion").

[0155] Furthermore, the failure to analyze certain instances of a first candidate configuration Gi defined according to a first architectural scale, in accordance with a first design level, can lead to a failure to analyze some or all of the instances of at least one second candidate configuration G2. Such an induced failure to analyze can occur, for example, if the second candidate configuration G2 is a sub-configuration of the first candidate configuration Gi whose analysis was interrupted. The second candidate configuration G2 can then be defined according to a second hierarchical scale and analyzed in accordance with the first level or a Second level of design. The accumulation of flaws in the analysis of candidate configuration instances significantly accelerates the effective analysis time of the evaluation step 140 of the candidate configurations Gn. This results in a significant computational gain.

[0156] In embodiments, for an evaluation tool and a given candidate configuration, it can be checked whether a stopping criterion is satisfied at the end of one or more execution iterations of a tool.

[0157] Advantageously, the stopping criteria associated with each evaluation tool considered for evaluating a given candidate configuration may differ from one another. A stopping criterion for one tool may also depend on the iteration execution of another tool.

[0158] If it is determined that the stopping criterion is not satisfied, the execution iterations of the evaluation tool continue. Thus, if the stopping criterion is not met during a series of executions of an evaluation tool, a new execution iteration of the evaluation tool in question is implemented (the execution is repeated).

[0159] It should be noted that at the end of an iterative execution, if it is determined that the stopping criterion has not been satisfied, the number of iterations H; actually implemented can then be equal to the number Hn of iterations planned when the iterative execution in question was triggered.

[0160] If it is determined that the stopping criterion is satisfied, the execution of the evaluation tool applied to a candidate configuration is stopped.

[0161] In some embodiments, the stop block 146 can be configured to apply a temporary interruption (also called "pause") to the execution iterations of at least one of the tools of the selected evaluation tools Om, in response to the verification of a first predefined criterion, such as a pause criterion. In other embodiments, the control block 144 can be configured to trigger the continuation of the paused execution iterations, in response to the verification of a second predefined criterion, such as a resume criterion. If such a resume criterion is not met, the paused execution iterations can be considered stopped.

[0162] It should be noted that, for a candidate configuration Gn, the resumption of the execution iterations of an evaluation tool Om, after an interruption, results in the total number of iterations denoted Hj, actually implemented at the end of the iterative execution, being strictly greater than the number H of iterations implemented until the interruption of the iterative execution at the verification of the stopping criterion.

[0163] Such a pause in execution iterations of the same tool evaluating a given candidate configuration can be applied, for example, to allow the control block 144 to trigger the evaluation of the same configuration with another tool, or of another candidate configuration with the same tool or another tool.

[0164] For example, and without limitation, the control block 144 can be configured to trigger execution iterations of a first evaluation tool Op. This initial triggering of execution iterations can, for example, be implemented in response to the generation of an input file of the first evaluation tool Op. The stop block 146 can then be configured to pause these execution iterations of the first evaluation tool Op. The execution iterations can, for example, be paused in response to the triggering by the control block 144 of one or more executions of the second evaluation tool O2.The control block 144 can be configured to then trigger the continuation of the execution iterations previously paused of the first evaluation tool Op. This resumption of execution (or second triggering) can, for example, be implemented in response to the translation and / or storage of analysis results of the second evaluation tool O2 to be injected, as new value(s) of input quantity(ies) Ep into the input file, then modified for the paused execution iterations, of the first evaluation tool Op. Such injection makes it possible in particular to refine the values ​​of input quantities of the first evaluation tool Oi that was paused, by giving it more inputs, by modifying its inputs (i.e. parameters and / or sub-parameters), etc.

[0165] By way of non-limiting example, the execution time ti of the first evaluation tool Oi can be significantly longer than the execution time t2 of the second evaluation tool O2. The execution iterations of the first evaluation tool Oi can be implemented to analyze a candidate configuration very precisely, while the execution iterations of the second evaluation tool O2 can be implemented to analyze this candidate configuration less precisely but very quickly. These execution iterations of the first evaluation tool Oi can be triggered and then paused, for example, in response to the analysis of results from the execution of the first evaluation tool Op. These initial results can be considered unfavorable, thus corresponding to a pausing criterion.The paused execution iterations of the first assessment tool (Oi) can be re-triggered following the execution iterations of the second assessment tool (O2). Specifically, the second trigger of the first assessment tool (Oi) can be implemented in response to the analysis of results from the execution of the second assessment tool (O2). For example, the second trigger of the first assessment tool (Oi) can be implemented if the evaluation results of the second assessment tool (O2) meet the [condition / condition]. determination of favorable intermediate results, corresponding here to a recovery criterion.

[0166] Such a pause in the execution iterations of a tool thus makes it possible to drastically improve the efficiency of evaluating the different candidate architectures, which allows for significant savings in computing resources, for better eco-design of the integrated circuit to be designed.

[0167] In embodiments, the control block 144 can be configured to trigger a second time the set of execution iterations of an evaluation tool Om, in response to the verification of another predefined criterion, such as a repetition criterion.

[0168] Such repeated iterations of execution of the same tool evaluating a given candidate configuration can, for example, be implemented in response to the analysis, translation, and / or storage of evaluation results from the tool or another evaluation tool. Such repetition can be performed in response to the injection of analysis results as new input value(s) into the input file associated with the given candidate configuration.

[0169] In the following description, reference is made only to the concept of "stopping criterion". However, those skilled in the art will readily understand that the description of the following embodiments, associated with the use of the "stopping criterion", applies similarly to the "pause criterion", the "resume criterion", and the "repeat criterion".

[0170] In embodiments, the stopping criterion can be defined as a function of the execution time of a single execution iteration tm or the execution time resulting from the plurality of execution iterations and / or the number of iterations executed, of a tool and / or the analysis of a given configuration. For example, it can be determined that the stopping criterion is satisfied if the exploration time bound tmax_m is reached (i.e., the resulting execution time has expired, the resulting execution time then being greater than or equal to the exploration time bound tmax_m)*

[0171] In embodiments, the stopping criterion can be defined by comparing different output values ​​Sm returned in response to the execution of a given evaluation tool Om at each execution iteration, and / or in response to several execution iterations of a given evaluation tool Om in a series of executions, for example, after the last iteration of an iterative execution. Such a comparison can be implemented to determine at least one optimal value of a specific variable from the list V of variables associated with a defined candidate configuration.

[0172] In other words, at least some of the instances of the same candidate configuration Gn can be evaluated and compared with each other, in order to analyze the effect of the different variable values ​​on the candidate configuration Gn.

[0173] Similarly, the stopping criterion can be defined from the comparison of different output quantities Sm returned in response to the execution of several given evaluation tools Om.

[0174] In embodiments, the stopping criterion may be related to the evaluation of one or more objective functions and / or constraints with respect to determined circuit optimization criterion values.

[0175] An objective and / or constraint function of a set (or list) F in the architecture exploration space is defined to evaluate one or more optimization criteria of the circuit associated with an integrated circuit configuration to be designed. An objective and / or constraint function then corresponds to a mathematical formulation associated with one or more objectives and / or constraints of the integrated circuit to be designed.

[0176] There are a plurality of circuit optimization criteria Cq. The index 'q' associated with different optimization criteria is thus an integer between 1 and the value of an integer greater than or equal to 3. In embodiments, the optimization criteria may include the following three main optimization criteria:

[0177] - a first main optimization criterion of the circuit Ci corresponding to the integrated circuit calculation performance which can be defined for example by a number of floating-point operations per second expressed in FLOPS (or Floating-point Operations Per Second according to the Anglo-Saxon expression), a time data of the integrated circuit such as a latency (in seconds) or an operating frequency (in Hertz), or even a measurement of a memory size (in number of bits or bytes);

[0178] - a second main optimization criterion of the C2 circuit corresponding to the energy consumption of the integrated circuit; and

[0179] - a third main optimization criterion of the C3 circuit corresponding to the surface of the integrated circuit.

[0180] Advantageously, other optimization criteria Cq of the circuit can be defined, such as the price of the circuit, the environmental footprint of the circuit (such as the Carbon footprint for example), the manufacturing time of the circuit, the level of safety of the circuit, etc.

[0181] For example, and without limitation, the set F of objective functions and / or constraints may include a first, a second and a third objective function, Fi, F2 and F3, associated respectively with the first, the second and the third The main optimization criteria of the circuit are Ci, C2, and C3. The first objective function Fi can be a maximum argument function (or Argmax) of the integrated circuit's computational performance Cp. The second objective function F2 and the third objective function F3 can then be a minimum argument function (or Argmin) of the integrated circuit's power consumption C2 and a minimum argument function of the integrated circuit's surface area C3. The maximum and minimum argument functions refer to the functions that determine the minimum and maximum possible values, respectively, of a variable represented by a data set.

[0182] In particular, it should be noted that an objective function of list F is a function seeking to minimize or maximize a criterion expressed as an optimization objective for the circuit. A constraint function of list F is a function seeking to respect a constraint of the integrated circuit to be designed. For example, and without limitation, a constraint function can then be an inequality function between several parameters of list P and / or subparameters of a list Ln.

[0183] For the evaluation of the stopping criterion, the stopping block 146 can further be configured to determine two or more values ​​of the optimization criterion of the Cq circuit from analysis results of at least one candidate configuration obtained by executing the evaluation tools via the control block 144.

[0184] Two optimization criteria from the set of optimization criteria of the circuit to be determined can be chosen from among antagonistic optimization criteria characterizing the integrated circuit to be designed, i.e. chosen from at least one main optimization criterion of computing performance, one main optimization criterion of energy consumption and one main optimization criterion of the surface area of ​​an integrated circuit.

[0185] For example and without limitation, the value of the performance of calculations Ci can be obtained from the performance estimate determined by a first evaluation tool Oi (for example the VPSim simulator) or by a second evaluation tool O2 (for example the GEM5 simulator).

[0186] According to certain embodiments, at least one value of a circuit optimization criterion Cq to be determined can be calculated using one or more analytical formulas (or analytical functions). Such an analytical formula can take as input parameters at least one or more evaluation results of one or more candidate configurations by at least one evaluation tool.

[0187] Advantageously, such input parameters of an analytical formula may include at least one piece of information related to the structure of the integrated circuit to be designed and / or one piece of information related to the operating activity of the integrated circuit to be designed. For example, and without limitation, so-called structural information may correspond to a number or type of component (e.g., cores) of an integrated circuit. Activity information can correspond to a number or type of memory access or access to a component of the integrated circuit, a number or type of activation of a component of the integrated circuit or a chain of components of the integrated circuit, a number or type of operations performed by the integrated circuit, etc. The type of activity information can depend on the design level of the integrated circuit. For example, the computation latency of a component of the circuit can be activity information and allows for the calculation of a more global latency or a quantity related to energy consumption through an analytical formulation.

[0188] Advantageously, such input parameters of an analytical formula may further include technological information determined from one or more technological databases comprising data for circuit components that can be manufactured according to a given integrated circuit design technology.

[0189] Advantageously, information (of structure, activity and / or technology) may correspond to configuration elements (parameters and / or sub-parameters, or constituent elements) of the candidate configurations evaluated and / or of one or more evaluation results obtained, i.e. of one or more values ​​of output quantities Sm from at least one of the evaluation tools Om.

[0190] In some embodiments, the step of determining the value of the optimization criterion for the Cq circuit can be performed using a function register. The function register is associated with the analytical formulas to be applied to the information (structural, activity, and / or technological) to calculate a value of the optimization criterion for the Cq circuit.

[0191] For example, an analytic function may include a sum of parameters, a division, a subtraction, and / or a multiplication, etc.

[0192] For example, and without limitation, for determining a value of the third principal optimization criterion C3 of the circuit, corresponding to the surface area of ​​the integrated circuit, an analytical function can be a sum taking as arguments the sum of the surface areas of the circuit elements. For determining a value of the second principal optimization criterion C2 of the circuit, corresponding to the energy consumption of a computing element of the integrated circuit, an analytical function can be a multiplication taking as arguments the number of activations of each operation and their average energy consumption.

[0193] It should be noted that a value of a circuit optimization criterion Cq defined among the set of circuit optimization criteria to be determined can be obtained directly from output values ​​Sm after analysis of a candidate configuration by a given evaluation tool Om. The evaluation tool Om can then use technology databases for its internal operation. In this case, the value of the circuit optimization criterion Cq is not obtained by an analytical function executed after analysis by the evaluation tool.

[0194] In stop block 146, the selection in the function register of the analytical formula(s) to be applied can be carried out from the optimization criterion of the Cq circuit to be determined.

[0195] Fig. 5 schematically represents the pilot block 144 and the stop block 146, according to certain embodiments of the invention.

[0196] As illustrated in [Fig. 5], the control block 144 can be configured to trigger one or more executions 144-a of at least one first evaluation tool suitable for evaluating system architecture configurations, and to trigger one or more executions 144-b of at least one second evaluation tool suitable for evaluating microarchitecture configurations. Furthermore, the stop block 146 can be configured to implement an evaluation 146-c of one or more objective functions and / or constraints associated with configurations to be evaluated.

[0197] In embodiments, in the control block 144 and / or in the stop block 146, the evaluation results generated by the plurality of evaluation tools Om and / or the values ​​of the optimization criteria of the circuit Cq associated with each candidate configuration Gn can be recorded (i.e. stored) in a candidate configuration data memory.

[0198] Advantageously, in order to evaluate a stopping criterion relating to the evaluation of objective functions and / or constraints, the stopping block 146 can be configured to evaluate optimization criterion values ​​in response to the storage of elements associated with these criteria (derived in particular from the analysis results of one or more evaluation tools). Thus, the evaluation of stopping criteria can be carried out continuously during the operation of the various evaluation tools Om.

[0199] In some embodiments, the stop block 146 can be configured to stop the executions of the first evaluation tool Oi triggered by the control block 144 in response to the verification of at least one stopping criterion. The control block 144 (and / or the stop block 146) can be configured to store and translate elements from the execution results after the evaluation tool Op has stopped. The control block 144 can then be configured to trigger one or more executions of the second evaluation tool O2, using the stored and translated elements, in response to the stopping of the evaluation tool Oi by the stop block 146.

[0200] The dynamic use of candidate configuration analysis results between different tools in the control block 144 and the evaluation of optimization criteria in the stopping block 146 enables a rapid and comprehensive multi-level and / or multi-scale evaluation of candidate configurations for different criteria. In particular, the configuration of the control block 144 allows for the retrieval of traces from different evaluation tools (e.g., simulators) and their real-time injection into a second evaluation tool (e.g., a simulator), or other evaluation tools, for a mixed and dynamic evaluation of several parameters. Furthermore, the configuration of the stopping block 146 allows for the stopping of a simulation at any time during the execution of the simulators according to a specified stopping criterion, and the return of the results obtained.Stopping the simulators according to the embodiments of the invention allows for a compromise between time and accuracy in the evaluation of candidate configurations.

[0201] For example, and without limitation, one or more given candidate configurations can be evaluated by the GEM5 simulator to obtain a very precise estimate of the computational performance values ​​Ci associated with these configurations. However, the very high analysis (i.e., simulation) time of these configurations by the GEM5 simulator can lead to a long overall evaluation time for all candidate configurations in the same optimization iteration. Alternatively, one or more given candidate configurations can be evaluated by the VPsim simulator to obtain a less precise estimate of the computational performance values ​​Ci associated with these configurations, but the very short analysis (i.e., simulation) time of these configurations allows for an acceleration of the overall evaluation of all candidate configurations in the same optimization iteration.Thus, such simulators can be run in parallel, and the evaluation of optimization criteria in stop block 146 can use either of the two simulators (GEM5 or VPsim) depending on the availability of evaluation results. In particular, the evaluation of optimization criteria, and therefore the evaluation of at least one candidate configuration, can be updated in response to the recording of results from a simulator.

[0202] For example, and without limitation, to obtain an estimate of the computing performance values ​​Ci associated with one or more given candidate configurations, stop block 146 can further combine the evaluation results from the Arm Fast models (which are not related to execution time) with the evaluation results from the VPSim simulator. Such a combination allows for a dynamic estimation of the computing performance values ​​Ci, by focusing on a particular part of the hardware architecture (or by processing it individually) via the model (or method) called ROI (acronym for Region Of Interest meaning "Region of Interest").

[0203] According to another non-limiting example, to obtain an estimate of C2 energy consumption values ​​associated with one or more given candidate configurations, stop block 146 can combine the evaluation results of these configurations by GEM5 and VPsim (interconnect or memory access obtained) with the consumption of an access (read, write, etc.). The consumption of an access can be obtained from data from a computing resource provider (IP block, acronym for 'Intellectual Property'), from RTL simulations of an architectural model (memory models, IP models simulated in tools such as Synopsys' PrimeTime PX), from data related to the technology node, or from high-level simulations performed using dedicated simulators such as CACTI for cache memories or McPat for the entire system.

[0204] To obtain an estimate of the values ​​of criterion C3 (area of ​​the integrated circuit) for at least one given candidate configuration, stop block 146 can combine available data (for example from a computing resource provider), evaluation results of RTL syntheses of an architectural model (for example Synopsys Design Compiler), surface models available in McPat, or high-level simulations carried out using dedicated simulators (for example CACTI for cache memories).

[0205] According to some embodiments, step 160 of the determination process can use the results of the evaluation of the recorded candidate configurations Gn and the evaluations of the optimization criterion values ​​to determine optimized configurations Gopt.

[0206] In some embodiments, step 160 may include a substep for sorting and / or ranking the evaluated candidate configurations Gn (or configuration instances). Such a substep may be performed (or executed) based on determined values ​​of optimization criteria for the Cq circuit and / or the evaluation of one or more objective functions and / or constraints with respect to the determined values ​​of optimization criteria for the Cq circuit. Such a substep may also be performed in such a way as to maintain the so-called 'dominant configurations'. A dominant configuration refers to a candidate configuration defined with respect to at least one other candidate configuration evaluated during the same execution iteration of a tool, the same optimization iteration, and / or two different execution or optimization iterations.A dominant configuration presents configuration evaluation results inducing a better evaluation across all objective functions and / or constraints compared to . to the evaluation across all objective functions and / or constraints induced by the configuration evaluation results from a secondary candidate configuration. Such a substep can also be carried out in such a way as to order the evaluated candidate configurations, or only dominant configurations, according to the evaluation of one or more objective functions and / or constraints.

[0207] A person skilled in the art will readily understand that certain steps or sub-steps of the process can be carried out simultaneously, sequentially, successively, independently or not, and / or in a different order, for example in an order defined by the initialization of the implementation of the tools.

[0208] Fig. 6 represents an example of a hardware architecture design system 1 for an integrated circuit in which the hardware architecture design process for an integrated circuit can be implemented.

[0209] The system 1 for determining (or designing) the hardware architecture of an integrated circuit includes a hardware architecture determination device 20 configured to implement the method for determining integrated circuit hardware architectures. The determination system 1 further includes a memory 40.

[0210] As shown in [Fig. 6], the system 1 comprises a set of 60 available evaluation tools. The device 20 may include a module 202 configured to generate candidate configurations Gn, an evaluation module 204 configured to evaluate the candidate configurations from the selected evaluation tools Om, and an exploitation module 206 configured to exploit evaluation results of candidate configurations to generate optimized configurations.

[0211] In particular, the evaluation module 204 (or control module, pilot module) can be configured to implement the various functional blocks associated with the evaluation of candidate configurations Gn in the determination process.

[0212] In embodiments, memory 40 may include at least one RT translation register associated with the assessment tools which can be used by the assessment module 204 to select the transcription elements associated with the assessment tools and translate elements of the candidate configurations.

[0213] The memory 40 may further include a temporary memory 402 configured to store at least some of the evaluation results delivered by the plurality of evaluation tools Om executed and / or the values ​​of the circuit optimization criteria Cq associated with candidate configurations. The use of a temporary memory 402 makes it possible to accelerate the exploration of different multi-scale and / or multi-level architecture configurations to quickly and accurately generate an optimized integrated circuit.

[0214] In embodiments, the system 1 may include one or more data input / output interfaces, such as human-machine interfaces (HMIs). These human-machine interfaces may include one or more means for acquiring or transmitting information, such as input and control devices (e.g., microphone, speaker, keyboard) and / or one or more display devices (e.g., video screen, touchscreen, etc.). For example, and without limitation, the system 1 may include a human-machine interface configured to acquire an architecture descriptor provided by a user of the system 1 in the form of a computational architecture demplate, enabling the architecture exploration space to be defined.

[0215] In some embodiments, system 1 may include an 801 translation tool configured to transform the optimized Gopt configuration into a hardware architecture description file (also called a 'hardware description file') at the RTL level, defining the behavior of a circuit and directly convertible into combinational logic gates and sequential elements (flip-flops, etc.). A low-level, or RTL-level, hardware architecture description can, for example, be defined in a Hardware Description Language (HDL) such as Verilog or VHDL.

[0216] The exploitation of optimized Gopt configurations by implementing the hardware architecture determination method, according to the embodiments of the invention, allows multi-scale and / or multi-level management of the design of integrated circuit hardware architectures.

[0217] The set 60 of the determination system 1 may include evaluation tools that can be used according to different scales of architectural configurations or one or more constituent elements of an architectural configuration. Thus, the translation and function registers can be adapted to the evaluation tools and to each of the different levels of architectural configuration description usable by the evaluation tools. Advantageously, some evaluation tools can be used and operated on a multitude of levels of hardware architecture design.

[0218] Those skilled in the art will understand that the invention can be implemented by computer, in particular as a computer program comprising instructions for its execution. The computer program can be stored on a storage medium readable by a processor. The reference to a computer program that, when executed, performs any of the functions described above, is not limited to an application program running on a single host computer. Rather, the terms computer program and software are used here in a general sense to refer to any type of code Computer science (for example, application software, firmware, microcode, or any other form of computer instruction) that can be used to program one or more processors to implement aspects of the techniques described herein. Computing means or resources may be distributed ("cloud computing"), possibly using peer-to-peer technologies.

[0219] The software code can be executed on any suitable processor (e.g., a microprocessor) or processor core or a set of processors, whether provided in a single computing device or distributed among several computing devices (e.g., as possibly accessible in the device's environment). The executable code of each program enabling the programmable device to implement the processes according to the invention can be stored, for example, in the hard drive or in read-only memory. Generally, the program(s) can be loaded into one of the device's storage means before being executed. The central processing unit can command and direct the execution of the instructions or portions of software code of the program(s) according to the invention, instructions which are stored in the hard drive or in read-only memory or in the other aforementioned storage elements.

[0220] The method for determining hardware architectures can be implemented on a distributed computing unit comprising a plurality of physical cores. The embodiments of the invention are particularly well-suited to such a distributed implementation as well as to porting to multi-core hardware technologies. The method for determining hardware architectures according to the embodiments of the invention can be implemented in computer code (which may in particular consist of a hardware abstraction language) in various languages, such as C, C++, Python, etc.

[0221] The invention is not limited to the embodiments and examples described above by way of non-limiting example. The invention encompasses all embodiments that can be envisaged by a person skilled in the art.

Claims

1. Demands A method for determining the hardware architecture of an integrated circuit, the method being implemented by computer, characterized in that the method comprises: - the determination (120) of a plurality of candidate architecture configurations (Gn) corresponding to different hierarchical scales of the architecture of said integrated circuit to be designed, each candidate configuration (Gn) being defined by a set of configuration elements comprising at least one configuration element, each candidate configuration (Gn) being associated with a number (Hn) of instances of the candidate configuration, each configuration instance corresponding to a combination of values ​​of said configuration elements, - the evaluation (140) of said plurality of candidate configurations (Gn) using at least two evaluation tools (Om) chosen from a plurality of evaluation tools capable of performing a multi-level architectural design analysis, each candidate configuration (Gn) being evaluated by at least one of said evaluation tools (Om) chosen, the evaluation of a candidate configuration (Gn) by an evaluation tool comprising the iterative execution of the evaluation tool to evaluate one or more instances of said candidate configuration, the iterative execution of the tool comprising a number (H;) of iterations, each iteration corresponding to the evaluation of an instance of the candidate configuration by the evaluation tool, the evaluation stage providing an evaluation output relating to the execution of each of the at least two of said selected evaluation tools (Om), - the determination (160) of at least one optimized configuration of a hardware architecture of an integrated circuit (Gopt) from said evaluation output, and in that the process comprises: - an automatic piloting (144) of said at least two of selected evaluation tools (Om), said piloting comprising piloting at least one iterative execution of each evaluation tool for the evaluation of at least one candidate configuration (Gn), the method comprising an interruption (146) of the iterative execution of an evaluation tool (Om) associated with a candidate configuration, in response to the verification of a stopping criterion, the stopping criterion being defined such that the total number of iterations (H;) of said iterative execution is strictly less than the number (Hn) of instances of the candidate configuration (Gn).

2. A method according to claim 1, wherein the evaluation step (140) includes resuming the iterative execution of a selected evaluation tool (Om), after an interruption, in response to the verification of a defined resumption criterion such that the total number of iterations (Hj) of said iterative execution is strictly greater than the number of iterations (Hj) carried out up to the interruption (146).

3. A method according to any one of the preceding claims, wherein said plurality of candidate configurations (Gn) comprises at least one first candidate configuration (Gi) and one second candidate configuration (G2), said second candidate configuration (G2) being a sub-configuration of said first candidate configuration (GJ), said evaluation tools (Om) chosen comprising at least one first evaluation tool (Oi) for evaluating said first candidate configuration (Gi) and one second evaluation tool (O2) for evaluating said second candidate configuration (G2), the stopping criterion for the interruption of the iterative execution of said second evaluation tool (O2) being checked in response to the interruption of the iterative execution of said first evaluation tool (OJ).

4. A method according to any one of claims 1 to 3, wherein the evaluation of an instance of a candidate configuration (Gn) by an evaluation tool comprises: - an analysis of an instance of said architecture configuration, by the evaluation tool, in response to the reception of input quantity values ​​(Em) associated with the configuration instance, and - the determination of a set of output quantity values ​​(Sm) relating to the result of the analysis of the configuration instance by said evaluation tool.

5. A method according to claim 4, wherein said evaluation step (140) comprises, for each candidate configuration (Gn) to be evaluated, the translation of at least a part of said candidate configuration (Gn) into input quantity values ​​(Em) and the generation of an input file (Fm) associated with one of said evaluation tools (Om) chosen to evaluate said candidate configuration (Gn), said input file (Fm) comprising said input quantity values ​​(Em).

6. A method according to any one of claims 3 to 5, wherein said plurality of candidate configurations (Gn) comprises at least one first candidate configuration (Gi) and one second candidate configuration (G2), said evaluation tools (Om) selected comprising at least one first evaluation tool (Oi) for evaluating said first candidate configuration (Gi) and one second evaluation tool (O2) for evaluating said first candidate configuration (G2), and wherein each iteration of an iterative execution of an evaluation tool provides at least one output magnitude value, the iterative execution of the first evaluation tool (Oi) for evaluating said first candidate configuration (Gi) comprising, in response to an iteration of execution of said first evaluation tool (Oi), the storage of said at least one output magnitude value (Si),and the triggering of at least one execution iteration of said second evaluation tool (O2) to evaluate said second candidate configuration (G2).

7. A method according to claims 4 and 5, wherein at least one value of input quantities (E2) of said input file of said second evaluation tool (O2) is defined from the translation of said at least one value of output quantities (Si) stored.

8. A method according to any one of claims 1 to 5, wherein the evaluation step (140) comprises the simultaneous triggering of at least an iteration of execution of at least two tools from among said evaluation tools (Om) chosen.

9. A method according to any one of claims 1 to 8, wherein said stopping criterion is defined as a function of an evaluation of at least one objective function and / or constraint relative to at least one optimization criterion, said at least one optimization criterion (Cq) being chosen from a calculation performance criterion, an energy consumption criterion and / or a surface area criterion of said integrated circuit to be designed.

10. A method according to any one of claims 1 to 8, wherein said stopping criterion is defined as a function of the execution time of at least one of the execution iterations of an evaluation tool (Om) considered, the stopping criterion being satisfied if said execution time reaches a predefined maximum execution time.

11. A method according to any one of claims 1 to 10, wherein an evaluation tool (Om) of said plurality of evaluation tools is an evaluation tool selected from an architecture configuration simulator, an architecture compilation tool, a consumption evaluation tool, a tool based on the exploitation of a database and a tool based on the exploitation of a candidate configuration data memory.

12. Integrated circuit hardware architecture obtained by implementing the method according to any one of claims 1 to 11.

13. Method of designing an integrated circuit comprising an implementation of an integrated circuit from the integrated circuit hardware architecture of claim 12.

14. Product computer program comprising programming code instructions capable of being implemented by a computer, the computer being capable of implementing the method according to any one of claims 1 to 11.

Images