Collaboration, conversion method and apparatus for register specification document

Abstract

This specification provides a method and apparatus for collaborating and converting register specification documents. The method for collaborating register specification documents includes: obtaining at least two register specification documents in a first format corresponding to the same register; parsing and extracting the specification semantics of the register specification documents and generating standardized structured text; wherein the structured text is hierarchically divided and arranged in lines according to registers and bit fields; using a version control system to merge the structured text at the line level to obtain the latest merged structured text; parsing the latest structured text and reconstructing it to generate a register specification document in a second format including the layout style.

Description

Technical Field

[0001] This specification relates to the field of integrated circuit technology, and in particular to a method and apparatus for collaborating and converting register specification documents. Background Technology

[0002] In chip design, register specifications (such as control registers and status registers) are typically maintained collaboratively by architects, designers, verifiers, and software engineers. These specifications can be used to convert registers into various hardware implementations, such as RTL (register-transfer level) and UVM (Universal Verification Methodology) models. RTL is an abstract model of synchronous digital circuits, determined by the flow of digital signals between hardware registers, memories, combinational logic devices, and buses, and their logical algebraic operations. UVM is a standard verification method in integrated circuit design, used to improve the automation level of the verification process and shorten the chip verification cycle.

[0003] Initially, hardware implementation primarily employed conversion methods based on specialized modeling languages ​​or standard drivers. Examples include SystemRDL (and PeakRDL / ordt), IP-XACT (XML), and Synopsys RALF. However, this approach requires first constructing register specification documents in a unique, authoritative source format such as DSL (Domain-Specific Language) or XML (Extensible Markup Language), and then converting these documents into hardware implementations such as RTL. The problem with this approach is that the unique, authoritative source format is not the document format engineers use daily, resulting in a high learning curve. For example, architects / software engineers are accustomed to maintaining register specification documents using everyday Word / Excel, requiring others proficient in the unique, authoritative source format to manually input the data (i.e., manually entering data from Word / Excel into the unique, authoritative source format register specification document), which can easily introduce inconsistencies.

[0004] To address this, a document-driven, one-way generation tool was later introduced as a conversion method. This method supports register specification documents maintained in Word / Excel format, and can automatically convert these documents to RTL using an automatic generation tool. However, this method still has some problems: (a) One-way conversion only: Word / Excel data is converted to RTL in a single direction. Once the intermediate data is modified, it cannot be fed back into the Word / Excel format register specification document. (b) The register specification document cannot be converted between different formats (e.g., Word cannot be automatically converted to Excel, and vice versa). (c) Collaboration is difficult: the commonly used Word / Excel format of the register specification document is essentially a binary package, and the register version control system cannot perform line-level merging of Word / Excel files. Conflicts will occur if multiple people modify the Word / Excel format register specification document in parallel, thus forcing the adoption of a "serial modification" mode (one person locks the register specification document while others wait in a queue), severely slowing down the development progress.

[0005] Therefore, there is a need to provide a method that can solve at least one of the above problems. Summary of the Invention

[0006] In view of the above, one or more embodiments of this specification provide a method and apparatus, electronic device, and storage medium for collaborating and converting register specification documents to solve the problems existing in the related art.

[0007] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of the embodiments of this specification, a collaborative method for register specification documentation is provided, the method comprising: Obtain at least two register specification documents in first format corresponding to the same register; The specification semantics of the register specification document are parsed and extracted to generate standardized structured text; wherein, the structured text is hierarchically divided and arranged in lines according to registers and bit fields; The structured text is merged at the line level using a version control system to obtain the latest merged structured text. The latest structured text is parsed, and a register specification document in a second format, including layout styles, is generated by reverse reconstruction.

[0008] Optionally, the process of parsing the register specification document may also include: The error-prone and highly regular specification semantics in the register specification document are derived to obtain the corresponding specification semantics.

[0009] Optionally, the step of deriving the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics includes: Obtain the register address from the parsed register specification document, and verify whether the register address is less than or equal to the previous register address; If the register address is less than or equal to the previous register address, then the previous register address is incremented by a first value to obtain the corrected register address, and the register address in the register specification document is set to the corrected register address.

[0010] Optionally, the step of deriving the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics includes: Obtain the bit width information of each field in the parsed register specification document, and verify whether the sum of the bit width information of each field is equal to the second value; If the sum of the bit width information of any field is not equal to the second value, an error will be reported and the parsing will be exited.

[0011] Optionally, the step of deriving the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics includes: Obtain all fields from the parsed register specification document, the double reset value for each field, and an indication flag indicating whether the double reset is executed independently; wherein, the double reset value includes a function reset value and a scan reset value; If the indicator flag indicates non-independent execution, then for target fields whose names contain clken, _rstn, or _rst_n, the scan reset value of the target field is set to 1, and the scan reset values ​​of other fields besides the target field are set to their respective function reset values.

[0012] Optionally, the step of deriving the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics includes: Obtain the read mask field from the parsed register specification document. For target fields whose names contain "reserved" and "write-only", set the value of the target field to 0, and set the value of other read mask fields other than the target field to 1.

[0013] Optionally, parsing the latest structured text and reconstructing it in reverse to generate a register specification document in a second format including typography styles includes: The specification semantics of the latest structured text are analyzed, and pure typesetting attributes are filtered out. During reverse reconstruction, the specification semantics are injected into a unified typesetting style template to generate a second-format unified register specification document; wherein, the unified typesetting style template is one of a variety of templates specified in the full version or release version.

[0014] Optionally, the collaborative method for the register specification document also includes an automated iterative step based on artificial intelligence: Receive natural language input commands from the user; The artificial intelligence agent (AI Agent) is used to parse the natural language requirement instructions and identify the register attributes or bit field parameters that need to be changed. The AI ​​agent automatically modifies the latest structured text and triggers an automated generation process downstream, simultaneously generating the corresponding hardware transmission-level code, verification model, and register planning document in the second format.

[0015] According to a second aspect of the embodiments of this specification, a method for converting register specification documents is provided, the method comprising: The various document formats of the register specification document are uniformly parsed into an intermediate representation dictionary; wherein, the intermediate representation dictionary records the field mapping relationship between the standardized structured text and the various document formats, as well as the field mapping relationship between the structured text and the corresponding hardware implementation model; the structured text is hierarchically divided and arranged in lines according to registers and bit fields; Perform at least one of the following transformation functions based on the intermediate representation dictionary: Based on the intermediate representation dictionary, the corresponding model is generated using hardware implementation. Perform mutual conversion between multiple document formats based on the intermediate representation dictionary; Based on the intermediate representation dictionary, the modified specification semantics are fed back into the register specification document, triggered by the modified specification semantics of the structured text.

