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.

• For information about setting up a Nios^® II system with the System Console to perform remote debugging, refer to Application Note 624
• For information about setting up an Intel FPGA SoC to perform remote debugging with the Intel^® Quartus^® Prime SLD tools, refer to Application Note 693.

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.

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 Signal Tap logic analyzer allows you to debug static or PR regions of a 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 JTAG Avalon Master Bridge.

To facilitate the debugging process, you can save the captured data in device memory for later analysis. You can also filter data that is not relevant for debug by defining custom trigger-condition logic. The Signal Tap logic analyzer supports the highest number of channels, largest sample depth, and fastest clock speeds of any logic analyzer in the programmable logic market.

The Signal Tap logic analyzer is available as a stand-alone package or with a software subscription.

• Signal Tap logic analyzer

  The following software includes the Signal Tap logic analyzer:

  • Intel^® Quartus^® Prime Design Software
  • Intel^® Quartus^® Prime Lite Edition

  Alternatively, use the Signal Tap logic analyzer standalone software and standalone Programmer software.

• Download/upload cable
• Intel^® development kit or your design board with JTAG connection to device under test

During data acquisition, the memory blocks in the device store the captured data, and then transfer the data to the logic analyzer over a JTAG communication cable, such as Intel^® FPGA Ethernet Cable or Intel^® FPGA Download Cable.

If you have a Intel^® Quartus^® Prime project file from a previous version of the software, you may have to update the .stp configuration file to recompile the project. You can update the configuration file by opening the Signal Tap logic analyzer. If you need to update your configuration, a prompt appears asking if you want to update the .stp to match the current version of the Intel^® Quartus^® Prime software.

To use the Signal Tap logic analyzer to debug your design, you perform a number of tasks to add, configure, and run the logic analyzer.

After you add the Signal Tap logic analyzer to your design, configure the logic analyzer to monitor the signals you want.

You can add signals manually or use a plug-in, such as the Nios^® II processor plug-in, to add entire sets of associated signals for a particular IP.

Specify settings for the data capture buffer, such as its size, the method in which the Signal Tap logic analyzer captures and stores the data. If your device supports memory type selection, you can specify the memory type to use for the buffer.

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. Power-Up Triggers allow you to capture data from trigger events occurring immediately after the device enters user-mode after configuration.

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

You can use any signal in your design as the acquisition clock. However, for best results in data acquisition, use a global, non-gated clock that is synchronous to the signals under test. Using a gated clock as your acquisition clock can result in unexpected data that does not accurately reflect the behavior of your design. The Intel^® Quartus^® Prime static timing analysis tools show the maximum acquisition clock frequency at which you can run your design. To find the maximum frequency of the logic analyzer clock, refer to the Timing Analysis section of the Compilation Report.

If you do not assign an acquisition clock in the Signal Tap Logic Analyzer Editor, Intel^® Quartus^® Prime software automatically creates a clock pin called auto_stp_external_clk. You must make a pin assignment to this pin, and make sure that a clock signal in your design drives the acquisition clock.

• Pre-synthesis—These signals exist after design elaboration, but before any synthesis optimizations are done. This set of signals must reflect your Register Transfer Level (RTL) signals.
• Post-fitting—These signals exist after physical synthesis optimizations and place-and-route.

Intel^® Quartus^® Prime software does not limit 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 tap signals if a routing resource (row or column interconnects) exists to route the connection to the Signal Tap instance. For example, you cannot tap 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 tap the signal that is driving a logic array block (LAB) from an IOE, or, for output pins, you can tap the signal from the LAB that is driving an IOE.

When you add pre-synthesis signals, 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 tap post-fit signals, you are connecting to actual atoms in the post-fit netlist. You can only tap signals that exist in the post-fit netlist, and existing routing resources must be available.

In the case of post-fit output signals, tap 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 Intel^® Quartus^® Prime software optimizes the RTL signals during synthesis and place-and-route. RTL signal names may not appear in the post-fit netlist after optimizations.

The optimization attributes are:

• keep—Prevents removal of combinational signals during optimization.
• preserve—Prevents removal of registers during optimization.

However, preserving attributes can increase device resource utilization or decrease timing performance.

Preserving nodes is often necessary when you add groups of signals for an IP with a plug-in. If you are debugging an encrypted IP core, such as the Nios^® II CPU, you might need to preserve nodes from the core to keep available for debugging with the Signal Tap logic analyzer.

