WO2025221815A1 - Accelerating microarchitecture simulation with machine learning - Google Patents

Accelerating microarchitecture simulation with machine learning

Info

Publication number
WO2025221815A1
WO2025221815A1 PCT/US2025/024808 US2025024808W WO2025221815A1 WO 2025221815 A1 WO2025221815 A1 WO 2025221815A1 US 2025024808 W US2025024808 W US 2025024808W WO 2025221815 A1 WO2025221815 A1 WO 2025221815A1
Authority
WO
WIPO (PCT)
Prior art keywords
microarchitecture
agnostic
trace
deep learning
learning model
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2025/024808
Other languages
French (fr)
Inventor
Hang Liu
Santosh Pandey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Rutgers State University of New Jersey
Original Assignee
Rutgers State University of New Jersey
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Rutgers State University of New Jersey filed Critical Rutgers State University of New Jersey
Publication of WO2025221815A1 publication Critical patent/WO2025221815A1/en
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/045—Combinations of networks
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/084—Backpropagation, e.g. using gradient descent
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/0895—Weakly supervised learning, e.g. semi-supervised or self-supervised learning
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/09—Supervised learning
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/091—Active learning
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/092—Reinforcement learning
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/094—Adversarial learning
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/096—Transfer learning
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/098—Distributed learning, e.g. federated learning
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/0985—Hyperparameter optimisation; Meta-learning; Learning-to-learn

