Code generation method and device

Abstract

The invention discloses a code generation method, aiming at an SOC, a design document corresponding to the SOC is obtained, and the design document comprises basic information of different function modules, configuration information corresponding to a register included in each function module and protocol information corresponding to an interface. The design document corresponding to the SOC is analyzed to obtain structured data, and the structured data comprises a function module, a connection relation between a register and an interface and a register mapping space. Then, based on the structured data and the code template, a target code is generated. Wherein the code template defines the structure and the style of a target code, and the target code can be used in embedded software development. It can be seen that the structural data is obtained by analyzing the design document corresponding to the SOC, and the complete verification code and the chip drive code meeting the specification are automatically generated through the structural data and the code template, so that the design efficiency is greatly improved, human errors are reduced, and the consistency among hardware, the verification environment and software drive is guaranteed.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a code generation method and apparatus. Background Technology

[0002] A system-on-a-chip (SoC), also known as a system-on-a-chip, is an integrated circuit technology that highly integrates various functional modules required for a complete system onto a single chip. Specifically, it integrates multiple functional modules such as processors, memory, and peripheral interfaces onto a single chip, achieving "system-level" miniaturization.

[0003] Typically, during the Design Verification (DV) phase, DV personnel need to manually write verification code based on the user manual of the functional modules. After verification, they also need to drive developers to manually write the corresponding driver code for each functional module.

[0004] When a System-on-a-Chip (SoC) includes a large number and variety of functional modules, verification engineers and driver development engineers need to manually write a large amount of relatively fixed verification and driver code based on the design documents (i.e., the user manuals for different functional modules). This process is extremely tedious and repetitive, and is highly susceptible to human error, leading to inconsistencies between the code and the design documents, thus introducing subtle errors. Moreover, manually writing code consumes a significant amount of time and human resources, becoming one of the bottlenecks in the entire SoC design process. Summary of the Invention

[0005] In view of this, this application provides a code generation method and apparatus that can automatically generate complete and compliant verification code and / or driver code by parsing structured SOC design template data, thereby reducing human error and improving design efficiency.

[0006] To solve the above problems, the technical solution provided in this application is as follows:

[0007] In its first aspect, this application provides a code generation method. For any System-on-a-Chip (SoC), the method obtains the design document corresponding to that SoC. This design document includes basic information about different functional modules, configuration information for the registers included in each functional module, and protocol information for the interfaces. The method then parses the design document to obtain structured data, which includes the connection relationships between functional modules, registers, and interfaces, as well as the register mapping space. Finally, based on the structured data and a code template, target code is generated. The code template defines the structure and style of the target code, which can be used in embedded software development. Therefore, this application obtains structured data by parsing the design document corresponding to the SoC, and then automatically generates complete and compliant verification code and chip driver code using the structured data and code template. This significantly improves design efficiency, reduces human error, and ensures consistency between hardware, verification environment, and software driver.

[0008] In a second aspect of this application, a code generation apparatus is provided, comprising: an acquisition unit, a parsing unit, and a generation unit. The acquisition unit is configured to acquire a design document corresponding to a system-on-a-chip (SoC), the design document including basic information of different functional modules, configuration information of registers included in a functional module, and protocol information corresponding to interfaces.

[0009] The parsing unit is used to parse the design document to obtain structured data, which includes the connection relationship between the functional modules, the registers and the interfaces, and the register mapping space.

[0010] The generation unit is used to generate target code based on the structured data and the code template. The code template defines the structure and style of the target code, and the target code can be used in embedded software development.

[0011] In a third aspect of this application, a code generation apparatus is provided, including a processor and a memory, wherein the memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to perform the method as described in the first aspect.

[0012] In a fourth aspect of this application, a computer-readable storage medium is provided storing a computer program that is loaded by a processor to execute the method described in the first aspect.

[0013] In a fifth aspect of this application, a computer program product is provided, the computer program product comprising: a computer program (also referred to as code or instructions) that, when the computer program is run, causes a computer to perform the method described in the first aspect above. Attached Figure Description

[0014] Figure 1 A flowchart of a code generation method provided in an embodiment of this application;

[0015] Figures 2a to 2c This is a schematic diagram of a SOC structure;

[0016] Figure 3 A schematic diagram of a code generation framework provided in an embodiment of this application;

[0017] Figure 4 A structural diagram of a code generation device provided in an embodiment of this application;

[0018] Figure 5 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the embodiments of this application will be further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0020] To facilitate understanding of the technical solutions provided in the embodiments of this application, the technical knowledge of this application will be explained below.

