Module code generation method and device, equipment and storage medium

Abstract

This invention relates to a module code generation method, apparatus, device, and storage medium. The module code generation method includes: acquiring configuration specification data of a Universal Asynchronous Receiver / Transmitter (UART) module, wherein the configuration specification data characterizes the functional requirements and key parameters of the UART module; drawing a timing waveform diagram containing all variables based on the configuration specification data, wherein the timing waveform diagram visually displays the timing logic relationship of each variable during the reception of a data frame by the UART module; and generating hardware description code for the UART module based on the timing waveform diagram, wherein the code statements included in the hardware description code correspond to the timing logic relationship. The method provided in this application effectively reduces the difficulty of code writing and the logical error rate, and improves design efficiency.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for generating module code. Background Technology

[0002] Currently, in the design flow of the Register Transfer Level (RTL) of Universal Asynchronous Receiver / Transmitter (UART), relevant personnel study the datasheet, rely on experience to conceptualize the internal logic and timing relationships of various variables, directly write RTL code, and then verify the code's functionality through simulation. However, this design flow lacks intermediate design basis, making code writing difficult and logical errors highly concealed. Simulation debugging requires line-by-line checking of the code logic, resulting in low design efficiency. Summary of the Invention

[0003] To address the aforementioned technical problems, this disclosure provides a module code generation method, apparatus, device, and storage medium.

[0004] In a first aspect, embodiments of this disclosure provide a module code generation method, including: Obtain the configuration specification data of the general asynchronous transceiver module, whereby the configuration specification data is used to characterize the functional requirements and key parameters of the general asynchronous transceiver module; Based on the configuration specification data, a timing waveform diagram containing all variables is drawn. The timing waveform diagram visually displays the timing logic relationship of each variable in the process of the general asynchronous transceiver module receiving a frame of data. The hardware description code of the general asynchronous transceiver module is generated based on the timing waveform diagram. The code statements included in the hardware description code correspond to the timing logic relationship.

[0005] Secondly, embodiments of this disclosure provide a module code generation apparatus, comprising: The data acquisition module is used to acquire the configuration specification data of the general asynchronous transceiver module. The configuration specification data is used to characterize the functional requirements and key parameters of the general asynchronous transceiver module. The waveform plotting module is used to plot a time-series waveform containing all variables based on the configuration specification data. The time-series waveform visually displays the temporal logic relationship of each variable during the process of the general asynchronous transceiver module receiving a frame of data. The code generation module is used to generate hardware description code for the general asynchronous transceiver module based on the timing waveform diagram. The code statements included in the hardware description code correspond to the timing logic relationships.

[0006] Thirdly, embodiments of this disclosure provide an electronic device, including: Memory; Processor; and Computer programs; The computer program is stored in memory and configured to be executed by a processor to implement the first aspect of the method described above.

[0007] Fourthly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect above.

[0008] The module code generation method disclosed herein includes: obtaining configuration specification data of a general asynchronous transceiver module (GAT), wherein the configuration specification data characterizes the functional requirements and key parameters of the GTA; plotting a timing waveform diagram containing all variables based on the configuration specification data, wherein the timing waveform diagram visually displays the timing logic relationship of each variable during the reception of a data frame by the GTA; and generating hardware description code for the GTA based on the timing waveform diagram, wherein the code statements included in the hardware description code correspond to the timing logic relationship. The method provided in this application effectively reduces the difficulty of code writing and the logical error rate, and improves design efficiency. Attached Figure Description

[0009] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0010] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A flowchart illustrating a module code generation method provided in an embodiment of this disclosure; Figure 2 A timing waveform diagram provided in an embodiment of this disclosure; Figure 3 A flowchart illustrating another module code generation method provided in this embodiment of the disclosure; Figure 4 This is a schematic diagram of the structure of a module code generation device provided in an embodiment of the present disclosure; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0012] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0013] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0014] Specifically, in digital integrated circuit design, the UART module, as a universal asynchronous transceiver interface, is an indispensable basic communication module in various electronic devices. The reliability and efficiency of its RTL design directly affect the product development cycle. As chip functions become increasingly complex, higher demands are placed on the design precision and development speed of the UART module.

