Register transfer level coding generation method and device and computer equipment

Abstract

This disclosure provides a method, apparatus, and computer device for generating register transfer level (RTL) codes. The method includes: parsing a target document according to a target document format to locate a register mapping table for one or more registers in the target document; traversing the contents of each cell in the register mapping table to parse out the names of one or more registers and one or more addresses associated with each register; for each register, searching at a specified location in the target document based on the register name to locate the register bit field description table corresponding to the register, obtaining the register bit field information by traversing the register bit field description table, and associating the bit field information with the register name; forming a register configuration dictionary based on the register name and the addresses and bit field information associated with each register name; and generating a register configuration file and the corresponding RTL code based on the register configuration dictionary.

Description

Technical Field

[0001] This disclosure relates to register transfer level coding, and more particularly to a method for generating register transfer level codes. Background Technology

[0002] In modern integrated circuits, registers are the core timing units of digital circuits and key components that ensure the normal operation of integrated circuits and realize their logical functions. As a fundamental device for temporarily storing binary data and realizing timing synchronization and control, the core function of registers is to complete data writing, storage, and reading operations under the trigger of clock signals, providing precise timing support for internal logic operations and data transmission.

[0003] Register transfer level (RTL) encoding is a core step in the integrated circuit front-end design flow and a key means of defining register functions, timing configurations, and logic descriptions. Using a hardware description language (HDL), RTL encoding standardizes the behavior, data transmission paths, and logical operations of internal registers within an integrated circuit, clarifying port definitions, bit width configurations, clock constraints, reset methods, and connections to other logic units. Through RTL encoding, designers can transform register functional requirements into hardware descriptions that can be recognized by subsequent design flows, bridging the gap between registers and the overall circuit logic. It is a crucial transition from functional design to physical implementation of integrated circuits, directly impacting the efficiency of subsequent design stages and the final chip performance. Summary of the Invention

[0004] This disclosure provides a method for generating register transfer level codes, as well as an apparatus, computer device, computer-readable storage medium, and computer program product for generating register transfer level codes.

[0005] According to one aspect of this disclosure, a method for generating register transfer level encoding is provided. The method includes: parsing a target document according to a target document format to locate a register mapping table for one or more registers in the target document; traversing the contents of each cell in the register mapping table to parse the names of one or more registers and one or more addresses associated with each register from the contents of each cell; for each of the one or more registers, searching at a specified location in the target document based on the register's name to locate the register bit field description table corresponding to the register, obtaining the bit field information of the register by traversing the register bit field description table, and associating the bit field information with the name of the register; forming a register configuration dictionary based on the names of one or more registers and the addresses and bit field information associated with each register's name; and generating a register configuration file and a register transfer level encoding corresponding to the register configuration file based on the register configuration dictionary.

[0006] In some embodiments, parsing a target document according to a target document format to locate a register mapping table of one or more registers in the target document includes: implementing a location rule matching the target document format on the target document; the location rule includes: searching for keywords associated with the register mapping table in response to the target document format being rich text format; searching for key tables associated with the register mapping table in response to the target document format being tabular format; and searching for key structures associated with the register mapping table in response to the target document format being plain text format.

[0007] In some embodiments, traversing the contents of each cell in the register mapping table to parse the names of the one or more registers and one or more addresses associated with each register from the contents of each cell includes: for each cell in the register mapping table, in response to the content of the cell matching a preset base address format, the content of the cell is determined as the base address of the one or more registers; in response to the content of the cell matching a preset name format, the content of the cell is determined as the name of the first register among the one or more registers; in response to the content of the cell matching a preset offset address format, the content of the cell is determined as the offset address of the first register among the one or more registers; wherein the address of the first register is jointly indicated by the base address of the one or more registers and the offset address of the first register.

[0008] In some embodiments, the address of the first register is the sum of the base address of the one or more registers and the offset address of the first register.

[0009] In some embodiments, obtaining the bit field information of a register by traversing the register bit field description table includes: traversing the register bit field description table and determining each column of the register bit field description table from left to right as the bit field name, bit width, reset value, access type, and description of the register, wherein the description indicates the signal clock field corresponding to the bit field of the register.

[0010] In some embodiments, the method further includes: traversing the register configuration dictionary to determine the access type and the signal clock field associated with the bit fields of each of the one or more registers; and performing cross-clock processing on the register transfer level encoding based on the access type and the signal clock field of the bit fields of each register to instantiate and encapsulate a register module including the one or more registers.

[0011] In some embodiments, cross-clock processing of the register transfer-level encoding based on the access type of the bit fields of each register and the signal clock field includes: if the description of the register bit field description table indicates that the signal clock field of the bit field of the register is the same as the module clock field of the register module, the signal generated by the bit field of the register is output from the register module; if the description of the register bit field description table indicates that the signal clock field of the bit field of the register is different from the module clock field of the register module, the signal type corresponding to the signal generated by the bit field of each register is determined based on the access type in the register bit field description table, and cross-clock processing is performed on the signal generated by the bit field of each register based on the signal type.

[0012] In some embodiments, determining the signal type corresponding to the signal generated by the bit field of each register based on the access type in the register bit field description table, and performing cross-clock processing on the signal generated by the bit field of each register based on the signal type includes: determining, based on the access type in the register bit field description table, that the signal type corresponding to the signal generated by the bit field of each register is one of an input level signal, an input pulse signal, an output level signal, or an output pulse signal; synchronizing the output level signal in the signal clock domain in response to determining that the signal type is the output level signal; synchronizing the input level signal in the module clock domain in response to determining that the signal type is the input level signal; converting the output pulse signal into an output level signal in the module clock domain, synchronizing the output level signal in the signal clock domain, and further converting the output level signal into a pulse signal in response to determining that the signal type is the input pulse signal; converting the input pulse signal into an input level signal in the signal clock domain, synchronizing the input level signal in the module clock domain, and further converting the input level signal into a pulse signal in response to determining that the signal type is the input pulse signal.

[0013] In some embodiments, forming a register configuration dictionary based on the names of the one or more registers and the address and bit field information associated with each register name includes: for each of the one or more registers, forming a key-value pair with the register name as the key and the address and bit field information associated with the register name as the value; and forming the register configuration dictionary with the one or more key-value pairs corresponding to the one or more registers.

