Programmable logic unit simulation and code generation system, method, medium device and program product

Abstract

The present application provides a programmable logic unit simulation and code generation system, method, medium device and program product, the system includes: a graphical programming module, based on a graphical programming environment, in response to user configuration operations to build modules to establish a simulation model; a file parsing and code generation module, for parsing the file output by the simulation model and generating corresponding code; and generating corresponding code according to the new simulation model when the simulation model changes are monitored; a target hardware code configuration module, for calling the code generated by the file parsing and code generation module and converting it into a code adapted to the target hardware to perform hardware-in-the-loop simulation. Through the technical solution provided by the present application, the existing Simulink software can be combined with some script codes to easily realize the design, simulation and code generation of digital circuits, which greatly reduces the customer support cost for chip manufacturers; intuitive and easy to build circuits; Simulink has a lower learning curve, allowing users to quickly get started; can support the use of signals collected by microcontrollers (MCUs) as simulation inputs; simplify the development process and reduce development costs; avoid manual coding errors, improve development efficiency and code quality.

Description

Technical Field

[0001] The present application relates to the field of simulation technology, and in particular to a programmable logic unit simulation and code generation system, method, medium device and program product. Background Art

[0002] Nowadays, high-performance MCU chips integrate programmable logic arrays (PLA), complex logic blocks (CLB) or complex programmable logic devices (CPLD), etc. These components can provide additional logic functions, help MCU process high-speed signals and perform complex logic operations, thereby improving overall performance.

[0003] However, programming of these programmable logic arrays usually requires specialized programming languages ​​and tools, which is different from the firmware programming of the MCU in this application. Currently, only a few companies provide the following types of tools and resources to support users in programming programmable logic arrays: (1) Integrated development environment (IDE), which provides functions such as code editing, compilation, simulation and debugging; (2) Hardware description language (HDL) compiler, which converts HDL code into logic circuits that can be executed on FPGA or CPLD; (3) Logic simulation tools, which allow users to test and verify logic designs before actual hardware deployment; (4) Configuration and burning tools, which download the compiled logic design to the programmable logic array in the MCU; (5) Documentation and examples, which provide programming guides, API documentation and sample code to help users get started quickly.

[0004] However, implementing the above tools and resources faces the following problems:

[0005] (1) This requires a large tool team and is costly;

[0006] (2) The configuration method of these tools is still register mode, that is, specifying the value of the register, which is not intuitive. Figure 1 As shown, the input and output of signals are configured by selecting options, which makes the design difficult.

[0007] (3) Specialized tools increase learning costs and have low user acceptance.

[0008] (4) The simulation input signal is not flexible, and signal observation and debugging are inconvenient.

[0009] (5) It is not possible to use real input signals as simulation inputs.

[0010] (6) When using simulink simulation and its own code generation tool, it is not possible to directly generate code from signal lines.

[0011] Therefore, it is a technical problem that urgently needs to be solved in this field to provide a low-cost and fast solution for designing digital circuits, a low-cost and fast solution for simulating digital circuits, a model that can generate code used by programmable logic units after design and simulation, and support hardware-in-the-loop simulation. Summary of the invention

[0012] In view of the shortcomings of the prior art described above, the purpose of the present application is to provide a programmable logic unit simulation and code generation system, method, medium device and program product to solve the technical problems of the prior art such as high cost, low user acceptance, inconvenient debugging, inability to use real input signals, and inability to directly generate code from signal lines.

[0013] To achieve the above-mentioned purpose and other related purposes, the first aspect of the present application provides a programmable logic unit simulation and code generation system, including: a graphical programming module, which is based on a graphical programming environment and builds modules in response to user configuration operations to establish a simulation model; a file parsing and code generation module, which is used to parse the files output by the simulation model and generate corresponding codes; and generates corresponding codes according to the new simulation model when changes to the simulation model are detected; a target hardware code configuration module, which is used to call the code generated by the file parsing and code generation module and convert it into code suitable for running on the target hardware to perform hardware-in-the-loop simulation.

[0014] In some embodiments of the first aspect of the present application, the graphical programming module includes a programming module that uses a Simulink model as a graphical programming environment; the process of establishing a simulation model includes: starting the Simulink environment and creating a new model, and adding multiple basic modules to the newly created model according to user needs; configuring and connecting each basic module; running the model simulation, and verifying whether the signal processing meets expectations based on the waveforms of the signal input module and the signal output module; adjusting the module parameters or logic according to the simulation results until the design requirements are met.

[0015] In some embodiments of the first aspect of the present application, multiple basic modules are added to the newly created model, and the basic modules include any one or more combinations of the following: a truth table module, a signal connection module, a counting module, a shift module, a comparison module, a signal input module, a signal output module and a debugging module.