[0015] Currently, the RTL design flow for UART receiver modules is as follows: engineers study the datasheet to understand the functional requirements and key signal timing of the receiver module (e.g., transmit and receive baud rates, data bit formats, etc.), then mentally visualize the internal logic and timing relationships of various variables, directly write the RTL code, and finally verify the code functionality through simulation. Specifically, in related RTL designs, there is a lack of visual representation of the timing relationships of internal intermediate variables. Engineers need to mentally visualize the logical relationships of these intermediate variables, leading to unclear design thinking, and making it easy for logical errors such as clock deviations and missing conditions to occur in the code. It is also difficult to accurately grasp the transition conditions and time nodes of each variable, increasing the difficulty of coding and prolonging the development cycle. Secondly, there is a lack of clear reference standards during simulation debugging, making it difficult to quickly locate problems and requiring significant time and manpower costs. This results in low problem location efficiency and high debugging costs. Furthermore, if problems occur during simulation, the code logic must be checked line by line to locate the root cause of the error, making it difficult to quickly understand the original design logic, leading to high maintenance costs and poor design reusability. In summary, the relevant RTL designs suffer from problems such as unclear design concepts, high coding difficulty, high logical error rate, and long debugging cycles.

[0016] To address the aforementioned technical problems, this disclosure provides a module code generation method. By drawing a simplified waveform diagram containing all variables, the design concept is visualized. This waveform diagram guides RTL code writing, reducing the difficulty of code creation. Subsequent simulation and debugging are performed using this waveform diagram as a reference, forming a standardized closed-loop design process for quickly locating logical errors. It also simplifies later maintenance and modification processes, improves design efficiency, accuracy, and scalability, and reduces labor costs and development cycles. Detailed descriptions are provided through one or more of the following embodiments.

[0017] The module code generation method provided in this disclosure is applicable to module code generation scenarios. This method can be executed by a module code generation device, which can be implemented in software and / or hardware and can be integrated into an electronic device. The electronic device can include, but is not limited to, mobile terminals such as smartphones, laptops, digital radio receivers, personal digital assistants (PDAs), tablet PCs, portable multimedia players (PMPs), in-vehicle terminals (e.g., in-vehicle navigation terminals), wearable devices, etc., as well as fixed terminals such as digital televisions, desktop computers, smart home devices, etc.

[0018] Figure 1 This is a flowchart illustrating a module code generation method provided in an embodiment of the present disclosure, specifically including as follows: Figure 1 The following steps are shown: S101. Obtain the configuration specification data of the general asynchronous transceiver module.

[0019] Among them, the configuration specification data is used to characterize the functional requirements and key parameters of the general asynchronous transceiver module.

[0020] Understandably, obtaining the configuration specification data of the Universal Asynchronous Receiver / Transmitter (UART) module (hereinafter referred to as the receiver module) is crucial. The UART module is a digital circuit unit used to receive asynchronous serial data, and its core function is to recover serial input signals into parallel data. The configuration specification data is obtained by parsing the receiver module's datasheet, which characterizes the module's core functions and key parameters. For example, the core function is to receive serial data, including metastability elimination, baud rate adaptation, data bit acquisition and splicing, and valid data output. Key parameters include clock frequency (e.g., 50MHz), baud rate (e.g., 9500bps), data format (8 data bits), and reset mode (active low). This process transforms the design information, originally scattered throughout the datasheet, into structured input information, providing a clear basis for subsequent waveform plotting and avoiding logical deviations caused by ambiguity in manual interpretation.

[0021] S102. Draw a time-series waveform diagram containing all variables based on the configuration specification data.

[0022] Among them, the timing waveform diagram visually displays the timing logic relationship of each variable in the process of the general asynchronous transceiver module receiving a frame of data.