Definitions

  • embodiments and implementations hereof may involve use of microarchitecture agnostic trace data and associate performance metrics.
  • BACKGROUND [0004] As “smart” technology proliferates throughout modern society, from IoT and edge devices to advanced AI-supporting servers, the need for high-performance processing resources that are tailored to their intended use cases and environmental/design constraints has expanded. Manufacturers of chips, ASICs, and other microarchitecture-based circuits and logic have encountered needs of their customers for an increasing breadth and variation in performance among their product offerings, as well as desires for software/hardware co-development and custom chip development for anticipated applications.
  • execution-driven platforms may allow for simulations, but suffer from significant computational overhead, resulting in simulation speeds that are often many orders of magnitude slower than real hardware execution – this makes them an imperfect simulation as well as time- consuming and resource hungry.
  • “Trace-driven” approaches may seek to reduce overhead of simulation by essentially ‘replaying’ previously-identified execution traces on different microarchitecture designs; yet, these simulations exhibit notable accuracy challenges due, in part, to differences in execution paths, instruction scheduling, and dynamic runtime behaviors across different microarchitectural configurations. Other approaches have sought to leverage leveraging machine learning techniques for simulation.
  • the present disclosure can provide a method for simulating a hardware design.
  • a plurality of microarchitecture agnostic trace data from a hardware design can be extracted.
  • the plurality of microarchitecture agnostic data can be provided to a trained deep learning model.
  • a simulation of microarchitecture corresponding to hardware information can be commenced.
  • a plurality of similarities or relationships between instruction features of the plurality of microarchitecture agnostic trace data can be processed.
  • a plurality of instruction embeddings can be generated using a plurality of embedding layers from the trained deep learning model.
  • a plurality of performance metric predictions associated with microarchitecture agnostic trace information outputted from the trained deep learning model can be obtained.
  • FIG.1 is a process flow diagram of an example method for predicting performance metrics of a hardware design.
  • FIG. 2 is a process flow diagram of an example method for creating a training dataset for hardware design performance prediction.
  • FIG. 3 is a process flow diagram of an example method for training a deep learning model to predict performance metrics of a hardware design.
  • FIGS. 4A-4D illustrate a comparison between a mainstream simulation mechanism and a Tao microarchitecture, according to some embodiments.
  • FIG. 5 illustrates a training dataset construction illustrated via trace snippets, according to some embodiments.
  • FIG. 6 illustrates an example feature engineering diagram, according to some embodiments.
  • FIG.7 illustrates an example input for branch instruction, according to some embodiments.
  • FIG. 8 illustrates an example deep learning model architecture, according to some embodiments.
  • FIG. 9 illustrates an overview of transfer learning, according to some embodiments.
  • FIGS.10A-10C illustrate a comparison of multi-architecture training paradigms, according to some embodiments. [0023] FIG.
  • FIG. 11 illustrates a process for selecting a training dataset, according to some embodiments.
  • FIG. 12 is a chart illustrating simulation accuracy comparisons, according to some embodiments.
  • FIG.13 is a chart illustrating instruction differences in percentages for speculative and nop QB ⁇ 95869970.1 Docket No. 183161.00022 5 instructions, according to some embodiments.
  • FIG. 14 is a chart illustrating trace throughput comparisons for detailed and function traces, according to some embodiments.
  • FIGS. 15A-15L are plots illustrating phase behavior for test benchmarks, according to some embodiments.
  • FIGS. 16A-16B are plots illustrating choices of context size and branch configuration, according to some embodiments. [0029] FIG.
  • FIG. 17 is a plot illustrating a number of epochs and a test error on a log scale, according to some embodiments.
  • FIG. 18 is a chart illustrating training dataset selection, according to some embodiments.
  • FIGS. 19A-19B are plots illustrating hardware design space exploration of L1 Dcache misses and branch mispredictions, according to some embodiments. DETAILED DESCRIPTION [0032] The detailed description set forth below, in connection with the appended drawings and the attached appendices, is intended as a description of various configurations and is not intended to represent the only configurations in which the subject matter described herein may be practiced. The detailed description includes specific details to provide a thorough understanding of various embodiments of the present disclosure.
  • the teachings provided herein may be implemented in the form of a method for simulating a hardware design that is capable of determining performance metrics that can provide design improvements and recommendations for fast microarchitecture exploration.
  • Some embodiments may be implemented as simulation tools for computer microarchitecture design and hardware engineering.
  • Designers of hardware e.g., chips, microcontrollers, processors, circuits-on-a-chip, etc.
  • the use of such simulation tools will reduce the development cycle, allow for early detection and correction of design bottlenecks, and enables rapid iteration over design variations by providing more detailed and accurate information.
  • Embodiments may also be implemented as tools for predicting and evaluating quality and performance of existing designs under specified, real-world conditions. For example, some embodiments may allow semiconductor companies and hardware manufacturers to evaluate their existing designs and/or product offerings so as to predict real-world hardware performance under certain conditions. E.g., where a new device, board, or application is desired, a manufacturer or designer may evaluate potential existing processing/chip solutions to determine which may offer optimal performance under those conditions, helping ensure their designs will meet targeted performance and reliability metrics and optimize for cost-performance trade-offs. [0038] Other embodiments may be implemented as software development tools for purpose- driven designs.
  • FIG. 1 is a flow diagram illustrating an example process 100 for predicting performance metrics of a hardware design.
  • the process 100 may optionally obtain hardware design information.
  • the hardware design information may be a user-identification of a given processor or microarchitecture type and/or may include design requirements of a given computer processor, microcontroller, logic circuit, circuit-on-a-chip, ASIC, or the like.
  • the hardware design information may include a full or partial transistor-level layout, such as RTL or HDL design files reflecting low-level hardware description (e.g., .vhdl files, Verilog files, etc.).
  • the hardware design information may be more high level or conceptual, such as high level architecture configuration files or layouts according to block functions (e.g., files that specify microarchitectural parameters like pipeline widths, buffer sizes, cache sizes, branch predictors, etc. for use in simulators).
  • the hardware design information may include or correspond to a processor with varying cache size requirements, pipeline length, layout, memory allocations, etc.
  • hardware design information may include descriptions of compiled or serialized deep learning models, which correspond to pre-trained models that define or will be implemented by microarchitectural configurations.
  • step 102 may QB ⁇ 95869970.1 Docket No. 183161.00022 8 also include generating higher-level information from low-level hardware layouts/descriptions.
  • the process 100 may microarchitecture agnostic trace data, such as “functional trace” information and/or “execution trace” information, as described in various embodiments herein. .
  • step 104 may involve obtaining microarchitecture- agnostic execution trace information by simulating a benchmark program using a functional simulator, or obtaining such trace information that was previously generated through processor- agnostic, microprocessor-agnostic and/or microarchitecture-agnostic simulation of a given program, workload, application, code, function, algorithm, neural network etc.
  • the functional trace information may include, for example, information regarding the functions, steps, or behaviors of a program, such as information about the instructions it entails relative to a processing resource (e.g., relative to a generic processing resource or process model, or a general class of processing resource types, etc.).
  • a benchmark program may be run via a functional simulator that produces execution-level traces that may comprise or reveal dynamic performance metrics and/or static properties of instructions caused by or comprising the program, such as opcodes, register usage, branch addresses, and memory addresses, without microarchitecture-specific timing information, .
  • the process 100 provides the microarchitecture agnostic trace data to a trained deep learning (DL) model.
  • the trained DL model may be trained using datasets and methods described below with respect to processes 200 and 300.
  • the DL model may be trained to capture relationships between instructions and a given microarchitecture, processor, general class of processors, or other hardware, based on properties of the instructions, as well as performance metrics.
  • the DL model may be fine-tuned to a specific category of processor design (e.g., to single core, multi-core, many-core general processing designs, application/function-specific circuits, low-power edge processors, systems on a chip, etc.), whereas in other examples the DL model may be trained on a wide variety of designs.
  • the DL model may be trained to simulate real-world behavior of given processor execution.
  • information obtained regarding a hardware or architecture of interest, such as obtained with respect to step 102 may be utilized to select and/or fine-tune a DL model that can be used for simulation.
  • a DL model has been pre-trained to represent or simulate a processor, class of processors, or microarchitecture of interest.
  • Such preexisting models may be utilized by software developers to assess performance of applications QB ⁇ 95869970.1 Docket No. 183161.00022 9 or other code that will be run on that hardware.
  • preexisting models may be utilized to benchmark performance of a given resource or design against potential new or alternative designs and architectures curing co-development of software and hardware.
  • DL models may be included in a library of available models, each associated with hardware and/or architecture information for purposes of selection for use various simulation tasks.
  • a preexisting or pretrained DL model may not be available that is suitable for a given simulation task.
  • a transfer learning approach may be utilized to adapt an existing DL model (e.g., a DL model pre-trained on a generic processing resource, a processing resource of a same/similar class, a given microarchitecture approach, etc.) to rapidly generate a suitable DL model applicable to the new microarchitecture.
  • an existing DL model e.g., a DL model pre-trained on a generic processing resource, a processing resource of a same/similar class, a given microarchitecture approach, etc.
  • the hardware information obtained at step 102 may be utilized to select a DL model that can be used as a basis for fine-tuning through transfer learning, and to train, retrain, and/or fine-tune that DL model such that it will accurately simulate a microarchitecture per the hardware information.
  • the process 100 commences simulation of a microarchitecture corresponding to the hardware information, such as by calling for generation of performance metrics based on the microarchitecture agnostic trace data from the DL model output.
  • microarchitecture-agnostic trace data that comprises functional trace information can be provided as input to a DL model obtained in process 106, and process 100 can obtain performance information from outputs of the DL model.
  • these metrics can include instruction latencies, fetch and execution cycles, branch mispredictions, and data access levels.
  • the process 100 may in some embodiments process similarities or relationships between instruction features of the microarchitecture agnostic trace data via the deep learning model.
  • the deep learning model can utilize learned representations or mappings between the instruction features and the microarchitecture data on which the DL model was trained.
  • the process 100 may in some embodiments utilize or leverage a plurality of embedding layers of the DL model, such as to generate a plurality of instruction embeddings based on two-level embedding layers. QB ⁇ 95869970.1 Docket No.
  • the process 100 obtains from outputs of the DL model predictions of a plurality of performance metrics associated with the agnostic trace information. [0050] At step 116, in some examples, these metrics may be used to determine whether the microarchitecture design modeled by the DL model meets a users’ design requirements. For example, process 100 may include making a determination that the microarchitecture design “succeeds” in achieving stated performance goals (such as latency, etc.) for a given workload, or “fails” or does not meet certain performance requirements, such as if the design were implemented outside of a simulation to perform a given processing task.
  • stated performance goals such as latency, etc.
  • process 100 may also or alternatively include making a determination as to whether an application or code, when run on a microarchitecture modeled by the DL model, will cause the microarchitecture to succeed or fail on given design requirements (e.g., instruction latency, fetch/execution cycles, and/or higher-level information such as predicted power usage based on cycles and other actions).
  • the metrics may be outputted on an user device, such as a laptop, a computer, a smartphone, etc.
  • the performance metrics may be saved or sent to a memory of one or more devices, such as saving the performance metrics and successes/failures in a database record for the associated microarchitecture design iteration or software version that is being designed and simulated.
  • the process 100 optionally recommends alterations to the hardware design.
  • the recommended alterations can include techniques which may be used to improve the metrics and performance of the design.
  • FIG. 2 a flow diagram is presented, illustrating an example process 200 for creating and refining a training dataset in a manner that will optimize its use for hardware design performance prediction, such as through use of a machine learning or deep learning algorithm or model that is trained on this dataset. For example, a deep learning model described above with respect to process 100 may be trained using the training set created by process 200.
  • the process 200 obtains a plurality of microarchitecture hardware design information for a processor, microcontroller, chip, architecture, or other processing resource of interest.
  • the hardware design information can include information such as the hardware design information described above with respect to step 102 of process 100.
  • the microarchitectural designs can include specific microarchitectural layouts and/or descriptions of attributes of a given hardware resource design/architecture of interest.
  • the hardware designs may include, or may be used to extract, various parameters that describe behavior of a processor and/or its such as: pipeline configuration (e.g., fetch width, reorder buffer size, etc.); cache design (e.g., hierarchy, sizes, association information, latency information, etc.); a branch prediction algorithm; a memory subsystem configuration; and/or an instruction set architecture.
  • the hardware design information may also comprise information usable to obtain detailed trace information, such as timing information obtained through detailed stimulations of a hardware design.
  • the plurality microarchitecture hardware design information may comprise architectural information of a hardware resource sufficient to enable detailed simulation of the hardware resource, as described below and in the Examples section herein.
  • the process 200 obtains microarchitecture agnostic trace data (or functional trace data) for a given benchmark program or other application, based on a generic hardware design.
  • the trace data can be obtained and include properties as described above with respect to step 104.
  • the static properties extracted can include opcode, register information, and instruction flags.
  • the trace data may include a stream of instructions generated by a functional or detailed stimulation.
  • the traces may capture various static instruction properties or dynamic performance metrics of a benchmark program, application of interest, workload, etc.
  • such functional trace data may have been previously obtained and stored in a database in association with various benchmark or example programs.
  • the process 200 may obtain microarchitecture-dependent trace information for the microarchitecture of interest.
  • process 200 may perform a simulation of the microarchitecture of interest by providing the hardware information obtained in step 202 to a detailed simulator and causing it to simulate the same benchmark program or application from which the microarchitecture agnostic trace data (or functional trace data) was obtained in step 204.
  • process 200 may then associate microarchitecture agnostic trace data (or functional trace data) from step 204 with microarchitecture-dependent trace information (or detailed trace data) from step 206 as a pair, based on the common benchmark program or other application that was used. For example, process 200 may align instructions from the functional trace and the detailed trace, to pair them together in an associative or aligned manner. In some embodiments, this may include removing speculative, stall-related, or other outlier instructions QB ⁇ 95869970.1 Docket No. 183161.00022 12 from the detailed trace, and attributing the performance impact to the corresponding instructions in the functional trace.
  • process 200 can be thought of as obtaining a plurality of performance numerals associated with each of the static properties.
  • the performance numerals may be determined based on differences and attributes linked to specific instructions within the functional trace.
  • static features of instructions from the functional trace information can be combined with corresponding performance labels from the detailed trace information; thus instruction-level pairings, multi-instruction-sequence pairings, as well as application-level pairings can be obtained.
  • Steps 204-208 may be repeated in a cycle or iterative loop, to generate more pairings of functional and detailed trace information, such as by running different programs, workloads, applications, and/or benchmarks to generate pairs.
  • additional pairings may alternatively or additionally be generated by varying hardware information to reflect varying architectures or processors of a class or family of resources that will be modeled by a DL model.
  • the process 200 creates a training dataset based on the plurality of performance numerals. This training dataset may be used to train and/or fine-tune one or more deep learning models used for predicting performance metrics. Additionally, or alternatively, the training dataset may be stored in a database in association with a record for the hardware/architecture design and hardware information. Thus, the training data may be re-used for purposes of generating more- specific/more-tailored DL models and/or for generating DL models that can predict performance for a more general class of hardware.
  • the training dataset may be used in combination with process 300, as described below, to adapt a DL model through a transfer learning-based method so that it will be tailored to a different microarchitecture without incurring the time or resource expenditure of fully training a model from scratch.
  • the one or more deep learning models may be used for improving and evaluating other functionalities and design characteristics of various hardware designs.
  • process 200 trains a DL model using the training dataset.
  • the detailed trace information and performance metrics may be utilized as “ground truth” or to define the output channels of a DL model, and the associated functional trace information may be used as the “input” data.
  • the DL model can learn representations of how software instructions (from the functional trace information) correlate to hardware-level behavior for the specific hardware design of interest, as described by the hardware information.
  • QB ⁇ 95869970.1 Docket No. 183161.00022 13 the structure of the DL model may comprise a novel combination of inputs, layers, connections, and outputs.
  • the DL model may be structured to accept microarchitecture-agnostic functional traces as inputs and output multiple performance metrics at the instruction level.
  • such a DL model may have an input feature encoding layer that extracts features from the functional trace information/static instruction information (e.g., opcode, source/destination register information, etc.). These features may then be passed through feature- specific embedding layers.
  • these feature embeddings may be processed by the DL model in a two-level embedding fashion, such that the feature-specific embeddings are combined after being generated (e.g., concatenated as a vector).
  • the DL model may then process a sequence of instruction embeddings via a multi-head self-attention network, which may be structured similar to a transformer network encoder. This layer comprises learned temporal and substantive relationships between instructions. This structure allows for better long-range capture of dependences than and LSTM or CNN-style architecture.
  • the DL model may comprise architecture-specific prediction and adaptation layers.
  • the outputs of the self-attention network may be processed by individual prediction heads – each head representing an output performance metric (e.g., execution latency, data access level, etc.).
  • the DL model itself may be trained via a multi-task loss function, such as one combining regression losses for continuous outputs and classification losses for categorical outputs.
  • the DL model can be trained to generate both continuous-value outputs as well as generating binary/class decision outputs, with varying combinations thereof, while still retaining the internal network learnings of their relationships.
  • FIG. 3 a flow diagram is presented, illustrating an example process 300 for training a deep learning model to predict performance metrics of a hardware design.
  • the process 300 obtains a plurality of embedding layers corresponding to agnostic trace data of a hardware design.
  • instruction properties such as opcode, register information, data access addresses, and PC addresses associated with the hardware design can be obtained.
  • the process 300 generates a first microarchitecture based on prediction and adaptation layers of shared embedding layers.
  • the process 300 determines a first plurality of gradients based on individual embeddings of the first microarchitecture. In some examples, each gradient can include a QB ⁇ 95869970.1 Docket No. 183161.00022 14 magnitude for shared layers.
  • the magnitudes may be negative when gradients are from different microarchitectures that are to each other.
  • the process 300 generates a second microarchitecture based on prediction and adaptation layers of the plurality of embedding layers.
  • the process 300 determines a second plurality of gradients based on individual embeddings of the second microarchitecture.
  • the process 300 normalizes the first and second plurality of gradients based on magnitudes. In some examples, the normalization of the gradients can reduce magnitude imbalances and can ensure gradients from the first and second pluralities are within the same or a similar range.
  • the process 300 trains a deep learning model based on the plurality of embedding layers as inputs and normalized gradients as corresponding outputs.
  • the deep learning model used by process 100 may be pre-trained by the steps of process 300.
  • process 300 may be used to update the training of a pre- trained deep learning model.
  • Execution trace Described herein are execution traces, which refer to the stream of instructions generated by functional or detailed simulation.
  • the gem5 simulator is modified to generate execution traces capturing various static instruction properties and dynamic performance metrics.
  • Functional trace refers to the microarchitecture agnostic trace generated with functional simulation using AtomicSimpleCPU model.
  • the terms functional trace and microarchitecture agnostic trace are used interchangeably. It only contains static properties like opcode, registers, and other instruction flags.
  • Detailed trace refers to the trace generated with the O3CPU model. It captures various microarchitecture specific performance metrics like data access misses, instruction cache misses, branch mispredictions, speculative instructions and latency of individual instructions.
  • Deep Learning (DL) based microarchitecture simulation In DL-based approaches, the simulated processor is abstracted as a whole, eliminating the need to simulate individual components within the processor. As DL excels at deriving the sophisticated rules that govern various complex functions, recent work shows that it can capture the microarchitecture simulations in a similar way.
  • Previous DL-based simulations e.g., SimNet and Ithemal manage to model the performance of a program at the instruction level, generally, in two steps: (i) An DL model is trained to capture the complex and dynamic relationships between instructions and the hardware based on the instruction properties and the performance metrics.
  • the performance prediction problem can be defined as: (1) where is the desired output performance metric of the instruction, typically including the cycles required to execute the instruction. , . .
  • the input features include the properties of the current and earlier instructions (i.e., context QB ⁇ 95869970.1 Docket No. 183161.00022 16 instruction).
  • Context instructions are used to model the dependencies and resource contentions among the instructions.
  • the instruction of existing DL-based simulators include static features like opcode, registers used by the instruction, branch predictions and data access level.
  • the performance metric and input features are gathered from detailed traces by simulating various programs. is a microarchitecture specific function the model learns. (ii) During inference, this trained DL model can be used to predict the performance metrics of various unseen programs for the same microarchitecture at the instruction level.
  • the required instruction input features are collected from dynamic profiling or simulation for a specific microarchitecture. As the processor is abstracted as a whole, any change in the microarchitecture requires re-training of the DL model with microarchitecture specific training datasets. [0074] In some embodiments, the inventors have contemplated that it may be advantagous to configure a system such that (i) the input to the DL model should only (or need only) capture the instruction execution sequence and (ii) the DL model should govern the hardware features stemming from the following considerations: First, if the input to the DL model only needs to capture the execution sequence, the DL model captures all the microarchitecture features.
  • a trained DL model can be used to predict the impactful and/or important low-level microarchitectural performance metrics (i.e., CPI, branch mispredictions, cache misses) of any benchmarks, even when only provided with an input as noted above.
  • CPI microarchitectural performance metrics
  • generating the microarchitecture-agnostic instruction execution sequence of a particular benchmark is significantly faster than generating the traces with architectural information (referred to as detailed trace herein).
  • the inventors have also contemplated that it may be advantagous to configure a system such that a DL-based microarchitecture simulator can (i) report various performance metrics during the architecture simulation and (ii) support rapid explorations of different architecture configurations.
  • a DL-based microarchitecture simulator can (i) report various performance metrics during the architecture simulation and (ii) support rapid explorations of different architecture configurations.
  • other approaches might provide cycles as the only output metrics from the DL prediction model. This limits the application of such approaches to be used in simulators for microarchitectural bottleneck analysis. Further, learning from more metrics helps the model learn more complex program and hardware interactions, improving simulation detail and accuracy.
  • Second, conventional efforts require re-training of the model from scratch. Simulating the whole design would incur huge costs just for the training. This discourages the QB ⁇ 95869970.1 Docket No.
  • Tao is a multi-modal DL architecture for microarchitecture simulation.
  • the metrics are instruction latency, branch misprediction, data cache misses, instruction cache misses, and translation lookaside buffer (TLB) misses of each instruction.
  • TLB translation lookaside buffer
  • Three major performance metrics are used, i.e., latency, branch misprediction, and data cache misses, to explain how the detail and function traces are processed to arrive at the training dataset.
  • Tao can potentially support other performance metrics.
  • Functional and detailed traces output similar sequence order, which permits us to associate each instruction of a functional trace with a detailed trace. However, the challenge is that the difference in number of instructions between detailed and functional traces is nontrivial.
  • Table 1 shows the difference in instruction counts for detailed and functional simulations of 531.deepsjeng_r SPEC 2017 benchmark for a base ARM microarchitecture. As the table shows, for simulation with 1M and 10M as specified instruction count with gem5, the instruction counts QB ⁇ 95869970.1 Docket No. 183161.00022 18 of functional and detailed trace differ in 5.2% and 4.8%, respectively. [0080] Table 1: Number of instructions in detailed vs. function trace for 531.deepsjeng_r benchmark. # Detailed vs. Functional Trace Detailed trace (O3CPU) Functional Trace [0081] ollowing two aspects. First, a detailed trace includes various performance metrics introduced earlier for individual instructions.
  • a detailed trace includes two types of additional dynamic instructions during execution that are missing in the functional trace. Specifically, the detailed trace contains incorrect speculative and stall instructions. Incorrect speculative instructions are the wrongly executed instructions squashed based on branch prediction. Stall instructions are used to stall the pipeline by inserting a no-operation (nop) instruction in the pipeline when any other instructions cannot be executed. [0082] Both types of additional instructions can be converted into numerical performance differences and attributed to specific instructions from the functional trace. Using the stall instructions from the detailed trace as an example, one can project the timing impact of these instructions to the latency of the subsequent instructions. [0083] Squashed speculative instructions.
  • Instructions are speculatively executed following the prediction of whether a conditional branch instruction will be taken or not. If the predicted branch path is correct, speculatively executed instructions will be correct, thus the instruction streams of detailed and functional traces will be identical. When a speculative path is wrong due to branch misprediction, speculatively executed instructions should be squashed. This case leads to a distinction between functional and detailed traces. Having squashed speculative instructions in the detailed trace avoids separately modeling the total impact of a branch misprediction. [0084] The total impact of branch misprediction can be accounted for in the functional trace with the fetch timing information obtained from the detailed trace. If a branch is mispredicted, it will delay the fetch of the next correct instruction.
  • the training dataset resembles functional trace with only modifications regarding performance metrics (see red dashed line arrows).
  • the first branch instruction (b.ls 0x455cb4) is mispredicted, and two consecutive instructions are speculatively executed until the branch is resolved.
  • the fetch latency of the next correct instruction (subs x1, 0xff455) is 10, whereas the total overhead of branch misprediction is 18 cycles.
  • the speculative instructions are used and assigned the fetch latency of 18 cycles instead of 10 to (subs x1, 0xff455).
  • the fetch latency for (subs x1, 0xff455) changes from 10 to 18 cycles.
  • the ML model can be trained to predict the total impact of misprediction without squashed speculative instructions.
  • the nop instruction is removed from the detailed trace, and then the fetch clock is used to derive fetch latency for the following instruction.
  • the fetch latency for (ld x3, [ureg0]) is updated to 4 from 3.
  • the total cycles remain the same for the detailed trace and adjusted trace, i.e., 25 cycles.
  • the differences between detailed and function traces are observed, mainly focusing on speculative and nop instructions for various benchmarks and microarchitectures.
  • FIG. 6 shows the process of gathering the input features for the model.
  • the input should be representative enough that the DL model can learn to map the interplay between the instruction features and the microarchitecture to predict various performance metrics.
  • Four key instruction properties are extracted from the microarchitecture agnostic execution trace: the opcode, registers, data access address and PC address.
  • Opcode and registers derive the per-instruction features.
  • For opcode an integer mapping is employed for each unique opcode in the dataset.
  • registers since the instructions can involve multiple registers, a QB ⁇ 95869970.1 Docket No. 183161.00022 20 bitmap vector is created with a size equal to the total number of registers. If an instruction uses register, index in the vector will be set to 1 otherwise).
  • Both source and destination registers are included in the bitmap vector.
  • Cross-instruction features crucial for predicting branch misprediction and data access level, are derived from the PC and memory addresses.
  • the branch history is used as input to model the outcome of conditional branch instructions. This history, indicating the outcomes of prior branch instructions, is employed by existing branch predictors to predict whether the branch will be taken. For a given input feature size, storing the outcome of each branch in a separate queue will limit the number of unique branches. To address this, a hash table is employed to store the outcomes of branch instructions. Hashing effectively controls the input feature size while maintaining relevant outcomes history for each branch (exemplified in FIG. 7).
  • FIG. 7 shows an example of retrieving the branch input feature with a sample program execution trace.
  • PC a ddress%4 bucket is retrived and used as branch input features. Subsequently, the outcome of that branch is updated to the respective bucket before the next instruction.
  • To retrieve the branch input features for the last instruction of the program execution trace, i.e., (00A0: b.ls #5), it is first d etermined the hash bucket, i.e., (00A0%4 ) B .
  • the retrieved branch input feature will be [0 , -].
  • the input contains the earlier outcome of the same instruction.
  • the hash table effectively separates the outcome of other PC addresses like (00A8: b.le eax, edx, LOOP3) and (00B4: b.le rax, eax LOOP2), which may be unrelated. It is also important to note that this design also permits different branches that are hashed to the same bucket to together offer a global history for future predictions. [0090]
  • the access distance is calced, which is the difference between current memory access and the previous memory accesses, and use that as the input to the model. Data access level is used to derive the cache misses. Intuitively, if the access distance between the current and earlier memory access is smaller, current access is more likely to be in the cache.
  • Access distance is similar to reuse or stack distance histograms in earlier analytical models but cheaper to calculate.
  • a memory context queue is used to track the access distance of memory accesses.
  • the model first generates instruction embeddings from input features with two-level embedding layers and then uses multi-headed self-attention to perform multi-metric prediction.
  • a sequence of +1 instructions is used as input to the model.
  • earlier instructions can influence the performance of the current instruction, which are the context instructions.
  • the approach relies on the self-attention layer to autonomously learn which earlier instructions significantly impact the current instruction.
  • the embedding layers generate instruction embeddings in two steps. Initially, embeddings are created independently for each category of input. This separate generation facilitates enhanced representation learning for each category.
  • a trainable lookup table based embedding layer is employed for opcode.
  • distinct linear embedding layers are utilized for the remaining categories.
  • the individual instruction embedding is obtained by combining categorical embeddings through a linear layer.
  • Note embedding layers independently generate instruction embeddings for current and context instructions. Similar to SimNet, the value of is assigned as the maximum value of reorder buffer (ROB) in a design space, in this case, 128.
  • ROB reorder buffer
  • the prediction layers employ multi- head self-attention to determine the performance metrics. Considering the impact of microarchitecture, this approach allows attention layers to model the interaction between current and earlier instructions. Using self-attention obviates the need for manually tracking context instructions, enhancing efficiency.
  • More performance metrics like instruction cache miss and TLB miss can be predicted through a sigmoid
  • a loss is computed from each performance metric and combined with a linear ratio in backpropagation.
  • the retire clock of instructions is used. Retire clock is computed as current clock + fetch latency + execution latency.
  • the retire clock of the last instruction of a benchmark determines the total cycles.
  • Multi-metric prediction exploits the relatedness of performance metrics. With the attention model and microarchitecture agnostic input, the design allows us to output various performance metrics of interest. It can capture the relationship between each performance metric and the specific input features that impact the metric.
  • FIG. 9 illustrates the fast transfer learning process to enable Tao for a new unseen microarchitecture rapidly, i.e., Arch C, employing microarchitecture agnostic embedding layers and fine-tuning. Initially, shared embedding layers are trained with two carefully selected microarchitectures, i.e., Arch A and Arch B.
  • the parameters of shared embedding layers are frozen, i.e., the parameters are not updated during backpropagation.
  • the parameters of prediction layers and embedding adaptation layer are fine-tuned with the training dataset for Arch C.
  • Microarchitecture agnostic embedding design The shared embedding layers generate embedding for each individual instruction, and microarchitecture specific prediction layers predict the performance labels.
  • the prediction layers of each microarchitecture computes the gradients for the embedding layers separately. The combination of them is proposed to update the shared embedding layers.
  • FIGS. 10A-10C compares the multi-architecture training paradigm with two existing projects, Granite and GradNorm. Two microarchitectures, A and B, are used to illustrate the techniques.
  • each prediction n etwork predicts microarchitecture specific output labels ( and ) and losses ( and ).
  • FIG. 10A to derive the gradients for shared embedding layers, the gradients from the prediction layers of each are averaged (i.e., ). Just averaging the gradients may resolve neither the negative transfer nor problem. Using gradient imbalance as an example, if the gradient of one task is than the other, the larger one will dominate the average gradients.
  • GradNorm FIG.
  • 10B addresses the imbalance in gradient magnitude for multi-task l earning by using learnable combination weights ( and ) to combine the losses from each task. This indirectly controls the magnitude of the gradients.
  • the underlying rationale is to dynamically adjust the combination weights in response to the gradient magnitudes of shared layers, ensuring they neither become excessively large nor too small.
  • the process begins with the c omputation of a combined loss ( ) as a weighted sum of microarchitecture specific weights and loss, i.e., .
  • a standard backward pass generates gradients and for the respective prediction layers using . and are basically weighted gradient loss i.e., and , respectively. and are averaged for computing gradients of embedding layers.
  • FIG. 10C illustrates the design that tackles negative transfer and gradient imbalance. In QB ⁇ 95869970.1 Docket No.
  • the gradients are normalized for the embedding layers based on the magnitude of the gradients and to reduce any existing gradient magnitude imbalance.
  • a typical normalization method is adopted: compute the mean of a g radient matrix . Then, the difference of the gradient matrix with its mean (X- ) is obtained. The difference is divided by the range of the values in the gradient matrix, i.e., . This normalization was performed individually for each gradient matrix. This ensures that both gradients have the similar scale. The average of normalized gradients, i.e., is used to update the shared embedding layers.
  • Algorithm 1 Training workflow for shared embedding layers with Tao QB ⁇ 95869970.1 Docket No. 183161.00022 25 [00107] Algorithm 1 explains the workflow. First, microarchitecture specific loss and are computed. The gradient for each performance prediction layer and is calculated based on and , respectively. Then, the gradients are calculated for the linear projection layer as and . For gradient normalization, both gradients are normalized individually, and . The final gradients for the embedding layers will be the average of normalized gradients, . Finally, the gradients are updated for embedding layers and continue the backward pass. [00108] Training dataset. Tao only uses two microarchitectures based on performance variations to train the model efficiently with the desired accuracy.
  • Mahalanobis distance measures the distance between two points in a multi-dimensional space. For two vectors X and Y, Mahalanobis distance QB ⁇ 95869970.1 Docket No.
  • FIG. 11 shows an example of the overall process. First, N designs were randomly selected from the design space. Here, three designs A, B and C were selected. Detailed simulations of those designs are performed using gem5 to gather the performance metrics. The performance metric is averaged across the benchmarks. Then, the Mahalanobis distance is calculated for all designs, resulting in a 3x3 matrix. Based on Mahalanobis distance, two designs with the largest distance were selected.
  • Table 2 SPEC CPU2017 benchmarks used for training and testing. Datasets Abbr.
  • Benchmarks The SPEC CPU2017 benchmark suite was used to evaluate Tao .
  • the benchmark suite contains various benchmarks designated for “speed” or “rate” for INT and FLOAT workloads, resulting in a diverse and complex range of applications like 3D rendering, image manipulation, compression, etc. A subset of benchmarks was used from each category to train and evaluate the model.
  • the duplicate samples were removed from the and generate input features with workflow as discussed herein.
  • the resulting training dataset contains around 180 million instructions across four training benchmarks (See Table 2).
  • Table 3 Microarchitectural design space parameters choices. Components Design Range ⁇ Arch ⁇ Arch ⁇ Arch C parameters A B nt
  • Design space Table 3 shows the overall design space and microarchitecture designs used for evaluations in the paper. Various microarchitecture parameters related to the pipeline, cache and branch predictors were varied, similar to those other researchers have looked for evaluations. Nine design parameters with varying ranges were selected for a single-core superscalar CPU. For example, the ROB has a minimum size of 32 entries and a maximum size of 128 entries.
  • misses per kilo instructions were used.
  • the ⁇ microarchitecture name>- ⁇ benchmark name> ⁇ notation was used in the plots to represent the outcome of benchmark ⁇ benchmark name> on microarchitecture ⁇ microarchitecture name>.
  • Simulation throughput is measured in million instructions per second (MIPS).
  • MIPS million instructions per second
  • Tao a functional trace with 100 million instructions was generated for each test benchmark using gem5 AtomicSimpleCPU model.
  • System For training and simulation, the work was evaluated on a server with four A100 GPUs (80 GB) and an Intel(R) Xeon(R) Silver 4309Y 32-core CPU.
  • FIG. 11 compares the simulation error for the selected three microarchitectures and four test benchmarks.
  • the x-axis represents the simulation error derived from gem5, and the y-axis represents benchmarks from different microarchitectures.
  • Tao closely matches the simulation error of SimNet.
  • SimNet and Tao exhibit simulation errors of 5.11% and 5.23%, respectively.
  • the slightly higher simulation error of TAo can be attributed to prediction error for branch misprediction and cache misses.
  • Tao performs relatively better in mcf and cac benchmark.
  • the improvement in mcf can be attributed to relatively higher arithmetic instructions of mcf benchmark, in which Tao can provide better prediction with an embedding representation of instructions while SimNet uses numerical representation.
  • cac has a relatively higher number of memory stores and fewer branch instructions. SimNet incurs higher errors for memory store instructions due to limited input features relating to memory store instructions.
  • Tao demonstrates a maximum and minimum simulation error of 3.7% and 7.4%, respectively.
  • Benchmark cac has a relatively higher simulation error than other benchmarks for both SimNet and Tao , likely due to its distinctive behavior in memory access among all the QB ⁇ 95869970.1 Docket No. 183161.00022 29 benchmarks.
  • Tao maintains similar accuracy as SimNet without performance metrics across benchmarks and microarchitecture [00120] Table 4: Simulation time comparison with DL-based stimulator for 1 billion instructions.
  • SimNet Tao Speedup Training Training 54 hours 1.9 hours 28.3X [0012 . oth SimNet and Tao are trained until the error during training is under 6%. It takes 54 hours to train a CNN SimNet model. Meanwhile, with microarchitecture agnostic embeddings and transfer learning, Tao can train a model with similar accuracy in merely 1.9 hours.
  • SimNet For simulation, SimNet requires 13.22 hours to generate an input trace with 10 billion instructions. In contrast, utilizing the microarchitecture independent trace which do not simulate any microarchitecture component, the trace generation time is significantly reduced to 0.53 hours for Tao .
  • Tao along with SimNet, performs parallel simulation to provide highly scalable simulation throughput. The parallel simulation technique was followed. The program traces are partitioned into subtraces and simulated in parallel. For SimNet, it takes 1.93 hours to simulate 10 billion instructions with a simulation throughput of 1.46 MIPS. On the other hand, Tao completes the simulation in 1.41 hours with a throughput of 1.98 MIPS.
  • Tao only needs to generate a functional trace for simulation, which is 24.94 faster.
  • the functional trace is architecture agnostic, therefore trace generation from one microarchitecture to another can be avoided.
  • the input trace of SimNet requires simulation of cache, and branch along with additional simulation of pipeline. Furthermore, for each microarchitecture change, the trace needs to be regenerated.
  • the relatively slow throughput of SimNet is attributed to history context simulation involving frequent CPU- GPU data movements.
  • the simulation throughput for Tao can be further improved with various acceleration techniques like inference optimization and further scaling. Leveraging functional t race and efficient DL-based simulation workflow, the simulation process is accelerated by 7.81 .
  • FIG. 13 analyzes the ratio of instruction differences in the detailed trace compared to the functional trace used for training dataset construction.
  • FIG. 14 compares the trace generation throughput for the detailed trace and the functional trace used by Tao for simulation. On average, the trace generation throughput for detailed and functional traces is 0.21 and 5.29 MIPS, respectively.
  • the functional traces utilized by Tao exhibit a remarkable speed advantage, being generated 25.19 faster than their detailed counterparts.
  • FIG.15A-15L shows the phase level behavior for benchmarks mcf, xal, wrf and cac, respectively.
  • the CPI, L1 misses and branch misprediction were compared for each benchmark against the ground truth generated from the gem5 simulation for microarchitecture Arch A. While SimNet only captures the phase level behavior of CPI, Tao can also capture the behavior of instruction cache misses and branch mispredictions. Hence, SimNet was only compared against CPI.
  • the y-axis for L1 Dcache misses and branch mispredictions in the figure represents MPKI. Average CPI, L1 misses, and branch misprediction QB ⁇ 95869970.1 Docket No. 183161.00022 31 were predicted per ten million instructions. The x-axis shows the number of instructions in millions.
  • Tao adeptly captures the dynamic behavior of the program for each performance metric during execution.
  • CPI For CPI, Tao accurately captures performance variation across different phases of program execution.
  • Tao shows slightly better phase level prediction for cac benchmark (FIG. 15J), attributed to its enhanced accuracy in predicting latency for store instructions within the benchmark.
  • L1 Dcache misses Tao precisely captures the behavior for most of the benchmarks.
  • Tao shows slightly higher prediction error for branch MPKI than CPI and L1 Dcache MPKI. Nevertheless, it still effectively captures the trend in branch MPKI over the course of program execution.
  • Benchmark cac does not show much variation in branch MPKI due to a lower count of branch instructions (FIG. 15L).
  • FIG. 16A varies the queue size of memory accesses ( ) from 32 to 256 and evaluates average accuracy of test benchmarks for each microarchitecture design. The results indicate a general improvement in accuracy with increasing queue size for all microarchitecture configurations. However, beyond a queue size of 64, the accuracy improvements are marginal. Consequently, was selected for generating input features related to data access level.
  • Branch misprediction input FIG. 16A
  • FIG. 17 compares the test error during training of microarchitecture agnostic embedding layers for Granite, GradNorm and Tao .
  • the performance was compared with and without embedding adaptation layers ( Tao w/o embed).
  • the y-axis represents the average prediction error QB ⁇ 95869970.1 Docket No.
  • the x-axis represents the number of epochs for training. While 200 epochs, Granite and GradNorm converge with a test error of 7.5% and 7%, respectively. Granite exhibits the highest prediction error, attributed to its challenges in handling gradient imbalance and negative transfer. GradNorm, adept at balancing gradients from each microarchitecture prediction layer, achieves a lower error than Granite. However, it falls short of further error reduction due to negative transfer. Without using embedding adaptation layers, Tao demonstrates a slight improvement over Granite, achieving a test error of 7.18% with gradient normalization. But it falls short of surpassing GradNorm.
  • FIG. 18 evaluates the effectiveness of Mahalanobis distance against random selection and Euclidean distance for benchmark selection to construct microarchitecture agnostic embeddings. Simulation error over training error was used to evaluate how well the embeddings perform with transfer learning. The y-axis represents the average simulation error for the test microarchitectures and benchmarks. One to six different microarchitectures were selected randomly for random selection to construct reusable embeddings. This excludes the test Arch A, B and C. For random selection, the simulation error starts converging after five microarchitectures. The simulation error does not further decrease due to adversarial gradients from different microarchitectures.
  • the first approach scratch represents a model for unseen microarchitecture trained from scratch without any transfer learning. Training a model from scratch takes 56 and 54 hours, respectively, for Tao and SimNet.
  • the second approach direct fine-tuning, all parameters of the model are initialized from an earlier trained model. It takes 38 and 41 hours, respectively, for Tao and SimNet.
  • the model proposed by Tao shows better transfer learning speed due to separated program embeddings and prediction layers. Although fine-tuning reduces the training time, it is not significant.
  • the third approach, shared embeddings + fine-tuning, is proposed by Tao and not directly applicable to SimNet.
  • the shared embeddings constructed from microarchitecture agnostic embedding construction were used directly.
  • the prediction layers are initialized from earlier trained models and fine-tuned. 20 million instructions were used for fine-tuning the prediction layers.
  • shared embeddings + fine-tuning further reduces the training time to only 1.9 hours. The resulting speedup comes from a reduced number of epochs for training, less inference time with shared embeddings and less per epoch time due to reduced datasets.
  • Table 6 shows the preprocessing overhead of one-time microarchitecture agnostic embedding construction. Constructing the embeddings involves training dataset selection and training shared embeddings.
  • microarchitectures from the design space were randomly selected, as outlined in Table 3, which has 184,320 total possible designs.
  • 10 million instructions were simulated for all training benchmarks with gem5. It takes 0.35 hours to simulate and gather the performance metrics for each microarchitecture.
  • two microarchitectures were selected for training the embeddings based on the Mahalanobis distance among the performance metrics of 16 microarchitectures.
  • a Python script was used to compute the distance which takes only 0.1 min and select two microarchitectures with the maximum distance.
  • the microarchitecture agnostic embeddings are trained from the training dataset of the two selection microarchitectures, which takes around 71 hours.
  • Tao maintains the relative accuracy across the spectrum of branch predictors. Overall, Tao prediction aligns with the simulated results from gem5 for hardware design exploration of L1 Dcache and branch predictors.
  • Unseen benchmarks Tao can be generalized across a wide variety of unseen benchmarks. The generality of Tao across different benchmarks comes from the fact that the deep learning model is trained at the instruction level. Multiple diverse training benchmarks were used to train over a variety of instructions. That allows TAO to predict performance metrics for each instruction across different benchmarks accurately.
  • TAO is designed to simulate single-core out-of-order superscalar processors.
  • a training dataset was gathered through gem5 simulation and train the DL model with transfer learning.
  • TAO can accommodate changes in ISAs similarly to microarchitecture changes with some additional feature engineering for ISA-specific opcodes and registers.
  • Tao cannot be directly used to simulate multi-core CPU and GPU architectures.
  • the techniques proposed herein i.e., microarchitecture agnostic trace, embeddings, and multi-metric prediction, establish a framework for a rapid DL-based simulation and is transferable to other architectures.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Artificial Intelligence (AREA)
  • Mathematical Physics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Evolutionary Computation (AREA)
  • General Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Molecular Biology (AREA)
  • General Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Biophysics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Medical Informatics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Methods and systems simulating a hardware design is disclosed, A plurality of microarchitecture agnostic trace data from a hardware design are extracted, The plurality of microarchitecture agnostic data is provided to a trained deep learning model, A simulation of microarchitecture corresponding to hardware information is commenced, A plurality of similarities or relationships between instruction features of the plurality of microarchitecture agnostic trace data is processed. A plurality of instruction embeddings are generated using a plurality of embedding layers from the trained deep learning model. A plurality of performance metric predictions associated with microarchitecture agnostic trace information outputted from the trained deep learning model is obtained. Is it determined whether a microarchitecture design modeled by the trained deep learning model meets a plurality of user-defined requirements.

Description

Docket No. 183161.00022 1 ACCELERATING SIMULATION WITH MACHINE LEARNING CROSS-REFERENCE TO RELATED APPLICATION(S) [0001] This application claims priority to and incorporates by reference U.S. provisional patent application no. 63/634,302, filed April 15, 2024, the content of which is hereby incorporated by reference in its entirety. STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH [0002] This invention was made with government support under grant number 2326141 awarded by the National Science Foundation. The government has certain rights in the invention. TECHNICAL FIELD [0003] Various embodiments and implementations described herein relate generally to systems and methods for simulating and predicting performance associated with a hardware design. More specifically, embodiments and implementations hereof may involve use of microarchitecture agnostic trace data and associate performance metrics. BACKGROUND [0004] As “smart” technology proliferates throughout modern society, from IoT and edge devices to advanced AI-supporting servers, the need for high-performance processing resources that are tailored to their intended use cases and environmental/design constraints has expanded. Manufacturers of chips, ASICs, and other microarchitecture-based circuits and logic have encountered needs of their customers for an increasing breadth and variation in performance among their product offerings, as well as desires for software/hardware co-development and custom chip development for anticipated applications. [0005] Given the upfront costs in chip fabrication process deployment, computer architects and hardware engineers have relied on various software simulation platforms and chip design tools to develop, evaluate, validate, and optimize new chip and circuit designs prior to manufacturing. Such software-based simulation platforms are relied upon to assess different layouts and make some modeling or prediction about their function and behavior. It is advantageous to hardware QB\95869970.1 Docket No. 183161.00022 2 developers to attempt to predict the behavior and performance of their designs, such as via certain design metrics like cycles per instruction , cache miss rates, branch misprediction rates, and instruction latencies under various workloads. Errors or miscalculations in their predictions of performance and behavior can lead to costly redesign cycles or suboptimal hardware performance after fabrication. [0006] However, existing microarchitecture simulation approaches face substantial limitations. For example, “execution-driven” platforms may allow for simulations, but suffer from significant computational overhead, resulting in simulation speeds that are often many orders of magnitude slower than real hardware execution – this makes them an imperfect simulation as well as time- consuming and resource hungry. “Trace-driven” approaches, in contrast, may seek to reduce overhead of simulation by essentially ‘replaying’ previously-identified execution traces on different microarchitecture designs; yet, these simulations exhibit notable accuracy challenges due, in part, to differences in execution paths, instruction scheduling, and dynamic runtime behaviors across different microarchitectural configurations. Other approaches have sought to leverage leveraging machine learning techniques for simulation. However, these approaches are difficult to interpret with granularity, as they typically provide limited performance metric outputs, do not offer sufficient information for interpretability and validation, and are heavily dependent on, and influenced by, their existing microarchitecture-specific training data. Consequently, significant overhead arises from repeatedly generating detailed execution traces and retraining the simulation models each time a new microarchitecture is explored. [0007] Therefore, there exists a substantial need in the microarchitecture design and simulation domain for a more robust, flexible, and efficient solution—one capable of accurately modeling detailed low-level performance metrics while minimizing trace-generation overhead and retraining efforts. Such a solution would enable users to quickly and accurately explore new hardware designs and software solutions for given hardware resources, efficiently iterate through design variations, and ultimately reduce the time-to-market and development cost while improving confidence and reliability. [0008] While certain aspects of technologies have been discussed herein to facilitate disclosure of the invention, such discussions in no way frame these as preexisting or prior art, nor disclaim these technical aspects as being part of the contemplated embodiments. Rather, it is contemplated that embodiments of the present disclosure may encompass one or more of the technical aspects QB\95869970.1 Docket No. 183161.00022 3 discussed herein. [0009] The present disclosure may address or more of the problems and deficiencies of the approaches discussed above. However, it is contemplated that advantages of this disclosure may prove useful in addressing other problems and deficiencies in a number of technical areas. Therefore, any given claimed embodiment should not necessarily be construed as limited to addressing any of the particular problems or deficiencies discussed herein. SUMMARY [0010] The following presents a simplified summary of one or more aspects of the present disclosure, to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated features of the disclosure and is intended neither to identify key or critical elements of all aspects of the disclosure nor to delineate the scope of any or all aspects of the disclosure. Its purpose includes presenting some concepts of one or more aspects of the disclosure in a simplified form as a prelude to the more detailed description that is presented later. [0011] In some aspects, the present disclosure can provide a method for simulating a hardware design is disclosed. A plurality of microarchitecture agnostic trace data from a hardware design can be extracted. The plurality of microarchitecture agnostic data can be provided to a trained deep learning model. A simulation of microarchitecture corresponding to hardware information can be commenced. A plurality of similarities or relationships between instruction features of the plurality of microarchitecture agnostic trace data can be processed. A plurality of instruction embeddings can be generated using a plurality of embedding layers from the trained deep learning model. A plurality of performance metric predictions associated with microarchitecture agnostic trace information outputted from the trained deep learning model can be obtained. It can be determined whether a microarchitecture design modeled by the trained deep learning model meets a plurality of user-defined requirements. [0012] These and other aspects of the disclosure will become more fully understood upon a review of the drawings and the detailed description, which follows. Other aspects, features, and embodiments of the present disclosure will become apparent to those skilled in the art, upon reviewing the following description of specific, example embodiments of the present disclosure in conjunction with the accompanying figures. While features of the present disclosure may be discussed relative to certain embodiments and figures below, all embodiments of the present QB\95869970.1 Docket No. 183161.00022 4 disclosure can include one or more of the advantageous features discussed herein. In other words, while one or more embodiments may be as having certain advantageous features, one or more of such features may also be used in accordance with the various embodiments of the disclosure discussed herein. Similarly, while example embodiments may be discussed below as devices, systems, or methods embodiments it should be understood that such example embodiments can be implemented in various devices, systems, and methods. BRIEF DESCRIPTION OF THE DRAWINGS [0013] FIG.1 is a process flow diagram of an example method for predicting performance metrics of a hardware design. [0014] FIG. 2 is a process flow diagram of an example method for creating a training dataset for hardware design performance prediction. [0015] FIG. 3 is a process flow diagram of an example method for training a deep learning model to predict performance metrics of a hardware design. [0016] FIGS. 4A-4D illustrate a comparison between a mainstream simulation mechanism and a Tao microarchitecture, according to some embodiments. [0017] FIG. 5 illustrates a training dataset construction illustrated via trace snippets, according to some embodiments. [0018] FIG. 6 illustrates an example feature engineering diagram, according to some embodiments. [0019] FIG.7 illustrates an example input for branch instruction, according to some embodiments. [0020] FIG. 8 illustrates an example deep learning model architecture, according to some embodiments. [0021] FIG. 9 illustrates an overview of transfer learning, according to some embodiments. [0022] FIGS.10A-10C illustrate a comparison of multi-architecture training paradigms, according to some embodiments. [0023] FIG. 11 illustrates a process for selecting a training dataset, according to some embodiments. [0024] FIG. 12 is a chart illustrating simulation accuracy comparisons, according to some embodiments. [0025] FIG.13 is a chart illustrating instruction differences in percentages for speculative and nop QB\95869970.1 Docket No. 183161.00022 5 instructions, according to some embodiments. [0026] FIG. 14 is a chart illustrating trace throughput comparisons for detailed and function traces, according to some embodiments. [0027] FIGS. 15A-15L are plots illustrating phase behavior for test benchmarks, according to some embodiments. [0028] FIGS. 16A-16B are plots illustrating choices of context size and branch configuration, according to some embodiments. [0029] FIG. 17 is a plot illustrating a number of epochs and a test error on a log scale, according to some embodiments. [0030] FIG. 18 is a chart illustrating training dataset selection, according to some embodiments. [0031] FIGS. 19A-19B are plots illustrating hardware design space exploration of L1 Dcache misses and branch mispredictions, according to some embodiments. DETAILED DESCRIPTION [0032] The detailed description set forth below, in connection with the appended drawings and the attached appendices, is intended as a description of various configurations and is not intended to represent the only configurations in which the subject matter described herein may be practiced. The detailed description includes specific details to provide a thorough understanding of various embodiments of the present disclosure. However, it will be apparent to those skilled in the art that the various features, concepts and embodiments described herein may be implemented and practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts. [0033] As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the content clearly dictates otherwise. As used in this specification and the appended claims, the term “or” is generally employed in its sense including “and/or” unless the context clearly dictates otherwise. [0034] As described below, various embodiments may utilize or implement variations of some general methods, steps, and/or approaches. Several such methods are laid out below in relation to associated flowcharts – these methods may comprise or become part of many different embodiments contemplated herein. And, in addition to the generalized notions of these flowcharts, more specific embodiments are presented as examples in the context of certain validation QB\95869970.1 Docket No. 183161.00022 6 experiments and tools from the inventors’ work. These examples demonstrate the effectiveness of the methods provided herein, including the improvements of these approaches over prior techniques. The advantages of the below-described methods and the established improvements are not, however, limited to the specified arrangements or embodiments. [0035] For example, the teachings provided herein may be implemented in the form of a method for simulating a hardware design that is capable of determining performance metrics that can provide design improvements and recommendations for fast microarchitecture exploration. [0036] Some embodiments may be implemented as simulation tools for computer microarchitecture design and hardware engineering. Designers of hardware (e.g., chips, microcontrollers, processors, circuits-on-a-chip, etc.) may use such simulators to extensively evaluate, validate, and optimize new microarchitecture designs and components before actual manufacturing. By leveraging the advantages provided herein, the use of such simulation tools will reduce the development cycle, allow for early detection and correction of design bottlenecks, and enables rapid iteration over design variations by providing more detailed and accurate information. [0037] Embodiments may also be implemented as tools for predicting and evaluating quality and performance of existing designs under specified, real-world conditions. For example, some embodiments may allow semiconductor companies and hardware manufacturers to evaluate their existing designs and/or product offerings so as to predict real-world hardware performance under certain conditions. E.g., where a new device, board, or application is desired, a manufacturer or designer may evaluate potential existing processing/chip solutions to determine which may offer optimal performance under those conditions, helping ensure their designs will meet targeted performance and reliability metrics and optimize for cost-performance trade-offs. [0038] Other embodiments may be implemented as software development tools for purpose- driven designs. For example, where a software development team knows in advance which processing/chip resources will be available to run their code, the team can simulate their code on that exact microarchitecture and use the simulation outputs to optimize code generation, improve software performance on the anticipated hardware designs, and tune software workloads to better match hardware capabilities. Likewise, as patches, firmware/software updates, etc. are being developed, they can be modeled on the specific microarchitectures and potential inputs/environmental conditions that may be “in the field”, prior to deployment. Thus, such QB\95869970.1 Docket No. 183161.00022 7 implementations enhance software-hardware co-design, and improve reliability and confidence in the software development and re-development [0039] Other embodiments may allow for researchers in computer architecture to evaluate potential architectural innovations, explore potential new design concepts/arrangements that have not been fabricated before, and/or perform comparison studies across different architectural approaches. Because, as described below, the computational cost of methods herein is lower, while the simulation data generated is more fine-grained, far more robust and reliable platforms can be realized for research and experimentation of novel architectural ideas. Methods and Techniques [0040] FIG. 1 is a flow diagram illustrating an example process 100 for predicting performance metrics of a hardware design. As described below, a given implementation of such methods might omit some or all illustrate features/steps, may be implemented in some embodiments in a different order, and may not require some illustrated features to achieve certain advantages or improvements. It should be appreciated that various suitable hardware, sensors, and system architectures for carrying out the operations or features described below may perform process 100. [0041] At step 102, the process 100 may optionally obtain hardware design information. In some examples, the hardware design information may be a user-identification of a given processor or microarchitecture type and/or may include design requirements of a given computer processor, microcontroller, logic circuit, circuit-on-a-chip, ASIC, or the like. In other examples, the hardware design information may include a full or partial transistor-level layout, such as RTL or HDL design files reflecting low-level hardware description (e.g., .vhdl files, Verilog files, etc.). In other embodiments, the hardware design information may be more high level or conceptual, such as high level architecture configuration files or layouts according to block functions (e.g., files that specify microarchitectural parameters like pipeline widths, buffer sizes, cache sizes, branch predictors, etc. for use in simulators). For example, the hardware design information may include or correspond to a processor with varying cache size requirements, pipeline length, layout, memory allocations, etc. In other implementations, hardware design information may include descriptions of compiled or serialized deep learning models, which correspond to pre-trained models that define or will be implemented by microarchitectural configurations. In some embodiments, step 102 may QB\95869970.1 Docket No. 183161.00022 8 also include generating higher-level information from low-level hardware layouts/descriptions. [0042] At step 104, the process 100 may microarchitecture agnostic trace data, such as “functional trace” information and/or “execution trace” information, as described in various embodiments herein. . In some embodiments, step 104 may involve obtaining microarchitecture- agnostic execution trace information by simulating a benchmark program using a functional simulator, or obtaining such trace information that was previously generated through processor- agnostic, microprocessor-agnostic and/or microarchitecture-agnostic simulation of a given program, workload, application, code, function, algorithm, neural network etc. The functional trace information may include, for example, information regarding the functions, steps, or behaviors of a program, such as information about the instructions it entails relative to a processing resource (e.g., relative to a generic processing resource or process model, or a general class of processing resource types, etc.). In some embodiments, a benchmark program may be run via a functional simulator that produces execution-level traces that may comprise or reveal dynamic performance metrics and/or static properties of instructions caused by or comprising the program, such as opcodes, register usage, branch addresses, and memory addresses, without microarchitecture-specific timing information, . [0043] At step 106, the process 100 provides the microarchitecture agnostic trace data to a trained deep learning (DL) model. The trained DL model may be trained using datasets and methods described below with respect to processes 200 and 300. In some examples, the DL model may be trained to capture relationships between instructions and a given microarchitecture, processor, general class of processors, or other hardware, based on properties of the instructions, as well as performance metrics. In some examples, the DL model may be fine-tuned to a specific category of processor design (e.g., to single core, multi-core, many-core general processing designs, application/function-specific circuits, low-power edge processors, systems on a chip, etc.), whereas in other examples the DL model may be trained on a wide variety of designs. Thus, the DL model may be trained to simulate real-world behavior of given processor execution. [0044] In some embodiments, information obtained regarding a hardware or architecture of interest, such as obtained with respect to step 102 may be utilized to select and/or fine-tune a DL model that can be used for simulation. In some embodiments, a DL model has been pre-trained to represent or simulate a processor, class of processors, or microarchitecture of interest. Such preexisting models may be utilized by software developers to assess performance of applications QB\95869970.1 Docket No. 183161.00022 9 or other code that will be run on that hardware. In other cases, such preexisting models may be utilized to benchmark performance of a given resource or design against potential new or alternative designs and architectures curing co-development of software and hardware. Thus, DL models may be included in a library of available models, each associated with hardware and/or architecture information for purposes of selection for use various simulation tasks. [0045] In other embodiments, a preexisting or pretrained DL model may not be available that is suitable for a given simulation task. For example, when a simulation task will entail assessing an entirely new microarchitecture, there would not necessarily be a DL model available in a library that can be used to accurate simulate that microarchitecture under various workloads/conditions. Thus, as described below, a transfer learning approach may be utilized to adapt an existing DL model (e.g., a DL model pre-trained on a generic processing resource, a processing resource of a same/similar class, a given microarchitecture approach, etc.) to rapidly generate a suitable DL model applicable to the new microarchitecture. Thus, in these cases, the hardware information obtained at step 102 may be utilized to select a DL model that can be used as a basis for fine-tuning through transfer learning, and to train, retrain, and/or fine-tune that DL model such that it will accurately simulate a microarchitecture per the hardware information. [0046] At step 108, the process 100 commences simulation of a microarchitecture corresponding to the hardware information, such as by calling for generation of performance metrics based on the microarchitecture agnostic trace data from the DL model output. For example, microarchitecture-agnostic trace data that comprises functional trace information can be provided as input to a DL model obtained in process 106, and process 100 can obtain performance information from outputs of the DL model. In some examples, these metrics can include instruction latencies, fetch and execution cycles, branch mispredictions, and data access levels. [0047] At step 110, the process 100 may in some embodiments process similarities or relationships between instruction features of the microarchitecture agnostic trace data via the deep learning model. In some examples, the deep learning model can utilize learned representations or mappings between the instruction features and the microarchitecture data on which the DL model was trained. [0048] At step 112, the process 100 may in some embodiments utilize or leverage a plurality of embedding layers of the DL model, such as to generate a plurality of instruction embeddings based on two-level embedding layers. QB\95869970.1 Docket No. 183161.00022 10 [0049] At step 114, the process 100 obtains from outputs of the DL model predictions of a plurality of performance metrics associated with the agnostic trace information. [0050] At step 116, in some examples, these metrics may be used to determine whether the microarchitecture design modeled by the DL model meets a users’ design requirements. For example, process 100 may include making a determination that the microarchitecture design “succeeds” in achieving stated performance goals (such as latency, etc.) for a given workload, or “fails” or does not meet certain performance requirements, such as if the design were implemented outside of a simulation to perform a given processing task. Correspondingly, process 100 may also or alternatively include making a determination as to whether an application or code, when run on a microarchitecture modeled by the DL model, will cause the microarchitecture to succeed or fail on given design requirements (e.g., instruction latency, fetch/execution cycles, and/or higher-level information such as predicted power usage based on cycles and other actions).. In some examples, the metrics may be outputted on an user device, such as a laptop, a computer, a smartphone, etc. In other examples, the performance metrics may be saved or sent to a memory of one or more devices, such as saving the performance metrics and successes/failures in a database record for the associated microarchitecture design iteration or software version that is being designed and simulated. [0051] At step 118, the process 100 optionally recommends alterations to the hardware design. In some examples, the recommended alterations can include techniques which may be used to improve the metrics and performance of the design. [0052] Referring now to FIG. 2, a flow diagram is presented, illustrating an example process 200 for creating and refining a training dataset in a manner that will optimize its use for hardware design performance prediction, such as through use of a machine learning or deep learning algorithm or model that is trained on this dataset. For example, a deep learning model described above with respect to process 100 may be trained using the training set created by process 200. [0053] At step 202, the process 200 obtains a plurality of microarchitecture hardware design information for a processor, microcontroller, chip, architecture, or other processing resource of interest. In some examples, the hardware design information can include information such as the hardware design information described above with respect to step 102 of process 100. In other words, the microarchitectural designs can include specific microarchitectural layouts and/or descriptions of attributes of a given hardware resource design/architecture of interest. For QB\95869970.1 Docket No. 183161.00022 11 example, the hardware designs may include, or may be used to extract, various parameters that describe behavior of a processor and/or its such as: pipeline configuration (e.g., fetch width, reorder buffer size, etc.); cache design (e.g., hierarchy, sizes, association information, latency information, etc.); a branch prediction algorithm; a memory subsystem configuration; and/or an instruction set architecture. Furthermore, the hardware design information may also comprise information usable to obtain detailed trace information, such as timing information obtained through detailed stimulations of a hardware design. In other words, the plurality microarchitecture hardware design information may comprise architectural information of a hardware resource sufficient to enable detailed simulation of the hardware resource, as described below and in the Examples section herein. [0054] At step 204, the process 200 obtains microarchitecture agnostic trace data (or functional trace data) for a given benchmark program or other application, based on a generic hardware design. In some examples, the trace data can be obtained and include properties as described above with respect to step 104. In some examples, the static properties extracted can include opcode, register information, and instruction flags. For example, the trace data may include a stream of instructions generated by a functional or detailed stimulation. Therefore, the traces may capture various static instruction properties or dynamic performance metrics of a benchmark program, application of interest, workload, etc. In alternative embodiments, such functional trace data may have been previously obtained and stored in a database in association with various benchmark or example programs. [0055] At step 206, the process 200 may obtain microarchitecture-dependent trace information for the microarchitecture of interest. In some embodiments, process 200 may perform a simulation of the microarchitecture of interest by providing the hardware information obtained in step 202 to a detailed simulator and causing it to simulate the same benchmark program or application from which the microarchitecture agnostic trace data (or functional trace data) was obtained in step 204. [0056] At step 208, process 200 may then associate microarchitecture agnostic trace data (or functional trace data) from step 204 with microarchitecture-dependent trace information (or detailed trace data) from step 206 as a pair, based on the common benchmark program or other application that was used. For example, process 200 may align instructions from the functional trace and the detailed trace, to pair them together in an associative or aligned manner. In some embodiments, this may include removing speculative, stall-related, or other outlier instructions QB\95869970.1 Docket No. 183161.00022 12 from the detailed trace, and attributing the performance impact to the corresponding instructions in the functional trace. In some process 200 can be thought of as obtaining a plurality of performance numerals associated with each of the static properties. In some examples, the performance numerals may be determined based on differences and attributes linked to specific instructions within the functional trace. As an example, static features of instructions from the functional trace information can be combined with corresponding performance labels from the detailed trace information; thus instruction-level pairings, multi-instruction-sequence pairings, as well as application-level pairings can be obtained. [0057] Steps 204-208 may be repeated in a cycle or iterative loop, to generate more pairings of functional and detailed trace information, such as by running different programs, workloads, applications, and/or benchmarks to generate pairs. In alternative embodiments, additional pairings may alternatively or additionally be generated by varying hardware information to reflect varying architectures or processors of a class or family of resources that will be modeled by a DL model. [0058] At step 210, the process 200 creates a training dataset based on the plurality of performance numerals. This training dataset may be used to train and/or fine-tune one or more deep learning models used for predicting performance metrics. Additionally, or alternatively, the training dataset may be stored in a database in association with a record for the hardware/architecture design and hardware information. Thus, the training data may be re-used for purposes of generating more- specific/more-tailored DL models and/or for generating DL models that can predict performance for a more general class of hardware. For example, in some embodiments, the training dataset may be used in combination with process 300, as described below, to adapt a DL model through a transfer learning-based method so that it will be tailored to a different microarchitecture without incurring the time or resource expenditure of fully training a model from scratch. In other examples, the one or more deep learning models may be used for improving and evaluating other functionalities and design characteristics of various hardware designs. [0059] At step 212, process 200 trains a DL model using the training dataset. For example, the detailed trace information and performance metrics may be utilized as “ground truth” or to define the output channels of a DL model, and the associated functional trace information may be used as the “input” data. Thus, the DL model can learn representations of how software instructions (from the functional trace information) correlate to hardware-level behavior for the specific hardware design of interest, as described by the hardware information. QB\95869970.1 Docket No. 183161.00022 13 [0060] In some embodiments, the structure of the DL model may comprise a novel combination of inputs, layers, connections, and outputs. the DL model may be structured to accept microarchitecture-agnostic functional traces as inputs and output multiple performance metrics at the instruction level. Thus, such a DL model may have an input feature encoding layer that extracts features from the functional trace information/static instruction information (e.g., opcode, source/destination register information, etc.). These features may then be passed through feature- specific embedding layers. In some embodiments, these feature embeddings may be processed by the DL model in a two-level embedding fashion, such that the feature-specific embeddings are combined after being generated (e.g., concatenated as a vector). The DL model may then process a sequence of instruction embeddings via a multi-head self-attention network, which may be structured similar to a transformer network encoder. This layer comprises learned temporal and substantive relationships between instructions. This structure allows for better long-range capture of dependences than and LSTM or CNN-style architecture. Next, the DL model may comprise architecture-specific prediction and adaptation layers. Thus, the outputs of the self-attention network may be processed by individual prediction heads – each head representing an output performance metric (e.g., execution latency, data access level, etc.). The DL model itself may be trained via a multi-task loss function, such as one combining regression losses for continuous outputs and classification losses for categorical outputs. Thus, the DL model can be trained to generate both continuous-value outputs as well as generating binary/class decision outputs, with varying combinations thereof, while still retaining the internal network learnings of their relationships. [0061] Referring now to FIG. 3, a flow diagram is presented, illustrating an example process 300 for training a deep learning model to predict performance metrics of a hardware design. [0062] At step 302, the process 300 obtains a plurality of embedding layers corresponding to agnostic trace data of a hardware design. In some examples, instruction properties such as opcode, register information, data access addresses, and PC addresses associated with the hardware design can be obtained. [0063] At step 304, the process 300 generates a first microarchitecture based on prediction and adaptation layers of shared embedding layers. [0064] At step 306, the process 300 determines a first plurality of gradients based on individual embeddings of the first microarchitecture. In some examples, each gradient can include a QB\95869970.1 Docket No. 183161.00022 14 magnitude for shared layers. Furthermore, the magnitudes may be negative when gradients are from different microarchitectures that are to each other. [0065] At step 308, the process 300 generates a second microarchitecture based on prediction and adaptation layers of the plurality of embedding layers. [0066] At step 310, the process 300 determines a second plurality of gradients based on individual embeddings of the second microarchitecture. [0067] At step 312, the process 300 normalizes the first and second plurality of gradients based on magnitudes. In some examples, the normalization of the gradients can reduce magnitude imbalances and can ensure gradients from the first and second pluralities are within the same or a similar range. [0068] At step 314, the process 300 trains a deep learning model based on the plurality of embedding layers as inputs and normalized gradients as corresponding outputs. In some examples, the deep learning model used by process 100, as described above, may be pre-trained by the steps of process 300. In further examples, process 300 may be used to update the training of a pre- trained deep learning model. Example Methods and Embodiments [0069] Aspects of the present invention are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. [0070] Architecture simulations by level of details. Architecture simulators can be divided into functional and detailed simulations based on the level of detail. (i) Functional simulation. Functional simulators are designed to model the functionality of a microarchitecture rather than its detailed implementation. They primarily validate hardware functions and generate execution traces for specific workloads. They do not simulate the microarchitecture in detail, so they typically do QB\95869970.1 Docket No. 183161.00022 15 not produce timing information. However, their lack of detail allows them to operate at a speed that is one to two orders of magnitude faster a detailed simulation. (ii) Detailed simulation. Detailed simulators simulate the processor by performing all the operations from each component with cycle granularity. They model the detailed knowledge of how the processor works to capture the dynamic behavior of the microarchitecture, which impacts the performance. It provides a meticulous analysis of performance characteristics, enabling researchers to explore how different microarchitectural elements interact and impact overall performance. While detailed simulation offers higher accuracy, it comes at the cost of increased computational overhead, making it more time-consuming. [0071] Execution trace. Described herein are execution traces, which refer to the stream of instructions generated by functional or detailed simulation. The gem5 simulator is modified to generate execution traces capturing various static instruction properties and dynamic performance metrics. Functional trace refers to the microarchitecture agnostic trace generated with functional simulation using AtomicSimpleCPU model. The terms functional trace and microarchitecture agnostic trace are used interchangeably. It only contains static properties like opcode, registers, and other instruction flags. Detailed trace refers to the trace generated with the O3CPU model. It captures various microarchitecture specific performance metrics like data access misses, instruction cache misses, branch mispredictions, speculative instructions and latency of individual instructions. [0072] Deep Learning (DL) based microarchitecture simulation: In DL-based approaches, the simulated processor is abstracted as a whole, eliminating the need to simulate individual components within the processor. As DL excels at deriving the sophisticated rules that govern various complex functions, recent work shows that it can capture the microarchitecture simulations in a similar way. Previous DL-based simulations, e.g., SimNet and Ithemal manage to model the performance of a program at the instruction level, generally, in two steps: (i) An DL model is trained to capture the complex and dynamic relationships between instructions and the hardware based on the instruction properties and the performance metrics. The performance prediction problem can be defined as: (1) where is the desired output performance metric of the instruction, typically including the cycles required to execute the instruction. , .. , represent the input features used by the models. [0073] The input features include the properties of the current and earlier instructions (i.e., context QB\95869970.1 Docket No. 183161.00022 16 instruction). Context instructions are used to model the dependencies and resource contentions among the instructions. The instruction of existing DL-based simulators include static features like opcode, registers used by the instruction, branch predictions and data access level. The performance metric and input features are gathered from detailed traces by simulating various programs. is a microarchitecture specific function the model learns. (ii) During inference, this trained DL model can be used to predict the performance metrics of various unseen programs for the same microarchitecture at the instruction level. The required instruction input features are collected from dynamic profiling or simulation for a specific microarchitecture. As the processor is abstracted as a whole, any change in the microarchitecture requires re-training of the DL model with microarchitecture specific training datasets. [0074] In some embodiments, the inventors have contemplated that it may be advantagous to configure a system such that (i) the input to the DL model should only (or need only) capture the instruction execution sequence and (ii) the DL model should govern the hardware features stemming from the following considerations: First, if the input to the DL model only needs to capture the execution sequence, the DL model captures all the microarchitecture features. That is, a trained DL model can be used to predict the impactful and/or important low-level microarchitectural performance metrics (i.e., CPI, branch mispredictions, cache misses) of any benchmarks, even when only provided with an input as noted above. Second, generating the microarchitecture-agnostic instruction execution sequence of a particular benchmark is significantly faster than generating the traces with architectural information (referred to as detailed trace herein). Third, if a microarchitecture practitioner would like to change the microarchitecture of a particular hardware, the inputs to the DL model can be reused. [0075] In some embodiments, the inventors have also contemplated that it may be advantagous to configure a system such that a DL-based microarchitecture simulator can (i) report various performance metrics during the architecture simulation and (ii) support rapid explorations of different architecture configurations. First, other approaches might provide cycles as the only output metrics from the DL prediction model. This limits the application of such approaches to be used in simulators for microarchitectural bottleneck analysis. Further, learning from more metrics helps the model learn more complex program and hardware interactions, improving simulation detail and accuracy. Second, conventional efforts require re-training of the model from scratch. Simulating the whole design would incur huge costs just for the training. This discourages the QB\95869970.1 Docket No. 183161.00022 17 usability of DL-based architecture simulation. The proposed microarchitecture agnostic embedding layers is leveraged for learning and fast adaptation across different microarchitecture designs with a relatively small training dataset. [0076] Challenges. Tao faces three grand challenges: (i) For the training dataset, the microarchitecture impacts is associated with each executed instruction in the functional trace. (ii) Reporting various performance metrics demands us to derive sufficiently powerful DL models that can capture the impacts of various hardware components. (iii) Training microarchitecture-agnostic program embeddings presents difficulties because the embeddings are biased towards the architecture they are trained on. These three challenges motivate the design of Tao . [0077] Overview. Tao is a multi-modal DL architecture for microarchitecture simulation. This approach adheres to design principle #1 by proposing a workflow to construct training datasets from detailed and functional traces which attributes the differences in these two traces to performance metrics, allowing the reuse of functional traces for varying microarchitectures. For design principle #2, multi-metric predictions with feature engineering with a self-attention model to increase the simulation detail are proposed. Further proposed are techniques to train microarchitecture agnostic embedding layers that enable fast transfer learning which significantly reduces the re-training overhead of DL-based microarchitecture training and simulation. [0078] Tao uses functional trace as input to the model and the output (i.e. label) can be various performance metrics. This permits the subsequent simulation (i.e., inference) to only require functional trace as inputs, which can be rapidly generated and reused across microarchitectures. For the output, the metrics are instruction latency, branch misprediction, data cache misses, instruction cache misses, and translation lookaside buffer (TLB) misses of each instruction. Three major performance metrics are used, i.e., latency, branch misprediction, and data cache misses, to explain how the detail and function traces are processed to arrive at the training dataset. However, it is important to note that Tao can potentially support other performance metrics. [0079] Functional and detailed traces output similar sequence order, which permits us to associate each instruction of a functional trace with a detailed trace. However, the challenge is that the difference in number of instructions between detailed and functional traces is nontrivial. Table 1 shows the difference in instruction counts for detailed and functional simulations of 531.deepsjeng_r SPEC 2017 benchmark for a base ARM microarchitecture. As the table shows, for simulation with 1M and 10M as specified instruction count with gem5, the instruction counts QB\95869970.1 Docket No. 183161.00022 18 of functional and detailed trace differ in 5.2% and 4.8%, respectively. [0080] Table 1: Number of instructions in detailed vs. function trace for 531.deepsjeng_r benchmark. # Detailed vs. Functional Trace Detailed trace (O3CPU) Functional Trace [0081] ollowing two aspects. First, a detailed trace includes various performance metrics introduced earlier for individual instructions. Second, a detailed trace includes two types of additional dynamic instructions during execution that are missing in the functional trace. Specifically, the detailed trace contains incorrect speculative and stall instructions. Incorrect speculative instructions are the wrongly executed instructions squashed based on branch prediction. Stall instructions are used to stall the pipeline by inserting a no-operation (nop) instruction in the pipeline when any other instructions cannot be executed. [0082] Both types of additional instructions can be converted into numerical performance differences and attributed to specific instructions from the functional trace. Using the stall instructions from the detailed trace as an example, one can project the timing impact of these instructions to the latency of the subsequent instructions. [0083] Squashed speculative instructions. Instructions are speculatively executed following the prediction of whether a conditional branch instruction will be taken or not. If the predicted branch path is correct, speculatively executed instructions will be correct, thus the instruction streams of detailed and functional traces will be identical. When a speculative path is wrong due to branch misprediction, speculatively executed instructions should be squashed. This case leads to a distinction between functional and detailed traces. Having squashed speculative instructions in the detailed trace avoids separately modeling the total impact of a branch misprediction. [0084] The total impact of branch misprediction can be accounted for in the functional trace with the fetch timing information obtained from the detailed trace. If a branch is mispredicted, it will delay the fetch of the next correct instruction. In a detailed trace, the fetch latency of the correct QB\95869970.1 Docket No. 183161.00022 19 instruction does not include the speculation or branch resolution overhead. To include the miss prediction overhead, the squashed instruction from the detailed trace, get the difference in the fetch clock as the fetch latency, and add it to the subsequent instruction. [0085] Pipeline stalls. Stall instructions can be handled similarly to squashed speculative instructions. When no instruction can be executed in the pipeline due to dependency or resource contention, nop instructions are filled. Similar to squashed speculative instructions, the latency impact of nop instructions is removed and projected to the subsequent instruction. The fetch clock from the detailed trace is used to determine the additional fetch latency delay. [0086] FIG. 5 exemplifies that the training dataset resembles functional trace with only modifications regarding performance metrics (see red dashed line arrows). In the detailed trace, the first branch instruction (b.ls 0x455cb4) is mispredicted, and two consecutive instructions are speculatively executed until the branch is resolved. The fetch latency of the next correct instruction (subs x1, 0xff455) is 10, whereas the total overhead of branch misprediction is 18 cycles. To model the total impact in training dataset, the speculative instructions are used and assigned the fetch latency of 18 cycles instead of 10 to (subs x1, 0xff455). The fetch latency for (subs x1, 0xff455) changes from 10 to 18 cycles. With the new fetch latency, the ML model can be trained to predict the total impact of misprediction without squashed speculative instructions. Similarly, for stall instructions, the nop instruction is removed from the detailed trace, and then the fetch clock is used to derive fetch latency for the following instruction. The fetch latency for (ld x3, [ureg0]) is updated to 4 from 3. With this workflow, the total cycles remain the same for the detailed trace and adjusted trace, i.e., 25 cycles. In evaluation, the differences between detailed and function traces are observed, mainly focusing on speculative and nop instructions for various benchmarks and microarchitectures. [0087] Feature engineering. New techniques to build cross-instruction features are proposed, in addition to the per-instruction features. FIG. 6 shows the process of gathering the input features for the model. The input should be representative enough that the DL model can learn to map the interplay between the instruction features and the microarchitecture to predict various performance metrics. Four key instruction properties are extracted from the microarchitecture agnostic execution trace: the opcode, registers, data access address and PC address. Opcode and registers derive the per-instruction features. For opcode, an integer mapping is employed for each unique opcode in the dataset. Regarding registers, since the instructions can involve multiple registers, a QB\95869970.1 Docket No. 183161.00022 20 bitmap vector is created with a size equal to the total number of registers. If an instruction uses register, index in the vector will be set to 1 otherwise). Both source and destination registers are included in the bitmap vector. [0088] Cross-instruction features, crucial for predicting branch misprediction and data access level, are derived from the PC and memory addresses. The branch history is used as input to model the outcome of conditional branch instructions. This history, indicating the outcomes of prior branch instructions, is employed by existing branch predictors to predict whether the branch will be taken. For a given input feature size, storing the outcome of each branch in a separate queue will limit the number of unique branches. To address this, a hash table is employed to store the outcomes of branch instructions. Hashing effectively controls the input feature size while maintaining relevant outcomes history for each branch (exemplified in FIG. 7). [0089] FIG. 7 shows an example of retrieving the branch input feature with a sample program execution trace. A hash table with =3 buckets and =2 is constructed. The table is populated as it goes through each instruction. When a conditional branch instruction is encountered, PC address%4 bucket is retrived and used as branch input features. Subsequently, the outcome of that branch is updated to the respective bucket before the next instruction. To retrieve the branch input features for the last instruction of the program execution trace, i.e., (00A0: b.ls #5), it is first determined the hash bucket, i.e., (00A0%4 )=B . The retrieved branch input feature will be [0 , -]. The input contains the earlier outcome of the same instruction. The hash table effectively separates the outcome of other PC addresses like (00A8: b.le eax, edx, LOOP3) and (00B4: b.le rax, eax LOOP2), which may be unrelated. It is also important to note that this design also permits different branches that are hashed to the same bucket to together offer a global history for future predictions. [0090] To model the data access level, the access distance is calced, which is the difference between current memory access and the previous memory accesses, and use that as the input to the model. Data access level is used to derive the cache misses. Intuitively, if the access distance between the current and earlier memory access is smaller, current access is more likely to be in the cache. Access distance is similar to reuse or stack distance histograms in earlier analytical models but cheaper to calculate. A memory context queue is used to track the access distance of memory accesses. FIG. 6 illustrates how access distance is calculated for memory instructions. In the case of (subs x1, 0xff455), being the first memory access, the access distance is zero. The QB\95869970.1 Docket No. 183161.00022 21 address is added to the memory context queue. For the second memory access, the difference in memory address with the first instruction is 463408=4. With =4, the access distance will be [4,0,0,0]. The optimal value of , and are empirically derived based on the simulation error across test benchmarks. [0091] DL model architecture. FIG. 8 exemplifies the DL model design. The model first generates instruction embeddings from input features with two-level embedding layers and then uses multi-headed self-attention to perform multi-metric prediction. A sequence of +1 instructions is used as input to the model. Here, signifies that earlier instructions can influence the performance of the current instruction, which are the context instructions. Unlike the prior approaches that manages a context instruction queue, adding or removing context instruction based on fetch cycles, the approach relies on the self-attention layer to autonomously learn which earlier instructions significantly impact the current instruction. [0092] The embedding layers generate instruction embeddings in two steps. Initially, embeddings are created independently for each category of input. This separate generation facilitates enhanced representation learning for each category. Specifically, for opcode, a trainable lookup table based embedding layer is employed. For the remaining categories, distinct linear embedding layers are utilized. The individual instruction embedding is obtained by combining categorical embeddings through a linear layer. Note embedding layers independently generate instruction embeddings for current and context instructions. Similar to SimNet, the value of is assigned as the maximum value of reorder buffer (ROB) in a design space, in this case, 128. [0093] Following the generation of instruction embeddings, the prediction layers employ multi- head self-attention to determine the performance metrics. Considering the impact of microarchitecture, this approach allows attention layers to model the interaction between current and earlier instructions. Using self-attention obviates the need for manually tracking context instructions, enhancing efficiency. Employing multiple heads enables each head to learn unique hardware-instruction interplay. The output from each head is concatenated and passed through a linear layer. [0094] Different operators are used to predict different performance metrics based on the output of the last linear layer: (i) The fetch and execution cycles are directly predicted from the linear layer. (ii) An additional sigmoid layer is incorporated for branch prediction to predict whether the branch will be mispredicted. (iii) A softmax layer is used for the data access level, as the output QB\95869970.1 Docket No. 183161.00022 22 can be multiple categories. (iv) More performance metrics like instruction cache miss and TLB miss can be predicted through a sigmoid During training, a loss is computed from each performance metric and combined with a linear ratio in backpropagation. To obtain the total cycle of all instructions, the retire clock of instructions is used. Retire clock is computed as current clock + fetch latency + execution latency. The retire clock of the last instruction of a benchmark determines the total cycles. [0095] Intuitive explanation on supporting a set of performance metrics. Multi-metric prediction exploits the relatedness of performance metrics. With the attention model and microarchitecture agnostic input, the design allows us to output various performance metrics of interest. It can capture the relationship between each performance metric and the specific input features that impact the metric. This allows all metrics to be derived from the same hidden layers. The validity of this idea is demonstrated by accurately predicting three performance metrics. Multi-metric prediction has two benefits. First, it increases the output details of the simulation. Second, individual loss from data access level and branch prediction helps the model relate the cycle prediction with memory and branch behavior during training. [0096] FIG. 9 illustrates the fast transfer learning process to enable Tao for a new unseen microarchitecture rapidly, i.e., Arch C, employing microarchitecture agnostic embedding layers and fine-tuning. Initially, shared embedding layers are trained with two carefully selected microarchitectures, i.e., Arch A and Arch B. During training for Arch C, the parameters of shared embedding layers are frozen, i.e., the parameters are not updated during backpropagation. The parameters of prediction layers and embedding adaptation layer are fine-tuned with the training dataset for Arch C. [0097] Microarchitecture agnostic embedding design. The shared embedding layers generate embedding for each individual instruction, and microarchitecture specific prediction layers predict the performance labels. The prediction layers of each microarchitecture computes the gradients for the embedding layers separately. The combination of them is proposed to update the shared embedding layers. [0098] Such designs that combine gradients to update shared layers can face two critical issues: negative transfer and imbalance in gradient magnitude for shared layers: (i) Negative transfer occurs when the shared layers receive gradients from different microarchitecture that are opposite to each other. (ii) Imbalance in gradients magnitude arises when one microarchitecture is too QB\95869970.1 Docket No. 183161.00022 23 dominant during training, inducing gradients with relatively large magnitudes. These issues impact convergence and generalization. [0099] FIGS. 10A-10C compares the multi-architecture training paradigm with two existing projects, Granite and GradNorm. Two microarchitectures, A and B, are used to illustrate the techniques. Although GradNorm is proposed for multi-task learning, and its effectiveness for generating microarchitecture agnostic embedding layers is compared. In the figure, each prediction network predicts microarchitecture specific output labels ( and ) and losses ( and ). [00100] In Granite, FIG. 10A to derive the gradients for shared embedding layers, the gradients from the prediction layers of each are averaged (i.e., ). Just averaging the gradients may resolve neither the negative transfer nor problem. Using gradient imbalance as an example, if the gradient of one task is than the other, the larger one will dominate the average gradients. [00101] GradNorm, FIG. 10B addresses the imbalance in gradient magnitude for multi-task learning by using learnable combination weights ( and ) to combine the losses from each task. This indirectly controls the magnitude of the gradients. The underlying rationale is to dynamically adjust the combination weights in response to the gradient magnitudes of shared layers, ensuring they neither become excessively large nor too small. The process begins with the computation of a combined loss ( ) as a weighted sum of microarchitecture specific weights and loss, i.e., . Subsequently, a standard backward pass generates gradients and for the respective prediction layers using . and are basically weighted gradient loss i.e., and , respectively. and are averaged for computing gradients of embedding layers. Combination weights are updated based on L, and a learning rate . In this way, GradNorm indirectly balances the magnitude of gradients by updating the loss weight, i.e., and for various tasks. [00102] While GradNorm can effectively address gradient magnitude imbalance, it cannot adequately address negative transfer issues that arise from conflicting gradient directions. Of note, conflicting gradients may appear when the performances of two different microarchitectures are opposite for the same instruction. Modifying the magnitude of gradients may not effectively change gradient direction in joint training. Hence, it may not fully mitigate the adversarial effect of gradients. [00103] FIG. 10C illustrates the design that tackles negative transfer and gradient imbalance. In QB\95869970.1 Docket No. 183161.00022 24 contrast to GradNorm which relies on reactive approaches of projecting conflicting gradients to a different plane or finding common direction negative transfer, a proactive solution is adopted. An individual embedding adaptation layer is adopted, i.e., for Arch A, similarly for Arch B, between the embedding and performance network, see FIG. 10C. The linear layer projects the shared embedding (i.e., Green layers) into microarchitecture specific spaces (i.e., Arch prediction layers) during forward propagation. [00104] Adding this linear projection layer resolves the negative transfer issue as follows: during backpropagation, to compute the gradients for the linear projection layer, the gradients from the earlier layer are multiplied with the transpose of the weight matrix , i.e., based on the chain rule. Under most of the cases, this operation rotates the gradients in the gradient space, changing the direction of gradients. [00105] To tackle the gradient imbalance concern, the gradients are normalized for the embedding layers based on the magnitude of the gradients and to reduce any existing gradient magnitude imbalance. A typical normalization method is adopted: compute the mean of a gradient matrix . Then, the difference of the gradient matrix with its mean (X- ) is obtained. The difference is divided by the range of the values in the gradient matrix, i.e., . This normalization was performed individually for each gradient matrix. This ensures that both gradients have the similar scale. The average of normalized gradients, i.e., is used to update the shared embedding layers. [00106] Algorithm 1: Training workflow for shared embedding layers with Tao QB\95869970.1 Docket No. 183161.00022 25 [00107] Algorithm 1 explains the workflow. First, microarchitecture specific loss and are computed. The gradient for each performance prediction layer and is calculated based on and , respectively. Then, the gradients are calculated for the linear projection layer as and . For gradient normalization, both gradients are normalized individually, and . The final gradients for the embedding layers will be the average of normalized gradients, . Finally, the gradients are updated for embedding layers and continue the backward pass. [00108] Training dataset. Tao only uses two microarchitectures based on performance variations to train the model efficiently with the desired accuracy. This is significantly more efficient than training general embedding layers with random microarchitectures. To achieve the accuracy and efficiency goal, metrics are defined to measure the architectural variations and select the two architectural variations with the most difference. [00109] To measure the microarchitecture variations, four performance metrics are selected, i.e., CPI, L1 cache miss, L2 cache miss, and branch misprediction rate. Of note, since the embedding is performance embedding, the microarchitecture variation was tied to performance metrics. These four performance metrics were picked because they can capture the processor, cache, memory, and branch behaviors of a program. Combinedly, these metrics explain the performance impact of key microarchitecture components on overall performance. The choice is also evident by the earlier project, which solely uses these metrics to perform microarchitectural bottleneck analysis and hardware design space exploration. [00110] The performance metrics difference of different microarchitectures are measured with Mahalanobis distance instead of Euclidean or Cosine distance for two reasons: (i) Euclidean distance is sensitive to a larger value of one metric, and Cosine distance ignores the value difference. (ii) The other two distances do not consider the correlation among the performance metrics or their scales during distance computation. Mahalanobis distance measures the distance between two points in a multi-dimensional space. For two vectors X and Y, Mahalanobis distance QB\95869970.1 Docket No. 183161.00022 26 is defined as , where represents the inverse of the covariance matrix of The covariance matrix represents how the performance metrics Using the inverse of the covariance matrix, Mahalanobis distance normalizes the data and accounts for the correlation between dimensions. This normalization makes it less sensitive to a larger metric value. [00111] FIG. 11 shows an example of the overall process. First, N designs were randomly selected from the design space. Here, three designs A, B and C were selected. Detailed simulations of those designs are performed using gem5 to gather the performance metrics. The performance metric is averaged across the benchmarks. Then, the Mahalanobis distance is calculated for all designs, resulting in a 3x3 matrix. Based on Mahalanobis distance, two designs with the largest distance were selected. Here, as the distance between A and C is the largest among all pairs, i.e., 0.48, A and C were selected for microarchitecture agnostic embedding construction. Of note, since selecting a training dataset is one time cost, the overhead can be considered as preprocessing time. [00112] Table 2: SPEC CPU2017 benchmarks used for training and testing. Datasets Abbr. [00113] Benchmarks. The SPEC CPU2017 benchmark suite was used to evaluate Tao . The benchmark suite contains various benchmarks designated for “speed” or “rate” for INT and FLOAT workloads, resulting in a diverse and complex range of applications like 3D rendering, image manipulation, compression, etc. A subset of benchmarks was used from each category to train and evaluate the model. Instead of randomly selecting train/test benchmarks, unique representative benchmarks were selected based on the performance variations. This allows the model to be trained by diverse instructions from various benchmarks and helps generalize Tao over new benchmarks. Table 2 shows the training and testing datasets. For a fair comparison, this train/test dataset is used for all related evaluations. [00114] Training dataset. To construct the training dataset, detailed and functional traces with 100 million instructions were generated from each training benchmark with default test workloads using the gem5 O3CPU and AtomicSimpleCPU model, respectively. Of note, the first 100 million instructions are skipped to avoid the common program initialization phase. The benchmarks are QB\95869970.1 Docket No. 183161.00022 27 compiled and simulated in ARM Instruction Set Architecture (ISA). For preprocessing, the duplicate samples were removed from the and generate input features with workflow as discussed herein. After preprocessing, the resulting training dataset contains around 180 million instructions across four training benchmarks (See Table 2). [00115] Table 3: Microarchitectural design space parameters choices. Components Design Range μArch μArch μArch C parameters A B nt [00116] Design space. Table 3 shows the overall design space and microarchitecture designs used for evaluations in the paper. Various microarchitecture parameters related to the pipeline, cache and branch predictors were varied, similar to those other researchers have looked for evaluations. Nine design parameters with varying ranges were selected for a single-core superscalar CPU. For example, the ROB has a minimum size of 32 entries and a maximum size of 128 entries. For evaluating simulation accuracy and throughput, three microarchitecture designs were selected ( Arch A, Arch B and Arch C), with large variations from Table 3 to demonstrate the robustness of the approach. The microarchitecture parameters for each design are also shown in the table. Each microarchitecture is evaluated on the test benchmarks in Table 2. A separate DL model is trained for each microarchitecture design with transfer learning (see FIG. 9). QB\95869970.1 Docket No. 183161.00022 28 [00117] Simulation study criteria. The simulation error for CPI, branch prediction, and memory access levels, and throughput was evaluated. simulation error represents the absolute CPI prediction error for each benchmark and is defined as 100% . CPI is calculated by the sum predicted cycle of all instructions divided by the total count of instructions. and represents the CPI derived from Tao gem5, respectively. For evaluating cache misses and branch misprediction accuracy, misses per kilo instructions (MPKI) were used. The {<microarchitecture name>- <benchmark name>} notation was used in the plots to represent the outcome of benchmark <benchmark name> on microarchitecture <microarchitecture name>. Simulation throughput is measured in million instructions per second (MIPS). For evaluating Tao, a functional trace with 100 million instructions was generated for each test benchmark using gem5 AtomicSimpleCPU model. [00118] System. For training and simulation, the work was evaluated on a server with four A100 GPUs (80 GB) and an Intel(R) Xeon(R) Silver 4309Y 32-core CPU. GPUs were used for the DL model inference as it provides significantly higher throughput than CPUs. For comparison with the previous work, i.e., SimNet, the CNN (C3 hybrid) model was used. The same datasets were used to train SimNet and Tao . The models are trained with Pytorch 2.1.0. [00119] FIG. 11 compares the simulation error for the selected three microarchitectures and four test benchmarks. The x-axis represents the simulation error derived from gem5, and the y-axis represents benchmarks from different microarchitectures. In most microarchitectures and benchmarks, Tao closely matches the simulation error of SimNet. On average, SimNet and Tao exhibit simulation errors of 5.11% and 5.23%, respectively. The slightly higher simulation error of TAo can be attributed to prediction error for branch misprediction and cache misses. Interestingly, Tao performs relatively better in mcf and cac benchmark. The improvement in mcf can be attributed to relatively higher arithmetic instructions of mcf benchmark, in which Tao can provide better prediction with an embedding representation of instructions while SimNet uses numerical representation. cac has a relatively higher number of memory stores and fewer branch instructions. SimNet incurs higher errors for memory store instructions due to limited input features relating to memory store instructions. For the evaluated microarchitectures and benchmarks, Tao demonstrates a maximum and minimum simulation error of 3.7% and 7.4%, respectively. Benchmark cac has a relatively higher simulation error than other benchmarks for both SimNet and Tao , likely due to its distinctive behavior in memory access among all the QB\95869970.1 Docket No. 183161.00022 29 benchmarks. Notably, Tao maintains similar accuracy as SimNet without performance metrics across benchmarks and microarchitecture [00120] Table 4: Simulation time comparison with DL-based stimulator for 1 billion instructions. SimNet Tao Speedup Training Training 54 hours 1.9 hours 28.3X [0012 . oth SimNet and Tao are trained until the error during training is under 6%. It takes 54 hours to train a CNN SimNet model. Meanwhile, with microarchitecture agnostic embeddings and transfer learning, Tao can train a model with similar accuracy in merely 1.9 hours. It improves the training time by 28.52 . [00122] For simulation, SimNet requires 13.22 hours to generate an input trace with 10 billion instructions. In contrast, utilizing the microarchitecture independent trace which do not simulate any microarchitecture component, the trace generation time is significantly reduced to 0.53 hours for Tao . Tao , along with SimNet, performs parallel simulation to provide highly scalable simulation throughput. The parallel simulation technique was followed. The program traces are partitioned into subtraces and simulated in parallel. For SimNet, it takes 1.93 hours to simulate 10 billion instructions with a simulation throughput of 1.46 MIPS. On the other hand, Tao completes the simulation in 1.41 hours with a throughput of 1.98 MIPS. This speedup results from two aspects: (i) Tao only needs to generate a functional trace for simulation, which is 24.94 faster. Of note, the functional trace is architecture agnostic, therefore trace generation from one microarchitecture to another can be avoided. The input trace of SimNet requires simulation of cache, and branch along with additional simulation of pipeline. Furthermore, for each microarchitecture change, the trace needs to be regenerated. (ii) During inference, the relatively slow throughput of SimNet is attributed to history context simulation involving frequent CPU- GPU data movements. The simulation throughput for Tao can be further improved with various acceleration techniques like inference optimization and further scaling. Leveraging functional trace and efficient DL-based simulation workflow, the simulation process is accelerated by 7.81 . QB\95869970.1 Docket No. 183161.00022 30 Overall, Tao demonstrates a remarkable speed advantage for simulating a new microarchitecture, being 18.06 faster than SimNet. This is linearly scaled with the number of microarchitecture designs and benchmarks used to simulate. gem5 provides a simulation throughput of 0.198 MIPS and takes 14.01 hours to simulate 10 billion instructions. Tao provides 7.26 speedup for simulation against gem5. Even including the training time, provides a speedup of 3.66 . TAO provides further speedup when simulating more instructions or using more GPUs for simulation. [00123] FIG. 13 analyzes the ratio of instruction differences in the detailed trace compared to the functional trace used for training dataset construction. The y-axis represents the instruction ratio of each instruction type, and the x-axis represents the microarchitectures and benchmarks. For 100 million simulated instructions from each benchmark, the detailed trace has, on average 96.98% of squashed pipeline instructions and 3.02% of nop instructions. The remaining instructions remain the same for different microarchitectures. The variation in the count of speculative instructions across benchmarks comes from different branch predictors and their respective accuracy. [00124] FIG. 14 compares the trace generation throughput for the detailed trace and the functional trace used by Tao for simulation. On average, the trace generation throughput for detailed and functional traces is 0.21 and 5.29 MIPS, respectively. The functional traces utilized by Tao exhibit a remarkable speed advantage, being generated 25.19 faster than their detailed counterparts. The slower throughput of detailed traces can be attributed to the intricate modeling of various hardware components, such as memory, cache, and branch predictor. Notably, the functional trace throughput remains consistent across different microarchitectures for the same benchmarks. Arch A, characterized by a higher occurrence of branch mispredictions, exhibits an elevated number of speculative instructions. Consequently, the average trace throughput for Arch A (0.19 MIPS) is marginally lower compared to Arch B (0.21 MIPS) and Arch C (0.23 MIPS). [00125] Phase Level Behavior FIG.15A-15L shows the phase level behavior for benchmarks mcf, xal, wrf and cac, respectively. The CPI, L1 misses and branch misprediction were compared for each benchmark against the ground truth generated from the gem5 simulation for microarchitecture Arch A. While SimNet only captures the phase level behavior of CPI, Tao can also capture the behavior of instruction cache misses and branch mispredictions. Hence, SimNet was only compared against CPI. The y-axis for L1 Dcache misses and branch mispredictions in the figure represents MPKI. Average CPI, L1 misses, and branch misprediction QB\95869970.1 Docket No. 183161.00022 31 were predicted per ten million instructions. The x-axis shows the number of instructions in millions. [00126] Our evaluation reveals that Tao adeptly captures the dynamic behavior of the program for each performance metric during execution. For CPI, Tao accurately captures performance variation across different phases of program execution. Notably, Tao shows slightly better phase level prediction for cac benchmark (FIG. 15J), attributed to its enhanced accuracy in predicting latency for store instructions within the benchmark. For L1 Dcache misses, Tao precisely captures the behavior for most of the benchmarks. On average, Tao shows slightly higher prediction error for branch MPKI than CPI and L1 Dcache MPKI. Nevertheless, it still effectively captures the trend in branch MPKI over the course of program execution. Benchmark cac does not show much variation in branch MPKI due to a lower count of branch instructions (FIG. 15L). [00127] Multi-Metric Prediction Study The prediction accuracy of L1 Dcache MPKI and branch MPKI are compared with varying input features for their respective category. Prediction models were trained for each parameter on training benchmarks and compare the simulation accuracy across test benchmarks to determine the best value for the parameters. [00128] Data access level input. FIG. 16A varies the queue size of memory accesses ( ) from 32 to 256 and evaluates average accuracy of test benchmarks for each microarchitecture design. The results indicate a general improvement in accuracy with increasing queue size for all microarchitecture configurations. However, beyond a queue size of 64, the accuracy improvements are marginal. Consequently, was selected for generating input features related to data access level. [00129] Branch misprediction input. FIG. 16B investigates the influence of varying the combination of hash buckets (1k, 2k) and queue size (16,32) on the input features representing the history of branch PC address. The combination (1k,32) demonstrates favorable accuracy for predicting the branch MPKI, with no significant improvement observed by further increasing these parameters. Therefore, and was used to generate the input features specifically tailored for branch instructions. [00130] Evaluation on Transfer Learning via Microarchitecture Agnostic Embeddings: FIG. 17 compares the test error during training of microarchitecture agnostic embedding layers for Granite, GradNorm and Tao . For Tao , the performance was compared with and without embedding adaptation layers ( Tao w/o embed). The y-axis represents the average prediction error QB\95869970.1 Docket No. 183161.00022 32 from Arch A and Arch B for the test dataset during the training. The x-axis represents the number of epochs for training. While 200 epochs, Granite and GradNorm converge with a test error of 7.5% and 7%, respectively. Granite exhibits the highest prediction error, attributed to its challenges in handling gradient imbalance and negative transfer. GradNorm, adept at balancing gradients from each microarchitecture prediction layer, achieves a lower error than Granite. However, it falls short of further error reduction due to negative transfer. Without using embedding adaptation layers, Tao demonstrates a slight improvement over Granite, achieving a test error of 7.18% with gradient normalization. But it falls short of surpassing GradNorm. Notably, leveraging an embedding adaptation layer with gradient normalization, Tao reduces prediction error further to 5.5%. [00131] Training dataset. FIG. 18 evaluates the effectiveness of Mahalanobis distance against random selection and Euclidean distance for benchmark selection to construct microarchitecture agnostic embeddings. Simulation error over training error was used to evaluate how well the embeddings perform with transfer learning. The y-axis represents the average simulation error for the test microarchitectures and benchmarks. One to six different microarchitectures were selected randomly for random selection to construct reusable embeddings. This excludes the test Arch A, B and C. For random selection, the simulation error starts converging after five microarchitectures. The simulation error does not further decrease due to adversarial gradients from different microarchitectures. For Mahalanobis and Manhattan distance, the performance variations of 20 designs randomly sampled from Table 3 were calculated and two microarchitectures were selected for training. Euclidean distance based selection has slightly less simulation error of 7.5% compared with 8.5% for random selection. With Mahalanobis distance based selection, a higher accuracy of 6.34% was achieved, comapred to that of random selection of six microarchitectures. The generated embeddings are more robust because the microarchitecture selected from Mahalanobis distance has more variations. [00132] Table 5: Training time. Technique Training time QB\95869970.1 Docket No. 183161.00022 33 [00133] Transfer learning. Table 5 compares the effectiveness of transfer learning to train a DL model for an unseen microarchitecture. For Tao and SimNet, a DL model was trained until the error during training is close to 6%. [00134] Here, the first approach scratch represents a model for unseen microarchitecture trained from scratch without any transfer learning. Training a model from scratch takes 56 and 54 hours, respectively, for Tao and SimNet. In the second approach, direct fine-tuning, all parameters of the model are initialized from an earlier trained model. It takes 38 and 41 hours, respectively, for Tao and SimNet. The model proposed by Tao shows better transfer learning speed due to separated program embeddings and prediction layers. Although fine-tuning reduces the training time, it is not significant. [00135] The third approach, shared embeddings + fine-tuning, is proposed by Tao and not directly applicable to SimNet. For training a model for unseen microarchitecture, the shared embeddings constructed from microarchitecture agnostic embedding construction were used directly. The prediction layers are initialized from earlier trained models and fine-tuned. 20 million instructions were used for fine-tuning the prediction layers. shared embeddings + fine-tuning further reduces the training time to only 1.9 hours. The resulting speedup comes from a reduced number of epochs for training, less inference time with shared embeddings and less per epoch time due to reduced datasets. [00136] Table 6 shows the preprocessing overhead of one-time microarchitecture agnostic embedding construction. Constructing the embeddings involves training dataset selection and training shared embeddings. To collect the training dataset, 16 microarchitectures from the design space were randomly selected, as outlined in Table 3, which has 184,320 total possible designs. For each sampled microarchitecture, 10 million instructions were simulated for all training benchmarks with gem5. It takes 0.35 hours to simulate and gather the performance metrics for each microarchitecture. Then, two microarchitectures were selected for training the embeddings based on the Mahalanobis distance among the performance metrics of 16 microarchitectures. A Python script was used to compute the distance which takes only 0.1 min and select two microarchitectures with the maximum distance. The microarchitecture agnostic embeddings are trained from the training dataset of the two selection microarchitectures, which takes around 71 hours. [00137] Hardware Design Space Exploration varying L1 DCache size for gem5 simulation and QB\95869970.1 Docket No. 183161.00022 34 Tao . The simulated cache MPKI decreases as the cache size increases from 16KB to 128KB. Cache MPKI predicted by Tao aligns with result from gem5, demonstrating that a cache size of 128KB results in the least MPKI. [00138] In FIG.19A the average branch MPKI was used across four test benchmarks using different branch predictors for gem5 and Tao . The simulated result from gem5 indicates the highest branch MPKI for the Local and the lowest for the Tage_SC_L. Branch MPKI predicted by Tao also aligns with the simulated result from gem5. The prediction error is lower for simpler branch predictors like Local, experiencing only a marginal increase for relatively complex branch predictors like Tage_SC_L. Nonetheless, Tao maintains the relative accuracy across the spectrum of branch predictors. Overall, Tao prediction aligns with the simulated results from gem5 for hardware design exploration of L1 Dcache and branch predictors. [00139] Unseen benchmarks. Tao can be generalized across a wide variety of unseen benchmarks. The generality of Tao across different benchmarks comes from the fact that the deep learning model is trained at the instruction level. Multiple diverse training benchmarks were used to train over a variety of instructions. That allows TAO to predict performance metrics for each instruction across different benchmarks accurately. The evaluation confirms that Tao maintains a good accuracy over unseen test benchmarks. Unseen architectures. TAO is designed to simulate single-core out-of-order superscalar processors. To simulate an unseen microarchitecture, a training dataset was gathered through gem5 simulation and train the DL model with transfer learning. TAO can accommodate changes in ISAs similarly to microarchitecture changes with some additional feature engineering for ISA-specific opcodes and registers. Tao cannot be directly used to simulate multi-core CPU and GPU architectures. However, the techniques proposed herein, i.e., microarchitecture agnostic trace, embeddings, and multi-metric prediction, establish a framework for a rapid DL-based simulation and is transferable to other architectures. [00140] In the foregoing specification, implementations of the disclosure have been described with reference to specific example implementations thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of implementations of the disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense. QB\95869970.1

Claims

Docket No. 183161.00022 35 CLAIMS WHAT IS CLAIMED IS: 1. A method for simulating a hardware design, the method comprising: extracting a plurality of microarchitecture agnostic trace data from a hardware design, the plurality of microarchitecture agnostic trace data comprising functional or execution trace information; providing the plurality of microarchitecture agnostic data to a trained deep learning model; commencing a simulation of microarchitecture corresponding to hardware information; processing a plurality of similarities or relationships between instruction features of the plurality of microarchitecture agnostic trace data; generating a plurality of instruction embeddings using a plurality of embedding layers from the trained deep learning model; obtaining a plurality of performance metric predictions associated with microarchitecture agnostic trace information outputted from the trained deep learning model; and determining whether a microarchitecture design modeled by the trained deep learning model meets a plurality of user-defined requirements. 2. The method of claim 1, further comprising obtaining the hardware design. 3. The method of claim 1, further comprising recommending a plurality of alterations to the hardware design. 4. The method of claim 1, wherein the functional or execution trace data comprises a plurality of functions, steps, or behaviors of a program. 5. The method of claim 1, further comprising running a simulation a benchmark program using a functional stimulator. QB\95869970.1 Docket No. 183161.00022 36 6. The method of claim 5, wherein the simulation produces a plurality of execution- level traces comprising dynamic performance or static properties of instructions. 7. The method of claim 1, wherein the plurality of microarchitecture agnostic trace data comprises functional trace information, wherein the functional trace information is provided as an input to the trained deep learning model. 8. The method of claim 1, wherein the plurality of user-defined requirements comprises at least one of an instruction latency, a number of fetch cycles, a number of execution cycles, or a predicted power usage. 9. The method of claim 1, wherein the trained deep learning model was trained by: obtaining a plurality of microarchitecture hardware design information; obtaining microarchitecture agnostic trace data based on a generic hardware design; obtaining microarchitecture-dependent trace information for a microarchitecture of interest; associating the microarchitecture-dependent trace information as a pair based on a common benchmark program; and creating a training dataset based on a plurality of performance numerals. 10. The method of claim 1, wherein the trained deep learning model was trained by: obtaining a plurality of embedding layers of the hardware design; generating a first microarchitecture based on a prediction and a plurality of adaptation layers of shared embedding layers of the plurality of embedding layers; determining a first plurality of gradients based on individual embeddings of the first microarchitecture; generating a second microarchitecture based on the prediction and the plurality of adaptation layers; determining a second plurality of gradients based on a plurality of individuals embeddings of the second microarchitecture; QB\95869970.1 Docket No. 183161.00022 37 normalizing the first and second plurality of gradients based on a plurality of magnitudes; and training the deep learning model based on the plurality of embedding layers as inputs and normalized gradients as corresponding outputs. 11. A system for simulating a hardware design, the system comprising: a processor; and a memory in communication with the processor and having instructions stored thereon that, when executed, cause the processor to: extract a plurality of microarchitecture agnostic trace data from a hardware design, the plurality of microarchitecture agnostic trace data comprising functional or execution trace information; provide the plurality of microarchitecture agnostic data to a trained deep learning model; commence a simulation of microarchitecture corresponding to hardware information; process a plurality of similarities or relationships between instruction features of the plurality of microarchitecture agnostic trace data; generate a plurality of instruction embeddings using a plurality of embedding layers from the trained deep learning model; obtain a plurality of performance metric predictions associated with microarchitecture agnostic trace information outputted from the trained deep learning model; and determine whether a microarchitecture design modeled by the trained deep learning model meets a plurality of user-defined requirements. 12. The system of claim 11, wherein the instructions further cause the processor to obtain the hardware design. 13. The system of claim 11, wherein the instructions further cause the processor to recommend a plurality of alterations to the hardware design. QB\95869970.1 Docket No. 183161.00022 38 14. The system of claim 11, the functional or execution trace data comprises a plurality of functions, steps, or behaviors of a program. 15. The system of claim 11, wherein the instructions further cause the processor to run a simulation a benchmark program using a functional stimulator. 16. The system of claim 15, wherein the simulation produces a plurality of execution- level traces comprising dynamic performance metrics or static properties of instructions. 17. The system of claim 11, wherein the plurality of microarchitecture agnostic trace data comprises functional trace information, wherein the functional trace information is provided as an input to the trained deep learning model. 18. The system of claim 11, wherein the plurality of user-defined requirements comprises at least one of an instruction latency, a number of fetch cycles, a number of execution cycles, or a predicted power usage. 19. The system of claim 11, wherein the trained deep learning model was trained by: obtaining a plurality of microarchitecture hardware design information; obtaining microarchitecture agnostic trace data based on a generic hardware design; obtaining microarchitecture-dependent trace information for a microarchitecture of interest; associating the microarchitecture-dependent trace information as a pair based on a common benchmark program; and creating a training dataset based on a plurality of performance numerals. 20. The system of claim 11, wherein the trained deep learning model was trained by: obtaining a plurality of embedding layers of the hardware design; generating a first microarchitecture based on a prediction and a plurality of adaptation layers of shared embedding layers of the plurality of embedding layers; QB\95869970.1 Docket No. 183161.00022 39 determining a first plurality of gradients based on individual embeddings of the first microarchitecture; generating a second microarchitecture based on the prediction and the plurality of adaptation layers; determining a second plurality of gradients based on a plurality of individuals embeddings of the second microarchitecture; normalizing the first and second plurality of gradients based on a plurality of magnitudes; and training the deep learning model based on the plurality of embedding layers as inputs and normalized gradients as corresponding outputs. QB\95869970.1
PCT/US2025/024808 2024-04-15 2025-04-15 Accelerating microarchitecture simulation with machine learning Pending WO2025221815A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202463634302P 2024-04-15 2024-04-15
US63/634,302 2024-04-15

Publications (1)

Publication Number Publication Date
WO2025221815A1 true WO2025221815A1 (en) 2025-10-23

Family

ID=97404309

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2025/024808 Pending WO2025221815A1 (en) 2024-04-15 2025-04-15 Accelerating microarchitecture simulation with machine learning

Country Status (1)

Country Link
WO (1) WO2025221815A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220044119A1 (en) * 2019-01-17 2022-02-10 Visa International Service Association A deep learning model for learning program embeddings
US20220121752A1 (en) * 2020-10-16 2022-04-21 International Business Machines Corporation Identifying security vulnerabilities using modeled attribute propagation
US20220215241A1 (en) * 2021-01-05 2022-07-07 Alibaba Group Holding Limited Method and system for microarchitecture-aware program sampling

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220044119A1 (en) * 2019-01-17 2022-02-10 Visa International Service Association A deep learning model for learning program embeddings
US20220121752A1 (en) * 2020-10-16 2022-04-21 International Business Machines Corporation Identifying security vulnerabilities using modeled attribute propagation
US20220215241A1 (en) * 2021-01-05 2022-07-07 Alibaba Group Holding Limited Method and system for microarchitecture-aware program sampling

Similar Documents

Publication Publication Date Title
Bai et al. Boom-explorer: Risc-v boom microarchitecture design space exploration framework
Bera et al. Pythia: A customizable hardware prefetching framework using online reinforcement learning
Singh et al. Napel: Near-memory computing application performance prediction via ensemble learning
Eeckhout Computer architecture performance evaluation methods
US8019586B2 (en) Hole query for functional coverage analysis
Malik et al. System and architecture level characterization of big data applications on big and little core server architectures
Moshovos Memory dependence prediction
Santos et al. Sim2pim: A fast method for simulating host independent & pim agnostic designs
Lopes et al. A machine learning approach to accelerating DSE of reconfigurable accelerator systems
Pandey et al. Tao: re-thinking DL-based microarchitecture simulation
Pandey et al. Scalable deep learning-based microarchitecture simulation on gpus
Alcorta Lozano et al. Special session: Machine learning for embedded system design
Medhat et al. Managing the performance/error tradeoff of floating-point intensive applications
WO2025221815A1 (en) Accelerating microarchitecture simulation with machine learning
Jo et al. DiagSim: Systematically diagnosing simulators for healthy simulations
Marantos et al. Designing Application Analysis Tools for Cross-Device Energy Consumption Estimation
Wang et al. Improving the efficiency of functional verification based on test prioritization
Tompazi et al. Instruction-aware learning-based timing error models through significance-driven approximations
Wang et al. Multi-dimensional optimization for approximate near-threshold computing
Nelson et al. Verification of dataflow architectures in custom AI accelerators using simulationbased methods
Tompazi et al. Microarchitecture-aware timing error prediction via deep neural networks
US20260087217A1 (en) Method for determining computing hardware architectures by dynamically controlling a plurality of evaluation tools
US20240338509A1 (en) Method for determining computing hardware architectures
Sartor et al. Machine Learning-Based Processor Adaptability Targeting Energy, Performance, and Reliability
Chakravarthi et al. Application-Specific Instruction Set Processor

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25790877

Country of ref document: EP

Kind code of ref document: A1