Intel Quartus Prime Pro Edition User Guide: Debug Tools
Version Information
Updated for: |
---|
Intel® Quartus® Prime Design Suite 20.3 |
1. System Debugging Tools Overview
1.1. System Debugging Tools Portfolio
System debugging tools provide visibility by routing (or “tapping”) signals in your design to debugging logic. The Compiler includes the debugging logic in your design and generates programming files that you download into the FPGA or CPLD for analysis.
Each tool in the system debugging portfolio uses a combination of available memory, logic, and routing resources to assist in the debugging process. Because different designs have different constraints and requirements, you can choose the tool that matches the specific requirements for your design, such as the number of spare pins available or the amount of logic or memory resources remaining in the physical device.
1.1.1. System Debugging Tools Comparison
Tool | Description | Typical Usage |
---|---|---|
System Console and Debugging Toolkits |
|
|
Signal Tap logic analyzer |
|
You have spare on-chip memory and you want functional verification of a design running in hardware. |
Signal Probe | Incrementally routes internal signals to I/O pins while preserving results from the last place-and-routed design. | You have spare I/O pins and you want to check the operation of a small set of control pins using either an external logic analyzer or an oscilloscope. |
Logic Analyzer Interface (LAI) |
|
You have limited on-chip memory and a large set of internal data buses to verify using an external logic analyzer. Logic analyzer vendors, such as Tektronics* and Agilent*, provide integration with the tool to improve usability. |
In-System Sources and Probes | Provides an easy way to drive and sample logic values to and from internal nodes using the JTAG interface. | You want to prototype the FPGA design using a front panel with virtual buttons. |
In-System Memory Content Editor | Displays and allows you to edit on-chip memory. |
You want to view and edit the contents of on-chip memory that is not connected to a Nios® II processor. You can also use the tool when you do not want to have a Nios® II debug core in your system. |
Virtual JTAG Interface | Allows you to communicate with the JTAG interface so that you can develop custom applications. | You want to communicate with custom signals in your design. |
Refer to the following for more information about launching and using the available debugging toolkits:
1.1.2. Suggested Tools for Common Debugging Requirements
Requirement | Signal Probe | Logic Analyzer Interface (LAI) | Signal Tap Logic Analyzer | Description |
---|---|---|---|---|
More Data Storage | N/A | X | — |
An external logic analyzer with the LAI tool allows you to store more captured data than the Signal Tap logic analyzer, because the external logic analyzer can provide access to a bigger buffer. The Signal Probe tool does not capture or store data. |
Faster Debugging | X | X | — | You can use the LAI or the Signal Probe tool with external equipment, such as oscilloscopes and mixed signal oscilloscopes (MSOs). This ability provides access to timing mode, which allows you to debug combined streams of data. |
Minimal Effect on Logic Design | X | X (2) | X (2) | The Signal Probe tool incrementally
routes nodes to pins, with no effect on the design logic. The LAI adds minimal logic to a design, requiring fewer device resources. The Signal Tap logic analyzer has little effect on the design, because the Compiler considers the debug logic as a separate design partition. |
Short Compile and Recompile Time | X | X (2) | X (2) |
Signal Probe uses incremental routing to attach signals to previously reserved pins. This feature allows you to quickly recompile when you change the selection of source signals. The Signal Tap logic analyzer and the LAI can refit their own design partitions to decrease recompilation time. |
Sophisticated Triggering Capability | N/A | N/A | X | The triggering capabilities of the Signal Tap logic analyzer are comparable to commercial logic analyzers. |
Low I/O Usage | — | — | X |
The Signal Tap logic analyzer does not require additional output pins. Both the LAI and Signal Probe require I/O pin assignments. |
Fast Data Acquisition | N/A | — | X | The Signal Tap logic analyzer can
acquire data at speeds of over 200 MHz. Signal integrity issues limit acquisition speed for external logic analyzers that use the LAI. |
No JTAG Connection Required | X | — | — |
Signal Probe does not require a host for debugging purposes. The Signal Tap logic analyzer and the LAI require an active JTAG connection to a host running the Intel® Quartus® Prime software. |
No External Equipment Required | — | — | X |
The Signal Tap logic analyzer only requires a JTAG connection from a host running the Intel® Quartus® Prime software or the stand-alone Signal Tap logic analyzer. Signal Probe and the LAI require the use of external debugging equipment, such as multimeters, oscilloscopes, or logic analyzers. |
Notes to Table:
|
1.1.3. Debugging Ecosystem
A very important distinction in the system debugging tools is how they interact with the design. All debugging tools in the Intel® Quartus® Prime software allow you to read the information from the design node, but only a subset allow you to input data at runtime:
Debugging Tool | Read Data from Design | Input Values into the Design | Comments |
---|---|---|---|
Signal Tap logic analyzer, | Yes | No | General purpose troubleshooting tools optimized for probing signals in a register transfer level (RTL) netlist |
Logic Analyzer Interface | |||
Signal Probe | |||
In-System Sources and Probes | Yes | Yes | These tools allow to:
|
Virtual JTAG Interface | |||
System Console | |||
Debugging Toolkits | |||
In-System Memory Content Editor |
Taken together, the set of on-chip debugging tools form a debugging ecosystem. The set of tools can generate a stimulus to and solicit a response from the logic under test, providing a complete solution.
1.2. Tools for Monitoring RTL Nodes
The Signal Tap logic analyzer, Signal Probe, and LAI tools are useful for probing and debugging RTL signals at system speed. These general-purpose analysis tools enable you to tap and analyze any routable node from the FPGA.
- In cases when the design has spare logic and memory resources, the Signal Tap logic analyzer can providing fast functional verification of the design running on actual hardware.
- Conversely, if logic and memory resources are tight and you require the large sample depths associated with external logic analyzers, both the LAI and the Signal Probe tools simplify monitoring internal design signals using external equipment.
1.2.1. Resource Usage
Evaluate debugging options early on in the design planning process to ensure that you support the appropriate options in the board, Intel® Quartus® Prime project, and design. Planning early can reduce debugging time, and eliminates last minute changes to accommodate debug methodologies.
1.2.1.1. Overhead Logic
1.2.1.1.1. For Signal Tap Logic Analyzer
A baseline configuration consisting of the SLD arbitration logic and a single node with basic triggering logic contains approximately 300 to 400 Logic Elements (LEs). Each additional node you add to the baseline configuration adds about 11 LEs. Compared with logic resources, memory resources are a more important factor to consider for your design. Memory usage can be significant and depends on how you configure your Signal Tap logic analyzer instance to capture data and the sample depth that your design requires for debugging. For the Signal Tap logic analyzer, there is the added benefit of requiring no external equipment, as all of the triggering logic and storage is on the chip.
1.2.1.1.2. For Signal Probe
1.2.1.1.3. For Logic Analyzer Interface
1.2.2. Pin Usage
1.2.2.1. For Signal Tap Logic Analyzer
1.2.2.2. For Signal Probe
1.2.2.3. For Logic Analyzer Interface
1.2.3. Usability Enhancements
1.2.3.1. Incremental Routing
1.2.3.2. Automation Via Scripting
1.2.3.3. Remote Debugging
For information about setting up a Nios® II system with the System Console to perform remote debugging, refer to Application Note 624.
1.3. Stimulus-Capable Tools
- The In-System Sources and Probes is ideal for toggling control signals.
- The In-System Memory Content Editor is useful for inputting large sets of test data.
- Finally, the Virtual JTAG interface is well suited for advanced users who want to develop custom JTAG solutions.
System Console provides system-level debugging at a transaction level, such as with Avalon® -MM slave or Avalon® -ST interfaces. You can communicate to a chip through JTAG and TCP/IP protocols. System Console uses a Tcl interpreter to communicate with hardware modules that you instantiate into your design.
1.3.1. In-System Sources and Probes
In-System Sources and Probes allow you to read and write to a design by accessing JTAG resources.
You instantiate an Intel® FPGA IP into your HDL code. This Intel® FPGA IP core contains source ports and probe ports that you connect to signals in your design, and abstracts the JTAG interface's transaction details.
In addition, In-System Sources and Probes provide a GUI that displays source and probe ports by instance, and allows you to read from probe ports and drive to source ports. These features make this tool ideal for toggling a set of control signals during the debugging process.
1.3.1.1. Push Button Functionality
1.3.2. In-System Memory Content Editor
1.3.2.1. Generate Test Vectors
1.3.3. System Console
1.3.3.1. Test Signal Integrity
1.3.3.2. Board Bring-Up and Verification
1.3.3.3. Debug with Available Toolkits
Refer to the following for more information about launching and using the available debugging toolkits:
1.4. Virtual JTAG Interface Intel FPGA IP
1.5. System-Level Debug Fabric
Most Intel FPGA on-chip debugging tools use the JTAG port to control and read-back data from debugging logic and signals under test. The JTAG Hub manages the sharing of JTAG resources.
The JTAG Hub appears in the project's design hierarchy as a partition named auto_fab_<number> .
1.6. SLD JTAG Bridge
The SLD JTAG Bridge extends the debug fabric across partitions, allowing a higher-level partition (static region or root partition) to access debug signals in a lower-level partition (partial reconfiguration region or core partition).
This bridge consists of two IP components:
-
SLD JTAG Bridge Agent
Intel® FPGA IP
—Resides in the higher-level partition.
Extends the JTAG debug fabric from a higher-level partition to a lower-lever partition containing the SLD JTAG Bridge Host IP. You instantiate the SLD JTAG Bridge Agent IP in the higher-level partition.
-
SLD JTAG Bridge Host
Intel® FPGA IP
—resides in the lower-level partition. Connects to the PR JTAG hub on one end, and to the SLD JTAG Bridge Agent on the higher-level partition.
Connects the JTAG debug fabric in a lower-level to a higher-level partition containing the SLD JTAG Bridge Agent IP. You instantiate the SLD JTAG Bridge Host IP in the lower-level partition.
For each PR region or reserved core partition you debug, you must instantiate one SLD JTAG Bridge Agent in the higher-level partition and one SLD JTAG Bridge Host in the lower-level partition.
1.6.1. SLD JTAG Bridge Index
The Intel® Quartus® Prime software supports multiple instances of the SLD JTAG Bridge in designs. The Compiler assigns an index number to distinguish each instance. The bridge index for the root partition is always None.
When configuring the Signal Tap logic analyzer for the root partition, set the Bridge Index value to None in the JTAG Chain Configuration window.
Bridge Index Information in the Compilation Report
Following design synthesis, the Compilation Report lists the index numbers for the SLD JTAG Bridge Agents in the design. Open the Synthesis > In-System Debugging > JTAG Bridge Instance Agent Information report for details about how the bridge indexes are enumerated. The reports shows the hierarchy path and the associated index.
In the synthesis report (<base revision>.syn.rpt), this information appears in the table JTAG Bridge Agent Instance Information.

1.6.2. Instantiating the SLD JTAG Bridge Agent
-
On the IP Catalog (Tools > IP Catalog), type SLD JTAG Bridge
Agent.
Figure 7. Find in IP Catalog
- Double click SLD JTAG Bridge Agent Intel® FPGA IP .
-
In the Create IP
Variant dialog box, type a file name, and then click Create.
Figure 8. Create IP Variant Dialog BoxThe IP Parameter Editor Pro window shows the IP parameters. In most cases, you do not need to change the default values.Figure 9. SLD JTAG Bridge Agent Intel® FPGA IP Parameters
- Click Generate HDL.
- When the generation completes successfully, click Close.
- If you want an instantiation template, click Generate > Show Instantiation Template in the IP Parameter Editor Pro.
1.6.3. Instantiating the SLD JTAG Bridge Host
-
On the IP Catalog (Tools > IP Catalog), type SLD JTAG Bridge
Host.
Figure 10. Find in IP Catalog
- Double click SLD JTAG Bridge Host Intel® FPGA IP .
-
In the Create IP
Variant dialog box, type a file name, and then click Create.
Figure 11. Create IP Variant Dialog BoxThe IP Parameter Editor Pro window shows the IP parameters. In most cases, you do not need to change the default values.Figure 12. SLD JTAG Bridge Host Intel® FPGA IP Parameters
- Click Generate HDL.
- When the generation completes successfully, click Close.
- If you want an instantiation template, click Generate > Show Instantiation Template in the IP Parameter Editor Pro.
1.7. Partial Reconfiguration Design Debugging
The following Intel® FPGA IP cores support system-level debugging in the static region of a PR design:
- In-System Memory Content Editor
- In-System Sources and Probes Editor
- Virtual JTAG
- Nios® II JTAG Debug Module
- Signal Tap Logic Analyzer
In addition, the Signal Tap logic analyzer allows you to debug the static or partial reconfiguration (PR) regions of the design. If you only want to debug the static region, you can use the In-System Sources and Probes Editor, In-System Memory Content Editor, or System Console with the JTAG Avalon Master Bridge.
1.7.1. Debug Fabric for Partial Reconfiguration Designs
On designs with Partial Reconfiguration, the Compiler generates centralized debug managers—or hubs—for each region (static and PR) that contains system level debug agents. Each hub handles the debug agents in its partition. In the design hierarchy, the hub corresponding to the static region is auto_fab_0.
To connect the hubs on parent and child partitions, you must instantiate one SLD JTAG Bridge for each PR region that you want to debug.
1.7.1.1. Generation of PR Debug Infrastructure
During compilation, the synthesis engine performs the following functions:
- Generates a main JTAG hub in the static region.
- If the static region contains Signal Tap instances, connects those instances to the main JTAG hub.
- Detects bridge agent and bridge host instances.
- Connects the SLD JTAG bridge agent instances to the main JTAG hub.
- For each bridge host instance in a PR region that contains a
Signal Tap instance:
- Generates a PR JTAG hub in the PR region.
- Connects all Signal Tap instances in the PR region to the PR JTAG hub.
- Detects instance of the SLD JTAG bridge host.
- Connects the PR JTAG hub to the JTAG bridge host.
1.8. System Debugging Tools Overview Revision History
The following revision history applies to this chapter:
Document Version | Intel® Quartus® Prime Version | Changes |
---|---|---|
2020.09.28 | 20.3 |
|
2019.09.30 | 19.3 |
|
2018.09.24 | 18.1 |
|
2018.05.07 | 18.0 |
|
2017.05.08 | 17.0 |
|
2016.10.31 | 16.1 |
|
2015.11.02 | 15.1 | Changed instances of Quartus II to Intel® Quartus® Prime . |
June 2014 | 14.0 | Added information that System Console supports the Tk toolkit. |
November 2013 | 13.1 | Dita conversion. Added link to Remote Debugging over TCP/IP for Altera SoC Application Note. |
June 2012 | 12.0 | Maintenance release. |
November 2011 | 10.0 | Maintenance release. Changed to new document template. |
December 2010 | 10.0 | Maintenance release. Changed to new document template. |
July 2010 | 10.0 | Initial release |
2. Design Debugging with the Signal Tap Logic Analyzer
2.1. Signal Tap Logic Analyzer Introduction
By default, the Signal Tap logic analyzer captures data continuously from the signals you specify while the logic analyzer is running. To capture and store only specific signal data, you specify conditions that trigger the start or stop of data capture. A trigger activates when the trigger conditions are met, stopping analysis and displaying the data. You can save the captured data in device memory for later analysis, and filter data that is not relevant.
Signal Tap Logic Analyzer Instance
You enable the logic analyzer functionality by defining one or more instances of the Signal Tap logic analyzer in your project. You can define the properties of the Signal Tap instance in the Signal Tap logic analyzer GUI, or by HDL instantiation of the Signal Tap Logic Analyzer Intel® FPGA IP. After design compilation, you configure the target device with your design (including any Signal Tap instances), which enables data capture and communication with the Signal Tap logic analyzer GUI over a JTAG connection.
Signal Tap Logic Analyzer GUI
The Signal Tap logic analyzer GUI helps you to rapidly define and modify Signal Tap signal configuration and JTAG connection settings, displays the captured signals during analysis, starts and stops analysis, and displays and records signal data. When you configure a Signal Tap instance in the logic analyzer GUI, Signal Tap preserves the instance settings in a Signal Tap Logic Analyzer file (.stp) for reuse.
Signal Tap Logic Analyzer Feature Support
The Signal Tap logic analyzer supports a high number of channels, a large sample depth, fast clock speeds, and other features described in the Key Signal Tap Logic Analyzer Features table.
Feature | Benefit |
---|---|
Multiple logic analyzers in a single device, or in multiple devices in a single chain | Capture data from multiple clock domains and from multiple devices at the same time. |
Up to 10 trigger conditions for each analyzer instance | Send complex data capture commands to the logic analyzer for greater accuracy and problem isolation. |
Power-up trigger | Capture signal data for triggers that occur after device programming, but before manually starting the logic analyzer. |
Custom trigger HDL object | Define a custom trigger in Verilog HDL or VHDL and tap specific instances of modules across the design hierarchy, without manual routing of all the necessary connections. |
State-based triggering flow | Organize triggering conditions to precisely define data capture. |
Flexible buffer acquisition modes | Precise control of data written into the acquisition buffer. Discard data samples that are not relevant to the debugging of your design. |
MATLAB* integration with MEX function | Collect Signal Tap capture data into a MATLAB* integer matrix. |
Up to 4,096 channels per logic analyzer instance | Samples many signals and wide bus structures. |
Up to 128K samples per instance | Captures a large sample set for each channel. |
Fast clock frequencies | Synchronous sampling of data nodes using the same clock tree driving the logic under test. |
Resource usage estimator | Provides an estimate of logic and memory device resources that the Signal Tap logic analyzer configurations use. |
Compatible with other debugging utilities | Use the Signal Tap logic analyzer in tandem with any JTAG-based on-chip debugging tool, such as an In-System Memory Content editor, to change signal values in real-time. |
Floating-Point Display Format |
|
2.1.1. Signal Tap Hardware and Software Requirements
During data acquisition, the memory blocks in the FPGA device store the captured data, and then transfer the data to the Signal Tap logic analyzer over a JTAG communication cable, such as Intel® FPGA Ethernet Cable or Intel® FPGA Download Cable.
The Signal Tap logic analyzer requires the following hardware and software to perform logic analysis:
- The Signal Tap logic analyzer included with the Intel® Quartus® Prime software, or the Signal Tap logic analyzer standalone software and standalone Programmer software.
- An Intel® FPGA download or communications cable.
- An Intel® development kit, or your own design board with a JTAG connection to the device under test.
2.2. Signal Tap Debugging Flow
To use the Signal Tap logic analyzer to debug your design, you compile your design that includes one or more Signal Tap instances that you define, configure the target device, and then run the logic analyzer to capture and analyze signal data.
The following steps describe the Signal Tap debugging flow in detail:
2.3. Step 1: Add the Signal Tap Logic Analyzer to the Project
To help you get started quickly, the Signal Tap logic analyzer GUI includes preconfigured templates for various trigger conditions and applications. You can then modify the settings the template applies and adjust trigger conditions in the Signal Tap logic analyzer GUI.
Alternatively, you can define a Signal Tap instance by parameterizing an instance of the Signal Tap Logic Analyzer Intel FPGA IP, and then instantiating the Signal Tap entity or module in an HDL design file.
If you want to monitor multiple clock domains simultaneously, you can add additional instances of the logic analyzer to your design, limited only by the available resources in your device.
2.3.1. Creating a Signal Tap Instance with the Signal Tap GUI
- Open a project and run Analysis & Synthesis on the Compilation Dashboard.
-
To create a Signal Tap
instance with the Signal Tap logic analyzer
GUI, perform one of the following:
- Click Tools > Signal Tap Logic Analyzer.
- Click File > New > Signal Tap Logic Analyzer File.
Figure 16. Signal Tap file Templates - Select a Signal Tap file template. The Preview describes the setup and Signal Configuration the template applies. Refer to Signal Tap File Templates.
- Click Create. The Signal Tap logic analyzer GUI opens with the template options preset for the Signal Tap instance.
- Under Signal Configuration, specify the acquisition Clock and optionally modify other settings, as Step 2: Configure the Signal Tap Logic Analyzer describes.
- When you save or close the Signal Tap instance, click Yes when prompted to add the Signal Tap instance to the project.
2.3.1.1. Disabling or Enabling Signal Tap Instances
You can disable and enable Signal Tap instances in the Instance Manager pane. This setting determines whether the logic analyzer includes the instance the next time you compile the design. If you enable or disable instances, you must recompile the design to implement the changes.
2.3.2. Creating a Signal Tap Instance by HDL Instantiation
- From the Intel® Quartus® Prime IP Catalog (View > IP Catalog), locate and double-click the Signal Tap Logic Analyzer Intel FPGA IP.
- In the New IP Variant dialog box, specify the File Name for your Signal Tap instance, and then click Create. The IP parameter editor displays the available parameter settings for the Signal Tap instance.
- In the parameter editor, specify the Data, Segmented Acquisition, Storage Qualifier, Trigger, and Pipelining parameters, as Signal Tap Intel FPGA IP Parameters describes.
- Click Generate HDL. The parameter editor generates the HDL implementation of
the Signal Tap instance according your
specifications.Figure 18. IP Parameter Editor
- To instantiate the Signal Tap instance in
your RTL, click Generate > Show Instantiation Template in the parameter editor. Copy the
Instantiation Template contents into your RTL.Figure 19. Signal Tap Logic Analyzer Intel FPGA IP Instantiation Template
- Run at least the Analysis & Synthesis stage of the Compiler to synthesize the RTL (including Signal Tap instance) by clicking Processing > Start > Start Analysis & Synthesis. Alternatively, you can run full compilation and the Assembler at this point if ready.
- When the Compiler completes, click Create/Update > Create Signal Tap File from Design
Instance to create a .stp file for
analysis in the Signal Tap logic analyzer
GUI.Figure 20. Create Signal Tap File from Design Instances Dialog BoxNote: If your project contains partial reconfiguration partitions, the PR partitions display in a tree view. Select a partition from the view, and click Create Signal Tap file. The resulting .stp file that generates contains all HDL instances in the corresponding PR partition. The resulting .stp file does not include the instances in any nested partial reconfiguration partition.
- To analyze the Signal Tap instance, click File > Open and select the .stp file. The Signal Tap instance opens in the Signal Tap logic analyzer GUI for analysis. All the fields are read-only, except runtime-configurable trigger conditions.
- Modify any runtime-configurable trigger conditions, as Runtime Reconfigurable Options describes.
2.3.2.1. Signal Tap Intel FPGA IP Parameters
Parameter Groups | Parameter Descriptions |
---|---|
Data |
|
Segmented Acquisition | Specifies options for
organizing the captured data buffer:
|
Storage Qualifier | Specifies the Continuous or Input Port method, and whether to Record data discontinuities. |
Trigger |
|
Pipelining | The Pipeline Factor specifies the levels of pipelining added for potential fMAX improvement from 0 to 5. Default is 0. |
2.4. Step 2: Configure the Signal Tap Logic Analyzer
You must configure the Signal Tap logic analyzer before you can capture and analyze data. You can configure instances of the Signal Tap logic analyzer by specifying options in the Signal Tap Signal Configuration pane.
When you use the available Signal Tap templates to create a new Signal Tap instance, the template specifies many of the initial option values automatically.
Basic configuration of the Signal Tap logic analyzer includes specifying values for the following options:
2.4.1. Specifying the Clock, Sample Depth, and RAM Type
Specifying the Acquisition Clock
Signal Tap samples data on each positive (rising) edge of the acquisition clock. Therefore Signal Tap requires a clock signal from your design to control the logic analyzer data acquisition. For best data acquisition, specify a global, non-gated clock that is synchronous to the signals under test. Refer to the Timing Analysis section of the Compilation Report for the maximum frequency of the logic analyzer clock.
- To specify the acquisition clock signal, enter a signal name from your design for the Clock setting in Single Configuration.
- If you do not assign an acquisition clock, Signal Tap automatically creates clock pin auto_stp_external_clk. You must then make a pin assignment to this signal, and ensure that a clock signal in your design drives the acquisition clock.
- Using a transceiver recovered clock as the acquisition clock can cause incorrect or unexpected behavior, particularly when the transceiver recovered clock is the acquisition clock with the power-up trigger feature.
- Specifying a gated acquisition clock can result in unexpected data that does not accurately reflect the behavior of your design.
- Signal Tap does not support sampling on the negative (falling) clock edge.
Specifying Sample Depth
The sample depth determines the number of samples the logic analyzer captures and stores in the data buffer, for each signal. In cases with limited device memory resources, you can reduce the sample depth to reduce resource usage.
- To specify the sample depth, select the number of samples from the Sample depth list under Single Configuration. Available sample depth range is from 0 to 128K.
Specifying the RAM Type
You can specify the RAM type and buffer acquisition mode for storage of Signal Tap logic analyzer acquisition data. When you allocate the Signal Tap logic analyzer buffer to a particular RAM block, the entire RAM block becomes a dedicated resource for the logic analyzer.
- To specify the RAM type, select a Ram type under Single Configuration. Available settings are Auto, MLAB, or M20K RAM.
Use RAM selection to preserve a specific memory block for your design, and allocate another portion of memory for Signal Tap data acquisition. For example, if your design has an application that requires a large block of memory resources, such as a large instruction or data cache, use MLAB blocks for data acquisition and leave M20k blocks for your design.
2.4.2. Specifying the Buffer Acquisition Mode
The Signal Tap logic analyzer supports either a non-segmented (or circular) buffer and a segmented buffer.
- Non-segmented buffer—the Signal Tap logic analyzer treats the entire memory space as a single FIFO, continuously filling the buffer until the logic analyzer reaches the trigger conditions that you specify.
- Segmented buffer—the memory space is split into separate buffers. Each buffer acts as a separate FIFO with its own set of trigger conditions, and behaves as a non-segmented buffer. Only a single buffer is active during an acquisition. The Signal Tap logic analyzer advances to the next segment after the trigger condition or conditions for the active segment has been reached.
When using a non-segmented buffer, you can use the storage qualification feature to determine which samples are written into the acquisition buffer. Both the segmented buffers and the non-segmented buffer with the storage qualification feature help you maximize the use of the available memory space.
Both non-segmented and segmented buffers can use a preset trigger position (Pre-Trigger, Center Trigger, Post-Trigger). Alternatively, you can define a custom trigger position using the State-Based Triggering tab, as Specify Trigger Position describes.
2.4.2.1. Non-Segmented Buffer
The non-segmented buffer is the default buffer type in the Signal Tap logic analyzer.
At runtime, the logic analyzer stores data in the buffer until the buffer fills up. From that point on, new data overwrites the oldest data, until a specific trigger event occurs. The amount of data the buffer captures after the trigger event depends on the Trigger position setting:
- To capture most data before the trigger occurs, select Post trigger position from the list
- To capture most data after the trigger, select Pre trigger position.
- To center the trigger position in the data, select Center trigger position.
Alternatively, use the custom State-based triggering flow to define a custom trigger position within the capture buffer.
2.4.2.2. Segmented Buffer
If you want to have separate trigger conditions for each of the segmented buffers, you must use the state-based trigger flow. The figure shows an example of a segmented buffer system.
With the buffer acquisition feature allows you to monitor multiple read transactions from the SRAM device without running the Signal Tap logic analyzer again. You can split the memory to capture the same event multiple times, without wasting allocated memory. The buffer captures as many cycles as the number of segments you define under the Data settings in the Signal Configuration pane.
To enable and configure buffer acquisition, select Segmented in the Signal Tap logic analyzer Editor and determine the number of segments to use. In the example in the figure, selecting 64-sample segments allows you to capture 64 read cycles.
2.4.3. Adding Signals to the Signal Tap Logic Analyzer
To add one or more signals to Signal Tap for monitoring:
- In the Signal Tap logic analyzer, Click Edit > Add Nodes. The Node Finder appears, allowing you to find and add the signals in
your design. The following Filter options are available for finding the nodes you
want:
- Signal Tap: pre-synthesis—finds signal names present after design elaboration, but before any synthesis optimizations are done. This set of signals must reflect your Register Transfer Level (RTL) signals.
- Signal Tap: post-fitting—finds signal names present after physical synthesis optimizations and place-and-route.
- In the Node Finder, select one or more nodes that you want to add, and then click the Copy all to Selected Nodes list button.
- Click Insert. The nodes are added to the Setup tab signal list in the Signal Tap logic analyzer GUI.
- Specify how the logic analyzer uses the signal by enabling or disabling the
Data Enable, Trigger Enable, or
Storage Enable option for the signal:
- Trigger Enable—disabling prevents a signal from triggering the analysis, while still showing the signal's captured data.
- Data Enable—disabling prevent capture of data, while still allowing the signal to trigger.
Figure 25. Signal List Options
There is no limit to the number of signals available for monitoring in the Signal Tap window waveform display. However, the number of channels available is directly proportional to the number of logic elements (LEs) or adaptive logic modules (ALMs) in the device. Therefore, there is a physical restriction on the number of channels that are available for monitoring. Signals shown in blue text are post-fit node names. Signals shown in black text are pre-synthesis node names.
After successful Analysis and Elaboration, invalid signals appear in red. Unless you are certain that these signals are valid, remove them from the .stp file for correct operation. The Signal Tap Status Indicator also indicates if an invalid node name exists in the .stp file.
You can monitor signals only if a routing resource (row or column interconnects) exists to route the connection to the Signal Tap instance. For example, you cannot monitor signals that exist in the I/O element (IOE), because there are no direct routing resources from the signal in an IOE to a core logic element. For input pins, you can monitor the signal that is driving a logic array block (LAB) from an IOE, or, for output pins, you can monitor the signal from the LAB that is driving an IOE.
The Intel® Quartus® Prime Pro Edition software uses only the instance name, and not the entity name, in the form of:
a|b|c
not a_entity:a|b_entity:b|c_entity:c
2.4.3.1. Adding Pre-Synthesis Signals
When you add pre-synthesis signals to Signal Tap for monitoring, make all connections to the Signal Tap logic analyzer before synthesis. The Compiler allocates logic and routing resources to make the connection as if you changed your design files. For signals driving to and from IOEs, pre-synthesis signal names coincide with the pin's signal names.
2.4.3.2. Adding Post-Fit Signals
When you add post-fit signals to Signal Tap for monitoring, you are connecting to actual atoms in the post-fit netlist. You can only monitor signals that exist in the post-fit netlist, and existing routing resources must be available.
In the case of post-fit output signals, monitor the COMBOUT or REGOUT signal that drives the IOE block. For post-fit input signals, signals driving into the core logic coincide with the pin's signal name.
2.4.3.3. Adding Nios II Processor Signals with a Plug-In
The Nios® II plug-in creates one mnemonic table in the Setup tab and two tables in the Data tab:
- Nios® II Instruction (Setup tab)—capture all the required signals for triggering on a selected instruction address.
- Nios® II Instance Address (Data tab)—display address of executed instructions in hexadecimal format or as a programming symbol name if defined in an optional Executable and Linking Format (.elf) file.
- Nios® II Disassembly (Data tab)—display disassembled code from the corresponding address.
To add Nios® II IP signals to the logic analyzer using a plug-in, perform the following steps after running Analysis and Elaboration on your design:
- In the Signal Tap logic analyzer, right-click the node list, and then click Add Nodes with Plug-In > Nios® II .
-
Select
the IP that contains the signals you want to monitor with the
plug-in,
and click OK.
- If all the signals in the plug-in are available, a dialog box might appear, depending on the plug-in, where you can specify options for the plug-in.
- With the Nios® II plug-in, you can optionally select an .elf containing program symbols from your Nios® II Integrated Development Environment (IDE) software design. Specify options for the selected plug-in, and click OK.
2.4.3.4. Signals Unavailable for Signal Tap Debugging
The following signal types are unavailable for Signal Tap debugging:
- Post-fit output pins—You cannot monitor a post-fit output or bidirectional pin directly. To make an output signal visible, monitor the register or buffer that drives the output pin.
- Carry chain signals—You cannot monitor the carry out (cout0 or cout1) signal of a logic element. Due to architectural restrictions, the carry out signal can only feed the carry in of another LE.
- JTAG signals—You cannot monitor the JTAG control (TCK, TDI, TDO, or TMS) signals.
- LVDS—You cannot monitor the data output from a serializer/deserializer (SERDES) block.
- DQ, DQS signals—You cannot directly monitor the DQ or DQS signals in a DDR or DDRII design.
2.4.4. Defining Trigger Conditions
The Signal Tap logic analyzer allows you to define trigger conditions that range from very simple, such as the rising edge of a single signal, to very complex, involving groups of signals, extra logic, and multiple conditions. Additionally, you can specify Power-Up Triggers to capture data from trigger events occurring immediately after the device enters user-mode after configuration.
2.4.4.1. Basic Trigger Conditions
To specify the trigger pattern, right-click the Trigger Conditions column and click Don’t Care, Low, High, Falling Edge , Rising Edge, or Either Edge.
For buses, type a pattern in binary, or right-click and select Insert Value to enter the pattern in other number formats. Note that you can enter X to specify a set of “don’t care” values in either your hexadecimal or your binary string. For signals in the .stp file that have an associated mnemonic table, you can right-click and select an entry from the table to specify pre-defined conditions for the trigger.
When you add signals through plug-ins, you can create basic triggers using predefined mnemonic table entries. For example, with the Nios® II plug-in, if you specify an .elf file from your Nios® II IDE design, you can type the name of a function from your Nios® II code. The logic analyzer triggers when the Nios® II instruction address matches the address of the code function name that you specify.
Data capture stops and the logic analyzer stores the data in the buffer when the logical AND of all the signals for a given trigger condition evaluates to TRUE.
2.4.4.2. Nested Trigger Conditions
The evaluation precedence of a nested trigger condition starts at the bottom-level with the leaf-groups. The logic analyzer uses the resulting logic value to compute the parent group’s logic value. If you manually set the value of a group, the logic value of the group's members doesn't influence the result of the group trigger.
- Select Basic OR under Trigger Conditions.
- In the Setup tab, select several nodes. Include groups in your selection.
- Right-click the Setup tab and select Group.
-
Select the nested group and
right-click to set a group trigger condition that applies the reduction
AND,
OR,
NAND,
NOR,
XOR,
XNOR, or
logical TRUE or
FALSE.
Note: You can only select OR and AND group trigger conditions for bottom-level groups (groups with no groups as children).Figure 26. Applying Trigger Condition to Nested Group
2.4.4.3. Comparison Trigger Conditions
- Single-value comparison—compares a bus node’s value to a numeric value that you specify. Use one of these operands for comparison: >, >=, ==, <=, <. Returns 1 when the bus node matches the specified numeric value.
- Interval check—verifies whether a bus node’s value confines to an interval that you define. Returns 1 when the bus node's value lies within the specified bounded interval.
- Apply the Comparison trigger only to bus nodes consisting of leaf nodes.
- Do not form sub-groups within a bus node.
- Do not enable or disable individual trigger nodes within a bus node.
- Do not specify comparison values (in case of single-value comparison) or boundary values (in case of interval check) exceeding the selected node’s bus-width.
2.4.4.3.1. Specifying the Comparison Trigger Conditions
Follow these steps to specify the Comparison trigger conditions:
- From the Setup tab, select Comparison under Trigger Conditions.
- Right-click the node in the trigger editor, and select Compare.
-
Select the Comparison
type from the Compare window.
- If you choose Single-value comparison as your comparison type, specify the operand and value.
- If you choose Interval check as your comparison type, provide the lower and upper bound values for the interval.
Figure 27. Selecting the Comparison Trigger ConditionYou can also specify if you want to include or exclude the boundary values.
Figure 28. Specifying the Comparison Values -
Click OK. The trigger
editor displays the resulting comparison expression in the group node condition
text box.
Figure 29. Resulting Comparison Condition in Text Box
2.4.4.4. Advanced Trigger Conditions
To build a complex trigger condition in an expression tree, drag-and-drop operators from the Object Library pane and the Node List pane into the Advanced Trigger Configuration Editor window.
To configure the operators’ settings, double-click or right-click the operators that you placed and click Properties.
Category | Name |
---|---|
Signal Detection |
Edge and Level Detector |
Input Objects |
Bit Bit Value Bus Bus Value |
Comparison |
Less Than Less Than or Equal To Equality Inequality Greater Than or Equal To Greater Than |
Bitwise |
Bitwise Complement Bitwise AND Bitwise OR Bitwise XOR |
Logical |
Logical NOT Logical AND Logical OR Logical XOR |
Reduction |
Reduction AND Reduction OR Reduction XOR |
Shift |
Left Shift Right Shift |
Custom Trigger HDL |
Adding many objects to the Advanced Trigger Condition Editor can make the work space cluttered and difficult to read. To keep objects organized while you build your advanced trigger condition, use the shortcut menu and select Arrange All Objects. Alternatively, use the Zoom-Out command to fit more objects into the Advanced Trigger Condition Editor window.
2.4.4.4.1. Examples of Advanced Triggering Expressions