[0016] Optionally, when the model is a register-transfer level model, the step of generating the corresponding model in hardware based on the intermediate representation dictionary includes: Based on the field access type of the structured text, a register primitive template corresponding to the field access type is matched from the parameterized register primitive library, and an initial register transfer level model is instantiated according to the register primitive template. Based on the field mapping relationship between the structured text recorded in the intermediate representation dictionary and the register-transfer level model, the specification semantics of the structured text are mapped to the initial register-transfer level model to obtain the final register-transfer level model.

[0017] Optionally, the specification semantics of the structured text includes a reset value field, which supports writing macros and identifiers; The step of mapping the specification semantics of the structured text to the initial register-transfer level model includes: Obtain the reset value field of macros and identifiers contained in the specification semantics of the structured text, and write the macros and identifiers into the DEF_VAL field of the initial register transfer level model.

[0018] Optionally, the structured text includes software write ports for W1S, W1C, and WDP, as well as hardware write ports for cust_wr and cust_wdat; The timing sequence for the dual-port update of the same status bit by the software write port and the hardware write port includes: If W1S triggers a write event, and the i-th bit of the write data of the W1S write event is 1, then the i-th bit is set to 0 and written to the status bit; if W1S does not trigger a write event, then the cust_wr triggers the cust_wdat write event, and the write data of the cust_wdat write event is written to the status bit. If both W1C and cust_wdat trigger write events simultaneously, the write data of the cust_wdat write event is written to the status bit; if only W1S triggers a write event, and the i-th bit of the write data of the W1S write event is 1, the write data is set to 1 and then written to the status bit. If the bus signal wr_en is valid, the write data of the cust_wdat write event is written to the status bit. If the bus signal wr_en is invalid, the cust_wr triggers the cust_wdat write event, and the write data of the cust_wdat write event is written to the status bit.

[0019] Optionally, when the write event faces a transition from the source clock domain to the target clock domain, the write event in the source clock domain is synchronized in the target clock domain using a level-flipping method or a pulse synchronization method. The pulse synchronization method includes converting the write event of the source clock domain into a pulse signal of one clock cycle. The level-flipping method includes: converting the write event of the source clock domain into a level-flipping signal, and triggering the level-flipping signal by a SYNC_FLAG_DLY level trigger to obtain a stable signal in the target clock domain; so that the target clock domain can identify the write event in the source clock domain by performing edge detection on the stable signal.

[0020] According to a third aspect of the embodiments of this specification, a collaborative apparatus for register specification documents is provided, the apparatus comprising: The acquisition unit acquires at least two register specification documents in first format corresponding to the same register; The generation unit parses and extracts the specification semantics of the register specification document and generates standardized structured text; wherein, the structured text is hierarchically divided and arranged in lines according to registers and bit fields; The merging unit uses a version control system to perform line-level merging on the structured text to obtain the latest merged structured text. The collaborative unit parses the latest structured text and reverse-engineers it to generate a register specification document in a second format that includes the layout style.

[0021] According to a fourth aspect of the embodiments of this specification, a register specification document conversion apparatus is provided, the apparatus comprising: The parsing unit parses the various document formats of the register specification document into an intermediate representation dictionary; wherein, the intermediate representation dictionary records the field mapping relationship between the standardized structured text and the various document formats, as well as the field mapping relationship between the structured text and the corresponding hardware implementation model; the structured text is hierarchically divided and arranged in lines according to registers and bit fields; The conversion unit performs at least one of the following conversion functions based on the intermediate representation dictionary: generating a model corresponding to the hardware implementation based on the intermediate representation dictionary; performing mutual conversion between multiple document formats based on the intermediate representation dictionary; and performing a modified specification semantic backfill register specification document triggered by the modified specification semantic of the structured text.

[0022] According to a fifth aspect of the embodiments of this specification, an electronic device is provided, including a processor; a memory for storing processor-executable instructions; wherein the processor implements the above-described method by executing the executable instructions.

[0023] According to a sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided, wherein computer-readable instructions are stored on the computer-readable storage medium, and the computer-readable instructions, when executed by a processor, implement the above-described method.

[0024] The technical solutions provided in the embodiments of this specification may include the following beneficial effects: For collaborative work on register specification documents, the original binary (first-format) register specification documents are uniformly converted to standardized structured text that supports line-level merging. Since structured text supports line-level merging, it can be merged into the latest structured text using a version control system, and then reconstructed in reverse to generate the second-format register specification document, which includes formatting styles. This solves the problem of binary format register specification documents being unable to be merged at the line level, thus preventing collaborative modification of the same register specification document.

[0025] Furthermore, for the conversion of register specification documents, the various document formats of register specification documents are uniformly parsed into an intermediate representation dictionary. Since this intermediate representation dictionary records the field mapping relationships between standardized structured text and the various document formats, as well as the field mapping relationships between the structured text and the corresponding hardware implementation models, it supports one-click derivation downwards to the corresponding hardware implementation models (such as RTL / RALF), and also supports upwards mutual conversion between multiple document formats and lossless round-trip reconstruction of specification semantics (i.e., modifying the specification semantics of the structured text triggers the re-feedback of the modified specification semantics to the register specification document). This solves the problems of existing document-driven unidirectional generation tools, which only perform unidirectional conversions and cannot convert between the various document formats of register specification documents. Attached Figure Description

[0026] Figure 1 A schematic diagram of a software system for collaboration and conversion of register specification documents, provided as an exemplary embodiment of this specification; Figure 2 A flowchart illustrating a collaborative method for register specification documentation as provided in an exemplary embodiment of this specification; Figure 3 A flowchart illustrating a method for converting register specification documents, provided as an exemplary embodiment of this specification; Figure 4 A schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this specification; Figure 5 A block diagram of a collaborative apparatus for a register specification document provided as an exemplary embodiment of this specification; Figure 6 This is a block diagram of a register specification document conversion device provided for an exemplary embodiment of this specification. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0028] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0029] As previously introduced, this method utilizes a document-driven, one-way generation tool. This approach supports register specification documents maintained in Word / Excel format, and can automatically generate RTL from these documents using an automatic generation tool. However, this method still has some limitations: (a) One-way conversion only: Word / Excel data is converted to RTL in a single direction. Once the intermediate data is modified, it cannot be fed back into the Word / Excel format register specification document. (b) The register specification document cannot be converted between different formats (e.g., Word cannot be automatically converted to Excel, and vice versa). (c) Collaboration is difficult: the commonly used Word / Excel format of the register specification document is essentially a binary package, and the register versioning tool cannot perform line-level merging of Word / Excel files. Conflicts will occur if multiple people modify the Word / Excel format register specification document in parallel, thus forcing the adoption of a "serial modification" mode (one person locks the register specification document while others wait in a queue), severely slowing down the development progress.