[0021] 1. A System-on-a-Chip (SoC) mainly consists of three parts: functional modules, registers, and interfaces. Functional modules are the core functional carriers of the SoC, serving as hardware units that execute specific tasks. Registers are the operational windows of the functional modules. Interfaces are the data interaction channels between functional modules and between functional modules and external systems. Typically, the configuration, status reading, and data transmission of functional modules are all achieved by accessing the registers within the functional modules through the "interface," ultimately enabling the scheduling and coordination of functional modules.

[0022] Registers are the core internal hardware units of a functional module; a functional module without registers cannot be configured. Typically, a functional module integrates dozens to hundreds of dedicated registers. The essence of a System-on-a-Chip (SoC) is to perform "configuration, control, data transmission, and status feedback" on various functional modules. However, these four types of operations cannot be directly applied to the functional modules; they must be implemented through interfaces as pathways and registers as the objects of operation.

[0023] 2. Universal Verification Methodology (UVM), based on the object-oriented programming features of SystemVerilog, constructs a hierarchical, modular, and portable verification platform through standardized component architecture, unified communication mechanisms, and reusable class libraries. This enables efficient and comprehensive verification of chip (e.g., SOC) functionality. Essentially, it abstracts the general chip verification process (stimulus generation, data acquisition, functional checking, coverage collection, etc.) into standardized components and interaction rules, allowing developers to focus on the specific verification logic of the Design Under Test (DUT) without repeatedly designing the infrastructure.

[0024] 3. Design Verification (DV) is the core and critical stage of SoC chip development from hardware design completion to tape-out (chip manufacturing), and it is also the most time-consuming and manpower-intensive stage in chip R&D. Simply put, the core goal of the DV stage is to discover and fix all functional, timing, protocol, and integration defects in the SoC hardware design (RTL code) through comprehensive verification methods, ensuring that the design fully meets the product specification requirements and avoiding hardware defects after tape-out.

[0025] Traditionally, design verification (DV) personnel need to manually write System Verilog code for design verification based on the functional module manuals. Furthermore, in the subsequent software driver phase of the SoC, driver developers also need to manually write the driver code for each functional module. This process is extremely tedious and repetitive, and is highly susceptible to human error leading to inconsistencies between the code and the design documents, thus introducing subtle errors. Moreover, manually writing code consumes significant time and manpower, resulting in low efficiency and long development cycles. Furthermore, when the hardware design changes (such as register addresses, bit widths, or functional modifications), the verification environment and drivers need to be updated synchronously. Manually maintaining this consistency is very difficult, often resulting in omissions, leading to insufficient verification or driver incompatibility with the hardware.

[0026] While some code generation tools exist that can generate partial code frameworks from XML files of a specific format, these tools typically have the following limitations: (1) Poor flexibility: They heavily rely on specific input formats (such as IP-XACT) and are difficult to adapt to company-defined design description templates or document formats. (2) Weak customization capability of generated code: The generated code is often a general framework that cannot adequately meet the verification strategies or driver programming specifications of specific projects or architectures, requiring engineers to make extensive manual modifications. (3) Low integration: They may only focus on generating either verification code or driver code, lacking a unified solution that can generate both types of code simultaneously.

[0027] Therefore, there is an urgent need for a method that can flexibly parse multiple design templates and automatically generate high-quality, customizable verification code and driver code to solve the above problems. Based on this, this application provides a code generation method that parses the design document corresponding to the SoC to obtain structured data for that SoC, and then automatically generates complete and compliant verification code and chip driver code based on this structured data and code templates. This significantly improves design efficiency, reduces human error, and ensures consistency between hardware, verification environment, and software drivers.

[0028] To facilitate understanding of the specific implementation of this application, the following description will be provided in conjunction with embodiments.

[0029] See Figure 1 The figure is a flowchart of a code generation method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes:

[0030] S101: Obtain the design document corresponding to a SOC. The design document includes basic information of different functional modules, configuration information of registers included in a functional module, and protocol information corresponding to the interface.

[0031] The basic information of a functional module can include its name, version, and functional description, as well as the configuration information for each register within that module. This configuration information can include the register name, address offset, bit width, reset value, access permissions, and the attributes and functional description of each functional domain. It's important to note that each register has a unique address (offset) in the SoC memory space, which is used to access the corresponding register along with the base address. Typically, a register is 32 bits wide. To save space, designers don't use 32 registers to control 32 switches; instead, they divide these 32 bits into different groups, each group responsible for a specific function—this is the functional domain.