[0014] According to another aspect of this disclosure, an apparatus for generating register transfer level encoding is provided. The apparatus includes: a register map table locating unit configured to parse a target document according to a target document format to locate a register map table of one or more registers in the target document; a map table information acquisition unit configured to traverse the contents of each cell in the register map table to parse the names of one or more registers and one or more addresses associated with each register from the contents of each cell; a bit field information acquisition unit configured to, for each of the one or more registers, search at a specified location in the target document based on the name of the register to locate the register bit field description table corresponding to the register, obtain the bit field information of the register by traversing the register bit field description table, and associate the bit field information with the name of the register; a register configuration dictionary forming unit configured to form a register configuration dictionary based on the names of one or more registers and the addresses and bit field information associated with the names of each register; and a generation unit configured to generate a register configuration file and a register transfer level encoding corresponding to the register configuration file based on the register configuration dictionary.

[0015] According to another aspect of this disclosure, a computer device is provided, the computer device comprising: at least one processor; and a memory having a computer program stored thereon, wherein the computer program, when executed by the at least one processor, causes the at least one processor to perform the aforementioned method.

[0016] According to another aspect of this disclosure, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, causes the processor to perform the aforementioned method.

[0017] According to another aspect of this disclosure, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, causes the processor to perform the aforementioned method.

[0018] The method disclosed herein defines uniform parsing rules for different target documents, thereby enabling register transfer-level encoding for cross-clock processing based on the obtained register information. This method can replace manual extraction of register configuration information, improving the efficiency and accuracy of register configuration information extraction. Furthermore, this disclosure introduces a process for cross-clock processing of register transfer-level encoding, eliminating the need for manual addition of synchronization logic.

[0019] These and other aspects of this disclosure will be apparent from the embodiments described below, and will be elucidated with reference to the embodiments described below. Attached Figure Description

[0020] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of this disclosure. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0021] Figure 1 An exemplary flowchart illustrating a method for generating register transfer level codes according to embodiments of the present disclosure is shown; Figure 2 An example register mapping table according to an embodiment of the present disclosure is illustrated; Figure 3 An example register bit field description table is illustrated according to an embodiment of the present disclosure; Figure 4 An example block diagram illustrating cross-clock processing of different signals of various registers according to embodiments of the present disclosure is shown; Figure 5 An exemplary flowchart illustrating register transfer-level encoding for generating a configuration status register according to an embodiment of the present disclosure is shown; Figure 6 An exemplary block diagram illustrating an apparatus for generating register transfer level codes according to embodiments of the present disclosure is shown; Figure 7 An exemplary block diagram of a computer device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0022] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0023] In this disclosure, unless otherwise stated, the use of terms such as "first," "second," etc., to describe various elements is not intended to limit the positional, temporal, or importance relationships of these elements; such terms are merely used to distinguish one element from another. In some examples, the first element and the second element may refer to the same instance of that element, while in other cases, based on the context, they may refer to different instances.

[0024] The terminology used in the description of the various examples described in this disclosure is for the purpose of describing particular examples only and is not intended to be limiting. Unless the context explicitly indicates otherwise, an element may be one or more unless the number of elements is specifically limited. As used herein, the term "multiple" means two or more, and the term "based on" should be interpreted as "at least partially based on". Furthermore, the terms "and / or" and "at least one of..." cover any one of the listed items and all possible combinations thereof.

[0025] In the design of very large-scale integrated circuits (VLSI), register-transfer-level encoding (RTA), as a hardware description of the chip's internal registers, directly determines the chip's operational reliability in terms of its generation quality, efficiency, and adaptability. However, existing RTA generation technologies have many shortcomings in adapting to core timing units such as registers, which has become a key bottleneck restricting the efficiency of VLSI design. Specific problems are as follows: First, common register-transfer-level (RTL) encoding generation tools can only generate RTL codes based on manually extracted register configurations, which is prone to human error and inefficient. Because design documents in the integrated circuit field lack a unified format, engineers need to extract key register configuration parameters from design documents in different formats (such as Word and Excel) to generate register configuration files and corresponding RTL codes. This extraction process requires engineers to manually search page by page, visually compare, and copy and paste, making it prone to errors in bit fields, addresses, and access types due to human oversight, leading to problems in the generated RTL codes. For example, if an engineer mistakenly writes the wrong physical address of a register by one bit during manual extraction, the generated RTL code may result in address decoding failure during chip testing, preventing the correct reading of configuration information. This necessitates a comprehensive review of all register address parameters and regeneration and modification of the RTL code.

[0026] Furthermore, register-transfer-level encoding (RTL-LQE) generation tools are ill-suited for multi-clock-domain design scenarios. Common RTL-LQE generation tools can only output basic register logic based on extracted register configurations, failing to consider the typical design scenarios of multiple clock domains coexisting in VLSI, and completely ignoring the synchronization requirements of registers in different clock domains. In related technologies, engineers must manually add synchronizer logic to registers in different clock domains after RTL-LQE generation. However, VLSI often contains dozens or even hundreds of clock domains, each with multiple registers. Manually adding synchronizer logic is not only extremely labor-intensive but also prone to problems such as missed synchronizers and incorrect synchronization logic configuration.

[0027] To address the aforementioned issues, this disclosure proposes a method for generating register transfer-level codes. This method defines unified parsing rules for different target documents to obtain relevant register information, including register names, addresses, and bit field information. Furthermore, based on the obtained register information, register configuration files and corresponding register transfer-level codes can be generated. Additionally, this disclosure can determine the access type and clock domain of each register based on the obtained register information, thereby automatically performing cross-clock processing on the register transfer-level codes during register module encapsulation. The method proposed in this disclosure firstly improves the automation level of register transfer-level code generation, eliminating the previous reliance on manual extraction of register configuration information. Automated extraction is introduced in advance during the register transfer-level code generation process, thereby improving the efficiency and accuracy of register configuration information extraction. Secondly, overcoming the limitation of common tools that can only generate basic register logic, this disclosure can automatically identify the clock attributes of registers during encapsulation and perform cross-clock processing on the register transfer-level codes, significantly reducing the risk of synchronization loss.

