Register and memory operation code unified generation method

Abstract

The application belongs to the chip verification test field and relates to a register and memory operation code unified generation method, which comprises design input specification and output specification, a structured flow table is defined according to the input specification and the output specification, the structured flow table is taken as input, legality checking is carried out, and is abstracted as an atomized operation sequence, an intermediate representation layer is constructed, merging and elimination are implemented, an optimized operation sequence is obtained, and the operation sequence is mapped into a C language and a SystemVerilog language which can be compiled and simulated. The application breaks through the limitations of the prior art in system-level complex scene modeling, cross-language consistent code generation, COSIM simulation environment adaptation and multi-protocol flexible expansion and the like, and provides a systematic, efficient and brand-new solution for the automation of chip verification and software test development processes.

Description

TECHNICAL FIELD

[0001] The present application relates to a register and memory operation code unified generation method, belonging to the technical field of integrated circuit design and verification and software prototype development and test. BACKGROUND

[0002] With the continuous improvement of the integration and complexity of integrated circuit design, the number of register and memory units in system on chip (SoC) increases significantly. The initialization and configuration of registers and memories have become a basic task in chip verification, software prototype development and system test process. In the application scenarios of hardware self-test, chip power-on initialization, system scenario-level verification and test, efficient and accurate access to registers and memories is an important basis for ensuring chip function and performance.

[0003] Chip development process usually includes front-end design and verification, hardware acceleration simulation and software test development, etc. Each link has certain commonality in register and memory operation requirements, but there are diversities in protocol support, environment support and operation process, etc. The system-level verification method represented by software and hardware co-simulation (Co-Simulation / OSIM) requires that the verification use case can achieve consistency and reusability between C and SystemVerilog (SV) language environments. With the expansion of chip size and the increase of application scenarios, the complexity of register and memory operation process increases, and manual development and maintenance face the problems of low efficiency and error-prone.

[0004] The common practice in the industry is for development and verification personnel to manually write register and memory operation codes based on register description documents, programmer's guide (Program Guide) and other documents. This method is limited in efficiency, and lacks consistency between different technology stacks, increasing the cost of repetitive labor and maintenance. Changes in chip design require synchronous modification of multiple sets of codes, which is prone to inconsistencies and errors. Existing automatic tools can only generate static register files or implement simple read-write scan test processes, and are difficult to meet complex development needs.

[0005] Therefore, the chip design and verification process has new demands for a register and memory operation method that can support complex system-level scenarios, multiple protocols, multiple languages and automatic consistency generation. Such a method can improve the collaboration efficiency of development, verification and software teams, standardize the operation process, reduce the difficulty of maintenance and improve the overall quality of the project.

[0006] Currently, the automation of register and memory operation in the chip design and verification process has certain technical accumulation. Related technologies mainly focus on the automatic generation of register description files, the generation of static register model scripts, and the automatic implementation of basic read-write operation scan tests. The related patent documents are analyzed as follows:

[0007] The patent document with publication number CN106484415A provides a method for automatically generating register module and its supporting bus port RTL code based on tabular register description document. The application scenario of this invention is limited to the RTL implementation of front-end design, and fails to involve the generation requirements of sequence code in system-level verification or software testing.

[0008] The patent document with publication number CN107436762A proposes a register-related code file generation method based on text format register description file. This method is limited to extracting information from independent text to generate design code, register model, and read-write scan test sequence, and cannot meet the needs of building dynamic and complex system-level verification scenarios.

[0009] The patent document with publication number CN115758973A discloses a method for automatically generating chip register design-related files from a single source. Its core contribution lies in register-level RTL design code, generation of multiple format description documents, and generation of basic read-write scan stimuli, but it fails to provide effective technical solutions for how to automatically build system-level, scenario-based complex configuration processes and how to support cross-protocol, multi-language collaborative generation.

[0010] The patent document with publication number CN112905450B discloses a chip register automatic development system based on template variable replacement. This system also focuses on the automatic creation of register files and register models, but lacks the ability to model system behavior and create complex operation sequence logic, making it impossible to automatically generate high-level system-level configuration and test code.

