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.

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:

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.

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.

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.

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.

For information about setting up a Nios^® II system with the System Console to perform remote debugging, refer to Application Note 624.

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.

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.

Refer to the following for more information about launching and using the available debugging toolkits:

• Launching a Toolkit in System Console
• Available System Debugging Toolkits

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> .

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.

• 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.

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:

• Step 1: Add the Signal Tap Logic Analyzer to the Project
• Step 2: Configure the Signal Tap Logic Analyzer
• Step 3: Compile the Design and Signal Tap Instances
• Step 4: Program the Target Hardware
• Step 5: Run the Signal Tap Logic Analyzer
• Step 6: Analyze Signal Tap Captured Data

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:

• Specifying the Clock, Sample Depth, and RAM Type
• Specifying the Buffer Acquisition Mode
• Adding Signals to the Signal Tap Logic Analyzer
• Defining Trigger Conditions
• Specifying Pipeline Settings
• Filtering Relevant Samples
• Managing Multiple Signal Tap Configurations

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.

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.

To add one or more signals to Signal Tap for monitoring:

1. 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.
2. 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.
3. Click Insert. The nodes are added to the Setup tab signal list in the Signal Tap logic analyzer GUI.
4. 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.

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.

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.

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.

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.

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.

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.

The Custom Trigger HDL object appears in the Object Library pane of the Advanced Trigger editor.

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.

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.

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.

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.

• 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.

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.

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.

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.

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.

Figure 47. State-Based Triggering Flow Tab

The State-Based Trigger Flow tab contains three panes:

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.

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.

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.

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:

state <state_label>:
	<action_list>
	if (<boolean_expression>)
		<action_list>
	[else if (<boolean_expression>)
		<action_list>]
	[else
		<action_list>]

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.

<identifier> > <numerical_value>

<identifier> >= <numerical_value>

<identifier> == <numerical_value>

<identifier> != <numerical_value>

<identifier> <= <numerical_value>

<identifier> < <numerical_value>

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.

1. On the Setup tab, point to Lock mode and select Allow trigger condition changes only.
   Figure 49. Allow Trigger Conditions Change Only
2. Modify the Trigger Flow conditions.

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.

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.

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

Figure 51. Storage Qualifier Settings

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.

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).

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.

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.

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.

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.

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.

1. 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
2. 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.

• 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.

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.

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

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.

• 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.

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.

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.

• 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.

Table 17.  Data Log Items

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.

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.

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.

In the base revision, for each PR region that you want to debug in the design:

1. Instantiate the SLD JTAG Bridge Agent Intel^® FPGA IP in the static region.
2. 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.

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.

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.

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.

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.

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.

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.

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.

Perform a full compilation of the design. You can use Intel^® Quartus^® Prime software, a command line executable, or a Tcl command.

execute_flow -compile

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.

# Run the fitter with --recompile to preserve timing
# and quickly connect the Signal Probe pins
execute_module -tool fit -args {--recompile}   

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.

• 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

• 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

1. Configuration and control of the LAI using a computer loaded with the Intel^® Quartus^® Prime software via the JTAG port.
2. Configuration and control of the LAI using a third-party vendor logic analyzer via the JTAG port. Support varies by vendor.

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.

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.

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.

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.

• Intel^® Quartus^® Prime software

or

• Intel^® Quartus^® Prime Lite Edition
• Download Cable (USB-Blaster^TM download cable or ByteBlaster^TM 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

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.

• 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.

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.

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.

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.

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.

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.

• 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.

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.