[0028] Below, refer to Figure 1 An exemplary flowchart 100 is provided to describe a method for generating register transfer level codes according to embodiments of the present disclosure.

[0029] In step 101, the target document is parsed according to the target document format to locate the register mapping table of one or more registers in the target document.

[0030] At step 102, the contents of each cell in the register map are traversed to parse the names of one or more registers and one or more addresses associated with each register from the contents of each cell.

[0031] In step 103, for each of the one or more registers, a search is performed at a specified location in the target document based on the name of the register to locate the register bit field description table corresponding to the register. The bit field information of the register is obtained by traversing the register bit field description table, and the bit field information is associated with the name of the register.

[0032] In step 104, a register configuration dictionary is formed based on the names of one or more registers and the address and bit field information associated with each register name.

[0033] In step 105, a register configuration file and a register transfer level code corresponding to the register configuration file are generated based on the register configuration dictionary.

[0034] By using the method provided in the embodiments of this disclosure to parse the target document with fixed parsing rules, register configuration information scattered throughout the target document can be automatically associated, thereby realizing a fully automated closed loop from the target document to register transfer-level encoding.

[0035] The above steps will be explained in detail below.

[0036] In step 101, the target document is parsed according to the target document format to locate the register mapping table of one or more registers in the target document.

[0037] Specifically, the target document can be a design document that includes register information such as register names, addresses, and bit field information. This target document provides corresponding register mapping tables for various registers. These register mapping tables include the names and addresses of each register. Therefore, to obtain the names and addresses of the registers, this disclosure first locates the position of the register mapping tables for one or more registers in the target document at step 101.

[0038] To adapt to various document formats with different structures, this disclosure proposes the following location rules for different target document formats. In some embodiments, step 101 may include implementing location rules that match the target document format. These location rules may include: searching for keywords associated with register mapping tables in response to the target document format being rich text; searching for key tables associated with register mapping tables in response to the target document format being table format; and searching for key structures associated with register mapping tables in response to the target document format being plain text.

[0039] In some embodiments, step 101 can be implemented as a pluggable function. For example, functions for parsing documents to locate register maps can be pre-configured for different document formats. In practical applications, a modular replacement approach can be used to dynamically adapt the parsing method to different document formats based on the current target document format. For rich text formats, function modules for parsing rich text documents to locate register maps are pre-configured; for table formats, function modules for parsing table formats to locate register maps are pre-configured; and for plain text formats, function modules for parsing plain text documents to locate register maps are pre-configured. During the actual parsing of the target document, different function modules can be replaced as needed to adapt to the requirements of document parsing. For example, although the function currently implementing step 101 is a function module for rich text formats, if the target document is in table format, this module can be replaced with a function module for table formats. Similarly, the various function modules can be interchanged, thus adapting to various document formats through modular replacement.

[0040] This location rule is determined based on the characteristics of different target document formats: the register map to be located is presented in different forms in different target document formats, therefore it is necessary to search for different content associated with the register map. For example, in response to the target document format being Word, since Word format is a rich text format, keywords associated with the register map can be searched.

[0041] This step is illustrated using the PE register as an example. If information about all PE registers is required, the keyword can be determined as "PE Registers Map". For example, if the target document format is Excel, since Excel is a spreadsheet format, the key table associated with the register map can be searched. Again using the PE register as an example, the key table can be determined as the worksheet titled "PE Registers Map". Similarly, if the target document format is YAML, since YAML is a plain text format, the key structure associated with the register map can be searched. Again using the PE register as an example, the key structure can be determined as the structure with "PE Registers Map" as its root node. Furthermore, the PE Registers Map here is only one example; the corresponding keywords, key tables, and key structures can be determined according to the naming rules in the target document, and this disclosure does not impose any limitations on this. In some examples, the corresponding keywords, key tables, and key structures can also be determined based on preset identifiers (such as register codes) for each register. This positioning rule not only allows for quick identification and location of the register map in the target document but also ensures high compatibility with different target document formats.

[0042] In other embodiments, the localization rule may further include using a pre-trained machine learning model to locate register maps based on contextual semantics and typographic features. In such embodiments, the localization rule may include: extracting text sequences and typographic features (e.g., character spacing, line break distribution, etc.) from the target document; inputting the text sequences and typographic features into a pre-trained machine learning model (e.g., a table detection model or a natural language processing (NLP) model); performing contextual semantic analysis and feature extraction on the document content using the machine learning model, and outputting text blocks, table coordinates, or page number ranges in the target document that belong to the "register map" category, thereby achieving localization.

[0043] At step 102, the contents of each cell in the register map are traversed to parse the names of one or more registers and one or more addresses associated with each register from the contents of each cell.

[0044] The register mapping table in the target document typically includes multiple cells, which are filled with the name and address information associated with the registers. Figure 2 An example register map table 200 according to an embodiment of the present disclosure is illustrated. Figure 2 In this context, the target document is in rich text format, and register mapping table 200 is a register mapping table associated with the PE register, which includes multiple cells. To obtain the name and address associated with the register, in step 102, the contents of each cell in register mapping table 200 are traversed (e.g., line-by-line) to parse the register name and address information from each cell. The parsing rules in this step will be explained in detail below.

[0045] The names and addresses of registers can be obtained directly or indirectly from a register map table. In some embodiments, the register map table can explicitly provide the names and addresses of each register, so the names and addresses of each register can be obtained directly from the register map table. In other embodiments, the register map table can implicitly provide the names and addresses of each register. For example, step 102 may include: for each cell in the register map table, in response to the content of the cell matching a preset base address format, the content of the cell is determined as the base address of one or more registers; in response to the content of the cell matching a preset name format, the content of the cell is determined as the name of a first register among one or more registers; in response to the content of the cell matching a preset offset address format, the content of the cell is determined as the offset address of the first register among one or more registers; wherein the address of the first register is jointly indicated by the base address and the offset address of one or more registers. In other words, this disclosure sets preset name formats, preset base address formats, and preset offset address formats. When traversing the register mapping table 200 line by line, for example, when traversing to the first cell of the first row, if the content of that cell matches the preset format, then the content of that cell can be determined as the register name, base address, or offset address. Moreover, the address of each register can, for example, be indicated by the base address and offset address of one or more registers. For example, the address of a register is the sum of the base addresses of one or more registers and the offset address of that register.