[0016] In some embodiments of the first aspect of the present application, the file parsing and code generation module parses the file output by the simulation model and generates corresponding code, and its processing method includes: parsing the Simulink model file through a text parsing tool, determining whether the number of lookup tables and custom modules meets the hardware resource limitations, allocating the corresponding target hardware ID and extracting the module SID; determining the input and output relationship between each module, configuring IOMUX parameters, obtaining lookup table parameters, and fusing the obtained parameter data to generate code suitable for the target hardware.

[0017] In some embodiments of the first aspect of the present application, the text parsing tool includes a Python script, and the target hardware includes an MCU processor; the process of parsing a file through a Python script and generating corresponding code includes: reading the MDL text; matching fields to obtain the number of lookup tables, and assigning them to the specified MCU hardware lookup table ID if the number of lookup tables does not exceed the maximum resource amount; matching fields to obtain the number of custom modules, and assigning them to the ID number corresponding to the corresponding MCU hardware resource if the number of custom modules does not exceed the hardware resource amount; obtaining the SID of the lookup table, as well as the SID of the IOMUX and the custom module; determining the input-output relationship of each module based on the signal source and signal destination in the text and creating a table; configuring the IOMUX parameters based on the created table; obtaining the value of the lookup table based on the SID of the lookup table; and fusing the obtained parameters to generate C code.

[0018] In some embodiments of the first aspect of the present application, the code configured by the target hardware code configuration module includes: board-level initialization code, peripheral and clock configuration code, and middleware encapsulation interface code.

[0019] To achieve the above-mentioned purpose and other related purposes, the second aspect of the present application provides a programmable logic unit simulation and code generation method, which is applied to the programmable logic unit simulation and code generation system; the method includes: based on a graphical programming environment, building modules in response to user configuration operations to establish a simulation model; parsing the file output by the simulation model and generating corresponding code; and continuously monitoring whether the simulation model changes, and generating corresponding code according to the new simulation model when the simulation model changes are monitored; retrieving the generated code and converting it into code suitable for running on the target hardware to perform hardware-in-the-loop simulation.

[0020] To achieve the above-mentioned purpose and other related purposes, the third aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the programmable logic unit simulation and code generation method is implemented.

[0021] To achieve the above-mentioned purpose and other related purposes, the fourth aspect of the present application provides a computer program product, which includes a computer program code. When the computer program code runs on a computer, the computer implements the programmable logic unit simulation and code generation method.

[0022] To achieve the above-mentioned purpose and other related purposes, the fifth aspect of the present application provides a computer device, including a memory, a processor and a computer program stored in the memory; the processor executes the computer program to implement the programmable logic unit simulation and code generation method.

[0023] As described above, the programmable logic unit simulation and code generation system, method, medium device and program product of the present application have the following beneficial effects:

[0024] (1) By using the existing Simulink software combined with some script codes, digital circuit design, simulation and code generation can be easily realized, which greatly reduces customer support costs for chip manufacturers.

[0025] (2) Using Simulink to build digital circuits, users can intuitively and easily build circuits by simply dragging and dropping on the graphical interface.

[0026] (3) Compared with professional tools, Simulink has a lower learning curve, allowing users to get started quickly.

[0027] (4) It can support the use of signals collected by a microcontroller (MCU) as simulation input, further enhancing the flexibility and practicality of the design.

[0028] (5) Users do not need to have an in-depth understanding of the specific implementation details of different chip peripherals, but only need to focus on the required functions, which greatly simplifies the development process and reduces development costs.

[0029] (6) By automatically generating code, errors that may be introduced during manual coding are effectively avoided, improving development efficiency and code quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 Shown is a schematic diagram of the interface of a configuration tool in the prior art.

[0031] Figure 2 Shown is a structural diagram of a programmable logic unit simulation and code generation system in one embodiment of the present application.

[0032] Figure 3 Shown is a schematic diagram of the construction and debugging process of the graphical programming module in one embodiment of the present application.

[0033] Figure 4 Shown is a schematic diagram of the structure of a programmable logic block applied to a microcontroller in one embodiment of the present application.

[0034] Figure 5 Shown is a flowchart of using Python to interpret .MDL files and generate C code in one embodiment of the present application.

[0035] Figure 6 Shown is an example diagram of a programmable logic unit simulation and code generation system in one embodiment of the present application.

[0036] Figure 7 Shown is a schematic diagram of the structure of a computer device in one embodiment of the present application. DETAILED DESCRIPTION