[0023] Understandably, based on the acquired configuration specification data, a timing waveform diagram containing all variables is drawn, which is a simplified waveform diagram including the input signals, internal variables, and output signals of the receiving module. The timing waveform diagram (hereinafter referred to as the simplified waveform diagram) is a graphical representation with time as the horizontal axis and signal level as the vertical axis, used to visually demonstrate the timing logic relationships between various signals and variables during the receiving module's reception of a complete frame of data. The total variables refer to all internal variables and input / output control signals involved in the signal reception process of the receiving module. The timing logic relationships are reflected in the state transition conditions and timing dependencies between variables. For example, the baud rate counter variable begins to increment after the start bit detection is successful, and a sampling point flag is generated every time it counts to a preset threshold. This sampling point flag triggers the shift data register to sample and concatenate the current serial input bit. The drawn simplified waveform diagram intuitively presents the timing relationships of all variables. Designing based on this waveform diagram clarifies the design concept, avoids logical confusion caused by engineers conceptualizing the code in their minds, reduces the difficulty of code writing, and improves development efficiency.

[0024] Optionally, a time-series waveform diagram containing all variables can be plotted based on the configuration specification data, including: Identify all variables representing the functional requirements of the configuration specification data to be implemented. These variables include input variables, intermediate variables, and output variables. Based on the unit functional logic described in the configuration specification data, determine the timing relationships and logical relationships of each variable. The timing relationships include the transition time, duration, and triggering conditions of each variable under clock drive, while the logical relationships are used to define the output logic of the output variables. Based on the timing and logical relationships of each variable, draw a timing waveform diagram containing all variables. The timing and logical relationships include both timing relationships and logical relationships.

[0025] Understandably, the full set of variables for the functional requirements to be implemented is determined. These full variables include input signals (clk, rst_n, rx), intermediate variables (internal variables: rx1, rx2, rx2_reg, rx_flag, cnt_baud, bit_flag, bit_cnt, shift_data, done_flag), and output signals (po_data, po_flag). The input signals are linear, and the output signals are either linear or register-type. clk, rst_n, and rx are variables input to the UART receiver module, while po_data and po_flag are variables output from the UART receiver module. The rest are intermediate variables within the UART receiver module. Subsequently, based on the functional logic of the receiver module, the timing and logical relationships of each variable are plotted. The timing relationships clarify the transition times, durations, and trigger conditions of each variable under the clk clock drive. For example, the rx signal is sampled through three registers (rx1, rx2, rx2_reg). The first two-stage tapping from rx to rx1 and from rx1 to rx2 is used to eliminate metastability. The third-stage tapping from rx2 to rx2_reg is used to detect falling edges (i.e., a falling edge is detected when rx2_reg is 1 and rx2 is 0). Falling edges of rx2_reg and rx2 trigger rx_flag to go high. cnt_baud performs a cyclic count from 0 to 5207 when rx_flag is 1, and when it counts to 2503, bit_flag goes high (i.e., bit_flag is 1). bit_cnt performs a cyclic count from 0 to 8 when bit_flag is 1, and when bit_cnt is 8 and bit_flag is 1, done_flag goes high (i.e., done_flag is 1). The logical relationships define the output logic of the output signals. For example, shift_data is bit-concatenated when bit_cnt≥1 and bit_flag is 1, and po_data latches the value of shift_data when done_flag is 1. This complete listing of all variables ensures that no critical signals are missed during subsequent code writing. The graphical representation of the timing logic also lays the foundation for a one-to-one mapping between code logic and waveform diagrams, thereby effectively reducing the risk of logical errors caused by misunderstandings of design intent.

[0026] Understandably, in the 0~5207 cyclic counting, the reason why bit_flag goes high when cnt_baud counts to 2503 is that the clock frequency is 50MHz (i.e., 50,000,000 Hz), the baud rate is 9500bps, and the number of bits is 50,000,000 / 9500≈5208. Counting from 0 to 5207 is a total of 5208, meaning each bit of data will be held for 5208 clock cycles. If stable data can be collected at the exact middle of each bit, then 2503 is exactly the middle of the 5208 clock cycles. When cnt_baud is 2503, bit_flag is only raised for one clock cycle. When bit_flag is 1, it serves as a condition for collecting stable data. Therefore, 5207 and 2503 are designed for a clock frequency of 50MHz and a UART baud rate of 9500bps. If either the clock frequency or the baud rate is a different value, both values ​​need to be recalculated, which will not be elaborated here.

