This user guide assumes that you are familiar with IP cores and how to configure them.

Intel recommends that you use the ALTIOBUF IP core to utilize the I/O buffers for any purpose that includes:

• LVDS interfaces—using the ALTLVDS IP core, enabling dynamic delay through Intel^® Quartus^® Prime Setting File (.qsf) statements
• DDR interfaces—using the ALTDDIO_IN, ALTDDIO_OUT, ALTDDIO_BIDIR, ALTDQ, ALTDQS, and ALTDQ_DQS IP cores
• Dynamic on-chip termination (OCT) control—using the ALTOCT IP core

One of the key applications for this IP core is to have more direct termination control of the buffers. By enabling series and parallel termination control ports for the I/O output buffers and I/O bidirectional buffers, you can connect these ports to the ALTOCT IP core to enable dynamic calibration for on-chip termination.

The additional dynamic termination control ports allow control when series termination or parallel termination are enabled for bidirectional buffers. Parallel termination needs to only be enabled when the bidirectional I/O is receiving input. Otherwise, it needs to be disabled so that the output performance and power dissipation is optimal.

Another key application for this IP core is for dynamic delay chain in the I/O buffer. Dynamic I/O delay allows implementing automatic deskew, especially for memory interfaces, such as DDR3, which is handled by the memory interface intellectual property (IP). You need to dynamically deskew and not calculate manually because much of the skew can come from the I/O buffers of either the FPGA or the other device the FPGA is interfacing with (for example, memory). Even if the trace lengths are matched, there can still be electrical skew in the system. Also, this skew changes and can change from device to device. Having the ability to deskew from the fabric allows you to remove uncertainties that would have to be considered in the timing budget. This allows you to gain more timing margin, which allows higher frequencies.

Figure 1. Example Illustrating DeskewThis figure shows an example of deskew.

For example, if the input (or output) bus signals are DQ[0] and DQ[1], board trace skew, transmitter device skew, or even FPGA package skew could cause signals that were initially aligned to become misaligned. The third waveform shows the window available to the receiver for capturing the data. If DQ[0] was delayed a bit to match DQ[1], a wider window would become available to the receiver.

To find the left and right edges of the data valid window, you need to do coarser adjustments (one possible method is to use the new phase adjustment functionality of the PLL (ALTPLL IP core). The range of the deskew delay chains is only designed to compensate for a reasonable amount of board and package/layout skew.

Dynamic delay chains are integrated in the input path for input and bidirectional buffers. Dynamic delay chains are integrated in the output and oe paths for output and bidirectional buffers. This section describes the dynamic delay chain-related components only.

All paths share a similar configuration in which the delay cells are getting their delay control signal from the IO_CONFIG component. For the input path, the IO_CONFIG’s PADTOINPUTREGISTERDELAYSETTING output port drives the DELAY_CHAIN’s (input delay cell) DELAYCTRLIN input port. For the output and oe path, use the IO_CONFIG’s OUTPUTDELAYSETTING 1 and 2 output ports to drive the DELAYCTRLIN port of the first and second output delay cells, respectively.

The number of delay chains needed is NUMBER_OF_CHANNELS. Each instance of the I/O buffer includes a delay chain. Assume NUMBER_OF_CHANNELS is equal to ×. There must be × instances of input delay chain for × input buffer, and 2× instances of the first output delay chain and 2× instances of the second output delay chain output buffer because it uses the output and oe paths. The bidirectional buffer combines all instances of the delay chains mentioned above.

The datain and datain_b input ports of the ALTIOBUF IP core (input buffer mode) connect to the i and ibar ports (if differential mode is enabled) of the input buffer, respectively. In the input path, the value of the input buffer’s dataout port is passed into the input delay chain. The dataout port of the ALTIOBUF IP core (input buffer mode) is the output of the dataout delay chain.

You must add a register external to the IP core, either a regular DFFE or a DDIO and connect its input to the IP core’s dataout port.

Contrary to the input path in the output and oe paths, you can add two optional registers, which are external to the IP core. One is for the output path and the other is for the oe path.

Instead of connecting the input data to the datain port of the ALTIOBUF IP core (output buffer mode), it is connected to the input of the registers that are external to the IP core. The output of the register is then driven to the datain port of the first output delay chain port. In a similar way, the inverted input oe is connected to the oe register that is external to the IP core, which drives the datain port of the first oe delay chain port.

Each of the output and oe delay chains are built from two cascaded output delay chains. The first output delay chain’s dataout is connected to the second output delay chain’s datain. Depending on the parameter chosen (use_out_dynamic_delay_chain1 or use_out_dynamic_delay_chain2), one or both of the output delay chains can be dynamic. In this IP core, you can set the delay only for the dynamic delay chains.

The second output delay chain’s dataout is connected to the output buffer’s i input port for the output path and to the output buffer’s oe port for the oe path. Note that the output path and the oe path have their own cascaded delay chains.

By combining the input and output buffers, the output path and oe path are placed before the buffer and the input path is placed after the buffer.

By following these specifications, only the input path needs a register external to the IP core. The output and oe registers that are added externally to the IP core are optional.

The external register placement is similar to the input/output buffers, where the output and oe registers drive the datain and oe ports of the ALTIOBUF IP core (bidirectional buffer mode) and the dataout port drives the input register.

This is because the IP core utilizes the IO_CONFIG and DELAY_CHAIN blocks that are associated with the use of DDR interfaces. Therefore, the Intel^® Quartus^® Prime Fitter requires the assignment to determine the placement of the blocks with the respective IO_xBUF block.

The format of the MEMORY_INTERFACE_DATA_PIN assignments generally appears as the following:

MEMORY_INTERFACE_DATA_PIN_GROUP {4|9|18|36} -from iobuf[0] -to iobuf[0]
MEMORY_INTERFACE_DATA_PIN_GROUP {4|9|18|36} -from iobuf[0] -to iobuf[1]
MEMORY_INTERFACE_DATA_PIN_GROUP {4|9|18|36} -from iobuf[0] -to iobuf[2]
….
MEMORY_INTERFACE_DATA_PIN_GROUP {4|9|18|36} -from iobuf[0] -to iobuf[n]

iobuf is the name of the buffer, either a stratixiii_io_obuf (for the output buffer) or stratixiii_io_ibuf (for the input buffer). For the bidirectional buffer, either one is acceptable.

To allow this particular design to be fit, add the following line in the Intel^® Quartus^® Prime Setting File (.qsf):

set_instance_assignment -name MEMORY_INTERFACE_DATA_PIN_GROUP 4 -from "u2|test_output_iobuffer_iobuf_out_kk21:test_output_iobuffer_iobuf_out_kk21_component|obufa_0" -to "u2|test_output_iobuffer_iobuf_out_kk21:test_output_iobuffer_iobuf_out_kk21_component|obufa_0"

You can also use the Assignment Editor to set the column fields as shown in the following table:

Then, set the Value field as shown in the following table:

The design example associated with this user guide has this assignment.

You can locate VHDL component declaration in the VHDL Design File (.vhd) altera_mf_components.vhd in the < Intel^® Quartus^® Prime installation directory>\libraries\vhdl\altera_mf directory.

The VHDL LIBRARY-USE declaration is not required if you use the VHDL Component Declaration.

LIBRARY altera_mf;
USE altera_mf.altera_mf_components.all;