[0030] Therefore, this specification aims to provide a collaborative and conversion solution for register specification documents. Specifically, for collaborative work on register specification documents, the original binary first-format register specification documents are uniformly converted into standardized structured text that supports line-level merging. Since structured text supports line-level merging, it can be merged into the latest structured text using a version control system, and then reverse-engineered to generate a second-format register specification document including layout styles. This fundamentally solves the problem of binary documents being unable to be merged, enabling multiple people to edit register specification text in parallel and reverse-engineer the required register specification document.

[0031] Furthermore, for the conversion of register specification documents, the various document formats of register specification documents are uniformly parsed into an intermediate representation dictionary. Since this intermediate representation dictionary records the field mapping relationship between the standardized structured text and the various document formats, as well as the field mapping relationship between the structured text and the model corresponding to the hardware implementation, it supports one-click derivation of the corresponding model (such as RTL, RALF) for the hardware implementation, and also supports mutual conversion between multiple document formats and lossless round-trip reconstruction of specification semantics (i.e., modifying the specification semantics of the structured text triggers the re-feedback of the modified specification semantics to the register specification document).

[0032] The technical solution in this application introduces an Intermediate Representation (IR) dictionary as a "semantic anchor," decoupling "multi-document format parsing" and "multi-target transformation generation" into two independent stages, thus forming a star-shaped transformation architecture with IR as the hub. Standardized structured text (such as JSON) is used as an intermediate medium for line-level merging in version control systems (such as Git).

[0033] In the embodiments described in this application, the concept of "bidirectional" is involved, which generally has two meanings: Reversible format conversion at the same level: This refers to the forward parsing and reverse reconstruction between register specification documents (Word, Excel) and structured text (JSON). This enables lossless conversion between Word and Excel, and lays the foundation for multi-person collaboration on register specification documents.

[0034] Forward derivation of abstract dimensions: that is, one-click derivation of the corresponding model (such as RTL, UVM verification model, etc.) from the register specification document through IR generation hardware implementation.

[0035] It should be noted that the "bidirectional conversion" in this application refers to the reversible conversion between the register specification document (Word / Excel) and its structured text, as well as the forward derivation from the structured text to the hardware implementation; its core lies in eliminating the collaboration conflicts between multiple document formats by using the structured text as a hub, rather than deriving the register specification document from the generated hardware implementation model.

[0036] The following section, with reference to the accompanying drawings, provides a detailed explanation of the collaboration and conversion methods for the register specification document in this manual.

[0037] Please refer to Figure 1 , Figure 1This is a schematic diagram of a software system for collaboration and conversion of register specification documents provided as an exemplary embodiment of this specification. The software system may include a three-layer structure: a parsing front-end layer, an intermediate representation layer, and a product generation layer; and the product generation layer is also equipped with a parameterized register primitive library as an implementation base for generating models corresponding to the hardware implementation.

[0038] [Intermediate Presentation Layer] The intermediate representation layer contains the aforementioned intermediate representation dictionary IR. IR is the semantic anchor point for the transformation of the register specification document, and its data structure is as follows: Registers├── Memory_Map │ └──<REG_NAME> : {addr, name, rw,reset, domain, rd_bit_mask}└──<REG_NAME> └── <bits>: {bits, offset, name,width, rw, reset,scan, scan_in_reset, description} The intermediate dictionary includes a separate register master table (Memory_Map) and field details (bits) for each register.

[0039] The register summary table records the metadata of each register (register address addr, global type, reset domain, read mask rd_bit_mask), while the field details record the specification semantics at the register bit field level.

[0040] Each field in the field details carries two reset values: reset (functional reset value) and scan (DFT scan reset value), and the scan_in_reset flag distinguishes whether the functional reset value and the DFT scan reset value are specified independently.

[0041] In addition, IR contains both manually entered specification semantics such as bits, name, rw, reset, and description, as well as automatically derived specification semantics such as offset, width, rd_bit_mask, and normalized addr. Both manually entered and automatically derived specification semantics are solidified once during the parsing process of the upstream parsing front-end layer, so that the downstream product generation layer does not need to repeatedly derive specification semantics.

[0042] [Analyzing the Front-End Layer] The parsing front-end layer is used to unify the parsing of various document formats in register specification documents into a single IR.