[0027] Optionally, a time-series waveform diagram containing all variables can be plotted based on the configuration specification data, including: Based on the configuration specification data, a framework diagram is determined that includes the relationships between input units, internal logic units, and output units, where internal logic units interact with signals through intermediate variables. Based on the framework diagram, a timing waveform diagram containing all variables is drawn according to the configuration specification data.

[0028] Understandably, after determining the core functions of the receiving module and setting key parameters based on the configuration specification data, a module framework diagram is drawn based on the relationship between the input unit, internal logic unit and output unit described in the configuration specification data. The framework diagram clarifies the relationship between input signals, output signals and core internal variables. For example, input signals include clk, rst_n and rx, and output signals include po_data and po_flag. The variable names of each signal or variable can be customized, which will not be elaborated here.

[0029] In one embodiment, the receiving module includes an input unit, an internal logic unit, and an output unit. The internal logic unit is further divided into internal sub-units that implement functions such as metastability elimination, counting control, data splicing, and flag generation. Each unit interacts with signals through internal variables. For example, the connection relationship between the units inside the receiving module and the variables involved are as follows: the input ports (clk, rst_n, rx), the metastability elimination unit (rx1, rx2, rx2_reg), the counting control unit (cnt_baud, bit_flag, bit_cnt), the data splicing unit (shift_data), the flag generation unit (rx_flag, done_flag, po_flag), and the output ports (po_data, po_flag) are connected in sequence.

[0030] Subsequently, a simplified waveform diagram can be drawn based on the framework diagram and the configuration specification data. For example, the simplified waveform diagram can be drawn using a drawing tool, and is suitable for receiver module designs with different baud rates and data bit lengths. Only the counting parameters and timing nodes in the waveform diagram need to be adjusted.

[0031] For example, Figure 2 This disclosure provides a timing waveform diagram that illustrates the timing relationship of key signals during the reception module's reception of a data frame. Figure 2 This includes clock clk, reset rst_n, serial input rx and its synchronization signals rx1 / rx2 / rx2_reg, receive flag rx_flag, baud rate counter cnt_baud, sampling flag bit_flag, bit counter bit_cnt, shift register shift_data, frame completion flag done_flag, data valid flag po_flag, and output data po_data, presenting a complete reception process. po_flag and po_data serve as inputs to other modules. These modules determine whether po_data is valid by checking if po_flag is high. For example, the falling edge of rx2_reg or rx2 triggers rx_flag to go high. cnt_baud performs a cyclic count from 0 to 5207 when rx_flag is 1, and pulls bit_flag high when the count reaches 2503.

[0032] S103. Generate the hardware description code of the general asynchronous transceiver module based on the timing waveform diagram.

[0033] The code statements included in the hardware description code correspond to the timing logic relationships.

[0034] Understandably, the hardware description code for the receiving module is generated based on the drawn simplified waveform diagram. Hardware description code refers to computer program code written in a hardware description language (HMR) to describe the structure and behavior of digital circuits, which can be synthesized into an actual physical circuit by electronic design automation (EDA) tools. The code statements in the hardware description code correspond one-to-one with the timing logic relationships in the timing waveform diagram. Specifically, each timing node, each set of state transition conditions, and each variable assignment time in the simplified waveform diagram is implemented with corresponding HMR statements. This method of writing RTL code for the receiving module based on simplified waveform diagrams ensures a clear code structure and high readability through the explicit correspondence between code statements and waveform logic, achieving a visual transformation of the design concept.

[0035] Optionally, hardware description code for the general asynchronous transceiver module is generated based on the timing waveform diagram, including: Based on the full variable list of the timing waveform diagram, declare the bit width and direction of the corresponding variables of the input unit, internal logic unit, and output unit in the general asynchronous transceiver module; according to the timing relationship of each variable in the timing waveform diagram, write the corresponding logic block statements, including combinational logic blocks and sequential logic blocks; establish the correspondence between each logic block statement and the timing relationship in the timing waveform diagram, so as to generate hardware description code based on the logic block statements.