[0032] In practical implementation, the division of register functional domains is ultimately reflected in the address space mapping of the SoC. This is the core bridge from "logical classification" to "hardware implementation" of functional domains, and the sole basis for software access to registers. The address division of register functional domains satisfies the following conditions: register addresses within the same functional domain are contiguous, facilitating hardware decoding and batch software operations; register addresses of different functional domains do not overlap, avoiding address conflicts; and a certain address gap is reserved (e.g., 0x1000 address space is reserved for each module domain) to facilitate subsequent hardware upgrades and register expansion.

[0033] The protocol information corresponding to the interface can include the type of on-chip bus, signal list, and timing. This standardized constraint on bus interaction from three dimensions—functional positioning, physical implementation, and execution rules—is a prerequisite for correct communication between functional modules. The bus type is used to match appropriate buses for interactions between different functional modules; for example, low-speed peripherals use the APB bus, and high-speed storage uses the AXI bus, balancing performance and hardware overhead. The signal list defines the physical carrier for data interaction between different functional modules. According to function, it can be divided into control signals, address signals, response signals, clock signals, and reset signals, etc., each with a defined direction and bit width. The timing defines the timing and duration requirements of signals to avoid data transmission errors caused by out-of-order or unstable signals.

[0034] The design document can be in various formats, such as YAML, JSON, XML, or a custom structured table format. When the design document is in Excel format, one functional module corresponds to one sheet, and different functional modules correspond to different sheets, thus allowing different designers to be responsible for their respective functional modules.

[0035] S102: Parse the design document to obtain structured data, which includes the connection relationships between functional modules, registers, and functional domains, as well as the register mapping space.

[0036] After obtaining the SOC design document, it is parsed to obtain structured data. This structured data includes the connections between functional modules, registers, and functional fields within registers in a hierarchical structure, as well as the register mapping space. That is, the structured data can display the connections between the functional modules included in the SOC, the registers included in a functional module, the different functional fields included in each register, and the protocols corresponding to the interfaces in the form of a hierarchical tree.

[0037] In this embodiment, a parsing engine can be used to parse the design document. During parsing, the engine also checks the syntax and semantics of the design document to determine the correctness of the extracted structured data. Specifically, it verifies the register configuration information in the design document. If the verification passes, structured data is obtained from the design document; if the verification fails, the result is fed back to the designer for adjustments to the design document.

[0038] The verification of register configuration information includes checking whether register addresses are aligned, whether address ranges overlap, and whether functional fields (bit fields) conflict. Address alignment ensures that a single register can be correctly accessed by the bus, address non-overlapping ensures that the address spaces of different functional modules do not conflict, and bit field non-conflict ensures that the functional definition of each bit in the register is not repeated. These three factors together guarantee the underlying correctness of the register from "address access" to "field function".

[0039] In some implementations, interface timing constraints can also be verified. Interface timing constraint verification is a timing compliance check conducted on the hardware interfaces of functional modules / chips during the SoC design and DV phases. The core is to first define clear timing constraint rules for the interface, and then check whether the actual behavior of the signals complies with these rules.

[0040] It should be noted that the structured data obtained through parsing is neutral and independent of the code language. This structured data is the core data for generating code, and it completely represents the register mapping space and interface information in the SOC in a standardized way.

[0041] For easier understanding of structured data, see [link to relevant documentation]. Figure 2a The SOC architecture diagram shown includes a central processing unit (CPU) and three functional modules: module A, module B, and module C. Modules A and B are assigned to the same domain (Domain1), while module C is assigned to Domain2.

[0042] The registers included in each of modules A, B, and C are as follows: Figure 2b As shown, the explanation uses a 32-bit register as an example. Figure 2b As shown, module A includes M registers, namely registers A_1 to A_M; module B includes N registers, namely registers B_1 to B_N; and module C includes K registers, namely registers C_1 to C_K. Each register corresponds to an address offset and a functional bit field (or simply functional field) that is divided into 32 bits. Different functional bit fields can correspond to different numbers of bits, and there are no overlapping bits between different functional fields.