2.4.4.5. Custom Trigger HDL Object
The Custom Trigger HDL object appears in the Object Library pane of the Advanced Trigger editor.
2.4.4.5.1. Using the Custom Trigger HDL Object
- Select the trigger you want to edit.
- Open the Advanced Trigger tab by selecting Advanced in the Trigger Conditions list.
- Add to your project the HDL source file that contains the trigger module using the Project Navigator.
- Implement the inputs and outputs that your Custom Trigger HDL module requires.
-
Drag in your Custom Trigger HDL object
and connect the object’s data input bus and result output bit to the final
trigger result.
Figure 36. Custom Trigger HDL Object
-
Right-click your Custom Trigger HDL
object and configure the object’s properties.
Figure 37. Configure Object Properties
- Compile your design.
- Acquire data with Signal Tap using your custom Trigger HDL object.
Verilog HDL Triggers
The following trigger uses configuration bitstream:
module test_trigger ( input acq_clk, reset, input[3:0] data_in, input[1:0] pattern_in, output reg trigger_out ); always @(pattern_in) begin case (pattern_in) 2'b00: trigger_out = &data_in; 2'b01: trigger_out = |data_in; 2'b10: trigger_out = 1'b0; 2'b11: trigger_out = 1'b1; endcase end endmodule
This trigger does not have configuration bitstream:
module test_trigger_no_bs ( input acq_clk, reset, input[3:0] data_in, output reg trigger_out ); assign trigger_out = &data_in; endmodule
2.4.4.5.2. Required Inputs and Outputs of Custom Trigger HDL Module
Name | Description | Input/Output | Required/ Optional |
---|---|---|---|
acq_clk | Acquisition clock that Signal Tap uses | Input | Required |
reset | Reset that Signal Tap uses when restarting a capture. | Input | Required |
data_in |
|
Input | Required |
pattern_in |
|
Input | Optional |
trigger_out | Output signal of your module that asserts when trigger conditions met. | Output | Required |
2.4.4.5.3. Custom Trigger HDL Module Properties
Property | Description |
---|---|
Custom HDL Module Name | Module name of the triggering logic. |
Configuration Bitstream |
|
Pipeline |
Specifies the number of pipeline stages in the triggering logic. For example, if after receiving a triggering input the LA needs three clock cycles to assert the trigger output, you can denote a pipeline value of three. |
2.4.4.6. Specify Trigger Position
The Signal Tap logic analyzer offers three pre-defined ratios of pre-trigger data to post-trigger data:
- Pre—saves signal activity that occurred after the trigger (12% pre-trigger, 88% post-trigger).
- Center—saves 50% pre-trigger and 50% post-trigger data.
- Post—saves signal activity that occurred before the trigger (88% pre-trigger, 12% post-trigger).
These pre-defined ratios apply to both non-segmented buffers and segmented buffers.
2.4.4.6.1. Post-fill Count
In a custom state-based triggering flow with the segment_trigger and trigger buffer control actions, you can use the post-fill_count argument to specify a custom trigger position.
- If you do not use the post-fill_count argument, the trigger position for the affected buffer defaults to the trigger position you specified in the Setup tab.
- In the trigger buffer control action (for non-segmented buffers), post-fill_count specifies the number of samples to capture before stopping data acquisition.
- In the segment_trigger buffer control action (for segmented buffer), post-fill_count specifies a data segment.
When the Signal Tap data window displays the captured data, the trigger position appears as the number of post-count samples from the end of the acquisition segment or buffer.
Sample Number of Trigger Position = (N – Post-Fill Count)
In this case, N is the sample depth of either the acquisition segment or non-segmented buffer.
2.4.4.7. Power-Up Triggers
The typical use of Signal Tap logic analyzer is triggering events that occur during normal device operation. You start an analysis manually once the target device fully powers on and the JTAG connection for the device is available. With Signal Tap Power-Up Trigger feature, the Signal Tap logic analyzer captures data immediately after device initialization.
You can add a different Power-Up Trigger to each logic analyzer instance in the Signal Tap Instance Manager pane.
2.4.4.7.1. Enabling a Power-Up Trigger
To enable the Power-Up Trigger for Signal Tap instance:
Power-Up Trigger appears as a child instance below the name of the selected instance. The node list displays the default trigger conditions.
To disable a Power-Up Trigger, right-click the instance and click Disable Power-Up Trigger.
2.4.4.7.2. Configuring Power-Up Trigger Conditions
- Any change that you make to a Power-Up Trigger conditions requires that you recompile the Signal Tap logic analyzer instance, even if a similar change to the Runtime Trigger conditions does not require a recompilation.
- You can also force trigger conditions with the In-System Sources and Probes in conjunction with the Signal Tap logic analyzer. The In-System Sources and Probes feature allows you to drive and sample values on to selected nets over the JTAG chain.
2.4.4.7.3. Managing Signal Tap Instances with Run-Time and Power-Up Trigger Conditions
On instances that have two types of trigger conditions, Power-Up Trigger conditions are color coded light blue, while Run-Time Trigger conditions remain white.
- To switch between the trigger conditions of the Power-Up Trigger and the Run-Time Trigger, double-click the instance name or the Power-Up Trigger name in the Instance Manager.
-
To copy trigger conditions from a Run-Time Trigger to a
Power-Up Trigger or vice versa, right-click the trigger name in the Instance Manager and
click Duplicate
Trigger. Alternatively, select the trigger name and click
Edit > Duplicate
Trigger.
Figure 39. Instance Manager Commands
2.4.4.8. External Triggers
The external trigger input behaves like trigger condition 0, in that the condition must evaluate to TRUE before the logic analyzer evaluates any other trigger conditions.
The Signal Tap logic analyzer supplies a signal to trigger external devices or other logic analyzer instances. These features allow you to synchronize external logic analysis equipment with the internal logic analyzer. Power-Up Triggers can use the external triggers feature, but they must use the same source or target signal as their associated Run-Time Trigger.
- The processor debugger allows you to configure the HPS to obey or disregard cross-trigger request from the FPGA, and to issue or not issue cross-trigger requests to the FPGA.
- The processor debugger in combination with the Signal Tap external trigger feature allow you to develop a dynamic combination of cross-trigger behaviors.
- You can implement a system-level debugging solution for an Intel FPGA SoC by using the cross-triggering feature with the ARM Development Studio 5 (DS-5) software.
2.4.4.9. Trigger Condition Flow Control
- Sequential Triggering—default triggering flow. Sequential triggering allows you to define up to 10 triggering levels that must be satisfied before the acquisition buffer finishes capturing.
- State-Based Triggering—gives the greatest control over your acquisition buffer. Custom-based triggering allows you to organize trigger conditions into states based on a conditional flow that you define.
You can use sequential or state based triggering with either a segmented or a non-segmented buffer.
2.4.4.9.1. Sequential Triggering
When the last triggering condition evaluates to TRUE, the Signal Tap logic analyzer starts the data acquisition. For segmented buffers, every acquisition segment after the first starts on the last condition that you specified. The Simple Sequential Triggering feature allows you to specify basic triggers, comparison triggers, advanced triggers, or a mix of all three. The following figure illustrates the simple sequential triggering flow for non-segmented and segmented buffers. The acquisition buffer starts capture when all n triggering levels are satisfied, where n <10.
The Signal Tap logic analyzer considers external triggers as level 0, evaluating external triggers before any other trigger condition.
2.4.4.9.2. Configuring the Sequential Triggering Flow
- On Trigger Flow Control, select Sequential
-
On Trigger Conditions, select the number
of trigger conditions from the drop-down list.
The Node List pane now displays the same number of trigger condition columns.
-
Configure each trigger condition in the Node List
pane.
You can enable/disable any trigger condition from the column header.
2.4.4.9.3. Trigger that Skips Clock Cycles after Hitting Condition
Trigger flow description that skips three clock cycles of samples after hitting condition 1
Code:
State 1: ST1 start_store if ( condition1 ) begin stop_store; goto ST2; end State 2: ST2 if (c1 < 3) increment c1; //skip three clock cycles; c1 initialized to 0 else if (c1 == 3) begin start_store;//start_store necessary to enable writing to finish //acquisition trigger; end
The figures show the data transaction on a continuous capture and the data capture when you apply the Trigger flow description.
2.4.4.9.4. Storage Qualification with Post-Fill Count Value Less than m
Real data acquisition of the previous scenario
The data capture finishes successfully. It uses a buffer with a sample depth of 64, m = n = 10, and post-fill count = 5.
The combination of using counters, Boolean and relational operators in conjunction with the start_store and stop_store commands can give a clock-cycle level of resolution to controlling the samples that are written into the acquisition buffer.
2.4.4.9.5. State-Based Triggering
Custom state-based triggering grants control over triggering condition arrangement. Because the logic analyzer only captures samples of interest, custom state-based triggering allows for more efficient use of the space available in the acquisition buffer.
To help you describe the relationship between triggering conditions, the state-based triggering flow provides tooltips in the GUI. Additionally, you can use the Signal Tap Trigger Flow Description Language, which is based upon conditional expressions.
Each state allows you to define a set of conditional expressions. Conditional expressions are Boolean expressions that depend on a combination of triggering conditions, counters, and status flags. You configure the triggering conditions within the Setup tab. The Signal Tap logic analyzer custom-based triggering flow provides counters and status flags.
Notes to figure:
- You can define up to 20 different states.
- The logic analyzer evaluates external trigger inputs that you define before any conditions in the custom state-based triggering flow.
Within each conditional expression you define a set of actions. Actions include triggering the acquisition buffer to stop capture, a modification to either a counter or status flag, or a state transition.
Trigger actions can apply to either a single segment of a segmented acquisition buffer or to the entire non-segmented acquisition buffer. Each trigger action provides an optional count that specifies the number of samples the buffer captures before the logic analyzer stops acquisition of the current segment. The count argument allows you to control the amount of data the buffer captures before and after a triggering event occurs.
Resource manipulation actions allow you to increment and decrement counters or set and clear status flags. The logic analyzer uses counter and status flag resources as optional inputs in conditional expressions. Counters and status flags are useful for counting the number of occurrences of certain events and for aiding in triggering flow control.
The state-based triggering flow allows you to capture a sequence of events that may not necessarily be contiguous in time. For example, a communication transaction between two devices that includes a hand shaking protocol containing a sequence of acknowledgments.
2.4.4.9.6. State-Based Triggering Flow Tab
The State-Based Trigger Flow tab is the control interface for the custom state-based triggering flow.
This tab is only available when you select State-Based on the Trigger Flow Control list. If you specify Trigger Flow Control as Sequential, the State-Based Trigger Flow tab is not visible.