[0036] Understandably, module ports and internal variables are defined. For example, following the variable list in the simplified waveform diagram, the bit width and direction of input and output ports and internal variables are declared. Subsequently, combinational and sequential logic code statements are written. For instance, based on the counting logic of `cnt_baud`, its loop counting and clearing code under the control of `rx_flag` is written; based on the bit concatenation timing of `shift_data`, its data concatenation code under the control of `bit_flag` and `bit_cnt` is written. Each code statement corresponds to a specific timing relationship in the simplified waveform diagram, ensuring logical consistency between the code and the waveform diagram and avoiding logical deviations. Strict adherence to the waveform diagram logic in code writing effectively reduces human-caused logical errors (such as omitted conditions and counting deviations), improving design accuracy.

[0037] In one embodiment, the variable list in the simplified waveform diagram is shown in Table 1. Table 1 shows the variable name, variable type (direction), bit width, and variable description of each variable. Figure 2 The variables correspond to each other.

[0038]

[0039] Optionally, after generating the hardware description code for the universal asynchronous transceiver module based on the timing waveform diagram, the method further includes: The hardware description code is simulated and tested to obtain simulation test results. Simulation waveforms are plotted based on the simulation test results. The simulation waveforms are used to characterize the actual signal transition behavior of the hardware description code under preset simulation stimuli. The simulation waveforms and timing waveforms are compared to generate code detection results for the hardware description code, and the hardware description code is updated based on the code detection results.