[0037] The following describes the embodiments of the present application through specific examples, and those skilled in the art can easily understand other advantages and effects of the present application from the contents disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0038] Before further describing the present invention in detail, the nouns and terms involved in the embodiments of the present invention are explained. The nouns and terms involved in the embodiments of the present invention are applicable to the following interpretations:

[0039] <1> Simulink, a graphical programming environment based on MATLAB, is used to simulate, analyze, and design dynamic systems. It is widely used in modeling and simulation in control systems, signal processing, communication systems, video processing, and other fields.

[0040] <2> Hardware-in-the-Loop (HiL) is an advanced simulation technology that simulates and tests the performance of the entire system by integrating real hardware components into the simulation environment. The purpose of HiL simulation is to test and verify hardware components and systems in a control environment to ensure that they can work properly under real-world conditions. HiL simulation usually includes simulation software, actual hardware components (such as controllers, actuators, sensors, etc.), data acquisition systems (DAQ), input / output interfaces, and possible real-time operating systems.

[0041] Figure 2 A structural schematic diagram of a programmable logic unit simulation and code generation system in an embodiment of the present invention is shown.

[0042] Graphical programming module 1, based on the graphical programming environment, responds to user configuration operations to build modules to establish a simulation model. Taking Simulink as a graphical programming environment as an example, the construction and debugging process of the graphical programming module includes: Figure 3 The steps shown in:

[0043] Step S11, start the Simulink environment and create a new model, and add one or more basic modules to the newly created model according to user requirements to form the required programmable logic block.

[0044] It should be understood that Simulink provides a drag-and-drop graphical interface, where users can build models graphically without writing traditional text code. Simulink models are composed of various predefined modules (such as mathematical operations, logical operations, signal processing, etc.), and users can build complex system models by combining these modules. Simulink supports time domain and frequency domain simulation, and users can simulate the behavior of the system under different time conditions or analyze the frequency response of the system. Users can also define parameters in the model and dynamically adjust these parameters during the simulation process to study the impact of different parameters on system performance. In addition, Simulink can be seamlessly integrated with other Math Works tools such as MATLAB, State flow (for state machine design), and Embedded Coder (for code generation).

[0045] For example, the basic modules added to the model include but are not limited to: truth table module (CombinatorialLogic), signal connection module (IOMUX), counting module, shift module, comparison module, signal input module (SignalIn), signal output module (SignalOut) and debugging module. Each basic module needs to be configured and connected to achieve specific system functions. By combining these basic building blocks, complex signal processing and control systems can be designed. Figure 4 A programmable logic block applied to a microcontroller is shown as an example, which consists of a LUT module (lookup table), an IOMUC module (signal connection unit), and other parts such as a technical module, a shift module, a comparison module, etc.

[0046] Explanatory, the truth table module (Combinatorial Logic) is used to implement combinatorial logic circuits, which determine the output based on the current value of the input signal without involving the historical information of the signal; it is usually configured in the form of a truth table, which lists all possible input combinations and their corresponding outputs. The signal connection module (IOMUX) is used for the interface between internal modules of signal input and output. The counting module is used to implement the counter function, which can count the pulses of the input signal and can be used to implement logic such as frequency division and timing. The shift module is used to implement data shift operations, such as left shift, right shift or circular shift, and is often used in data processing and communication protocols. The comparison module is used to compare the size of two signals and output true (high level) or false (low level) according to the comparison result, which can be used to implement conditional judgment and logic control. The signal input module (Signal In) is the input point of the model, receiving external signals or data, which can simulate sensor readings, user input or other external signal sources. The signal output module (Signal Out) is the output point of the model, sending the internally processed signals or data to the outside, which is used to drive actuators, display results or communicate with other systems. Debug modules are modules used for debugging purposes, for example, the Scope module can be used to observe and record the changes of signals over time, the Display module can be used to display the value of a signal in real time, and breakpoints and probes can be used to pause execution during simulation and inspect the value of variables.

[0047] Step S12, configure and connect each basic module. The specific execution steps are as follows:

[0048] Step S12a, configure the signal input module (Signal In) and the signal output module (Signal Out), and set the port name and data type.

[0049] The signal input module (Signal In) is the input point of the Simulink model, which can simulate sensors, user input or other signal sources. The configuration of the signal input module includes: selecting the signal source, setting the port name, configuring the data type, etc. Among them, when selecting the signal source, for example, you can find and drag a signal source module to the model in the Simulink library, such as Constant, Step, Sine wave, etc. The port name is the identifier of the module in the model. For example, in the parameter setting of the module, you can set the port name to "Input Voltage" or "Sensor Reading", etc., so as to identify and reference it in the model. The data type determines the numerical format of the signal. For example, "double" represents a double-precision floating point number, and "int8" represents an 8-bit integer. Select a suitable data type to ensure that the accuracy and range of the signal meet the requirements of the model.