The State-Based Trigger Flow tab contains three panes:
2.4.4.9.7. State Machine Pane
The State Machine pane contains the text entry boxes where you define the triggering flow and actions associated with each state.
- You can define the triggering flow using the Signal Tap Trigger Flow Description Language, a simple language based on “if-else” conditional statements.
- Tooltips appear when you move the mouse over the cursor, to guide command entry into the state boxes.
- The GUI provides a syntax check on your flow description in real-time and highlights any errors in the text flow.
The State Machine description text boxes default to show one text box per state. You can also have the entire flow description shown in a single text field. This option can be useful when copying and pasting a flow description from a template or an external text editor. To toggle between one window per state, or all states in one window, select the appropriate option under State Display mode.
2.4.4.9.8. Resources Pane
The Resources pane allows you to declare status flags and counters for your Custom Triggering Flow's conditional expressions.
- You can increment/decrement counters or set/clear status flags within your triggering flow.
- You can specify up to 20 counters and 20 status flags.
- To initialize counter and status flags, right-click the row in the table and select Set Initial Value.
- To specify a counter width, right-click the counter in the table and select Set Width.
- To assist in debugging your trigger flow specification, the logic analyzer dynamically updates counters and flag values after acquisition starts.
The Configurable at runtime settings allow you to control which options can change at runtime without requiring a recompilation.
Setting | Description |
---|---|
Destination of goto action | Allows you to modify the destination of the state transition at runtime. |
Comparison values | Allows you to modify comparison values in Boolean expressions at runtime. In addition, you can modify the segment_trigger and trigger action post-fill count argument at runtime. |
Comparison operators | Allows you to modify the operators in Boolean expressions at runtime. |
Logical operators | Allows you to modify the logical operators in Boolean expressions at runtime. |
2.4.4.9.9. State Diagram Pane
The State Diagram pane provides a graphical overview of your triggering flow. this pane displays the number of available states and the state transitions. To adjust the number of available states, use the menu above the graphical overview.
2.4.4.9.10. Signal Tap Trigger Flow Description Language
The Trigger Flow Description Language is based on a list of conditional expressions per state to define a set of actions.
To describe the actions that the logic analyzer evaluates when a state is reached, follow this syntax:
Syntax of Trigger Flow Description Language
state <state_label>: <action_list> if (<boolean_expression>) <action_list> [else if (<boolean_expression>) <action_list>] [else <action_list>]
- Non-terminals are delimited by "<>".
- Optional arguments are delimited by "[]"
- The priority for evaluation of conditional statements is from top to bottom.
- The Trigger Flow Description Language allows multiple else if conditions.
2.4.4.9.11. <state_label>
The state description header syntax is:
state <state_label>The description of a state ends with the beginning of another state or the end of the whole trigger flow description.
2.4.4.9.12. <boolean_expression>
Collection of operators and operands that evaluate into a Boolean result. The operators can be logical or relational. Depending on the operator, the operand can reference a trigger condition, a counter and a register, or a numeric value. To group a set of operands within an expression, you use parentheses.
Operator | Description | Syntax |
---|---|---|
! | NOT operator | ! expr1 |
&& | AND operator | expr1 && expr2 |
|| | OR operator | expr1 || expr2 |
Operator | Description | Syntax |
---|---|---|
> | Greater than |
<identifier> > <numerical_value> |
>= | Greater than or Equal to |
<identifier> >= <numerical_value> |
== | Equals |
<identifier> == <numerical_value> |
!= | Does not equal |
<identifier> != <numerical_value> |
<= | Less than or equal to |
<identifier> <= <numerical_value> |
< | Less than |
<identifier> < <numerical_value> |
Notes to table:
|
- The <boolean_expression> in an if statement can contain a single event or multiple event conditions.
- When the boolean expression evaluates TRUE, the logic analyzer evaluates all the commands in the <action_list> concurrently.
2.4.4.9.13. <action_list>
List of actions that the logic analyzer performs within a state once a condition is satisfied.
- Each action must end with a semicolon (;).
- If you specify more than one action within an if or an else if clause, you must delimit the action_list with begin and end tokens.
Possible actions include:
Buffer Control Actions
Actions that control the acquisition buffer.
Action | Description | Syntax |
---|---|---|
trigger | Stops the acquisition for the current buffer and ends analysis. This command is required in every flow definition. |
trigger <post-fill_count>; |
segment_trigger |
Available only in segmented acquisition mode. Ends acquisition of the current segment. After evaluating this command, the Signal Tap logic analyzer starts acquiring from the next segment. If all segments are written, the logic analyzer overwrites the oldest segment with the latest sample. When a trigger action is evaluated the acquisition stops. |
segment_trigger <post-fill_count>; |
start_store | Active only in state-based storage qualifier mode. Asserts the write_enable to the Signal Tap acquisition buffer. |
start_store |
stop_store |
Active only in state-based storage qualifier mode. De-asserts the write_enable signal to the Signal Tap acquisition buffer. |
stop_store |
Both trigger and segment_trigger actions accept an optional post-fill_count argument.
State Transition Action
Specifies the next state in the custom state control flow. The syntax is:
goto <state_label>;2.4.4.9.14. Resource Manipulation Action
The resources the trigger flow description uses can be either counters or status flags.
Action | Description | Syntax |
---|---|---|
increment | Increments a counter resource by 1 |
increment <counter_identifier>; |
decrement | Decrements a counter resource by 1 |
decrement <counter_identifier>; |
reset | Resets counter resource to initial value |
reset <counter_identifier>; |
set | Sets a status flag to 1 |
set <register_flag_identifier>; |
clear | Sets a status flag to 0 |
clear <register_flag_identifier>; |
2.4.4.9.15. Buffer Control Actions
Actions that control the acquisition buffer.
Action | Description | Syntax |
---|---|---|
trigger | Stops the acquisition for the current buffer and ends analysis. This command is required in every flow definition. |
trigger <post-fill_count>; |
segment_trigger |
Available only in segmented acquisition mode. Ends acquisition of the current segment. After evaluating this command, the Signal Tap logic analyzer starts acquiring from the next segment. If all segments are written, the logic analyzer overwrites the oldest segment with the latest sample. When a trigger action is evaluated the acquisition stops. |
segment_trigger <post-fill_count>; |
start_store | Active only in state-based storage qualifier mode. Asserts the write_enable to the Signal Tap acquisition buffer. |
start_store |
stop_store |
Active only in state-based storage qualifier mode. De-asserts the write_enable signal to the Signal Tap acquisition buffer. |
stop_store |
Both trigger and segment_trigger actions accept an optional post-fill_count argument.
2.4.4.9.16. State Transition Action
Specifies the next state in the custom state control flow. The syntax is:
goto <state_label>;2.4.4.9.17. State-Based Storage Qualifier Feature
Selecting a state-based storage qualifier type enables the start_store and stop_store actions. When you use these actions in conjunction with the expressions of the State-based trigger flow, you get maximum flexibility to control data written into the acquisition buffer.
The start_store and stop_store commands are similar to the start and stop conditions of the start/stop storage qualifier mode. If you enable storage qualification, Signal Tap logic analyzer doesn't write data into the acquisition buffer until the start_store command occurs. However, in the state-based storage qualifier type you must include a trigger command as part of the trigger flow description. This trigger command is necessary to complete the acquisition and display the results on the waveform display.
2.4.4.9.18. Storage Qualification Feature for the State-Based Trigger Flow.
This trigger flow description contains three trigger conditions that occur at different times after you click Start Analysis:
State 1: ST1: if ( condition1 ) start_store; else if ( condition2 ) trigger value; else if ( condition3 ) stop_store;
When you apply the trigger flow to the scenario in the figure:
- The Signal Tap logic analyzer does not write into the acquisition buffer until Condition 1 occurs (sample a).
- When Condition 2 occurs (sample b), the logic analyzer evaluates the trigger value command, and continues to write into the buffer to finish the acquisition.
- The trigger flow specifies a stop_store command at sample c, which occurs m samples after the trigger point.
- If the data acquisition finishes the post-fill acquisition samples before Condition 3 occurs, the logic analyzer finishes the acquisition and displays the contents of the waveform. In this case, the capture ends if the post-fill count value is < m.
- If the post-fill count value in the Trigger Flow description 1 is > m samples, the buffer pauses acquisition indefinitely, provided there is no recurrence of Condition 1 to trigger the logic analyzer to start capturing data again.
The Signal Tap logic analyzer continues to evaluate the stop_store and start_store commands even after evaluating the trigger. If the acquisition paused, click Stop Analysis to manually stop and force the acquisition to trigger. You can use counter values, flags, and the State diagram to help you perform the trigger flow. The counter values, flags, and the current state update in real-time during a data acquisition.
2.4.4.10. Trigger Lock Mode
Trigger lock mode restricts changes to only the configuration settings that you specify as Configurable at runtime. The runtime configurable settings for the Custom Trigger Flow tab are on by default.
You can restrict changes to your Signal Tap configuration to include only the options that do not require a recompilation. Trigger lock-mode allows you to make changes that reflect immediately in the device.
- On the Setup tab, point to Lock mode and
select Allow trigger condition changes only. Figure 49. Allow Trigger Conditions Change Only
- Modify the Trigger Flow conditions.
2.4.5. Specifying Pipeline Settings
To specify the pipeline factor from the Signal Tap GUI:
- In the Signal Configuration pane, specify a pipeline factor ranging from 0 to 5. The default value is 0.
Alternatively, you can specify pipeline parameters as part of HDL instantiation, as Creating a Signal Tap Instance by HDL Instantiation describes.
2.4.6. Filtering Relevant Samples
The Signal Tap logic analyzer offers a snapshot in time of the data that the acquisition buffers store. By default, the Signal Tap logic analyzer writes into acquisition memory with data samples on every clock cycle. With a non-segmented buffer, there is one data window that represents a comprehensive snapshot of the data stream. Conversely, segmented buffers use several smaller sampling windows spread out over more time, with each sampling window representing a contiguous data set.
With analysis using acquisition buffers you can capture most functional errors in a chosen signal set, provided adequate trigger conditions and a generous sample depth for the acquisition. However, each data window can have a considerable amount of unnecessary data; for example, long periods of idle signals between data bursts. The default behavior in the Signal Tap logic analyzer doesn't discard the redundant sample bits.
The Storage Qualifier feature allows you to establish a condition that acts as a write enable to the buffer during each clock cycle of data acquisition, thus allowing a more efficient use of acquisition memory over a longer period of analysis.
Because you can create a discontinuity between any two samples in the buffer, the Storage Qualifier feature is equivalent to creating a custom segmented buffer in which the number and size of segment boundaries are adjustable.
Notes to figure:
- Non-segmented buffers capture a fixed sample window of contiguous data.
- Segmented buffers divide the buffer into fixed sized segments, with each segment having an equal sample depth.
- Storage Qualifier allows you to define a custom sampling window for each segment you create with a qualifying condition, thus potentially allowing a larger time scale of coverage.
There are six storage qualifier types available under the Storage Qualifier feature:
- Continuous (default) Turns the Storage Qualifier off.
- Input port
- Transitional
- Conditional
- Start/Stop
- State-based