[0011] Overall, existing automation solutions mostly focus on register RTL design and document output, and stop at register modeling and register scan verification automation for verification needs, lacking technical solutions for complex scenario system-level verification and test sequence automation, making it difficult to meet the needs of modern chip complex scenario verification, COSIM simulation, hardware acceleration platform simulation, and software rapid linkage testing.

[0012] Problems and shortcomings of existing technologies:

[0013] 1. The automation code generation technology is limited to RTL code, register model code, and simple register read-write scan test code, and cannot support the configuration process required by complex system-level scenarios.

[0014] 2. Multi-language (C / SystemVerilog) code collaborative support is insufficient, and cross-platform driving / verification linkage cases are difficult to unify.

[0015] 3. The ability to automatically generate code for complex memory operations and multi-protocol interfaces is limited, making it difficult to efficiently scale to more complex data paths and advanced scenarios.

[0016] Based on this, the present invention is proposed. Summary of the Invention

[0017] This invention provides a unified method for generating register and memory operation codes, the specific technical solution of which is as follows:

[0018] I. Formation process of the present invention

[0019] The technical problem to be solved by this invention:

[0020] This invention addresses the practical need for automated system-level register and memory operations during chip design, verification, and software testing and development, proposing a technical solution for complex scenarios. The core technical problems to be solved include:

[0021] 1) Complex configuration processes in system-level scenarios are difficult to model and express in a unified way.

[0022] 2) Low level of automation, large workload of manual development and maintenance, and easy to introduce errors.

[0023] 3) Operational use cases across multiple teams, tools, and platforms are difficult to reuse and collaborate on.

[0024] 4) Insufficient adaptability to multiple protocols, multiple data types, and the COSIM simulation environment.

[0025] 5) Insufficient process standardization and engineering traceability.

[0026] The core innovations and technical protection points of this invention mainly include:

[0027] 1. Standardized input and modeling mechanism for system-level register and memory operation procedures:

[0028] This invention proposes a standardized input format for chip verification and software testing needs, used to describe system-level register and memory operation flows. The input format can not only express complex flow control (such as conditions, loops, delays, etc.), but also be flexibly extended to adapt to multi-protocol and multi-data type scenarios, significantly improving the coordination and consistency of different development stages and the standardization of processes.

[0029] 2. Highly versatile dual-language interface and access adaptation architecture:

[0030] The application provides a layered interface architecture which can cross multiple target implementation languages. The architecture makes the interface code be able to flexibly connect multiple register description models, instruction set specifications, protocol standards and compiling environments through layered abstraction, parameterized configuration and macro mechanism. The framework is not limited to specific implementation languages, can support multiple front-end design delivery formats, different types of register or memory modeling requirements, and provides a basis for subsequent customization expansion and platform adaptation.

[0031] 3. Semantic analysis based on standardized input and target code generation engine:

[0032] The application first performs semantic analysis on the structured input, constructs an intermediate representation (atomized operation sequence) which is irrelevant to specific target output languages, implements optimization splicing (including merging of 'write-after-read' of adjacent write bit fields, elimination of redundant writing, and constraint by barrier protection) at the intermediate representation layer, so as to reduce the number of bus access times and ensure timing equivalence, and finally maps to the code products of C language and SystemVerilog language.

[0033] The register and memory operation code unified generation method comprises the following steps:

[0034] Step 1, semantic analysis

[0035] Design input specification and output specification, define a structured flow table according to the input specification and the output specification, take the structured input of register / memory operation as a unified entrance, take the structured flow table as input, parse the content in the input structured flow table according to the definition in the input specification and perform legality check;

[0036] Step 2, intermediate representation construction

[0037] Abstract the register / memory operation which has passed the legality check into an atomized operation sequence, and construct an intermediate representation layer;

[0038] Step 3, optimization splicing

[0039] Merge and eliminate at the constructed intermediate representation layer to obtain an optimized operation sequence;

[0040] Step 4, target mapping

[0041] Map the optimized operation sequence to the compilable and simulative products of C language and SystemVerilog language;

[0042] Step 5, interface alignment

[0043] Standardize the interface form, parameter style and calling specification, all output codes adopt unified function interface and calling mode, and the output codes are standardized and unified;

[0044] Step 6, output code

[0045] Two types of code products are generated, which can be directly integrated in the simulation environment.

[0046] Further improvement, the semantic analysis of the parsing mechanism includes:

[0047] Default inheritance, the field is not explicitly filled in automatically inherited from the last line of the effective value;

[0048] Multi-numeric representation support, unified hexadecimal / decimal / binary and other different numeric representation;

[0049] Constraints and conflict checking, automatic detection of control flow pairing, bit width range, protocol legality and same field conflict.

[0050] Further improvement, the atomic operation sequence includes write whole word, write bit field, read, polling, block read and write, delay and control flow node.

[0051] Further improvement, the merging method of the optimized splicing includes:

[0052] The multiple write bit field operations acting on the same register are combined into a read-after-write sequence without barrier conditions, and the read-after-write sequence includes reading the register whole word, setting the new value of multiple bit fields in sequence, and writing back the register once.

[0053] Further improvement, the elimination method of the optimized splicing includes:

[0054] If the same bit field is written multiple times with the same value in the read-independent interval, the previous one is automatically removed.

[0055] Further improvement, in the process of interface standardization and unification, C-end standardized interface design is carried out, including:

[0056] The automatically generated C header file and source file are encapsulated by macro or static inline function;

[0057] The C-end standardized interface adopts a layered architecture, and the architecture of the C-end standardized interface includes a user interface layer of the C-end, a general implementation layer of the C-end, and a bottom layer implementation layer of the C-end.

[0058] Further improvement, in the process of interface standardization and unification, SystemVerilog-end standardized interface design is carried out, including:

[0059] The SystemVerilog-end standardized interface adopts a parameterized macro and task method, adapts to the UVM verification environment, and the SystemVerilog-end standardized interface adopts a layered architecture;

[0060] The architecture of the SystemVerilog end standardized interface includes a user interface layer of the SystemVerilog end, a general implementation layer of the SystemVerilog end and a bottom implementation layer of the SystemVerilog end.

[0061] Further improvement, two types of code products are C language code and SystemVerilog code, the C language code is directed to the compilable code / library of the C language stack, follows the hierarchical interface framework, automatically adapts the register / memory description of project delivery, and can be directly used for initialization and function calling of COSIM simulation and hardware acceleration;The SystemVerilog task is directed to the simulatable code / library of the SystemVerilog language stack, is consistent with the C language in interface semantics and calling sequence, can be directly integrated and called in the standardized simulation environment, supports front door / back door access and multi-protocol excitation.

[0062] The beneficial effects of the application are as follows:

[0063] 1、Reduce development and maintenance costs: by structurally defining the register and memory operation flow, and automatically generating the corresponding code by using the code generation engine, the manual writing and debugging workload is significantly reduced, the error rate and maintenance cost are reduced, and the development efficiency is improved.

[0064] 2、Improve multi-end consistency and use case reuse: through unified generation of multiple languages and general hierarchical interface design, the consistency of operation sequence in software driving and hardware verification environment is ensured, and the portability and reuse ability of test cases under different platforms such as COSIM simulation, hardware acceleration and the like are enhanced.

[0065] 3、Enhance team collaborative development efficiency: design, verification and software testing teams communicate and cooperate based on unified structured flow documents, avoid obstacles caused by relying on complex code for review and problem positioning, and greatly improve the cross-team collaborative development efficiency.

[0066] 4、Improve delivery quality and verification coverage: the flow generation mechanism based on the atomic operation model effectively avoids omissions in the manual configuration process, improves the test coverage depth and project delivery quality.

[0067] In summary, the application breaks through the limitations of the prior art in system-level complex scene modeling, cross-language consistency code generation, COSIM simulation environment adaptation and multi-protocol flexible expansion, and provides a systematic and efficient new solution for the automation of chip verification and software test development process. BRIEF DESCRIPTION OF DRAWINGS

[0068] Figure 1 The architecture for the implementation of the C end standardized interface code.

[0069] Figure 2 Implementation architecture for SystemVerilog end standardization interface code;

[0070] Figure 3 Automated script flowchart. DETAILED DESCRIPTION

[0071] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is further described in detail below in combination with the drawings and examples. It should be understood that the specific examples described herein are only used to explain the present application and do not limit the present application.

[0072] Abbreviations and key terms definition

[0073] AHB (Advanced High-performance Bus): bus interface protocol, one of AMBA protocols, used for on-chip communication.

