Hardware design and multi-layer abstract intermediate language-oriented CIRCT dialect form semantic construction method
By defining CIRCT dialect grammar and building multi-layer abstract semantic models in the K framework, the problem of difficulty in constructing the formal semantics of hardware design intermediate languages in the prior art is solved, and efficient hardware design simulation environment and scalability of formal semantics is achieved.
Patent Information
- Application Number
- CN202411801077.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-09
- Publication Date
- 2025-04-29
- Estimated Expiration
- Not applicable · inactive patent
AI Technical Summary
The prior art is difficult to effectively construct the formal semantics of the multi-layer abstract intermediate language CIRCT dialect for hardware design, especially in terms of embodying multi-layer abstract design and modular, expandable, and composable formal semantics.
Using the programming language definition method provided by the K framework, the CIRCT dialect syntax is defined in the K framework, and an expanded, multi-layer abstract semantic model containing the characteristics of the hardware design field is constructed, and the CIRCT dialect is represented as simulated and executed operational semantics with clear symbolic representations.
It realizes a hardware design simulation environment for CIRCT dialect, improves the scalability and modular features of formal semantics, and can effectively capture the features in multi-layer abstract design, meeting the complex needs of modern hardware design.
Smart Images

Figure CN119902748A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer programming language technology and formal methods, and in particular to a CIRCT dialect formal semantics construction method for hardware design and multi-layer abstract intermediate language. Background Art
[0002] Existing formal semantics construction methods: For general executable programming languages (such as C, Java, etc.), the main method is to build the corresponding memory model and then build its operational semantics based on the model. For hardware design languages such as Verilog, it is necessary to model the hardware design domain characteristics separately, and then express its formal semantics as operational semantics that can be simulated and have clear symbolic representation. For CIRCT dialect, a hardware description intermediate language that covers multiple layers of abstraction, there are no other formal semantics construction technologies and cases.
[0003] The defects of the existing methods are:
[0004] Currently, most of the construction methods and cases of formal semantics are oriented towards executable programming languages. The hardware design intermediate language (CIRCT dialect) contains a large number of hardware design domain features, which are difficult to cover with general formal semantic definition methods oriented towards programming languages.
[0005] Traditional formal semantic definition methods for hardware description languages (such as Verilog) cannot reflect multi-layer abstract design. As hardware design gradually develops to higher levels of abstraction using high-level programming languages, they cannot keep up with the formal verification requirements for multi-level hardware design abstraction.
[0006] The modern hardware design compiler framework CIRCT implements various domain feature representations through dialects, and dialects can be combined and transformed with each other. This requires that its formal semantics are also modular, extensible, and combinable. Existing formal semantics definition methods often only target a specific language that will not change and cannot meet the needs. Summary of the invention
[0007] The present invention aims at the deficiencies of the formal semantics construction technology of the existing multi-layer abstract intermediate language (CIRCT dialect) for hardware design, and proposes a CIRCT dialect formal semantics construction method for hardware design and multi-layer abstract intermediate language. The CIRCT dialect syntax is defined in the K framework using the programming language definition method provided by the K framework, and an extensible, multi-layer abstract semantic model containing the characteristics of the hardware design field is constructed. On this basis, the CIRCT dialect is represented as an operational semantics that can be simulated and executed with clear symbolic representation.
[0008] The present invention discloses a CIRCT dialect formal semantic construction method for hardware design and multi-layer abstract intermediate language, comprising:
[0009] S1. Model the general form of the MLIR language used by the CIRCT dialect and construct its BNF grammar;
[0010] S2. Define the general form of the MLIR grammar used by the CIRCT dialect in the K framework, convert the BNF grammar obtained in S1 into the grammar type definition in the K framework, and add the type definition built into the K framework to obtain the CIRCT dialect formal semantic type system;
[0011] S3. Based on the CIRCT dialect formal semantic type system obtained in S2, a hierarchical CIRCT dialect semantic model is constructed, which is divided into an MLIR layer for processing metadata information such as symbol tables, a CIRCT layer for processing hardware design domain features, and a dialect layer for processing operation statements under each dialect;
[0012] S4. Based on the hierarchical CIRCT dialect semantic model obtained in S3, refine it, build an MLIR layer semantic model according to the MLIR metadata information used by CIRCT, and define it as a configuration in the K framework;
[0013] S5. Based on the MLIR-level semantic model obtained in S4, construct the MLIR-level formal semantics, which is defined as the rewriting rules in the K framework;
[0014] S6. Based on the hierarchical CIRCT dialect semantic model obtained in S3, refine it, build a CIRCT layer semantic model according to the hardware design domain characteristics covered in CIRCT, and define it as the configuration in the K framework;
[0015] S7. Based on the CIRCT-level semantic model obtained in S6, construct the CIRCT-level formal semantics, which is defined as the rewriting rules in K;
[0016] S8. Based on the hierarchical CIRCT dialect semantic model obtained in S3, refine it, build a dialect-level semantic model according to the characteristics of each CIRCT dialect, and define it as the configuration in K;
[0017] S9. Based on the dialect-level semantic model obtained in S8, the formal semantics of the operation statements in each dialect are constructed, and the informal description in the CIRCT document is converted into the rewriting rules in K;
[0018] S10. Integrate and compile the semantic model and formal semantics obtained in S3-S9 to obtain a hardware design simulation environment for the CIRCT dialect;
[0019] S11. Based on the hardware design simulation environment obtained in S10, a data set is constructed to test the correctness of the semantics and obtain test results;
[0020] S12. Based on the hardware design simulation environment obtained in S10, a data set is constructed to test the integrity of the semantics and obtain test results;
[0021] S13. Check the test results in S11 and S12. If both pass, it means that the CIRCT dialect formal semantics is constructed correctly. Otherwise, start checking from S3 and correct the semantics to obtain the CIRCT dialect formal semantics.
[0022] As a further improvement, in step S1 of the present invention, in the process of constructing the BNF grammar, the BNF grammar rules are fully followed to avoid using the writing method in EBNF.
[0023] As a further improvement, the conversion of the BNF grammar obtained in S1 into the grammatical type definition in the K framework described in the present invention is specifically as follows: the terminal symbols in the BNF grammar obtained in S1 should be redefined in K rather than expanded on the basis of the existing terminal symbol types in K, that is, avoiding the use of the existing terminal symbol types in K.
[0024] As a further improvement, the construction of a hierarchical CIRCT dialect semantic model described in the present invention specifically adopts a programming language framework K to perform formal semantic modeling, uses configuration items in the K framework to define state quantities and semantic models, uses rewrite rules in the K framework to define operational semantics, and, driven by the rewrite engine of the K framework, simulates the hardware design described by CIRCT.
[0025] As a further improvement, in the layered CIRCT dialect semantic model in step S3 of the present invention, there is a refinement relationship between each layer and the upper layer, the upper layer should not be dependent on the lower layer, and the lower layer is based on the upper layer. The formal semantics in steps S4 and S5 should only involve the MLIR layer semantic model.
[0026] As a further improvement, the formal semantics in steps S6 and S7 of the present invention should only involve the MLIR layer and the CIRCT layer in the semantic model.
[0027] As a further improvement, in step S8 of the present invention, based on the characteristics of each CIRCT dialect, the formal semantics of different dialects in the dialect-level semantic model should be relatively isolated, not affect each other, and have no dependencies, that is, the corresponding rewriting rules should not operate the semantic model states in other dialect spaces.
[0028] As a further improvement, the data set in step S11 of the present invention includes various possible forms of operation statements, and the MLIR code input in the test sample should be in a universal syntax form and can be compiled normally through the CIRCT tool chain to generate the target Verilog code.
[0029] As a further improvement, the data set in step S11 of the present invention ensures that each rewrite rule defined in K is covered, and the stimulus in the test sample should be multi-clock.
[0030] As a further improvement, the CIRCT dialect formal semantics described in the present invention includes:
[0031] K framework, a formal programming language framework, is used to formally model the CIRCT dialect;
[0032] The semantic model and semantic rules of the CIRCT dialect include a multi-level semantic model and operational semantics for the model;
[0033] The MLIR language general form parser is implemented in the K framework and is used to parse the CIRCT dialect and generate a syntax tree.
[0034] The CIRCT hardware design simulation environment is completed in the K framework and is used to simulate the CIRCT hardware design at the semantic level. It can receive stimulus input from multiple clocks and output the clock status of each hardware module.
[0035] CIRCT hardware design semantic simulation execution result analyzer is used to analyze simulation execution results and generate VCD files.
[0036] The beneficial effects of the present invention are as follows:
[0037] 1) Use the K framework as the implementation basis of the formal semantics of the CIRCT dialect. The configuration items in the K framework can easily define semantic models and state quantities; the rewriting rules in the K framework can easily define operational semantics based on state quantities; the matching logic in the K framework is parallel, which can be well adapted to the concurrent simulation of various circuit instances in hardware design; the K framework allows the definition of rich types and rules, which can be used to add debugging information or control the execution process; at the same time, the K framework provides a python interface, which can simplify the batch testing process and provide encapsulation for the simulation of formal semantics and the interaction with external interfaces; the K framework provides a built-in theorem prover, which can be directly used in subsequent formal verification work based on formal semantics, enhancing the usability and application potential of formal semantics.
[0038] 2) A hierarchical semantic model is designed for the CIRCT dialect, which can capture the features of different abstract levels in the CIRCT dialect. There is a refinement relationship between the layers, which makes the construction of dialect formal semantics independent of the consideration of upper-level abstract features and transformed into operational semantics of model states, thereby simplifying the factors that need to be considered in the process of dialect formal semantics construction, providing a clear route for the construction of dialect formal semantics, and improving the scalability of dialect formal semantics.
[0039] 3) Designing an MLIR layer metadata model in the semantic model to capture the inherent features of the MLIR syntax structure can free the hardware design abstraction and dialect semantics implementation based on it from dependence on MLIR features, making the MLIR information transparent to subsequent refined layer models.
[0040] 4) Design a CIRCT layer semantic model in the semantic model to reflect the characteristics of the hardware design domain. It can provide infrastructure for the operation statements related to the hardware design domain characteristics in the CIRCT dialect, abstract the hardware design domain characteristics in the dialect upward, reduce the dependency and coupling between dialects, make the implementation of dialect semantics relatively independent, and increase the scalability of dialect semantics.
[0041] 5) Design a dialect-level semantic model in the semantic model to implement the formal semantics of dialect operation statements as the operational semantics for the semantic model, in which only the model operation interface exposed by the upper-level model is accessed, so that there is no coupling and dependency between dialects, which increases the composability between dialects and the modular characteristics of dialects.
[0042] 6) The use of two-way simulation comparison for testing can not only effectively verify the correctness and completeness of the dialect formal semantics, but also detect problems in the CIRCT tool chain.
[0043] 7) Using the K framework as the implementation basis of the formal semantics of the CIRCT dialect, the operation information provided by the K framework can be obtained in the experimental evaluation, which is convenient for locating errors and repairing them. BRIEF DESCRIPTION OF THE DRAWINGS
[0044] Figure 1 It is a complete operation flow chart of the present invention;
[0045] Figure 2 It is a schematic diagram of the device of the present invention;
[0046] Figure 3 is the hierarchical semantic model in the present invention;
[0047] Figure 4 The flowchart of the semantics test in the present invention is shown in FIG. DETAILED DESCRIPTION
[0048] The present invention discloses a CIRCT dialect formal semantic construction method for hardware design and multi-layer abstract intermediate language. The following is an introduction to the basic concepts:
[0049] CIRCT:
[0050] CIRCT (Circuit IR Compilers and Tools) is an open source project built on the LLVM and MLIR frameworks, focusing on the development of digital hardware design tool chains. The goal of CIRCT is to provide a flexible and efficient compilation and optimization framework for hardware design and verification, allowing hardware developers to better describe, optimize, and generate digital circuits.
[0051] The core idea of CIRCT is to use the MLIR (Multi-Level Intermediate Representation) framework to provide flexible programming and optimization capabilities for hardware design by building multiple levels of intermediate representations (IR). CIRCT uses these intermediate representations to describe hardware circuits and generate efficient low-level code or hardware description languages (HDL) such as Verilog or VHDL for them.
[0052] Traditional hardware description languages (such as Verilog and VHDL), although widely used, have limitations in terms of expressiveness, scalability, and optimization capabilities. As the complexity of hardware design gradually increases, hardware developers need more powerful tools for efficient hardware generation, optimization, and verification. CIRCT was born to fill this gap and aims to provide a modern tool chain for more complex and modular hardware development.
[0053] CIRCT is built on MLIR, which is used to represent and optimize multiple abstraction layers from high-level hardware design to low-level implementation. MLIR itself is a general intermediate representation framework, originally proposed by LLVM developers, to solve scalability and multi-level optimization problems in the compiler ecosystem. CIRCT uses the power of MLIR to provide a similar software compiler tool chain for hardware design.
[0054] Dialects in CIRCT are basic modules that define operations and types for specific hardware domains. Each dialect represents a specific hardware design domain feature or hardware description language. For example, there are dialects specifically used to support high-level hardware generation languages (such as FIRRTL in Chisel), and there are dialects for low-level circuit descriptions (such as gate-level circuits). Through these dialects, CIRCT can handle a variety of hardware designs from high-level abstraction to low-level implementation. The core dialects in CIRCT include comb, hw, seq, and sv.
[0055] Introduction to the basic concepts of CIRCT:
[0056] MLIR is the foundation of the CIRCT project. It defines a series of basic elements, including operations, types, attributes, domains, etc., and uses dialects to implement feature abstraction in specific fields.
[0057] MLIR syntax is divided into general form and non-general form. The structure of operations in the general form is more unified, while the non-general form is more concise.
[0058] Operation is the basic unit in MLIR. An operation consists of an operation name, operands, attributes, domains, and return results. The operation name is the unique identifier of the operation, and the operands have type constraints.
[0059] Attributes are constants attached to operations, in the form of dictionary key-value pairs, to provide information to the compiler at compile time. For some operations, attributes are optional, while for some operations, some specific attributes are required.
[0060] A region is a collection of blocks, and a block is a collection of operations. Regions are used to represent hierarchical structures in operations, such as the execution body of a control statement, the loop body of a loop statement, and the function body of a function.
[0061] A dialect is essentially a set of custom types and operations. For example, the tensor dialect defines the tensor type (tensor) and the corresponding operations (such as matrix multiplication, matrix transposition, etc.), and the builtin dialect defines the basic module concepts and basic types (such as floating point numbers, arrays, etc.).
[0062] CIRCT consists of various hardware description related dialects, including sv (for
[0063] SystemVerilog), Firrtl (an intermediate language for RTL design), etc.
[0064] There are 4 core dialects in CIRCT, and other dialects can be converted into these 4 dialects, including:
[0065] hw dialect: used to describe basic concepts in hardware design, such as modules, instances, constant signals, etc.
[0066] comb dialect: used to describe combinational logic, such as basic gate circuits
[0067] sv dialect: used to describe SystemVerilog related concepts, such as process blocks, registers, etc.
[0068] seq dialect: used to describe sequential logic related structures, such as clocks, storage, etc. CIRCT hardware design example (general form):
[0069]
[0070] The compiled Verilog code is:
[0071]
[0072] It represents a timer that increases its output value by 1 on each rising edge of the clock.
[0073] K-Frame:
[0074] The K Framework is a general programming language definition framework based on mathematical semantics, which is mainly used to formally define the syntax and semantics of programming languages. The core goal of the K Framework is to provide a unified tool for developing, verifying, and executing different programming languages. By using the K Framework, you can define the formal semantics for any programming language and automatically generate parsers, interpreters, model checking tools, test frameworks, formal verification tools, etc.
[0075] The core idea of the K framework is based on rewrite logic. In the K framework, the semantics of a programming language is defined as a set of rewrite rules that describe how the program state changes according to the semantics of the language. These rules can be used to interpret the execution of the language and to verify the correctness of the program.
[0076] The K framework can be directly used to define and implement new programming languages. By formally defining syntax and semantics, developers can quickly generate interpreters, compilers, and debugging tools. Many existing programming languages (such as C, Java, JavaScript, Solidity, etc.) have been formally defined through the K framework, which enables developers to formally verify programs in existing languages to ensure the correctness of the programs in specific environments. The K framework can also be used to verify the correctness of the compiler to ensure that the code generated by the compiler is consistent with the semantics of the source code.
[0077] The definition of grammatical units in K is as follows:
[0078] K provides the syntax statement for defining grammatical units, which is written similarly to the BNF grammar, as shown below
[0079] On the left side of the ::= symbol is the name of the grammatical unit
[0080] On the right side of the ::= symbol is the specific definition of the grammar
[0081] syntax Boolean::="true"|"false"
[0082] The way to define the semantic model in K is:
[0083] Decompose the semantic model into several state variables
[0084] Use the configuration items provided in K to represent each state quantity, and then combine them according to their structural relationships in the semantic model
[0085] Set the initial value of the configuration item according to its type, including the default value and whether it is external input
[0086] In K, configuration items are defined through configuration statements. Configuration items are presented in the format of XML cells. The following example defines a configuration item foo, whose type is Map and whose initial value is an empty Map.
[0087] configuration <foo> .Map< / foo>
[0088] The way formal semantics is defined in K is:
[0089] ·Convert the semantics of a statement into its impact on the semantic model and express it as a rule formula with a signed convention
[0090] Determine the pre- and post-conditions required for semantics and express the corresponding symbolic constraints
[0091] ·Convert the semantically corresponding rule formula and pre- and post-conditions into rewriting rules in K
[0092] In K, rewrite rules are defined through rule statements. The rewrite rule in the following example defines the semantics of adding two integers. => indicates the rewrite symbol, +Int indicates integer addition, and the + on the left side indicates the addition of integers.
[0093] Indicates a plus sign
[0094] rule X:Int+Y:Int=>X+Int Y
[0095] k cell in K:
[0096] k cell is a special configuration item in K, generally used to store the sequence to be calculated
[0097] The sequence to be calculated is separated by ~>, and each element can be any grammatical type defined in K
[0098] In k cell, ... is often used to indicate the part that is not of interest, such as <k> X=>Y...< / k>
[0099] Rewrite the first item of the calculated sequence to Y (if the first item happens to be X), and keep the subsequent sequence as it is
[0100] The technical solution of the present invention will be further described below through specific embodiments in conjunction with the accompanying drawings. Figure 1 The complete operation flow chart of the present invention is as follows:
[0101] First, we obtain the MLIR general formal syntax from the MLIR official document and convert it into the corresponding BNF grammar. Then, we define the MLIR syntax type in the K framework according to the BNF grammar, which together with the built-in type definition in the K framework constitutes the type system required for the formal semantics of the CIRCT dialect. Then, based on this type system, we design a hierarchical semantic model of the CIRCT dialect, which is divided into three layers: the MLIR layer, the CIRCT layer, and the dialect layer. We implement the semantic rules required by each layer in turn to obtain the formal semantics of the CIRCT dialect, and use the tools provided by the K framework to obtain the CIRCT hardware design simulation environment. Finally, we use the CIRCT hardware design simulation environment to test the correctness and completeness of the formal semantics. If the test passes, the formal semantics is constructed. Otherwise, the semantics is adjusted according to the debugging information provided by the K framework during the simulation.
[0102] MLIR Syntax
[0103] For step S1, "model the general form of the MLIR language used by the CIRCT dialect and construct its BNF grammar", the general form of the MLIR language used by the CIRCT dialect should be obtained from the MLIR official document or manual, and then the corresponding BNF grammar should be constructed according to its description, as shown in the following figure:
[0104]
[0105] For step S2, "define the general form of the MLIR grammar used by the CIRCT dialect in the K framework, convert the BNF grammar obtained in S1 into the grammar type definition in the K framework, and add the type definition built into the K framework to obtain the CIRCT dialect formal semantic type system", the grammar type definition in the K framework should be defined using the syntax statement in the K framework.
[0106] Taking the TopLevel syntax type as an example, it is composed of several operations, type-alias-def, or attr-alias-def combinations. Therefore, we first define a sub-syntax type TopLevelElement as a type selected from these three, and then make toplevel its sequence. The List usage is a special writing method provided in K, which means a sequence separated by a specific delimiter.
[0107] syntax TopLevelElement::=Operation|TypeAliasDef|AttrAlia sDef syntaxTopLevel::=List{TopLevelElement,""}
[0108] Then define the AttrAliasDef syntax type as shown below, wrap the terminal symbol in double quotes "", and then continue to define its substructure, and so on, until there are no other undefined syntax types in the syntax type definition.
[0109] syntax AttrAliasDef::=AttrAlias"="AttrValue
[0110] The same is true for the Operation and TypeAliasDef syntax types until the definitions of all syntax types are completed.
[0111] Hierarchical semantic model
[0112] Figure 3is the hierarchical semantic model in the present invention; for step S3, "on the basis of the CIRCT dialect formal semantic type system obtained in S2, a hierarchical CIRCT dialect semantic model is constructed, which is divided into an MLIR layer for processing metadata information such as symbol tables, a CIRCT layer for processing hardware design domain features, and a dialect layer for processing operation statements under various dialects", the hierarchical semantic model structure is as follows Figure 3 As shown, it is divided into three layers: MLIR layer, CIRCT layer, and dialect layer. Each layer contains state quantities, operation primitives for state quantities, and related semantics.
[0113] MLIR layer semantics
[0114] For step S4, "Based on the layered CIRCT dialect semantic model obtained in S3, refine it, build an MLIR layer semantic model according to the MLIR metadata information used by CIRCT, and define it as a configuration in the K framework", the MLIR layer semantic model state quantity includes:
[0115] CIRCT hardware design input (MLIR source code)
[0116] Metadata information (such as location information, etc.)
[0117] Symbol table (mapping of identifiers to hardware modules)
[0118] Corresponding to the configuration items in K
[0119] <mlir>
[0120] <prog> $PGM:TopLevel< / prog>
[0121] <metas> .Map< / metas>
[0122] <syms> .Map< / syms>
[0123] < / mlir>
[0124] Regarding step S5, "on the basis of the MLIR layer semantic model obtained in S4, constructing MLIR layer formal semantics, defined as rewriting rules in the K framework", the MLIR layer formal semantics includes:
[0125] Process CIRCT hardware design input
[0126] Identify symbol information in operation statements and build a symbol table
[0127] Processing MLIR metadata
[0128] Taking the processing of CIRCT hardware input as an example, first standardize each operation statement
[0129] rule <prog>Op:Operation T:TopLevel=>stdizeOp(Op)~>T< / pro g>
[0130] Build symbol information in recognition operation statements and build symbol table
[0131]
[0132] After the CIRCT hardware design input is semantically processed by the MLIR layer, the state of the symbol table state quantity syms should be as follows, indicating the mapping of each symbol to the operation statement:
[0133]
[0134] CIRCT layer semantics
[0135] Regarding the step S6, "Based on the layered CIRCT dialect semantic model obtained in S3, refine it, build a CIRCT layer semantic model according to the hardware design domain characteristics covered in CIRCT, and define it as the configuration in the K framework", the state quantity of the CIRCT layer semantic model includes:
[0136] Stimulus Input for Simulation
[0137] Hardware module information
[0138] –Module name
[0139] –Input signal, output signal
[0140] – Module structure (relationships between nodes)
[0141] – Process Block
[0142] Circuit Status
[0143] – Hardware instance identifier
[0144] –Module definition corresponding to the instance
[0145] –Current node status of the instance
[0146] – Instance storage structure state (registers, memory)
[0147] Analog signal calculator (k cell)
[0148] Simulation control signal
[0149] The corresponding configuration items in K are:
[0150]
[0151]
[0152] The hardware design domain features handled by the CIRCT layer include:
[0153] Combinational logic
[0154] –Variables in MLIR code do not have storage properties, but circuit nodes. Therefore, nets state quantities are used in module information to represent the connection between nodes. The specific implementation of this connection is the operation statement
[0155] – The operation statements in the MLIR code are order-independent. Given the characteristics of the hardware description intermediate language, the order does not affect the circuit structure described by the code
[0156] – Special signal values in the circuit, X and Z, represent uncertain value and high impedance state respectively, these two signal values will also participate in the calculation
[0157] Sequential logic
[0158] – The process block includes the initial block and the alwasy block (specifically defined in the sv dialect). Corresponding support needs to be implemented in the CIRCT layer, such as clock signal events (signal rising and falling edge judgment)
[0159] – Concurrent execution between process blocks
[0160] –Storage structures such as registers and corresponding operation primitives
[0161] – Clock signal control statements
[0162] Regarding the step S7, "on the basis of the CIRCT layer semantic model obtained in S6, constructing CIRCT layer formal semantics, defined as rewriting rules in K", the CIRCT layer formal semantics includes:
[0163] Circuit structure construction
[0164] Circuit state initialization (execute initial process block)
[0165] Circuit simulation (execute always block based on stimulus input)
[0166] Clock control (for synchronization between circuit instances)
[0167] Taking the circuit structure construction as an example, the following rewrite rule updates the signal source of each node to the nets state of the corresponding module. The sim-ctl state indicates that the current semantic execution stage is circuit construction (build)
[0168]
[0169] Taking the circuit state initialization as an example, the following rewrite rule executes the corresponding initial process block for each instance. The sim-ctl state quantity indicates that the current semantic execution stage is initialization.
[0170]
[0171] Taking circuit simulation as an example, the following rewrite rule calculates the current value of each node and sets the value to the states state quantity of the corresponding instance. The sim-ctl state quantity indicates that the current semantic state is simulation (execute the always process block)
[0172]
[0173] Other semantics are defined in a similar way.
[0174] Core dialect semantics
[0175] Regarding the step S8, "Based on the layered CIRCT dialect semantic model obtained in S3, it is refined, and according to the characteristics of each CIRCT dialect, a dialect layer semantic model is constructed and defined as the configuration in K", there are 4 core dialects in CIRCT, and other dialects can be converted into these 4 dialects.
[0176] comb dialect, which means combinational logic, including a series of logic gates, such as AND gates, OR gates, and NOT gates
[0177] hw dialect, which defines basic concepts in hardware design, such as hardware modules, hardware instances, and signal constants.
[0178] sv dialect, which defines a series of SystemVerilog-related concepts, such as initial blocks and
[0179] always block, registers and related operations
[0180] The seq dialect defines a series of types and structures related to sequential logic, such as the clock class
[0181] Type, as well as circuit structures such as firreg and firmem
[0182] Regarding step S9, "on the basis of the dialect-level semantic model obtained in S8, construct the formal semantics of the operation statements in each dialect, and convert the informal description in the CIRCT document into the rewriting rules in K", wherein:
[0183] For the semantics of the operation statements in the comb dialect, take the comb.and statement as an example. The following rewrite rule first calculates the value of each operand and then performs a bit-level logical AND operation on them.
[0184]
[0185] For the semantics in the hw dialect, taking hw.instance as an example, the following rewrite rule creates a new hardware instance (generating a new inst sub-state in the circuits state), and the sim-ctl state indicates that the current semantic state should be the circuit construction stage (build)
[0186]
[0187]
[0188] Taking hw.constant as an example, the following rewrite rule sets the value of the node to a constant value, indicating a constant signal, and the sim-ctl state quantity indicates that the current semantic state should be the circuit construction stage (build)
[0189]
[0190] For the sv dialect, taking sv.always as an example, the following rewrite rule adds an always process block to the module during the circuit construction phase
[0191]
[0192] The following rewrite rule checks the clock signal rising and falling edge events during the simulation phase and triggers the always process block based on the results.
[0193]
[0194]
[0195] For the seq dialect, taking seq.firreg as an example, the following rewrite rule checks the clock signal rising and falling edge events during the simulation phase and updates the corresponding register value based on the result (if the rst signal is set, the register value will be reset)
[0196]
[0197] The semantics of other operation statements are similar.
[0198] Simulation environment construction
[0199] Regarding the step S10 of "integrating and compiling the semantic model and formal semantics obtained in S3-S9 to obtain a hardware design simulation environment for the CIRCT dialect", the part of compiling the formal semantics needs to be built through the kompile tool provided by the K framework:
[0200] kompile*.k
[0201] After compilation, a semantic simulation execution environment will be obtained, which is a CIRCT dialect form semantic simulation environment.
[0202] Test suite construction
[0203] Regarding the step S11 of "building a data set based on the hardware design simulation environment obtained in S10, testing the correctness of semantics, and obtaining test results", wherein:
[0204] For the correctness of semantics, construct a test case for each operation statement. Take comb.icmp as an example to build the minimum hardware module that can reflect all its semantics. Since the predicate attribute affects the comparison method, such as 0 for equality and 1 for inequality, and the attribute needs to be provided as a constant and cannot be set in the stimulus signal input, a test case needs to be set for each predicate. The following is the CIRCT design input (MLIR code) corresponding to the predicate being 0:
[0205]
[0206] The corresponding stimulus signal and expected output use case are shown below. Here, the json format is used for easy parsing.
[0207]
[0208] When testing multiple clocks, you need to set the input and expected output for each clock. Multiple input and output test cases can be expressed in the format of a JSON list, such as
[0209]
[0210]
[0211] Regarding "on the basis of the hardware design simulation environment obtained in S10, constructing a data set, testing the integrity of semantics, and obtaining a test result" described in S12, wherein:
[0212] For semantic completeness, you can select a real-world hardware design case using Chisel, compile it into MLIR code, specify the top module, set the stimulus input for each clock, perform simulation, and convert the simulation results into a vcd file. Use a simulator to simulate the Verilog code generated by the hardware design project, and then compare the obtained vcd file with the vcd file obtained by the simulation.
[0213] Regarding the step S13, "check the test results in S11 and S12. If both are passed, it means that the CIRCT dialect formal semantics is constructed correctly. Otherwise, check from S3 and correct the semantics to obtain the CIRCT dialect formal semantics", wherein:
[0214] If the simulation can be successfully completed and the results are consistent with the actual simulation, it means that the constructed formal semantics is sufficient to cope with the real project and is complete enough. The corresponding flow chart is shown in Figure 4. Figure 4 This is a flowchart for testing semantics in the present invention. For a Chisel hardware design project, the same CIRCT tool chain is used to compile the code into two versions, MLIR code and Verilog code. Then, the two versions of the compiled products are simulated and tested separately: the MLIR code is simulated based on formal semantics in the simulation environment provided by the K framework, and the Verilog code is simulated based on open source simulation tools (such as Verilator). Then, the results of the two simulations are converted into VCD files for comparison.
[0215] The above description of the embodiments is to facilitate the understanding and application of the present invention by those skilled in the art. It is obvious that those skilled in the art can easily make various modifications to the above embodiments and apply the general principles described herein to other embodiments without creative work. Therefore, the present invention is not limited to the above embodiments. Improvements and modifications made by those skilled in the art to the present invention based on the disclosure of the present invention should be within the protection scope of the present invention.< / prog>
Claims
1. A CIRCT dialect formal semantic construction method for hardware design and multi-layer abstract intermediate language, characterized in that: include: S1. Model the general form of the MLIR language used by the CIRCT dialect and construct its BNF grammar; S2. Define the general form of the MLIR grammar used by the CIRCT dialect in the K framework, convert the BNF grammar obtained in S1 into the grammar type definition in the K framework, and add the type definition built into the K framework to obtain the CIRCT dialect formal semantic type system; S3. Based on the CIRCT dialect formal semantic type system obtained in S2, a hierarchical The CIRCT dialect semantic model is divided into the MLIR layer that processes metadata information such as symbol tables, the CIRCT layer that processes hardware design domain features, and the dialect layer that processes operation statements under each dialect; S4. Based on the hierarchical CIRCT dialect semantic model obtained in S3, refine it, build an MLIR layer semantic model according to the MLIR metadata information used by CIRCT, and define it as a configuration in the K framework; S5. Based on the MLIR-level semantic model obtained in S4, construct MLIR-level formal semantics, which is defined as rewriting rules in the K framework; S6. Based on the hierarchical CIRCT dialect semantic model obtained in S3, refine it, build a CIRCT layer semantic model according to the hardware design domain characteristics covered in CIRCT, and define it as the configuration in the K framework; S7. Based on the CIRCT-level semantic model obtained in S6, construct the CIRCT-level formal semantics, which is defined as the rewriting rules in K; S8. Based on the hierarchical CIRCT dialect semantic model obtained in S3, refine it, build a dialect-level semantic model according to the characteristics of each CIRCT dialect, and define it as the configuration in K; S9. Based on the dialect-level semantic model obtained in S8, the formal semantics of the operation statements in each dialect are constructed, and the informal description in the CIRCT document is converted into the rewriting rules in K; S10. Integrate and compile the semantic model and formal semantics obtained in S3-S9 to obtain Hardware design simulation environment for CIRCT dialect; S11. Based on the hardware design simulation environment obtained in S10, a data set is constructed to test the correctness of the semantics and obtain test results; S12. Based on the hardware design simulation environment obtained in S10, a data set is constructed to test the integrity of the semantics and obtain test results; S13. Check the test results in S11 and S12. If both pass, it means that the CIRCT dialect formal semantics is constructed correctly. Otherwise, start checking from S3 and correct the semantics to obtain the CIRCT dialect formal semantics.
2. The CIRCT dialect formal semantic construction method according to claim 1, characterized in that: In the step S1, during the process of constructing the BNF grammar, the BNF grammar rules are fully followed and the writing method in EBNF is avoided.
3. The CIRCT dialect formal semantic construction method according to claim 1, characterized in that: The conversion of the BNF grammar obtained in S1 into the grammatical type definition in the K framework is specifically as follows: the terminal symbols in the BNF grammar obtained in S1 should be redefined in K rather than expanded on the basis of the existing terminal symbol types in K, that is, avoiding the use of the existing terminal symbol types in K.
4. The CIRCT dialect form semantic construction method according to claim 1, 2 or 3, characterized in that: The construction of the hierarchical CIRCT dialect semantic model specifically adopts the programming language framework K to perform formal semantic modeling, uses the configuration items in the K framework to define state quantities and semantic models, uses the rewriting rules in the K framework to define operational semantics, and drives the rewriting engine of the K framework to simulate the hardware design described by CIRCT.
5. The CIRCT dialect formal semantic construction method according to claim 4, characterized in that: In the layered CIRCT dialect semantic model in step S3, there is a refinement relationship between each layer and the upper layer, the upper layer should not be dependent on the lower layer, and the lower layer is based on the upper layer. The formal semantics in steps S4 and S5 should only involve the MLIR layer semantic model.
6. The CIRCT dialect formal semantic construction method according to claim 5, characterized in that: The formal semantics in steps S6 and S7 should only involve the MLIR layer and the CIRCT layer in the semantic model.
7. The CIRCT dialect form semantic construction method according to claim 1, 2, 3, 5 or 6, characterized in that: In step S8, according to the characteristics of each CIRCT dialect, the formal semantics of different dialects in the dialect layer semantic model should be relatively isolated, not affect each other, and have no dependencies, that is, the corresponding rewriting rules should not operate the semantic model state in other dialect spaces.
8. The CIRCT dialect form semantic construction method according to claim 7, characterized in that: The data set in step S11 contains various possible forms of operation statements. The MLIR code input in the test sample should be in a universal syntax form and can be compiled normally through the CIRCT tool chain to generate target Verilog code.
9. The CIRCT dialect form semantic construction method according to claim 8, characterized in that: The data set in step S11 ensures that each rewrite rule defined in K is covered, and the stimulus in the test sample should be multi-clock.
10. The CIRCT dialect form semantic construction method according to claim 1 or 2 or 3 or 5 or 6 or 8 or 9, characterized in that: The CIRCT dialect formal semantics include: K framework, a formal programming language framework, is used to formally model the CIRCT dialect; The semantic model and semantic rules of the CIRCT dialect include a multi-level semantic model and operational semantics for the model; The MLIR language general form parser is implemented in the K framework and is used to parse the CIRCT dialect and generate a syntax tree. The CIRCT hardware design simulation environment is completed in the K framework and is used to simulate the CIRCT hardware design at the semantic level. It can receive stimulus input from multiple clocks and output the clock status of each hardware module. CIRCT hardware design semantic simulation execution result analyzer is used to analyze simulation execution results and generate VCD files.
Citation Information
Patent Citations
Formal verification method and device for Java software
CN115357492A
SELinux security policy formalized verification method based on KFramework
CN115357945A