[0040] Understandably, after generating the hardware description code, it undergoes simulation debugging. Specifically, a simulation environment is set up, simulation stimuli are configured (e.g., inputting specific data 8'hA5), and simulation tools are run under these stimuli to perform simulation tests on the hardware description code, generating simulation waveforms. These waveforms are graphical outputs of the actual signal transitions recorded by the simulator after applying simulation stimuli to the hardware description code, reflecting the true logic of the code during actual operation. The simplified waveform, on the other hand, is a pre-drawn, standardized timing blueprint representing the intended design. During simulation verification, the simulation waveforms and the simplified waveform are compared to generate code detection results, significantly reducing the logic error rate caused by inconsistencies between design intent and code implementation, thus improving development efficiency and code reliability.

[0041] Optionally, by comparing the simulation waveform diagram and the timing waveform diagram, code detection results for the hardware description code are generated, including: The simulation waveform and timing waveform are compared variable by variable and timing node by node to identify the differences between them. Based on the timing waveform, the abnormal code segments corresponding to the differences are identified in the hardware description code. The abnormal code segments are corrected and the hardware description code is updated so that the simulation waveform generated by the updated hardware description code matches the timing waveform under simulation testing.

[0042] Understandably, a waveform comparison analysis is performed between the simulated waveform diagram and the simplified waveform diagram, comparing them variable by variable and time-series node by time to check for differences. Variable-by-variable comparison refers to comparing the level changes of each key signal (e.g., baud rate count variable, sampling point flag, bit count variable, shift data register, etc.) within the same time window. Time-series node comparison refers to comparing the signal states of each key timing node (e.g., starting bit falling edge, sampling point trigger time, stop bit verification time, etc.) to see if they are consistent. After identifying the differences between the simulated waveform diagram and the timing waveform diagram, based on the expected timing logic relationships marked in the simplified waveform diagram, the abnormal code segment corresponding to the variable at the difference point is located in the hardware description code. Specifically, using the simplified waveform diagram as a reference standard, the source and triggering conditions of the assignment of the variable corresponding to the difference point under the expected timing logic are traced back, and the statement block related to this assignment behavior is searched in the hardware description code to identify the abnormal code segment. That is, if a discrepancy is found (e.g., po_data does not match the expected value, or the flag bit does not change as expected), the logic code of the corresponding variable is traced according to the simplified waveform diagram to locate the cause of the error (e.g., missing condition, count deviation) and correct it. The simulation is then repeated until the simulated waveform diagram matches the simplified waveform diagram. Figure 1 The correction process includes, but is not limited to, adjusting logical expressions, correcting assignment directions, supplementing missing conditional branches, and adjusting timing sequences. By performing a structured comparison of simulation waveforms and simplified waveforms, variable by variable and timing node by timing node, the inefficient method of blindly checking code line by line based on experience during debugging is transformed into a precise positioning method based on visual waveform differences. With waveforms as a clear reference during simulation debugging, differences can be quickly identified through comparison, significantly improving debugging efficiency and correction accuracy. This ensures the logical correctness and timing compliance of the final hardware description code, forming a complete closed loop from design specifications and code generation to verification and correction.

[0043] Optionally, after generating the hardware description code for the universal asynchronous transceiver module based on the timing waveform diagram, the method further includes: Obtain the unit function adjustment information of the general asynchronous transceiver module; adjust the timing logic relationship of the variables corresponding to the unit function adjustment information in the timing waveform diagram; and synchronously update the hardware description code according to the timing logic relationship of the variables corresponding to the adjusted unit function adjustment information.

[0044] Understandably, if module functions need to be adjusted later (e.g., changing the baud rate or modifying the data bit length), the timing of the relevant variables in the simplified waveform diagram can be modified first, and then the RTL code can be adjusted synchronously according to the changes in the simplified waveform diagram. There is no need to reorganize the overall logic, which effectively improves maintenance efficiency.

[0045] This disclosure provides a module code generation method. Based on configuration specification data, it clarifies the functional requirements and key parameters of the receiving module and draws a module framework diagram. Subsequently, based on the configuration specification data, it draws a timing waveform diagram containing all variables, visually displaying the timing logic relationships and state transition conditions of each variable during the reception of a signal frame. This transforms implicit design concepts into explicit graphical blueprints, avoiding logical deviations caused by ambiguity in manual interpretation. Hardware description code (RTL code) is written based on the simplified waveform diagram, ensuring a one-to-one correspondence between code statements and the timing logic relationships in the timing waveform diagram, reducing the code logic error rate. The written RTL code is simulated and verified, and the simulated waveform diagram is compared with the simplified waveform diagram to locate and correct logical errors in the code, achieving precise location based on waveform differences. In later maintenance, the code is adjusted synchronously by modifying the waveform diagram, improving the scalability and reusability of the design.

[0046] Based on the above embodiments, Figure 3 A flowchart illustrating another module code generation method provided in this disclosure embodiment, specifically including as follows: Figure 3 The following steps are shown: 1) Define the module's functions and parameters, and draw the module framework diagram; 2) Draw a simplified waveform diagram containing all variables; 3) Write RTL code based on the simplified waveform diagram; 4) Set up the simulation environment and generate the simulation waveform diagram; 5) Compare the simulation waveform diagram and the simplified waveform diagram; 6) Determine if the simulation waveform diagram and the simplified waveform diagram are consistent; 7) If the simulation waveform diagram and the simplified waveform diagram are inconsistent... Figure 1 If the simulation waveform and the simplified waveform are inconsistent, locate the error based on the waveform, correct the code, and re-perform simulation debugging; 9) During later code maintenance, modify the waveform and debug the code simultaneously.

[0047] Understandably, the implementation details of 1) to 9) above are as described in the above embodiments and will not be repeated here.

[0048] Figure 4 This is a schematic diagram of a module code generation apparatus provided in an embodiment of the present disclosure. The module code generation apparatus provided in this embodiment can execute the processing flow provided in the module code generation method embodiment, such as… Figure 4 As shown, the module code generation device 400 includes: The data acquisition module 401 is used to acquire the configuration specification data of the general asynchronous transceiver module, wherein the configuration specification data is used to characterize the functional requirements and key parameters of the general asynchronous transceiver module; The waveform drawing module 402 is used to draw a timing waveform diagram containing all variables according to the configuration specification data. The timing waveform diagram visually displays the timing logic relationship of each variable in the process of the general asynchronous transceiver module receiving a frame of data. The code generation module 403 is used to generate hardware description code for the general asynchronous transceiver module based on the timing waveform diagram. The code statements included in the hardware description code correspond to the timing logic relationship.

[0049] Optionally, the waveform plotting module 402 is used for: Identify all variables representing the functional requirements of the configuration specification data to be implemented, including input variables, intermediate variables, and output variables; Based on the unit functional logic described in the configuration specification data, determine the timing relationship and logical relationship of each variable. The timing relationship includes the transition time, duration and triggering condition of each variable under clock drive, and the logical relationship is used to define the output logic of the output variable. Based on the temporal and logical relationships of each variable, draw a time-series waveform diagram containing all variables, where the temporal and logical relationships include both temporal and logical relationships.