Upon the start of an acquisition, the Signal Tap logic analyzer examines each clock cycle and writes the data into the buffer based upon the storage qualifier type and condition. Acquisition stops when a defined set of trigger conditions occur.
The Signal Tap logic analyzer evaluates trigger conditions independently of storage qualifier conditions.
2.4.6.1. Input Port Mode
When creating a Signal Tap logic analyzer instance with the Signal Tap logic analyzer GUI, specify the Storage Qualifier signal for the Input port field located on the Setup tab. You must specify this port for your project to compile.
When creating a Signal Tap logic analyzer instance through HDL instantiation, specify the Storage Qualifier parameter to include in the instantiation template. You can then connect this port to a signal in your RTL. If you enable the input port storage qualifier, the port accepts a signal and predicates when signals are recorded into the acquisition buffer before or after the specified trigger condition occurs. That is, the trigger you specify is responsible for triggering and moving the logic analyzer into the post-fill state. The input port storage qualifier signal you select controls the recording of samples.
The following example compares and contrasts two waveforms of the same data, one without storage qualifier enabled (Continuous means always record samples, effectively no storage qualifier), and the other with Input Port mode. The bottom signal in the waveform, data_out[7],is the input port storage qualifier signal. The continuous mode waveform shows 01h, 07h, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h as the sequence of data_out[7] bus values where the storage qualifier signal is asserted. The lower waveform for input port storage qualifier shows how this same traffic pattern of the data_out bus is recorded when you enable the input port storage qualifier. Values recorded are a repeating sequence of the 01h, 07h, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h (same as Continuous mode).
- Continuous Mode:
- Input Port Storage Qualifier:
2.4.6.2. Transitional Mode
- Continuous mode:
- Transitional mode:
2.4.6.3. Conditional Mode
You can select either Basic AND, Basic OR, Comparison, or Advanced storage qualifier conditions. A Basic AND or Basic OR condition matches each signal to one of the following:
- Don’t Care
- Low
- High
- Falling Edge
- Rising Edge
- Either Edge
If you specify a Basic AND storage qualifier condition for more than one signal, the Signal Tap logic analyzer evaluates the logical AND of the conditions.
You can specify any other combinational or relational operators with the enabled signal set for storage qualification through advanced storage conditions.
You can define storage qualification conditions similar to the manner in which you define trigger conditions.
The data pattern is the same in both cases.
- Continuous sampling capture mode:
- Conditional sampling capture mode:
2.4.6.4. Start/Stop Mode
-
Continuous Mode:
-
Start/Stop Storage Qualifier:
2.4.6.5. State-Based Mode
When you enable the storage qualifier feature for the State-based flow, two additional commands become available: start_store and stop_store. These commands are similar to the Start/Stop capture conditions. Upon the start of acquisition, the Signal Tap logic analyzer doesn't write data into the buffer until a start_store action is performed. The stop_store command pauses the acquisition. If both start_store and stop_store actions occur within the same clock cycle, the logic analyzer stores a single sample into the acquisition buffer.
2.4.6.6. Showing Data Discontinuities
2.4.6.7. Disable the Storage Qualifier
2.5. Step 3: Compile the Design and Signal Tap Instances
When you define a Signal Tap instance in the logic analyzer GUI or with HDL instantiation, the Signal Tap logic analyzer instance becomes part of your design for compilation.
To run full compilation of the design that includes the Signal Tap logic analyzer instance:
- Click Processing > Start Compilation
You can employ various techniques to preserve specific signals for debugging during compilation, and to reduce overall compilation time and iterations. Refer to the following sections for more details.
- Preserving Signals for Monitoring
The Compiler optimizes the RTL signals during synthesis and place-and-route. RTL signal names may not exist in the post-fit netlist after signal optimizations. For example, the compilation process can add tildes (~) to net names that fan-out from a node, making it difficult to identify which signal nets they actually represent. - Timing Preservation
- Prevent Changes Requiring Recompilation
Making some types of changes to the Signal Tap configuration require recompilation to implement. To ensure that you make no changes to the Signal Tap configuration that require recompilation, select Allow trigger condition changes only for the Lock mode. - Performance and Resource Considerations
2.5.1. Preserving Signals for Monitoring
The Intel® Quartus® Prime software provides the keep and preserve synthesis attributes that you can use to prevent the Compiler from performing optimizations on specific signals, allowing them to persist into the post-fit netlist for Signal Tap monitoring.
The optimization attributes are:
- keep—prevents removal of combinational signals during optimization.
- preserve—prevents removal of registers during optimization.
Preserving nodes is helpful when you plan to add groups of signals for the Nios® II Intel® FPGA IP using a plug-in. When debugging an encrypted IP core, such as the Nios® II CPU, preserving nodes is essential to ensure that signals are available for debugging.
2.5.2. Timing Preservation
The Intel® Quartus® Prime Pro Edition software supports timing preservation for post-fit taps with the Rapid Recompile feature. Rapid Recompile automatically reuses verified portions of the design during recompilations, rather than reprocessing those portions.
The following techniques can help you preserve timing in designs that include the Signal Tap logic analyzer :
- Avoid adding critical path signals to the .stp file.
- Minimize the number of combinational signals you add to the .stp file, and add registers whenever possible.
- Specify an fMAX constraint for each clock in the design.
2.5.3. Prevent Changes Requiring Recompilation
2.5.3.1. Checking Recompilation Status
To verify whether a change you made to the Signal Tap configuration requires recompiling the project, check the Signal Tap status display at the top of the Instance Manager pane, as Signal Tap Status Messages describes
2.5.4. Performance and Resource Considerations
When you perform logic analysis of your design, you can see the necessary trade-off between runtime flexibility, timing performance, and resource usage. The Signal Tap logic analyzer allows you to select runtime configurable parameters to balance the need for runtime flexibility, speed, and area.
The default values of the runtime configurable parameters provide maximum flexibility, so you can complete debugging as quickly as possible; however, you can adjust these settings to determine whether there is a more appropriate configuration for your design. Because performance results are design-dependent, try these options in different combinations until you achieve the desired balance between functionality, performance, and utilization.
2.5.4.1. Increasing Signal Tap Logic Performance
If Signal Tap logic is part of your critical path, follow these tips to speed up the performance of the Signal Tap logic:
- Disable runtime configurable options—runtime flexibility features expend some device resources. If you use Advanced Triggers or State-based triggering flow, disable runtime configurable parameters to a boost in fMAX of the Signal Tap logic. If you use State-based triggering flow, disable the Goto state destination option and performing a recompilation before disabling the other runtime configurable options. The Goto state destination option has the greatest impact on fMAX, compared to the other runtime configurable options.
- Minimize the number of signals that have Trigger Enable selected—By default, Signal Tap logic analyzer enables the Trigger Enable option for all signals that you add to the .stp file. For signals that you do not plan to use as triggers, turn this option off.
- Turn on Physical Synthesis for register retiming—If many (more than the number of inputs that fit in a LAB) enabled triggering signals fan-in logic to a gate-based triggering condition (basic trigger condition or a logical reduction operator in the advanced trigger tab), turn on Perform register retiming. This can help balance combinational logic across LABs.
2.5.4.2. Reducing Signal Tap Device Resources
- Disable runtime configurable options—disabling runtime configurability for advanced trigger conditions or runtime configurable options in the State-based triggering flow results in fewer LEs.
- Minimize the number of segments in the acquisition buffer—you can reduce the logic resources that the Signal Tap logic analyzer requires if you limit the segments in your sampling buffer.
- Disable the Data Enable for signals that you use only for triggering—by default, the Signal Tap logic analyzer enables data enable options for all signals. Turning off the data enable option for signals you use only as trigger inputs saves memory resources.
2.6. Step 4: Program the Target Hardware
When you debug a design with the Signal Tap logic analyzer, you can program a target device directly using the supported JTAG hardware from the Signal Tap window, without using the Intel® Quartus® Prime Programmer.
2.6.1. Ensure Compatibility Between .stp and .sof Files
The .stp file is compatible with a .sof file if the logic analyzer instance parameters, such as the size of the capture buffer and the monitoring and triggering signals, match the programming settings for the target device. If the files are not compatible, you can still program the device, but you cannot run or control the logic analyzer from the Signal Tap logic analyzer GUI.
- To ensure programming compatibility, program the FPGA device with the he most recent .sof file.
2.7. Step 5: Run the Signal Tap Logic Analyzer
- You first select the Signal Tap instance, and
then initialize the logic analyzer for that instance by clicking Processing > Run Analysis in the Signal Tap logic analyzer
GUI.Figure 60. Starting Signal Tap Analysis
- When a trigger event occurs, the logic analyzer stores the captured data in the FPGA device's memory buffer, and then transfers this data to the Signal Tap logic analyzer GUI over the JTAG connection. You can perform the equivalent of a force trigger instruction that allows you to view the captured data currently in the buffer without a trigger event occurring
You can also use In-System Sources and Probes in conjunction with the Signal Tap logic analyzer to force trigger conditions. The In-System Sources and Probes feature allows you to drive and sample values on to selected signals over the JTAG chain.
2.7.1. Runtime Reconfigurable Options
When you use Runtime Trigger mode, you can change certain settings in the .stp without requiring recompilation of the design.
Runtime Reconfigurable Setting | Description |
---|---|
Basic Trigger Conditions and Basic Storage Qualifier Conditions | Change without recompiling all signals that have the Trigger condition turned on to any basic trigger condition value |
Comparison Trigger Conditions and Comparison Storage Qualifier Conditions |
All the comparison operands, the comparison numeric values, and the interval bound values are runtime-configurable. You can also switch from Comparison to Basic OR trigger at runtime without recompiling. |
Advanced Trigger Conditions and Advanced Storage Qualifier Conditions | Many operators include runtime configurable settings. For example, all comparison operators are runtime-configurable. Configurable settings appear with a white background in the block representation. This runtime reconfigurable option is turned on in the Object Properties dialog box. |
Switching between a storage-qualified and a continuous acquisition | Within any storage-qualified mode, you can switch to continuous capture mode without recompiling the design. To enable this feature, turn on disable storage qualifier. |
State-based trigger flow parameters | Refer to Runtime Reconfigurable Settings, State-Based Triggering Flow |
Runtime Reconfigurable options can save time during the debugging cycle by allowing you to cover a wider possible range of events, without requiring design recompilation. You may experience a slight impact to the performance and logic utilization. You can turn off runtime re-configurability for advanced trigger conditions and the state-based trigger flow parameters, boosting performance and decreasing area utilization.
To configure the .stp file to prevent changes that normally require recompilation in the Setup tab, select Allow Trigger Condition changes only above the node list.
This example illustrates a potential use case for Runtime Reconfigurable features, by providing a storage qualified enabled State-based trigger flow description, and showing how to modify the size of a capture window at runtime without a recompile. This example gives you equivalent functionality to a segmented buffer with a single trigger condition where the segment sizes are runtime reconfigurable.
state ST1: if ( condition1 && (c1 <= m) )// each "segment" triggers on condition // 1 begin // m = number of total "segments" start_store; increment c1; goto ST2: End else (c1 > m ) // This else condition handles the last // segment. begin start_store Trigger (n-1) end state ST2: if ( c2 >= n) //n = number of samples to capture in each //segment. begin reset c2; stop_store; goto ST1; end else (c2 < n) begin increment c2; goto ST2; end
The next figure shows the segmented buffer that the trigger flow example describes.
During runtime, you can modify the values m and n. Changing the m and n values in the trigger flow description adjust the segment boundaries without recompiling.
You can add states into the trigger flow description and selectively mask out specific states and enable other ones at runtime with status flags.
This example is like the previous example with an additional state inserted. You use this extra state to specify a different trigger condition that does not use the storage qualifier feature. You insert status flags into the conditional statements to control the execution of the trigger flow.
state ST1 : if (condition2 && f1) // additional state added for a non-segmented // acquisition set f1 to enable state begin start_store; trigger end else if (! f1) goto ST2; state ST2: if ( (condition1 && (c1 <= m) && f2) // f2 status flag used to mask state. Set f2 // to enable begin start_store; increment c1; goto ST3: end else (c1 > m ) start_store Trigger (n-1) end state ST3: if ( c2 >= n) begin reset c2; stop_store; goto ST1; end else (c2 < n) begin increment c2; goto ST2; end
2.7.2. Signal Tap Status Messages
The following table describes the text messages that might appear in the Signal Tap Status Indicator in the Instance Manager pane before, during, or after data acquisition. These messages allow you to monitor the state of the logic analyzer and identify the operation that the logic analyzer is performing.
Message | Message Description |
---|---|
Not running | The Signal Tap
logic analyzer is not running. This message appears when there is no connection to a device, or the device is not configured. |
(Power-Up Trigger) Waiting for clock (1) | The Signal Tap logic analyzer is performing a Runtime or Power-Up Trigger acquisition and is waiting for the clock signal to transition. |
Acquiring (Power-Up) pre-trigger data (1) | The trigger condition is not yet evaluated. If the acquisition mode is non-segmented buffer, and the storage qualifier type is continuous, the Signal Tap logic analyzer collects a full buffer of data. |
Trigger In conditions met | Trigger In conditions are met. The Signal Tap logic analyzer is waiting
for the first trigger condition to occur. This message only appears when a Trigger In condition exists. |
Waiting for (Power-up) trigger (1) | The Signal Tap logic analyzer is waiting for the trigger event to occur. |
Trigger level <x> met | Trigger condition x occurred. The Signal Tap logic analyzer is waiting for condition x + 1 to occur. |
Acquiring (power-up) post-trigger data (1) | The entire trigger event occurred. The Signal Tap logic analyzer is acquiring
the post-trigger data. You define the amount of post-trigger data to collect (between 12%, 50%, and 88%) when you select the non-segmented buffer acquisition mode. |
Offload acquired (Power-Up) data (1) | The JTAG chain is transmitting data to the Intel® Quartus® Prime software. |
Ready to acquire | The Signal Tap logic analyzer is waiting for you to initialize the analyzer. |
|
2.8. Step 6: Analyze Signal Tap Captured Data
- To simplify reading and interpreting the signal data you capture, set up mnemonic tables, either manually or with a plug-in.
- To speed up debugging, use the Locate feature in the Signal Tap node list to find the locations of problem nodes in other tools in the Intel® Quartus® Prime software.
2.8.1. Viewing Capture Data Using Segmented Buffers
Each acquisition segment acts as a non-segmented buffer, continuously capturing data after activation. When you run analyses with segmented buffers, the Signal Tap logic analyzer captures back-to-back data for each acquisition segment within the data buffer. You define the trigger flow, or the type and order in which the trigger conditions evaluate for each buffer, either in the Sequential trigger flow control or in the Custom State-based trigger flow control.
The following figure shows a segmented acquisition buffer with four segments represented as four separate non-segmented buffers.
When the Signal Tap logic analyzer finishes an acquisition with a segment and advances to the next segment to start a new acquisition. The data capture that appears in the waveform viewer depends on when a trigger condition occurs. The figure illustrates the data capture method. The Trigger markers—Trigger 1, Trigger 2, Trigger 3 and Trigger 4—refer to the evaluation of the segment_trigger and trigger commands in the Custom State-based trigger flow. In sequential flows, the Trigger markers refer to trigger conditions that you specify within the Setup tab.
If the Segment 1 Buffer is the active segment and Trigger 1 occurs, the Signal Tap logic analyzer starts evaluating Trigger 2 immediately. Data Acquisition for Segment 2 buffer starts when either Segment Buffer 1 finishes its post-fill count, or when Trigger 2 evaluates as TRUE, whichever condition occurs first. Thus, trigger conditions associated with the next buffer in the data capture sequence can preempt the post-fill count of the current active buffer. This allows the Signal Tap logic analyzer to accurately capture all the trigger conditions that occurred. Unused samples appear as a blank space in the waveform viewer.
Each segment before the last captures only one sample, because the next trigger condition immediately preempts capture of the current buffer. The trigger position for all segments is specified as pre-trigger (10% of the data is before the trigger condition and 90% of the data is after the trigger position). Because the last segment starts immediately with the trigger condition, the segment contains only post-trigger data. The three empty samples in the last segment are left over from the pre-trigger samples that the Signal Tap logic analyzer allocated to the buffer.
For the sequential trigger flow, the Trigger Position option applies to every segment in the buffer. A custom state-based trigger flow provides maximum flexibility defining the trigger position. By adjusting the trigger position specific to the debugging requirements, you can help maximize the use of the allocated buffer space.
2.8.2. Viewing Data with Different Acquisition Modes
Different acquisition modes capture different amounts of data immediately after running the Signal Tap logic analyzer and before any trigger conditions occur.
Non-Segmented Buffers in Continuous Mode
In configurations with non-segmented buffers running in continuous mode, the buffer must be full with sampled data before evaluating any trigger condition. Only after the buffer is full, the Signal Tap logic analyzer starts retrieving data through the JTAG connection and evaluates the trigger condition.
If you click the Stop Analysis button, Signal Tap prevents the buffer from dumping during the first acquisition prior to a trigger condition.
Buffers with Storage Qualification
For buffers using a storage qualification mode, the Signal Tap logic analyzer immediately evaluates all trigger conditions while writing samples into the acquisition memory. This evaluation is especially important when using any storage qualification on the data set. The logic analyzer may miss a trigger condition if it waits to capture a full buffer's worth of data before evaluating any trigger conditions.
If a trigger activates before the specified amount of pre-trigger data has occurred, the Signal Tap logic analyzer begins filling memory with post-trigger data, regardless of the amount of pre-trigger data you specify. For example, if you set the trigger position to 50% and set the logic analyzer to trigger on a processor reset, start the logic analyzer, and then power on the target system, the trigger activates. However, the logic analyzer memory contains only post-trigger data, and not any pre-trigger data, because the trigger event has higher precedence than the capture of pre-trigger data.
2.8.2.1. Continuous Mode and a Storage Qualifier Examples
The following show the capture differences between a non-segmented buffer in continuous mode and a non-segmented buffer using a storage qualifier. The configuration of the logic analyzer waveforms is a base trigger condition, sample depth of 64 bits, and Post trigger position.
In the continuous data capture, Trig1 occurs several times in the data buffer before the Signal Tap logic analyzer trigger activates. The buffer must be full before the logic analyzer evaluates any trigger condition. After the trigger condition occurs, the logic analyzer continues acquisition for eight additional samples (12% of the buffer, as defined by the "post-trigger" position).
Note to figure:
- Conditional capture, storage always enabled, post-fill count.
- The Signal Tap logic analyzer capture of a recurring pattern using a non-segmented buffer in conditional mode. The configuration of the logic analyzer is a basic trigger condition "Trig1" and sample depth of 64 bits. The Trigger in condition is Don't care, so the buffer captures all samples.
In conditional capture the logic analyzer triggers immediately. As in continuous capture, the logic analyzer completes the acquisition with eight samples, or 12% of 64, the sample capacity of the acquisition buffer.
2.8.3. Creating Mnemonics for Bit Patterns
- Right-click the Setup or Data tab of a Signal Tap instance, and click Mnemonic Table Setup.
- Create a mnemonic table by entering sets of bit patterns and specifying a label to represent each pattern.
- Assign the table to a group of signals by right-clicking the group, clicking Bus Display Format, and selecting the mnemonic table.
- On the Setup tab, you can create basic triggers with meaningful names by right-clicking an entry in the Trigger Conditions column and selecting a label from the table you assigned to the signal group.
2.8.3.1. Adding Mnemonics with a Plug-In
As an example, the Nios® II plug-in helps you to monitor signal activity for your design as the code is executed. If you set up the logic analyzer to trigger on a function name in your Nios® II code based on data from an .elf, you can see the function name in the Instance Address signal group at the trigger sample, along with the corresponding disassembled code in the Disassembly signal group, as shown in Figure 13–52. Captured data samples around the trigger are referenced as offset addresses from the trigger function name.
2.8.4. Locating a Node in the Design
You can locate a signal from the node list with the following tools:
- Assignment Editor
- Pin Planner
- Timing Closure Floorplan
- Chip Planner
- Resource Property Editor
- Technology Map Viewer
- RTL Viewer
- Design File
2.8.5. Saving Captured Signal Tap Data
When you set Signal Tap analysis to Auto-run mode, the logic analyzer creates a separate entry in the Data Log to store the data captured each time the trigger occurs. This preservation allows you to review the captured data for each trigger event.
The default name for a log derives from the time stamp when the logic analyzer acquires the data. As a best practice, rename the data log with a more meaningful name.
The organization of logs is hierarchical; the logic analyzer groups similar logs of captured data in trigger sets.
2.8.6. Exporting Captured Signal Tap Data
- Comma Separated Values File (.csv)
- Table File (.tbl)
- Value Change Dump File (.vcd)
- Vector Waveform File (.vwf)
- Graphics format files (.jpg, .bmp)
To export the captured data from Signal Tap logic analyzer, click File > Export, and then specify the File Name, Export Format, and Clock Period.
2.8.7. Creating a Signal Tap List File
The Signal Tap list file is especially useful when combined with a plug-in that includes instruction code disassembly. You can view the order of instruction code execution during the same time period of the trigger event.
To create a Signal Tap, click File > Create/Update > Create Signal Tap List File.
Each row of the list file corresponds to one captured sample in the buffer. Columns correspond to the value of each of the captured signals or signal groups for that sample. If you defined a mnemonic table for the captured data, a matching entry from the table replaces the numerical values in the list.
2.9. Other Signal Tap Debugging Flows
2.9.1. Managing Multiple Signal Tap Configurations
You can debug different blocks in your design by grouping related monitoring signals. Similarly, you can use a group of signals to define multiple trigger conditions. Each combination of signals, capture settings, and trigger conditions determines a debug configuration, and one configuration can have zero or more associated data logs.
You can save each debug configuration as a different .stp file. Alternatively, you can embed multiple configurations within the same .stp file, and use the Data Log to view and manage each debug configuration.
2.9.1.1. Data Log Pane
- To save the current configuration or capture in the Data Log—and .stp file, click Edit > Save to Data Log.
- To generate a log entry after every data capture, click Edit > Enable Data Log. Alternatively, check the box at the top of the Data Log pane.
The Data Log displays its contents in a tree hierarchy. The active items display a different icon.
Item | Icon | Contains one or more | Comments | |
---|---|---|---|---|
Unselected | Selected | |||
Instance |
![]() |
![]() |
Signal Set | |
Signal Set |
![]() |
![]() |
Trigger | The Signal Set changes whenever you add a new signal to Signal Tap. After a change in the Signal Set, you need to recompile. |
Trigger |
![]() |
![]() |
Capture Log | A trigger changes when you change any trigger condition. These changes do not require recompilation. |
Capture Log |
![]() |
![]() |
The name on each entry displays the wall-clock time when the Signal Tap logic analyzer triggers, and the time elapsed from start acquisition to trigger activation. You can rename entries.
To switch between configurations, double-click an entry in the Data Log. As a result, the Setup tab updates to display the active signal list and trigger conditions.
2.9.1.2. SOF Manager
The SOF Manager is in the JTAG Chain Configuration pane.
With the SOF Manager you can attach
multiple .sof files to a
single .stp file. This
attachment allows you to move the .stp file to a different location, either on the same computer or across a
network, without including the attached .sof separately. To attach a new .sof in the .stp file, click the Attach SOF File icon .
As you switch between configurations in the Data Log, you can extract the .sof that is compatible with that configuration.
To download the new .sof to the FPGA, click the Program
Device icon in the SOF Manager, after ensuring that the configuration of your .stp matches the design programmed into
the target device.
2.9.2. Debugging Partial Reconfiguration Designs with Signal Tap
For examples on debugging PR designs targeting specific devices, refer to AN 841: Signal Tap Tutorial for Intel® Stratix® 10 Partial Reconfiguration Design or AN 845: Signal Tap Tutorial for Intel® Arria® 10 Partial Reconfiguration Design .
2.9.2.1. Signal Tap Guidelines for PR Designs
- Include one .stp file per project revision.
- Tap pre-synthesis nodes only. In the Node Finder, filter by Signal Tap: pre-synthesis.
- Do not tap nodes in the default persona (the personas you use in the base revision compile). Create a new PR implementation revision that instantiates the default persona, and tap nodes in the new revision.
- Store all the tapped nodes from a PR persona in one .stp file, to enable debugging the entire persona using only one Signal Tap window.
- Do not tap across PR regions, or from a static region to a PR region in the same .stp file.
- Each Signal Tap window opens only one .stp file. Therefore, to debug more than one partition simultaneously, you must use stand-alone Signal Tap from the command-line.
2.9.2.2. PR Design Setup for Signal Tap Debug
To debug a PR design you must instantiate SLD JTAG bridges when generating the base revision, and then define debug components for all PR personas. Optionally, you can specify signals to tap in the static region. After configuring all the PR personas in the design, you can continue the PR design flow.
2.9.2.2.1. Preparing the Static Region for Signal Tap Debugging
To debug the static region in your PR design:
- Tap nodes in the static region exclusively.
- Save the .stp file with a name that identifies the file with the static region.
- Enable Signal Tap in your project, and include the .stp file in the base revision.
2.9.2.2.2. Preparing the Base Revision for Signal Tap Debugging
In the base revision, for each PR region that you want to debug in the design:
- Instantiate the SLD JTAG Bridge Agent Intel® FPGA IP in the static region.
- Instantiate the SLD JTAG Bridge Host Intel® FPGA IP in the PR region of the default persona.
You can use the IP Catalog or Platform Designer to instantiate SLD JTAG Bridge components.
2.9.2.2.3. Preparing PR Personas for Signal Tap Debugging
For each PR persona that you want to debug:
- Instantiate the SLD JTAG bridge host Intel® FPGA IP in the PR persona.
- Tap pre-synthesis nodes in the PR persona only.
- Save in a new .stp file with a name that identifies the persona.
- Use the new .stp file in the implementation revision.
2.9.2.3. Performing Data Acquisition in a PR design
To perform data acquisition:
- Program the base image into your device.
- Partially reconfigure the device with the persona that you want to debug.
-
Open the Signal Tap logic
analyzer by clicking Tools >
Signal Tap
logic analyzer in the
Intel®
Quartus® Prime
software.
The logic analyzer opens and loads the .stp file set in the current active revision.
-
To debug other regions in your design, open new Signal Tap windows by opening the other region's
.stp file from the
Intel®
Quartus® Prime main window.
Alternatively, use the command-line:
quartus_stpw <stp_file_other_region.stp>
- Debug your design with Signal Tap.
2.9.3. Debugging Block-Based Designs with Signal Tap
Verifying a block-based design requires planning to ensure visibility of logic inside partitions and communication with the Signal Tap logic analyzer. The preparation steps depend on whether you are reusing a core partition or a root partition.
For information about designing with reusable blocks, refer to the Intel® Quartus® Prime Pro Edition User Guide: Block-Based Design . For step-by-step block-based design debugging instructions, refer to AN 847: Signal Tap Tutorial with Design Block Reuse for Intel® Arria® 10 FPGA Development Board.
2.9.3.1. Signal Tap Debugging with a Core Partition
To perform Signal Tap debugging in a core design partition that you reuse from another project, you identify the signals of interest, and then make those signals visible to a Signal Tap logic analyzer instance. The Intel® Quartus® Prime software supports two methods to make the reused core partition signals visible for Signal Tap monitoring: by creating partition boundary ports, or by Signal Tap HDL instantiation.
2.9.3.1.1. Partition Boundary Ports Method
- In the project that exports the partition, define boundary ports for all potential Signal Tap nodes in the core partition. Define partition boundary ports with the Create Partition Boundary Ports assignment in the Assignment Editor. When you assign a bus, the assignment applies to the root name of the debug port, with each bit enumerated.
- In the project that exports the partition, create a black box file that includes the partition boundary ports, to allows tapping these ports as pre-synthesis or post-fit nodes in another project.
- In the project that reuses the partition, run Analysis & Synthesis on the reused partition. All valid ports with the Create Partition Boundary Ports become visible in the project. After synthesis you can verify the partition boundary ports in the Create Partition Boundary Ports report in the In-System Debugging folder under Synthesis reports.
- Tap the partition boundary ports to connect to a Signal Tap instance in the top-level partition. You can also tap logic from the top-level partition to this Signal Tap instance. When using this method, the project requires only one Signal Tap instance to debug both the top-level and the reused core partition.
The following procedures explain these steps in more detail.
2.9.3.1.2. Debug a Core Partition through Partition Boundary Ports
- Add to your project the black-box file that you create in Export a Core Partition with Partition Boundary Ports.
- To run synthesis, double-click Analysis & Synthesis on the Compilation Dashboard.
- Define a Signal Tap instance with the Signal Tap GUI, or by instantiating a Signal Tap HDL instance in the top level root partition, as Step 1: Add the Signal Tap Logic Analyzer to the Project describes.
- Connect the partition boundary ports of the reused core partition to the HDL instance, or add post-synthesis or post-fit nodes to the Signal Configuration tab in the Signal Tap logic analyzer GUI.
- To create a design partition, click Assignments > Design Partitions Window. Define a partition and assign the exported partition .qdb file as the Partition Database File option.
- Compile the design, including all partitions and the Signal Tap instance.
- Program the Intel FPGA device with the design and Signal Tap instances.
- Perform data acquisition with the Signal Tap logic analyzer GUI.
2.9.3.1.3. Export a Core Partition with Partition Boundary Ports
- To run synthesis, double-click Analysis & Synthesis on the Compilation Dashboard.
- Define a design partition for reuse that contains only core logic. Click Assignments > Design Partitions Window to define the partition.
- To create partition boundary ports for the core partition, specify the Create Partition Boundary Ports assignment in the Assignment Editor for partition ports.
- Click Project > Export Design Partition. By default, the .qdb file you export includes any Signal Tap HDL instances for the partition.
- Compile the design and Signal Tap instance.
- Create a black box file that defines only the port and module or entity definitions, without any logic.
- Manually copy the exported partition .qdb file and any black box file to the other project.
Optionally, you can verify signals in the root and core partitions in the Developer project with the Signal Tap logic analyzer.
2.9.3.1.4. Signal Tap HDL Instance Method
To use the Signal Tap HDL instance method you create a Signal Tap HDL instance in the reusable core partition, and then connect the signals of interest to that instance. The Compiler ensures top-level visibility of Signal Tap instances inside partitions. Since the root partition and the core partition have separated HDL instances, the Signal Tap files are also separate.
When you reuse the partition in another project, you must generate one Signal Tap file in the target project for each HDL instance present in the reused partition.
2.9.3.1.5. Export a Core Partition with Signal Tap HDL Instances
- To run synthesis, double-click Analysis & Synthesis on the Compilation Dashboard.
- Define a design partition for reuse that contains only core logic. Click Assignments > Design Partitions Window to define the partition.
- Add a Signal Tap HDL instance to the core partition, connecting it to nodes of interest.
- Click Project > Export Design Partition. By default, the .qdb file you export includes any Signal Tap HDL instances for the partition.
- Create a black box file that defines only the port and module or entity definitions, without any logic.
- Manually copy the exported partition .qdb file and any black box file to the other project.
2.9.3.1.6. Debug a Core Partition Exported with Signal Tap HDL Instances
- Add to your project the black-box file that you create in Export a Core Partition with Signal Tap HDL Instances.
- To create a design partition, click Assignments > Design Partitions Window. Define a partition and assign the exported partition .qdb file as the Partition Database File option.
- Create a Signal Tap file for the top-level partition as Step 1: Add the Signal Tap Logic Analyzer to the Project describes.
- Compile the design and Signal Tap instances.
- Generate a Signal Tap file for the reused Core Partition with the File > Create/Update > Create Signal Tap File from Design Instance command.
- Program the Intel FPGA device with the design and Signal Tap instances.
- Perform hardware verification of top-level partition with the Signal Tap instance defined in Step 3.
- Perform hardware verification of the Reused Core Partition with the Signal Tap instance defined in Step 5.
2.9.3.2. Signal Tap Debugging with a Root Partition
You implement the debug bridge with the SLD JTAG Bridge Agent Intel® FPGA IP and SLD JTAG Bridge Host Intel® FPGA IP pair for each reserved core boundary in the design. You instantiate the SLD JTAG Bridge Agent IP in the root partition, and the SLD JTAG Bridge Host IP in the core partition.
For details about the debug bridge, refer to the SLD JTAG Bridge in the System Debugging Tools Overview chapter.
2.9.3.2.1. Export the Root Partition with SLD JTAG Bridge
- Create a reserved core partition and define a Logic Lock region.
-
Generate and instantiate SLD JTAG Bridge Agent in the root
partition.
The combination of agent and host allows debugging the reserved core partition in Consumer projects.
- Generate and instantiate the SLD JTAG Bridge Host in the reserved core partition.
- Add a Signal Tap instance to the root partition, as Step 1: Add the Signal Tap Logic Analyzer to the Project describes.
- In the Signal Tap instance, specify the signals for monitoring. This action allows debugging the root partition in the Developer and Consumer projects.
- Compile the design and Signal Tap instance.
- Click Project > Export Design Partition. By default, the .qdb file you export includes any Signal Tap HDL instances for the partition.
-
Manually copy files to the project that reuses the root
partition:
- In designs targeting the Intel® Arria® 10 device family, copy .qdb and .sdc files.
- In designs targeting the Intel® Stratix® 10 device family copy the .qdb file.
In designs with multiple child partitions, you must provide the hierarchy path and the associated index of the JTAG Bridge Instance Agents in the design to the Consumer.
2.9.3.2.2. Debugging an Exported Root Partition and Core Partition Simultaneously using the SLD JTAG Bridge
To perform Signal Tap debugging in a project that includes a reused root partition:
- Add the exported .qdb (and .sdc) files to the project that reuses them.
- From the IP Catalog, parameterize and instantiate the SLD JTAG Bridge Host Intel® FPGA IP in the core partition.
- Run the Analysis & Synthesis stage of the Compiler.
- Create a Signal Tap instance in the core partition, as Step 1: Add the Signal Tap Logic Analyzer to the Project describes.
-
In the Signal Tap instance, specify
post-synthesis signals for monitoring.
Note: You can only tap signals in the core partition.
- Compile the design and Signal Tap instance.
- Generate a Signal Tap file for the reused root partition with the quartus_stp command.
- Program the device.
- Perform hardware verification of the reserved core partition with the Signal Tap instance defined in Step 3.
- Perform hardware verification of the reused root partition with the Signal Tap instance defined in Step 7.
2.9.3.3. Compiler Snapshots and Signal Tap Debugging
Adding new signals to a Signal Tap instance in a reused partition requires the Fitter to connect and route these signals. This is only possible when:
- The reused partition contains the Synthesis snapshot—reused partitions that contain the Placed or Final snapshot do not allow adding more signals to the Signal Tap instance for monitoring, because you cannot create additional boundary ports.
- The signal that you want to tap is a post-fit signal—adding pre-synthesis Signal Tap signals is not possible, because that requires resynthesis of the partition.
2.9.3.3.1. Add Post-Fit Nodes when Reusing a Partition Containing a Synthesis Snapshot
To add post-fit nodes to Signal Tap for monitoring:
- Open the project that reuses the partition, and then compile the reused partition through the Fitter stage.
- Add a Signal Tap instance to the project that reuses the partition, as Step 1: Add the Signal Tap Logic Analyzer to the Project describes.
- In the Signal Tap GUI, add the post-fit Signal Tap nodes to the Signal Configuration tab.
-
Recompile the design from the Place stage by clicking Processing > Start > Start Fitter (Place).
The Fitter attaches the Signal Tap nodes to the existing synthesized nodes.
2.9.4. Debugging Devices that use Configuration Bitstream Security
Use an unencrypted bitstream during the prototype and debugging phases of the design, to allow programming file generation and reconfiguration of the device over the JTAG connection while debugging.
If you must use the Signal Tap logic analyzer with an encrypted bitstream, first configure the device with an encrypted configuration file using Passive Serial (PS), Fast Passive Parallel (FPP), or Active Serial (AS) configuration modes. The design must contain at least one instance of the Signal Tap logic analyzer. After configuring the FPGA with a Signal Tap instance and the design, you can open the Signal Tap logic analyzer GUI and scan the chain to acquire data with the JTAG connection.
2.9.5. Signal Tap Data Capture with the MATLAB MEX Function
To set up the Intel® Quartus® Prime software and the MATLAB* environment to perform Signal Tap acquisitions:
- In the Intel® Quartus® Prime software, create an .stp file.
-
In the node list in the Data tab of the Signal Tap
logic analyzer Editor, organize the signals and groups of signals into the order
in which you want them to appear in the MATLAB* matrix.
Each column of the imported matrix represents a single Signal Tap acquisition sample, while each row represents a signal or group of signals in the order you defined in the Data tab.
Note: Signal groups that the Signal Tap logic analyzer acquires and transfers into the MATLAB* MEX function have a width limit of 32 signals. To use the MATLAB* MEX function with a bus or signal group that contains more than 32 signals, split the group into smaller groups that do not exceed the limit. - Save the .stp file and compile your design. Program your device and run the Signal Tap logic analyzer to ensure your trigger conditions and signal acquisition work correctly.
-
In the MATLAB* environment, add the
Intel®
Quartus® Prime binary directory to your path with the following command:
addpath <Quartus install directory>\win
You can view the help file for the MEX function by entering the following command in MATLAB* without any operators:
alt_signaltap_run
-
Use the MATLAB* MEX function to open the JTAG connection to the device and run
the Signal Tap logic analyzer to acquire
data. When you finish acquiring data, close the JTAG connection.
To open the JTAG connection and begin acquiring captured data directly into a MATLAB* matrix called stp, use the following command:
stp = alt_signaltap_run \ ('<stp filename>'[,('signed'|'unsigned')[,'<instance names>'[, \ '<signalset name>'[,'<trigger name>']]]]);
When capturing data, you must assign a filename, for example, <stp filename> as a requirement of the MATLAB* MEX function. The following table describes other MATLAB* MEX function options:
Table 18. Signal Tap MATLAB* MEX Function Options Option Usage Description signed unsigned
'signed' 'unsigned'
The signed option turns signal group data into 32-bit two’s-complement signed integers. The MSB of the group as defined in the Signal Tap Data tab is the sign bit. The unsigned option keeps the data as an unsigned integer. The default is signed. <instance name> 'auto_signaltap_0' Specify a Signal Tap instance if more than one instance is defined. The default is the first instance in the .stp, auto_signaltap_0. <signal set name> <trigger name>
'my_signalset' 'my_trigger'
Specify the signal set and trigger from the Signal Tap data log if multiple configurations are present in the .stp. The default is the active signal set and trigger in the file. During data acquisition, you can enable or disable verbose mode to see the status of the logic analyzer. To enable or disable verbose mode, use the following commands:
alt_signaltap_run('VERBOSE_ON');-alt_signaltap_run('VERBOSE_OFF');
When you finish acquiring data, close the JTAG connection with the following command:
alt_signaltap_run('END_CONNECTION');
For more information about the use of MATLAB* MEX functions in MATLAB*, refer to the MATLAB* Help.
2.10. Signal Tap Logic Analyzer Design Examples
Application Note 845: Signal Tap Tutorial for Intel Arria 10 Partial Reconfiguration Design includes a design example that demonstrates Signal Tap debugging with a partial reconfiguration design. The design example has one 32-bit counter. At the board level, the design connects the clock to a 50MHz source, and connects the output to four LEDs on the FPGA. Selecting the output from the counter bits in a specific sequence causes the LEDs to blink at a specific frequency example demonstrates initiating a DMA transfer. The tutorial demonstrates how to tap signals in a PR design by extending the debug fabric to the PR regions when creating the base revision, and then defining debug components in the implementation revisions.
Application Note 446: Debugging Nios® II Systems with the Signal Tap Logic Analyzer includes a design example with a Nios® II processor, a direct memory access (DMA) controller, on-chip memory, and an interface to external SDRAM memory. After you press a button, the processor initiates a DMA transfer, which you analyze using the Signal Tap logic analyzer. In this example, the Nios® II processor executes a simple C program from on-chip memory and waits for you to press a button.
2.11. Custom Triggering Flow Examples
2.11.1. Trigger Example 1: Custom Trigger Position
Actions to the acquisition buffer can accept an optional post-count argument. This post-count argument enables you to define a custom triggering position for each segment in the acquisition buffer.
The following example shows how to apply a trigger position to all segments in the acquisition buffer. The example describes a triggering flow for an acquisition buffer split into four segments. If each acquisition segment is 64 samples in depth, the trigger position for each buffer is at sample #34. The acquisition stops after all segments are filled once.
if (c1 == 3 && condition1) trigger 30; else if ( condition1 ) begin segment_trigger 30; increment c1; end
Each segment acts as a non-segmented buffer that continuously updates the memory contents with the signal values.
The Data tab displays the last acquisition before stopping the buffer as the last sample number in the affected segment. The trigger position in the affected segment is then defined by N – post count fill, where N is the number of samples per segment.
2.11.2. Trigger Example 2: Trigger When triggercond1 Occurs Ten Times between triggercond2 and triggercond3
You can use a custom trigger flow to count a sequence of events before triggering the acquisition buffer, as the following example shows. This example uses three basic triggering conditions configured in the Signal Tap Setup tab.
This example triggers the acquisition buffer when condition1 occurs after condition3 and occurs ten times prior to condition3. If condition3 occurs prior to ten repetitions of condition1, the state machine transitions to a permanent wait state.
state ST1: if ( condition2 ) begin reset c1; goto ST2; end State ST2 : if ( condition1 ) increment c1; else if (condition3 && c1 < 10) goto ST3; else if ( condition3 && c1 >= 10) trigger; ST3: goto ST3;
2.12. Signal Tap File Templates
Right-click any template in the New File from Template dialog box, and then click Set as the default selection to always open new .stp files in that template by default.
Template | Summary Description |
---|---|
Default | The most basic and compact setup that is suitable for many debugging needs |
Default with Hidden Hierarchy and Data Log | The same setup as the Default template, with additional Hierarchy Display and Data Log windows for trigger condition setup. |
State-Based Trigger Flow Control | Starts with three conditions setup to replicate the basic sequential trigger flow control. |
Conditional Storage Qualifier | Enables the Conditional storage qualifier and Basic OR condition. This setup provides a versatile storage qualifier condition expression. |
Transitional Storage Qualifier | Enables the Transitional storage qualifier. The Transitional storage qualifier simply detects changes in data. |
Start-Stop Storage Qualifier | Enables the Start/Stop storage qualifier and the Basic OR condition. Provides two conditions to frame the data. |
State-Based Storage Qualifier | Provides more sophisticated qualification conditions for use with state machine expressions. You must use the State-Based Storage Qualifier template in conjunction with the state-based trigger flow control |
Input Port Storage Qualifier | Enables the Input port storage qualifier to provide total control of the storage qualifier condition by supporting development of custom logic outside of the Signal Tap logic hierarchy. |
Trivial Advanced Trigger Condition | Enables the Advanced trigger condition. The Advanced condition provides the most flexibility to express complex conditions. The Advanced trigger condition scales from a simple wire to the most complex logical expression. This template starts with the simplest condition. |
Trigger Position Defined Using Sample Count | Supports specifying an exact number of samples to store after the trigger position, using the State-Based Trigger Flow Control template as a reference. |
Cross-triggering Between STP Instances | Enables "Cross-triggering by using the Trigger out from one instance as the Trigger in of another instance, when using multiple Signal Tap instances. |
Setup for Incremental Compilation | Specifies a fixed input width for signal inputs. This technique allows efficient incremental compilation by reducing the amount of Signal Tap logic change, and by adding only post-fit nodes to tap. |
Define Trigger Condition in RTL | Supports defining a custom trigger condition in the RTL language of your choice. |
Template | Summary Description |
---|---|
Capture Avalon Memory Mapped Transactions | Allows you to use the storage qualifier feature to store only meaningful Avalon® memory-mapped interface transactions. |
Simple Avalon Streaming Interface Bus Performance Analysis | Supports recording of event time for analysis of the data packet flow in an Avalon® streaming interface. |
Use Counters in the State-based Flow Control to Collect Stats | Use counters to track of the number of packets produced (pkt_counter), number of data beats produced (pkt_beat_counter), and number of data beats consumed (stream_beat_counter). |
Template | Setup Description |
---|---|
Trigger on an Event Absent for Greater Than or Equal to 5 Clock Cycles | Requires setup of one basic trigger condition in the Setup tab to the value that you want. |
Trigger on Event Absent for Less Than 5 Clock Cycles | Requires setup of one basic trigger condition in the Setup tab to the value that you want. |
Trigger on 5th Occurrence of a Group Value | Requires setup of one basic trigger condition in the Setup tab to the value that you want. |
Trigger on the 5th Transition of a Group Value | Requires setup of an edge-sensitive trigger condition to detect all bus transitions to the desired group value. Requires edge detection for any data bus bit logically ANDed with a comparison to the desired group value. An advanced trigger condition is necessary in this case. |
Trigger After Condition1 is Followed by Condition2 | Requires setup of three basic trigger conditions in the Setup tab to the values you specify. The first two trigger conditions are set to the desired group values. The third trigger condition is set to capture some type of idle transaction across the bus between the first and second conditions. |
Trigger on Condition1 Immediately Followed by Condition2 | Requires setup of two basic trigger conditions in the Setup tab to the group values that you want. |
Trigger on Condition2 Not Occurring Between Condition1 and Condition3 | Requires setup of three basic trigger conditions in the Setup tab to the group values that you want. |
Trigger on the 5th Consecutive Occurrence of Condition1 | Requires setup of one basic trigger condition in the Setup tab to the value you want. |
Trigger After a Violation of Sequence From Condition1 To Condition4 | Requires setup of four basic trigger conditions to the sequence values that you want. |
Trigger on a Sequence of Edges | Requires setup of three edge-sensitive basic trigger conditions for the sequence that you want. |
Trigger on Condition1 Followed by Condition2 After 5 Clock Cycles | Requires setup of two basic trigger conditions to the group values that you want. |
Trigger on Condition1 Followed by Condition2 Within 5 Samples | Requires setup of two basic trigger conditions to the group values that you want. |
Trigger on Condition1 Not Followed by Condition2 Within 5 Samples | Requires setup of two basic trigger conditions to the group values that you want. |
Trigger After 5 Consecutive Transitions | Requires setup of a trigger condition to capture any transition activity on the monitored bus. This example requires an Advanced trigger condition because the example requires an OR condition. |
Trigger When Condition1 Occurs Less Than 5 Times Between Condition2 and Condition3 | Requires setup of three edge-sensitive trigger conditions, with each trigger condition containing a comparison to the desired group value. |
2.13. Running the Stand-Alone Version of Signal Tap
You can optionally install a stand-alone version of the Signal Tap logic analyzer, rather than using the Signal Tap logic analyzer integrated with the Intel® Quartus® Prime software.
The stand-alone version of Signal Tap is particularly useful in a lab environment that lacks a suitable workstation for a complete Intel® Quartus® Prime installation, or lacks a full Intel® Quartus® Prime software license.
The standalone version of the Signal Tap logic analyzer includes and requires use of the Intel® Quartus® Prime stand-alone Programmer, which is also available from the Download Center for FPGAs.
2.14. Signal Tap Scripting Support
2.14.1. Signal Tap Command-Line Options
You can use the following options with the quartus_stp executable:
Option | Usage | Description |
---|---|---|
--stp_file <stp_filename> | Required | Specifies the name of the .stp file. |
--enable | Optional |
Sets the ENABLE_SIGNALTAP option to ON in the project's .qsf file, so the Signal Tap logic analyzer runs in the next compilation. If you omit this option, the Intel® Quartus® Prime software uses the current value of ENABLE_SIGNALTAP in the .qsf file. Writes subsequent Signal Tap assignments to the .stp that appears in the .qsf file. If the .qsf file does not specify a .stp file, you must use the --stp_file option. |
--disable | Optional |
Sets the ENABLE_SIGNALTAP option to OFF in the project's .qsf file, so the Signal Tap logic analyzer does not in the next compilation. If you omit the --disable option, the Intel® Quartus® Prime software uses the current value of ENABLE_SIGNALTAP in the .qsf file. |
2.14.2. Data Capture from the Command Line
To execute a Tcl script containing Signal Tap logic analyzer Tcl commands, use:
quartus_stp -t <Tcl file>
Continuously Capturing Data
This excerpt shows commands you can use to continuously capture data. Once the capture meets trigger condition e, the Signal Tap logic analyzer starts the capture and stores the data in the data log.
# Open Signal Tap session open_session -name stp1.stp ### Start acquisition of instances auto_signaltap_0 and ### auto_signaltap_1 at the same time # Calling run_multiple_end starts all instances run_multiple_start run -instance auto_signaltap_0 -signal_set signal_set_1 -trigger \ trigger_1 -data_log log_1 -timeout 5 run -instance auto_signaltap_1 -signal_set signal_set_1 -trigger \ trigger_1 -data_log log_1 -timeout 5 run_multiple_end # Close Signal Tap session close_session
2.15. Signal Tap File Version Compatibility
If you open an Intel® Quartus® Prime project that includes a .stp file from a previous version of the software in a later version of the Intel® Quartus® Prime software, the software may require you to update the .stp configuration file before you can compile the project. Update the configuration file by simply opening the .stp in the Signal Tap logic analyzer GUI. If configuration update is required, Signal Tap confirms that you want to update the .stp to match the current version of the Intel® Quartus® Prime software.
2.16. Design Debugging with the Signal Tap Logic Analyzer Revision History
The following revision history applies to this chapter:
Document Version | Intel® Quartus® Prime Version | Changes |
---|---|---|
2020.09.28 | 20.3 |
|
2019.06.11 | 18.1.0 | Added more explanation to Figure 52 about continuous and input mode. |
2019.05.01 | 18.1.0 | In Adding Signals with a Plug-In topic, removed outdated information from step 1 about turning on Create debugging nodes for IP cores. |
2018.09.24 | 18.1.0 |
|
2018.08.07 | 18.0.0 | Reverted document title to Debug Tools User Guide: Intel Quartus Prime Pro Edition. |
2018.07.30 | 18.0.0 | Updated Partial Reconfiguration sections to reflect changes in the PR flow. |
2018.05.07 | 18.0.0 |
|
2017.11.06 | 17.1.0 |
|
2017.05.08 | 17.0.0 |
|
2016.10.31 | 16.1.0 |
|
2016.05.03 | 16.0.0 |
|
2015.11.02 | 15.1.0 |
|
2015.05.04 | 15.0.0 | Added content for Floating Point Display Format in table: SignalTap II Logic Analyzer Features and Benefits. |
2014.12.15 | 14.1.0 | Updated location of Fitter Settings, Analysis & Synthesis Settings, and Physical Synthesis Optimizations to Compiler Settings. |
December 2014 | 14.1.0 |
|
June 2014 | 14.0.0 |
|
November 2013 | 13.1.0 | Removed HardCopy material. Added section on using cross-triggering with DS-5 tool and added link to white paper 01198. Added section on remote debugging an Altera SoC and added link to application note 693. Updated support for MEX function. |
May 2013 | 13.0.0 |
|
June 2012 | 12.0.0 | Updated Figure 13–5 on page 13–16 and “Adding Signals to the SignalTap II File” on page 13–10. |
November 2011 | 11.0.1 | Template
update. Minor editorial updates. |
May 2011 | 11.0.0 | Updated the requirement for the standalone SignalTap II software. |
December 2010 | 10.0.1 | Changed to new document template. |
July 2010 | 10.0.0 |
|
November 2009 | 9.1.0 | No change to content. |
March 2009 | 9.0.0 |
|
November 2008 | 8.1.0 | Updated
for the Quartus II software version 8.1 release:
|
May 2008 | 8.0.0 | Updated
for the Quartus II software version 8.0:
|
3. Quick Design Verification with Signal Probe
The Signal Probe feature in the Intel® Quartus® Prime Pro Edition software allows you to route an internal node to a top-level I/O. When you start with a fully routed design, you can select and route debugging signals to I/O pins that you previously reserve or are currently unused.
During Rapid Recompile, the Compiler reuses previous synthesis and fitting results whenever possible, and does not reprocess unchanged design blocks. When you make small design changes, using Rapid Recompile reduces timing variations and the total recompilation time.
The Intel® Quartus® Prime Pro Edition Signal Probe feature supports the Intel® Arria® 10 and Intel® Stratix® 10 device families.
3.1. Debug Flow with Signal Probe and Rapid Recompile
To add verification capabilities to a design using Signal Probe routing feature:
3.1.1. Reserve Signal Probe Pins
You create and reserve a pin for Signal Probe with a Tcl command:
set_global_assignment –name CREATE_SIGNALPROBE_PIN <pin_name>
- pin_name
- Specifies the name of the Signal Probe pin.
Optionally, you can assign locations for the Signal Probe pins. If you do not assign a location, the Fitter places the pins automatically.
Tcl Command to Reserve Signal Probe Pins
set_global_assignment -name CREATE_SIGNALPROBE_PIN wizard set_global_assignment -name CREATE_SIGNALPROBE_PIN probey
3.1.2. Compile the Design
Perform a full compilation of the design. You can use Intel® Quartus® Prime software, a command line executable, or a Tcl command.
Tcl Command to Compile the Design
execute_flow -compile
At this point in the design flow you determine the nodes you want to debug.
3.1.3. Assign Nodes to Signal Probe Pins
You can assign any node in the post-compilation netlist to a Signal Probe pin. In Intel® Quartus® Prime software, click View > Node Finder, and filter by Signal Tap: post-fitting to view the nodes you can route.
You specify the node that connects to a Signal Probe pin with a Tcl command:
set_instance_assignment –name CONNECT_SIGNALPROBE_PIN <pin_name> –to <node_name>
- pin_name
- Specifies the name of the Signal Probe pin that connects to the node.
- node_name
- Specifies the full hierarchy path of the node you want to route.
Tcl Commands to Connect Pins to Internal Nodes
# Make assignments to connect nodes of interest to pins set_instance_assignment -name CONNECT_SIGNALPROBE_PIN wizard -to sprobe_me1 set_instance_assignment -name CONNECT_SIGNALPROBE_PIN probey -to sprobe_me2
3.1.4. Recompile the Design
After assigning nodes to the Signal Probe pins, run Rapid Recompile. Rapid Recompile preserves timing and reduces compilation time by reusing previous results whenever possible.
You can run Rapid Recompile from the Intel® Quartus® Prime software, a command line executable, or a Tcl script.
Tcl Command to Recompile the Design
# Run the fitter with --recompile to preserve timing # and quickly connect the Signal Probe pins execute_module -tool fit -args {--recompile}
After recompilation, you are ready to program the device and debug the design.
3.1.5. Check Connection Table in Fitter Report
When you compile a design with Signal Probe pins, Intel® Quartus® Prime software generates a connection report table. To see this report, click Processing > Compilation Report, open the Fitter > In-System Debugging folder, and click Connections to Signal Probe pins.
The Status column informs whether or not the routing attempt from the nodes to the Signal Probe pins succeeded.
Status | Description |
---|---|
Connected | Routing succeeded. |
Unconnected | Routing did not succeed. Possible reasons are:
|
Connections to Signal Probe Pins in the Compilation Report
Connections to Signal Probe Pins in top.fit.rpt
+--------------------------------------------------------------------------------+ ; Connections to Signal Probe pins ; +--------------------------------------------------------------------------------+ Signal Probe Pin Name : probey Status : Connected Attempted Connection : sprobe_me2 Actual Connection : sprobe_me2 Details : Signal Probe Pin Name : wizard Status : Connected Attempted Connection : sprobe_me1 Actual Connection : sprobe_me1 Details : +--------------------------------------------------------------------------------+
3.2. Quick Design Verification with Signal Probe Revision History
Document Version | Intel® Quartus® Prime Version | Changes |
---|---|---|
2018.05.07 | 18.0.0 | Initial release for Intel® Quartus® Prime Pro Edition software. |
4. In-System Debugging Using External Logic Analyzers
4.1. About the Intel Quartus Prime Logic Analyzer Interface
The LAI connects a large set of internal device signals to a small number of output pins. You can connect these output pins to an external logic analyzer for debugging purposes. In the Intel® Quartus® Prime LAI, the internal signals are grouped together, distributed to a user-configurable multiplexer, and then output to available I/O pins on your Intel-supported device. Instead of having a one-to-one relationship between internal signals and output pins, the Intel® Quartus® Prime LAI enables you to map many internal signals to a smaller number of output pins. The exact number of internal signals that you can map to an output pin varies based on the multiplexer settings in the Intel® Quartus® Prime LAI.
The LAI does not support Hard Processor System (HPS) I/Os.
4.2. Choosing a Logic Analyzer
- The Signal Tap Logic Analyzer
- An external logic analyzer, which connects to internal signals in your Intel-supported device by using the Intel® Quartus® Prime LAI
Feature | Description | Recommended Logic Analyzer |
---|---|---|
Sample Depth | You have access to a wider sample depth with an external logic analyzer. In the Signal Tap Logic Analyzer, the maximum sample depth is set to 128 Kb, which is a device constraint. However, with an external logic analyzer, there are no device constraints, providing you a wider sample depth. | LAI |
Debugging Timing Issues | Using an external logic analyzer provides you with access to a “timing” mode, which enables you to debug combined streams of data. | LAI |
Performance | You frequently have limited routing resources available to place and route when you use the Signal Tap Logic Analyzer with your design. An external logic analyzer adds minimal logic, which removes resource limits on place-and-route. | LAI |
Triggering Capability | The Signal Tap Logic Analyzer offers triggering capabilities that are comparable to external logic analyzers. | LAI or Signal Tap |
Use of Output Pins | Using the Signal Tap Logic Analyzer, no additional output pins are required. Using an external logic analyzer requires the use of additional output pins. | Signal Tap |
Acquisition Speed | With the Signal Tap Logic Analyzer, you can acquire data at speeds of over 200 MHz. You can achieve the same acquisition speeds with an external logic analyzer; however, you must consider signal integrity issues. | Signal Tap |
4.2.1. Required Components
- Intel® Quartus® Prime software version 15.1 or later
- The device under test
- An external logic analyzer
- An Intel FPGA communications cable
- A cable to connect the Intel-supported device to the external logic analyzer
Notes to figure:
- Configuration and control of the LAI using a computer loaded with the Intel® Quartus® Prime software via the JTAG port.
- Configuration and control of the LAI using a third-party vendor logic analyzer via the JTAG port. Support varies by vendor.
4.3. Flow for Using the LAI
Notes to figure:
- Configuration and control of the LAI using a computer loaded with the Intel® Quartus® Prime software via the JTAG port.
- Configuration and control of the LAI using a third-party vendor logic analyzer via the JTAG port. Support varies by vendor.
4.3.1. Defining Parameters for the Logic Analyzer Interface
-
Click Tools > Logic Analyzer Interface Editor.
Figure 76. Logic Analyzer Interface Editor
- In the Setup View list, select Core Parameters.
- Specify the parameters of the LAI instance.
4.3.2. Mapping the LAI File Pins to Available I/O Pins
To assign pin locations for the LAI:
-
Select Pins in the Setup View list
Figure 77. Mapping LAI file Pins
- Double-click the Location column next to the reserved pins in the Name column, and select a pin from the list.
- Right-click the selected pin and locate in the Pin Planner.
4.3.3. Mapping Internal Signals to the LAI Banks
- Click the Setup View arrow and select Bank n or All Banks.
- To view all the bank connections, click Setup View and then select All Banks.
- Before making bank assignments, right click the Node list and select Add Nodes to open the Node Finder.
- Find the signals that you want to acquire.
-
Drag the signals from the Node
Finder dialog box into the bank Setup
View.
When adding signals, use Signal Tap: pre-synthesis for non-incrementally routed instances and Signal Tap: post-fitting for incrementally routed instancesAs you continue to make assignments in the bank Setup View, the schematic of the LAI in the Logical View pane begins to reflect the changes.
- Continue making assignments for each bank in the Setup View until you add all the internal signals that you want to acquire.
4.3.4. Compiling Your Intel Quartus Prime Project
To verify the Logic Analyzer Interface is properly compiled with your project, open the Compilation Report tab and select Resource Utilization by Entity, nested under Partition "auto_fab_0". The LAI IP instance appears in the Compilation Hierarchy Node column, nested under the internal module of auto_fab_0
4.3.5. Programming Your Intel-Supported Device Using the LAI
You can use the LAI with multiple devices in your JTAG chain. Your JTAG chain can also consist of devices that do not support the LAI or non-Intel, JTAG-compliant devices. To use the LAI in more than one Intel-supported device, create an .lai file and configure an .lai file for each Intel-supported device that you want to analyze.
4.4. Controlling the Active Bank During Runtime
When you have programmed your Intel-supported device, you can control which bank you map to the reserved .lai file output pins. To control which bank you map, in the schematic in the Logical View, right-click the bank and click Connect Bank.
4.4.1. Acquiring Data on Your Logic Analyzer
4.5. LAI Core Parameters
The table lists the LAI file core parameters:
Parameter | Range Value | Description |
---|---|---|
Pin Count | 1 - 255 | Number of pins dedicated to the LAI. You must connect the
pins to a debug header on the board. Within the device, The Compiler maps each pin to a user-configurable number of internal signals. |
Bank Count | 1 - 255 | Number of internal signals that you want to map to each
pin. For example, a Bank Count of 8 implies that you connect eight internal signals to each pin. |
Output/Capture Mode | Specifies the acquisition mode. The
two options are:
|
|
Clock | Specifies the sample clock. You can use any signal in the
design as a sample clock. However, for best results, use a clock
with an operating frequency fast enough to sample the data that you
want to acquire. Note: The Clock parameter is available only when
Output/Capture Mode
is set to Registered
State.
|
|
Power-Up State | Specifies the power-up state of the pins designated for use with the LAI. You can select tri-stated for all pins, or selecting a particular bank that you enable. |
4.6. In-System Debugging Using External Logic Analyzers Revision History
The following revision history applies to this chapter:
Document Version | Intel® Quartus® Prime Version | Changes |
---|---|---|
2018.05.07 | 18.0.0 |
|
2017.05.08 | 17.0.0 |
|
2016.10.31 | 16.1.0 |
|
2015.11.02 | 15.1.0 | Changed instances of Quartus II to Intel® Quartus® Prime . |
June 2014 | 14.0.0 |
|
June 2012 | 12.0.0 | Removed survey link |
November 2011 | 10.1.1 | Changed to new document template |
December 2010 | 10.1.0 |
|
August 2010 | 10.0.1 | Corrected links |
July 2010 | 10.0.0 |
|
November 2009 | 9.1.0 |
|
March 2009 | 9.0.0 |
|
November 2008 | 8.1.0 | Changed to 8-1/2 x 11 page size. No change to content |
May 2008 | 8.0.0 |
|
5. In-System Modification of Memory and Constants
The ability to read data from memories and constants can help you identify the source of problems, and the write capability allows you to bypass functional issues by writing expected data.
When you use the In-System Memory Content Editor in conjunction with the Signal Tap logic analyzer, you can view and debug your design in the hardware lab.
5.1. IP Cores Supporting ISMCE
In Intel® Arria® 10 and Intel® Stratix® 10 device families, you can use the ISMCE in RAM: 1 PORT and the ROM: 1 PORT IP Cores.
5.2. Debug Flow with the In-System Memory Content Editor
- Identify the memories and constants that you want to access at runtime.
- Specify in the design the memory or constant that must be run-time modifiable.
- Perform a full compilation.
- Program the device.
-
Launch the
In-System Memory Content Editor.
The In-System Memory Content Editor retrieves all instances of run-time configurable memories and constants by scanning the JTAG chain and sending a query to the device selected in the JTAG Chain Configuration pane.
-
Modify the
values of the memories or constants, and check the results.
For example, if a parity bit in a memory is incorrect, you can use the In-System Memory Content Editor to write the correct parity bit values into the RAM, allowing the system to continue functioning. To check the error handling functionality of a design, you can intentionally write incorrect parity bit values into the RAM.
5.3. Enabling Runtime Modification of Instances in the Design
To make an instance of a memory or constant runtime-modifiable:
- Open the instance with the Parameter Editor.
-
In the Parameter Editor, turn on Allow In-System Memory Content Editor to capture and update content
independently of the system clock.
- Recompile the design.
- Converting single-port RAMs to dual-port RAMs
- Adding logic to avoid memory write collision and maintain read write coherency in device families that do not support true dual-port RAMs, such as Intel® Stratix® 10.
5.4. Programming the Device with the In-System Memory Content Editor
5.5. Loading Memory Instances to the ISMCE
- On the Intel® Quartus® Prime software, click Tools > In-System Memory Content Editor.
-
In the JTAG Chain Configuration pane, click
Scan Chain.
The In-System Memory Content Editor sends a query to the device in the JTAG Chain Configuration pane and retrieves all instances of run-time configurable memories and constants.The Instance Manager pane lists all the instances of constants and memories that are runtime-modifiable. The Hex Editor pane displays the contents of each memory or constant instance. The memory contents in the Hex Editor pane appear as red question marks until you read the device.Figure 80. Hex Editor After Scanning JTAG Chain
-
Click an instance from the Instance
manager, and then click
to load the contents of that instance.
The Hex Editor now displays the contents of the instance.