[0046] Let's take register mapping table 200 as an example to illustrate this step. For example, in... Figure 2In the register map 200, each cell is traversed row by row from left to right. The preset base address format can be pre-set as follows: the previous cell's content is "Addr". For each cell in register map 200, for example, when traversing to the second cell of the first row, the previous cell (the first cell of the first row) has the content "Addr", meaning the content of the second cell of the first row matches the preset base address format, then the content of that cell is determined as the base address 0x00_0000_0000 of one or more PE registers. The preset name format can be pre-set as follows: the current cell's content begins with "$", and the previous cell's content is "0x" followed by a number. For each cell in register map 200, for example, when traversing to the second cell of the second row, the cell's content is "$WAIT_PE_IDLE_CFG", and the previous cell's content is "0x000", meaning the content of the second cell of the second row matches the preset name format, then the content of that cell is determined as the register name "$WAIT_PE_IDLE_CFG". The preset offset address format can be set as follows: the current cell content is in the format of "0x" followed by a number, and the next cell content is in the format of starting with "$". For each cell in register mapping table 200, for example, when traversing to the first cell of the second row, the cell content is "0x000", and the next cell content is "$WAIT_PE_IDLE_CFG", that is, the content of the first cell of the second row matches the preset offset address format, then the content of that cell is determined as the offset address "0x000" of register "$WAIT_PE_IDLE_CFG". The address of register "$WAIT_PE_IDLE_CFG" is jointly indicated by the base address of one or more PE registers (0x00_0000_0000) and the offset address of register "$WAIT_PE_IDLE_CFG" (0x000). For example, the address of register "$WAIT_PE_IDLE_CFG" is equal to the sum of the two (0x000 + 0x00_0000_0000). The preset name format, preset base address format, and preset offset address format in this disclosure are merely examples. Those skilled in the art can perform the aforementioned settings and matching of unit content based on the actual formats used, and this disclosure does not impose any limitations on this. By executing the parsing rules in this step, the names of all the registers to be obtained and the addresses associated with each register can be automatically extracted, which is fast and highly accurate. Moreover, by determining the address of each register by calculating the sum of the base address and the offset address by machine, errors that may occur in manual calculation are avoided. In step 103, for each of the one or more registers, a search is performed at a specified location in the target document based on the name of the register to locate the register bit field description table corresponding to the register.Then, the bit field information of the register can be obtained by traversing the register bit field description table, and the bit field information can be associated with the name of the register.

[0047] Since the name of each register has been obtained in step 102, a search can be performed at a specified location in the target document based on the obtained register name to locate the register bit field description table corresponding to that register. This specified location can be the location in the target document where a register bit field description table includes one or more registers. For a rich text format target document, this specified location can be a specific section of the register bit field description table including one or more registers. In the example, the specific section containing the register bit field description table can be determined by searching the register name in the table of contents. Those skilled in the art can set this specified location as needed. If the target document is in rich text format, and the specified location is section 3.1.2, using register $PE_RST_TIME_CFG as an example, a search can be performed at the specified location based on the register name to locate the register bit field description table corresponding to that register. The register bit field description table can include bit field information of a register. Figure 3 An example register bit field information description table 300 according to an embodiment of the present disclosure is illustrated. This register bit field information description table 300 includes bit field information for register $PE_RST_TIME_CFG.

[0048] Then, the bit field information of the register can be obtained by traversing the register bit field description table, and the bit field information can be associated with the name of the register.

[0049] Specifically, obtaining the bit field information of a register by traversing the register bit field description table includes: traversing the register bit field description table and determining each column of the register bit field description table from left to right as the register's bit field name, bit width, reset value, access type, and description, where the description indicates the clock field corresponding to the register's bit field.

[0050] by Figure 3 To illustrate with an example, we will iterate through... Figure 3The register bit field information description table 300 defines the columns of the register bit field description table for register $PE_RST_TIME_CFG from left to right as the field name, bit field, reset value, access type, and description of one or more bit fields in the register. The description indicates the clock field corresponding to the register. The clock field corresponding to $PE_RST_TIME_CFG is not separately defined in the description of the register bit field information description table 300. Those skilled in the art will understand that the register bit field description table can be adjusted according to the needs of the chip design. For example, the information of the clock field corresponding to the register can be defined in the description of the register bit field description table, and this disclosure does not impose any limitations on this.

[0051] After obtaining the bit field information, associate the bit field information with the name of the register. Still using... Figure 3 The example of $PE_RST_TIME_CFG is used for illustration. Since the bit field information of $PE_RST_TIME_CFG is already obtained, this bit field information can be associated with the register name $PE_RST_TIME_CFG, which helps in forming the subsequent register configuration dictionary. The formation of the register configuration dictionary will be explained in conjunction with step 104.

[0052] In step 104, a register configuration dictionary is formed based on the names of one or more registers and the address and bit field information associated with each register name.

[0053] Still with Figure 3 The example of $PE_RST_TIME_CFG illustrates this. In step 102, the name of register $PE_RST_TIME_CFG and its associated address have been obtained. In step 103, the bit field information of register $PE_RST_TIME_CFG has been obtained, and this bit field information has been associated with the register's name; that is, the configuration information associated with this register has been obtained. Similarly, the aforementioned steps can be performed for one or more registers. By aggregating the configuration information associated with all registers, a register configuration dictionary can be formed.

[0054] In some embodiments, step 104 may include: for each of one or more registers, forming a key-value pair using the register's name as the key and the address and bit field information associated with the register's name as the value; and forming a register configuration dictionary using one or more key-value pairs corresponding to one or more registers. That is, the register configuration dictionary includes key-value pairs corresponding to one or more registers. For example, one key-value pair may be: using the name of register $PE_RST_TIME_CFG as the key and the address and bit field information associated with the name of register $PE_RST_TIME_CFG as the value, forming a key-value pair corresponding to register $PE_RST_TIME_CFG. The advantage of using a register configuration dictionary to store register-related information is that this format has a regular structure and is machine-resolvable, allowing direct interface with automated code generation tools and effectively adapting to the automated generation requirements of register transfer-level encoding. In other embodiments, other structured storage formats such as structures and index tables can also be used to implement the register configuration dictionary of this disclosure. Those skilled in the art can determine the specific implementation method of the register dictionary according to the actual situation.