[0074] APB (Advanced Peripheral Bus): bus interface protocol, one of AMBA protocols, suitable for low-bandwidth peripherals.

[0075] AXI (Advanced eXtensible Interface): bus interface protocol, one of AMBA protocols, widely used high-bandwidth, low-latency on-chip bus interface.

[0076] CHI (Coherent Hub Interface): bus interface protocol, one of AMBA protocols, high-level cache coherence interconnection bus protocol, used to support high-performance multi-core SoC.

[0077] COSIM (Co-Simulation): software and hardware co-simulation method, realizing joint verification of CPU software and hardware model.

[0078] CPU (Central Processing Unit): central processing unit, core computing component of chip system.

[0079] EDA (Electronic Design Automation): electronic design automation, supporting chip design, simulation, verification and other automated tools and processes.

[0080] FPGA (Field Programmable Gate Array): field programmable gate array, commonly used for chip prototype testing and acceleration simulation platform.

[0081] Magillem: A company that provides EDA software solutions and its flagship product. Its tool suite focuses on IP reuse and SoC integration automation based on the IP-XACT standard.

[0082] RTL (Register Transfer Level): A hardware level used to describe and simulate digital logic.

[0083] SoC (System-on-Chip): A system-level chip that integrates processors, storage, interfaces, and other functions into a single chip.

[0084] SystemVerilog (SV): A high-level hardware description language that supports hardware modeling and verification.

[0085] UVM (Universal Verification Methodology): A functional verification framework based on SystemVerilog.

[0086] UVM sequence: A type of transaction sequence object in UVM, used to define and drive a series of bus or register access operations in the verification platform. UVM sequence supports randomization and constraints, can be reused and combined into complex test scenarios, and is the main means of stimulus generation in the verification environment.

[0087] UVM RAL (Register Abstraction Layer): A register abstraction layer in the UVM verification methodology, providing a unified register access model.

[0088] Front-end design (Front-end Design): In the chip development process, it refers to the stage from functional definition, architecture design to completion of RTL coding. The core product of this stage is RTL code.

[0089] Front-end verification (Front-end Verification): In the chip development process, it refers to the stage of simulating and formally verifying the correctness of the design function, timing integrity, protocol compatibility, etc. by writing and executing verification cases based on RTL implementation. Front-end verification usually uses SystemVerilog, UVM and other methodologies to ensure that the chip design meets the design goals and avoids potential risks before it is taped out.

[0090] Hardware acceleration platform (Hardware Acceleration Platform): A hardware simulation device used for verification and software testing development, such as an emulator or FPGA prototype verification platform.

[0091] Embodiment 1

[0092] The present application provides a register and memory operation code unified generation method, especially a register and memory operation code unified generation method for chip verification and software test development. The core of the present application is an automatic code generation process based on a structured input format driving:

[0093] The structured input of system-level register / memory operation is taken as a unified entrance to complete "structured input→semantic analysis→intermediate representation (atomic operation sequence) construction→optimization splicing→target mapping (C / SystemVerilog)→interface alignment→output code", so as to realize one-time input and consistent output of two languages.

[0094] To support the stable operation and scalability of the core process, the present application proposes and designs the following two support layers:

[0095] Input / output specification: define the data items, control semantics (conditions / cycles / delays / barriers, etc.) of the input and the organization method of the output products, so as to ensure that the input can be stably parsed and the output can be reused by engineering;

[0096] Multi-language interface and access adaptation (two languages, C / SystemVerilog language in this example): realize decoupling and adaptation with different register / memory descriptions, different bus / access paradigms and different language stacks, so as to ensure seamless access to the engineering environment after target mapping.

[0097] The following is a detailed technical implementation.

[0098] 1. Input / output specification

[0099] 1.1. Input specification:

[0100] In the scheme of the present application, the design and verification team can jointly maintain one or more structured operation flow tables according to the requirements of chip system-level initialization, software and hardware co-simulation, functional testing, etc., which are referred to as structured flow tables. The structured flow table adopts standardized fields, supports reading and writing of registers and memories, field access, polling, delay, conditional branching, loop, etc. and can be extended to adapt to the needs of different protocol interfaces.