5.6. Monitoring Locations in Memory
-
Click
to synchronize the Hex Editor to the current instance's content.
The Hex Editor displays in red content that changed with respect to the last device synchronization.Figure 81. Hex Editor after Manually Editing Content -
If you want a live output of the memory contents instead of manually
synchronizing, click
.
Continuous read is analogous to using Signal Tap in continuous acquisition, with the memory values appearing as words in the Hex Editor instead of toggling waveforms.
5.7. Editing Memory Contents with the Hex Editor Pane
Black content on the Hex Editor pane means that the value read is the same as last synchronization.
-
Type content on the pane.
The Hex Editor displays in blue changed content that has not been synchronized to the device.Figure 82. Hex Editor after Manually Editing Content
-
Click
to synchronize the content to the device.
5.8. Importing and Exporting Memory Files
You can import or export files in hex or mif formats.
-
To import a file, click Edit > Import Data from File..., and then select the file to import.
If the file is not compatible, unexpected data appears in the Hex Editor.
- To export memory contents to a file, click Edit > Export Data to File..., and then specify the name.
5.9. Access Two or More Devices
If you have more than one device with in-system configurable memories or constants in a JTAG chain, you can launch multiple In-System Memory Content Editors within the Intel® Quartus® Prime software to access the memories and constants in each of the devices. Each window of the In-System Memory Content Editor can access the memories and constants of a single device.
5.10. Scripting Support
You can enable memory and constant instances to be runtime modifiable from the HDL code. Additionally, the In-System Memory Content Editor supports reading and writing of memory contents via Tcl commands from the insystem_memory_edit package.
5.10.1. The insystem_memory_edit Tcl Package
The ::quartus::insystem_memory_edit Tcl package contains the set of Tcl functions for reading and editing the contents of memory in an Intel® FPGA device using the In-System Memory Content Editor. The quartus_stp and quartus_stp_tcl command line executables load this package by default.
For the most up-to-date information about the ::quartus::insystem_memory_edit, refer to the Intel® Quartus® Prime Help.
5.10.1.1. Getting Information about the insystem_memory_edit Package
-
For general information about the package, type:
quartus_stp --tcl_eval help -pkg insystem_memory_edit
-
For information about a command in the package, type:
quartus_stp --tcl_eval help -cmd <command_name>
5.11. In-System Modification of Memory and Constants Revision History
The following revision history applies to this chapter:
Document Version | Intel® Quartus® Prime Version | Changes |
---|---|---|
2018.05.07 | 18.0.0 |
|
2016.10.31 | 16.1.0 |
|
2015.11.02 | 15.1.0 | Changed instances of Quartus II to Intel® Quartus® Prime . |
June 2014 | 14.0.0 |
|
June 2012 | 12.0.0 | Removed survey link. |
November 2011 | 10.0.3 | Template update. |
December 2010 | 10.0.2 | Changed to new document template. No change to content. |
August 2010 | 10.0.1 | Corrected links |
July 2010 | 10.0.0 |
|
November 2009 | 9.1.0 |
|
March 2009 | 9.0.0 | No change to content |
November 2008 | 8.1.0 | Changed to 8-1/2 x 11 page size. No change to content. |
May 2008 | 8.0.0 |
|
6. Design Debugging Using In-System Sources and Probes
Traditional debugging techniques often involve using an external pattern generator to exercise the logic and a logic analyzer to study the output waveforms during run time.
You can make the debugging cycle more efficient when you can drive any internal signal manually within your design, which allows you to perform the following actions:
- Force the occurrence of trigger conditions set up in the Signal Tap Logic Analyzer
- Create simple test vectors to exercise your design without using external test equipment
- Dynamically control run time control signals with the JTAG chain
The In-System Sources and Probes Editor in the Intel® Quartus® Prime software extends the portfolio of verification tools, and allows you to easily control any internal signal and provides you with a completely dynamic debugging environment. Coupled with either the Signal Tap Logic Analyzer or Signal Probe, the In-System Sources and Probes Editor gives you a powerful debugging environment in which to generate stimuli and solicit responses from your logic design.
The Virtual JTAG IP core and the In-System Memory Content Editor also give you the capability to drive virtual inputs into your design. The Intel® Quartus® Prime software offers a variety of on-chip debugging tools.
The ALTSOURCE_PROBE IP core hides the detailed transactions between the JTAG controller and the registers instrumented in your design to give you a basic building block for stimulating and probing your design. Additionally, the In-System Sources and Probes Editor provides single-cycle samples and single-cycle writes to selected logic nodes. You can use this feature to input simple virtual stimuli and to capture the current value on instrumented nodes. Because the In-System Sources and Probes Editor gives you access to logic nodes in your design, you can toggle the inputs of low-level components during the debugging process. If used in conjunction with the Signal Tap Logic Analyzer, you can force trigger conditions to help isolate your problem and shorten your debugging process.
The In-System Sources and Probes Editor allows you to easily implement control signals in your design as virtual stimuli. This feature can be especially helpful for prototyping your design, such as in the following operations:
- Creating virtual push buttons
- Creating a virtual front panel to interface with your design
- Emulating external sensor data
- Monitoring and changing run time constants on the fly
The In-System Sources and Probes Editor supports Tcl commands that interface with all your ALTSOURCE_PROBE IP core instances to increase the level of automation.
6.1. Hardware and Software Requirements
- Intel® Quartus® Prime software
or
- Intel® Quartus® Prime Lite Edition
- Download Cable (USB-BlasterTM download cable or ByteBlasterTM cable)
- Intel FPGA development kit or user design board with a JTAG connection to device under test
The In-System Sources and Probes Editor supports the following device families:
- Arria® series
- Stratix® series
- Cyclone® series
- MAX® series
6.2. Design Flow Using the In-System Sources and Probes Editor
6.2.1. Instantiating the In-System Sources and Probes IP Core
- In the IP Catalog (Tools > IP Catalog), type In-System Sources and Probes.
- Double-click In-System Sources and Probes to open the parameter editor.
- Specify a name for the IP variation.
-
Specify the parameters for the IP
variation.
The IP core supports up to 512 bits for each source, and design can include up to 128 instances of this IP core.
- Click Generate or Finish to generate IP core synthesis and simulation files matching your specifications.
- Using the generated template, instantiate the In-System Sources and Probes IP core in your design.
6.2.2. In-System Sources and Probes IP Core Parameters
Port Name | Required? | Direction | Comments |
---|---|---|---|
probe[] | No | Input | The outputs from your design. |
source_clk | No | Input | Source Data is written synchronously to this clock. This input is required if you turn on Source Clock in the Advanced Options box in the parameter editor. |
source_ena | No | Input | Clock enable signal for source_clk. This input is required if specified in the Advanced Options box in the parameter editor. |
source[] | No | Output | Used to drive inputs to user design. |
You can include up to 128 instances of the in-system sources and probes IP core in your design, if your device has available resources. Each instance of the IP core uses a pair of registers per signal for the width of the widest port in the IP core. Additionally, there is some fixed overhead logic to accommodate communication between the IP core instances and the JTAG controller. You can also specify an additional pair of registers per source port for synchronization.
6.3. Compiling the Design
You can modify the number of connections to your design by editing the In-System Sources and Probes IP core. To open the design instance you want to modify in the parameter editor, double-click the instance in the Project Navigator. You can then modify the connections in the HDL source file. You must recompile your design after you make changes.
6.4. Running the In-System Sources and Probes Editor
To run the In-System Sources and Probes Editor:
- On the Tools menu, click In-System Sources and Probes Editor.
6.4.1. In-System Sources and Probes Editor GUI
- JTAG Chain Configuration—Allows you to specify programming hardware, device, and file settings that the In-System Sources and Probes Editor uses to program and acquire data from a device.
- Instance Manager—Displays information about the instances generated when you compile a design, and allows you to control data that the In-System Sources and Probes Editor acquires.
- In-System Sources and Probes Editor—Logs all data read from the selected instance and allows you to modify source data that is written to your device.
When you use the In-System Sources and Probes Editor, you do not need to open an Intel® Quartus® Prime software project. The In-System Sources and Probes Editor retrieves all instances of the ALTSOURCE_PROBE IP core by scanning the JTAG chain and sending a query to the device selected in the JTAG Chain Configuration pane. You can also use a previously saved configuration to run the In-System Sources and Probes Editor.
Each In-System Sources and Probes Editor pane can access the ALTSOURCE_PROBE IP core instances in a single device. If you have more than one device containing IP core instances in a JTAG chain, you can launch multiple In-System Sources and Probes Editor panes to access the IP core instances in each device.
6.4.2. Programming Your Device With JTAG Chain Configuration
To configure a device to use with the In-System Sources and Probes Editor, perform the following steps:
- Open the In-System Sources and Probes Editor.
- In the JTAG Chain Configuration pane, point to Hardware, and then select the hardware communications device. You may be prompted to configure your hardware; in this case, click Setup.
- From the Device list, select the FPGA device to which you want to download the design (the device may be automatically detected). You may need to click Scan Chain to detect your target device.
- In the JTAG Chain Configuration pane, click to browse for the SRAM Object File (.sof) that includes the In-System Sources and Probes instance or instances. (The .sof may be automatically detected).
- Click Program Device to program the target device.
6.4.3. Instance Manager
The Instance Manager pane contains the following buttons and sub-panes:
- Read Probe Data—Samples the probe data in the selected instance and displays the probe data in the In-System Sources and Probes Editor pane.
- Continuously Read Probe Data—Continuously samples the probe data of the selected instance and displays the probe data in the In-System Sources and Probes Editor pane; you can modify the sample rate via the Probe read interval setting.
- Stop Continuously Reading Probe Data—Cancels continuous sampling of the probe of the selected instance.
- Read Source Data—Reads the data of the sources in the selected instances.
- Probe Read Interval—Displays the sample interval of all the In-System Sources and Probe instances in your design; you can modify the sample interval by clicking Manual.
- Event Log—Controls the event log that appears in the In-System Sources and Probes Editor pane.
- Write Source Data—Allows you to manually or continuously write data to the system.
Beside each entry, the Instance Manager pane displays the instance status. The possible instance statuses are Not running Offloading data, Updating data, and Unexpected JTAG communication error.
6.4.4. In-System Sources and Probes Editor Pane
The data is organized according to the index number of the instance. The editor provides an easy way to manage your signals, and allows you to rename signals or group them into buses. All data collected from in-system source and probe nodes is recorded in the event log and you can view the data as a timing diagram.
6.4.4.1. Reading Probe Data
This action produces a single sample of the probe data and updates the data column of the selected index in the In-System Sources and Probes Editor pane. You can save the data to an event log by turning on the Save data to event log option in the Instance Manager pane.
If you want to sample data from your probe instance continuously, in the Instance Manager pane, click the instance you want to read, and then click Continuously read probe data. While reading, the status of the active instance shows Unloading. You can read continuously from multiple instances.
You can access read data with the shortcut menus in the Instance Manager pane.
To adjust the probe read interval, in the Instance Manager pane, turn on the Manual option in the Probe read interval sub-pane, and specify the sample rate in the text field next to the Manual option. The maximum sample rate depends on your computer setup. The actual sample rate is shown in the Current interval box. You can adjust the event log window buffer size in the Maximum Size box.
6.4.4.2. Writing Data
Modified values that are not written out to the ALTSOURCE_PROBE instances appear in red. To update the ALTSOURCE_PROBE instance, highlight the instance in the Instance Manager pane and click Write source data. The Write source data function is also available via the shortcut menus in the Instance Manager pane.
The In-System Sources and Probes Editor provides the option to continuously update each ALTSOURCE_PROBE instance. Continuous updating allows any modifications you make to the source data buffer to also write immediately to the ALTSOURCE_PROBE instances. To continuously update the ALTSOURCE_PROBE instances, change the Write source data field from Manually to Continuously.
6.4.4.3. Organizing Data
To create a group of signals, select the node names you want to group, right-click and select Group. You can modify the display format in the Bus Display Format and the Bus Bit order shortcut menus.
The In-System Sources and Probes Editor pane allows you to rename any signal. To rename a signal, double-click the name of the signal and type the new name.
The event log contains a record of the most recent samples. The buffer size is adjustable up to 128k samples. The time stamp for each sample is logged and is displayed above the event log of the active instance as you move your pointer over the data samples.
You can save the changes that you make and the recorded data to a Sources and Probes File ( .spf ). To save changes, on the File menu, click Save. The file contains all the modifications you made to the signal groups, as well as the current data event log.
6.5. Tcl interface for the In-System Sources and Probes Editor
The Tcl interface for the In-System Sources and Probes Editor provides a powerful platform to help you debug your design. The Tcl interface is especially helpful for debugging designs that require toggling multiple sets of control inputs. You can combine multiple commands with a Tcl script to define a custom command set.
Command | Argument | Description |
---|---|---|
start_insystem_source_probe | -device_name <device name> -hardware_name <hardware name> | Opens a
handle to a device with the specified hardware. Call this command before starting any transactions. |
get_insystem_source_probe_instance_info | -device_name <device name> -hardware_name <hardware name> | Returns a
list of all ALTSOURCE_PROBE instances in your design. Each record
returned is in the following format: {<instance Index>, <source width>, <probe width>, <instance name>} |
read_probe_data | -instance_index <instance_index> -value_in_hex (optional) | Retrieves
the current value of the probe. A string is returned that specifies the status of each probe, with the MSB as the left-most bit. |
read_source_data | -instance_index <instance_index> -value_in_hex (optional) | Retrieves
the current value of the sources. A string is returned that specifies the status of each source, with the MSB as the left-most bit. |
write_source_data | -instance_index <instance_index> -value <value> -value_in_hex (optional) | Sets the
value of the sources. A binary string is sent to the source ports, with the MSB as the left-most bit. |
end_insystem_source_probe | None | Releases
the JTAG chain. Issue this command when all transactions are finished. |
The example shows an excerpt from a Tcl script with procedures that control the ALTSOURCE_PROBE instances of the design as shown in the figure below. The example design contains a DCFIFO with ALTSOURCE_PROBE instances to read from and write to the DCFIFO. A set of control muxes are added to the design to control the flow of data to the DCFIFO between the input pins and the ALTSOURCE_PROBE instances. A pulse generator is added to the read request and write request control lines to guarantee a single sample read or write. The ALTSOURCE_PROBE instances, when used with the script in the example below, provide visibility into the contents of the FIFO by performing single sample write and read operations and reporting the state of the full and empty status flags.
## Setup USB hardware - assumes only USB Blaster is installed and ## an FPGA is the only device in the JTAG chain set usb [lindex [get_hardware_names] 0] set device_name [lindex [get_device_names -hardware_name $usb] 0] ## write procedure : argument value is integer proc write {value} { global device_name usb variable full start_insystem_source_probe -device_name $device_name -hardware_name $usb #read full flag set full [read_probe_data -instance_index 0] if {$full == 1} {end_insystem_source_probe return "Write Buffer Full" } ##toggle select line, drive value onto port, toggle enable ##bits 7:0 of instance 0 is S_data[7:0]; bit 8 = S_write_req; ##bit 9 = Source_write_sel ##int2bits is custom procedure that returns a bitstring from an integer ## argument write_source_data -instance_index 0 -value /[int2bits [expr 0x200 | $value]] write_source_data -instance_index 0 -value [int2bits [expr 0x300 | $value]] ##clear transaction write_source_data -instance_index 0 -value 0 end_insystem_source_probe } proc read {} { global device_name usb variable empty start_insystem_source_probe -device_name $device_name -hardware_name $usb ##read empty flag : probe port[7:0] reads FIFO output; bit 8 reads empty_flag set empty [read_probe_data -instance_index 1] if {[regexp {1........} $empty]} { end_insystem_source_probe return "FIFO empty" } ## toggle select line for read transaction ## Source_read_sel = bit 0; s_read_reg = bit 1 ## pulse read enable on DC FIFO write_source_data -instance_index 1 -value 0x1 -value_in_hex write_source_data -instance_index 1 -value 0x3 -value_in_hex set x [read_probe_data -instance_index 1 ] end_insystem_source_probe return $x }
6.6. Design Example: Dynamic PLL Reconfiguration
Stratix® PLLs allow you to dynamically update PLL coefficients during run time. Each enhanced PLL within the Stratix® device contains a register chain that allows you to modify the pre-scale counters (m and n values), output divide counters, and delay counters. In addition, the ALTPLL_RECONFIG IP core provides an easy interface to access the register chain counters. The ALTPLL_RECONFIG IP core provides a cache that contains all modifiable PLL parameters. After you update all the PLL parameters in the cache, the ALTPLL_RECONFIG IP core drives the PLL register chain to update the PLL with the updated parameters. The figure shows a Stratix® -enhanced PLL with reconfigurable coefficients.
This design example was created using a Nios® II Development Kit, Stratix® Edition. The file sourceprobe_DE_dynamic_pll.zip contains all the necessary files for running this design example, including the following:
- Readme.txt—A text file that describes the files contained in the design example and provides instructions about running the Tk GUI shown in the figure below.
-
Interactive_Reconfig.qar—The archived
Intel®
Quartus® Prime project for this design example. Figure 88. Interactive PLL Reconfiguration GUI Created with Tk and In-System Sources and Probes Tcl Package
6.7. Document Revision History
The following revision history applies to this chapter:
Document Version | Intel® Quartus® Prime Version | Changes |
---|---|---|
2019.06.11 | 18.1.0 | Rebranded megafunction to Intel® FPGA IP core |
2018.05.07 | 18.0.0 | Added details on finding the In-System Sources and Probes in the IP Catalog. |
2016.10.31 | 16.1.0 | Implemented Intel rebranding. |
2015.11.02 | 15.1.0 | Changed instances of Quartus II to Intel® Quartus® Prime . |
June 2014 | 14.0.0 | Updated formatting. |
June 2012 | 12.0.0 | Removed survey link. |
November 2011 | 10.1.1 | Template update. |
December 2010 | 10.1.0 | Minor corrections. Changed to new document template. |
July 2010 | 10.0.0 | Minor corrections. |
November 2009 | 9.1.0 |
|
March 2009 | 9.0.0 | No change to content. |
November 2008 | 8.1.0 | Changed to 8-1/2 x 11 page size. No change to content. |
May 2008 | 8.0.0 |
|
7. Analyzing and Debugging Designs with System Console
7.1. Introduction to System Console
- Perform board bring-up with finalized or partially complete designs.
- Automate run-time verification through scripting across multiple devices.
- Debug transceiver links, memory interfaces, and Ethernet interfaces with toolkits.
- Integrate your debug IP into the debug platform.
- Perform system verification with MATLAB* and Simulink.
7.1.1. IP Cores that Interact with System Console
You can instantiate debug IP cores using the Intel® Quartus® Prime software IP Catalog and parameter editor. Some IP cores are enabled for debug by default, while you can enable debug for other IP cores through options in the parameter editor. Some debug agents have multiple purposes.
When you include debug enabled IP cores in your design, you can access large portions of the design running on hardware for debugging purposes. Debug agents allow you to read and write to memory and alter peripheral registers from the host computer.
Services associated with debug agents in the running design can open and close as you need. System Console determines the communication protocol with the debug agent. The communication protocol determines the best board connection to use for command and data transmission.
The Programmable SRAM Object File (.sof) that the Intel® Quartus® Prime Assembler generates for programming provides the System Console with channel communication information. When you open System Console from the Intel® Quartus® Prime software GUI, with a project open that includes a .sof, System Console automatically finds and links to the device(s) it detects. When you open System Console without an open project, or with an unrelated project open, you can manually load the .sof file that you want, and then the design linking occurs automatically if the device(s) match.
7.1.2. Services Provided through Debug Agents
Service |
Function |
Debug Agent Providing Service |
---|---|---|
master | Access memory-mapped ( Avalon® -MM or AXI) slaves connected to the master interface. |
|
slave | Allows the host to access a single slave without needing to know the location of the slave in the host's memory map. Any slave that is accessible to a System Console master can provide this service. |
If an SRAM Object File (.sof) is loaded, then slaves controlled by a debug master provide the slave service. |
processor |
|
Nios® II with debug |
JTAG UART | The JTAG UART is an Avalon® -MM slave device that you can use in conjunction with System Console to send and receive byte streams. | JTAG UART |
- JTAG Debug Link
- JTAG Hub Controller System
- USB Debug Link
7.1.3. System Console Debugging Flow
The System Console debugging flow includes the following steps:
- Add debug enabled Intel® FPGA IP to your design.
- Compile the design.
- Connect to a board and program the FPGA.
- Start the System Console.
- Locate and open a System Console service.
- Perform debug operations with the service.
- Close the service.
7.2. Starting System Console
- To start System Console from the
Intel®
Quartus® Prime
software GUI:
Click Tools > System Debugging Tools > System Console.
Or
Click Tools > System Debugging Tools > System Debugging Toolkits.
- To start System Console from Platform Designer:
Click Tools > System Console
- To start Stand-Alone System Console:
- Navigate to the Download Center page, click Additional Software, and download and install Stand-Alone System Console .
- On the Windows Start menu, click All Programs > Intel FPGA <version> > Programmer and Tools > System Console.
- To start System Console from a
Nios® II Command
Shell:
- On the Windows Start menu, click All Programs > Intel > Nios® II EDS <version> > Nios® II<version> > Command Shell..
- Type system-console.
- Type system-console --project_dir=<project directory> to point
to a directory that contains .qsf or
.sof files. Note: Type --help for System Console help.
7.2.1. Customizing System Console Startup
- Add commands to the system_console_rc configuration file located at:
- <$HOME>/system_console/system_console_rc.tcl
- Specify your own design startup configuration file with the command-line argument --rc_script=<path_to_script> , when you launch System Console from the Nios® II command shell.
- Use the system_console_rc.tcl file in combination with your custom rc_script.tcl file. In this case, the system_console_rc.tcl file performs System Console actions, and the rc_script.tcl file performs your debugging actions.
On startup, System Console automatically runs the Tcl commands in these files. The commands in the system_console_rc.tcl file run first, followed by the commands in the rc_script.tcl file.
7.3. System Console GUI
- Toolkit Explorer—displays all available toolkits and launches tools that use the System Console framework.
- System Explorer—displays a list of interactive instances in your design, including board connections, devices, designs, servers, and scripts.
- Main View—initially displays the welcome screen. All toolkits that you launch display in this view.
- Tcl Console—allows you to interact with your design using Tcl scripts, for example, sourcing scripts, writing procedures, and using System Console APIs.
- Messages—displays status, warning, and error messages related to connections and debug actions.
The System Console GUI also provides the Autosweep, Dashboard, and Eye Viewer panes, that display as tabs in the Main View.
- System Console Views
The System Console provides the following views: - Toolkit Explorer Pane
- System Explorer Pane
The System Explorer pane displays a list of interactive instances from the design loaded on a connected device. This includes the following items:
7.3.1. System Console Views
- Main View
The Main View in System Console allows you to visualize certain parameter values of the IP that the toolkit targets. These parameter values can be static values from compile-time parameterization, or dynamic values read from the hardware (like reading from CSR registers) at run-time. - Autosweep View
The Autosweep view allows you to sweep over IP parameters to find the best combination. - Dashboard View
The Dashboard view allows you to visualize the changes to toolkit parameters over time. - Eye Viewer
7.3.1.1. Main View
The Main View GUI controls allow you to control or configure the IP on the hardware.

