AXI4 high-speed bus and multi-queue simulation verification method and simulation verification device
By constructing a simulation and verification method for the AXI4 high-speed bus and multi-queue using Python and the MyHDL extension package, the problem of low simulation and verification efficiency in FPGA development is solved, achieving efficient and comprehensive simulation design and shortening the development cycle.
Patent Information
- Application Number
- CN202110789997.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-07-13
- Publication Date
- 2025-11-11
- Estimated Expiration
- 2041-07-13
AI Technical Summary
In the existing FPGA development process, simulation verification methods are inefficient, difficult, and cannot guarantee the comprehensiveness of the simulation design. Especially in high-speed network communication, traditional hardware description languages lead to long development cycles, and logic verification work takes up a lot of time.
This paper proposes a simulation and verification method for the AXI4 high-speed bus and multi-queue using Python and the MyHDL extension package. Through the collaborative work of software and hardware, it provides modular design and flexible simulation and verification process, supports multi-specification verification, and utilizes the MyHDL signal transmission interface for data packet processing and queue management.
It improves the efficiency and comprehensiveness of simulation verification, reduces development difficulty, shortens the development cycle, supports a wider range of functional verification, and enhances the reusability and flexibility of the simulation system.
Smart Images

Figure CN115622896B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of computer network communication technology, specifically, it relates to an AXI4 high-speed bus and multi-queue simulation verification method and simulation verification device. Background Technology
[0002] With the rapid development of computer network communication technology, various network application scenarios have emerged, accompanied by a gradual increase in network traffic in data centers. This poses a challenge to high-performance processing of network data packets. On the server side, traditional software-based data packet processing methods struggle to achieve 100% line-rate processing, especially for repetitive computational operations, consuming excessive system resources and limiting CPU processing performance to some extent. Compared to software processing methods, the programmability, parallelism, and real-time capabilities of FPGAs have made them one of the mainstream platforms for high-speed data packet processing. Adopting an FPGA+CPU heterogeneous architecture, offloading some high-speed computational operations to FPGA hardware, is gradually becoming a research hotspot in the industry.
[0003] Currently, the industry primarily uses hardware description languages (HMRs) as the development language for FPGAs. However, the simplicity of these language specifications has led to increasingly higher design complexity for FPGAs. The high development difficulty and long development cycle significantly impact the speed of FPGA engineering updates and commercialization, especially in the logic verification stage, where simulation testing and performance verification based on Verilog or VHDL account for at least 50% of the overall design time. Therefore, reducing FPGA development difficulty, shortening engineering development time, and improving system verification efficiency have become crucial to solving this problem.
[0004] Using a higher-level programming language instead of a hardware description language for simulation module design is undoubtedly a better choice. Recently, DecaluweJ proposed a Python extension package called MyHDL, which provides powerful hardware and software description capabilities for the Python language. The MyHDL extension package provides an interface between hardware description languages and Python, supporting collaborative work between hardware engineering design and software simulation.
[0005] Research indicates that in the development of high-speed FPGA networks exceeding 40G, to support high-performance packet processing, the data transmission protocol between various acceleration units primarily adopts the high-bandwidth, low-latency AXI4-stream protocol, while interaction with external storage devices mainly relies on the high-performance address mapping protocol AXI4. Simulation design, which provides effective and reasonable input signals to the functional modules under test based on module design requirements, involves the generation of various data stream specifications, the management of dual-channel bus protocol interface signals for read / write operations, and the management of multi-queue descriptor signals in parallel data transmission. Therefore, existing simulation verification methods suffer from low development efficiency, high development difficulty, and difficulty in ensuring the comprehensiveness of the simulation design. Summary of the Invention
[0006] To address the aforementioned shortcomings of existing technologies, this invention proposes an AXI4 high-speed bus and multi-queue simulation verification method. This method, designed to meet the high-performance data packet processing requirements in high-speed network communication, supports FPGA engineering simulation verification of common Ethernet communication protocols and data packet processing operations through hardware and software collaboration. It provides a complete simulation verification process and modular design approach, supports more flexible and efficient simulation file design to save development and verification time, and provides configurable module parameters for upper-level users, facilitating multi-specification verification according to user needs.
[0007] This invention provides a simulation and verification method for the AXI4 high-speed bus and multi-queue system, utilizing the Python language to construct the AXI4 bus protocol simulation logic and multi-queue simulation logic; the method includes:
[0008] Based on the AXI4 bus protocol and Ethernet message structure, data packets supporting different formats are obtained; among them, the data packets are accompanied by AXI4 bus protocol control signals for parallel synchronous transmission.
[0009] By calling the Python MyHDL extension package and using the MyHDL signal transmission interface, the obtained data packets supporting different formats are interacted with the multi-queue signal under test. The output results are then observed and compared to see if they match the expected results.
[0010] As one improvement to the above technical solution, the process of obtaining data packets supporting different formats based on the AXI4 bus protocol and Ethernet message structure is as follows:
[0011] Based on the AXI4 bus protocol and Ethernet message structure, construct a data packet frame structure class and a signal generation function;
[0012] The frame structure class is encapsulated layer by layer to generate data packets of different formats, call the signal generation function to generate a continuous data stream, and AXI4 bus data stream control signals for parallel transmission.
[0013] By combining the above two methods independently or in any combination with the AXI4 bus protocol or multiple queues, data packets supporting different formats can be obtained.
[0014] As an improvement to the above technical solution, the method further includes:
[0015] Based on the AXI4 bus protocol and Ethernet message structure, a frame structure class is constructed. Based on the frame structure class, a signal generation function is called in Python to construct the test signal frame structure. The test signal frame structure is then encapsulated layer by layer from high to low using class inheritance.
[0016] Call the signal generation function to generate the data packet to be tested and the corresponding AXI4 bus control signal, and combine the two to obtain a continuous data packet to be tested;
[0017] The comparison results of the layer address, frame start flag, frame end flag, and valid fields of the observed data packets supporting different formats and the continuous test data packets are then observed to see if the comparison results are the same as the expected results.
[0018] This invention also provides an AXI4 high-speed bus and multi-queue simulation verification system, which includes:
[0019] The software packet sending test module is used to obtain data packets supporting different formats according to the AXI4 bus protocol and Ethernet message structure, and to send data packets supporting different formats; wherein, the data packets are accompanied by AXI4 bus protocol control signals for parallel synchronous transmission; and
[0020] The multi-queue simulation module is used to call the Python MyHDL extension package. Through the MyHDL signal transmission interface, it interacts with the multi-queue signal under test, which supports different data packets, and observes and compares whether the output results are the same as the expected results.
[0021] As one improvement to the above technical solution, the specific process of the software packet sending and testing module is as follows:
[0022] Based on the AXI4 bus protocol and Ethernet message structure, construct a data packet frame structure class and a signal generation function;
[0023] The frame structure class is encapsulated layer by layer to generate data packets of different formats, call the signal generation function to generate a continuous data stream, and AXI4 bus data stream control signals for parallel transmission.
[0024] By combining the above two methods independently or in any combination with the AXI4 bus protocol or multiple queues, data packets supporting different formats can be obtained.
[0025] As an improvement to the above technical solution, the system further includes:
[0026] The AXI4 bus protocol simulation module is used to construct a frame structure class based on the AXI4 bus protocol and Ethernet message structure. Based on the frame structure class, it uses Python to call the signal generation function to construct the test signal frame structure, and encapsulates it layer by layer from high to low level in the form of class inheritance to obtain the encapsulated test signal frame structure.
[0027] Call the signal generation function to generate the data packet to be tested and the corresponding AXI4 bus control signal, and combine the two to obtain a continuous data packet to be tested;
[0028] The comparison results of the layer address, frame start flag, frame end flag, and valid fields of the observed data packets supporting different formats and the continuous test data packets are then observed to see if the comparison results are the same as the expected results.
[0029] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described thereon.
[0030] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the method described thereon.
[0031] The advantages of this invention compared to the prior art are:
[0032] 1. The task invocation based on the Python extension package MyHDL gives the method of this invention good visibility and adjustability, enabling both developers and testers to understand the test logic well;
[0033] 2. Modular design of the high-speed network communication system verification platform, encapsulating simulation of common engineering units such as data packet generation, queue management, bus protocol interface, and DMA data transfer, and flexibly combining various simulation modules through decorators, function calls, class inheritance, etc., to enhance the reusability of the simulation system;
[0034] 3. By providing the MyHDL signal transmission interface as the main parameter interface, users can easily make modifications on the software side, thereby performing multi-specification tests according to requirements and improving the comprehensiveness of the tests;
[0035] 4. The method of this invention proposes an AXI4 high-speed bus and multi-queue simulation verification method for bus protocol access and multi-queue management in FPGA network side development, which improves the flexibility of simulation test case design, thereby reducing the difficulty of simulation design, shortening the development cycle, and ensuring the comprehensiveness of simulation verification.
[0036] 5. The method of this invention utilizes the Python language and its MyHDL library to design modular simulation units for data flow construction, bus protocol interaction, and queue management logic. In actual simulation case design, the various simulation units are flexibly combined through class inheritance, function calls, and other methods.
[0037] 6. The method of the present invention supports the development of complex simulation logic, supports a wider range of functional verification, reduces the complexity of test case development, and improves development efficiency. Attached Figure Description
[0038] Figure 1 This is a flowchart of an AXI4 high-speed bus and multi-queue simulation verification method according to the present invention;
[0039] Figure 2 This is a structural diagram of the AXI4 high-speed bus and multi-queue simulation verification method of the present invention for functional testing of FPGA;
[0040] Figure 3 This is a diagram of the data frame encapsulation structure. Figure 4 The subgraph first generates the data packet structure, then generates the data stream;
[0041] Figure 4 It is a data flow generation structure diagram;
[0042] Figure 5 This is the internal logic diagram of the write operation of the AXI4 bus signal generation function;
[0043] Figure 6 This is a simulation design diagram for multi-queue management. Detailed Implementation
[0044] The present invention will now be further described with reference to the accompanying drawings.
[0045] This invention provides a simulation and verification method for the AXI4 high-speed bus and multi-queue system. By utilizing the object-oriented structural features of the Python language, the simulation logic for the AXI4 high-speed bus protocol and multi-queue management is constructed, thereby enabling rapid simulation and verification of the functional modules of the FPGA network acceleration card.
[0046] This paper describes a test module designed for high-performance network processing using Python and the corresponding MyHDL library. It can use the generated continuous data stream, either alone or after being concatenated with the AXI4 high-speed bus protocol or multiple queues, as the input data packet required for testing. It supports different formats and uses them as test modules to support high-performance simulation verification of multiple queues, effectively improving the efficiency of FPGA network development and verification. Compared with traditional simulation testing methods, it has the characteristics of flexible and convenient simulation test cases and high simulation verification efficiency.
[0047] This invention provides a simulation and verification method for the AXI4 high-speed bus and multi-queue system, utilizing the Python language to construct the AXI4 bus protocol simulation logic and multi-queue simulation logic; the method includes:
[0048] Based on the AXI4 bus protocol and Ethernet message structure, data packets supporting different formats are obtained; among them, the data packets are accompanied by AXI4 bus protocol control signals for parallel synchronous transmission.
[0049] Specifically, based on the AXI4 bus protocol and Ethernet message structure, a data packet frame structure class and a signal generation function are constructed;
[0050] The frame structure class is encapsulated layer by layer to generate data packets of different formats, call the signal generation function to generate a continuous data stream, and AXI4 bus data stream control signals for parallel transmission.
[0051] By combining the above two methods independently or in any combination, and arbitrarily integrating them with the AXI4 bus protocol or multi-queue, data packets supporting different formats can be obtained. The throughput and size of these data packets are controlled through a parameter interface.
[0052] By calling the Python MyHDL extension package and using the MyHDL signal transmission interface, the obtained data packets supporting different formats are interacted with the multi-queue signal under test. The output results are then observed and compared to see if they match the expected results.
[0053] The method further includes: constructing a frame structure class according to the AXI4 bus protocol and Ethernet message structure; constructing a test signal frame structure by calling a signal generation function based on Python according to the frame structure class; and encapsulating the test signal frame structure layer by layer from high to low in the manner of class inheritance.
[0054] Call the signal generation function to generate the data packet to be tested and the corresponding AXI4 bus control signal, and combine the two to obtain a continuous data packet to be tested;
[0055] The comparison results of the layer address, frame start flag, frame end flag, and valid fields of the observed data packets supporting different formats and the continuous test data packets are then observed to see if the comparison results are the same as the expected results.
[0056] This invention also provides an AXI4 high-speed bus and multi-queue simulation verification system, which includes:
[0057] The software packet sending test module is used to obtain data packets that support different formats according to the AXI4 bus protocol and Ethernet message structure, and send data packets that support different formats; wherein, the data packets are accompanied by AXI4 bus protocol control signals for parallel synchronous transmission.
[0058] Specifically, based on the AXI4 bus protocol and Ethernet message structure, a data packet frame structure class and a signal generation function are constructed;
[0059] The frame structure class is encapsulated layer by layer to generate data packets of different formats, call the signal generation function to generate a continuous data stream, and AXI4 bus data stream control signals for parallel transmission.
[0060] By combining the above two methods independently or in any combination, and arbitrarily combining them with the AXI4 bus protocol or multi-queue, data packets supporting different formats can be obtained.
[0061] The multi-queue simulation module is used to call the Python MyHDL extension package. Through the MyHDL signal transmission interface, it interacts with the multi-queue signal under test, which supports different data packets, and observes and compares whether the output results are the same as the expected results.
[0062] The system further includes: an AXI4 bus protocol simulation module, used to construct a frame structure class based on the AXI4 bus protocol and Ethernet message structure; based on the frame structure class, using Python, to call the signal generation function to construct a test signal frame structure, and to encapsulate it layer by layer from high to low level in the manner of class inheritance to obtain the encapsulated test signal frame structure;
[0063] Call the signal generation function to generate the data packet to be tested and the corresponding AXI4 bus control signal, and combine the two to obtain a continuous data packet to be tested;
[0064] The comparison results of the layer address, frame start flag, frame end flag, and valid fields of the observed data packets supporting different formats and the continuous test data packets are then observed to see if the comparison results are the same as the expected results.
[0065] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the methods described above.
[0066] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the method described thereon.
[0067] Among them, AXI4 serves as the main interface for data transmission between the acceleration unit and the external storage module in the FPGA. Its stream mode transmission protocol, AXI4-stream, is used for data interaction between functional modules inside the FPGA. Therefore, AXI4 high-speed bus protocol signals are generated according to the handshake logic, and bidirectional interface signals on the host side or slave side in the read / write dual channel are selected through the parameter configuration interface.
[0068] The test cases achieve multi-queue simulation through descriptor queues, completion queues, event management queues, and corresponding configurations.
[0069] However, traditional simulation logic development using Verilog or VHDL, due to the structural characteristics of hardware languages, often only allows for the individual simulation of each functional module within the FPGA. Even repetitive logic implementations cannot be easily called across multiple simulation files, impacting development progress. Furthermore, the simple language design rules make it difficult to support complex simulation designs for each functional module within the FPGA, compromising the comprehensiveness of the simulation design. The software-based simulation verification system leverages the powerful functions and class library resources of the Python language, reducing the development difficulty of simulation modules. It also constructs a data transmission channel between hardware engineering and software simulation through the task calls `to_myhdl` and `from_myhdl` of the Python extension package MyHDL, thereby achieving Python-based hardware and software co-simulation.
[0070] The simulation verification method of this invention is based on existing hardware simulation verification processes, and by analogy with the language characteristics of Python and Verilog, proposes a joint simulation verification method using Verilog and Python for packet processing. The specific process of this method includes:
[0071] First, list the module's input and output interfaces according to the requirements;
[0072] Secondly, modules are divided according to the functions of the design units, and combinational logic modules with high algorithm complexity and insensitivity to timing are designed using the Python language;
[0073] Then, the logic is converted to the corresponding hardware language implementation using the toVerilog() function of the MyHDL extension package, and the converted logic unit is tested and debugged according to the hardware description language design concept.
[0074] Then, the hardware engineering module of the Verilog design is added; to simplify the development cycle, in the simulation verification part, the hardware simulation verification platform is built using Python, the input interface signals are assigned, and the synchronization relationship is set according to the engineering design requirements.
[0075] Finally, simulation verification was performed according to the software and hardware co-simulation process.
[0076] When simulation test results are incorrect or do not meet system design requirements, the engineering logic or simulation code should be readjusted according to the problem.
[0077] To facilitate the use of hardware integrated development environments such as Vivado and ISE, the Python-based simulation test files can also be converted into Verilog code after the simulation passes.
[0078] like Figure 2 As shown, the software and hardware engineering code is divided according to the system design. Testing of the FPGA functional units mainly consists of three parts: the hardware engineering module (module.v), the software simulation file (test_module.py), and the top-level test file connecting the software and hardware interfaces (testbench.v). The collaborative relationship among these three is as follows: Figure 2 As shown.
[0079] The hardware engineering module is generated in two main ways: one is by directly writing engineering code in Verilog; the other is by writing code in Python according to the design logic and then converting it into Verilog code using MyHDL's tooverilog() function.
[0080] Due to significant differences in coding standards between Python and hardware description languages such as Verilog, direct conversion may result in logical errors. To ensure accuracy and flexibility in design, the hardware engineering module primarily utilizes hardware description languages. Simulation design, on the other hand, mainly generates matching interface signals and does not require concern for the internal logic's validity. Therefore, using Python improves the efficiency of simulation design and development.
[0081] The top-level test file is mainly used for the interface signal transmission of hardware and software connectivity. The top-level test file includes: the from_myhdl module, the to_myhdl module, and the hardware engineering module;
[0082] The from_myhdl module is used to transmit input signals for Python software design. Its simulation design function is to simulate changes in input signals. The from_myhdl module can send continuously changing input signals generated by the software to the input interface of the hardware unit.
[0083] Correspondingly, the to_myhdl module is used to receive the output signal from the hardware unit;
[0084] Similar to traditional hardware simulation, the simulation file also needs to include calls to the hardware engineering modules.
[0085] Finally, the Verilog system tasks $dumpfile() and $dumpvars() are introduced to generate simulation files. $dumpfile() is used to create an executable simulation record file based on the current test, which is used by gtkwave commands to observe the simulation waveforms. gtkwave supports file types such as vcd, lxt, and lxt2. lxt2 is a compressed format that occupies less space, so the method of this invention adopts the lxt2 format.
[0086] $dumpvars() records the input and output interface signals for which simulation waveform data needs to be saved in the file specified by $dumpfile().
[0087] The core of this invention is a simulation system design based on Python. Traditional simulation designs using hardware description languages suffer from limitations. Due to the simple structure of these languages, which are designed for low-level hardware, the logic functions cannot be flexibly called across multiple simulation units. Therefore, it often requires separate simulation design for each functional unit in an FPGA project, resulting in significant redundancy in simulation verification and long development cycles for complex simulation logic. In contrast, this invention, based on the high-performance data packet processing requirements of high-speed network communication, builds a universal simulation verification system. It utilizes Python's class construction and function features to modularize simulation files, then integrates them through decorators, function calls, and class inheritance to generate more flexible and complex simulation logic. Furthermore, it leverages the hardware-specific functions and data types provided by the MyHDL extension package to support the implementation of software simulation in hardware engineering. Research shows that current FPGA-based network communication accelerator cards primarily construct the main data transmission path from optical port transceiver to PCIe interaction with the host computer. The specific design includes data packet parsing, splitting, filtering, and matching, allowing for better verification of the performance of each functional unit in the FPGA project.
[0088] The first step is the design of data stream generation. This invention uses Python to design a software packet sending test model for hardware functional module testing. It employs object-oriented concepts and structural features, calling signal generation functions to construct two- and three-layer data packets. The data packets are designed in layers, and then encapsulated layer by layer through class inheritance.
[0089] Specifically, such as Figure 3 As shown, three class files and data stream generation files are designed for xgmii, ETH, and IP layer data packets (general standard format). The three data packets are encapsulated layer by layer from high to low using class inheritance.
[0090] like Figure 3As shown, for xgmii data stream signals that require testing with specific IP and ETH identifiers, specific flag information can be input according to the provided parameter interface. The protocol layer is then encapsulated layer by layer in a class inheritance manner to generate test data signals.
[0091] Figure 4 This demonstrates the composition of the frame structure class and frame generation functions in the library files, as well as the data stream generation process. The frame structure class provides an interface for configuring Ethernet frame parameters and optional user-defined field settings. The signal generation function calls output the configured frame fields and synchronously output control signals. In XGMII data generation, this corresponds to generating XGMII control signals, while at the MAC layer, it synchronously outputs data packets with the configured MAC layer address and signals such as SOP (Start of Frame), EOP (End of Frame), and Valid (Valid Field). Finally, the data stream generation function (which encompasses all signals, while the data stream generation function specifically refers to data stream signals) generates continuous data packets and sends them to the input signal interface of the hardware module under test.
[0092] like Figure 4 As shown, the user designs the required Ethernet frame format according to the Ethernet frame configuration interface, calls the signal generation function to generate specific data streams and corresponding control signals, and generates continuously output data packets through the data stream generation function, which are sent to the input signal interface of the hardware module under test. The hardware module under test reads the signal to complete the data interaction with the simulation unit.
[0093] If only the xgmii signal input is to be verified, the class(xgmii) must first be imported, and the preamble must be set according to the provided configuration interface, or private fields such as timestamps must be added. Then, in the data stream generation function, the corresponding generation function xgmii_create is called by selecting the frame type to generate the MAC layer interface data signal and the corresponding control signal.
[0094] If joint simulation testing of multiple modules is required, and the data packets are required to contain valid xgmii fields, MAC layer addresses and VLAN fields, as well as IP layer header information, then the IP frame structure class, ethFrame class, and xgmii class need to be set layer by layer. Then, the IP layer field information and MAC layer field information are all inherited into the xgmii generated frame through class inheritance. Finally, the generation function is called to generate an xgmii data stream with Layer 2 and Layer 3 protocol characteristics.
[0095] To support comprehensive testing and effectively ensure the logical correctness of hardware modules, multiple control parameter interfaces are provided in the data stream generation function. The frame interval field can be adjusted through the flow control interface to control the flow rate. The packet length option is provided to configure the payload field. Alternatively, the provided packet length field can be used as a basis to configure the payload field with incrementing, decrementing, or fixed length through mode selection. The specific payload information adopts a regular design to facilitate packet loss detection for users.
[0096] In the development of smart network cards based on FPGA high-performance packet processing, the main bus protocols used are AXI4 (used as an internal data transmission bus), AXI4-lite (a lightweight address-mapped single-transmission interface, commonly used for register read / write design), and AXIS (stream-mode data transmission bus). These protocols are complex in structure and frequently referenced. Based on hardware description language-specific simulation design of functional units, it is necessary to design bus protocol generation signals separately for each module, redesign the address-data matching relationship each time, and ensure the validity of handshake signals to guarantee synchronous input of corresponding signals. This leads to high complexity in simulation design. The AXI4 protocol can be divided into read data channels and write data channels according to data flow direction, and into master side and slave side according to the operation object. The master side is the interface data transmission module connecting the FPGA board to DDR, while the slave side represents the DDR RAM space. This invention adopts a modular design for the AXI4 series bus protocols, generating read / write operation signals on both the master and slave sides through a defined handshake. In the simulation file design, bus protocol signals can be generated flexibly and efficiently through function calls.
[0097] The AXI4 bus protocol simulation module mainly consists of two parts: the AXIMaster class and the AXIRam class. The AXIMaster class is responsible for supporting the generation of data transmission and reception path signals on the host side. It mainly consists of four parts: read / write path initialization function, signal wait function, signal extraction function, and bus signal generation function. The initialization function allocates initial signal values for read (write) operations; the signal wait function is called when there is no data transmission, setting each signal interface to zero; the signal extraction function extracts data from the signal list for signal verification; the generation function generates corresponding read / write operation signals based on the initial signal values and the selected read / write operation mode. The generation function instantiates chip select enable logic, write logic, write response logic, write address interface logic, write data interface logic, and write interface response logic, as well as corresponding logic units related to read operations and their responses. Taking data transmission as an example, the write channel initialization function `init_write(address,data,burst=0b01,size=None,lock=0b0,cache=0b0011,prot=0b010,qos=0b0000,region=0b0000,user=None)` is called first. The set address and initial data values are placed into the bus signal list according to the interface order. Other signals can be initialized with default values, or according to the AXI4 bus protocol specification, a burst mode setting of up to 256 cycles is supported, and the selection of fixed burst, incremental burst or loopback burst is supported. Then, based on this value, the bus signal generation function `create_logic()` is called to generate a continuous bus write signal data stream. The generation function contains the host-side read and write signal generation logic, and the read or write logic signal can be selected by configuring the enabled port.
[0098] The specific generation logic is as follows: Figure 5 As shown, when a read / write operation is determined based on the chip select enable signal input from the function call, taking a write operation as an example, the `write_logic` function extracts the initialization parameter signals and the initial handshake signal values. To ensure efficient data transmission, alignment is performed based on the provided address and data, generating address bus and data bus signal lists, and extracting the burst size and depth to determine the burst transmission cycle. `write_resp` sets the burst completion list once based on the burst completion status. Next, a continuous list of address and data signals is generated based on the burst length, and a corresponding continuous response signal stream is generated based on the burst completion status. Finally, the generator encapsulates the sequential data streams in the list and parallelizes them according to the bus protocol order to match the FPGA's parallel signal interface. When there is no data transmission requirement, a signal wait function can be called to construct an idle state.
[0099] Correspondingly, the AXIRam class is used on the DDR side to generate DDR data write and fetch signals. It updates the data and address in the DDR by calling Python's mmap library functions in the form of a ring buffer operation. Furthermore, it generates the corresponding handshake signals using the designed AXIRam signal generation function `create_port`. Finally, in the design of the corresponding test module, the generated bus handshake signals are synchronized based on the clock signal edge triggering state.
[0100] like Figure 6 As shown, compared to the pipeline mechanism of a CPU, FPGAs feature parallel transmission. To meet high throughput requirements, current high-performance FPGA accelerator cards typically offload load balancing to hardware implementation, necessitating multi-queue management within the FPGA. This invention designs a queue management simulation module to verify high-performance queue scheduling logic. It mainly includes three types: queue management, completion queue management, and event queue management, used to update the transmission status of data in the queues. Taking the queue management module as an example, a queue management list is designed in the hardware engineering. Each queue entry consists of parameters such as queue index, queue address, operation table index, descriptor read / write pointer address, enable port, and active status. For packet reception, a hash load balancing algorithm allocates transmission queues to data packets. The queue management module checks the queue enable status and pointer spacing to determine if transmission is allowed in that queue. If transmission is permitted, a corresponding transmission channel is allocated to the data packet, and the header pointer address is updated. The driver updates the corresponding tail pointer status based on the data packet reception status and dequeues the data packet. Based on this characteristic, a corresponding queue management simulation module is set up to simulate the data packet reception state. In this module, a queue operation list with a maximum of 8192 bits is designed. When a data packet is received, the corresponding reception queue information is added to the beginning of the operation list. The queue information is managed according to the FIFO first-in-first-out structure. The queue update at the exit position of the operation list is processed in sequence, the queue tail pointer is updated, and the processed queue entries are released to achieve efficient management of the queue state.
[0101] There are two key technical aspects to the specific module design. First, there's the parallel processing of the mapped FPGA, which utilizes the `@always` and `@always_comb` decorators from MyHDL, corresponding to the implementation of sequential and combinational logic, respectively. Second, there's the continuous data stream transmission. Recording generated data in a list and returning the entire list after simulation would consume significant memory resources, and transmitting a large data list at once is prone to segmentation faults. This invention employs a `yield` instruction to construct a generator. `yield` is equivalent to `return`, returning a value and remembering the return position. In the next iteration, the code starts execution from the statement following `yield`. This generator design allows for the iterative calculation of subsequent generated data while continuously returning data signals, thus ensuring the stability of signal transmission.
[0102] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to the embodiments, those skilled in the art should understand that modifications or equivalent substitutions to the technical solutions of the present invention do not depart from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.
Claims
1. A simulation and verification method for the AXI4 high-speed bus and multi-queue system, which utilizes Python to construct the AXI4 bus protocol simulation logic and multi-queue simulation logic; the method includes: Based on the AXI4 bus protocol and Ethernet message structure, data packets supporting different formats are obtained; among them, the data packets are accompanied by AXI4 bus protocol control signals for parallel synchronous transmission. The Python MyHDL extension package is called, and the MyHDL signal transmission interface is used to interact with the multi-queue signal under test, which supports different formats of data packets. The output results are observed and compared to see if they are the same as expected. The output results include layer address, frame start flag, frame end flag and valid fields.
2. The AXI4 high-speed bus and multi-queue simulation verification method according to claim 1, characterized in that, The process of obtaining data packets supporting different formats based on the AXI4 bus protocol and Ethernet message structure is as follows: Based on the AXI4 bus protocol and Ethernet message structure, construct a data packet frame structure class and a signal generation function; The frame structure class is encapsulated layer by layer to generate data packets of different formats, call the signal generation function to generate a continuous data stream, and AXI4 bus data stream control signals for parallel synchronous transmission. By combining the data stream and AXI4 bus data stream control signals with the AXI4 bus protocol, or by combining the data stream and AXI4 bus data stream control signals with multiple queues, data packets supporting different formats can be obtained.
3. The AXI4 high-speed bus and multi-queue simulation verification method according to claim 1, characterized in that, The method further includes: Based on the AXI4 bus protocol and Ethernet message structure, a frame structure class is constructed. Based on the frame structure class, a signal generation function is called in Python to construct the test signal frame structure. The test signal frame structure is then encapsulated layer by layer from high to low using class inheritance. Call the signal generation function to generate the data packet to be tested and the corresponding AXI4 bus control signal, and combine the two to obtain a continuous data packet to be tested; The comparison results of the observed address information, frame start marker, frame end marker and payload feature fields of the data packets supporting different formats, as well as the frame interval of the continuous data stream, are then observed to see if the comparison results are the same as the expected results.
4. An AXI4 high-speed bus and multi-queue simulation verification system, characterized in that, The system includes: The software packet sending test module is used to obtain data packets supporting different formats according to the AXI4 bus protocol and Ethernet message structure, and to send data packets supporting different formats; wherein, the data packets are accompanied by AXI4 bus protocol control signals for parallel synchronous transmission; and The multi-queue simulation module is used to call the Python MyHDL extension package. Through the MyHDL signal transmission interface, it interacts with the multi-queue signal under test, which supports different data packets, and observes and compares whether the output results are the same as the expected results. The output results include layer address, frame start flag, frame end symbol, and valid fields.
5. The AXI4 high-speed bus and multi-queue simulation verification system according to claim 4, characterized in that, The specific process of the software packet sending test module is as follows: Based on the AXI4 bus protocol and Ethernet message structure, construct a data packet frame structure class and a signal generation function; The frame structure class is encapsulated layer by layer to generate data packets of different formats, call the signal generation function to generate a continuous data stream, and AXI4 bus data stream control signals for parallel transmission. By combining the data stream and AXI4 bus data stream control signals with the AXI4 bus protocol, or by combining the data stream and AXI4 bus data stream control signals with multiple queues, data packets supporting different formats can be obtained.
6. The AXI4 high-speed bus and multi-queue simulation verification system according to claim 4, characterized in that, The system also includes: The AXI4 bus protocol simulation module is used to construct a frame structure class based on the AXI4 bus protocol and Ethernet message structure. Based on the frame structure class, it uses Python to call the signal generation function to construct the test signal frame structure, and encapsulates it layer by layer from high to low level in the form of class inheritance to obtain the encapsulated test signal frame structure. Call the signal generation function to generate the data packet to be tested and the corresponding AXI4 bus control signal, and combine the two to obtain a continuous test data stream; The comparison results of the observed address information, frame start marker, frame end marker and payload feature fields of the data packets supporting different formats, as well as the frame interval of the continuous data stream, are then observed to see if the comparison results are the same as the expected results.
7. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1-3.
8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1-3.
Citation Information
Patent Citations
High-speed Ethernet frame reconstruction system based on FPGA
CN112100119A
Software and hardware co-simulation verification method and device and medium
CN112861468A