[0043] like Figure 1 As shown, for the conversion of register specification documents, taking Word and Excel, two commonly used document formats, as examples, the parsing front-end layer can be set up with two parsing entry points corresponding to Word and Excel (i.e., Figure 1 The parsing entry points 1 and 2 shown are used to parse and normalize Word and Excel document formats to IR. For example, for Word documents, parsing requires traversing paragraphs and tables to extract register names and addresses; parsing global types and reset domains. For Excel documents, parsing automatically locates the table header to determine the data starting point, first scanning the overall register table and then the detailed fields. For collaborative work on register specification documents, the generated structured text is directly loaded by the software system as the underlying data for collaborative merging.

[0044] The two parsing entry points share the same set of fields to construct the underlying logic (ensuring semantic consistency and avoiding duplicate logic): bit field parsing and reset value type identification, bit range conversion (calculating offset / width), reserved / read-only bit normalization and mask accumulation, reset bit string accumulation, and backfilling register-level global attributes.

[0045] [Product Formation Layer] The product generation layer is used to derive multiple hardware implementations from the same IR (such as RTL, RALF), convert between multiple document formats (such as Word, Excel), and backfill register specification documents.

[0046] Specifically, the product generation layer also needs to utilize the parameterized register primitive library to achieve the aforementioned derivation, conversion, and refeeding transformations. The parameterized register primitive library stores register primitive templates corresponding to each type of register.

[0047] Taking RTL generation as an example, the register primitive template provides register primitives for each register, including field access types. Therefore, during RTL generation, the corresponding register primitive template can be matched based on the field access types of the structured text. Then, an initial RTL model is instantiated based on the register primitive template, accumulating address decoding logic and read data multiplexing logic (by masking read-only / reserved bits with a read mask `rd_bit_mask` and performing OR operations to combine them). Read-only fields are directly connected to input ports, and fields with user write interfaces are connected to a custom write bus. Finally, through the field mapping relationship between the structured text recorded in the IR and the RTL model, the specification semantics of the structured text are mapped to the initial RTL model, resulting in the final RTL model.

[0048] It should be noted that users can utilize an artificial intelligence agent (AI Agent) to perform the aforementioned derivation, conversion, and refeeding transformations. For example, a user can input natural language commands into the AI ​​Agent, which will then parse these commands. Upon identifying register attributes or bit field parameters that need to be changed, the AI ​​Agent can automatically modify the structured text and automatically generate supporting hardware and software products (such as hardware transfer-level code, verification models, and register planning documents in the second format).

[0049] The software system described above also configures interface timing relationships. The _reg.sv file generated by the product generation layer exposes itself to a standard bus slave. The front-end bus interface of the parsing front-end layer adopts a decoupled design, and internally it is uniformly mapped to standard static SRAM read / write timing. By replacing the top-level wrapper module or template, it can seamlessly adapt to different system buses such as APB and AHB. This example uses the APB bus to illustrate the internal signal mapping and timing.

[0050] 1. Bus-side interface mapping and read pipeline timing The two parsing entry points of the parsing front-end layer map the APB signal into an internal unified read / write timing signal: reg_wr = pwrite&penable / / Write enabled reg_rd = !pwrite&psel / / Read is valid reg_cs = psel / / Piece selection reg_addr = paddr; reg_wdat = pwdata In addition, the read path employs a two-stage register pipeline to meet bus timing and multiplexing convergence requirements: (1) Combine to generate reg_rdat: reg_offset_ of each register <addr>Hit signal × (reg_dat_ <addr>The _w&rd_bit_mask) bitwise OR merge; read-only / reserved bits are masked by the read mask rd_bit_mask to ensure that the read is certain.

[0051] (2) First level reg_rvalid = reg_rd®_cs generates o_reg_rvalid in one step; (3) In the second stage, when reg_rvalid is valid, reg_rdat is latched into o_reg_rdat; otherwise, it is cleared to zero; prdata = o_reg_rdat.

[0052] Timing considerations: When a read request selects data in a given combination, the output is valid in the next combination, avoiding long combination chains being directly connected to the bus.

[0053] 2. Clock Gating (ICG) and Low-Power Timing The LOW_POWER parameter allows for two options in generate: when enabled, it inserts the integrated clock gating st_cg, with reg_cs enabled and dft_mode enabled for scanning, and reg_clk is only enabled when accessed; when disabled, reg_clk passes through pclk. This gating occurs at the root of the register clock and is transparent to all downstream register primitives.

[0054] 3. DFT scan reset timing When -dft is enabled, the output of each field is selected from two options based on dft_mode: assign o_r_ <name>= dft_mode ?<scan_val> : reg_dat_w[....

[0055] The scan_val parameter comes from the scan field of the IR (In-Reference Information Center). If it is explicitly specified in the documentation using the function value / scan value syntax (e.g., 0x1 / 0x0), then the two are independent; otherwise, for fields whose names contain clken, _rstn, or _rst_n, the scan value is automatically set to 1 (to ensure that the clock is on and the reset is released in scan mode), and the rest are set to the function reset value. This automatic derivation avoids the need for manual input of scan safety values ​​one by one.

[0056] 4. User-defined write interface timing (W1S / W1C / WDP and RWSC) For W1C / W1S / WDP type fields, in addition to the bus write port, an additional interface is provided. <name>_cust_wr (write enable, high effective single tick) and <name>_cust_wdat (write data). The primitive reg_wdp is instantiated bitwise internally, with the following priority and behavior: W1C: Bus write and i_dat[i]=1 → clear this bit to 0; otherwise, when cust_wr is executed, it is directly loaded by cust_wdat (hardware set).

[0057] W1S: cust_wr load priority; bus write and i_dat[i]=1 → set to 1.

[0058] WDP: Bus write loads i_dat on wr_en; otherwise loads cust_wdat on cust_wr.

[0059] This enables dual-port updates of the same status bit by both the "software write side" and the "hardware event write side," which is the standard timing for scenarios such as interrupt status bits. In -mb multi-bit mode, cust_wr is expanded into an array with the same width as the field, supporting independent hardware writes bit by bit.

[0060] RWSC signal packing (register level): If the global access type of the register is set to RWSC, the parsing layer no longer breaks down the ports by field when generating RTL, but instead generates a complete [31:0] wide bus port and directly assigns it to o_r_<reg_name> Or by i_<reg_name> Driver-driven. This avoids the cumbersome bit-by-bit splicing operations when connecting upper-level modules.

[0061] 5. Cross-clock domain pulse synchronization and reset domain WTM / WPM: reg_wp converts the "write to this address" event into a single-pulse; reg_wm converts the write event into a level toggle and triggers it through a SYNC_FLAG_DLY stage trigger chain for edge detection in the destination clock domain, enabling a secure handshake across clock domains.

[0062] Multiple reset domains: The IR domain is processed via reg_rstn[ <domain>Select the reset domain to which each register belongs; the top-level presetn is a vector of [max_domain:0], and the bit width is automatically determined by process_document / parse_excel during parsing by calculating max_domain.

[0063] After introducing the software system, the following describes the relevant method implementation examples.

[0064] Please refer to Figure 2 , Figure 2 A flowchart illustrating a collaborative method for register specification documentation, provided as an exemplary embodiment of this specification, the method comprising: Step 210: Obtain at least two register specification documents in the first format corresponding to the same register; Step 220: Parse and extract the specification semantics of the register specification document and generate standardized structured text; wherein, the structured text is hierarchically divided and arranged in lines according to registers and bit fields; Step 230: Use the version control system to merge the structured text at the line level to obtain the latest merged structured text; Step 240: Parse the latest structured text and reverse-construct to generate a register specification document in a second format that includes the layout style.

[0065] The collaborative method for register specification documents provided in this application converts the original binary first-format register specification documents into standardized structured text that supports line-level merging. Since structured text supports line-level merging, it can be merged into the latest structured text using a version control system, and then reconstructed in reverse to generate a second-format register specification document containing formatting styles. This solves the problem that binary format register specification documents cannot be merged at the line level, thus preventing collaborative modification of the same register specification document.

[0066] In one exemplary embodiment, the process of parsing the register specification document may further include: The error-prone and highly regular specification semantics in the register specification document are derived to obtain the corresponding specification semantics.

[0067] In this embodiment, during the parsing phase, deterministic automatic derivation is performed on several error-prone and highly regular pieces of information, so that engineers only need to fill in the minimum necessary information, reducing manual input errors.

[0068] In one derivation method, the derivation of error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics includes: Obtain the register address from the parsed register specification document, and verify whether the register address is less than or equal to the previous register address; If the register address is less than or equal to the previous register address, then the previous register address is incremented by a first value to obtain the corrected register address, and the register address in the register specification document is set to the corrected register address.

[0069] This embodiment provides a derivation method based on automatic address arrangement. When filling in the register address (except for the first one), 0 can be left or left blank. In this way, if the register address is less than or equal to the previous register address during parsing, "the previous register address + 4" (i.e., the first value is 4) will be automatically taken, avoiding overlap or misalignment caused by manually calculating the offset one by one.

[0070] In another derivation method, the derivation of the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics includes: Obtain the bit width information of each field in the parsed register specification document, and verify whether the sum of the bit width information of each field is equal to the second value; If the sum of the bit width information of any field is not equal to the second value, an error will be reported and the parsing will be exited.

[0071] This embodiment provides a derivation method for automatic calculation and verification of bit width. The width and offset are calculated from the bit width information bits (high:low) through range parsing. At the end of the register, it is verified that the sum of the bit widths of each field must be 32 (i.e. the second value is 32). Otherwise, an error is reported and the process is exited to prevent omissions and overlaps.

[0072] In another derivation method, the derivation of the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics includes: Obtain all fields from the parsed register specification document, the double reset value for each field, and an indication flag indicating whether the double reset is executed independently; wherein, the double reset value includes a function reset value and a scan reset value; If the indicator flag indicates non-independent execution, then for target fields whose names contain clken, _rstn, or _rst_n, the scan reset value of the target field is assigned to 1, and the scan reset values ​​of other fields besides the target field are assigned to their respective function reset values.

[0073] This embodiment provides a method for automatically deriving scan reset values. As described in the aforementioned DFT scan reset timing, scan safety values ​​are automatically assigned to fields of type clken / _rstn / _rst_n, eliminating the need for manual entry of DFT reset values ​​item by item.

[0074] In another derivation method, the derivation of the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics includes: Obtain the read mask field from the parsed register specification document, set the values ​​of reserved and write-only bits to 0, and set the values ​​of other read mask fields to 1.

[0075] This embodiment provides a derivation method for automatically generating read masks, setting the Reserved and write-only bits to 0 and the rest to 1, and finally synthesizing a register-level rd_bit_mask to ensure that undefined bits return a definite value when reading.

[0076] Another derivation method also provides an automatic ID register generation method for tracking and verification. After parsing all registers, it can automatically count the total number of registers and the maximum boundary of the address arrangement, and automatically insert a Dummy ID register at the end, which is then fixed into the RTL for the software system to read at runtime to verify the matching of hardware register versions.

[0077] In one exemplary embodiment, step 240, which parses the latest structured text and reverse-reconstructs it to generate a second format uniform register specification document containing typography styles, may include: The specification semantics of the latest structured text are analyzed, and pure typesetting attributes are filtered out. During reverse reconstruction, the specification semantics are injected into a unified typesetting style template to generate a second-format unified register specification document; wherein, the unified typesetting style template is one of a variety of templates specified in the full version or release version.

[0078] This application provides a document style standardization and reflow method. During the reverse reconstruction of a second-format unified register specification document, the output generation layer actively standardizes the layout style. That is, pure layout attributes such as fonts, colors, backgrounds, and images are not included in the IR (Integrated Reflow Object). During reconstruction, the document is reflowed according to a unified standard layout template. In this way, a specification document whose format has been artificially altered can be standardized into a unified standard register specification document with a single click. Furthermore, this unified layout template supports multiple template versions, including custom full versions and release versions, improving layout flexibility.

[0079] In one exemplary embodiment, based on the above-described collaborative method for register specification files, the following automated iterative steps based on artificial intelligence (AI) may also be included: Receive natural language input commands from the user; The artificial intelligence agent (AI Agent) is used to parse the natural language requirement instructions and identify the register attributes or bit field parameters that need to be changed. The AI ​​agent automatically modifies the latest structured text and triggers an automated generation process downstream, generating the corresponding hardware transmission-level code, verification model, and register specification document in the second format with one click.

[0080] In this embodiment, when multiple users concurrently modify the same register specification file, each user only needs to interact with the AI ​​Agent. For example, by inputting a natural language command (describing the modifications to the register specification file) into the AI ​​Agent, the AI ​​Agent can automatically modify the latest structured text corresponding to the register specification file and simultaneously trigger the downstream automated generation process. Details of this automated generation process can be found later. Figure 3 The illustrated embodiment, for example, can generate, with a single click, the accompanying hardware transport-level (RTL) code or model, verification model, and register specification documents in the second format. Thus, leveraging the automated execution capabilities provided by artificial intelligence can further reduce the amount of work required from the user, thereby improving automation and work efficiency.

[0081] The following is a reference. Figure 3 , Figure 3 A flowchart illustrating a method for converting register specification documents, provided as an exemplary embodiment of this specification, the method comprising: Step 310: The various document formats of the register specification document are uniformly parsed into an intermediate representation dictionary; wherein, the intermediate representation dictionary records the field mapping relationship between the standardized structured text and the various document formats, as well as the field mapping relationship between the structured text and the hardware implementation corresponding model; the structured text is hierarchically divided and arranged in lines according to registers and bit fields; Step 320: Perform at least one of the following transformation functions based on the intermediate representation dictionary: Based on the intermediate representation dictionary, the corresponding model is generated using hardware implementation. Perform mutual conversion between multiple document formats based on the intermediate representation dictionary; Based on the intermediate representation dictionary, the modified specification semantics are fed back into the register specification document, triggered by the modified specification semantics of the structured text.

[0082] The register specification document conversion method provided in this application unifies the parsing of various register specification document formats into an intermediate representation dictionary. Since this intermediate representation dictionary records the field mapping relationships between standardized structured text and the various document formats, as well as the field mapping relationships between the structured text and the corresponding hardware implementation models, it supports one-click derivation downwards for the corresponding hardware implementation models (such as RTL / RALF), and also supports upwards for mutual conversion between multiple document formats and lossless round-trip reconstruction of specification semantics (i.e., model modification triggers the re-feedback of modified specification semantics into the register specification document). This solves the problems of existing document-driven unidirectional generation tools, which only perform unidirectional conversions and cannot convert between various register specification document formats.

[0083] In an exemplary embodiment, when the model is a register-transfer-level (RTL) model, the step of generating the corresponding model in hardware based on the intermediate representation dictionary includes: Based on the field access type of the structured text, a register primitive template corresponding to the field access type is matched from the parameterized register primitive library, and an initial register transfer level model is instantiated according to the register primitive template. Based on the field mapping relationship between the structured text recorded in the intermediate representation dictionary and the register-transfer level model, the specification semantics of the structured text are mapped to the initial register-transfer level model to obtain the final register-transfer level model.

[0084] As described in the previous software system, the product generation layer, which generates models corresponding to the hardware implementation, also requires the use of a parameterized register primitive library. The parameterized register primitive library stores register primitive templates corresponding to each type of register.

[0085] Taking RTL generation as an example, the register primitive template provides register primitives for each register, including field access types. Therefore, during RTL generation, the corresponding register primitive template can be matched based on the field access types of the structured text. Then, an initial RTL model is instantiated based on the register primitive template, accumulating address decoding logic and read data multiplexing logic (by masking read-only / reserved bits with a read mask `rd_bit_mask` and performing OR operations to combine them). Read-only fields are directly connected to input ports, and fields with user write interfaces are connected to a custom write bus. Finally, through the field mapping relationship between the structured text recorded in the IR and the RTL model, the specification semantics of the structured text are mapped to the initial RTL model, resulting in the final RTL model.

[0086] In one exemplary embodiment, the specification semantics of the structured text includes a reset value field that supports writing macros and identifiers; The step of mapping the specification semantics of the structured text to the initial register-transfer level model includes: Obtain the reset value field of macros and identifiers contained in the specification semantics of the structured text, and write the macros and identifiers into the DEF_VAL field of the initial register transfer level model.

[0087] In this embodiment, the reset value in the specification semantics supports pass-through mapping of macros and parameters to the RTL model and is automatically declared in the DEF_VAL field. Therefore, the reset value can be configured at instantiation time without changing the specification document or RTL model, adapting to the reset differences of the same register under different chip configurations.

[0088] In an exemplary embodiment, the structured text includes software write ports for W1S (write-1 to clear), W1C (write-1 to set), and WDP (normal load), as well as hardware write ports for cust_wr (write enable, active-high single tick) and cust_wdat (write data). The timing sequence for the dual-port update of the same status bit by the software interface and the hardware write port includes: If W1S triggers a write event, and the i-th bit of the write data of the W1S write event is 1, then the i-th bit is set to 0 and written to the status bit; if W1S does not trigger a write event, then the cust_wr triggers the cust_wdat write event, and the write data of the cust_wdat write event is written to the status bit. If both W1C and cust_wdat trigger write events simultaneously, the write data of the cust_wdat write event is written to the status bit; if only W1S triggers a write event, and the i-th bit of the write data of the W1S write event is 1, the write data is set to 1 and then written to the status bit. If the bus signal wr_en is valid, the write data of the cust_wdat write event is written to the status bit. If the bus signal wr_en is invalid, the cust_wr triggers the cust_wdat write event, and the write data of the cust_wdat write event is written to the status bit.

[0089] In this embodiment, for software write ports such as W1C / W1S / WDP, and hardware write ports such as cust_wr and ust_wdat, when they trigger write events for the same status bit, the relevant data update priorities and specific behaviors are defined by the dual-port update timing provided above, thereby preventing the status bit data from being accidentally overwritten.

[0090] This code / document is a specification for register RTL (Register Transfer Level) design. It solves the arbitration and data merging problems when multiple master devices (external bus and internal logic) access the same register. In particular, it defines strict bit-level operation masks and priority rules for special attribute registers (such as W1C and W1S) to prevent hardware state from being accidentally overwritten.

[0091] In practical applications, when a signal is transmitted from one clock domain to another clock domain with a different frequency or phase, metastability is very likely to occur, leading to data sampling errors.

[0092] In view of this, in an exemplary embodiment, when the write event faces crossing from the source clock domain to the target clock domain, the write event in the source clock domain is synchronized in the target clock domain using the Write Toggle Method (WTM) or the Write Pulse Method (WPM). The pulse synchronization method includes converting the write event of the source clock domain into a single clock cycle pulse signal (this is typically used for fast response within the source clock domain, or in conjunction with a specific pulse synchronizer). The level-flipping method includes: converting the write event in the source clock domain into a level-flipping (Toggle) signal, and having the level-flipping signal tapped by a SYNC_FLAG_DLY stage flip-flop (i.e., a classic "two-stage flip-flop synchronizer") (this design can greatly reduce the probability of metastability propagation, allowing the signal to stabilize in the target clock domain), thus obtaining a stable signal in the target clock domain; so that the target clock domain can identify the write event in the source clock domain by performing edge detection on the stable signal (thereby achieving secure cross-clock domain handshake).

[0093] The above-mentioned level-toggle synchronization mechanism can effectively solve the fatal metastability problem in cross-clock domain communication.

[0094] After introducing the methods of exemplary embodiments of this specification, the apparatus, electronic devices, and computer-readable storage media of exemplary embodiments of this specification will now be described.

[0095] In an exemplary embodiment of this specification, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor implements the method described above by executing the executable instructions.

[0096] Figure 4 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment. Please refer to... Figure 4 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor reading the corresponding computer program from non-volatile memory into memory and then running it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0097] Please refer to Figure 5 In one software implementation, a collaborative apparatus for register specification documents is provided, the apparatus comprising: Acquire unit 510 to acquire at least two register specification documents of the first format corresponding to the same register; The generation unit 520 parses and extracts the specification semantics of the register specification document and generates standardized structured text; wherein, the structured text is hierarchically divided and arranged in lines according to registers and bit fields; Merging unit 530 uses a version control system to merge the structured text at the line level to obtain the latest merged structured text. Collaboration unit 540 parses the latest structured text and reverse-constructs it to generate a register specification document in a second format that includes the typesetting style.

[0098] Optionally, during the process of parsing the register specification document, the generation unit 520 is also used to deduce the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics.

[0099] Optionally, the generation unit 520 derives the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics, further including: The address derivation subunit obtains the register address from the parsed register specification document and verifies whether the register address is less than or equal to the previous register address. If the register address is less than or equal to the previous register address, the previous register address is incremented by a first value to obtain the corrected register address, and the register address in the register specification document is set to the corrected register address.

[0100] Optionally, the generation unit 520 derives the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics, further including: The bit width verification subunit obtains the bit width information of each field in the parsed register specification document and verifies whether the sum of the bit width information of each field is equal to the second value; if the sum of the bit width information of any field is not equal to the second value, an error is reported and the parsing is exited.

[0101] Optionally, the generation unit 520 derives the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics, further including: The reset value derivation subunit obtains all fields in the parsed register specification document, the double reset value of each field, and an indication flag indicating whether the double reset is executed independently; wherein, the double reset value includes a functional reset value and a scan reset value; if the indication flag indicates that it is not executed independently, then for target fields whose names contain clken, _rstn, or _rst_n, the scan reset value of the target field is set to 1, and the scan reset values ​​of other fields other than the target field are set to their respective functional reset values.

[0102] Optionally, the generation unit 520 derives the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics, further including: The read mask derivation subunit obtains the read mask field from the parsed register specification document, sets the value of the target field containing "reserved" and "write-only" to 0, and sets the value of other read mask fields other than the target field to 1.

[0103] Optionally, the collaborative unit further parses the specification semantics of the latest structured text and filters out pure typesetting attributes; during reverse reconstruction, the specification semantics are injected into a unified typesetting style template to generate a second-format unified register specification document; wherein, the unified typesetting style template is one of a variety of templates in the full version or the release version.

[0104] Optionally, the collaborative device for the register specification document further includes an automation unit, which is used to: receive natural language requirement instructions input by the user; use an artificial intelligence agent to parse the natural language requirement instructions and identify the register attributes or bit field parameters that need to be changed; automatically modify the corresponding latest structured text by the artificial intelligence agent and trigger an automated generation process downstream to simultaneously generate the corresponding hardware transfer-level code, verification model, and register planning document in the second format.

[0105] Please refer to Figure 6 In one software implementation, a register specification document conversion apparatus is provided, the apparatus comprising: The parsing unit 610 parses the various document formats of the register specification document into an intermediate representation dictionary; wherein, the intermediate representation dictionary records the field mapping relationship between the standardized structured text and the various document formats, as well as the field mapping relationship between the structured text and the hardware implementation corresponding model; the structured text is hierarchically divided and arranged in lines according to registers and bit fields; The conversion unit 620 performs at least one of the following conversion functions based on the intermediate representation dictionary: generating a model corresponding to the hardware implementation based on the intermediate representation dictionary; performing mutual conversion between multiple document formats based on the intermediate representation dictionary; and performing a modified specification semantic backfill register specification document triggered by the modified specification semantic of the structured text.

[0106] Optionally, when the model is a register-transfer level model, the conversion unit 620 generates the corresponding hardware implementation model based on the intermediate representation dictionary, including: The instantiation subunit, based on the field access type of the structured text, matches the register primitive template corresponding to the field access type from the parameterized register primitive library, and instantiates an initial register transfer level model according to the register primitive template. The mapping subunit, based on the field mapping relationship between the structured text recorded in the intermediate representation dictionary and the register-transfer level model, maps the specification semantics of the structured text to the initial register-transfer level model to obtain the final register-transfer level model.

[0107] Optionally, the specification semantics of the structured text includes a reset value field, which supports writing macros and identifiers; The mapping subunit maps the specification semantics of the structured text to the initial register-transfer level model, including: Obtain the reset value field of macros and identifiers contained in the specification semantics of the structured text, and write the macros and identifiers into the DEF_VAL field of the initial register transfer level model.

[0108] Optionally, the structured text includes software write ports for W1S, W1C, and WDP, as well as hardware write ports for cust_wr and cust_wdat; The software write port and the hardware write port update the dual-port update timing of the same status bit through the update subunit; The update subunit is configured to perform at least one of the following: If W1S triggers a write event, and the i-th bit of the write data of the W1S write event is 1, then the i-th bit is set to 0 and written to the status bit; if W1S does not trigger a write event, then the cust_wr triggers the cust_wdat write event, and the write data of the cust_wdat write event is written to the status bit. If both W1C and cust_wdat trigger write events simultaneously, the write data of the cust_wdat write event is written to the status bit; if only W1S triggers a write event, and the i-th bit of the write data of the W1S write event is 1, the write data is set to 1 and then written to the status bit. If the bus signal wr_en is valid, the write data of the cust_wdat write event is written to the status bit. If the bus signal wr_en is invalid, the cust_wr triggers the cust_wdat write event, and the write data of the cust_wdat write event is written to the status bit.

[0109] Optionally, the device further includes: The synchronization subunit, when the write event faces crossing from the source clock domain to the target clock domain, uses a level-flipping method or a pulse synchronization method to synchronize the write event in the source clock domain under the target clock domain; The pulse synchronization method includes converting the write event of the source clock domain into a pulse signal of one clock cycle. The level-flipping method includes: converting the write event of the source clock domain into a level-flipping signal, and triggering the level-flipping signal by a SYNC_FLAG_DLY level trigger to obtain a stable signal in the target clock domain; so that the target clock domain can identify the write event in the source clock domain by performing edge detection on the stable signal.

[0110] For details on the implementation process of the functions and roles of each module in the above-mentioned device, please refer to the implementation process of the corresponding steps in the above-mentioned register specification document and the coordinated control method of the transfer level code. For relevant parts, please refer to the description of the method implementation method. It will not be repeated here.

[0111] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the units or modules can be selected to achieve the purpose of the solution described in this specification, depending on actual needs. Those skilled in the art can understand and implement this without any inventive effort.

[0112] The systems, devices, modules, or units described in the above embodiments can be implemented by a computer or entity, or by a product with a certain function. A typical implementation device is a computer, which can be a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0113] In exemplary embodiments of this specification, a computer-readable storage medium is also provided, on which computer-readable instructions are stored, which, when executed by a processor, implement the aforementioned method embodiments.

[0114] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0115] Program code contained on a computer-readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RE, or any suitable combination thereof.