If you are using a toolkit, you can add or remove columns from the table in the Main View. Right-click on the table header and select Edit Columns in the right-click menu. The Select column headers dialog box is displayed where you can choose to include more columns, as shown in the following image:
Parameters Pane
The Main View provides the Parameters pane that has two tabs, one for global parameters (those not associated with a given channel) and another for channel parameters (those associated with channels). The Channel Parameters tab is filled with per-channel parameter editors based on channel row selection in the Status Table, as Figure 97 shows.
Status Table Pane
The Status Table does not appear for toolkits that do not define channels. The Status Table allows you to view status information across all channels of a collection or a toolkit instance, as well as execute actions across multiple channels, as Figure 97 shows. You can execute bulk actions spanning multiple channels by selecting desired channels, and right-clicking and exploring the Actions sub-menu.
You can also use the Status Table to select which channel to display in the Parameters Pane. The channels you select in the Status Table are shown in the Parameters Pane. You can use the Pin setting for a channel to display the channel, regardless of the current selection in the Status Table.
If you decide to develop your own toolkit, you can design the layout and GUI elements in the Main View using the Toolkit Tcl API. You can also define how each GUI elements interact with the hardware.
7.3.1.1.1. Link Pair View
Displaying Links With the Main View
- Select both RX and TX channels in the Status Table.
- Right-click to view the context-sensitive menu.
- Navigate to the Actions menu.
Custom Groups with Links
In the Status Table, links are displayed like any other channel, with the exception that its parameter list encompasses all parameters from the associated TX and RX channels. If you create a group with a link and its associated TX and RX instance channels, the link row in the Status Table populates in all columns. Whereas, for the independent TX and RX channel rows, only parameters associated to that channel populate the Status Table.
Configuring Link
You have the option to configure links in the following ways:
- Through the provided status table in Main View.
- Through configuration options provided for the associated TX and RX channels.
Provided TX and RX channels allow you to individually manipulate each associated channel. You can manipulate multiple parameters by multi-selecting and right-clicking parameters in the status table.
7.3.1.2. Autosweep View
The System Console Autosweep view allows you to define your own quality metrics for a given Autosweep run.