[0101] These structured flow tables not only serve as direct input for automatic code generation, but also can be used as part of the programmer's manual, so as to realize consistent understanding and cooperation of the design, verification and software development teams on the register configuration sequence and reduce the risks caused by manual operation flow fragmentation. Table 1 is a simple example of a structured flow table (wherein the operation types in English are all listed with specific meanings in Table 2).

[0102] The present application atomizes, classifies and abstractly models register and memory access operations. All basic operation types supported by the structured flow table are listed in Table 2.

[0103] Table 1 structured flow representation example

[0104] Operation Type System Level Base Address Register Name Prefix Register Name Field Name Operation Value or Variable Comment WRITE_REG <address value> <prefix name> <register name> / <Operand Value> Integer Register Write Operation POLLING_REG_FIELD <address value> <Prefix Name> <register name> <field name> <polling value> Register Field Polling Operation MEMORY_WRITE <address value> / / / <Operation Variables> Memory Write Operation for Predefined Operation Variable DELAY / / / / <delay value> Delay Operation IF / / / / <Branch on condition> Conditional Branch Operation WRITE_REG_FIELD <address value> <prefix name> <register name> <field name> <Operand Value> Register Field Write Operation ENDIF / / / / / End of Conditional Branch Flag

[0105] Table 2 structured flow table supported basic operation list

[0106] Operation Name Function Description WRITE_REG Write Integer Register READ_REG Read Integer Register WRITE_REG_FIELD Write Register Specific Field READ_REG_FIELD Read Register Specific Field POLLING_REG Poll Integer Register POLLING_REG_FIELD Poll Register Field DELAY Delay Specify Period MEMORY_WRITE Block Write Memory MEMORY_READ Block Read Memory IF / ELSE / ENDIF Flow Control Conditional LOOP / ENDLOOP Flow Control Loop

[0107] 1.2, output specification:

[0108] The automatic code generation mechanism takes the structured flow table as input and generates two types of code products that can be directly integrated in the simulation environment:

[0109] 1.2.1, C language code: C language stack-oriented compilable code / library, following the layered interface framework of the present application, automatically adapting the register / memory description of the project delivery, which can be directly used for initialization and function calling in COSIM simulation, hardware acceleration and other scenarios.

[0110] 1.2.2, SystemVerilog code: SystemVerilog language stack-oriented simulation code / library, consistent with C language in interface semantics and calling order, which can be directly integrated and called in the standardized simulation environment, supporting front door / back door access and multi-protocol stimulation.

[0111] The present application ensures that the programs generated on both C and SystemVerilog ends are completely consistent in parameter definition and operation flow. Users can flexibly choose different language versions of code combinations for integration according to specific verification or testing needs, or perform multi-end comparison simulation and consistency verification for the same register / memory operation sequence. This significantly improves the efficiency and consistency of software and hardware co-verification.

[0112] 2, dual-language interface and access adaptation

[0113] Interface standardization and unification

[0114] To ensure that the automatically generated C language and SystemVerilog code can be efficiently integrated into actual engineering projects, the interface form, parameter style and calling specification are strictly standardized. All output codes use uniform parameter order and calling method, whether in COSIM simulation, hardware test C environment or RTL simulation SystemVerilog verification platform, fast integration can be achieved, significantly reducing the complexity of manual interfacing and debugging.

[0115] 2.1, C-end standardized interface design, as shown in Figure 1

[0116] 1) Both the automatically generated C header file and the source file are encapsulated by macros or static inline functions to ensure type safety and efficient data transmission. For example, the output code of the register operation is as follows:

[0117] WRITE_REG(0x40001000, CTRL, 0x1);

[0118] wherein 0x40001000 is a hexadecimal address value, CRTL is a register name, and 0x1 is a hexadecimal write operation value. This code generation format allows the code generation mechanism to not need to concern about the underlying implementation details.

[0119] 2) The C-end standardized interface adopts a layered architecture, including a C-end user interface layer, a C-end general implementation layer, and a C-end underlying implementation layer:

[0120] ① The C-end user interface layer: provides fixed and unified function interfaces to ensure the consistency of the upper layer code; Figure 1 The WRITE_REG, READ_REG, MEMORY_WRITE, and MEMORY_READ shown in the user interface block diagram of the C-end are directly callable interface functions. These functions form a one-to-one correspondence with all the operations listed in the basic operation list supported by the structured flow table in Table 2.