[0043] based on Figure 2a and Figure 2b The SOC shown can be obtained Figure 2c The structured data shown allows us to obtain the mapping relationship between registers and addresses within different modules of the SOC, as well as the partitioning structure of different functional bit fields within the registers. Figure 2cIt can be seen that different registers within the same module can be divided into different functional domains, and different functional domains can occupy different bits. For example, register A_1 in module A is divided into 4 functional domains: functional domain A_1_fd1 occupies Bit0; functional domain A_1_fd2 occupies Bits 1 and 2; functional domain A_1_fd3 occupies Bits 3, 4, and 5; and functional domain A_1_fd4 occupies Bits 8, 9, and 10. Register A_M in module A is also divided into 4 functional domains: functional domain A_M_fd1 occupies Bits 0, 1, and 2; functional domain A_M_fd2 occupies Bits 4, 5, and 6; functional domain A_M_fd3 occupies Bits 7, 8, and 9; and functional domain A_M_fd4 occupies Bits 10, 11, and 12.

[0044] S103: Generate target code based on structured data and code templates. This target code can be used in embedded software development for this SCO.

[0045] The code template defines the structure and style of the code. In this embodiment, the structured data extracted in S102 is used as the data source and input into the code template to render the final target code. After obtaining the target code, it can be stored in the directory corresponding to the execution project.

[0046] Specifically, the code template may include a first code template for generating verification code and / or a second code template for generating driver code. By using different code templates with the same structured data, the required code can be generated. Specifically, verification code is generated based on the structured data and the first code template; and / or, driver code is generated based on the structured data and the second code template.

[0047] The first code template includes a register template, a test sequence template, and a bus adapter template. The verification code includes the required register model, bus adapter, and test sequence. Specifically, the register model is used to simulate the behavior of hardware registers; the bus adapter is used to adapt to the bus protocol for data interaction; and the test cases are used to define the verification scenario and execution logic, and are responsible for all verification operations, controlling the verification process, and judging the verification results.

[0048] The second code template includes a register mapping header file template, an application programming interface (API) function template, and an interrupt handling template. The driver code includes register read / write functions, such as the read function REG_READ(addr) and the write function REG_WRITE(addr, value).

[0049] In some implementations, code templates can be modified to suit the needs of different projects, customizing code style, naming conventions, comment formats, etc., so that the generated code can be seamlessly integrated into traditional development workflows. Because the code template structure is simple and easy to adjust, the workload for adjustments is reduced, and the universality of the code template is improved.

[0050] As can be seen, this application obtains structured data by parsing the design document corresponding to the SOC, and then uses the structured data and code templates to automatically generate complete and compliant verification code and chip driver code, thereby significantly improving design efficiency, reducing human error, and ensuring consistency between hardware, verification environment and software driver.

[0051] For a better understanding of the implementation framework of this application, please refer to [link / reference]. Figure 3 The system architecture diagram for automatic code generation shown first obtains the design document corresponding to the SOC; then, it uses a parsing engine to parse and verify the design document to obtain structured data; finally, it inputs the structured data into the code generation engine, uses a verification code template to generate verification code, and uses a driver code template to generate driver code.

[0052] Based on the above method embodiments, this application provides a code generation apparatus and device, which will be described below in conjunction with embodiments.

[0053] See Figure 4 This figure is a structural diagram of a code generation device provided in an embodiment of this application, such as... Figure 4 As shown, the code generation device 400 includes an acquisition unit 401, a parsing unit 402, and a generation unit 404. The code generation device 400 can implement the functions of the above-described method embodiments.

[0054] The acquisition unit 401 is used to acquire the design document corresponding to a system-on-a-chip (SOC). The design document includes basic information of different functional modules, configuration information of registers included in a functional module, and protocol information corresponding to the interface.

[0055] The parsing unit 402 is used to parse the design document to obtain structured data, which includes the connection relationship between the functional module, the register and the functional domain in the register, the register mapping space and the interface;

[0056] The generation unit 404 is used to generate target code based on the structured data and the code template. The code template defines the structure and style of the target code, and the target code can be used in embedded software development for the SOC.

[0057] In some implementations, the generation unit 404 is specifically used to generate verification code based on the structured data and the first code template; and / or to generate driver code based on the structured data and the second code template.

[0058] In some implementations, the first code template includes a register model template, a test sequence template, and a bus adapter template, and the verification code includes the register model, bus adapter, and read / write test sequence required for verification.

[0059] In some implementations, the second code template includes a register mapping header file template, an application programming interface (API) function template, and an interrupt handling template, and the driver code includes register read / write functions.

[0060] In some implementations, the parsing unit 402 is specifically used to parse the design document and verify the configuration information of the registers in the design document;

[0061] If the verification passes, structured data is obtained from the design document.