[0050] The signal output module (Signal Out) is the output point of the Simulink model, which can display or record signals, drive actuators, etc. The configuration of the signal output module includes: selecting the output destination, setting the port name, configuring the data type, and other parameter configurations. Among them, select an output module in the Simulink library, such as Scope (oscilloscope) to display the signal waveform, or To Workspace (to the workspace) to output data to the MATLAB workspace. The method of setting the port name and configuring the data type is similar to the signal input module and will not be repeated here. In the signal output module, other parameter configurations, such as the sampling time of the Scope module or the variable name of the TO workspace module, are not limited here.

[0051] Step S12b: Based on the Lookup Table, input the corresponding input vector and output vector according to the logic function to be implemented.

[0052] Exemplarily, double-click the Lookup Table module in the Simulink model to enter its configuration interface, define a series of input vectors and corresponding output vectors to create a custom mapping table. This mapping table queries and outputs preset results based on the input value to implement specific logical functions, such as conditional judgment or signal conversion. Among them, the logical relationship between the input signal and the output signal is, for example: if the input value is less than threshold 1, the output value is 0, if the input value is between threshold 1 and threshold 2, the output value is the input value minus threshold 1, and if the input value is greater than threshold 2, a fixed value is output.

[0053] Step S12c, use IOMUX to create connection lines and connect all modules according to the design logic.

[0054] It should be understood that in Simulink, connecting lines (rather than specific IOMUX components) are used to implement signal transmission between modules. These connecting lines are drawn by simply dragging the mouse from the output port to the input port, and the layout and signal properties can be adjusted as needed to build the design logic of the entire system.

[0055] Step S13: Run the model simulation to verify whether the signal processing meets expectations based on the waveforms of the signal input module and the signal output module; adjust the module parameters or logic based on the simulation results until the design requirements are met.

[0056] Specifically, after the simulation is finished, observe the oscilloscope or data recorder to analyze the waveforms of the input and output waveforms. According to the waveform diagram, check whether the signal processing meets expectations. For example, if the design is a low-pass filter, you should see that the high-frequency components are suppressed and the low-pass components pass through. If the signal processing does not meet expectations, you need to go back to the model to adjust the parameters or logic of the relevant modules, such as changing the cutoff frequency of the filter, adjusting the gain, modifying the signal processing algorithm, etc. After adjusting the parameters, rerun the simulation and observe the waveform again. This process requires multiple iterations until the output signal meets the design requirements.

[0057] The file parsing and code generating module 2 is composed of codes, and is used to parse the files output by the simulation model and generate corresponding codes; and to generate corresponding codes according to the new simulation model when changes to the simulation model are detected.

[0058] Specifically, the file parsing and code generation module 2 parses the Simulink model file through a text parsing tool, determines whether the number of lookup tables and custom modules meets the hardware resource restrictions, allocates the corresponding target hardware ID and extracts the module SID; determines the input-output relationship between each module, configures IOMUX parameters, obtains lookup table parameters, and fuses the obtained parameters to generate code suitable for the target hardware, thereby improving the efficiency and accuracy of code generation. It should be understood that in Simulink, models are usually saved as .mdl files, which are actually text files that follow the XML specification.

[0059] Exemplarily, the text parsing tool can be a Python script, or any other tool that can perform text parsing, including but not limited to JavaScript, Java, C#, C++, PHP, Go language, Ruby, Rust, etc., which is not limited in this embodiment.

[0060] Taking Python as an example, the file parsing and code generation module 2 is composed of Python code, which mainly performs MDL file parsing and C code generation. The specific process of using Python to interpret .MDL files and generate C code includes: Figure 5 Each step in .

[0061] Step S5a, start.

[0062] Step S5b, reading the MDL text. Use Python's file operation function to open and read the content of the .MDL file.

[0063] Step S5c, matching fields to obtain the number of lookup tables. Using Python's XML parsing library, search for all lookup table elements in the document through XPath or similar methods, and calculate their number.

[0064] Step S5d, determine whether the number of lookup tables exceeds the maximum resource amount. For example, compare the number of lookup tables with the maximum number of lookup tables supported by the MCU, and determine whether the number of lookup tables exceeds the maximum resource amount based on the comparison result. If it exceeds, jump to step S5e, otherwise jump to step S5f.

[0065] Step S5e, reporting an error. That is, if the number of lookup tables exceeds the resource limit of the MCU, the process is terminated and an error prompt is given.