To prevent a signal from triggering the analysis, disable the signal's Trigger Enable option in the .stp file. This option is useful when you only want to see the signal's captured data.

You can turn off the ability to view data for a signal by disabling the Data Enable column in the .stp file. This option is useful when you want to trigger on a signal, but have no interest in viewing that signal's data.

You cannot tap any of the following signal types:

• Post-fit output pins—You cannot tap a post-fit output pin directly. To make an output signal visible, tap the register or buffer that drives the output pin. This includes pins defined as bidirectional.
• Signals that are part of a carry chain—You cannot tap 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 tap the JTAG control (TCK, TDI, TDO, and TMS) signals.
• ALTGXB IP core—You cannot directly tap any ports of an ALTGXB instantiation.
• LVDS—You cannot tap the data output from a serializer/deserializer (SERDES) block.
• DQ, DQS Signals—You cannot directly tap the DQ or DQS signals in a DDR/DDRII design.

RAM selection allows you to preserve a specific memory block for your design, and allocate another portion of memory for Signal Tap logic analyzer 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, you can use MLAB blocks for data acquisition and leave M20k blocks for the rest of your design.

To specify the RAM type to use for the Signal Tap logic analyzer buffer, go to the Signal Configuration pane in the Signal Tap window, and select one Ram type from the drop-down menu.

Use this feature only when the acquired data is smaller than the available memory of the RAM type that you selected. The amount of data appears in the Signal Tap resource estimator.

There are two types of acquisition buffer within the Signal Tap logic analyzer—a non-segmented (or circular) buffer and a segmented buffer.

• With a non-segmented buffer, the Signal Tap logic analyzer treats entire memory space as a single FIFO, continuously filling the buffer until the logic analyzer reaches a defined set of trigger conditions.
• With a 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. Refer to Specify Trigger Position for more details.

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

The Signal Tap logic analyzer offers a snapshot in time of the data stored in the acquisition buffers. 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 21. 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.

If you are creating a Signal Tap logic analyzer instance through an .stp file, specify the storage qualifier signal using the input port field located on the Setup tab. You must specify this port for your project to compile.

If you use the IP parameter editor, the storage qualification input port, if specified, appears in the generated instantiation template. You can then connect this port to a signal in your RTL. If you enable the input port storage qualifier, it accepts a signal and predicates when signals are recorded into the acquisition buffer before or after the specified trigger condition has occurred. 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 used as 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.

You can debug different blocks in your design by grouping related monitoring signals. Likewise, 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.

Signal Tap logic analyzer allows you to save debug configurations in more than one .stp file. Alternatively, you can embed multiple configurations within the same .stp file, and use the Data Log as a managing tool.

• 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 4.  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 Signal Tap logic analyzer triggered, and the time elapsed from start acquisition to trigger activation. You can rename entries so they make sense to you.

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.

Simple Data Log

On this example, the Data Log displays one instance with three signal set configurations.

The SOF Manager is in the JTAG Chain Configuration pane.

With the SOF Manager you can embed multiple SOFs into one .stp file. This action lets you move the .stp file to a different location, either on the same computer or across a network, without including the associated .sof separately. To embed 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.

• Don’t Care
• Low
• High
• Falling Edge
• Rising Edge
• 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.

Open the Advanced Trigger tab by selecting Advanced in the Trigger Conditions drop-down menu.

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.

• 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 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 within the flow 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 51. State-Based Triggering Flow Tab

The State-Based Trigger Flow tab contains three panes:

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 52. Allow Trigger Conditions Change Only
2. Modify the Trigger Flow conditions.

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 the Logic Analyzer evaluates when a state is reached, you 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>

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.
  Note: In the case of segment_trigger, acquisition of the current buffer stops immediately if a subsequent triggering action is issued in the next state, regardless of the current buffer's post-fill count. The logic analyzer discards the remaining unfilled post-count acquisitions in the current buffer, and displays them as grayed-out samples in the data window.

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 is fully powered 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.

Intel^® Quartus^® Prime Pro Edition software supports Incremental Route with Rapid Recompile for Intel^® Arria^® 10, Intel^® Cyclone^® 10 GX, and Intel^® Stratix^® 10 device families.

• Basic AND (which applies to Storage Qualifier as well as trigger input) is the fastest for the Incremental Route flow.
• Basic OR is slower for the Incremental Route flow, but if you avoid changing the parent-child relationship of nodes within groups, you can minimize the impact on compile time. You can change the sibling relationships of nodes.
  • Basic OR and advanced triggers require re-synthesis when you change the number/names of tapped nodes.
