Virtual JTAG Intel FPGA IP Core User Guide
Version Information
Updated for: |
---|
Intel® Quartus® Prime Design Suite 20.3 |
Virtual JTAG Intel FPGA IP Core User Guide
Introduction
The Virtual JTAG Intel® FPGA IP core allows you to create your own software solution for monitoring, updating, and debugging designs through the JTAG port without using I/O pins on the device, and is one feature in the On‑Chip Debugging Tool Suite. The Intel® Quartus® Prime software or JTAG control host identifies each instance of this IP core by a unique index. Each IP core instance functions in a flow that resembles the JTAG operation of a device. The logic that uses this interface must maintain the continuity of the JTAG chain on behalf the PLD device when this instance becomes active.
With the Virtual JTAG Intel® FPGA IP core you can build your design for efficient, fast, and productive debugging solutions. Debugging solutions can be part of an evaluation test where you use other logic analyzers to debug your design, or as part of a production test where you do not have a host running an embedded logic analyzer. In addition to debugging features, you can use the Virtual JTAG Intel® FPGA IP core to provide a single channel or multiple serial channels through the JTAG port of the device. You can use serial channels in applications to capture data or to force data to various parts of your logic.
Each feature in the On‑Chip Debugging Tool Suite leverages on-chip resources to achieve real time visibility to the logic under test. During runtime, each tool shares the JTAG connection to transmit collected test data to the Intel® Quartus® Prime software for analysis. The tool set consists of a set of GUIs, IP core intellectual property (IP) cores, and Tcl application programming interfaces (APIs). The GUIs provide the configuration of test signals and the visualization of data captured during debugging. The Tcl scripting interface provides automation during runtime.
The Virtual JTAG Intel® FPGA IP core provides you direct access to the JTAG control signals routed to the FPGA core logic, which gives you a fine granularity of control over the JTAG resource and opens up the JTAG resource as a general‑purpose serial communication interface. A complete Tcl API is available for sending and receiving transactions into your device during runtime. Because the JTAG pins are readily accessible during runtime, this IP core enables an easy way to customize a JTAG scan chain internal to the device, which you can then use to create debugging applications.
Examples of debugging applications include induced trigger conditions evaluated by a Signal Tap logic analyzer by exercising test signals connected to the analyzer instance, a replacement for a front panel interface during the prototyping phase of the design, or inserted test vectors for exercising the design under test.
The infrastructure is an extension of the JTAG protocol for use with Intel® ‑specific applications and user applications, such as the Signal Tap logic analyzer.
Installing and Licensing Intel FPGA IP Cores
The Intel® Quartus® Prime software installs IP cores in the following locations by default:
Location | Software | Platform |
---|---|---|
<drive>:\intelFPGA_pro\quartus\ip\altera | Intel® Quartus® Prime Pro Edition | Windows* |
<drive>:\intelFPGA\quartus\ip\altera | Intel® Quartus® Prime Standard Edition | Windows |
<home directory>:/intelFPGA_pro/quartus/ip/altera | Intel® Quartus® Prime Pro Edition | Linux* |
<home directory>:/intelFPGA/quartus/ip/altera | Intel® Quartus® Prime Standard Edition | Linux |
On-Chip Debugging Tool Suite
Tool |
Description |
Typical Circumstances for Use |
---|---|---|
Signal Tap Logic Analyzer |
Uses FPGA resources to sample tests nodes and outputs the information to the Intel® Quartus® Prime software for display and analysis. |
You have spare on-chip memory and want functional verification of your design running in hardware. |
Signal Probe |
Incrementally routes internal signals to I/O pins while preserving the results from your last place-and-route. |
You have spare I/O pins and want to check the operation of a small set of control pins using either an external logic analyzer or an oscilloscope. |
Logic Analyzer Interface (LAI) |
Multiplexes a larger set of signals to a smaller number of spare I/O pins. LAI allows you to select which signals are switched onto the I/O pins over a JTAG connection. |
You have limited on-chip memory and have a large set of internal data buses that you want to verify using an external logic analyzer. Logic analyzer vendors, such as Tektronics and Agilent, provide integration with the tool to improve usability. |
In-System Memory Content Editor |
Displays and allows you to edit on‑chip memory. |
You want to view and edit the contents of either the instruction cache or data cache of a Nios® II processor application. |
In-System Sources and Probes |
Provides a way to drive and sample logic values to and from internal nodes using the JTAG interface. |
You want to prototype a front panel with virtual buttons for your FPGA design. |
Virtual JTAG Interface |
Opens the JTAG interface so that you can develop your own custom applications. |
You want to generate a large set of test vectors and send them to your device over the JTAG port to functionally verify your design running in hardware. |
Applications of the Virtual JTAG Intel FPGA IP Core
The hub automatically arbitrates between multiple applications that share a single JTAG resource. Therefore, you can use the IP core in tandem with other on‑chip debugging applications, such as the Signal Tap logic analyzer, to increase debugging visibility. You can also use the IP core to provide simple stimulus patterns to solicit a response from the design under test during run‑time, including the following applications:
- To diagnose, sample, and update the values of internal parts of your logic. With this IP core, you can easily sample and update the values of the internal counters and state machines in your hardware device.
- To build your own custom software debugging IP using the Tcl commands to debug your hardware. This IP communicates with the instances of the Virtual JTAG Intel® FPGA IP core inside your design.
- To construct your design to achieve virtual inputs and outputs.
- If you are building a debugging solution for a system in which a microprocessor controls the JTAG chain, you cannot use the Signal Tap logic analyzer because the JTAG control must be with the microprocessor. You can use low‑level controls for the JTAG port from the Tcl commands to direct microprocessors to communicate with the Virtual JTAG Intel® FPGA IP core inside the device core.
JTAG Protocol
During boundary scan testing, software shifts out test data over the serial interface to the BSCs of select ICs. This test data forces a known pattern to the pins connected to the affected BSCs. If the adjacent IC at the other end of the PCB trace is JTAG‑compliant, the BSC of the adjacent IC samples the test pattern and feeds the BSCs back to the software for analysis. The figure below illustrates the boundary-scan testing concept.
Because the JTAG interface shifts in any information to the device, leaves a low footprint, and is available on all Intel® devices, it is considered a general purpose communication interface. In addition to boundary scan applications, Intel® devices use the JTAG port for other applications, such as device configuration and on‑chip debugging features available in the Intel® Quartus® Prime software.
JTAG Circuitry Architecture
The basic architecture of the JTAG circuitry consists of the following components:
- A set of Data Registers (DRs)
- An Instruction Register (IR)
- A state machine to arbitrate data (known as the Test Access Port (TAP) controller)
- A four- or five‑pin serial
interface, consisting of the following pins:
- Test data in (TDI), used to shift data into the IR and DR shift register chains
- Test data out (TDO), used to shift data out of the IR and DR shift register chains
- Test mode select (TMS), used as an input into the TAP controller
- TCK, used as the clock source for the JTAG circuitry
- TRST resets the TAP controller. This is an optional input pin defined by the 1149.1 standard.
The bank of DRs is the primary data path of the JTAG circuitry. It carries the payload data for all JTAG transactions. Each DR chain is dedicated to serving a specific function. Boundary scan cells form the primary DR chain. The other DR chains are used for identification, bypassing the IC during boundary scan tests, or a custom set of register chains with functions defined by the IC vendor. Intel uses two of the DR chains with user‑defined IP that requires the JTAG chain as a communication resource, such as the on‑chip debugging applications. The Virtual JTAG Intel® FPGA IP core, in particular, allows you to extend the two DR chains to a user‑defined custom application.
You use the instruction register to select the bank of Data Registers to which the TDI and TDO must connect. It functions as an address register for the bank of Data Registers. Each IR instruction maps to a specific DR chain.
All shift registers that are a part of the JTAG circuitry (IR and DR register chains) are composed of two kinds of registers: shift registers, which capture new serial shift input from the TDI pin, and parallel hold registers, which connect to each shift register to hold the current input in place when shifting. The parallel hold registers ensure stability in the output when new data is shifted.
The following figure shows a functional model of the JTAG circuitry. The TRST pin is an optional pin in the 1149.1 standard and not available in Cyclone devices. The TAP controller is a hard controller; it is not created using programmable resources. The major function of the TAP controller is to route test data between the IR and DR register chains.
System-Level Debugging Infrastructure
Because the JTAG resource is shared among multiple on-chip applications, an arbitration scheme must define how the USER0 and USER1 scan chains are allocated between the different applications. The system-level debugging (SLD) infrastructure defines the signaling convention and the arbitration logic for all programmable logic applications using a JTAG resource. The figure below shows the SLD infrastructure architecture.
Transaction Model of the SLD Infrastructure
The SLD infrastructure mimics the IR/DR paradigm defined by the JTAG protocol. Each application implements an Instruction Register, and a set of Data Registers that operate similarly to the Instruction Register and Data Registers in the JTAG standard. Note that the Instruction Register and the Data Register banks implemented by each application are a subset of the USER1 and USER0 Data Register chains. The SLD infrastructure consists of three subsystems: the JTAG TAP controller, the SLD hub, and the SLD nodes.
The SLD hub acts as the arbiter that routes the TDI pin connection between each SLD node, and is a state machine that mirrors the JTAG TAP controller state machine.
The SLD nodes represent the communication channels for the end applications. Each instance of IP requiring a JTAG communication resource, such as the Signal Tap logic analyzer, would have its own communication channel in the form of a SLD node interface to the SLD hub. Each SLD node instance has its own Instruction Register and bank of DR chains. Up to 255 SLD nodes can be instantiated, depending on resources available in your device.
Together, the sld_hub and the SLD nodes form a virtual JTAG scan chain within the JTAG protocol. It is virtual in the sense that both the Instruction Register and DR transactions for each SLD node instance are encapsulated within a standard DR scan shift of the JTAG protocol.
The Instruction Register and Data Registers for the SLD nodes are a subset of the USER1 and USER0 Data Registers. Because the SLD Node IR/DR register set is not directly part of the IR/DR register set of the JTAG protocol, the SLD node Instruction Register and Data Register chains are known as Virtual IR (VIR) and Virtual DR (VDR) chains. The figure below shows the transaction model of the SLD infrastructure.
SLD Hub Finite State Machine
Because all shifts to VIR and VDR are encapsulated within a DR shift transaction, an additional control signal is necessary to select between the VIR and VDR data paths. The SLD hub uses the USER1 command to select the VIR data path and the USER0 command to select the VDR data path.
This state information, including a bank of enable signals, is forwarded to each of the SLD nodes. The SLD nodes perform the updates to the VIR and VDR according to the control states provided by the sld_hub. The SLD nodes are responsible for maintaining continuity between the TDI and TDO pins.
The figure below shows the SLD hub finite state machine. There is no direct state signal available to use for application design.
Virtual JTAG Interface Description
The Virtual JTAG Intel® FPGA IP core provides a port interface that mirrors the actual JTAG ports. The interface contains the JTAG port pins, a one‑hot decoded output of all JTAG states, and a one-hot decoded output of all the virtual JTAG states. Virtual JTAG states are the states decoded from the SLD hub finite state machine. The ir_in and ir_out ports are the parallel input and output to and from the VIR. The VIR ports are used to select the active VDR datapath. The JTAG states and TMS output ports are provided for debugging purposes only. Only the virtual JTAG, TDI, TDO, and the IR signals are functional elements of the IP core. When configuring this IP core using the parameter editor, you can hide TMS and the decoded JTAG states.
The figure below shows the input and output ports of the virtual JTAG Intel® FPGA IP core. The JTAG TAP controller outputs and TMS signals are used for informational purposes only. These signals can be exposed using the Create primitive JTAG state signal ports option in the parameter editor.
Input Ports
Port name | Required | Description | Comments |
---|---|---|---|
tdo | Yes | Writes to the TDO pin on the device. | |
ir_out[] | No | Virtual JTAG instruction register output. The value is captured whenever virtual_state_cir is high. | Input port [SLD_IR_WIDTH-1..0] wide. Specify the width of this bus with the SLD_IR_WIDTH parameter. |
Output Ports
Port Name | Required | Description | Comments |
---|---|---|---|
tck | Yes | JTAG test clock. | Connected directly to the TCK device pin. Shared among all virtual JTAG instances. |
tdi | Yes | TDI input data on the device. Used when virtual_state_sdr is high. | Shared among all virtual JTAG instances. |
ir_in[] | No | Virtual JTAG instruction register data. The value is available and latched when virtual_state_uir is high. | Output port [SLD_IR_WIDTH-1..0] wide. Specify the width of this bus with the SLD_IR_WIDTH parameter. |
Port Name | Required | Description | Comments |
---|---|---|---|
virtual_state_cdr | No |
Indicates that virtual JTAG is in Capture_DR state. |
|
virtual_state_sdr | Yes |
Indicates that virtual JTAG is in Shift_DR state. |
In this state, this instance is required to establish the JTAG chain for this device. |
virtual_state_e1dr | No |
Indicates that virtual JTAG is in Exit1_DR state. |
|
virtual_state pdr | No |
Indicates that virtual JTAG is in Pause_DR state. |
The Intel® Quartus® Prime software does not cycle through this state using the Tcl command. |
virtual_state_e2dr | No |
Indicates that virtual JTAG is in Exit2_DR state. |
The Intel® Quartus® Prime software does not cycle through this state using the Tcl command. |
virtual_state_udr | No |
Indicates that virtual JTAG is in Update_DR state. |
|
virtual_state_cir | No |
Indicates that virtual JTAG is in Capture_IR state. |
|
virtual_state_uir | No |
Indicates that virtual JTAG is in Update_IR state. |
Port Name | Required | Description | Comments |
---|---|---|---|
jtag_state_tlr | No |
Indicates that the device JTAG controller is in the Test_Logic_Reset state. |
Shared among all virtual JTAG instances. |
jtag_state_rti | No |
Indicates that the device JTAG controller is in the Run_Test/Idle state. |
Shared among all virtual JTAG instances. |
jtag_state_sdrs | No |
Indicates that the device JTAG controller is in the Select_DR_Scan state. |
Shared among all virtual JTAG instances. |
jtag_state_cdr | No |
Indicates that the device JTAG controller is in the Capture_DR state. |
Shared among all virtual JTAG instances. |
jtag_state_sdr | No |
Indicates that the device JTAG controller is in the Shift_DR state. |
Shared among all virtual JTAG instances. |
jtag_state_e1dr | No |
Indicates that the device JTAG controller is in the Exit1_DR state. |
Shared among all virtual JTAG instances. |
jtag_state_pdr | No |
Indicates that the device JTAG controller is in the Pause_DR state. |
Shared among all virtual JTAG instances. |
jtag_state_e2dr | No |
Indicates that the device JTAG controller is in the Exit2_DR state. |
Shared among all virtual JTAG instances. |
jtag_state_udr | No |
Indicates that the device JTAG controller is in the Update_DR state. |
Shared among all virtual JTAG instances. |
jtag_state_sirs | No |
Indicates that the device JTAG controller is in the Select_IR_Scan state. |
Shared among all virtual JTAG instances. |
jtag_state_cir | No |
Indicates that the device JTAG controller is in the Capture_IR state. |
Shared among all virtual JTAG instances. |
jtag_state_sir | No |
Indicates that the device JTAG controller is in the Shift_IR state. |
Shared among all virtual JTAG instances. |
jtag_state_e1ir | No |
Indicates that the device JTAG controller is in the Exit1_IR state. |
Shared among all virtual JTAG instances. |
jtag_state_pir | No |
Indicates that the device JTAG controller is in the Pause_IR state. |
Shared among all virtual JTAG instances. |
jtag_state_e2ir | No |
Indicates that the device JTAG controller is in the Exit2_IR state. |
Shared among all virtual JTAG instances. |
jtag_state_uir |
Indicates that the device JTAG controller is in the Update_IR state. |
Shared among all virtual JTAG instances. |
|
tms |
TMS input pin on the device. |
Shared among all virtual JTAG instances. |
Parameters
Parameter | Type | Required | Description |
---|---|---|---|
SLD_AUTO_INSTANCE_INDEX | String | Yes |
Specifies whether the Compiler automatically assigns an index to the Virtual JTAG instance. Values are YES or NO. When you specify NO, you can find the auto assigned value of INSTANCE_ID in the quartus_map file. When you specify NO, you must define INSTANCE_INDEX. If the index specified is not unique in a design, the Compiler automatically reassigns an index to the instance. The default value is YES. |
SLD_INSTANCE_INDEX | Integer | No |
Specifies a unique identifier for every instance of alt_virtual_jtag when AUTO_INSTANCE_ID is specified to YES. Otherwise, this value is ignored. |
SLD_IR_WIDTH | Integer | Yes |
Specifies the width of the instruction register ir_in[] of this virtual JTAG between 1 and 24. If omitted, the default is 1. |
Design Flow of the Virtual JTAG Intel FPGA IP Core
- Configuring the Virtual JTAG Intel® FPGA IP core with the desired Instruction Register length and instantiating the IP core.
- Building the glue logic for interfacing with your application.
- Communicating with the Virtual JTAG instance during runtime.
In addition to the JTAG datapath and control signals, the Virtual JTAG Intel® FPGA IP core encompasses the VIR. The Instruction Register size is configured in the parameter editor. The Instruction Register port on the Virtual JTAG Intel® FPGA IP core is the parallel output of the VIR. Any updated VIR information can be read from this port after the virtual_state_uir signal is asserted.
After instantiating the IP core, you must create the VDR chains that interface with your application. To do this, you use the virtual instruction output to determine which VDR chain is the active datapath, and then create the following:
- Decode logic for the VIR
- VDR chains to which each VIR maps
- Interface logic between your VDR chains and your application logic
Your glue logic uses the decoded one-hot outputs from the IP core to determine when to shift and when to update the VDR. Your application logic interfaces with the VDR chains during any one of the non-shift virtual JTAG states.
For example, your application logic can parallel read an updated value that was shifted in from the JTAG port after the virtual_state_uir signal is asserted. If you load a value to be shifted out of the JTAG port, you would do so when the virtual_state_cdr signal is asserted. Finally, if you enable the shift register to clock out information to TDO, you would do so during the assertion of virtual_state_sdr.
Maintaining TDI‑to‑TDO connectivity is important. Ensure that all possible instruction codes map to an active register chain to maintain connectivity in the TDI‑to‑TDO datapath. Intel recommends including a bypass register as the active register for all unmapped IR values.
Note that TCK (a maximum 10‑MHz clock, if using an Intel® programming cable) provides the clock for the entire SLD infrastructure. Be sure to follow best practices for proper clock domain crossing between the JTAG clock domain and the rest of your application logic to avoid metastability issues. The decoded virtual JTAG state signals can help determine a stable output in the VIR and VDR chains.
After compiling and downloading your design into the device, you can perform shift operations directly to the VIR and VDR chains using the Tcl commands from the quartus_stp executable and an Intel® programming cable (for example, an Intel® FPGA Download Cable, a MasterBlaster™ cable, or an Intel® FPGA Parallel Port Cable). The quartus_stp executable is a command‑line executable that contains Tcl commands for all on‑chip debug features available in the Intel® Quartus® Prime software.
The figure below shows the components of a design containing one instance of the Virtual JTAG Intel® FPGA IP core. The TDI-to-TDO datapath for the virtual JTAG chain, shown in red, consists of a bank of DR registers. Input to the application logic is the parallel output of the VDR chains. Decoded state signals are used to signal start and stop of shift transactions and signals when the VDR output is ready.
The IR_out port, not shown, is an optional input port you can use to parallel load the VIR from the FPGA core logic.
Simulation Model
Run-Time Communication
These commands contain the underlying drivers for accessing an Intel® programming cable and for issuing shift transactions to each VIR and VDR. The table below provides the Tcl commands in the quartus_stp executable that you can use with the Virtual JTAG Intel® FPGA IP core, and are intended for designs that use a custom controller to drive the JTAG chain.
Each instantiation of the Virtual JTAG Intel® FPGA IP core includes an instance index. All instances are sequentially numbered and are automatically provided by the Intel® Quartus® Prime software. The instance index starts at instance index 0. The VIR and VDR shift commands described in the table decode the instance index and provide an address to the SLD hub for each IP core instance. You can override the default index provided by the Intel® Quartus® Prime software during configuration of the IP core.
The table below provides the Tcl commands in the quartus_stp executable that you can use with the Virtual JTAG Intel® FPGA IP core, and are intended for designs that use a custom controller to drive the JTAG chain.
Command |
Arguments |
Description |
---|---|---|
Device virtual ir shift |
-instance_index <instance_index> -ir_value <numeric_ir_value> -no_captured_ir_value 1 -show_equivalent_device_ir_dr_shift 1 |
Perform an IR shift operation to the virtual JTAG instance specified by the instance_index. Note that ir_value takes a numerical argument. |
Device virtual dr shift |
-instance_index <instance_index> -dr_value <dr_value> -length <data_register_length> -no_captured_dr_value 1 -show_equivalent_device_ir_dr_shift -value_in_hex 1 |
Perform a DR shift operation to the virtual JTAG instance. |
Get hardware names |
NONE |
Queries for all available programming cables. |
Open device |
-device_name <device_name> -hardware_name <hardware_name> |
Selects the active device on the JTAG chain. |
Close device |
NONE |
Ends communication with the active JTAG device. |
Device lock |
-timeout <timeout> |
Obtains exclusive communication to the JTAG chain. |
Device unlock |
NONE |
Releases device_lock. |
Device ir shift |
-ir_value <ir_value> -no_captured_ir_value |
Performs a IR shift operation. |
Device dr shift |
-dr_value <dr_value> -length <data register length> -no_captured_dr_value -value_in_hex |
Performs a DR shift operation. |
Central to Virtual JTAG Intel® FPGA IP core are the device_virtual_ir_shift and device_virtual_dr_shift commands. These commands perform the shift operation to each VIR/VDR and provide the address to the SLD hub for the active JTAG datapath.
Each device_virtual_ir_shift command issues a USER1 instruction to the JTAG Instruction Register followed by a DR shift containing the VIR value provided by the ir_value argument prepended by address bits to target the correct SLD node instance.
Use the -no_captured_ir_value argument if you do not care about shifting out the contents of the current VIR value. Enabling this argument increases the speed of the VIR shift transaction by eliminating a command cycle within the underlying transaction.
Similarly, each device_virtual_dr_shift command issues a USER0 instruction to the JTAG Instruction Register followed by a DR shift containing the VDR value provided by the dr_value argument. These commands return the underlying JTAG transactions with the show_equivalent_device_ir_dr_shift option set.
The device_virtual_ir_shift takes the ir_value argument as a numeric value. The device_virtual_dr_shift takes the dr_value argument by either a binary string or a hexadecimal string. Do not use numeric values for the device_virtual_dr_shift.
Running a DR Shift Operation Through a Virtual JTAG Chain
- Query for the Intel® programming cable and select the active cable.
- Target the desired device in the JTAG chain.
- Obtain a device lock for exclusive communication to the device.
- Perform a VIR shift.
- Perform a VDR shift.
- Release exclusive link with the device with the device_unlock command.
- Close communication with the device with the close_device command.
Run-Time Communication
Setting | Description |
---|---|
sld_auto_instance_index | Details whether the index was auto-assigned. |
sld_instance_index | Instance index of the Virtual JTAG Intel® FPGA IP core. Assigned at compile time. |
sld_ir_width | Length of the Virtual IR register for this IP core instance; defined in the parameter editor. |
The Tcl API provides a way to return the JTAG IR/DR transactions by using the show_equivalent_device_ir_dr_shift argument with the device_virtual_ir_shift and device_virtual_dr_shift commands. The following examples use returned values of a virtual IR/DR shift to illustrate the format of the underlying transactions.
To use the Tcl API to query for the bit pattern in your design, use the show_equivalent_device_ir_dr_shift argument with the device_virtual_ir_shift and device_virtual_dr_shift commands.
Both examples are from the same design, with a single Virtual JTAG instance. The VIR length for the reference Virtual JTAG instance is configured to 3 bits in length.
Virtual IR/DR Shift Transaction without Returning Captured IR/DR Values
The Tcl command examples below show a VIR/VDR transaction with the no_captured_value option set. The commands return the underlying JTAG shift transactions that occur.
Virtual IR Shift with the no_captured_value Option |
---|
device_virtual_ir_shift -instance_index 0 -ir_value 1 \ -no_captured_ir_value -show_equivalent_device_ir_dr_shift ↵ |
Returns: Info: Equivalent device ir and dr shift commands Info: device_ir_shift -ir_value 14 Info: device_dr_shift -length 5 -dr_value 11 -value_in_hex |
Virtual DR Shift with the no_captured_value Option |
---|
device_virtual_dr_shift -instance_index 0 -length 8 -dr_value \ 04 -value_in_hex -no_captured_dr_value \ -show_equivalent_device_ir_dr_shift ↵ |
Returns: Info: Equivalent device ir and dr shift commands Info: device_ir_shift -ir_value 12 Info: device_dr_shift -length 8 -dr_value 04 -value_in_hex |
The VIR value field in the figure below is four bits long, even though the VIR length is configured to be three bits long, and shows the bit values and fields associated with the VIR/VDR scans. The Instruction Register length for all Intel® FPGAs and CPLDs is 10-bits long. The USER1 value is 0x0E and USER0 value is 0x0C for all Intel® FPGAs and CPLDs. The Address bits contained in the DR scan shift of a VIR scan are determined by the Intel® Quartus® Prime software.
All USER1 DR chains must be of uniform length. The length of the VIR value field length is determined by length of the longest VIR register for all SLD nodes instantiated in the design. Because the SLD hub VIR is four bits long, the minimum length for the VIR value field for all SLD nodes in the design is at least four bits in length. The Intel® Quartus® Prime Tcl API automatically sizes the shift transaction to the correct length. The length of the VIR register is provided in the Virtual JTAG settings compilation report. If you are driving the JTAG interface with a custom controller, you must pay attention to size of the USER1 DR chain.
Virtual IR/DR Shift Transaction that Captures Current VIR/VDR Values
Virtual IR Shift |
---|
device_virtual_ir_shift -instance_index 0 -ir_value 1 \ -no_captured_ir_value -show_equivalent_device_ir_dr_shift Returns: Info: Equivalent device ir and dr shift commands Info: device_ir_shift -ir_value 14 Info: device_dr_shift –length 5 –dr_value 0B –value_in_hex Info: device_dr_shift -length 5 -dr_value 11 -value_in_hex |
Virtual DR Shift |
---|
device_virtual_dr_shift -instance_index 0 -length 8 -dr_value \ 04 -value_in_hex -show_equivalent_device_ir_dr_shift Returns: Info: Equivalent device ir and dr shift commands Info: device_ir_shift -ir_value 12 Info: device_dr_shift -length 8 -dr_value 04 -value_in_hex |
The figure below shows an example of VIR/VDR Shift Commands with captured IR values. DR Scan Shift 1 is the VIR_CAPTURE command, as shown in the figure below. It targets the VIR of the sld_hub. This command is an address cycle to select the active VIR chain to shift after jtag_state_cir is asserted. The HUB_FORCE_IR capture must be issued whenever you capture the VIR from a target SLD node that is different than the current active node. DR Scan Shift 1 targets the SLD hub VIR to force a captured value from Virtual JTAG instance 1 and is shown as the VIR_CAPTURE command. DR Scan Shift 2 targets the VIR of Virtual JTAG instance.
Reset Considerations when Using a Custom JTAG Controller
This can cause the following two situations in which control states of the SLD hub and the JTAG TAP controller are not in lock-step:
- An assertion of the device wide global reset signal (DEV_CLRn)
- An assertion of the TRST signal, if available on the device
DEV_CLRn resets the SLD hub but does not reset the hard TAP controller block. The TAP controller is meant to be decoupled from USER mode device operation to run boundary scan operations. Asserting the global reset signal does not disrupt boundary‑scan test (BST) operation.
Conversely, the TRST signal, if available, resets the JTAG TAP controller but does not reset the SLD hub. The TRST signal does not route into the core programmable logic of the PLD.
To guarantee that the states of the JTAG TAP controller and the SLD hub state machine are properly synchronized, TMS should be held high for at least five clock cycles after any intentional reset of either the TAP controller or the system logic. Both the JTAG TAP controller and the sld_hub controller are guaranteed to be in the Test Logic Reset state after five clock cycles of TMS held high.
Instantiating the Virtual JTAG Intel FPGA IP Core
- The Intel® Quartus® Prime software
- An Intel® download cable, such as an Intel® FPGA Download Cable cable
The download cable is required to communicate with the Virtual JTAG Intel® FPGA IP core from a host running the quartus_stp executable.
IP Catalog and Parameter Editor
- Filter IP Catalog to Show IP for active device family or Show IP for all device families. If you have no project open, select the Device Family in IP Catalog.
- Type in the Search field to locate any full or partial IP core name in IP Catalog.
- Right-click an IP core name in IP Catalog to display details about supported devices, to open the IP core's installation folder, and for links to IP documentation.
- Click Search for Partner IP to access partner IP information on the web.
The Parameter Editor
- Use the Presets window to apply preset parameter values for specific applications (for select cores).
- Use the Details window to view port and parameter descriptions, and click links to documentation.
- Click Generate > Generate Testbench System to generate a testbench system (for select cores).
- Click Generate > Generate Example Design to generate an example design (for select cores).
The IP Catalog is also available in Platform Designer (View > IP Catalog). The Platform Designer IP Catalog includes exclusive system interconnect, video and image processing, and other system-level IP that are not available in the Intel® Quartus® Prime IP Catalog. Refer to Creating a System with Platform Designer or Creating a System with Platform Designer (Standard) for information on use of IP in Platform Designer (Standard) and Platform Designer, respectively.
Specifying IP Core Parameters and Options
- In the Platform Designer IP Catalog (Tools > IP Catalog), locate and double-click the name of the IP core to customize. The parameter editor appears.
- Specify a top-level name for your custom IP variation. This name identifies the IP core variation files in your project. If prompted, also specify the target FPGA device family and output file HDL preference. Click OK.
-
Specify parameters
and options for your IP variation:
- Optionally select preset parameter values. Presets specify all initial parameter values for specific applications (where provided).
- Specify parameters defining the IP core functionality, port configurations, and device-specific features.
- Specify options for generation of a timing netlist, simulation model, testbench, or example design (where applicable).
- Specify options for processing the IP core files in other EDA tools.
- Click Finish to generate synthesis and other optional files matching your IP variation specifications. The parameter editor generates the top-level .qsys IP variation file and HDL files for synthesis and simulation. Some IP cores also simultaneously generate a testbench or example design for hardware testing.
- To generate a simulation testbench, click Generate > Generate Testbench System. Generate Testbench System is not available for some IP cores that do not provide a simulation testbench.
- To generate a top-level HDL example for hardware verification, click Generate > HDL Example. Generate > HDL Example is not available for some IP cores.
The top-level IP variation is added to the current Intel® Quartus® Prime project. Click Project > Add/Remove Files in Project to manually add a .qsys ( Intel® Quartus® Prime Standard Edition) or .ip ( Intel® Quartus® Prime Pro Edition) file to a project. Make appropriate pin assignments to connect ports.
Files Generated for Intel FPGA IP Cores (Legacy Parameter Editor)
Instantiating Directly in HDL
- The tck output from the Virtual JTAG Intel® FPGA IP core is the clock used for shifting the data in and out on the TDI and TDO pins.
- The TMS output of the Virtual JTAG Intel® FPGA IP core reflects the TMS input to the main JTAG circuit.
- The ir_in output port of the Virtual JTAG Intel® FPGA IP core is the parallel output of the contents that get shifted into the virtual IR of the Virtual JTAG instance. This port is used for decoding logic to select the active virtual DR chain.
The purpose of instantiating a Virtual JTAG instance in this example is to load my_counter through the JTAG port using a software application built with Tcl commands and the quartus_stp executable. In this design, the Virtual JTAG instance is called my_vji. Whenever a Virtual JTAG Intel® FPGA IP core is instantiated in a design, three logic blocks are usually needed: a decode logic block, a TDO logic block, and a Data Register block. The example below combines the Virtual JTAG instance, the decode logic, the TDO logic and the Data Register blocks.
You can use the following Verilog HDL template as a guide for instantiating and connecting various signals of the IP cores in your design.
module counter (clock, my_counter); input clock; output [3:0] my_counter; reg [3:0] my_counter; always @ (posedge clock) if (load && e1dr) // decode logic: used to load the counter my_counter my_counter <= tmp_reg; else my_counter <= my_counter + 1; // Signals and registers declared for VJI instance wire tck, tdi; reg tdo; wire cdr, eldr, e2dr, pdr, sdr, udr, uir, cir; wire [1:0] ir_in; // Instantiation of VJI my_vji VJI_INST( .tdo (tdo), .tck (tck), .tdi (tdi), .tms(), .ir_in(ir_in), .ir_out(), .virtual_state_cdr (cdr), .virtual_state_e1dr(e1dr), .virtual_state_e2dr(e2dr), .virtual_state_pdr (pdr), .virtual_state_sdr (sdr), .virtual_state_udr (udr), .virtual_state_uir (uir), .virtual_state_cir (cir) ); // Declaration of data register reg [3:0] tmp_reg; // Deocde Logic Block // Making some decode logic from ir_in output port of VJI wire load = ir_in[1] && ~ir_in[0]; // Bypass used to maintain the scan chain continuity for // tdi and tdo ports bypass_reg <= tdi; // Data Register Block always @ (posedge tck) if ( load && sdr ) tmp_reg <= {tdi, tmp_reg[3:1]}; // tdo Logic Block always @ (tmp_reg[0] or bypass_reg) if(load) tdo <= tmp_reg[0] else tdo <= bypass_reg; endmodule
The decode logic is produced by defining a wire load to be active high whenever the IR of the Virtual JTAG Intel® FPGA IP core is 01. The IR scan shift is used to load the data into the IR of the Virtual JTAG Intel® FPGA IP core. The ir_in output port reflects the IR contents.
The Data Register logic contains a 4-bit shift register named tmp_reg. The always blocks shown for the Data Register logic also contain the decode logic consisting of the load and sdr signals. The sdr signal is the output of the Virtual JTAG Intel® FPGA IP core that is asserted high during a DR scan shift operation. The time during which the sdr output is asserted high is the time in which the data on tdi is valid. During that time period, the data is shifted into the tmp_reg shift register. Therefore, tmp_reg gets the data from the Virtual JTAG Intel® FPGA IP core on the tdi output port during a DR scan operation.
There is a 1‑bit register named bypass_reg whose output is connected with tdo logic to maintain the continuity of the scan chain during idle or IR scan shift operation of the Virtual JTAG Intel® FPGA IP core. The tdo logic consists of outputs coming from tmp_reg and bypass_reg and connecting to the tdo input of the Virtual JTAG Intel® FPGA IP core. The tdo logic passes the data from tmp_reg to the Virtual JTAG Intel® FPGA IP core during DR scan shift operations.
The always block of a 4-bit counter also consists of some decode logic. This decode logic uses the load signal and e1dr output signal of the Virtual JTAG Intel® FPGA IP core to load the counter with the contents of tmp_reg. The Virtual JTAG output signal e1dr is asserted high during a DR scan shift operation when all the data is completely shifted into the tmp_reg and sdr has been de-asserted. In addition to sdr and e1dr, there are other outputs from the Virtual JTAG Intel® FPGA IP core that are asserted high to show various states of the TAP controller and internal states of the Virtual JTAG Intel® FPGA IP core. All of these signals can be used to perform different logic operations as needed in your design.
Simulation Support
In its implementation, the Virtual JTAG Intel® FPGA IP core connects to your design on one side and to the JTAG port through the JTAG hub on the other side. However, a simulation model connects only to your design. There is no simulation model for the JTAG circuit. Therefore, no stimuli can be provided from the JTAG ports of the device to imitate the scan shift operations of the Virtual JTAG Intel® FPGA IP core in simulation.
The scan operations in simulation are realized using the simulation model. The simulation model consists of a signal generator, a model of the SLD hub, and the Virtual JTAG model. The stimuli defined in the wizard are passed as parameters to this simulation model from the variation file. The simulation parameters are listed in the table below. The signal generator then produces the necessary signals for Virtual JTAG Intel® FPGA IP core outputs such as tck, tdi, tms, and so forth.
The model is parameterized to allow the simulation of an unlimited number of Virtual JTAG instances. The parameter sld_sim_action defines the strings used for IR and DR scan shifts. Each Virtual JTAG’s variation file passes these parameters to the Virtual JTAG component. The Virtual JTAG’s variation file can always be edited for generating different stimuli, though the preferred way to specify stimuli for DR and IR scan shifts is to use the parameter editor.
Parameter |
Comments |
---|---|
sld_sim_n_scan |
Specifies the number of shifts in the simulation model. |
sld_sim_total_length |
The total number of bits to be shifted in either an IR shift or a DR shift. This value should be equal to the sum of all the length values specified in the sld_sim_action string. |
sld_sim_action |
Specifies the strings used for instruction register (IR) and data register (DR) scan shifts. The string has the following format: ((time,type,value,length), (time,type,value,length), ... (time,type,value,length)) where:
Entries are in hexadecimal format. |
Simulation has the following limitations:
- Scan shifts (IR or DR) must be at least 1 ms apart in simulation time.
- Only behavioral or functional level simulation support is present for this IP core. There is no gate level or timing level simulation support.
- For behavioral simulation, the stimuli tell the signal generator model in the Virtual JTAG model to generate the sequence of signals needed to produce the necessary outputs for tck, tms, tdi, and so forth. You cannot provide the stimulus at the JTAG pins of the device.
- The tck clock period used in simulation is 10 MHz with a 50% duty cycle. In hardware, the period of the tck clock cycle may vary.
- In a real system, each instance of the Virtual JTAG Intel® FPGA IP core works independently. In simulation, multiple instances can work at the same time. For example, if you define a scan shift for Virtual JTAG instance number 1 to happen at 3 ms and a scan shift for Virtual JTAG instance number 2 to happen at the same time, the simulation works correctly.
If you are using the ModelSim* - Intel® FPGA Edition simulator, the altera_mf.v and altera_mf.vhd libraries are provided in precompiled form with the simulator.
The inputs and outputs of the Virtual JTAG Intel® FPGA IP core during a typical IR scan shift operation are shown in the figure below.
The figure below shows the inputs and outputs of the Virtual JTAG Intel® FPGA IP core during a typical DR scan shift operation.
Compiling the Design
These unique IDs are necessary for the Intel® Quartus® Prime Tcl API to properly address each instance of the IP core.
The addition of Virtual JTAG Intel® FPGA IP cores uses logic resources in your design. The Fitter Resource Section in the Compilation Report shows the logic resource utilization, as shown in the figure below.
Third-Party Synthesis Support
For example, if you create a my_vji.v file, a my_vji_bb.v file is also created. In third‑party synthesis, you include this black box file with your design files to synthesize your project. A VQM file is usually produced by third‑party synthesis tools. This VQM netlist and the Virtual JTAG Intel® FPGA IP core’s variation files are input to the Intel® Quartus® Prime software for further compilation.
SLD_NODE Discovery and Enumeration
Instruction |
Binary Pattern |
---|---|
USER0 |
00 0000 1100 |
USER1 |
00 0000 1110 |
The USER1 instruction targets the virtual IR of either the sld_hub or a SLD node. That is, when the USER1 instruction is issued to the device, the subsequent DR scans target a specific virtual IR chain based on an address field contained within the DR scan. The table below shows how the virtual IR, the DR target of the USER1 instruction is interpreted.
The VIR_VALUE in the table below is the virtual IR value for the target SLD node. The width of this field is m bits in length, where m is the length of the largest VIR for all of the SLD nodes in the design. All SLD nodes with VIR lengths of fewer than m bits must pad VIR_VALUE with zeros up to a length of m.
m + n – 1 |
m |
m – 1 |
0 |
---|---|---|---|
ADDR [(n – 1)..0] |
VIR_VALUE [(m – 1)..0] |
The ADDR bits act as address values to signal the active SLD node that the virtual IR shift targets. ADDR is n bits in length, where n bits must be long enough to encode all SLD nodes within the design, as shown below.
n = CEIL(log2(Number of SLD_nodes +1))
The SLD hub is always 0 in the address map, as shown below.
ADDR[(n -1)..0] = 0
Discovery and enumeration of the SLD instances within a design requires interrogation of the sld_hub to determine the dimensions of the USER1 DR (m and n) and associating each SLD instance, specifically the Virtual JTAG Intel® FPGA IP core instances, with an address value contained within the ADDR bits of the USER1 DR.
The discovery and enumeration process consists of the following steps:
- Interrogate the SLD hub with the HUB_INFO instruction.
- Shift out the 32-bit HUB IP Configuration Register to determine the number of SLD nodes in the design and the dimensions of the USER1 DR.
- Associate the Virtual JTAG instance index to an ADDR value by shifting out the 32‑bit SLD node info register for each SLD node in the design.
Issuing the HUB_INFO Instruction
The SLD_NODE_INFO register is used to determine the address mapping for Virtual JTAG instance in your design. This register set is shifted out by issuing the HUB_INFO instruction. Both the ADDR bits for the SLD hub and the HUB_INFO instruction is 0 × 0.
Because m and n are unknown at this point, the DR register (ADDR bits + VIR_VALUE) must be filled with zeros. Shifting a sequence of 64 zeroes into the USER1 DR is sufficient to cover the most conservative case for m and n.
HUB IP Configuration Register
The HUB IP configuration register is shifted out using eight four-bit nibble scans of the DR register. Each four-bit scan must pass through the UPDATE_DR state before the next four-bit scan. The 8 scans are assembled into a 32-bit value with the definitions shown in the table below.
Nibble7 |
Nibble6 |
Nibble5 |
Nibble4 |
Nibble3 |
Nibble2 |
Nibble1 |
Nibble0 |
||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
31 |
27 |
26 |
19 |
18 |
8 |
7 |
0 |
||||||||
HUB IP version |
N |
ALTERA_MFG_ID (0 × 06E) |
m |
n = CEIL(log2(N+1)) m = SUM(m,n) – n
SLD_NODE Info Register
The DR nibble shifts are a continuation of the HUB_INFO DR shift used to shift out the Hub IP Configuration register.
The order of the Nodes as they are shifted out determines the ADDR values for the Nodes, beginning with, for the first Node SLD_NODE_INFO shifted out, up to and including, for the last node on the hub. The tables below show the SLD_NODE_INFO register and their functional descriptions.
31 |
27 |
26 |
19 |
18 |
8 |
7 |
0 |
---|---|---|---|---|---|---|---|
Node Version |
NODE ID |
NODE MFG_ID |
NODE_INST_ID |
Field |
Function |
---|---|
Node Version |
Identifies the version of the SLD node |
NODE ID |
Identifies the type of NODE IP (0x8 for the Virtual JTAG Intel® FPGA IP core) |
NODE MFG_ID |
SLD Node Manufacturer ID (0x6E for Virtual JTAG Intel® FPGA IP core) |
NODE_INST_ID |
Used to distinguish multiple instances of the same IP. Corresponds to the instance index assigned in the parameter editor. |
You can identify each Virtual JTAG instance within the design by decoding NODE ID and NODE_INST_ID. The Virtual JTAG Intel® FPGA IP core uses a NODE ID of 8. The NODE_INST_ID corresponds to the instance index that you configured within the parameter editor. The ADDR bits for each Virtual JTAG node is then determined by matching each Virtual JTAG instance to the sequence number in which the SLD_NODE_INFO register is shifted out.
Capturing the Virtual IR Instruction Register
Each NODE VIR register acts as a parallel hold rank register to the USER1 DR chain. The sld_hub uses the bits prepended to the VIR shift value to target the correct SLD NODE VIR register. After the SLD_state_machine asserts virtual_update_IR, the active SLD node latches VIR_VALUE of the USER1 DR register.
The figure below shows a functional model of the interaction of the USER1 DR register and the SLD node VIR. The ADDR bits target the selection muxes in the figure after the sld_hub FSM has exited the virtual_update_IR state. Upon the next USER1 DR transaction, the USER1 DR chain will latch the VIR of the last active SLD_NODE to shift out of TDO. Thus, if you need to capture the VIR of an SLD node that is different than the one addressed in the previous shift cycle, you must issue the VIR_CAPTURE instruction. The VIR_CAPTURE instruction to the sld_hub acts as an address cycle to force an update to the muxes.
To form the VIR_CAPTURE instruction, use the following instruction format:
VIR_CAPTURE = ZERO [ (m – 4)..0] ## ADDR [(n – 1)..0] ## 011
In this format, ZERO[] is an array of zeros, ## is the concatenation operator, m is the width of VIR_VALUE, and n is the width of the ADDR bit.
AHDL Function Prototype
Port name and order also apply to Verilog HDL.
FUNCTION sld_virtual_jtag( ir_out[sld_ir_width-1..0], tdo ) WITH( lpm_hint, lpm_type, sld_auto_instance_index, sld_instance_index, sld_ir_width, sld_sim_action, sld_sim_n_scan, sld_sim_total_length ) RETURNS( ir_in[sld_ir_width-1..0], jtag_state_cdr, jtag_state_cir, jtag_state_e1dr, jtag_state_e1ir, jtag_state_e2dr, jtag_state_e2ir, jtag_state_pdr, jtag_state_pir, jtag_state_rti, jtag_state_sdr, jtag_state_sdrs, jtag_state_sir, jtag_state_sirs, jtag_state_tlr, jtag_state_udr, jtag_state_uir, tck, tdi, tms, virtual_state_cdr, virtual_state_cir, virtual_state_e1dr, virtual_state_e2dr, virtual_state_pdr, virtual_state_sdr, virtual_state_udr, virtual_state_uir );
VHDL Component Declaration
component sld_virtual_jtag generic ( lpm_hint : string := "UNUSED"; lpm_type : string := "sld_virtual_jtag"; sld_auto_instance_index : string := "NO"; sld_instance_index : natural := 0; sld_ir_width : natural := 1; sld_sim_action : string := "UNUSED"; sld_sim_n_scan : natural := 0; sld_sim_total_length : natural := 0 ); port( ir_in : out std_logic_vector(sld_ir_width-1 downto 0); ir_out: in std_logic_vector(sld_ir_width-1 downto 0); jtag_state_cdr : out std_logic; jtag_state_cir : out std_logic; jtag_state_e1dr : out std_logic; jtag_state_e1ir : out std_logic; jtag_state_e2dr : out std_logic; jtag_state_e2ir : out std_logic; jtag_state_pdr : out std_logic; jtag_state_pir : out std_logic; jtag_state_rti : out std_logic; jtag_state_sdr : out std_logic; jtag_state_sdrs : out std_logic; jtag_state_sir : out std_logic; jtag_state_sirs : out std_logic; jtag_state_tlr : out std_logic; jtag_state_udr : out std_logic; jtag_state_uir : out std_logic; tck : out std_logic; tdi : out std_logic; tdo : in std_logic; tms : out std_logic; virtual_state_cdr : out std_logic; virtual_state_cir : out std_logic; virtual_state_e1dr : out std_logic; virtual_state_e2dr : out std_logic; virtual_state_pdr : out std_logic; virtual_state_sdr : out std_logic; virtual_state_udr : out std_logic; virtual_state_uir : out std_logic ); end component;
VHDL LIBRARY-USE Declaration
LIBRARY altera_mf; USE altera_mf.altera_mf_components.all;
Design Example: TAP Controller State Machine
The figure below shows the TAP controller state machine. The table that follows provides a description of each of the states.
TAP Controller State |
Functional Description |
---|---|
Test-Logic-Reset |
The test logic of the JTAG scan chain is disabled. |
Run-Test/Idle |
This is a hold state. Once entered, the controller remains in this state as long as TMS is held low. |
Select DR-Scan/Select IR Scan |
These are temporary controller states. A decision is made here whether to enter the DR states or the IR states. |
Capture DR/Capture IR |
These states enable a parallel load of the shift registers from the hold registers on the rising edge of TCK. |
Shift DR/Shift IR |
These states enable shifting of the DR and IR chains. |
Exit1 DR/Exit1 IR |
Temporary hold states. A decision is made in these states to either advance to the Update states or the Pause states. |
Pause DR/Pause IR |
This controller state allows shifting of the Instruction Register and Data Register to be temporarily halted. |
Exit2 DR/Exit2 IR |
Temporary hold states. A decision is made in these states to advance to the Update states. |
Update DR/Update IR |
These states enable a parallel load of the hold registers from the shift registers. Update happens on the falling edge of TCK. |
Design Example: Modifying the DCFIFO Contents at Runtime
The Tcl API that ships with the Virtual JTAG Intel® FPGA IP core makes it an ideal solution for developing command‑line scripts that can be used to either update data values or toggle control bits at run time. This visibility into the FPGA can help expedite debug closure during the prototyping phase of the design, especially when external equipment is not available to provide a stimulus.
This design example consists of an Intel® Quartus® Prime project file that implements a DCFIFO and a command‑line script that is used to modify the contents of the FIFO at runtime.
The RTL consists of a single instantiation of the Virtual JTAG Intel® FPGA IP core to communicate with the JTAG circuitry. Both read and write ports of the DCFIFO are clocked at 50 MHz. A Signal Tap logic analyzer instance taps the data output bus of the DCFIFO to read burst transactions from the DCFIFO. The following sections discuss the RTL implementation and the runtime control of the DCFIFO using the Tcl API.
Write Logic
Instruction Register Value |
Function |
---|---|
PUSH |
Instruction to write a single value to the write side logic of the DCFIFO. |
POP |
Instruction to read a single value from the read side logic of the DCFIFO |
FLUSH |
Instruction to perform a burst read transaction from the FIFO until empty. |
The IR decode logic shifts the Push_in virtual DR chain when the PUSH instruction is on the IR port and virtual_state_sdr is asserted. A write enable pulse, synchronized to the write_clock, asserts after the virtual_state_udr signal goes high. The virtual_state_udr signal guarantees stability from the virtual DR chain. The figure below shows the write side logic for the DCFIFO.
Read Logic
When the FLUSH instruction is shifted into the Virtual JTAG instance, the IR decode logic asserts the read_req line until the FIFO is empty. The bypass register is selected when the FLUSH instruction is active to maintain TDI‑to‑TDO connectivity. The figure below shows the read side logic for the DCFIFO.
Runtime Communication
Procedure |
Description |
---|---|
push [value] |
IR shift the PUSH instruction, followed by a DR shift of the value argument. Value must be an integer less than 256. |
pop |
IR shift the POP instruction, followed by a DR shift of 8 bits. |
flushfifo |
IR shift the FLUSH instruction. |
The figure below shows runtime execution of eight values pushed into the DCFIFO and a flushfifo command, and a Signal Tap logic analyzer capture triggering on a flush operation.
Design Example: Offloading Hardwired Revision Information
Because the Intel® Quartus® Prime software ships with an installation of Tcl/Tk, you can use the Tk package to build a custom GUI to interact with your design. In many cases, the JTAG port is a convenient interface to use, since it is present in most designs for debug purposes. By leveraging Tk and the virtual JTAG interface, you perform rapid prototyping such as creating virtual front panels or creating simple software applications. The figure below shows the organization of the design.
A Tcl script creates and updates the verilog file containing the hardcoded version control information every time the project goes through a full compile. The Tcl script is executed automatically by adding the following assignment to the project’s .qsf file.
The USERCODE value shifted out by this design example is a user‑configurable 32-bit JTAG register. This value is configured in the Intel® Quartus® Prime software using the Device and Pin Options dialog box.
Configuring the JTAG User Code Setting
- On the Assignment menu, click Settings.
- On the Settings page, in the Category list, click Device.
- The Device dialog box appears. Click Device and Pin Options.
- In the Device and Pin Options dialog box, on the General tab, the JTAG user code appears. Type the user code in 32-bit hexadecimal format.
- Click OK.
Document Revision History for the Virtual JTAG Intel FPGA IP Core User Guide
Document Version | Intel® Quartus® Prime Version | Changes |
---|---|---|
2020.12.01 | 20.3 |
|
2018.07.19 | 16.1 |
|
Date |
Version |
Changes |
---|---|---|
October 2016 | 2016.10.31 | Removed Upgrading IP Cores section. |
November 2015 | 2015.11.20 | Corrected the flow for EXIT2_DR to SHIFT_DR in the JTAG TAP Controller State Machine figure. |
July 2014 | 2014.07.08 |
|
March 2014 |
2014.03.19 |
Updated the description of the SLD_IR_WIDTH parameter in the "Parameters for the Virtual JTAG Megafunction" table. |
February 2014 |
2014.02.25 |
|