[0116] Program code for performing the operations described herein can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0117] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0118] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0119] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms "a," "described," and "the" as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0120] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0121] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the scope of protection of one or more embodiments of this specification.< / domain> < / name> < / name> < / name> < / addr> < / addr> < / bits>

Claims

1. A collaborative method for register specification documents, characterized in that, The method includes: Obtain at least two register specification documents in first format corresponding to the same register; The specification semantics of the register specification document are parsed and extracted to generate standardized structured text; wherein, the structured text is hierarchically divided and arranged in lines according to registers and bit fields; The structured text is merged at the line level using a version control system to obtain the latest merged structured text. The latest structured text is parsed, and a register specification document in a second format, including layout styles, is generated by reverse reconstruction.

2. The method according to claim 1, characterized in that, The process of parsing and extracting the specification semantics of the register specification document also includes: The error-prone and highly regular specification semantics in the register specification document are derived to obtain the corresponding specification semantics.

3. The method according to claim 2, characterized in that, The derivation of the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics includes: Obtain the register address from the parsed register specification document, and verify whether the register address is less than or equal to the previous register address; If the register address is less than or equal to the previous register address, then the previous register address is incremented by a first value to obtain the corrected register address, and the register address in the register specification document is set to the corrected register address.

4. The method according to claim 2, characterized in that, The derivation of the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics includes: Obtain the bit width information of each field in the parsed register specification document, and verify whether the sum of the bit width information of each field is equal to 32; If the sum of the bit width information of any field is not equal to the second value, an error will be reported and the parsing will be exited.

