This series will bring systematic learning of FPGA, starting from the most basic digital circuit fundamentals, with the most detailed operational steps and straightforward language descriptions, providing a “foolproof” explanation. This allows students majoring in electronics, information, and communication, as well as newcomers to the workplace and professional developers looking to advance, to have a systematic learning opportunity.
Systematic mastery of technology development and related requirements has potential benefits for personal employment and career development. I hope this is helpful to everyone.This time, we present the Vivado series, specifically the Vivado Logic Analyzer user guide.Without further ado, let’s get started.
Vivado Logic Analyzer User Guide
Author: Li Xirui Proofreader: Lu Hui
When using a traditional logic analyzer, we need to connect the signals we want to observe to the FPGA’s IO pins and then monitor the signals. When there are many signals, the operation can become cumbersome. The online logic analyzer effectively solves this problem by allowing us to incorporate these functionalities into FPGA design.
The design under test is our entire logic design module, and the online logic analyzer is also integrated into the FPGA design. We use one or more probes to collect the signals we want to observe. Then, through the JTAG interface, the captured data is sent back to our user interface via the downloader for observation.
During the use of the logic analyzer, we generally have two common methods:
1. IP Core
2. Mark Debug Signal
Next, we will first discuss the first method. This method requires us to open the IP core manager and instantiate ILA in the program design. First, we open the IP core manager, search for ILA, and double-click to open it.
In this configuration interface, we configure several items. First is the Component Name; we can give our logic analyzer a name, for example, I will change it to my_ila.
In the number of probes option, select the number of signals we need to observe. Taking the LED counter as an example, we can observe the counter cnt and output led in the code design. So we set this item to 2. Sample data depth is the sampling depth, which affects the length of the signals we can observe; everyone can set it according to their needs; here I choose a depth of 1024.
Then, in the Probe ports, set the bit width of the observed signals. The counter is 26 bits, and the LED output is 4 bits, so we set the bit width accordingly and click OK to generate the IP core.
Here, we briefly introduce the concept of Vivado’s OOC (Out-of-Context) synthesis. For top-level design, Vivado uses a top-down global synthesis method, synthesizing all logic modules beneath the top level, except for those set to OOC mode, which are synthesized independently of the top-level design. Typically, during the entire design cycle, the top-level design will be modified and synthesized multiple times. However, some sub-modules, once created, will not be modified due to changes in the top-level design, such as IPs. They are set to OOC synthesis mode, and OOC modules will only be synthesized once before the top-level synthesis. Thus, during the iterative process of top-level design, OOC modules do not need to be synthesized repeatedly, which would yield the same results. Therefore, the OOC process reduces the design cycle time and eliminates design iterations, allowing users to save and reuse synthesis results.
Out-of-Context (OOC) synthesis is a bottom-up design process. By default, the Vivado design suite uses the OOC design process to synthesize OOC modules. OOC modules can be IPs from the IP catalog, block designs from the Vivado IP Integrator, or any sub-modules manually set to OOC mode beneath the top-level module.
IPs from the IP catalog are synthesized using OOC by default. For example, the “Synthesis Options” option in the above image is set to “Out of Context Per IP.” These IPs will be synthesized separately in OOC before the global synthesis of the top-level and will generate output products (Generate Output Products), including synthesized netlists and various files. During the synthesis of the top-level, OOC modules will be treated as black boxes and will not participate in the synthesis of the top-level. After synthesis, during the implementation process, the black boxes of OOC modules will be opened, and their netlists will become visible and participate in the global design’s layout and routing.
After OOC synthesis, it is shown in the following image:
After completing the IP core call, we open the IP core’s instantiation template in the IP sources window. Taking the my_ila.veo file as an example, we double-click to open it and copy the content into the top-level file.
After copying, we will connect the signals and change the instantiation name. Thus, our logic analyzer call is complete.
After the call is complete, we save the file and generate the board file for downloading.
During the download, two files appear in the interface. The first file is the bitstream file. The second is the logic analyzer file. Simply click program. After the download is complete, the following interface will appear.
Before we start observing waveforms, we need to set the trigger signal in the small window in the lower right corner. We can understand this as the position of the waveform we want to observe. For example, we can observe the second LED being lit and the counter reaching 1000; thus, our settings are as shown in the following image:
After setting, we click the triangle symbol on the waveform interface to trigger, and we can observe our waveform.
Second method:
The “Netlist Insertion Debug Probe Process” requires marking each signal to be debugged in the synthesized netlist with the “Mark_Debug” attribute, and then using the “Setup Debug” wizard to set the parameters of the ILA IP core, finally the tool will automatically create the ILA IP core based on the parameters. We click the “Open Synthesized Design” button in the Flow Navigator window, as shown in the following image:
In the layout selector of the synthesized design window, we select the “Debug” window layout, as shown in the following image:
At this point, Vivado opens the “Netlist” sub-window, “Schematic” sub-window, and “Debug” sub-window. The “Netlist” and “Schematic” sub-windows are used to mark the signals to be observed, while the “Debug” sub-window is used to display and set the parameters of the ILA IP core. As shown in the following image:
In the “Debug” sub-window, there are two tabs: “Debug Cores” and “Debug Nets.” These two tabs are used to display all signals marked as “Mark_Debug.” The difference is that the “Debug Cores” tab provides a view centered around the ILA IP core, showing all signals marked as “Mark_Debug” that have been assigned to ILA probes under each ILA IP core’s view tree. Signals marked as “Mark_Debug” but not yet assigned to ILA probes are displayed under “Unassigned Debug Nets.” Of course, one can also view and set various properties and parameters of the ILA IP core there. The “Debug Nets” tab only displays signals marked as “Mark_Debug” but does not show the ILA IP core. All signals marked as “Mark_Debug” and assigned to ILA probes are displayed under “Assigned Debug Nets,” while signals marked as “Mark_Debug” but not yet assigned to ILA probes are shown under “Unassigned Debug Nets.”
First, we mark the signals to be observed. Taking the led signal as an example, in the “Netlist” sub-window under the “Nets” directory, find the “led_OBUF” network, right-click on this network (the “Schematic” sub-window on the right will automatically highlight this network as well since the objects in the “Netlist” and “Schematic” sub-windows are cross-selected), and select the “Mark Debug” command from the pop-up menu, as shown in the following image:
You can also select the network in the “Schematic” sub-window and right-click to choose the “Mark Debug” command, as shown in the following image:
Additionally, you can add the “Mark Debug” attribute to the reg or wire signals you want to observe in the HDL source code, for example: (* mark_debug = “true” *)reg [25:0] cnt; where “(* mark_debug = “true” *)” must be immediately before the variable declaration. After synthesis, when you open the synthesized design, the counter signal will be automatically marked with the “Mark Debug” attribute. At this point, in the “Debug” sub-window’s “Debug Nets” tab under the “Unassigned Debug Nets” directory, we will see the “led_OBUF” network we just marked.
At this point, the “Debug” sub-window’s “Debug Nets” tab will have both the “led_OBUF” and “cnt” signals under the “Unassigned Debug Nets” directory, as shown in the following image:
Next, we click the “Setup Debug” button in the “Debug” sub-window, as shown in the following image:
The “Setup Debug” wizard pops up, and we directly click next, as shown in the following image:
The next page is to select the clock domain used for sampling the signals to be tested. Vivado will automatically identify the clock domains of the signals to be tested and set them as their sampling clocks. For example, the two signals we just added, “led_OBUF” and “cnt,” belong to the “sys_clk_IBUF” clock domain, and Vivado has automatically set “sys_clk_IBUF” as the sampling clock for these two signals, as shown in the following image:
Of course, users can also manually specify the clock domains for sampling the signals to be tested by right-clicking on the signals to be tested and selecting “Select Clock Domain,” which pops up the “Select Clock Domain” window, as shown in the following two images:
In the “Select Clock Domain” window, you can choose the clock to be used for sampling the signals to be tested. The “Setup Debug” wizard will generate a separate ILA IP core for each sampling clock. Since there is only one clock in this example, only one ILA IP core will be generated here. After setting the sampling clock, we click next, and the next page is for setting the global settings of the ILA IP core, as shown in the following image:
Here, “Sample of data depth” is used to set the sampling depth, and “Input pipe stages” is used to set the number of synchronization stages between the signals to be tested and their sampling clock. If there are asynchronous signals to be tested in the previous clock domain setting page, this value should preferably not be less than 2 to avoid metastability. Since the two signals to be tested in this example are synchronous with their sampling clock, this can be set to 0. We click next, and the next page is the final overview page; if everything is correct, we can directly click finish, as shown in the following image:
In the “Debug” sub-window’s “Debug Cores” tab, you can see that Vivado has added the ILA IP core, and there are no unassigned signals left in the “Unassigned Debug Nets” directory, as shown in the following image:
The signals marked as Mark Debug in the netlist also change to dashed lines to indicate their allocation to the ILA IP core has been completed, as shown in the following image:
Earlier, we mentioned that in the “Netlist Insertion Debug Probe Process,” the debug information set by the user will be saved to the XDC constraint file in the form of Tcl XDC debug commands. During the implementation phase, Vivado will read these XDC debug commands and add these ILA IP cores during layout and routing. At this point, all the changes and settings we have made are still only in computer memory; we need to save them to the XDC constraint file on the hard disk by clicking the save button on the toolbar, as shown in the following image:
In the dialog that appears, simply click OK, as shown in the following image:
In the popped-up “Save Constraints” window, it asks the user where to save the constraints in which XDC constraint file. In this example project, there is only one XDC constraint file, as shown in the following image; we can directly click OK:
At this point, if we open led_twinkle.xdc, we will see that below the user constraints, Vivado has automatically written the constraints for debug, as shown in the following image:
During the implementation phase, Vivado will read these constraints and automatically add the ILA IP cores during layout and routing according to the parameters of these commands. Thus, we have successfully added the ILA IP core to the design using the “Netlist Insertion Debug Probe Process.” Next, we can implement the design and generate the bitstream, and finally download the bitstream to the FPGA for online observation of the signals. This part has already been introduced in detail in the first method and will not be repeated here.
– End –
Due to recent changes in the WeChat public platform’s push rules, many readers have reported not seeing updated articles in time. According to the latest rules, it is recommended to frequently click “Recommended Read, Share, Favorite,” etc., to become a regular reader.
Recommended Reading:
-
Breaking News! Nezha Auto CEO resigns to join a new company.
-
Xiaomi SU7: The more cars, the more debts!
-
NIO breaks through defenses: has reported to the police!