• Use the Incremental Route lock-mode to avoid inadvertent changes requiring a full compilation.

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.

After you add the Signal Tap Logic Analyzer to your project and re-compile, you can configure the FPGA target device.

If you want to debug multiple designs simultaneously, configure the device from the .stp instead of the Intel^® Quartus^® Prime Programmer. This allows you to open more than one .stp file and program multiple devices.

You can also perform the equivalent of a force trigger instruction that lets you view the captured data currently in the buffer without a trigger event occurring.

The flowchart shows how you operate the Signal Tap logic analyzer. Indicates where Power-Up and Runtime Trigger events occur and when captured data from these events is available for analysis.

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.

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 analysis is set to Auto-run mode, the logic analyzer creates a separate entry in the Data Log to store the data captured each time the trigger occurred. This allows you to review the captured data for each trigger event.

The default name for a log is based time stamp when the logic analyzer acquired 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, on the File menu, click Export and 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.

The .stp 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 .stp list file in the Intel^® Quartus^® Prime software, click File > Create/Update > Create Signal Tap List File.

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 IP in the static region.
2. Instantiate the SLD JTAG Bridge Host 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.

The debug bridge requires instantiation of 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.

You can install a stand-alone version of the Signal Tap Logic Analyzer. This version is particularly useful in a lab environment in which you do not have a workstation that meets the requirements for a complete Intel^® Quartus^® Prime installation, or if you do not have a license for a full installation of the Intel^® Quartus^® Prime software. The standalone version of the Signal Tap Logic Analyzer is included with and requires the Intel^® Quartus^® Prime stand-alone Programmer which is available from the Downloads page of the Intel website.

To perform a remote debugging session, you must have the following setup:

• The Intel^® Quartus^® Prime software installed on the local PC
• Stand-alone Signal Tap Logic Analyzer or the full version of the Intel^® Quartus^® Prime software installed on the remote PC
• Programming hardware connected to the device on the PCB at the remote location
• TCP/IP protocol connection

1. On the PC in the remote location, install the standalone version of the Signal Tap logic analyzer, included in the Intel^® Quartus^® Prime stand-alone Programmer, or the full version of the Intel^® Quartus^® Prime software.
2. Connect the remote computer to Intel programming hardware, such as the Intel^® FPGA Ethernet Cable or Intel^® FPGA Download Cable.
3. On the local PC, install the full version of the Intel^® Quartus^® Prime software.
4. Connect the local PC to the remote PC across a LAN with the TCP/IP protocol.

Intel FPGA recommends that you use an unencrypted bitstream during the prototype and debugging phases of the design. Using an unencrypted bitstream allows you to generate new programming files and reconfigure the device over the JTAG connection during the debugging cycle.

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 the FPGA is configured with a Signal Tap Logic Analyzer instance in the design, when you open the Signal Tap Logic Analyzer in the Intel^® Quartus^® Prime software, you then scan the chain and are ready to acquire data with the JTAG connection.

You can see resource usage (by instance and total) in the columns of the Instance Manager pane of the Signal Tap logic analyzer Editor. Use this feature when you know that your design is running low on resources.

The logic element value that the resource usage estimator reports may vary by as much as 10% from the actual resource usage.

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

• Bring up boards with both finalized and partially complete designs.
• Perform remote debug with internet access.
• Automate run-time verification through scripting across multiple devices in your system.
• Test serial links with point-and-click configuration tuning in the Transceiver Toolkit.
• Debug memory interfaces with the External Memory Interface Toolkit.
• Integrate your debug IP into the debug platform.
• Perform system verification with MATLAB*/Simulink.

To debug a design with the System Console, you must perform a series of steps:

1. Add an IP Core to the Platform Designer system.
2. Generate the Platform Designer system.
3. Compile the design.
4. Connect a board and program the FPGA.
5. Start the System Console.
6. Locate and open a System Console service.
7. Perform debug operations with the service.
8. Close the service.

You instantiate debug IP cores using the Platform Designer IP Catalog. 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 use IP cores with embedded debug in your design, you can make large portions of the design accessible. 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 needed. 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) provides the System Console with channel communication information. When System Console opens in the Intel^® Quartus^® Prime software or Platform Designer while your design is open, any existing .sof is automatically found and linked to the detected running device. In a complex system, you may need to link the design and device manually.