[0066] Step S5f, assigning a specified MCU hardware lookup table ID. That is, if the number of lookup tables is within the limit, assigning a unique MCU hardware lookup table ID to each lookup table.

[0067] Step S5g, matching fields to obtain the number of custom modules such as counter, etc. Similarly, search for custom modules (such as counter Counter) in the document and calculate the number.

[0068] Step S5h, determine whether the number exceeds the hardware resource amount: if it exceeds, jump to step S5e, otherwise jump to step S5i.

[0069] Step S5i, assigning an ID number corresponding to the corresponding MCU hardware resource.

[0070] Step S5j, obtain the SID of the lookup table. SID (System ID) is a unique identifier of a module in Simulink, and the SID of each lookup table and custom module is extracted.

[0071] Step S5k, obtaining the SIDs of the IOMUX and the custom module.

[0072] Step S51, determine the input and output relationship of each module according to the signal source and signal destination in the text and create a table.

[0073] By analyzing the SRC (signal source) and DST (signal destination) fields in the XML, the input and output relationships of each module are determined and a relationship table is created.

[0074] Step S5m, configure IOMUX parameters according to the created table.

[0075] Step S5n, obtaining the value of the lookup table according to the SID of the lookup table. For example, according to the SID of the lookup table, extracting the parameters defined in the .MDL file, such as the value of the lookup table.

[0076] Step S5o, generate C code by integrating the acquired parameters. For example, integrate all acquired parameters and configuration information, use Python script to generate C code, which contains logic and initialization code executable by MCU. Finally, verify the correctness of the generated C code and deploy it to MCU for execution.

[0077] The target hardware code configuration module 3 is used to call the code generated by the file parsing and code generation module 2 and convert it into code suitable for running on the target hardware for hardware-in-the-loop simulation with Simulink. The purpose of the target hardware code configuration module 3 is to ensure that the Simulink model can run on the MCU and communicate effectively with the hardware device, while realizing real-time data exchange and simulation feedback for hardware-in-the-loop testing and verification, which not only improves development efficiency, but also enhances the reliability and practicality of the model.

[0078] Specifically, the target hardware code configuration module 3 uses the abstraction layer provided by the MCU development kit to simplify the hardware driver development process. One part of the abstraction layer is the driver interface for Python-generated code, and the other part is the code for calling the MCU driver.

[0079] It should be understood that MCU development kits usually provide a wealth of libraries and tools that help developers communicate with hardware through abstract layers without having to deeply understand the underlying implementation of the hardware. The role of the abstract layer is to provide a simplified interface for interacting with the underlying hardware, hiding the specific details of the hardware, making the development process easier and more efficient. Part of the abstract layer is designed specifically for the code generated by Python. When users use Python scripts to generate C code or other code, the abstract layer provides an interface that enables these generated codes to interact with the hardware driver. Another part of the abstract layer is the code that is directly connected to the hardware driver of the MCU, which includes direct operations on hardware peripherals such as GPIO, ADC, PWM, etc. Therefore, using the abstract layer can reduce the workload of directly writing hardware driver code and allow developers to focus on the implementation of application logic; because the hardware details are hidden by the abstract layer, the application code is decoupled from the specific implementation of the hardware, which improves the portability of the code; the abstract layer provides a set of standardized functions and objects, allowing developers to quickly develop functions that interact with the hardware without having to write complex hardware control code from scratch.

[0080] In the embodiments of the present application, in order to ensure that the MCU hardware device can operate normally in the simulation environment and conduct effective data exchange and communication with the Simulink model to facilitate system-level testing and verification, the code configured by the target hardware code configuration module 3 includes but is not limited to: board-level initialization code, peripheral and clock configuration code, middleware encapsulation interface code, and at the same time, the level of the input signal will be uploaded to the Simulink model through the serial port to complete the hardware-in-the-loop simulation.

[0081] It should be understood that the board-level initialization code is the code written to initialize the basic functions of the microcontroller (MCU) board, which usually includes setting the initial state of the CPU, memory, and other key hardware. The peripheral and clock configuration code is to ensure that all necessary peripherals (such as serial ports, ADC, PWM, etc.) and clock systems are correctly configured to ensure that the device can work properly. The middleware encapsulation interface code provides a standardized interface that helps abstract hardware details, simplify application development, and facilitate maintenance and upgrades. In addition, uploading the level of the input signal to the Simulink model through the serial port means sending the level information of the input signal to the Simulink model through serial communication, allowing the model to receive the status of the hardware in real time for monitoring or as simulation input.