[0121] ② The C-end general implementation layer: through parameterized configuration, it adapts to the register description header file based on macros or structures, supports the output format (header file based on macros or header file based on structures) of different EDA tools or self-developed tools; Figure 1 ​REG_STRUCT, REG_FIELD_STRUCT, WRITE_REG_32, WRITE_REG_64, SET_REG_FIELD, READ_REG_32, READ_REG_64, GET_REG_FIELD, write_loop(), read_loop(), nop_loop(), REG_ADDR, REG_FIELD_SHIFT, REG_FIELD_MASK, WRITE_32_BIT, READ_32_BIT, WRITE_64_BIT, READ_64_BIT, WRITE_128_BIT, READ_128_BIT, etc. shown in the general implementation block diagram of the present application are all for the purpose of realizing the intermediate layer function logic of interfacing the standardized user interface to the underlying implementation and delivering the standardized header file of EDA. The intermediate connection code structure is shown in the figure through strict classification and layering, realizing the decoupling of the underlying implementation and the user interface, laying the foundation for the flexible implementation of the underlying code in the next step.

[0122] ③, the underlying implementation layer of the C end: according to the actual demand for specific CPU architecture or compiler, a small amount of code can be flexibly adjusted to adapt the basic implementation, improve the applicability and portability of the code. Figure 1 volatile_write() and volatile_read() in the underlying implementation block diagram in the present application are the function names of the underlying implementation. They can be flexibly modified and adapted for different CPU architectures and compilers without affecting the user interface and the top-level working mode of the whole application.

[0123] Figure 1 the front-end design delivers the standardized header file: refers to the header file delivered by the chip front-end design team, which is used to describe the register and memory mapping information. The file usually defines the register address, bit width, field and default value in a standardized format (such as structure, macro definition, etc.), which is used for automatic docking of subsequent driver development and verification environment.

[0124] Figure 1 the structure body register description: refers to the method of modeling the register in the form of structure body of programming language. Each register is represented as a structure field, including address, bit width and field definition, which can be used for direct access to the register in driver development.

[0125] Figure 1 the macro register description: refers to the description of register and field by macro definition. Macro register description usually presents in the form of address, offset and mask, which is used for quick expansion of register operation in code, suitable for expansion at compile time and improve access efficiency.

[0126] Figure 1 EDA tool delivered code: refers to the register modeling or access code automatically generated by electronic design automation (EDA) tools according to register specification or register transfer level (RTL) code. This type of deliverable often serves as the basis for the interface between the design and verification teams.

[0127] 3) SystemVerilog end standardized interface design, as shown in Figure 2

[0128] ①, the SystemVerilog end standardized interface also uses parameterized macros and task methods to ensure the consistency of the interface and the calling process. The underlying implementation can automatically adapt to different protocols according to the configuration, ensuring seamless integration with the actual verification platform.

[0129] ②, fully adapt to the UVM verification environment, with good scalability. For special protocol requirements, targeted extension can be carried out through inheritance and parameterization mechanism to meet the diversified scenarios of the project.

[0130] ③, the SystemVerilog end standardized interface also uses a layered architecture:

[0131] ⅰ, the user interface layer of the SystemVerilog end: unified calling interface, convenient for verification case development and maintenance; Figure 2 The WRITE_REG, READ_REG, MEMORY_WRITE and MEMORY_READ shown in the user interface block diagram of the SystemVerilog end are directly callable interface functions. These functions form a one-to-one correspondence with all the operations listed in the basic operation list supported by the structured flow table in Table 2.

[0132] ⅱ, the general implementation layer of the SystemVerilog end: supports register description based on UVM RAL model or macro definition, flexible parameter configuration; Figure 2 The uvm_reg_write(), uvm_reg_field_write(), uvm_reg_field_read(), uvm_reg_read(), mmio_read() and mmio_write() shown in the general implementation block diagram of the SystemVerilog end are all intermediate layer function logic for connecting the standardized user interface to the underlying implementation and EDA standardized header file. The figure shows the structure of the intermediate connection code through strict classification and layering, which realizes the decoupling of the underlying implementation and the user interface, and lays the foundation for supporting multiple bus protocols in the actual SystemVerilog verification environment, automatically adapting the UVM RAL register model, and supporting front door and back door access.