5. The method according to claim 2, characterized in that, The derivation of the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics includes: Obtain all fields from the parsed register specification document, the double reset value for each field, and an indication flag indicating whether the double reset is executed independently; wherein, the double reset value includes a function reset value and a scan reset value; If the indicator flag indicates non-independent execution, then for target fields whose names contain clken, _rstn, or _rst_n, the scan reset value of the target field is set to 1, and the scan reset values ​​of other fields besides the target field are set to their respective function reset values.

6. The method according to claim 2, characterized in that, The derivation of the error-prone and highly regular specification semantics in the register specification document to obtain the corresponding specification semantics includes: Obtain the read mask field from the parsed register specification document. For target fields whose names contain "reserved" and "write-only", set the value of the target field to 0, and set the value of other read mask fields other than the target field to 1.

7. The method according to claim 1, characterized in that, The process of parsing the latest structured text and reconstructing it in reverse to generate a register specification document in a second format including layout styles includes: The specification semantics of the latest structured text are analyzed, and pure typesetting attributes are filtered out. During reverse reconstruction, the specification semantics are injected into a unified typesetting style template to generate a second-format unified register specification document; wherein, the unified typesetting style template is one of a variety of templates specified in the full version or release version.

8. The method according to claim 1, characterized in that, It also includes automated iterative steps based on artificial intelligence: Receive natural language input commands from the user; The artificial intelligence agent is used to parse the natural language requirement instructions and identify the register attributes or bit field parameters that need to be changed. The AI ​​agent automatically modifies the latest structured text and triggers an automated generation process downstream, generating the corresponding hardware transmission-level code, verification model, and register specification document in the second format with one click.