[0082] In summary, the programmable logic unit simulation and code generation system is an automated workflow that is used to implement iteration and automated updates during model design, simulation, code generation, compilation, and deployment. The specific steps are as follows: Figure 6 As shown, including the following:

[0083] First, the graphical programming module is called to establish the model simulation. The process of establishing the model simulation by the graphical programming module has been described in detail above and will not be repeated here.

[0084] Secondly, monitor whether the read model has changed. For example, this can be achieved through file system monitoring or version control system. It should be understood that the designer can modify the model to improve performance or implement new functions.

[0085] Subsequently, when the model is monitored for changes, the file parsing and code generation module is called to generate the corresponding code based on the updated model. That is, once the model is modified, the monitoring mechanism detects the change and re-triggers the code generation, compilation, and downloading process. This ensures that changes to the model can be quickly reflected on the hardware and verified.

[0086] Next, the target hardware code configuration module is called to download the executable code to the target hardware platform. That is, the generated code is then passed to the development environment, which is responsible for compiling the code and downloading it to the target hardware platform (such as MCU).

[0087] Finally, run the program. That is, execute the compiled program on the hardware platform to start the actual operation and testing of the model.

[0088] Figure 7 The example diagram of the programmable logic unit simulation and code generation system in the embodiment of the present application is shown. In the model of this embodiment, Counter0 is a self-built module, which is used for counting, corresponding to the counting function of the PLB (programmable logic block) of the microcontroller MCU. Other modules (such as Counter1 module) are built-in modules of the Simulink model.

[0089] Table 1 below shows how the above model is converted in the three-layer structure. The first column "Simulink Block / Name" is the name of each module in the Simulink model, the second column "C code" is the C language code implementation corresponding to each Simulink module, and the third column "C code configuration" is the conversion of the C code to code that can be run on the microcontroller unit.

[0090] Specifically, in the first column "Simulink Block / Name", the LUT (Look-Up Table) module is used to look up table values ​​according to input; Counter0 is a counting module; Line is a line used to connect various modules in the model; PulseConvert is a pulse conversion module used to generate pulse signals. In the second column "C code", the plb_set_lut function is used to initialize or set the parameters of the LUT (lookup table) module; the plb_set_counter function is used to initialize or set the custom module Counter0; the trgm_output_config function is used to configure the output of the trigger. In the third column "C code configuration", LutValue is the specific value stored in the lookup table; Counter mode is the counter mode (such as increment, decrement, reset, etc.); Cmp0 value, Cmp1 value, Cmp2 value, Cmp3 value are the set values ​​of different comparison modules, which are used to compare with the input signal to determine whether the logical condition is met; Input and Output are input ports and output ports, which are used to input and output signals or data respectively; Type is the module type or data type. It should be noted that the above table and content are only examples and do not represent specific implementation details or limiting conditions of the present invention.

[0091] Table 1

[0092]

[0093] It should be understood that the specific process of each module executing the above corresponding steps has been described in detail in the above method embodiment, and for the sake of brevity, it will not be repeated here. It should also be understood that the division of modules in the embodiment of the present application is schematic, which is only a logical function division, and there may be other division methods in actual implementation. Each functional module in each embodiment of the present application can be integrated in a processor, or it can exist physically separately, or two or more modules can be integrated in one module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules.

[0094] In the embodiments of the present application, words such as "first" and "second" are used to distinguish the same or similar items with substantially the same functions and effects. For example, the first XX and the second XX are only used to distinguish different XXs, and do not limit their order. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit them to be different.

[0095] It should be noted that in the embodiments of the present application, words such as "exemplary" or "for example" represent examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0096] In the embodiments of the present application, "at least one" refers to one or more, and "plurality" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can represent: a, b, c, ab, ac, bc or abc, where a, b, c can be single or multiple.

[0097] Figure 8 : is a flow chart of a programmable logic unit simulation and code generation method provided in an embodiment of the present application, the method comprising:

[0098] Step S81: Based on the graphical programming environment, in response to user configuration operations, module construction is performed to establish a simulation model.

[0099] Step S82: parsing the file output by the simulation model and generating corresponding code; and continuously monitoring whether the simulation model changes, and generating corresponding code according to the new simulation model when the simulation model changes are monitored.

[0100] Step S83: Retrieve the generated code and convert it into code suitable for running on the target hardware to perform hardware-in-the-loop simulation.

[0101] It should be noted that the implementation method of the programmable logic unit simulation and code generation method provided in the embodiment of the present application is similar to that of the programmable logic unit simulation and code generation system mentioned above, and will not be repeated here.