[0133] ​iii. The bottom layer implementation layer of the SystemVerilog end: support multiple bus protocols (such as CHI, AXI, AHB, APB) excitation, automatically adapt UVM RAL register model, and support front door and back door access. Back door access utilizes the SystemVerilog RTL simulation feature, which helps to significantly improve the simulation speed. Figure 2 The init_ref_env(), ref_env(), apb_write(), ahb_write(), axi_write(), chi_write(), apb_read(), ahb_read(), axi_read(), chi_read(), backdoor_write, backdoor_read and the like shown in the bottom layer implementation block diagram are bottom layer implementation functions supporting different bus protocols and different types (front door or back door) of access. These functions can be flexibly reconstructed or extended, thereby allowing the application to support more application scenarios according to actual needs without affecting the user interface and the top layer working mode of the application.

[0134] Embodiment 2

[0135] The automatic code generation process proposed by the application takes the tabular input of register and memory operation as a unified entrance, and sequentially completes semantic analysis, intermediate representation construction, optimization splicing, target mapping and interface alignment consistent output, so that consistent code products are obtained for C and SystemVerilog languages at one time.

[0136] The application introduces an original analysis mechanism and an optimization splicing method in the process.

[0137] 1. Information flow and module division

[0138] The processing information flow of the automatic script is as shown in Figure 3 The key steps are as follows:

[0139] 1. Semantic analysis: The contents in the input table are parsed according to the definition in the input specification and are subjected to legality check.

[0140] 2. Intermediate representation construction: The parsed register / memory operation is abstracted into an atomic operation sequence (write whole word, write bit field, read, polling, block read / write, delay, control flow node, etc.).

[0141] 3. Optimization splicing: The constructed intermediate representation layer is implemented to be merged and eliminated, so as to reduce the bus transaction volume while ensuring semantic equivalence.

[0142] 4. Target mapping: The optimized operation sequence is mapped into C language and SystemVerilog language, which can be compiled and simulated.

[0143] 5)Interface alignment: Ensure the consistency of name, parameter, bit width, timing, etc. in the final code generation stage, to avoid cross-language stack deviation.

[0144] 2. Parsing mechanism

[0145] In the parsing stage, the present application proposes several optimization designs:

[0146] 1)Default inheritance: Automatically inherit the effective value of the previous line for fields not explicitly filled, simplifying long process input description.

[0147] 2)Multi-numeric value representation support: Unified hexadecimal / decimal / binary and other different numeric representations to avoid inconsistencies caused by target language differences.

[0148] 3)Constraint and conflict checking: Automatically detect control flow pairing, bit width range, protocol legality and same field conflict to ensure input validity and auditability.

[0149] These mechanisms reduce the burden of manual maintenance and improve engineering controllability.

[0150] 3. Optimized splicing method

[0151] 1)"Read-Write" merge

[0152] For multiple write bitfield operations on adjacent registers, merge them into a "read-write" sequence without barrier conditions:

[0153] ① Read the entire word of the register;

[0154] ② Set the new value of multiple bitfields in order (later write overwrites earlier write);

[0155] ③ Write back to the register once.

[0156] Bus access is reduced from multiple to "1 read + 1 write", with unchanged functionality.

[0157] 2)Redundancy elimination

[0158] If the same bitfield is written multiple times with the same value within a read-independent interval, the previous item is automatically removed to reduce redundancy.

[0159] 3)Barrier protection

[0160] The following situations constitute a barrier, and optimization cannot cross:

[0161] ① Explicit time delay.

[0162] ② Control flow boundaries (IF / ELSE / ENDIF, LOOP / ENDLOOP).

[0163] ③, read dependency (register value used for subsequent comparison / polling).

[0164] ④, register / namespaces switching.

[0165] 4) Cross-language consistency

[0166] Optimization is completed uniformly at the intermediate representation layer, and is simultaneously mapped to C language and SystemVerilog language, ensuring "one optimization, double consistency".

[0167] 4, final engineering code output product

[0168] 1) Automatically output C code, unified interface style functions and macro calls, implement register / memory operations, flow control and other functions, and facilitate integration in bare machine testing, embedded driver or COSIM firmware direct calls.