By default the Autosweep view launches without any connection to a toolkit instance(s) or channel pair(s). You can add parameters by clicking Add Parameter and selecting parameters from specific toolkit instance(s) in the Select Parameter dialog box. You can remove parameters by selecting them and clicking Remove Parameter. Alternatively, you can add your own parameters and create as many Autosweep views as you want, to allow sweeping over different parameters on different channels of the same instance, or different instances entirely.
To save a parameter set for future use, select the parameter set, and then click Export Settings. To load a collection, click Import Settings.
Consider the following example of the Autosweep system:
The Autosweep view allows you to sweep a complex system with parameters spread across multiple devices visible to System Console. You can select the quality metrics from instances different from than those you sweep. You can even span levels of the hardware stack from the PMA-level up to protocol-level signaling.
Results
The Results table is populated with one row per autosweep iteration. For every output quality metric added in the Output Metrics section, a column for that metric is added to the Results table, with new row entries added to the bottom. This format allows sorting the results by quality metric of the system under test, across many combinations of parameters, to determine which parameter settings achieve best real-world results.
The Results table allows visualizing or copying the parameter settings associated with a given case, and sorting by quality metrics. Sort the rows of the table by clicking on the column headers.
Control
The Control pane of the Autosweep view allows starting an autosweep run, once you define at least one input parameter and one quality metric. Starting a run, allowing all combinations to complete, and then pressing the Start button re-runs the same test case. Pressing the Stop button cancels a currently running autosweep.
7.3.1.3. Dashboard View
The Dashboard provides a line chart, histogram, pie chart, bar graph, and data history. There is no limit imposed on the number of instances of the Dashboard view open at once. However, a performance penalty occurs if you update a high number of parameters at a high frequency simultaneously.

The Add Parameter dialog box opens when you click the Add parameter button. Only those parameters that declare the allows_charting parameter property are available for selection in the Add Parameter dialog box.
7.3.1.4. Eye Viewer
The System Console Eye Viewer allows you to configure, run, and render eye scans. The Eye Viewer allows independent control of the eye for each different transceiver instances. System Console allows you to open only one Eye Viewer per-instance channel pair at any given time. Therefore, there is a one-to-one mapping of a given Eye Viewer GUI to a given instance of the eye capture hardware on the FPGA. Click Tools > Eye Viewer to launch the Eye Viewer.
Eye Viewer Controls
The Eye Viewer controls allows you to configure toolkit-specific settings for the current Eye Viewer scan. The parameters in the Eye Viewer affect the behavior and details of the eye scan run.
Start / Stop Controls
The Eye Viewer provides Start and Stop controls. The Start button starts the eye scanning process while the Stop button cancels an incomplete scan
Eye Diagram Visualization
The eye diagram displays the transceiver eye captured from on-die instrumentation (ODI) with a color gradient. a map of bit error rate (BER) range to color represents the gradient, as shown in the legend on the left.
Results Table
The Results table displays results and statistics of all eye scans. While an eye scan is running, you cannot view any partial result. However, there is a progress bar showing the current progress of the eye scan underway.
When an eye scan successfully completes, a new entry appears in the Results table, and that entry automatically gains focus. When you select a given entry in the Results table, the eye diagram renders the associated eye data. You can right-click in the Results table to do the following:
- Apply the test case parameters to the device
- Delete an entry
If developing your own toolkit that includes the Eye Viewer, the BER gradient is configurable, and the eye diagram GUI supports the following features:
- A BER tool-tip for each cell
- Ability to export the map as PNG
- Zoom
7.3.2. Toolkit Explorer Pane
The Toolkit Explorer pane displays all available toolkits and launches tools that use the System Console framework. When you load a design that contains debug-enabled IP, the Toolkit Explorer displays the design instances, along with a list of channels and channel collections for debugging. To interact with a channel or a toolkit, double-click on it to launch the Main View tabbed window, as shown in the following image:
7.3.3. System Explorer Pane
- IP instances with debugging toolkit capabilities
- IP instances with a debug endpoint
Additionally, the System Explorer also displays custom toolkit groups and links that you create. System Explorer organizes the interactive instances according to the available device connections. The System Explorer contains a Links instance, and may contain a Files instance. The Links instance shows debug agents (and other hardware) that System Console can access. The Files instance contains information about the design files loaded from the Intel® Quartus® Prime project for the device.
The System Explorer provides the following information:
- Devices—displays information about all devices connected to the System Console.
- Scripts—stores scripts for easy execution.
- Connections—displays information about the board connections visible to System Console, such as the Intel® FPGA Download Cable. Multiple connections are possible.
- Designs—displays information about Intel® Quartus® Prime designs connected to System Console. Each design represents a loaded .sof file.
- Right-click on some of the instances to execute related commands.
- Instances that include a message display a message icon. Click on the instance to view the messages in the Messages pane.
7.4. Launching a Toolkit in System Console
System Console provides the hardware debugging infrastructure to run the Available System Debugging Toolkits. When you load a design in the Toolkit Explorer that includes debug-enabled Intel® FPGA IP, the Toolkit Explorer automatically lists the toolkits that are available for the IP in the design.
To launch a toolkit in System Console, follow these steps:
- Create an Intel® Quartus® Prime project that includes debug-enabled Intel® FPGA IP. Refer to IP Cores that Interact with System Console.
- On the Compilation Dashboard, double-click Assembler to generate a .sof programming file for the design.
- Launch System Console, as Starting System Console describes.Figure 99. Launching a Toolkit in System Console
- In the Toolkit Explorer, click Load Design, and then select the .sof file that you create in step 2. When you load the design, Toolkit Explorer displays the debug-enabled IP instances.
- Select a debug-enabled IP instance. The Details pane displays the channels that can launch toolkits.
- To launch a toolkit, select the toolkit under Details. For toolkits with channels, you can also multi-select, one or more channels from the Details pane. Then, click Open Toolkit. The toolkit opens in the Main View, and the Collections pane displays a collection of any channels that you select.
- To save a collection for future use, right-click the collection, and then click Export Collection. To load a collection, right-click in the Collections pane, and then click Import Collection. By default, System Console creates a collection when you launch a toolkit.
7.4.1. Available System Debugging Toolkits
Toolkit | Description | Toolkit Documentation |
---|---|---|
EMIF Calibration Debug Toolkit | Helps you to debug external memory interfaces by accessing data during memory calibration. The analysis tools can evaluate the stability of the calibrated interface and assess hardware conditions. |
|
EMIF Traffic Generator Configuration Toolkit |
Helps you to debug external memory interfaces by sending sample traffic through the external memory interface to the memory device. The generated EMIF design example includes a traffic generator block with control and status registers. |
|
EMIF Efficiency Monitor Toolkit | Helps you to debug external memory interfaces by measuring efficiency on the Avalon interface in real time. The generated EMIF design example can include the Efficiency Monitor block. |
|
Ethernet Toolkit | Helps you to interact with and debug an Ethernet Intel FPGA IP interface in real time. You can verify the status of the Ethernet link, assert and deassert IP resets, verifies the IP error correction capability, | Ethernet Toolkit User Guide |
Intel® Stratix® 10 FPGA P-Tile Toolkit (for PCIe) | Helps you to optimize the performance of large-size data transfers with real-time control, monitoring, and debugging of the PCI Express* links at the Physical, Data Link, and Transaction layers. | Intel FPGA P-Tile Avalon® Memory Mapped IP for PCI Express* User Guide |
Serial Lite IV IP Toolkit | An inspection tool that monitors the status of a Serial Lite IV IP link and provides a step-by-step guide for the IP link initialization sequences. |
|
Intel® Arria® 10 and Intel® Cyclone® 10 GX Transceiver Native PHY Toolkit | Helps you to optimize high-speed serial links in your board design by providing real-time control, monitoring, and debugging of the transceiver links running on your board. | |
L-Tile and H-Tile Transceiver Native PHY Toolkit | ||
E-Tile Transceiver Native PHY Toolkit |
The following legacy toolkits remain available by clicking Tools > Legacy Toolkits in System Console:
Legacy Toolkit | Description | Legacy Toolkit Documentation |
---|---|---|
Ethernet Link Inspector - Link Monitor Toolkit | The Ethernet Link Inspector is an inspection tool that can continuously monitor an Ethernet link that contains an Ethernet IP. The Link Monitor toolkit performs real-time status monitoring of an Ethernet IP link. The link monitor continuously reads and displays all of the required status registers related to the Ethernet IP link, and displays the Ethernet IP link status at various stages are valid. | Ethernet Link Inspector User Guide for Intel® Stratix® 10 Devices |
Ethernet Link Inspector - Link Analysis Toolkit | The Link Analysis toolkit displays a sequence of events on an Ethernet IP link, which occur in a finite duration of time. The Link Analysis requires the Signal Tap logic analyzer to first capture and store a database (.csv) of all required signals. The Link Analysis toolkit then performs an analysis on the database to extract all the required information and displays them in a user-friendly graphical user interface (GUI). | |
S10 SDM Debug Toolkit | Provides access to current status of the Intel® Stratix® 10 device. To use these commands you must have a valid design loaded that includes the module that you intend to access | Intel® Stratix® 10 Configuration User Guide |
7.4.2. Creating Collections from the Toolkit Explorer
You can create custom collections to view and configure members from different instances in a single Main View.
Perform these steps to group instances:
- Select multiple items in the instances tree.
- Right click to view the content-sensitive menu.
- Select Add to Collection > New Collection. The Add to Collection dialog box appears with members you select.
System Console add the collections that you create to the Collections pane of the Toolkit Explorer. You can perform one of the following actions:
- Double-click on a custom-created collection to launch the Main view containing all of the group’s members.
- Right-click on an existing collection member and select Remove from Collection to remove the member.
7.4.3. Filtering and Searching Interactive Instances
By default, the Toolkits list shows all toolkit instances and their respective channels linking to the System Console. This view is useful in simple cases, but can become very dense in a complex system having many debug-enabled IPs, and having potentially multiple FPGAs connected to System Console.

