Method, device and equipment for debugging prototype verification signal based on ZYNQ
By using ZYNQ's external memory DDR in the FPGA prototype verification system to store debug signal data, the problem of ILA resource limitation is solved, more efficient signal processing and storage is achieved, and debugging efficiency is improved.
Patent Information
- Application Number
- CN202510543219.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-28
- Publication Date
- 2025-08-12
AI Technical Summary
The debugging efficiency of existing FPGA prototype verification systems is low, mainly because ILA relies on limited internal memory resources, resulting in limited sampling depth, occupies too much logical resources, and the FPGA bitstream needs to be recompiled when debugging settings are modified, which affects the design progress.
The ZYNQ-based prototype verification signal debugging method is adopted to store the collected debug signal data through the external memory DDR, and the control and scheduling module of the programmable logic PL terminal receives the trigger conditions and sampling depth. The trigger signal generation module generates the trigger signal and sends it to the DDR through the AXI-HP interface to avoid consuming internal storage logic resources.
It significantly improves the number of signals that can be processed during the debugging process, provides large-capacity waveform storage space, ensures complete and detailed data, and greatly improves the debugging efficiency of the prototype verification system.
Smart Images
Figure CN120470993A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of FPGA prototype verification technology, for example, to a ZYNQ-based prototype verification signal debugging method, device, and equipment. Background Art
[0002] With the rapid development of the integrated circuit industry, the scale and complexity of chips are growing exponentially. In large-scale integrated circuit design, prototype verification technology has become an indispensable and critical step to improve tapeout success rates. However, the problem of low debugging efficiency is becoming increasingly prominent, becoming a major bottleneck restricting design efficiency and progress.
[0003] The traditional debugging method uses an integrated logic analyzer (ILA) embedded within the FPGA. However, using ILA to debug FPGA prototype verification systems has several drawbacks. First, because ILA relies on the FPGA's internal memory resources to store debug data, FPGA internal memory resources are very limited, resulting in a limited sampling depth. Furthermore, as the number of sampled signals and the bit width increase, the sampling depth decreases, making it unable to meet the debugging requirements of prototype verification systems. Second, ILA consumes FPGA logic resources. The greater the number of sampled signals and the sampling depth, the more logic resources are required. When the FPGA logic resource utilization is high, excessive logic resource usage by ILA may lead to FPGA routing difficulties and difficulty in timing convergence. Third, because the number of sampled signals is limited, each modification of debug settings or the addition of new observation signals typically requires recompiling and regenerating the FPGA bitstream, which significantly increases debugging time and impacts design progress.
[0004] Therefore, the existing prototype verification process has the problem of low debugging efficiency.
[0005] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of this application. Summary of the Invention
[0006] In order to provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. The summary is not an extensive review, nor is it intended to identify key / critical elements or delineate the scope of protection of these embodiments, but rather serves as a prelude to the detailed description that follows.
[0007] The ZYNQ-based prototype verification signal debugging method, device, and equipment provided by the embodiments of the present disclosure solve the problem of low debugging efficiency of the prototype verification system.
[0008] The ZYNQ-based prototype verification signal debugging method in the embodiment of the present disclosure includes:
[0009] The control and scheduling module in the programmable logic (PL) receives the trigger conditions, sampling depth, and trigger position issued by the software, sends the trigger conditions to the trigger signal generation module on the PL side, and sends the sampling depth and trigger position to the data acquisition module on the PL side;
[0010] The control and scheduling module in the programmable logic PL side forwards the data acquisition address and data acquisition command sent by the data acquisition module to the processing system PS;
[0011] The trigger signal generation module receives multiple debug signal data and extracts corresponding data from the debug signal data according to the sequence number of the trigger condition signal. The extracted data is then compared according to the trigger comparison type, trigger operator type, and trigger comparison value. When the trigger condition is met, a trigger signal is generated and sent to the data acquisition module.
[0012] The data acquisition module sends the received multiple debugging signal data to the DDR through the AXI-HP interface.
[0013] In some embodiments, the method further comprises:
[0014] The data acquisition module calculates the address of the debug signal data sent to the DDR, and based on the trigger signal, subtracts the trigger position k from the sampling depth m to obtain the number s, sends the debug signal data again s times, and sends the current data acquisition command and data acquisition address to the control and scheduling module.
[0015] In some embodiments, the method further comprises:
[0016] Write multiple debug signal data into the corresponding addresses of DDR one by one;
[0017] Before the trigger signal arrives, the data of each debug signal is cyclically overwritten and stored within a range of a sampling depth m.
[0018] When a trigger signal is received, each debug signal stores s cycles of data in the DDR.
[0019] In some embodiments, when the storage is completed, the storage address addrz1 of the first debug signal is recorded, and a read signal command is sent to the DDR;
[0020] DDR starts reading the data of the first signal, fetches data from address addrz1+1, takes out the data in the range of addrz1+1 to addr1+m, and then reads the data in addr1 to addrz1;
[0021] Take out the data of n debug signals in sequence and stop the DDR read operation.
[0022] The ZYNQ-based prototype verification signal debugging device in the embodiment of the present disclosure includes:
[0023] The control and scheduling module in the programmable logic (PL) side is used to receive the trigger conditions, sampling depth, and trigger position issued by the software, and send the trigger conditions to the trigger signal generation module on the PL side, and send the sampling depth and trigger position to the data acquisition module on the PL side;
[0024] The control and scheduling module in the programmable logic PL is used to forward the data acquisition address and data acquisition command sent by the data acquisition module to the processing system PS;
[0025] A trigger signal generation module is used to receive multiple debug signal data, extract corresponding data from the debug signal data according to the sequence number of the trigger condition signal, and then compare the extracted data according to the trigger comparison type, trigger operator type, and trigger comparison value. When the trigger condition is met, a trigger signal is generated and sent to the data acquisition module;
[0026] The data acquisition module is used to send the received multiple debugging signal data to the DDR through the AXI-HP interface.
[0027] In some embodiments, the data acquisition module is also used to calculate the address to which the debug signal data is sent in the DDR, and based on the trigger signal, subtract the trigger position k from the sampling depth m to obtain the number s, send the debug signal data again s times, and send the current data acquisition command and data acquisition address to the control and scheduling module.
[0028] In some embodiments, the data acquisition module is further configured to write the plurality of debug signal data into corresponding addresses of the DDR one by one;
[0029] Before the trigger signal arrives, the data of each debug signal is cyclically overwritten and stored within a range of a sampling depth m.
[0030] When a trigger signal is received, each debug signal stores s cycles of data in the DDR.
[0031] In some embodiments, when the storage is completed, the storage address addrz1 of the first debug signal is recorded, and a read signal command is sent to the DDR;
[0032] DDR starts reading the data of the first signal, fetches data from address addrz1+1, takes out the data in the range of addrz1+1 to addr1+m, and then reads the data in addr1 to addrz1;
[0033] Take out the data of n debug signals in sequence and stop the DDR read operation.
[0034] An electronic device provided by an embodiment of the present disclosure includes at least one processor;
[0035] and a memory communicatively coupled to the at least one processor;
[0036] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the above-mentioned ZYNQ-based prototype verification signal debugging method.
[0037] The storage medium provided by the embodiment of the present disclosure stores program instructions, which, when run, execute the above-mentioned ZYNQ-based prototype verification signal debugging method.
[0038] The ZYNQ-based prototype verification signal debugging method, apparatus, device, and storage medium provided in the embodiments of the present disclosure can achieve the following technical effects:
[0039] The ZYNQ-based prototype verification signal debugging method provided in the present disclosure uses an external memory DDR to store the collected debugging signal data without consuming the user's internal storage logic resources. It not only significantly increases the number of signals that can be processed during the debugging process, but also provides a large-capacity waveform storage space, ensuring that the stored data is more complete and detailed, thereby greatly improving the debugging efficiency of the prototype verification system.
[0040] The above general description and the following description are exemplary and explanatory only and are not intended to limit the present application. BRIEF DESCRIPTION OF THE DRAWINGS
[0041] One or more embodiments are exemplarily described by corresponding drawings. These exemplary descriptions and drawings do not limit the embodiments. Elements with the same reference numerals in the drawings are shown as similar elements. The drawings do not constitute a scale limitation. In addition,
[0042] Figure 1 This is a flowchart of a ZYNQ-based prototype verification signal debugging method provided by an embodiment of the present disclosure;
[0043] Figure 2 This is a block diagram of a debugging architecture design provided by an embodiment of the present disclosure;
[0044] Figure 3 This is a signal debugging software workflow diagram provided by an embodiment of the present disclosure;
[0045] Figure 4 This is a block diagram of an on-chip logic design provided by an embodiment of the present disclosure;
[0046] Figure 5 This is a logic flow chart of a DDR read and write strategy provided by an embodiment of the present disclosure;
[0047] Figure 6 It is a structural diagram of a ZYNQ-based prototype verification signal debugging device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION
[0048] In order to be able to understand the features and technical content of the embodiments of the present disclosure in more detail, the implementation of the embodiments of the present disclosure is described in detail below in conjunction with the accompanying drawings. The accompanying drawings are for reference only and are not used to limit the embodiments of the present disclosure. In the following technical description, for the sake of convenience of explanation, a full understanding of the disclosed embodiments is provided through multiple details. However, one or more embodiments can still be implemented without these details. In other cases, to simplify the drawings, well-known structures and devices can be simplified for display.
[0049] The terms "first," "second," and the like in the embodiments of the present disclosure are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate to facilitate the description of the embodiments of the present disclosure herein. Furthermore, the terms "including," "having," and any variations thereof are intended to cover non-exclusive inclusions.
[0050] Unless otherwise stated, the term "plurality" means two or more.
[0051] In the embodiment of the present disclosure, the character " / " indicates that the preceding and following objects are in an "or" relationship. For example, A / B means: A or B.
[0052] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.
[0053] The term "correspondence" may refer to an association relationship or a binding relationship. The correspondence between A and B means that there is an association relationship or a binding relationship between A and B.
[0054] In order to solve the above problems, the present disclosure provides a ZYNQ-based prototype verification signal debugging method, apparatus, device and storage medium.
[0055] The following describes the ZYNQ-based prototype verification signal debugging method, device, equipment, and storage medium provided by the embodiments of the present disclosure in conjunction with the accompanying drawings.
[0056] Figure 1This is a flowchart of a ZYNQ-based prototype verification signal debugging method provided by an embodiment of the present disclosure.
[0057] like Figure 1 As shown, the ZYNQ-based prototype verification signal debugging method may include:
[0058] S101: The control and scheduling module in the programmable logic (PL) receives the trigger condition, sampling depth, and trigger position issued by the software, sends the trigger condition to the trigger signal generation module in the PL, and sends the sampling depth and trigger position to the data acquisition module in the PL.
[0059] S102, the control and scheduling module in the programmable logic PL side forwards the data acquisition address and data acquisition command sent by the data acquisition module to the processing system PS;
[0060] S103: The trigger signal generation module receives multiple debug signal data and extracts corresponding data from the debug signal data according to the sequence number of the trigger condition signal. The extracted data is then compared according to the trigger comparison type, trigger operator type, and trigger comparison value. When the trigger condition is met, a trigger signal is generated and sent to the data acquisition module.
[0061] S104: The data acquisition module sends the received multiple debugging signal data to the DDR through the AXI-HP interface.
[0062] In some embodiments, Figure 1 The method may further include:
[0063] The data acquisition module calculates the address of the debug signal data sent to the DDR, and based on the trigger signal, subtracts the trigger position k from the sampling depth m to obtain the number s, sends the debug signal data again s times, and sends the current data acquisition command and data acquisition address to the control and scheduling module.
[0064] In some embodiments, Figure 1 The method may further include:
[0065] Write multiple debug signal data into the corresponding addresses of DDR one by one;
[0066] Before the trigger signal arrives, the data of each debug signal is cyclically overwritten and stored within a range of a sampling depth m.
[0067] When a trigger signal is received, each debug signal stores s cycles of data in the DDR.
[0068] In some embodiments, when the storage is completed, the storage address addrz1 of the first debug signal is recorded, and a read signal command is sent to the DDR;
[0069] DDR starts reading the data of the first signal, fetches data from address addrz1+1, takes out the data in the range of addrz1+1 to addr1+m, and then reads the data in addr1 to addrz1;
[0070] Take out the data of n debug signals in sequence and stop the DDR read operation.
[0071] Figure 2 This is a block diagram of a debugging architecture design provided by an embodiment of the present disclosure. Figure 3 This is a signal debugging software workflow diagram provided by an embodiment of the present disclosure. Figure 4 This is a block diagram of an on-chip logic design provided by an embodiment of the present disclosure. Figure 5 This is a DDR read and write strategy logic flow chart provided by the embodiment of the present disclosure, combined with Figures 2 to 5 ,right Figure 1 The method is further described in .
[0072] Specifically, Figure 3 The software workflow for signal debugging is described in detail. First, the RTL file under test is loaded into the software, and a complete hierarchy and signal list of the design under test are generated. Second, the debug signals to be viewed are selected in the list. The software automatically sorts the selected debug signals and saves the signal names and their corresponding serial numbers in a list. Third, the Vivado tool is called for synthesis, ultimately generating a bitstream file. Fourth, to debug, first configure the sampling depth and trigger position, then set the trigger conditions, including the signal, trigger comparison type, trigger operator type, and trigger comparison value. Then, click the trigger function and wait for the trigger. The trigger signal is the serial number in the second step. Fifth, when the trigger conditions are met, the waveform display window shows the data of the current debug signal.
[0073] Figure 4 The on-chip logic design is detailed, including the PS design, as well as the control and scheduling module, trigger signal generation module, and data acquisition module in the PL. First, information such as trigger conditions and debug signal data is transmitted between the software and the PS via Ethernet. Second, the DDR on the PS connects to the PL via the AXI-HP interface to transmit debug signal data. The PS connects to the PL via the AXI-GP interface to send trigger conditions and receive information such as data access commands and addresses.
[0074] The control and scheduling module in the PL first receives information such as the trigger condition, sampling depth, and trigger position, and sends the trigger condition to the trigger signal generation module, which in turn sends the sampling depth and trigger position to the data acquisition module. The data acquisition module then sends the data acquisition address and data acquisition command to the PS. The trigger signal generation module first receives n debug signal data, extracts the signal data according to the sequence number that serves as the trigger condition signal, and then compares the data according to the trigger comparison type, trigger operator type, and trigger comparison value. When the trigger condition is met, a trigger signal is generated. For example, if the trigger comparison type is set to single bit, the trigger operator type is "==", and the trigger comparison value is 1, then when the signal data is equal to 1, the trigger condition is met and a trigger signal is generated, setting the debug signal to 1. Finally, the trigger signal is sent to the data acquisition module.
[0075] The data acquisition module first sends the received n debug signal data to the DDR via the AXI-HP interface and calculates the address to be sent to the DDR. The initial address for each signal data transmission is addr1, addr2, ..., addrn, and each subsequent address is incremented by 1 based on the previous one. Then, until the trigger signal arrives, the number s is obtained by subtracting the trigger position k from the sampling depth m. Then, s debug signal data are sent again, and data transmission stops. The current data acquisition command and address are sent to the control and scheduling module.
[0076] Figure 5 The logical flow of the read and write strategy of the DDR memory is shown. First, n signal data are written one by one to the corresponding addresses addr1, addr2, ..., addrn of the DDR; before the trigger signal arrives, that is, the trigger signal is not 1, the data of each debug signal is cyclically overwritten and stored within a space with a sampling depth of m; when the trigger signal is 1, each debug signal stores s cycles of data in the DDR; after the storage is completed, the storage address addrz1 of the first signal at this time is recorded, and the read signal command is sent to the DDR; then, the DDR starts to read the data of the first signal, fetching data from the address addrz1+1, first fetching the data in the range of addrz1+1 to addr1+m, and then reading the data from addr1 to addrz1; finally, the data of n debug signals are fetched in sequence, and the fetch address is the fetch address of the previous signal plus m according to the above process. After fetching n times, the data of all debug signals are fetched and the DDR read operation stops.
[0077] The prototype verification signal debugging method based on ZYNQ provided in the present disclosure mainly includes the following design aspects. Its debugging architecture includes two parts: software and ZYNQ on-chip logic design.
[0078] The software part is used to select the debug signal, configure the trigger condition, sampling depth and trigger position, and display the received debug signal data.
[0079] The Zynq on-chip logic design has multiple functions. First, it transmits signals such as trigger conditions configured by software through the Zynq Processing System (PS). Second, it designs DDR data read and write strategies, controls the DDR memory on the PS side to store debug signal data, and reads data from it and transmits it to the software. Third, it receives debug signal data and commands transmitted through the Zynq Programmable Logic (PL). Fourth, the PL side receives signals such as trigger conditions and uses the received trigger conditions to generate trigger signals. Fifth, the data acquisition module accurately collects debug data and transmits the data to the DDR on the PS side.
[0080] The ZYNQ-based prototype verification signal debugging method provided in the present disclosure uses an external memory DDR to store the collected debugging signal data without consuming the user's internal storage logic resources. It not only significantly increases the number of signals that can be processed during the debugging process, but also provides a large-capacity waveform storage space, ensuring that the stored data is more complete and detailed, thereby greatly improving the debugging efficiency of the prototype verification system.
[0081] and Figure 1 Corresponding to the prototype verification signal debugging method based on ZYNQ, the present disclosure further provides a prototype verification signal debugging device based on ZYNQ, which may specifically include:
[0082] The control and scheduling module in the programmable logic (PL) side is used to receive the trigger conditions, sampling depth, and trigger position issued by the software, and send the trigger conditions to the trigger signal generation module on the PL side, and send the sampling depth and trigger position to the data acquisition module on the PL side;
[0083] The control and scheduling module in the programmable logic PL is used to forward the data acquisition address and data acquisition command sent by the data acquisition module to the processing system PS;
[0084] A trigger signal generation module is used to receive multiple debug signal data, extract corresponding data from the debug signal data according to the sequence number of the trigger condition signal, and then compare the extracted data according to the trigger comparison type, trigger operator type, and trigger comparison value. When the trigger condition is met, a trigger signal is generated and sent to the data acquisition module;
[0085] The data acquisition module is used to send the received multiple debugging signal data to the DDR through the AXI-HP interface.
[0086] In some embodiments, the data acquisition module is also used to calculate the address to which the debug signal data is sent in the DDR, and based on the trigger signal, subtract the trigger position k from the sampling depth m to obtain the number s, send the debug signal data again s times, and send the current data acquisition command and data acquisition address to the control and scheduling module.
[0087] In some embodiments, the data acquisition module is further configured to write the plurality of debug signal data into corresponding addresses of the DDR one by one;
[0088] Before the trigger signal arrives, the data of each debug signal is cyclically overwritten and stored within a range of a sampling depth m.
[0089] When a trigger signal is received, each debug signal stores s cycles of data in the DDR.
[0090] In some embodiments, when the storage is completed, the storage address addrz1 of the first debug signal is recorded, and a read signal command is sent to the DDR;
[0091] DDR starts reading the data of the first signal, fetches data from address addrz1+1, takes out the data in the range of addrz1+1 to addr1+m, and then reads the data in addr1 to addrz1;
[0092] Take out the data of n debug signals in sequence and stop the DDR read operation.
[0093] Combine Figure 6 As shown, the embodiment of the present disclosure also provides a ZYNQ-based prototype verification signal debugging device 600, including a processor 604 and a memory 601. Optionally, the system may also include a communication interface 602 and a bus 603. The processor 604, the communication interface 602, and the memory 601 can communicate with each other through the bus 603. The communication interface 602 can be used for information transmission. The processor 604 can call the logic instructions in the memory 601 to execute the ZYNQ-based prototype verification signal debugging method of the above embodiment.
[0094] In addition, the logic instructions in the memory 601 can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product.
[0095] Memory 601, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of the present disclosure. Processor 604 executes the program instructions / modules stored in memory 601 to perform functional applications and data processing, thereby implementing the ZYNQ-based prototype verification signal debugging method in the above-mentioned embodiments.
[0096] The memory 601 may include a program storage area and a data storage area. The program storage area may store an operating system and at least one application required for a function; the data storage area may store data generated based on the use of the terminal device. Furthermore, the memory 601 may include a high-speed random access memory and a non-volatile memory.
[0097] An embodiment of the present disclosure provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured to execute a ZYNQ-based prototype verification signal debugging method.
[0098] The aforementioned computer-readable storage medium may be a transient computer-readable storage medium or a non-transitory computer-readable storage medium.
[0099] The technical solution of the embodiments of the present disclosure may be embodied in the form of a software product, which is stored in a storage medium and includes one or more instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method of the embodiments of the present disclosure. The aforementioned storage medium may be a non-transitory storage medium, including: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program code, or a transient storage medium.
[0100] The above description and accompanying drawings sufficiently illustrate the embodiments of the present disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, process, and other changes. The embodiments represent only possible variations. Unless expressly required, individual components and functions are optional, and the order of operations may vary. Portions and features of some embodiments may be included in or replaced with portions and features of other embodiments. As used in the description of the embodiments, unless the context clearly indicates otherwise, the singular forms "a," "an," and "the" are intended to include the plural forms as well. Similarly, the term "and / or" as used in this application means including any and all possible combinations of one or more of the associated listed items. In addition, when used in this application, the term "comprise" and its variations "comprises" and / or comprising refer to the presence of the stated features, wholes, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or groups thereof. In the absence of further limitations, the phrase "comprising a..." does not preclude the presence of other identical elements in the process, method, or device comprising the elements. In this document, each embodiment may focus on the differences from other embodiments, and similar parts between the embodiments can be referenced to each other. For methods, products, etc. disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, then the relevant parts can be referenced to the description of the method section.
[0101] In the embodiments disclosed herein, the disclosed methods and products (including but not limited to devices, equipment, etc.) can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units can be merely a logical functional division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, 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. 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 they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to implement this embodiment. In addition, the functional units in the embodiments of the present disclosure may be integrated into a processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0102] The flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions and operations of the systems, methods and computer program products according to the embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment or part of the code, and the module, program segment or part of the code contains one or more executable instructions for implementing the specified logical functions. In some alternative implementations, the functions marked in the boxes can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, or they can sometimes be executed in the opposite order, which can depend on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different boxes can also occur in an order different from that disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps can actually be executed substantially in parallel, or they can sometimes be executed in the opposite order, which can depend on the functions involved. Each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action, or may be implemented by a combination of dedicated hardware and computer instructions.
Claims
1. A prototype verification signal debugging method based on ZYNQ, characterized in that: The method comprises: The control and scheduling module in the programmable logic (PL) receives the trigger conditions, sampling depth, and trigger position issued by the software, sends the trigger conditions to the trigger signal generation module on the PL side, and sends the sampling depth and trigger position to the data acquisition module on the PL side; The control and scheduling module in the programmable logic PL side forwards the data acquisition address and data acquisition command sent by the data acquisition module to the processing system PS; The trigger signal generation module receives multiple debug signal data and extracts corresponding data from the debug signal data according to the sequence number of the trigger condition signal. The extracted data is then compared according to the trigger comparison type, trigger operator type, and trigger comparison value. When the trigger condition is met, a trigger signal is generated and sent to the data acquisition module. The data acquisition module sends the received multiple debugging signal data to the DDR through the AXI-HP interface.
2. The method according to claim 1, characterized in that The method further comprises: The data acquisition module calculates the address of the debug signal data sent to the DDR, and based on the trigger signal, subtracts the trigger position k from the sampling depth m to obtain the number s, sends the debug signal data again s times, and sends the current data acquisition command and data acquisition address to the control and scheduling module.
3. The method according to claim 1, characterized in that The method further comprises: Write multiple debug signal data into the corresponding addresses of DDR one by one; Before the trigger signal arrives, the data of each debug signal is cyclically overwritten and stored within a range of a sampling depth m. When a trigger signal is received, each debug signal stores s cycles of data in the DDR.
4. The method according to claim 3, characterized in that When the storage is completed, the storage address addrz1 of the first debug signal is recorded, and the read signal command is sent to the DDR; DDR starts reading the data of the first signal, fetches data from address addrz1+1, takes out the data in the range of addrz1+1 to addr1+m, and then reads the data in addr1 to addrz1; Take out the data of n debug signals in sequence and stop the DDR read operation.
5. A prototype verification signal debugging device based on ZYNQ, characterized in that: The device comprises: The control and scheduling module in the programmable logic (PL) side is used to receive the trigger conditions, sampling depth, and trigger position issued by the software, and send the trigger conditions to the trigger signal generation module on the PL side, and send the sampling depth and trigger position to the data acquisition module on the PL side; The control and scheduling module in the programmable logic PL is used to forward the data acquisition address and data acquisition command sent by the data acquisition module to the processing system PS; A trigger signal generation module is used to receive multiple debug signal data, extract corresponding data from the debug signal data according to the sequence number of the trigger condition signal, and then compare the extracted data according to the trigger comparison type, trigger operator type, and trigger comparison value. When the trigger condition is met, a trigger signal is generated and sent to the data acquisition module; The data acquisition module is used to send the received multiple debugging signal data to the DDR through the AXI-HP interface.
6. The device according to claim 5, characterized in that The data acquisition module is also used to calculate the address of the debug signal data sent to the DDR, and based on the trigger signal, subtract the trigger position k from the sampling depth m to obtain the number s, send the debug signal data again s times, and send the current data acquisition command and data acquisition address to the control and scheduling module.
7. The device according to claim 5, characterized in that The data acquisition module is also used to write multiple debugging signal data into the corresponding addresses of the DDR one by one; Before the trigger signal arrives, the data of each debug signal is cyclically overwritten and stored within a range of a sampling depth m. When a trigger signal is received, each debug signal stores s cycles of data in the DDR.
8. The device according to claim 7, characterized in that When the storage is completed, the storage address addrz1 of the first debug signal is recorded, and the read signal command is sent to the DDR; DDR starts reading the data of the first signal, fetches data from address addrz1+1, takes out the data in the range of addrz1+1 to addr1+m, and then reads the data in addr1 to addrz1; Take out the data of n debug signals in sequence and stop the DDR read operation.
9. An electronic device, characterized in that: include: at least one processor; and a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 4.
10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to cause the computer to execute the method according to any one of claims 1-4.