[0102] Fig. 9 is a schematic block diagram of a computer device / equipment / system provided in an embodiment of the present application. Fig. 9 As shown, the computer device includes: at least one processor 901, a memory 902, at least one network interface 903 and a user interface 905. The various components in the device are coupled together through a bus system 904. It can be understood that the bus system 904 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 904 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 904 is not used in the embodiment of the present invention. Fig. 9 In the specification, various buses are labeled as bus systems.

[0103] The user interface 905 may include a display, a keyboard, a mouse, a trackball, a click gun, keys, buttons, a touch pad or a touch screen.

[0104] It is understood that the memory 902 can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM). The memory described in the embodiments of the present invention is intended to include but is not limited to these and any other suitable categories of memory.

[0105] The memory 902 in the embodiment of the present invention is used to store various categories of data to support the operation of the electronic terminal 900. Examples of these data include: any executable program for operating on the electronic terminal 900, such as an operating system 9021 and an application 9022; the operating system 9021 includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks. The application 9022 may include various applications, such as a media player (Media Player), a browser (Browser), etc., for implementing various application services. The programmable logic unit simulation and code generation method provided by the embodiment of the present invention may be included in the application 9022.

[0106] The method disclosed in the above embodiment of the present invention can be applied to the processor 901, or implemented by the processor 901. The processor 901 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor 901 or the instruction in the form of software. The above processor 901 may be a general processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor 901 can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiment of the present invention. The general processor 901 may be a microprocessor or any conventional processor, etc. In combination with the steps of the accessory optimization method provided in the embodiment of the present invention, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium, which is located in a memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0107] In an exemplary embodiment, the electronic terminal 900 may be implemented by one or more application specific integrated circuits (ASIC), DSP, programmable logic device (PLD), complex programmable logic device (CPLD) to execute the aforementioned method.

[0108] According to the method provided in the embodiment of the present application, the present application also provides a computer program product, which includes: computer program code, when the computer program code is run on a computer, the computer executes the programmable logic unit simulation and code generation method.

[0109] According to the method provided in the embodiment of the present application, the present application also provides a computer-readable storage medium, which stores a program code. When the program code runs on a computer, the computer executes the programmable logic unit simulation and code generation method.

[0110] The terms "component", "module", "system", etc. used in this specification are used to represent computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program and / or a computer. By way of illustration, both applications running on a computing device and a computing device can be components. One or more components may reside in a process and / or an execution thread, and a component may be located on a computer and / or distributed between two or more computers. In addition, these components may be executed from various computer-readable media having various data structures stored thereon. Components may, for example, communicate through local and / or remote processes according to signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system and / or a network, such as the Internet interacting with other systems through signals).

[0111] Those of ordinary skill in the art will appreciate that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or in a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0112] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0113] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0114] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0115] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0116] In the above embodiments, the functions of each functional unit can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions (programs). When loading and executing computer program instructions (programs) on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. Computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, computer instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that contains one or more available media integrations. Available media may be magnetic media (e.g., floppy disks, hard disks, tapes), optical media (e.g., high-density digital video discs (DVDs), or semiconductor media (e.g., solid state disks (SSDs), etc.).

[0117] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0118] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0119] In summary, the present application provides a programmable logic unit simulation and code generation system, method, medium device and program product. The present invention uses the existing Simulink software combined with some script codes to easily realize the design, simulation and code generation of digital circuits, which greatly reduces the customer support cost for chip manufacturers. Using Simulink to build digital circuits, users can intuitively and easily build circuits by simply dragging a graphical interface. Compared with professional tools, Simulink has a lower learning curve, allowing users to quickly get started. It can support the use of signals collected by a microcontroller (MCU) as simulation input, further enhancing the flexibility and practicality of the design. Users do not need to have a deep understanding of the specific implementation details of different chip peripherals, but only need to focus on the required functions, which greatly simplifies the development process and reduces development costs. By automatically generating code, errors that may be introduced during manual coding are effectively avoided, and development efficiency and code quality are improved. Therefore, the present application effectively overcomes the various shortcomings in the prior art and has a high industrial utilization value.

[0120] The above embodiments are merely illustrative of the principles and effects of the present application and are not intended to limit the present application. Anyone familiar with the technology may modify or change the above embodiments without violating the spirit and scope of the present application. Therefore, all equivalent modifications or changes made by a person of ordinary skill in the art without departing from the spirit and technical ideas disclosed in the present application shall still be covered by the claims of the present application.

Claims