[0169] 2) Automatically output SystemVerilog code, unified interface tasks or macros, which can be directly integrated into verification platforms, UVM environments or COSIM stimulus tasks.

[0170] 5, engineering integration and application expansion

[0171] 1) By editing and managing different structured flow tables, the program code (C code or SysvermVerilog code) automatically generated by the present application can be flexibly embedded in the project verification simulation or software test environment (such as embedded C code environment, embedded UVM environment, and finally co-verification simulation), thereby meeting different configuration requirements of complex SoC systems in different test scenarios.

[0172] 2) In the COSIM environment, the automatically generated C / SystemVerilog interface and task implementation parameters are one-to-one corresponding, providing a table-driven, automatic code generation and interface consistency integrated solution for software and hardware co-verification.

[0173] 3) Support for subsequent expansion, including adding protocols, memory spaces or data types, only need to adjust the input table or the underlying template, reducing the difficulty of system maintenance and upgrading.

[0174] The above only describes the preferred embodiments of the present application and does not limit the present application. Any modification, equivalent replacement and improvement made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for generating a register and memory operation code uniformly, characterized in that, The method comprises the following steps: Step 1, semantic analysis Design input specification and output specification, define structured flow table according to input specification and output specification, take structured input of register / memory operation as unified entrance, take structured flow table as input, parse content in input structured flow table according to definition in input specification and perform legality check; Step 2, intermediate representation construction Abstract register / memory operation after legality check into atomized operation sequence to obtain intermediate representation layer; Step 3, optimization splicing Implement merging and elimination on obtained intermediate representation layer to obtain optimized operation sequence; Step 4, target mapping Map optimized operation sequence into C language and SystemVerilog language compilable and simulatable products; Step 5, interface alignment Standardize interface form, parameter style and calling specification, all output codes adopt unified function interface and calling mode to perform output code standardization and unification; Step 6, output code Generate two types of code products which can be directly integrated for use in simulation environment; The merging method of the optimization splicing comprises: If multiple write bit field operations acting on the same register are adjacent, under barrier-free condition, the multiple write bit field operations are merged into a read-after-write sequence, and the read-after-write sequence comprises reading an integral word of the register, sequentially setting new values of multiple bit fields, and writing back the integral word of the register once. The elimination method of the optimization splicing comprises: If the same bit field is written with the same value multiple times in a read-independent interval, the previous operation is automatically removed.

2. The method of claim 1, wherein: The parsing mechanism of the semantic analysis comprises: Default inheritance, fields not explicitly filled automatically inherit valid values of the previous line; Support for multi-radix numerical representation, unified hexadecimal / decimal / binary and other different numerical representations; Constraint and conflict checking, automatically detect control flow pairing, bit width range, protocol legality and same field conflict.

3. The method of claim 1, wherein: The atomized operation sequence comprises write integral word, write bit field, read, polling, block read-write, delay and control flow node.

4. The method of claim 1, wherein: In the process of interface standardization and unification, C-end standardized interface design is performed, comprising: Both automatically generated C header files and source files are encapsulated by using macro or static inline function; The C-end standardized interface adopts layered architecture, and the architecture of the C-end standardized interface comprises a user interface layer of the C-end, a general implementation layer of the C-end and a bottom layer implementation layer of the C-end.

5. The method of claim 1, wherein: In the process of interface standardization and unification, SystemVerilog-end standardized interface design is performed, comprising: The SystemVerilog-end standardized interface adopts parameterized macro and task mode, adapts to UVM verification environment, and the SystemVerilog-end standardized interface adopts layered architecture; The architecture of the SystemVerilog-end standardized interface comprises a user interface layer of the SystemVerilog-end, a general implementation layer of the SystemVerilog-end and a bottom layer implementation layer of the SystemVerilog-end.

6. The method of claim 1, wherein: The two types of code products are C language code and SystemVerilog code, the C language code is directed to a C language stack compilable code / library, follows a layered interface framework, automatically adapts register / memory description of project delivery, and can be directly used for COSIM simulation, initialization and function calling of hardware acceleration; the SystemVerilog task is directed to a SystemVerilog language stack simulative code / library, is consistent with the C language in interface semantics and calling sequence, can be directly integrated and called in a standardized simulation environment, and supports front door / back door access and multi-protocol excitation.

Images