[0055] In step 105, a register configuration file and a register transfer level code corresponding to the register configuration file are generated based on the register configuration dictionary.

[0056] Specifically, a register configuration file is a standardized document describing all register information within the chip, defining register configuration information in a structured format. The format of the register configuration file to be generated can be determined according to actual needs. Register transfer level encoding is an encoded description of the register configuration. Using the register configuration dictionary generated in step 104, the information of each register can be used to generate a register configuration file in the required format. Alternatively, based on the register configuration file, a register transfer level encoding generation tool can be used to generate a register transfer level encoding corresponding to the register configuration file. Exemplary register transfer level encoding generation tools could be the SystemRDL compiler, IP-XACT tool, etc.

[0057] Furthermore, this disclosure can also perform cross-clock processing on register transfer level encoding through the following steps: traversing the register configuration dictionary to determine the access type and signal clock domain associated with the bit fields of each of the one or more registers; and performing cross-clock processing on the register transfer level encoding based on the access type and signal clock domain of the bit fields of each register to instantiate and encapsulate a register module including one or more registers. In some cases, the clock domains corresponding to the signals generated by the bit fields of each register may be different, and the signal generated by at least one bit field may not be in the same clock domain as the register module. In this case, synchronizer logic needs to be added for cross-clock domain signals. Whether the signal generated by the bit field of a register is in the same clock domain as the register module is determined by the signal clock domain in the description of the register bit field description table. By traversing the register configuration dictionary formed through the aforementioned steps, the access type and signal clock domain of the bit fields of each register can be determined, thereby automatically performing cross-clock processing on the register transfer level encoding before instantiating and encapsulating the register module. Using the above method, cross-clock processing of registers can be achieved. Clock attributes can be automatically identified during register module instantiation and encapsulation, and synchronizers can be accurately inserted, reducing the risk of synchronization loss to one in ten thousand.

[0058] Based on the access type and signal clock domain of each register's bit field, cross-clock processing of register transfer-level encoding can include: if the description in the register bit field descriptor table indicates that the signal clock domain of the register's bit field is the same as the module clock domain of the register module, then the signal generated by the bit field of that register is output from the register module; if the description in the register bit field descriptor table indicates that the signal clock domain of the register's bit field is different from the module clock domain of the register module, then based on the access type in the register bit field descriptor table, the signal type corresponding to the signal generated by the bit field of each register is determined, and based on the signal type, cross-clock processing is performed on the signal generated by the bit field of each register. In other words, the register module itself is under the module clock domain, but the signal generated by the bit fields of one or more registers within the register module corresponds to a corresponding signal clock domain, which may be the same as or different from the module clock domain. When the signal clock domain differs from the module clock domain, cross-clock processing is required for the signal generated by the bit field of the register. This can be achieved by first determining whether the signal clock domain of each register's bit field is the same as the module clock domain of the register module through the description in the register bit field information. If they are the same, there is no need to perform cross-clock processing on the signals generated by the bit fields of that register; the register module can directly communicate normally with other modules. If they are different, cross-clock processing needs to be performed on the corresponding signal types according to the different signal types corresponding to the signals generated by the bit fields of each register.

[0059] Based on the access type in the register bit field description table, determining the signal type corresponding to the signal generated by the bit field of each register, and performing cross-clock processing on the signal generated by the bit field of each register based on the signal type, may include: determining, based on the access type in the register bit field description table, that the signal type corresponding to the signal generated by the bit field of each register is one of an input level signal, an input pulse signal, an output level signal, or an output pulse signal; in response to determining that the signal type is an output level signal, synchronously outputting a level signal in the signal clock domain; in response to determining that the signal type is an input level signal, synchronously inputting a level signal in the module clock domain; in response to determining that the signal type is an output pulse signal, converting the output pulse signal into an output level signal in the module clock domain, synchronously outputting a level signal in the signal clock domain, and further converting the output level signal into a pulse signal; in response to determining that the signal type is an input pulse signal, converting the input pulse signal into an input level signal in the signal clock domain, synchronously inputting a level signal in the module clock domain, and further converting the input level signal into a pulse signal.

[0060] Based on the access type in the register bit field description table, determining the signal type corresponding to the signal generated by each register's bit field—whether it's an input level signal, an input pulse signal, an output level signal, or an output pulse signal—can include: if the access type is RWC (Read Write Clear) or W1C (Write 1 to Clear), the register's bit field will generate an input pulse signal; if the access type is RWC, W1C, RW (Read Write), or WO (Write Only), the register's bit field will generate an output level signal; if the access type is RO (Read Only), the register's bit field will generate an input level signal; if the access type is W1TRG (Write 1 Trigger), the register's bit field will generate an output pulse signal. Based on the signal type generated by the register's bit field, it's possible to determine how to synchronize the registers.

[0061] by Figure 4 Let's take an example to illustrate. Figure 4 Example block diagram 400 illustrates cross-clock processing of different signals generated from the bit fields of a register according to embodiments of the present disclosure. Note that... Figure 4 The diagram does not show the case where the signal clock domain of the signal generated by the bit field of the register is the same as the module clock domain of the register module. From Figure 4As can be seen, the register module is located in the module clock domain CLK0, while the input pulse signal, output level signal, input level signal, and output pulse signal generated by the bit fields of one or more registers in the register module are located in the clock domains CLK1-CLK4 respectively. The asynchronous synchronization unit may include asynchronous beat registers or synchronization unit registers, etc., used to synchronize signals across clock domains. The l2p module is the unit that converts level signals into pulse signals, while the p2l module is the unit that converts pulse signals into level signals.