9. A method for converting register specification documents, characterized in that, The method includes: The various document formats of the register specification document are uniformly parsed into an intermediate representation dictionary; wherein, the intermediate representation dictionary records the field mapping relationship between the standardized structured text and the various document formats, as well as the field mapping relationship between the structured text and the corresponding hardware implementation model; the structured text is hierarchically divided and arranged in lines according to registers and bit fields; Perform at least one of the following transformation functions based on the intermediate representation dictionary: Based on the intermediate representation dictionary, the corresponding model is generated using hardware implementation. Perform mutual conversion between multiple document formats based on the intermediate representation dictionary; Based on the intermediate representation dictionary, the modified specification semantics are fed back into the register specification document, triggered by the modified specification semantics of the structured text.

10. The method according to claim 9, characterized in that, When the model is a register-transfer level model, the step of generating the corresponding model based on the intermediate representation dictionary includes: Based on the field access type of the structured text, a register primitive template corresponding to the field access type is matched from the parameterized register primitive library, and an initial register transfer level model is instantiated according to the register primitive template. Based on the field mapping relationship between the structured text recorded in the intermediate representation dictionary and the register-transfer level model, the specification semantics of the structured text are mapped to the initial register-transfer level model to obtain the final register-transfer level model.

11. The method according to claim 10, characterized in that, The specification semantics of the structured text include a reset value field, which supports writing macros and identifiers; The step of mapping the specification semantics of the structured text to the initial register-transfer level model includes: Obtain the reset value field of macros and identifiers contained in the specification semantics of the structured text, and write the macros and identifiers into the DEF_VAL field of the initial register transfer level model.