[0062] In some implementations, the verification entries include one or more of the following:

[0063] Are the register addresses aligned? Do the address ranges overlap? Do the functional domains conflict?

[0064] In some implementations, the design document is YAML, JSON, or XML.

[0065] It should be noted that the specific implementation of each unit in this embodiment can be found in the relevant descriptions in the above method embodiments.

[0066] The code generation apparatus provided in this application embodiment may include software to implement the code generation method described above. Alternatively, the code generation apparatus provided in this application embodiment may include hardware to implement the code generation method described above. Alternatively, the code generation apparatus provided in this application embodiment may include both software and hardware, utilizing a combination of software and hardware to execute the code generation method described above.

[0067] This application also provides an electronic device. This electronic device is specifically used to implement, as described above. Figure 4 The code generation device 400 in the illustrated embodiment has the following functions.

[0068] Figure 5 A structural schematic diagram of an electronic device 500 is provided, such as... Figure 5As shown, the electronic device 500 includes a bus 501, a processor 502, a communication interface 503, and a memory 504. The processor 502, the memory 504, and the communication interface 503 communicate with each other via the bus 501.

[0069] Bus 501 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0070] The processor 502 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0071] Communication interface 503 is used for external communication. For example, communication interface 503 can be used to communicate with a terminal.

[0072] Memory 504 may include volatile memory, such as random access memory (RAM). Memory 504 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0073] The memory 504 stores executable code, and the processor 502 executes the executable code to perform the aforementioned code generation method.

[0074] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape) or a semiconductor medium (e.g., solid-state disk (SSD)).

[0075] This application also provides a readable storage medium for storing the methods provided in the above embodiments. Examples include random access memory (RAM), flash memory, read-only memory (ROM), EPROM, non-volatile read-only memory (EPROM), registers, hard disks, removable disks, or any other form of storage medium in the art.

[0076] This application also provides a computer program product comprising one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this application are generated.

[0077] The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another website, computer, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0078] When the computer program product is executed by a computer, the computer performs any of the aforementioned task flow repair methods. The computer program product can be a software installation package; when any of the aforementioned task flow repair methods is required, the computer program product can be downloaded and executed on the computer.

[0079] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0080] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A code generation method, characterized in that, The method includes: Obtain the design document corresponding to a system-on-a-chip (SOC). The design document includes basic information of different functional modules, configuration information of registers included in a functional module, and protocol information corresponding to the interface. The design document is parsed to obtain structured data, which includes the connection relationship between the functional module, the register, and the functional domain of the register, the register mapping space, and the interface. Based on the structured data and code template, target code is generated. The code template defines the structure and style of the target code. The target code can be used in embedded software development for the SOC.

2. The method according to claim 1, characterized in that, The step of generating target code based on the structured data and code template includes: Based on the structured data and the first code template, generate verification code; and / or, Based on the structured data and the second code template, driver code is generated.

3. The method according to claim 2, characterized in that, The first code template includes a register model template, a test sequence template, and a bus adapter template. The verification code includes the register model, bus adapter, and read / write test sequence required for verification.

4. The method according to claim 2, characterized in that, The second code template includes a register mapping header file template, an application programming interface (API) function template, and an interrupt handling template. The driver code includes register read / write functions.

5. The method according to claim 1, characterized in that, The process of parsing the design document to obtain structured data includes: The design document is parsed, and the configuration information of the registers in the design document is verified; If the verification passes, structured data is obtained from the design document.

6. The method according to claim 5, characterized in that, The verification entries include one or more of the following: Are the register addresses aligned? Do the address ranges overlap? Do the functional domains conflict? 7. The method according to claim 1, characterized in that, The design document can be in YAML, JSON, or XML format.

8. A code generation device, characterized in that, The device includes: The acquisition unit is used to acquire the design document corresponding to a system-on-a-chip (SOC). The design document includes basic information of different functional modules, configuration information of registers included in a functional module, and protocol information corresponding to the interface. The parsing unit is used to parse the design document to obtain structured data, which includes the connection relationship between the functional modules, the registers and the interfaces, and the register mapping space. The generation unit is used to generate target code based on the structured data and the code template. The code template defines the structure and style of the target code, and the target code can be used in embedded software development.

9. A code generation device, characterized in that, It includes a processor and a memory, the memory being used to store programs, instructions, or code, and the processor being used to execute the programs, instructions, or code in the memory to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The device contains a computer program that is loaded by a processor to perform the method as described in any one of claims 1-7.

Images