[0062] First, let's explain the case where the register signal is a level signal. Specifically, if the register signal is determined to be an output level signal, then that output level signal is synchronized in the signal clock domain (i.e., CLK2). This is because the signal is used to output the register module, and therefore should be synchronized to the CLK2 signal clock domain before being output. If the register signal is determined to be an input level signal, then that input level signal is synchronized in the module clock domain (i.e., CLK0). Similarly, this is because the signal is used to input the register module, and therefore should be synchronized to the CLK0 module clock domain of that register module before being input.

[0063] Let's further explain the case where the register signal is a pulse signal. The difference between pulse signals and level signals in cross-clock processing is that the pulse signal needs to be converted to a level signal first, and then converted back to a pulse signal in the appropriate clock domain. This is because pulse signals are relatively narrow, and by the time the target sampling edge arrives, the pulse may have already disappeared, making it difficult to capture the pulse signal. Therefore, the pulse signal needs to be converted to a level signal first, synchronized, and then converted back to a pulse signal. Specifically, in response to the register signal being an input pulse signal, the pulse signal is first converted to a level signal in the signal clock domain (i.e., CLK1) using the p2l module, then synchronized in the module clock domain (i.e., CLK0), and finally converted back to a pulse signal using the l2p module. Similarly, in response to the register signal being an output pulse signal, the pulse signal is first converted to a level signal in the module clock domain (i.e., CLK0) using the p2l module, then synchronized in the signal clock domain (i.e., CLK4), and finally converted back to a pulse signal using the l2p module.

[0064] By performing the aforementioned cross-clock processing steps through register transfer-level encoding, a synchronizer logic is added to the traditional basic configuration of registers. This reduces the tediousness of manual synchronization in subsequent top-level designs and improves the synchronization accuracy.

[0065] Below, for reference Figure 5 An exemplary flowchart 500 is provided to describe the register transfer-level encoding of the configuration status register according to embodiments of the present disclosure. It should be noted that... Figure 5 Using the Configuration Status Registers (CSR) as an example, the methods provided in this disclosure are not limited to the CSR and can also be used on other address-based registers. Figure 5 In the example scenario, the target document is a Word document, and the goal is to obtain the register configuration information of the CSR.

[0066] At position 501, the target document is parsed based on its Word format to locate one or more CSR mapping tables within the target document.

[0067] At position 502, the contents of each cell in the CSR mapping table are traversed to parse the CSR name and the address associated with each CSR from the contents of each cell. This process is repeated cell by cell in the CSR mapping table until position 503, at which point the CSR mapping table has been completely traversed.

[0068] At position 504, for each CSR, a search is performed at a specified location in the Word document based on the name of the CSR to locate the corresponding CSR bit field description table. The bit field information of the CSR, including the bit field name and description, is obtained by traversing the CSR description table. The bit field information of the CSR is then associated with the name of the CSR.

[0069] At position 505, determine whether the CSR bit field descriptor table has been completely traversed.

[0070] At position 506, a register configuration dictionary is formed based on the obtained CSR names and the address and bit field information associated with each CSR name.

[0071] At point 507, a register configuration file in YAML format is generated based on the register configuration dictionary. At point 508, an external tool is invoked to generate the CSR RTL encoding corresponding to the register configuration file.

[0072] At position 509, based on the access type of the bit fields of each CSR and the signal clock field, the RTL encoding is processed across clocks until the bit field description tables of each CSR are traversed at position 510.

[0073] At position 511, the CSR module is instantiated and encapsulated.

[0074] Below, for reference Figure 6 This invention relates to an apparatus 600 for generating register transfer level codes according to embodiments of the present disclosure.

[0075] The apparatus 600 includes a register mapping table locating unit 601, a mapping table information acquisition unit 602, a bit field information acquisition unit 603, a register configuration dictionary forming unit 604, and a generation unit 605. In addition to these units, the apparatus 600 may also include other components; however, since these components are not relevant to the content of this embodiment, their illustrations and descriptions are omitted here. Furthermore, the specific details of the operations performed by the apparatus 600 according to this embodiment are consistent with those described above. Figure 1 The details described are the same, so repeated descriptions of the same details are omitted here to avoid repetition.

[0076] The apparatus 600 includes a register map locator unit 601, configured to parse a target document according to a target document format to locate a register map of one or more registers in the target document.

[0077] The device 600 includes a mapping table information acquisition unit 602, which is configured to traverse the contents of each cell in the register mapping table to parse the names of one or more registers and one or more addresses associated with each register from the contents of each cell.

[0078] The apparatus 600 includes a bit field information acquisition unit 603, configured to, for each of one or more registers, search at a specified location in a target document based on the name of the register to locate the register bit field description table corresponding to the register, obtain the bit field information of the register by traversing the register bit field description table, and associate the bit field information with the name of the register.

[0079] The device 600 includes a register configuration dictionary forming unit 604, configured to form a register configuration dictionary based on the names of one or more registers and address and bit field information associated with the names of each register.

[0080] The apparatus 600 includes a generation unit 605 configured to generate a register configuration file and a register transfer level code corresponding to the register configuration file based on a register configuration dictionary.

[0081] Below, refer to Figure 7 To describe a computer device 700 according to embodiments of the present disclosure, Figure 7 An exemplary block diagram of a computer device 700 according to an embodiment of the present disclosure is shown.

[0082] Computer device 700 can be used as one or more components for implementing the systems and methods described above. Computer device 700 may include a bus 702 or other communication mechanism for communicating information, and one or more processors 704 coupled to the bus 702 for processing information. Processor 704 may be, for example, one or more general-purpose microprocessors.

[0083] Computer device 700 may also include main memory 706, such as random access memory (RAM), cache, and / or other dynamic storage devices, coupled to bus 702, for storing information and instructions to be executed by processor 704. Main memory 706 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 704. Such instructions, when stored in a storage medium accessible to processor 704, can make computer device 700 a special-purpose machine customized to perform the operations specified in the instructions. Main memory 706 may include non-volatile media and / or volatile media. Non-volatile media may include, for example, optical discs or magnetic disks. Volatile media may include dynamic memory. Common media formats may include, for example, floppy disks, collapsible disks, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, CD-ROMs (read-only optical disc drives), any other optical data storage media, any physical media with a perforated arrangement, RAM (random access memory), DRAM (dynamic random access memory), PROM (programmable read-only memory) and EPROM (erasable programmable read-only memory), FLASH-EPROM (fast erase programmable read-only memory), NVRAM (non-volatile random access memory), any other memory chips or tape cartridges, or network versions of the above.