To limit the information display, the Filter list allows filtering the display by toolkit types currently available in the System Console. You can also create custom filters using groups, for example, “Inst A, Inst F, and Inst Z”, or “E-Tile and L/H-Tile Transceivers only".
To refine the list of toolkits, use the search field in the Toolkit Explorer to filter the list further.
7.5. System Console Services
7.5.1. Locating Available Services
Locating a Service Path
#We are interested in master services. set service_type "master" #Get all the paths as a list. set master_service_paths [get_service_paths $service_type] #We are interested in the first service in the list. set master_index 0 #The path of the first master. set master_path [lindex $master_service_paths $master_index] #Or condense the above statements into one statement: set master_path [lindex [get_service_paths master] 0]
System Console commands require service paths to identify the service instance you want to access. The paths for different components can change between runs of System Console and between versions. Use the get_service_paths command to obtain service paths.
The string values of service paths change with different releases of the tool. Use the marker_node_info command to get information from the path.
System Console automatically discovers most services at startup. System Console automatically scans for all JTAG and USB-based service instances and retrieves their service paths. System Console does not automatically discover some services, such as TCP/IP. Use add_service to inform System Console about those services.
Marker_node_info
Use the marker_node_info command to get information about SLD nodes associated with the specified service.
set slave_path [get_service_paths -type altera_avalon_uart.slave slave] array set uart_info [marker_node_info $slave_path] echo $uart_info(full_hpath)
7.5.2. Opening and Closing Services
The claim_service command directs System Console to start using a particular service instance, and with no additional arguments, claims a service instance for exclusive use.
Opening a Service
set service_type "master" set claim_path [claim_service $service_type $master_path mylib];#Claims service.
You can pass additional arguments to the claim_service command to direct System Console to start accessing a particular portion of a service instance. For example, if you use the master service to access memory, then use claim_service to only access the address space between 0x0 and 0x1000. System Console then allows other users to access other memory ranges, and denies access to the claimed memory range. The claim_service command returns a newly created service path that you can use to access your claimed resources.
You can access a service after you open it. When you finish accessing a service instance, use the close_service command to direct System Console to make this resource available to other users.
Closing a Service
close_service master $claim_path; #Closes the service.
7.5.3. SLD Service
SLD Service
set timeout_in_ms 1000 set lock_failed [sld_lock $sld_service_path $timeout_in_ms]
This code attempts to lock the selected SLD node. If it is already locked, sld_lock waits for the specified timeout. Confirm the procedure returns non-zero before proceeding. Set the instruction register and capture the previous one:
if {$lock_failed} { return } set instr 7 set delay_us 1000 set capture [sld_access_ir $sld_service_path $instr $delay_us]
The 1000 microsecond delay guarantees that the following SLD command executes at least 1000 microseconds later. Data register access works the same way.
set data_bit_length 32 set delay_us 1000 set data_bytes [list 0xEF 0xBE 0xAD 0xDE] set capture [sld_access_dr $sld_service_path $data_bit_length $delay_us \ $data_bytes]
Shift count is specified in bits, but the data content is specified as a list of bytes. The capture return value is also a list of bytes. Always unlock the SLD node once finished with the SLD service.
sld_unlock $sld_service_path
7.5.3.1. SLD Commands
Command |
Arguments |
Function |
---|---|---|
sld_access_ir |
<claim-path> <ir-value> <delay> (in µs) |
Shifts the instruction value into the instruction register of the specified node. Returns the previous value of the instruction. If the <delay> parameter is non-zero, then the JTAG clock is paused for this length of time after the access. |
sld_access_dr |
<service-path> <size_in_bits> <delay-in-µs>, <list_of_byte_values> |
Shifts the byte values into the data register of the SLD node up to the size in bits specified. If the <delay> parameter is non-zero, then the JTAG clock is paused for at least this length of time after the access. Returns the previous contents of the data register. |
sld_lock |
<service-path> <timeout-in-milliseconds> |
Locks the SLD chain to guarantee exclusive access. Returns 0 if successful. If the SLD chain is already locked by another user, tries for <timeout>ms before returning a Tcl error. You can use the catch command if you want to handle the error. |
sld_unlock |
<service-path> |
Unlocks the SLD chain. |
7.5.4. In-System Sources and Probes Service
ISSP Service
Before you use the ISSP service, ensure your design works in the In-System Sources and Probes Editor. In System Console, open the service for an ISSP instance:
set issp_index 0 set issp [lindex [get_service_paths issp] 0] set claimed_issp [claim_service issp $issp mylib]
View information about this particular ISSP instance:
array set instance_info [issp_get_instance_info $claimed_issp] set source_width $instance_info(source_width) set probe_width $instance_info(probe_width)
The Intel® Quartus® Prime software reads probe data as a single bitstring of length equal to the probe width:
set all_probe_data [issp_read_probe_data $claimed_issp]
As an example, you can define the following procedure to extract an individual probe line's data:
proc get_probe_line_data {all_probe_data index} { set line_data [expr { ($all_probe_data >> $index) & 1 }] return $line_data } set initial_all_probe_data [issp_read_probe_data $claim_issp] set initial_line_0 [get_probe_line_data $initial_all_probe_data 0] set initial_line_5 [get_probe_line_data $initial_all_probe_data 5] # ... set final_all_probe_data [issp_read_probe_data $claimed_issp] set final_line_0 [get_probe_line_data $final_all_probe_data 0]
Similarly, the Intel® Quartus® Prime software writes source data as a single bitstring of length equal to the source width:
set source_data 0xDEADBEEF issp_write_source_data $claimed_issp $source_data
You can also retrieve the currently set source data:
set current_source_data [issp_read_source_data $claimed_issp]
As an example, you can invert the data for a 32-bit wide source by doing the following:
set current_source_data [issp_read_source_data $claimed_issp] set inverted_source_data [expr { $current_source_data ^ 0xFFFFFFFF }] issp_write_source_data $claimed_issp $inverted_source_data
7.5.4.1. In-System Sources and Probes Commands
Command |
Arguments |
Function |
---|---|---|
issp_get_instance_info |
<service-path> |
Returns a list of the configurations of the In-System Sources and Probes instance, including: instance_index instance_name source_width probe_width |
issp_read_probe_data |
<service-path> |
Retrieves the current value of the probe input. A hex string is returned representing the probe port value. |
issp_read_source_data |
<service-path> |
Retrieves the current value of the source output port. A hex string is returned representing the source port value. |
issp_write_source_data |
<service-path> <source-value> |
Sets values for the source output port. The value can be either a hex string or a decimal value supported by the System Console Tcl interpreter. |
7.5.5. Monitor Service
Monitor Service
- Determine the master and the memory address range that you want to
poll:
set master_index 0 set master [lindex [get_service_paths master] $master_index] set address 0x2000 set bytes_to_read 100 set read_interval_ms 100
With the first master, read 100 bytes starting at address 0x2000 every 100 milliseconds.
- Open the monitor
service:
set monitor [lindex [get_service_paths monitor] 0] set claimed_monitor [claim_service monitor $monitor mylib]
The monitor service opens the master service automatically.
- With the monitor service, register the address range and time
interval:
monitor_add_range $claimed_monitor $master $address $bytes_to_read monitor_set_interval $claimed_monitor $read_interval_ms
- Add more ranges, defining the result at each
interval:
global monitor_data_buffer set monitor_data_buffer [list]
- Gather the data and append it with a global
variable:
proc store_data {monitor master address bytes_to_read} { global monitor_data_buffer # monitor_read_data returns the range of data polled from the running design as a list #(in this example, a 100-element list). set data [monitor_read_data $claimed_monitor $master $address $bytes_to_read] # Append the list as a single element in the monitor_data_buffer global list. lappend monitor_data_buffer $data }
Note: If this procedure takes longer than the interval period, the monitor service may have to skip the next one or more calls to the procedure. In this case, monitor_read_data returns the latest polled data. - Register this callback with the opened monitor
service:
set callback [list store_data $claimed_monitor $master $address $bytes_to_read] monitor_set_callback $claimed_monitor $callback
- Use the callback variable to call when the monitor finishes an interval. Start
monitoring:
monitor_set_enabled $claimed_monitor 1
Immediately, the monitor reads the specified ranges from the device and invokes the callback at the specified interval. Check the contents of monitor_data_buffer to verify this. To turn off the monitor, use 0 instead of 1 in the above command.
7.5.5.1. Monitor Commands
Under normal load, the monitor service reads the data after each interval and then calls the callback. If the value you read is timing sensitive, you can use the monitor_get_read_interval command to read the exact time between the intervals at which the data was read.
Under heavy load, or with a callback that takes a long time to execute, the monitor service skips some callbacks. If the registers you read do not have side effects (for example, they read the total number of events since reset), skipping callbacks has no effect on your code. The monitor_read_data command and monitor_get_read_interval command are adequate for this scenario.
If the registers you read have side effects (for example, they return the number of events since the last read), you must have access to the data that was read, but for which the callback was skipped. The monitor_read_all_data and monitor_get_all_read_intervals commands provide access to this data.
Command | Arguments | Function |
---|---|---|
monitor_add_range |
<service-path> <target-path> <address> <size> |
Adds a contiguous memory address into the monitored memory list. <service path> is the value returned when you opened the service. <target-path> argument is the name of a master service to read. The address is within the address space of this service. <target-path> is returned from [lindex [get_service_paths master] n] where n is the number of the master service. <address> and <size> are relative to the master service. |
monitor_get_all_read_intervals |
<service-path> <target-path> <address> <size> |
Returns a list of intervals in milliseconds between two reads within the data returned by monitor_read_all_data. |
monitor_get_interval | <service-path> | Returns the current interval set which specifies the frequency of the polling action. |
monitor_get_missing_event_count | <service-path> | Returns the number of callback events missed during the evaluation of last Tcl callback expression. |
monitor_get_read_interval |
<service-path> <target-path> <address> <size> |
Returns the milliseconds elapsed between last two data reads returned by monitor_read_data. |
monitor_read_all_data |
<service-path> <target-path> <address> <size> |
Returns a list of 8-bit values read from all recent values read from device since last Tcl callback. You must specify a memory range within the range in monitor_add_range. |
monitor_read_data |
<service-path> <target-path> <address> <size> |
Returns a list of 8-bit values read from the most recent values read from device. You must specify a memory range within the range in monitor_add_range. |
monitor_set_callback |
<service-path> <Tcl-expression> |
Specifies a Tcl expression that the System Console must evaluate after reading all the memories that this service monitors. Typically, you specify this expression as a single string Tcl procedure call with necessary argument passed in. |
monitor_set_enabled |
<service-path>
<enable(1)/disable(0)> |
Enables and disables monitoring. Memory read starts after this command, and Tcl callback evaluates after data is read. |
monitor_set_interval |
<service-path> <interval> |
Defines the target frequency of the polling action by specifying the interval between two memory reads. The actual polling frequency varies depending on the system activity. |
7.5.6. Device Service
Programming
You can use the device service with Tcl scripting to perform device programming:
set device_index 0 ; #Device index for target set device [lindex [get_service_paths device] $device_index] set sof_path [file join project_path output_files project_name.sof] device_download_sof $device $sof_path
To program, all you need are the device service path and the file system path to a .sof. Ensure that no other service (e.g. master service) is open on the target device or else the command fails. Afterwards, you may do the following to check that the design linked to the device is the same one programmed:
device_get_design $device
7.5.6.1. Device Commands
Command |
Arguments |
Function |
---|---|---|
device_download_sof |
<service_path> <sof-file-path> |
Loads the specified .sof to the device specified by the path. |
device_get_connections |
<service_path> |
Returns all connections which go to the device at the specified path. |
device_get_design |
<device_path> |
Returns the design this device is currently linked to. |
7.5.7. Design Service
Load
When you open System Console from the Intel® Quartus® Prime software, the current project's debug information is sourced automatically if the .sof file is present. In other situations, you can load the .sof manually.
set sof_path [file join project_dir output_files project_name.sof] set design [design_load $sof_path]
System Console is now aware of the .sof loading.
Linking
Once a .sof loads, System Console automatically links design information to the connected device. The link persists and you can unlink or reuse the link on an equivalent device with the same .sof.
You can perform manual linking as follows:
set device_index 0; # Device index for our target set device [lindex [get_service_paths device] $device_index] design_link $design $device
Manually linking fails if the target device does not match the design service.
Linking fails even if the .sof programmed to the target is not the same as the design .sof.
7.5.7.1. Design Service Commands
Command |
Arguments |
Function |
---|---|---|
design_load |
<quartus-project-path>, <sof-file-path>, or <qpf-file-path> |
Loads a model of an Intel® Quartus® Prime design into System Console. Returns the design path. For example, if your Intel® Quartus® Prime Project File (.qpf) is in c:/projects/loopback, type the following command: design_load {c:\projects\loopback\} |
design_link |
<design-path> <device-service-path> |
Links an Intel® Quartus® Prime logical design with a physical device. For example, you can link an Intel® Quartus® Prime design called 2c35_quartus_design to a 2c35 device. After you create this link, System Console creates the appropriate correspondences between the logical and physical submodules of the Intel® Quartus® Prime project. |
design_extract_debug_files |
<design-path> <zip-file-name> |
Extracts debug files from a .sof to a zip file which can be emailed to Intel FPGA Support for analysis. You can specify a design path of {} to unlink a device and to disable auto linking for that device. |
design_get_warnings |
<design-path> |
Gets the list of warnings for this design. If the design loads correctly, then an empty list returns. |
7.5.8. Bytestream Service
Bytestream Service
The following code finds the bytestream service for your interface and opens it:
set bytestream_index 0 set bytestream [lindex [get_service_paths bytestream] $bytestream_index] set claimed_bytestream [claim_service bytestream $bytestream mylib]
To specify the outgoing data as a list of bytes and send it through the opened service:
set payload [list 1 2 3 4 5 6 7 8] bytestream_send $claimed_bytestream $payload
Incoming data also comes as a list of bytes:
set incoming_data [list] while {[llength $incoming_data] ==0} { set incoming_data [bytestream_receive $claimed_bytestream 8] }
Close the service when done:
close_service bytestream $claimed_bytestream
7.5.8.1. Bytestream Commands
Command |
Arguments |
Function |
---|---|---|
bytestream_send |
<service-path> <values> |
Sends the list of bytes to the specified bytestream service. Values argument is the list of bytes to send. |
bytestream_receive |
<service-path> <length> |
Returns a list of bytes currently available in the specified services receive queue, up to the specified limit. Length argument is the maximum number of bytes to receive. |
7.5.9. JTAG Debug Service
The following is a JTAG Debug design flow example.
- To identify available JTAG Debug
paths:
get_service_paths jtag_debug
- To select a JTAG Debug
path:
set jtag_debug_path [lindex [get_service_paths jtag_debug] 0]
- To claim a JTAG Debug service
path:
set claim_jtag_path [claim_service jtag_debug$jtag_debug_path mylib]
- Running the JTAG Debug
service:
jtag_debug_reset_system $claim_jtag_path jtag_debug_loop $claim_jtag_path [list 1 2 3 4 5]
7.5.9.1. JTAG Debug Commands
JTAG Debug commands help debug the JTAG Chain connected to a device.
Command | Argument | Function |
---|---|---|
jtag_debug_loop | <service-path> <list_of_byte_values> | Loops the specified list of bytes through a loopback of tdi and tdo of a system-level debug (SLD) node. Returns the list of byte values in the order that they were received. This command blocks until all bytes are received. Byte values have the 0x (hexadecimal) prefix and are delineated by spaces. |
jtag_debug_sample_clock | <service-path> | Returns the clock signal of the system clock that drives the module's system interface. The clock value is sampled asynchronously; consequently, you must sample the clock several times to guarantee that it is switching. |
jtag_debug_sample_reset | <service-path> | Returns the value of the reset_n signal of the Avalon® -ST JTAG Interface core. If reset_n is low (asserted), the value is 0 and if reset_n is high (deasserted), the value is 1. |
jtag_debug_sense_clock | <service-path> | Returns a sticky bit that monitors system clock activity. If the clock switched at least once since the last execution of this command, returns 1. Otherwise, returns 0.. The sticky bit is reset to 0 on read. |
jtag_debug_reset_system | <service-path> | Issues a reset request to the specified service. Connectivity within your device determines which part of the system is reset. |
7.6. On-Board Intel FPGA Download Cable II Support
7.7. MATLAB and Simulink in a System Verification Flow
Advantages of HIL Approach
- Avoid long computational delays for algorithms with high processing rates
- API helps to control, debug, visualize, and verify FPGA designs all within the MATLAB* environment
- FPGA results are read back by the MATLAB* software for further analysis and display
Required Tools and Components
- MATLAB* software
- DSP Builder for Intel® FPGAs software
- Intel® Quartus® Prime software
- Intel FPGA

7.7.1. Supported MATLAB API Commands
You can perform the work from the MATLAB* environment, and read and write to masters and slaves through the System Console. The supported MATLAB* API commands spare you from launching the System Console software. The supported commands are:
- SystemConsole.refreshMasters;
- M = SystemConsole.openMaster(1);
- M.write (type, byte address, data);
- M.read (type, byte address, number of words);
- M.close
MATLAB* API Script Example
SystemConsole.refreshMasters; %Investigate available targets M = SystemConsole.openMaster(1); %Creates connection with FPGA target %%%%%%%% User Application %%%%%%%%%%%% .... M.write('uint32',write_address,data); %Send data to FPGA target .... data = M.read('uint32',read_address,size); %Read data from FPGA target .... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% M.close; %Terminates connection to FPGA target
7.7.2. High Level Flow
- Install the DSP Builder for Intel® FPGAs software, so you have the necessary libraries to enable this flow
-
Build the design using Simulink and the DSP Builder for
Intel®
FPGAs libraries.
DSP Builder for Intel® FPGAs helps to convert the Simulink design to HDL
- Include Avalon® -MM components in the design (DSP Builder for Intel® FPGAs can port non- Avalon® -MM components)
- Include Signals and Control blocks in the design
- Separate synthesizable and non-synthesizable logic with boundary blocks.
- Integrate the DSP system in Platform Designer
- Program the Intel FPGA
- Interact with the Intel FPGA through the supported MATLAB* API commands.
7.8. System Console Examples and Tutorials
7.8.1. Nios II Processor Example
To run this example, perform the following steps:
- Download the Nios® II Ethernet Standard Design Example for your board from the Intel® website.
- Create a folder to extract the design. For this example, use C:\Count_binary.
- Unzip the Nios® II Ethernet Standard Design Example into C:\Count_binary.
- In a Nios® II command shell, change to the directory of your new project.
- Program your board. In
a
Nios® II command shell, type the following:
nios2-configure-sof niosii_ethernet_standard_<board_version>.sof
- Using Nios® II Software Build Tools for Eclipse, create a new Nios® II Application and BSP from Template using the Count Binary template and targeting the Nios® II Ethernet Standard Design Example.
- To build the executable and linkable format (ELF) file (.elf) for this application, right-click the Count Binary project and select Build Project.
- Download the .elf file to your board by right-clicking
Count Binary project and selecting
Run As,
Nios® II Hardware.
- The LEDs on your board provide a new light show.
- Type the following:
system-console; #Start System Console. #Set the processor service path to the Nios II processor. set niosii_proc [lindex [get_service_paths processor] 0] set claimed_proc [claim_service processor $niosii_proc mylib]; #Open the service. processor_stop $claimed_proc; #Stop the processor. #The LEDs on your board freeze. processor_run $claimed_proc; #Start the processor. #The LEDs on your board resume their previous activity. processor_stop $claimed_proc; #Stop the processor. close_service processor $claimed_proc; #Close the service.
- The processor_step, processor_set_register, and processor_get_register commands provide additional control over the Nios® II processor.
7.8.1.1. Processor Commands
Command 1 | Arguments | Function |
---|---|---|
processor_download_elf |
<service-path> <elf-file-path> |
Downloads the given Executable and Linking Format File (.elf) to memory using the master service associated with the processor. Sets the processor's program counter to the .elf entry point. |
processor_in_debug_mode |
<service-path> |
Returns a non-zero value if the processor is in debug mode. |
processor_reset |
<service-path> |
Resets the processor and places it in debug mode. |
processor_run |
<service-path> |
Puts the processor into run mode. |
processor_stop |
<service-path> |
Puts the processor into debug mode. |
processor_step |
<service-path> |
Executes one assembly instruction. |
processor_get_register_names |
<service-path> |
Returns a list with the names of all of the processor's accessible registers. |
processor_get_register |
<service-path> <register_name> |
Returns the value of the specified register. |
processor_set_register |
<service-path> <register_name> <value> |
Sets the value of the specified register. |
7.9. Running System Console in Command-Line Mode
- --cli—Runs System Console in command-line mode.
- --project_dir=<project dir> —Directs System Console to the location of your hardware project. Also works in GUI mode.
- --script=<your script>.tcl—Directs System Console to run your Tcl script.
- --help— Lists all available commands. Typing --help <command name> provides the syntax and arguments of the command.
System Console provides command completion if you type the beginning letters of a command and then press the Tab key.
7.10. Toolkit Tcl Commands
Command Summary
Returns | Command | Arguments |
---|---|---|
no return value | add_channel | <channel-name> <channel-type> |
no return value | add_display_item | <parent-group> <id> <type> [<args>] |
no return value | add_parameter | <name> <type> [<value> <description>] |
no return value | add_requirement | <req-id> <req-type> |
no return value | add_timed_callback | <proc> <interval> |
String | get_accessible_module | [-hpath <hpath>] [-module_name <module-name>] [-version <version>] <req-id> |
String[] | get_accessible_modules | [-hpath <hpath>] [-module_name <module-name>] [-version <version>] <req-id> |
String | get_accessible_service | [-hpath <hpath>] [-type <type>] [-agent_type_name <agent-type-name>] <req-id> |
String[] | get_accessible_services | [-hpath <hpath>] [-type <type>] [-agent_type_name <agent-type-name>] <req-id> |
String | get_accessible_system | [-hpath <hpath>] [-design_id <design-id>] <req-id> |
String | get_channel_display_group | <channel> |
various | get_channel_property | <channel-name> <property> |
String | get_display_hint | <id> <display-hint> |
various | get_display_item_property | <id> <display-item-property> |
String | get_eye_viewer_display_group | <channel> |
various | get_parameter_property | <name> <property> |
String | get_parameter_value | <name> |
String | get_toolkit_property | <prop> |
no return value | remove_timed_callback | <proc> |
no return value | send_message | <level> <message> |
no return value | set_channel_property | <channel-name> <property> <property-value> |
no return value | set_current_progress | <progress> |
no return value | set_display_hint | <id> <display-hint> <value> |
no return value | set_display_item_property | <id> <display-property> <display-property-value> |
no return value | set_eye_data | <rows> |
no return value | set_eye_property | <property> <value> |
no return value | set_parameter_property | <name> <property> <value> |
no return value | set_parameter_update_callback | <name> <callback> [<opt-arg>] |
no return value | set_parameter_value | <name> <value> |
no return value | set_requirement_property | <req-id> <property-name> <property-values> |
no return value | set_toolkit_property | <prop> <value> |
boolean | stop_requested |
7.10.1.1. add_channel
Description
This adds a channel to your toolkit.Usage
add_channel <channel-name> <channel-type>ReturnType
NothingReturns
no return valueArguments
- channel-name
- The name of the channel.
- channel-type
- The data type of the channel.
Example
add_channel "Channel 0" OTHER
7.10.1.2. add_display_item
Description
This command adds a display item to the toolkit.Usage
add_display_item <parent-group> <id> <type> [<args>]ReturnType
NothingReturns
no return valueArguments
- parent-group
- Parent group of the display item
- id
- ID of this display item
- type
- Type of this display item this can be ACTION, GROUP, ICON, PARAMETER, TEXT, DIAL, or LED
- args (optional)
- Optional argument that will be supplied to the callback
Example
add_display_item "Timing" read_latency PARAMETER add_display_item "Sounds" speaker_image_id ICON speaker.jpg
7.10.1.3. add_parameter
Description
This command adds a new parameter to this toolkit.Usage
add_parameter <name> <type> [<value> <description>]ReturnType
NothingReturns
no return valueArguments
- name
- Parameter name
- type
- Parameter type
- value (optional)
- Parameter default value
- description (optional)
- Parameter description
Example
add_parameter myparam INTEGER 1
7.10.1.4. add_requirement
Description
Define a requirement of a specific type.Usage
add_requirement <req-id> <req-type>ReturnType
NothingReturns
no return valueArguments
- req-id
- Requirement ID which is a string of alpha-numerical characters.
- req-type
- Requirement type
Example
add_requirement req1 SYSTEM
7.10.1.5. add_timed_callback
Description
Used to add a callback procedure that is called at a fixed timed interval (in milliseconds). Interval has an allowed range of 500 - 60000. These callbacks execute sequentially, and when added, are scheduled to execute at the next available time slot.Usage
add_timed_callback <proc> <interval>ReturnType
NothingReturns
no return valueArguments
- proc
- The name of the callback tcl proc that will be called when the timed callback triggers.
- interval
- The length of time between callback triggers. This time is in milliseconds.
Example
add_timed_callback my_timed_callback 500
7.10.1.6. get_accessible_module
Description
Retrieve the IP targeted by the specified requirement. There is always only one such IP. Nothing is returned if the requirement is not an IP or OPTIONAL_IP requirement. To retrieve IP(s) that matches under a SYSTEM requirement, see get_accessible_modules.Usage
get_accessible_module [-hpath <hpath>] [-module_name <module-name>] [-version <version>] <req-id>ReturnType
StringReturns
Module pathArguments
- hpath (optional)
- Full hierarchy path of the IP
- module-name (optional)
- Module name (a.k.a. entity name) of the IP
- version (optional)
- IP version
- req-id
- Requirement ID
Example
get_accessible_module req1
7.10.1.7. get_accessible_modules
Description
For IP/OPTIONAL_IP requirement, retrieve the only IP targeted by the specified requirement. For SYSTEM requirement, retrieve the IPs that match IPS/OPTIONAL_IPS sub-requirement.Usage
get_accessible_modules [-hpath <hpath>] [-module_name <module-name>] [-version <version>] <req-id>ReturnType
String[]Returns
A list of module pathsArguments
- hpath (optional)
- Full hierarchy path of the IP
- module-name (optional)
- Module name (a.k.a. entity name) of the IP
- version (optional)
- IP version
- req-id
- Requirement ID
Example
get_accessible_modules req1
7.10.1.8. get_accessible_service
Description
Retrieve the service targeted by the specified requirement. There is always only one such service. Nothing is returned if the requirement is not a SERVICE requirement. To retrieve service(s) that matches under a SYSTEM/IP/OPTIONAL_IP requirement or IPS/OPTIONAL_IPS sub-requirement, see get_accessible_services.Usage
get_accessible_service [-hpath <hpath>] [-type <type>] [-agent_type_name <agent-type-name>] <req-id>ReturnType
StringReturns
Service pathArguments
- hpath (optional)
- Full hierarchy path of the service
- type (optional)
- Service type (e.g. master, slave, etile)
- agent-type-name (optional)
- Debug agent type name
- req-id
- Requirement ID
Example
get_accessible_service req1
7.10.1.9. get_accessible_services
Description
For SERVICE requirement, retrieve the only service targeted by the specified requirement. For IP/OPTIONAL_IP requirement, retrieve the services that match the SERVICES/OPTIONAL_SERVICES sub-requirement. For SYSTEM requirement, retrieve the services that match the SERVICES/OPTIONAL_SERVICES sub-requirement or SERVICES/OPTIONAL_SERVICES sub-sub-requirement under the IPS/OPTIONAL_IPS sub-requirement.Usage
get_accessible_services [-hpath <hpath>] [-type <type>] [-agent_type_name <agent-type-name>] <req-id>ReturnType
String[]Returns
A list of service pathsArguments
- hpath (optional)
- Full hierarchy path of the service
- type (optional)
- Service type(e.g. master, slave, etile)
- agent-type-name (optional)
- Debug agent type name
- req-id
- Requirement ID
Example
get_accessible_services req1
7.10.1.10. get_accessible_system
Description
Retrieve the system targeted by the specified requirement. There is always only one such system. Nothing is returned if the requirement is not a SYSTEM requirement.Usage
get_accessible_system [-hpath <hpath>] [-design_id <design-id>] <req-id>ReturnType
StringReturns
System pathArguments
- hpath (optional)
- Full hierarchy path of the system.
- design-id (optional)
- Design ID of the system
- req-id
- Requirement ID
Example
get_accessible_system req1
7.10.1.11. get_channel_display_group
Description
This command returns the associated display group for a given channel's display area.Usage
get_channel_display_group <channel>ReturnType
StringReturns
Associated channel display group name.Arguments
- channel
- The name of the targeted display group.
Example
set my_chan_display_group [ get_channel_display_group "Channel 0" ]
7.10.1.12. get_channel_property
Description
Retrieves a property of the channel.Usage
get_channel_property <channel-name> <property>ReturnType
variousReturns
The channel property matching the specified channel property type.Arguments
- channel-name
- The name of the channel.
- property
- The name of the channel property.
Example
get_channel_property "Channel_0" SUPPORTS_EYE
7.10.1.13. get_display_hint
Description
Retrieve the value of a display hint from a specified display item.Usage
get_display_hint <id> <display-hint>ReturnType
StringReturns
Returns the value of the display hint.Arguments
- id
- ID of the display hint's display item.
- display-hint
- Name of the display hint.
Example
set file_loc [ get_display_hint my_disp_item FILE ]
7.10.1.14. get_display_item_property
Description
Retrieves a property of a display item.Usage
get_display_item_property <id> <display-item-property>ReturnType
variousReturns
Returns the value of the display item's property.Arguments
- id
- ID of the property' display item.
- display-item-property
- The name of the property.
Example
set my_label [get_display_item_property my_action DISPLAY_NAME]
7.10.1.15. get_eye_viewer_display_group
Description
This command returns the associated display group for a given channel's eye viewer display area.Usage
get_eye_viewer_display_group <channel>ReturnType
StringReturns
Associated eye view display group name.Arguments
- channel
- The name of the targeted channel.
Example
set my_eye_display_group [ get_eye_viewer_display_group "Channel 0" ]
7.10.1.16. get_parameter_property
Description
This command returns the property value of a specific parameter.Usage
get_parameter_property <name> <property>ReturnType
variousReturns
The value of the property.Arguments
- name
- Parameter name
- property
- Parameter type
Example
set param_default [ get_parameter_property myparam DEFAULT_VALUE ]
7.10.1.17. get_parameter_value
Description
This command returns the current value of a parameter definedpreviously with the add_parameter command.Usage
get_parameter_value <name>ReturnType
StringReturns
The value of the parameter.Arguments
- name
- Parameter name
Example
set myvar [ get_parameter_value myparam ]
7.10.1.18. get_toolkit_property
Description
This command retrieves the value of a single toolkit property.Usage
get_toolkit_property <prop>ReturnType
StringReturns
Toolkit property value.Arguments
- prop
- Name of the toolkit property that will be retrieved.
Example
set tk_display_name [ get_toolkit_property DISPLAY_NAME ]
7.10.1.19. remove_timed_callback
Description
This command removes previously added timed callbacks. The removal of these timed callbacks removes them from being scheduled.Usage
remove_timed_callback <proc>ReturnType
NothingReturns
no return valueArguments
- proc
- The name of the previously added Tcl callback procedure.
Example
add_timed_callback my_timed_callback 500 remove_timed_callback my_timed_callback
7.10.1.20. send_message
Description
Send a message that will be displayed in the message window.Usage
send_message <level> <message>ReturnType
NothingReturns
no return valueArguments
- level
- The following message levels are supported: * ERROR: Provides an error message * WARNING: Provides a warning message * INFO: Provides an informational message * DEBUG: Provides a debug message when debug mode is enabled
- message
- The string that will be displayed by the message window.
Example
send_message ERROR "The system is down!"
7.10.1.21. set_channel_property
Description
This command sets a channel's property.Usage
set_channel_property <channel-name> <property> <property-value>ReturnType
NothingReturns
no return valueArguments
- channel-name
- The name of the channel.
- property
- The property of the channel that will be changed.
- property-value
- New value of the property.
Example
set_channel_property "Channel 0" SUPPORTS_EYE true
7.10.1.22. set_current_progress
Description
This command is used to set the current progress bar value. By default, this value is set to 0 for 0%.Usage
set_current_progress <progress>ReturnType
NothingReturns
no return valueArguments
- progress
- The new value of the progress bar.
Example
set_current_progress 0 set prog_max 100 for {set curr_prog 1} {$curr_prog <= $prog_max} {incr curr_prog 10} { after 250; # perfom some action ... # update current progress after action completes set_current_progress $curr_prog }
7.10.1.23. set_display_hint
Description
This command configures a display hint value for a specified display item.Usage
set_display_hint <id> <display-hint> <value>ReturnType
NothingReturns
no return valueArguments
- id
- ID of the display hint's display item.
- display-hint
- Name of the display hint.
- value
- The new display hint value.
Example
set_display_hint blocking_action NON_BLOCKING false
7.10.1.24. set_display_item_property
Description
Set a property of a display itemUsage
set_display_item_property <id> <display-property> <display-property-value>ReturnType
NothingReturns
no return valueArguments
- id
- ID of the display item that will have a property set.
- display-property
- The property of the display item that will be set.
- display-property-value
- The new value of the display item property.
Example
set_display_item_property my_action DISPLAY_NAME "Click Me"
7.10.1.25. set_eye_data
Description
This command sets the eye data to plot in the eye viewer's heat map graph diagram.Usage
set_eye_data <rows>ReturnType
NothingReturns
no return valueArguments
- rows
- Eye data expressed as a list of lists. Each inner list corresponds to a displayed row in the heat map. The number of elements inside each inner list define the number of columns in the map. The value of these elements define the color intensity of each cell in the heat map.
Example
# The following example draws a dummy eye set eye_data_str {} lappend eye_data_str [list 1 1 1 1 1 1 1 1 1 1 ] lappend eye_data_str [list 1 0.9 0.03 0.004 0.0002 0.0002 0.004 0.03 0.9 1 ] lappend eye_data_str [list 1 0.05 0.0003 0.000004 0.00000002 0.00000002 0.000004 0.0003 0.05 1 ] lappend eye_data_str [list 1 0.0005 0.000003 0.00000002 0 0 0.00000002 0.000003 0.0005 1 ] lappend eye_data_str [list 1 0.05 0.0003 0.000004 0.00000002 0.00000002 0.000004 0.0003 0.9 1 ] lappend eye_data_str [list 1 0.9 0.03 0.004 0.0002 0.0002 0.004 0.03 0.9 1 ] lappend eye_data_str [list 1 1 1 1 1 1 1 1 1 1 ] set_eye_data $eye_data_str
7.10.1.26. set_eye_property
Description
This command sets a single property that controls the eye viewer layout.Usage
set_eye_property <property> <value>ReturnType
NothingReturns
no return valueArguments
- property
- The name of the eye property.
- value
- The new value of the property.
Example
set_eye_property x_step 2