1. A programmable logic unit simulation and code generation system, characterized in that: include: A graphical programming module, based on a graphical programming environment, performs module construction in response to user configuration operations to establish a simulation model; The graphical programming module includes a programming module using a Simulink model as a graphical programming environment; A file parsing and code generation module, used to parse the file output by the simulation model and generate corresponding code; and generating corresponding code according to the new simulation model when the simulation model is monitored to be changed; The file parsing and code generation module parses the file output by the simulation model and generates corresponding code, and its processing method includes: parsing the Simulink model file through a text parsing tool, determining whether the number of lookup tables and custom modules meets the hardware resource limit, allocating the corresponding target hardware ID and extracting the module SID; determining the input and output relationship between each module, configuring IOMUX parameters, obtaining lookup table parameters, and fusing the obtained parameter data to generate code suitable for the target hardware; The text parsing tool includes a Python script, and the target hardware includes an MCU processor; the process of parsing a file through a Python script and generating a corresponding code includes: reading an MDL text; matching a field to obtain the number of lookup tables, and assigning the number of lookup tables to a specified MCU hardware lookup table ID if the number of lookup tables does not exceed the maximum resource amount; matching a field to obtain the number of custom modules, and assigning the number of IDs corresponding to the corresponding MCU hardware resources if the number of custom modules does not exceed the hardware resource amount; obtaining the SID of the lookup table, and the SIDs of the IOMUX and the custom module; determining the input-output relationship of each module according to the signal source and signal destination in the text and creating a table; configuring the IOMUX parameters according to the created table; obtaining the value of the lookup table according to the SID of the lookup table; and generating C code by fusing the obtained parameters; The target hardware code configuration module is used to retrieve the code generated by the file parsing and code generation module and convert it into code suitable for running on the target hardware to perform hardware-in-the-loop simulation.

2. The programmable logic unit simulation and code generation system according to claim 1, characterized in that: The process of establishing the simulation model includes: Start the Simulink environment and create a new model, and add multiple basic modules to the newly created model according to user needs; Configure and connect each basic module; Run the model simulation to verify whether the signal processing meets expectations based on the waveforms of the signal input module and the signal output module; adjust the module parameters or logic based on the simulation results until the design requirements are met.

3. The programmable logic unit simulation and code generation system according to claim 2, characterized in that: The multiple basic modules are added to the newly created model, and the basic modules include any one or more combinations of the following: a truth table module, a signal connection module, a counting module, a shift module, a comparison module, a signal input module, a signal output module and a debugging module.

4. The programmable logic unit simulation and code generation system according to claim 1, characterized in that: The codes configured by the target hardware code configuration module include: board-level initialization code, peripheral and clock configuration code, and middleware encapsulation interface code.

5. A method for simulating and generating code for a programmable logic unit, characterized in that: Applied to the programmable logic unit simulation and code generation system as claimed in claim 1; the method comprises: Based on the Simulink model as a graphical programming environment, the module is built in response to the user's configuration operation to establish a simulation model; Parsing the file output by the simulation model and generating corresponding code; and continuously monitoring whether the simulation model has changed, and generating corresponding code according to the new simulation model when the simulation model has changed; the processing method of parsing the file output by the simulation model and generating corresponding code includes: parsing the Simulink model file through a text parsing tool, determining whether the number of lookup tables and custom modules meets the hardware resource restrictions, allocating the corresponding target hardware ID and extracting the module SID; determining the input-output relationship between each module, configuring IOMUX parameters, obtaining lookup table parameters, and fusing the obtained parameter data to generate code suitable for the target hardware; The text parsing tool includes a Python script, and the target hardware includes an MCU processor; the process of parsing a file through a Python script and generating a corresponding code includes: reading an MDL text; matching a field to obtain the number of lookup tables, and assigning the number of lookup tables to a specified MCU hardware lookup table ID if the number of lookup tables does not exceed the maximum resource amount; matching a field to obtain the number of custom modules, and assigning the number of IDs corresponding to the corresponding MCU hardware resources if the number of custom modules does not exceed the hardware resource amount; obtaining the SID of the lookup table, and the SIDs of the IOMUX and the custom module; determining the input-output relationship of each module according to the signal source and signal destination in the text and creating a table; configuring the IOMUX parameters according to the created table; obtaining the value of the lookup table according to the SID of the lookup table; and generating C code by fusing the obtained parameters; The generated code is retrieved and converted into code suitable for running on the target hardware for hardware-in-the-loop simulation.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the programmable logic unit simulation and code generation method of claim 5 is implemented.

7. A computer program product, characterized in that The computer program product includes computer program codes, and when the computer program codes are executed on a computer, the computer is enabled to implement the programmable logic unit simulation and code generation method as claimed in claim 5 .

8. A computer device comprising a memory, a processor and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the programmable logic unit simulation and code generation method according to claim 5.

Images