[0084] Computer device 700 may implement the techniques described herein using custom hardwired logic, one or more ASICs (Application-Specific Integrated Circuits) or FPGAs (Field-Programmable Gate Arrays), firmware, and / or program logic, which, when combined with computer device 700, enable computer device 700 to become a special-purpose machine or to be programmed therein. According to one embodiment, the techniques herein are executed by computer device 700 in response to processor 704 executing one or more sequences of one or more instructions contained in main memory 706. Such instructions may be read into main memory 706 from another storage medium, such as storage device 708. Executing the sequence of instructions contained in main memory 706 causes processor 704 to perform the processing steps described herein. For example, the processes / methods disclosed herein may be implemented by computer program instructions stored in main memory 706. When these instructions are executed by processor 704, they may perform the steps shown in the corresponding figures and as described above. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0085] Computer device 700 also includes a network interface 710 coupled to bus 702. Network interface 710 can provide bidirectional data communication coupled to one or more network links connected to one or more networks. As another example, network interface 710 can be a local area network (LAN) card to provide data communication connectivity with a compatible LAN (or a WAN component communicating with a WAN (wide area network)). Wireless links can also be implemented.

[0086] The performance of certain operations can be distributed across processors, not just residing within a single machine, but deployed across many machines. In some exemplary embodiments, the processor or the processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other exemplary embodiments, the processor or the processor-implemented engine may be distributed across many geographic locations.

[0087] Each process, method, and algorithm described in the preceding sections can be embodied in a code module executed by one or more computer systems or computer processors including computer hardware, and can be fully or partially automated by them. These processes and algorithms can be implemented, in part or in whole, in a specific application circuit.

[0088] When the functions disclosed herein are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Specific technical solutions (all or part) disclosed herein, or aspects contributing to the prior art, can be embodied in the form of a software product. This software product can be stored in a storage medium and includes instructions to cause a computer device (which may be a personal computer, server, network device, etc.) to perform all or part of the steps of the methods described in the embodiments of this application. The storage medium may include a flash drive, a portable hard drive, ROM, RAM, a magnetic disk, an optical disk, another medium suitable for storing program code, or any combination thereof.

[0089] The embodiments disclosed herein can be implemented via a cloud platform, server, or group of servers that interact with a client. The client can be a terminal device or a client registered by a user on the platform, wherein the terminal device can be a mobile terminal, a personal computer (PC), or any device that can install platform applications.

[0090] The various features and processes described above can be used independently or combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. Furthermore, certain method or process blocks may be omitted in some embodiments. The methods and processes described herein are not limited to any particular order, and associated blocks or states may be executed in other suitable orders. For example, described blocks or states may be executed in a non-specifically disclosed order, or multiple blocks or states may be combined in a single block or state. Exemplary blocks or states may be executed serially, in parallel, or otherwise. Blocks or states may be added to or removed from the disclosed exemplary embodiments. The exemplary systems and components described herein may be configured differently from those described. For example, elements may be added, removed, or rearranged compared to the disclosed exemplary embodiments.

[0091] The various operations of the exemplary methods described herein can be performed at least in part by an algorithm. An algorithm may consist of program code or instructions stored in memory (such as the non-transitory computer-readable storage medium described above). Such an algorithm may include a machine learning algorithm. In some embodiments, the machine learning algorithm may not be explicitly programmed into the computer to perform the function, but may learn from training data to obtain a predictive model for performing that function.

[0092] The various operations of the exemplary methods described herein can be performed at least in part by one or more processors, which are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute the engine of a processor implementation whose operation is to perform one or more of the operations or functions described herein.

[0093] Similarly, the methods described herein can be implemented at least partially by a processor, where a specific processor or one or more processors are examples of hardware. For example, at least some operations of the methods can be performed by one or more processors or an engine implemented by a processor. Furthermore, one or more processors can also run in a “cloud computing” environment or as “Software as a Service” (SaaS) to support the execution of the relevant operations. For example, at least some operations can be performed by a group of computers (as an example of a machine including processors), which can be accessed via a network (e.g., the Internet) and through one or more appropriate interfaces (e.g., application programming interfaces (APIs)).

[0094] The performance of certain operations can be distributed across processors, not just residing within a single machine, but deployed across many machines. In some exemplary embodiments, the processor or the processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other exemplary embodiments, the processor or the processor-implemented engine may be distributed across many geographic locations.

[0095] The present invention describes a computer-readable storage medium on which a computer program is stored, which, when executed by a processor, causes the processor to perform the aforementioned register transfer level encoding generation method.

[0096] The following describes a computer program product according to the present invention, which includes a computer program that, when executed by a processor, causes the processor to perform the aforementioned register transfer level encoding generation method.

[0097] In this specification, multiple instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are described and illustrated as independent operations, one or more individual operations may be performed concurrently, and these operations are not required to be performed in the order shown. Structures and functionalities presented as independent components in the example configuration may be implemented as combined structures or components. Similarly, structures and functionalities presented as individual components may be implemented as independent components. These and other variations, modifications, additions, and improvements are all within the scope of this document.

[0098] As used herein, “or” is inclusive rather than exclusive unless explicitly stated or indicated by context. Furthermore, “and” is both common and individual unless explicitly stated or indicated by context. Moreover, multiple instances may be provided for the resources, operations, or structures described herein as a single example. Furthermore, the boundaries between various resources, operations, engines, and data stores are somewhat arbitrary, and specific operations are illustrated within the context of a particular illustrative configuration. The allocation of other functionalities is conceivable and may fall within the scope of various embodiments of this disclosure. Generally, structures and functionalities presented as independent resources in example configurations may be implemented as combined structures or resources. Similarly, structures and functionalities presented as individual resources may be implemented as independent resources. These and other variations, modifications, additions, and improvements are all within the scope of embodiments of this disclosure. Therefore, this specification and accompanying drawings should be viewed in an illustrative rather than restrictive sense.