12. The method according to claim 9, characterized in that, The structured text includes software write ports for W1S, W1C, and WDP, as well as hardware write ports for cust_wr and cust_wdat. The timing sequence for the dual-port update of the same status bit by the software write port and the hardware write port includes: If W1S triggers a write event, and the i-th bit of the write data of the W1S write event is 1, then the i-th bit is set to 0 and written to the status bit; if W1S does not trigger a write event, then the cust_wr triggers the cust_wdat write event, and the write data of the cust_wdat write event is written to the status bit. If both W1C and cust_wdat trigger write events simultaneously, the write data of the cust_wdat write event is written to the status bit; if only W1S triggers a write event, and the i-th bit of the write data of the W1S write event is 1, the write data is set to 1 and then written to the status bit. If the bus signal wr_en is valid, the write data of the cust_wdat write event is written to the status bit. If the bus signal wr_en is invalid, the cust_wr triggers the cust_wdat write event, and the write data of the cust_wdat write event is written to the status bit.

13. The method according to claim 12, characterized in that, When the write event faces a transition from the source clock domain to the target clock domain, the write event in the source clock domain is synchronized under the target clock domain using a level-flipping method or a pulse synchronization method. The pulse synchronization method includes converting the write event of the source clock domain into a pulse signal of one clock cycle. The level-flipping method includes: converting the write event of the source clock domain into a level-flipping signal, and triggering the level-flipping signal by a SYNC_FLAG_DLY level trigger to obtain a stable signal in the target clock domain; so that the target clock domain can identify the write event in the source clock domain by performing edge detection on the stable signal.

14. A collaborative device for register specification documents, characterized in that, The device includes: The acquisition unit acquires at least two register specification documents in first format corresponding to the same register; The generation unit parses and extracts the specification semantics of the register specification document and generates standardized structured text; wherein, the structured text is hierarchically divided and arranged in lines according to registers and bit fields; The merging unit uses a version control system to perform line-level merging on the structured text to obtain the latest merged structured text. The collaborative unit parses the latest structured text and reverse-engineers it to generate a register specification document in a second format that includes the layout style.

15. A register specification document conversion device, characterized in that, The device includes: The parsing unit parses the various document formats of the register specification document into an intermediate representation layer; wherein, the intermediate representation layer is used to generate standardized structured text, and the structured text is hierarchically divided and arranged in lines according to registers and bit fields; The conversion unit performs at least one of the following conversion functions based on the intermediate representation dictionary: generating a model corresponding to the hardware implementation based on the intermediate representation dictionary; performing mutual conversion between multiple document formats based on the intermediate representation dictionary; and performing a modified specification semantic backfill register specification document triggered by the modified specification semantic of the structured text.

16. A computer-readable storage medium, characterized in that, It stores computer-readable instructions thereon, which, when executed by a processor, implement the method as described in any one of claims 1-8 and / or 9-13.

Images