[0050] Optionally, the module code generation device 400 is used for: Simulation tests were performed on the hardware description code to obtain simulation test results; Simulation waveforms are plotted based on the simulation test results. These waveforms are used to characterize the actual signal transition behavior of the hardware description code under preset simulation stimuli. By comparing the simulation waveform diagram and the timing waveform diagram, code detection results are generated for the hardware description code, and the hardware description code is updated based on the code detection results.

[0051] Optionally, the module code generation device 400 is used for: The simulation waveform and the time-series waveform are compared variable by variable and time-series node by node to determine the differences between the simulation waveform and the time-series waveform. Based on timing waveform diagrams, identify the abnormal code segment in the hardware description code corresponding to the variable with the difference point; Correct the abnormal code segment and update the hardware description code so that the simulation waveform generated by the updated hardware description code matches the timing waveform under simulation testing.

[0052] Optionally, the module code generation device 400 is used for: Obtain the unit function adjustment information of the general asynchronous transceiver module; Adjust the timing logic relationship of the variables corresponding to the unit function adjustment information in the timing waveform diagram; Based on the timing logic relationship of the variables corresponding to the adjusted unit function adjustment information, the hardware description code is updated synchronously.

[0053] Optionally, the waveform plotting module 402 is used for: Based on the configuration specification data, a framework diagram is determined that includes the relationships between input units, internal logic units, and output units, where internal logic units interact with signals through intermediate variables; Based on the framework diagram, a time-series waveform diagram containing all variables is drawn according to the configuration specification data.

[0054] Optionally, code generation module 403 is used for: According to the full variable list of the timing waveform diagram, declare the bit width and direction of the corresponding variables of the input unit, internal logic unit and output unit in the general asynchronous transceiver module; Based on the timing relationships of the variables in the timing waveform diagram, write the corresponding logic block statements, which include combinational logic blocks and sequential logic blocks. Establish the correspondence between each logic block statement and the timing relationship in the timing waveform diagram, so as to generate hardware description code based on the logic block statements.

[0055] Figure 4 The module code generation device shown in the embodiment can be used to execute the technical solutions of the above method embodiments. Its implementation principle and technical effect are similar, and will not be repeated here.

[0056] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. See below for details. Figure 5 The diagram illustrates a structural schematic suitable for implementing the electronic device 500 in the embodiments of this disclosure. The electronic device 500 in the embodiments of this disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), wearable electronic devices, etc., as well as fixed terminals such as digital TVs, desktop computers, smart home devices, etc. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0057] like Figure 5As shown, the electronic device 500 may include a processing unit 501 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503 to implement the module code generation method as described in the embodiments of this disclosure. The RAM 503 also stores various programs and data required for the operation of the electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0058] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0059] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts, thereby implementing the module code generation method as described above. In such embodiments, the computer program can be downloaded and installed from a network via communication device 509, or installed from storage device 508, or installed from ROM 502. When the computer program is executed by processing device 501, it performs the functions defined in the methods of embodiments of this disclosure.

[0060] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0061] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0062] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0063] Optionally, when one or more of the above-described procedures are executed by the electronic device, the electronic device may also perform other steps described in the above embodiments.

[0064] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0065] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0066] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0067] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0068] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0069] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or gateway that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or gateway. Without further limitations, an element defined by the statement "comprising a module code generation" does not exclude the presence of other identical elements in the process, method, article, or gateway that includes said element.

[0070] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A module code generation method, characterized in that, include: Obtain the configuration specification data of the general asynchronous transceiver module, wherein the configuration specification data is used to characterize the functional requirements and key parameters of the general asynchronous transceiver module; A time-series waveform diagram containing all variables is drawn based on the configuration specification data. The time-series waveform diagram visually displays the temporal logic relationship of each variable in the process of the general asynchronous transceiver module receiving a frame of data. The hardware description code of the general asynchronous transceiver module is generated based on the timing waveform diagram, wherein the code statements included in the hardware description code correspond to the timing logic relationship.