[0099] The terms “comprising” or “including” are used to indicate the presence of a subsequently stated feature, but do not preclude the addition of other features. Conditional language, in particular, such as “may,” “can,” or “may,” unless specifically stated or otherwise understood in the context of use, is generally intended to express that certain embodiments include certain features, elements, and / or steps, while other embodiments do not. Therefore, such conditional language generally does not imply that a feature, element, and / or step is necessary in any way for one or more embodiments, or that one or more embodiments must include logic that, with or without user input or prompting, determines whether such features, elements, and / or steps are included in any particular embodiment, or whether they are to be performed in any particular embodiment.

Claims

1. A method for generating register-transfer-level codes, characterized in that, The method includes: Parse the target document according to the target document format to locate the register mapping table of one or more registers in the target document; The contents of each cell in the register mapping table are traversed to parse the contents of each cell to obtain the name of one or more registers and one or more addresses associated with each register. For each of the one or more registers The search is performed at a specified location in the target document based on the register's name to locate the register bit field description table corresponding to that register. The bit field information of the register is obtained by traversing the register bit field description table. Associate the bit field information with the name of the register; A register configuration dictionary is formed based on the names of the one or more registers and the address and bit field information associated with each register name; Based on the register configuration dictionary, a register configuration file and the register transfer level code corresponding to the register configuration file are generated.

2. The method according to claim 1, characterized in that, The register mapping table for parsing the target document according to the target document format to locate one or more registers in the target document includes: Based on the target document format, apply positioning rules that match the target document format to the target document; The positioning rules include: In response to the target document being in rich text format, search for keywords associated with the register mapping table; In response to the target document being in table format, search for key tables associated with the register mapping table; In response to the target document being in plain text format, a search is performed for key structures associated with the register mapping table.

3. The method according to claim 1, characterized in that, Traversing the contents of each cell in the register mapping table to parse the contents of each cell to obtain the name of one or more registers and one or more addresses associated with each register includes: For each cell in the register map table If the content of the unit matches a preset base address format, then the content of the unit is determined as the base address of the one or more registers; If the content of the unit matches a preset name format, then the content of the unit is determined as the name of the first register among the one or more registers; If the content of the unit matches a preset offset address format, then the content of the unit is determined as the offset address of the first register in the one or more registers. The address of the first register is indicated by the base address of the one or more registers and the offset address of the first register.

4. The method according to claim 3, characterized in that, The address of the first register is the sum of the base address of the one or more registers and the offset address of the first register.

5. The method according to claim 1, characterized in that, The bit field information of the register is obtained by traversing the register bit field description table, including: By traversing the register bit field description table, each column of the register bit field description table is determined from left to right as the register's bit field name, bit width, reset value, access type, and description, wherein the description indicates the signal clock field corresponding to the register's bit field.

6. The method according to claim 5, characterized in that, The method further includes: Traverse the register configuration dictionary to determine the access type and signal clock field associated with the bit fields of each of the one or more registers, respectively; Based on the access type of the bit fields of each register and the signal clock field, the register transfer level encoding is processed across clocks to instantiate and encapsulate a register module including one or more registers.

7. The method according to claim 6, characterized in that, Based on the access type of the bit fields of each register and the signal clock field, cross-clock processing of the register transfer-level encoding includes: If the description of the register bit field description table indicates that the signal clock field of the register bit field is the same as the module clock field of the register module, the signal generated by the bit field of the register is output from the register module. If the signal clock field of the register bit field description table is different from the module clock field of the register module, then based on the access type in the register bit field description table, the signal type corresponding to the signal generated by the bit field of each register is determined, and based on the signal type, the signal generated by the bit field of each register is processed across clocks.

8. The method according to claim 7, characterized in that, Based on the access type in the register bit field description table, the signal type corresponding to the signal generated by the bit field of each register is determined, and based on the signal type, cross-clock processing is performed on the signal generated by the bit field of each register, including: Based on the access type in the register bit field description table, determine that the signal type corresponding to the signal generated by the bit field of each register is one of the following: input level signal, input pulse signal, output level signal, or output pulse signal. In response to determining that the signal type is the output level signal, the output level signal is synchronized in the signal clock domain; In response to determining that the signal type is the input level signal, the input level signal is synchronized in the module clock domain; In response to determining that the signal type is the output pulse signal, the output pulse signal is converted into an output level signal in the module clock domain, the output level signal is synchronized in the signal clock domain, and the output level signal is further converted into a pulse signal. In response to determining that the signal type is the input pulse signal, the input pulse signal is converted into an input level signal in the signal clock domain, the input level signal is synchronized in the module clock domain, and the input level signal is further converted into a pulse signal.

9. The method according to any one of claims 1-8, characterized in that, Based on the names of the one or more registers and the address and bit field information associated with each register name, a register configuration dictionary is formed, including: For each of the one or more registers, a key-value pair is formed with the register's name as the key and the address and bit field information associated with the register's name as the value; The register configuration dictionary is formed using one or more key-value pairs corresponding to the one or more registers.

10. An apparatus for generating register-transfer level codes, characterized in that, The device includes: The register mapping table locating unit is configured to parse the target document according to the target document format in order to locate the register mapping table of one or more registers in the target document; The mapping table information acquisition unit is configured to traverse the contents of each cell in the register mapping table to parse the names of the one or more registers and one or more addresses associated with each register from the contents of each cell; The bit field information acquisition unit is configured to, for each of the one or more registers, search at a specified location in the target document based on the name of the register to locate the register bit field description table corresponding to the register, obtain the bit field information of the register by traversing the register bit field description table, and associate the bit field information with the name of the register. The register configuration dictionary forming unit is configured to form a register configuration dictionary based on the names of one or more registers and the address and bit field information associated with each register name. The generation unit is configured to generate a register configuration file and a register transfer level code corresponding to the register configuration file based on the register configuration dictionary.

11. A computer device, characterized in that, The computer device includes: At least one processor; A memory having a computer program stored thereon, wherein, when executed by the at least one processor, the computer program causes the at least one processor to perform the method of any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1-9.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1-9.

Images