2. The method according to claim 1, characterized in that, The step of drawing a time-series waveform diagram containing all variables based on the configuration specification data includes: Determine all variables representing the functional requirements of the configuration specification data to be implemented, wherein the all variables include input variables, intermediate variables, and output variables; Based on the unit functional logic described in the configuration specification data, determine the timing relationship of each variable and the logical relationship of each variable. The timing relationship includes the transition time, duration and triggering condition of each variable under clock drive, and the logical relationship is used to define the output logic of the output variable. Based on the temporal relationship and logical relationship of each variable, a time-series waveform diagram containing all the variables is drawn, wherein the temporal logical relationship includes both the temporal relationship and the logical relationship.

3. The method according to claim 1, characterized in that, After generating the hardware description code of the universal asynchronous transceiver module based on the timing waveform diagram, the method further includes: The hardware description code was simulated and tested to obtain simulation test results; Based on the simulation test results, a simulation waveform diagram is plotted, wherein the simulation waveform diagram is used to characterize the actual signal transition behavior of the hardware description code under a preset simulation stimulus; By comparing the simulation waveform diagram and the timing waveform diagram, a code detection result is generated for the hardware description code, and the hardware description code is updated based on the code detection result.

4. The method according to claim 3, characterized in that, The step of comparing the simulation waveform and the timing waveform to generate the code detection result for the hardware description code includes: The simulation waveform and the time-series waveform are compared variable by variable and time-series node by node to determine the differences between the simulation waveform and the time-series waveform. Based on the timing waveform diagram, the abnormal code segment corresponding to the variable at the difference point is determined in the hardware description code; The abnormal code segment is corrected, and the hardware description code is updated so that the simulation waveform generated by the updated hardware description code under simulation testing matches the timing waveform.

5. The method according to claim 1, characterized in that, After generating the hardware description code of the universal asynchronous transceiver module based on the timing waveform diagram, the method further includes: Obtain the unit function adjustment information of the general asynchronous transceiver module; Adjust the timing logic relationship of the variables corresponding to the unit function adjustment information in the timing waveform diagram; Based on the timing logic relationship of the variables corresponding to the adjusted unit function adjustment information, the hardware description code is updated synchronously.

6. The method according to claim 1, characterized in that, The step of drawing a time-series waveform diagram containing all variables based on the configuration specification data includes: Based on the configuration specification data, a framework diagram is determined that includes the relationships between input units, internal logic units, and output units, wherein the internal logic units interact with signals through intermediate variables; Based on the aforementioned framework diagram, a time-series waveform diagram containing all variables is drawn according to the configuration specification data.

7. The method according to claim 1, characterized in that, The step of generating the hardware description code for the universal asynchronous transceiver module based on the timing waveform diagram includes: According to the full variable list of the timing waveform diagram, declare the bit width and direction of the variables corresponding to the input unit, internal logic unit and output unit in the general asynchronous transceiver module; Based on the timing relationship of each variable in the timing waveform diagram, write the corresponding logic block statements, which include combinational logic blocks and sequential logic blocks; Establish a correspondence between each logic block statement and the timing relationship in the timing waveform diagram, so as to generate the hardware description code based on the logic block statements.

8. A module code generation device, characterized in that, include: The data acquisition module is used to acquire the configuration specification data of the general asynchronous transceiver module, wherein the configuration specification data is used to characterize the functional requirements and key parameters of the general asynchronous transceiver module; The waveform drawing module is used to draw a time-series waveform diagram containing all variables according to the configuration specification data. The time-series waveform diagram visually displays the temporal logic relationship of each variable in the process of the general asynchronous transceiver module receiving a frame of data. The code generation module is used to generate hardware description code for the general asynchronous transceiver module based on the timing waveform diagram, wherein the code statements included in the hardware description code correspond to the timing logic relationship.

9. An electronic device, characterized in that, include: Memory; processor; as well as Computer programs; The computer program is stored in the memory and configured to be executed by the processor to implement the module code generation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the module code generation method as described in any one of claims 1 to 7.

Images