Jim Wu's FPGA Blog

Floating Point Algorithm Development Made Easy in System Generator

2012-01-24T06:29:00.000-05:00

System Generator 13.3 added support for bit and cycle accurate, single, double and custom precision-floating-point on many blocks in the Xilinx Blockset. It now has a new "Floating-Point" library under "Xilinx Blockset" in the "Simulink Libary Browser", which lists all blocks supporting floating point numbers (see the "Floating Point Library in Xilinx Blockset" snapshot below). The list is really informational in that if some of these blocks are already in your fixed point model you don't need to swap them out with the blocks in the "Floating-Point" library to change it to a floating point model. In most of cases all you need to do is to change the input data type of the "Gateway In" blocks in the model to one of the supported floating point types and the tool will automatically generate the floating point model and netlist for simulation and implementation. The "Adder Example with all Supported Data Types" figure below shows that outputs of the same "AddSub" block are automatically adjusted to match the input data type.
PS: it is very handy to turn on the port data type display using "Format->Port/Signal Displays->Port Data Types" menu.
PPS: Click "Edit->Update Diagram" menu or pressing "CTRL-D" to update the data type display when the data types of some blocks are changed.

Floating Point Library in Xilinx Blockset


Added Example with all Supported Data Types

Below is a YouTube video from Xilinx on this new feature in case you are interested:

Memory Initialization Methods

2011-12-31T10:02:00.000-05:00

Questions on how to initialize a ROM or RAM come up quite often on FPGA discussion boards and forums. Several methods can be used to initialize memory in RTL, during implementation, and post-implementation when targeting Xilinx FPGA devices. Some of the methods are covered in this blog.

Verilog "initial" block with $readmemb or $readmemh
Memories can be initialized using $readmemb or $readmemh system tasks with a memory initialization file (.mif) (download complete example here):

reg [DATA_WIDTH-1:0] mem[0:2**ADDR_WIDTH-1];

initial begin
    $readmemh("mem_init_vlog.mif", mem, 0, 255);
end

XST has two different Verilog parsers depending on the target device. The old parser is used for Virtex5/Spartan3 and older devices. For Virtex6/Spartan6 and newer devices, the new parser will be used. The old parser has a few restrictions on the memory initialization:

The entire memory array must be initialized. For example, if the memory has 256 words, all 256 words must be explicitly initialized. Otherwise the initialization will be ignored with this warning message: WARNING:Xst:2319 - "rom_vlog.v" line 21: Signal mem in initial block is partially initialized. The initialization will be ignored.

Make sure the .mif file does NOT have any unnecessary white spaces (especially "tab") anywhere. Or it will issue some obscure error message like this: ERROR:Xst:2354 - "rom_vlog_mif.v" line 18: Value 262025260 found at line 256 is not hexadecimal in call of system task $readmemh.

Starting address (@hh), Verilog comments (// or /* */), and multiple values per line are not supported in the .mif file. Or as you guessed it, it will issue other weird errors.

It is very unlikely that these restrictions will removed from the old parser because workarounds exist by following the rules above. The good news is that the new Verilog parser supports all valid formats in a memory initialization file as describe in Verilog LRM. i.e. the restrictions no longer exist in the new Verilog parser. An even better news is that the switch "-use_new_parser yes" can be manually added to the XST command line to enable the new parser for older devices if you insist on using full features of the memory initialization file.

VHDL functions
Memory can be initialized in VHDL by using a function at signal declaration. Functions like sin(), cos()in the IEEE math_real library are supported by XST for initializing memories. The code snippet below shows how to generate a look up table with a cosine wave (download complete example here):

constant MEM_DEPTH : integer := 2**ADDR_WIDTH;
type mem_type is array (0 to MEM_DEPTH-1) of signed(DATA_WIDTH-1 downto 0);

function init_mem return mem_type is
    constant SCALE : real := 2**(real(DATA_WIDTH-2));
    constant STEP : real := 1.0/real(MEM_DEPTH);
    variable temp_mem : mem_type;
begin
    for i in 0 to MEM_DEPTH-1 loop
        temp_mem(i) := to_signed(integer(cos(2.0*MATH_PI*real(i)*STEP)*SCALE), DATA_WIDTH);
    end loop;
    return temp_mem;
end;

constant mem : mem_type := init_mem;

VHDL with external data files
XST User Guide has VHDL examples of initializing block RAMs with external data files. It's listed here so that you are aware of this option. The XST UG should always be your first stop for coding styles and techniques. I would like to point out two things highlighted in red in the code snippet below (download complete example here):

The "file" declaration in XST UG uses VHDL-87 syntax. The code snippet below uses VHDL-93 syntax because that is the default VHDL starndard XST uses.
The second argument for the "read" function needs to be a bit_vector. std_logic_vector or signed types are not supported by the "read" function in IEEE std.textio package.

constant MEM_DEPTH : integer := 2**ADDR_WIDTH;
type mem_type is array (0 to MEM_DEPTH-1) of signed(DATA_WIDTH-1 downto 0);

impure function init_mem(mif_file_name : in string) return mem_type is
    file mif_file : text open read_mode is mif_file_name;
    variable mif_line : line;
    variable temp_bv : bit_vector(DATA_WIDTH-1 downto 0);
    variable temp_mem : mem_type;
begin
    for i in mem_type'range loop
        readline(mif_file, mif_line);
        read(mif_line, temp_bv);
        temp_mem(i) := signed(to_stdlogicvector(temp_bv));
    end loop;
    return temp_mem;
end function;

constant mem : mem_type := init_mem("mem_init_vhd.mif");

Verify Memory Content in Synthesized Netlist

There are a couple of ways to verify that the memory is correctly initialized by the synthesis tool:

The values of INIT_xx attributes of the block RAM can be examined in PlanAhead by opening the netlist design in PlanAhead, selecting the instance for the memory, and selecting the "Attributes" tab of the "Instance Properties" window.

A post-synthesis simulation model can be generated for the synthesized netlist in Project Navigator or by using netgen tool. This simulation model can be used in the existing testbench to check if the initialization data made into the netlist correctly. The waveform below shows the correct outputs from the ROMs created in the Verilog .mif (counter) and VHDL function (sine wave) methods.

Rearrange Blocks in PlanAhead Schematic Viewer

2011-11-05T16:18:00.001-04:00

The Schematic Viewer in PlanAhead is an invaluable tool to help understand and analyze synthesized netlists. PlanAhead 13.3 added a nice feature that allows users to move blocks around in the Schematic Viewer. Users can easily rearrange the schematic to follow the control/data flow or specific structure the design was intended for so they can better visualize the logic as well as use it for documentation purse.

To move a block in the Schematic Viewer, simply hold down the SHIFT key and then use the left mouse button (LMB) to select and drag&drop the block to the new location. Connections between blocks will be redrawn for the new layout.

The two snapshots below are schematics of the ternary adder circuit before and after rearrangement. The second snapshot clearly shows the regular structure of the circuit that the LUT3/LUT4 pair for each bit share common inputs and can be packed into the same LUT6_2.

Schematic before rearrangement

Schematic After Rearrangement

Use Floating License Servers

2011-10-29T14:02:00.004-04:00

I used to just set LM_LICENSE_FILE environment variable to all floating license servers for all EDA tools that I use. It had become unacceptably slow to start and run Matlab with LM_LICENSE_FILE (see this Matlab solution for more information), so I switched to use individual environment variable that each EDA vendor checks for licenses. Things have been working a lot better since I made the change. Below is a list of environment variables that tools I run on a regular basis check for a license. This is mainly for my own reference. Hopefully somebody else may also find it useful.

Mentor Graphics: MGLS_LICENSE_FILE
Matlab: MLM_LICENSE_FILE
Synposys: SNPSLMD_LICENSE_FILE
Xilinx: XILINXD_LICENSE_FILE

P.S.: Check AR11630 (http://www.xilinx.com/support/answers/11630.htm) for instructions on how to set up environment variables. My personal favorite tool for setting/editing environment variables is Rapid Environment Editor
P.P.S: Check other Cool Programs in My Toolbox

Ternary Adder with LUT6_2

2011-10-22T10:59:00.001-04:00

Xilinx Virtex5 and newer FPGAs have 6-input look up tables with dual outputs (LUT6_2), which can be efficiently used to build ternary adders. The technique is described in details in US patent 7274211. Below is the circuit copied from the patent filing:

This exact circuit will be automatically inferred by XST for ternary adders in RTL. Below is an example that calculates sum=x+y+z:

(* shreg_extract = "no" *) module adder (
    input      clk,
    input [7:0] x ,
    input [7:0] y ,
    input [7:0] z ,
    output reg [7:0]sum
);

reg [7:0] sum_r, x_r, y_r, z_r;

always @(posedge clk) begin
       x_r <= x; 
       y_r <= y; 
       z_r <= z;
       sum_r <= x_r + y_r + z_r;
       sum <= sum_r;

end
endmodule

The snapshot below shows the technology view of the synthesized netlist targeting a Spartan6 device :

The MAP utilization shows exactly 8 LUTs used for the logic:
Slice Logic Utilization:
Number of Slice Registers:                    40 out of 11,440    1%
    Number used as Flip Flops:                  40
    Number used as Latches:                      0
    Number used as Latch-thrus:                  0
    Number used as AND/OR logics:                0
Number of Slice LUTs:                         12 out of   5,720    1%
    Number used as logic:                        8 out of   5,720    1%
      Number using O6 output only:               2
      Number using O5 output only:               0
      Number using O5 and O6:                    6
      Number used as ROM:                        0
    Number used as Memory:                       0 out of   1,440    0%
    Number used exclusively as route-thrus:      4
      Number with same-slice register load:      4
      Number with same-slice carry load:         0
      Number with other load:                    0

The two snapshots below shows the first two bits in a slice and all 4-bits packed in the same slice:

FFT Core Settings v.s Resources and Performance

2011-09-03T18:35:00.000-04:00

Core Generator can be used to quickly find out the resource estimate, latency, and maximum throughput of the FFT core based on the current configuration of the core. This makes it very easy to do trade-off analyses between differentFFT architectures, bit widths, output orders, etc.

The Implemetation Tab displays the resource estimates for DSP48 and 18Kb BRAM counts (note for device families with 36Kb BRAMs, each BRAM primitive can be used as two 18Kb BRAMs):

The Latency Tab displays the number of cycles required andthe latency for the current transform length:

The numbers on the “Implementation” and “Latency” tabs are updated as soon as settings are changed on the configuration GUI.

The table below shows the resource estimates and latencynumbers for a 1024-point FFT with 250MHz clock, 16-bit inputs and outputs anddifferent architectures and output orders:

As shown in the table above, different settings, especiallydifferent architectures, have big impact on hardware resources and latency. One nice feature is that the tool has “Automatically Select” as an architecture option so the tool will choosethe smallest implementation based onthe specified “Target Data Throughput” and “Target Clock Frequency”. Theselected architecture and its resource estimate and latency are displayed on the “Implementation” and “Latency” tabs (see the snapshotbelow).

Set up Xilinx IDS environment for non-IDS tools

2011-07-23T17:12:00.006-04:00

The installer for IDS 12.x or newer on Windows no longer sets up environment variables (XILINX, XILINX_EDK, PATH, etc) for running IDS tools during installation. Instead it provides a bootloader batch file that runs first to set up all required environment variables for the current session and then invokes the target application.
You can find out the path and name of the bootloader by looking at the "Target" of the shortcut to any of IDS tools. For example, below are the bootloaders for 64-bit and 32-bit IDS 13.2:
C:\Xilinx\13.2\ISE_DS\settings64.bat
C:\Xilinx\13.2\ISE_DS\settings32.bat

The bootloader makes it very easy to run multiple versions of IDS on the same machine and there is no need to manually modify environment variables any more. Even better, the bootloader can be used with non-IDS applications as well. Here is an example showing how to run Matlab with IDS 13.2.

Make a copy of the current Matlab shortcut on the desktop and change the name to something meaningful
Right click the new shortcut and open "Properties" window (see the snapshot below)
In the "Target" field, add the bootloader before the Matlab executable. A space is needed between the bootloader and the executable:

C:\Xilinx\13.2\ISE_DS\settings64.bat C:\MATLAB\R2011a\bin\matlab.exe

Click "Change Icon" to change the icon back to Matlab if needed
Apply changes and close the window.

The old Matlab shortcut will run with the ISE version set by the system environment variables. The new shortcut will run with IDS 13.2. The snapshot below shows the two sessions side by side.

IFFT with Symmetric Input in System Generator

2011-04-24T13:43:00.004-04:00

The FFT/IFFT of real data input is symmetric: X(N-k) = X*(k). The FFT/IFFT of data with X(N-k) = X*(k) symmetry may not be real numbers unless X(0) is real and X(N/2) is real (this is implied by the symmetry equation X(N-N/2) = X*(N/2) ).

When the FFT core (view all Xilinx documents in Document Navigator) is used in SysGen to calculate the IFFT of symmetric input, there are a couple of more things to consider.

Set up FFT core for inverse FFT

The FFT core needs to be set to IFFT mode by writing 0 to s_axis_config_tdata_fw_inv input through the AXI configuration interface PRIOR to the start of frame (see the constant blocks in the red circle below)

Starting index difference between Matlab and FFT
In Matlab, the array index starts from 1, while the index for FFT equations starts from 0. When the symmetric data input to the FFT core is created manually from a script, make sure this starting index difference is accounted for. Using an 8-point FFT as an example, the input array fft_in(1:8) should be set up like the below:

Sample 0: fft_in(1) = real

Sample 1,7: fft_in(2) = conj(fft_in(8))

Sample 2,6: fft_in(3) = conj(fft_in(7))

Sample 3,5: fft_in(4) = conj(fft_in(6))

Sample 4: fft_in(5) = real

Input data range of FFT core

The FFT block in SysGen expects the input data to be in the range [-1, 1) or a N bit fixed point with N-1 fractional bits, so make sure the input samples are properly scaled to [-1,1) when they are generated in the script.

Exampe

An example with 256-point FFT block set to compute IFFT can be downloaded here. The input samples are symmetric (i.e. X(N-k) = X*(k)). Below are the magnitudes of the real and imaginary parts of the IFFT outputs, where the imaginary part is negligible (i.e. the IFFT outputs are real.).

max_abs_real_fft_sg =
0.0078

max_abs_imag_fft_sg =
3.5763e-007

SysGen xlGenerateButton function example

2011-04-13T01:15:00.001-04:00

As described in SysGen Reference Guide (view all Xilinx documents in Document Navigator), the xlGenerateButton function provides a programmatic way to invoke the System Generator code generator. The syntax is
status = xlGenerateButton(sysgenblock)

This looks pretty straightforward: give it the full path name of the System Generator token in the design and let it run. The tricky part is that the actual name for the System Generator token has a space at the very beginning (i.e. " System Generator"), which must be included in the full path name of the SysGen token. In general, when in doubt, you can use the "gcb" function to get the full hierarchical path name of any selected block in a model. In this particular example (download the model and m script here), below are the steps to get the full path name of the System Generator token and the snapshot of the output:

Open the model system_period_test
Select the System Generator token by clicking on it
Go to the command window and run gcb, which will return the path name

You can now simply start the generation by running the command below:
xlGenerateButton('system_period_test/ System Generator')

OFFSET Constraint Entry Methods

2011-03-24T07:51:00.007-04:00

OFFSET IN/OUT constraints can be specified on IOs using three different methods. It can be entered

on specific net
on timing group consisting of different pads. This is the method I would recommended.
globally. All IOs not covered by other more specific OFFSET constraints will be included in the global OFFSET constraint.

A simple example (download the complete project with HDL and UCF here) is used below to show the syntax for these three methods and how they are reported by the Timing Analyzer:

UCF Constraints

NET "clk_i" TNM_NET = TN_clk_i;
TIMESPEC TS_clk_i = PERIOD "TN_clk_i" 20 ns HIGH 50%;

#global offset in
OFFSET = IN 10 ns BEFORE clk_i;

#offset in on time group
NET a_i[*] TNM = TN_a_i_pads;
NET a_vld_i TNM = TN_a_i_pads;
TIMEGRP TN_a_i_pads OFFSET = IN 8 ns BEFORE clk_i;

#add P/N of differential pairs to the same timing group
NET d_i_p     TNM = TN_d_pads;
NET d_i_n     TNM = TN_d_pads;
TIMEGRP TN_d_pads OFFSET = IN 10 ns BEFORE clk_i;

#offset in on specific net
NET "b_i[*]" OFFSET = IN 6 ns BEFORE clk_i;

Timing Result
Below is the timing result after the implementation is done.

Each net in the b_i bus is reported separately with 6 ns OFFSET IN requirement.
All nets in TN_a_i_pads group are reported under the OFFSET IN constraint on the timing group.
The c_i bus is not covered by any OFFSET IN constraints on specific net or timing group, so it's reported under the global OFFSET IN constraint.
The differential pair d_i_p and d_i_n are reported under the same timing group.

Xilinx Document Navigator is Live (latest version is 1.2 as of July 26, 2011)

2011-03-11T06:58:00.015-05:00

Update (Aug 1, 2011): Watch Xilinx Document Navigator 1.2 Overview Video

Xilinx Document Navigator is an awesome document manager that

downloads all HW (UG, AppNotes, errata, etc) and SW documents from one "Download" button
automatically checks for updates on all documents
can easily filter, find and search all documents
With improvements made to "User Documents" tab in v1.2 that allow documents/URLs to be organized hierarchically and re-ordered (see the snapshot at the end), DocNav can now be used to manage ALL your documents, not just Xilinx documents.

Download
The Document Navigator can be downloaded from http://www.xilinx.com/support/ (see the red rectangle in the snapshot below):

Main Application Window

Below is the main window of the Document Navigator (DocNav). It's pretty straightforward to use the tool, but I want to point out a few key features in case it helps:

The document catalog is used by DocNav to keep track all documents. The current status of the catalog is displayed next to it. If any changes are made to the catalog on the server, the status will change to "Update Catalog" and you can simply click on it to update to the latest catalog.
Download button opens the Download Manager from which you can download new or updated documents since last download.
Search button opens Search Tool to search keywords within all documents displayed on the filtered document list.
Find button opens the Find tool bar at the bottom of the window (red rectangle 6).
Status column displays the current status of each document so you can easily see which documents need to be updated.
Find tool bar is used to find documents that match the keyword in its title, Doc ID, etc. The "Auto Filter" on the Find tool bar is really handy to display only matched documents in the document list window.
Filter pane is where you can filter documents based devices, document types, etc. The filter setting can be saved by right clicking on the pane and then select "Save Settings".
New in v1.2 (see the second snapshot below), documents/URLs can be added to folders/subfolders and their order can be easily changed by dragging and dropping.

FFT v8.0 AXI with scaled output

2011-03-03T06:55:00.092-05:00

The output of the FFT core can be set to "Scaled" to save some logic resources if the full precision is not required. A few things are worth mentioning to get the scaling to work:

Scaling is done in stages. There are 2 bits in the scaling schedule input for each stage to scale the result by 0 to 3 bits.
The scaling schedule needs to be set BEFORE the start of the transformation.
It's always a good idea to bring the overflow output out and monitor it to make sure no overflow occurs during scaling.
The bit accurate C model also has a scaling option and scaling schedule input in a slightly difference format than the FFT SysGen block. When comparing the results between the FFT SysGen block and the C model, make sure the same scaling settings are used in both.
When comparing the result between the FFT SysGen block and the Matlab FFT function, remember to scale the output of the FFT function by the same scaling factor.

Below are more details about the points above:

Scaling Input Format:

The description in the FFT Datasheet (view all Xilinx documents in Document Navigator) is pretty good, so I just pasted it here for your reference:

Scaling Schedule Setup

In FFT 8.0, the scaling schedule is set via the AXI configuration channel. The data are sent to the core via the data input channel. To make the scaling schedule to take effect, make sure the configuration data are taken by the core before the input samples. Remember that in AXI, the data are only transferred when both TVALID and TREADY are asserted. In this case, check the waveform (see below) to confirm that the condition that s_axis_config_tvalid=1 and s_axis_config_tready=1 with desired a_axis_config_scale_sch happens before s_axis_data_tvalid=1 and s_axis_data_tready=1

Overflow output

The bit growth of the FFT core in full precision mode is NFFT+1 where NFFT is log2(FFT size). For example, for a 256 point FFT, the bit growth is 9 bits. When the scaled output is used, the output has the same width as the input samples, so theoretically the scaling schedule needs to scale back the full bit growth to avoid the overflow. For the 256 point FFT, the scaling schedule can be something like [3 2 2 2] to account for the additional 9 bits. However, for some applications the input samples may never reach the full bit growth going through the FFT core, so the scaling schedule can be smaller to get more dynamic range. This is when you need to monitor the overflow output closely to make sure the overflow doesn't happen. The best way I found for selecting a scaling schedule for maximum dynamic range is to run the bit accurate C model with large set of real input samples and adjust the scaling schedule as needed.

The snapshot below shows that overflow is observed on the m_axis_data_ovflow output as well as the m_axis_status_ovflow output when the scaling schedule is set too small.

The snapshot below shows a good transformation of a frame when the scaling schedule is good.

Set up Scaling in Bit Accurate C Model

Using the same 256 point FFT as an example, below are the things need to be set up to use the scaling with the bit accurate C model

generics.C_HAS_SCALING = 1; % Set to 0 if C_USE_FLT_PT = 1
% Scaling schedule
scaling_sch0 = 2;
scaling_sch1 = 2;
scaling_sch2 = 2;
scaling_sch3 = 2;

scaling_sch = [scaling_sch3, scaling_sch2, scaling_sch1, scaling_sch0];

[fft_ba, blkexp, overflow] = xfft_v8_0_bitacc_mex(generics, nfft, input, scaling_sch, direction);

Scale Matlab FFT Output

When comparing the Matlab FFT function with the FFT SysGen block, make sure the FFT function output is also scaled by the same scaling factor. e.g.

scaling_factor = 2^sum(scaling_sch);

fft_mat = fft(input);

mag_mat = abs(fft_mat)/scaling_factor;

Example

OK, now comes my favorite 256 point FFT example that is used a few other blogs. I updated it to turn on the scaling and bring out the overflow output. Below is how the model looks like followed by the plot of the comparison.

SysGen Example of FFT v8.0 with AXI

2010-12-08T06:54:00.001-05:00

Starting in IDS 12.3, most, if not all, new/upgraded Xilinx IP cores will only use AXI as user interface. For FFT v8.0 specifically, it provides AXI4-Stream interfaces for input/output data and control. The AXI4-stream interface is a lot simpler than memory mapped AXI4 interface. It uses basic handshake between the master and slave as shown in the snapshot below from the FFT v8.0 Data Sheet (note that all AXI IP cores have separate data sheets than the non-AXI versions). The key thing to remember is that the AXI payload is only transferred when both TVALID and TREADY are high.

I updated the SysGen example in the blog FFT results from Matlab fft, Bit Accurate C model and SysGen FFT block with FFT v8.0 core to show the use of AXI4 stream interface. Below is the updated SysGen model:

The updated SysGen model and m file can be downloaded from here. Again, you will need to download the bit accurate model from FFT core web site yourself to run fft_compare.m script.

Understand maximum frequency reporting in XST

2010-11-11T14:50:00.006-05:00

Let's say your design has a single 50MHz clock source coming in. It then goes to a DCM or PLL to generate three clock outputs at 50MHz, 100MHz and 150MHz. When you run through synthesis XST reports the maximum frequency of the design like below.

Minimum period: 6.292ns (Maximum Frequency: 158.931MHz)

Which clock is this maximum frequency reported on since the design uses all three derived clocks? Well, it depends if the derived clocks are from DCM or PLL. Let's use two test cases, one with DCM and one with PLL, to see how the maximum frequency is reported. Each test case has the same adder below in each derived clock domain.

Test case with DCM (click to download the project in IDS 12.3)
The snapshot below shows the timing summary and the worst case path for the test case with DCM. Note that the minimum period is reported as 6.292ns while the delay of the worst timing path is 2.097ns. This is because the worst case path is in the 150MHz clock domain (note that the source and destination clock of the path is clk0_i rising 3.0x) and XST references it back to the DCM input clock (clk0_i @50MHz) to calculate the maximum clock frequency. In other words, to meet the 2.097ns delay in the 150MHz clock domain, the minimum delay of the DCM input clock must be 2.097*3=6.292 ns or maximum frequency 158.93MHz. As long as the DCM input clock is 158.93MHz or lower, all the paths in all derived clock domains will meet timing.

Test case with PLL (click to download the project in IDS 12.3)
The snapshot below shows the timing summary and the worst case path for the test case with PLL. The minimum period in timing summary is the same as the delay in the worst case path. XST uses the PLL output directly to calculate the maximum frequency. Personally I think this is the wrong way of reporting the maximum frequency because users can't just change the clock frequency of one PLL output and have no way of knowing what the PLL input clock frequency needs to be. It's mostly likely an oversight (read BUG) in XST.

Use Excel to Draw Waveforms

2010-10-12T00:52:00.002-04:00

I learned a trick yesterday from a friend's tweet that Excel can be used to draw waveforms using different cell border outlines. I just tried it out and within a few minutes I got a pretty nice waveform in front of me. There is no learning curve involved and no need to purchase and/or install a special waveform drawing tool. I presume OpenOffice Calc can be used to do the same thing.

Below is the waveform in Excel:

And here how it looks like in "Print Preview":

DDS in System Generator: how to set up periods?

2010-07-22T06:48:00.047-04:00

If you use DDS Compiler in System Generator, you will notice there are 4 clock periods you need to deal with (circled in red in the snapshot below). This can be confusing for first time users. Hopefully this blog can clear up some of the confusions.

FPGA clock period (ns): only used for FPGA synthesis and implementation. This value does NOT affect simulation in Simulink (i.e. it will NOT affect output frequency of the DDS block).
Simulink System Period: only used in Simulink simulation. This is the lowest sampling period (highest sampling frequency) among all blocks in the model. There is no significance in its absolute value as long as the sampling periods of all other blocks are multiple of the Simulink System Period. Usually it is set to 1 to keep everything simple. (e.g. every tick in a scope is 1 clock cycle).
DDS System Clock (Mhz): It's used to calculate the phase increment for DDS block (see the DDS datasheet for details). Set it to match the FPGA clock period (i.e. DDS System Clock (Mhz) = 1/FPGA clock period).
Explicit Sample Period: This is the sample period used for the DDS block. IMPORTANT: if you set Simulink System Period to anything other than 1, "Use explicit period" MUST be checked and "Explicit Period" set to the same value as Simulink System period. Otherwise, Simulink will use the sample period of 1 for the DDS core and the output frequency will be wrong. This is likely a bug.

Let's use a simple model (download the model for test1 here) below to show how all these periods play together in SysGen. The clock frequency of the SineGen block is 1/100th of the Simulink System Period (or 1MHz for a 100MHz clock input).

Test1:
FPGA clock period (ns) = 10
Simulink system period = 1
DDS System Clock (MHz) = 100
Use Explicit Sample Period checked and Explicit Period = 1
DDS Output (MHz) = 1

As shown in the scope below the DDS output matches the SineGen output:

Test2:
FPGA clock period (ns) = 10
Simulink system period = 0.1
DDS System Clock (MHz) = 100
Use Explicit Sample Period checked and Explicit Period = 0.1
DDS Output (MHz) = 1

As shown in the scope below the DDS output matches the SineGen output. Note that the Simulink system period is now 1/10th of the period in Test1, so there are 10x more clock cycles in this test with the same simulation time.

Test3:
FPGA clock period (ns) = 10
Simulink system period = 0.1
DDS System Clock (MHz) = 100
Use Explicit Sample Period unchecked
DDS Output (MHz) = 1

As shown in the scope below the DDS output frequency is 1/10th of SinGen output. The incorrect DDS output frequency is caused by that when "Use Explicit Sample Period" is unchecked Simulink use a sample period of 1 for the DDS block. So it's very important to check this checkbox and set the explicit period to match the Simulink system period if it's not 1. It's worth mentioning that for sampling frequency related issues it's very helpful to turn on "Sample Time Display" (under Format menu) and then update the diagram by pressing CTRL-D. You can easily see if the sample time used for a particular is correct with sampling time displayed on all signals.

FFT: Valid Values of Number of Stages Using Block RAM

2010-07-13T00:40:00.006-04:00

If you have used the FFT block in System Generator, you probably have seen the error message below.

You've got to love these "you-did-something-wrong-but-I-am-not-gonna-tell-you-how-to-fix-it" error messages. If you read through the datasheet, you will find it's not any better as it asks you to run Core Generator to get the valid values for the FFT transform length you chose. I've gone through this quite a few times, so I put together the table below showing valid values of "Number of Stages Using Block RAM" for all supported FFT sizes (data extracted from CoreGen 12.1) for me to use it as a quick reference. I hope this will also save other people a few minutes by not having to run CoreGen to get this simple info which should have been clearly stated in the error message.

FFT Size	Number of Stages Using Block RAM
8	0
16	0
32	0
64	0-1
128	0-2
256	0-3
512	0-4
1024	1-5
2048	2-6
4096	3-7
8192	4-8
16384	5-9
32768	6-10
65536	7-11

FFT results from Matlab fft, Bit Accurate C model and SysGen FFT block

2010-07-04T07:49:00.001-04:00

The usage of the FFT core is straightforward, however, it does have a lot more knobs to turn compared to a simple fft() function in Matlab. Sometimes when the output from the FFT core doesn't match Matlab fft() result you start to question if there is a bug in the FFT core. I will use a simple example here hopefully to

provide some assurance that the result from the FFT core match well with Matlab fft() function and FFT bit accurate C model
provide a starting point so you can look at configurations as well as timing of control and data signals of the core in case you didn't have time to read the FFT core data sheet

Below is the SysGen model that uses a 256-point FFT with pipelined streaming IO and unscaled output in natural order. The input vector is a simple ramp (-128:127)/128 in fixed 16.15 format.

The waveform below shows the FFT signals at the beginning of the simulation in WaveScope (a great tool in Xilinx Blockset for debugging, by the way). Note that in FFT v7.0 and newer, there is no longer a requirement of 3 cycle offset between xn_index and xn_re/xn_im inputs.

The waveform below is at the end of FFT computation and data start to unload. Note that xk_index is incrementing as the core output is in natural order.

The simulation results are collected in workspace. A m script is then run to compare the results from Matlab fft(), FFT bit accurate C model, and the Simulink simulation. Below is an overlay plot showing all three outputs, where the difference is negligible.

The script also prints all elements of outputs side by side for easy comparison.

idx    Matlab       Bit Accurate SysGen
0      1.000000     1.000000     1.000000
1      81.489376    81.489504    81.489595
2      40.747756    40.747746    40.747868
3      27.168581    27.168709    27.168739
4      20.380016    20.380048    20.380078
5      16.307697    16.307667    16.307587
...
251    16.307697    16.307667    16.307545
252    20.380016    20.380048    20.380017
253    27.168581    27.168709    27.168495
254    40.747756    40.747746    40.747960
255    81.489376    81.489504    81.489687

In case you want to play with the example design, you can download it from here. You will need to download the bit accurate C model from FFT core web site yourself because it requires registration.

Calculate OFFSET OUT value

2010-06-12T19:59:00.000-04:00

Let's say on your PCB you have an FPGA that sends data to a DAC like the picture below:

It's clear that you need an OFFSET OUT constraint on the FPGA data output so that the setup and hold times are met on the DAC side. The question is how to calculate the OFFSET OUT value. The best way to figure it out is to draw all clock and data signals at different points on a piece of paper and write down all propagations delays. You can then do the calculation very easily. The picture below shows clock and data signals at the DAC and FPGA:

Now let's plug in all the delay numbers:

CLK_period = 1/64MHz = 15.625ns

CLK_DELAY_PCB is about 1ns (160mm PCB trace at 1ns/6 inches)

DATA_DELAY_PCB is about 1ns (160mm PCB trace at 1ns/6 inches)

SETUP_DAC = 5.3ns

=> FPGA DATA OFFSET OUT 

= CLK period - CLK_DELAY_PCB - DATA_DELAY_PCB - SETUP_DAC 

= 15.625 - 1 - 1 - 5.3

= 8.325 ns

Virtex6 and Spartan6 handbooks - OBSOLETE

2010-06-01T07:01:00.009-04:00

Now that Xilinx Document Navigator is live, I am marking this blog as OBSOLETE. I highly recommend everybody give the Xilinx Document Navigator a try. You will love it.

I always found myself having dozens of Virtex6 and Spartan6 DS/UGs open to get the information I want, so I merged individual PDFs into one document for each family to not only reduce the cluttering on my desktop but also make search a lot easier. The handbooks can be downloaded from the links below in case somebody else may find them useful:

Download

Virtex-6 "Handbook": combined V6 datasheets and user guides, which are the most up-to-date versions as of Aug 4, 2010.

Download Winzip compressed (23MB)

Spartan-6 "Handbook": combined S6 datasheets and user guides, which are the most up-to-date versions as of Aug 4, 2010.

Download Winzip compressed (16MB)

V6 handbook contents:

Name	Version	Date
DS150: Virtex-6 Family Overview http://www.xilinx.com/support/documentation/data_sheets/ds150.pdf	2.2	Jan 29, 2010
UG362 Virtex-6 FPGA Clocking Resources User Guide http://www.xilinx.com/support/documentation/user_guides/ug362.pdf	1.5	Aug 16, 2010
UG364 Virtex-6 FPGA Configurable Logic Block User Guide http://www.xilinx.com/support/documentation/user_guides/ug364.pdf	1.1	Sep 16, 2009
UG363 Virtex-6 FPGA Memory Resources User Guide http://www.xilinx.com/support/documentation/user_guides/ug363.pdf	1.5	Aug 3, 2010
UG361 Virtex-6 FPGA SelectIO Resources User Guide http://www.xilinx.com/support/documentation/user_guides/ug361.pdf	1.3	Aug 16, 2010
UG369 Virtex-6 FPGA DSP48E1 Slice User Guide http://www.xilinx.com/support/documentation/user_guides/ug369.pdf	1.2	Sep 16, 2009
UG370 Virtex-6 FPGA System Monitor User Guide http://www.xilinx.com/support/documentation/user_guides/ug370.pdf	1.1	Jun 14, 2010
UG368 Virtex-6 FPGA Embedded Tri-Mode Ethernet MAC User Guide http://www.xilinx.com/support/documentation/user_guides/ug368.pdf	1.2	Jan 17, 2010
UG366 Virtex-6 FPGA GTX Transceivers User Guide http://www.xilinx.com/support/documentation/user_guides/ug366.pdf	2.4	Oct 1, 2010
UG371 Virtex-6 FPGA GTH Transceivers User Guide http://www.xilinx.com/support/documentation/user_guides/ug371.pdf	2.1	Oct 4, 2010
UG373 Virtex-6 FPGA PCB Design Guide http://www.xilinx.com/support/documentation/user_guides/ug373.pdf	1.2	Jun 10, 2010
UG360 Virtex-6 FPGA Configuration User Guide http://www.xilinx.com/support/documentation/user_guides/ug360.pdf	3.2	Nov 1, 2010
DS152 Virtex-6 FPGA Data Sheet: DC and Switching Characteristics http://www.xilinx.com/support/documentation/data_sheets/ds152.pdf	2.10	Oct 18, 2010

S6 handbook contents:

Name	Version	Date
DS160: Spartan-6 Family Overview http://www.xilinx.com/support/documentation/data_sheets/ds160.pdf	1.5	Aug 2, 2010
UG382 Spartan-6 FPGA Clocking Resources User Guide http://www.xilinx.com/support/documentation/user_guides/ug382.pdf	1.4	Aug 24, 2010
UG384 Spartan-6 FPGA Configurable Logic Block User Guide http://www.xilinx.com/support/documentation/user_guides/ug384.pdf	1.1	Feb 23, 2010
UG383 Spartan-6 FPGA Block RAM Resources User Guide http://www.xilinx.com/support/documentation/user_guides/ug383.pdf	1.3	Oct 13, 2010
UG381 Spartan-6 FPGA SelectIO Resources User Guide http://www.xilinx.com/support/documentation/user_guides/ug381.pdf	1.3	Mar 15, 2010
UG389 Spartan-6 FPGA DSP48A1 Slice User Guide http://www.xilinx.com/support/documentation/user_guides/ug389.pdf	1.1	Aug 13, 2009
UG388 Spartan-6 FPGA Memory Controller User Guide http://www.xilinx.com/support/documentation/user_guides/ug388.pdf	2.3	Aug 9,2010
UG386 Spartan-6 FPGA GTP Transceivers User Guide http://www.xilinx.com/support/documentation/user_guides/ug386.pdf	2.2	Apr 30, 2010
UG393 Spartan-6 FPGA PCB Design and Pin Planning Guide http://www.xilinx.com/support/documentation/user_guides/ug393.pdf	1.2	Jul 15, 2010
UG394 Spartan-6 FPGA Power Management User Guide http://www.xilinx.com/support/documentation/user_guides/ug394.pdf	1.0	May 18, 2010
UG380 Spartan-6 FPGA Configuration User Guide http://www.xilinx.com/support/documentation/user_guides/ug380.pdf	2.2	Jul 30, 2010
DS162 Spartan-6 FPGA Data Sheet: DC and Switching Characteristics http://www.xilinx.com/support/documentation/data_sheets/ds162.pdf	1.9	Aug 23, 2010

Cool Programs in My Toolbox

2010-04-04T15:21:00.006-04:00

Over years I have installed many cool little programs on my machine. They become handy for so many different things. I had to rebuild my computer recently and took me a while to google the Internet to find all the goodies. It occurred to me that it would be handy if I build a list for all these programs and put it somewhere I can easily access. And here the list goes (I will add things as I go, so it will always be work-in-progress):

Agent Ransack: search for files based on file names and/or particular string pattern in file contents
CutePDF: print anything to a PDF file

CCleaner:cleaning registry, temporary files, etc on Windows

Free Launch Bar: A much better replacement of Windows Quick Launch Bar that allows you to group programs
http://www.pdfsam.org : Merge and Split PDFs
Rapid Environment Editor : Very nice GUI for setting and editing environment variables
ScreenHunter Free: Screen capture tool
WireShark : Network sniffer for debugging Ethernet designs

Spartan6 Configuration Examples

2010-01-12T23:05:00.003-05:00

The web links below will bring you directly to the block diagram for the selected configuration mode in the "Spartan6 FPGA Configuration User Guide" (UG380 v1.0 Jun 24, 2009). This is also the landing page for ADEPT (website and blog) when the "Example" button on the "Special Pin Setup" window is pressed.

SysGen: Create New HWCOSIM Target with NMM Ports

2009-12-16T23:56:00.005-05:00

Hardware Co-Simulation (HWCOSIM) is a great feature in System Generator (SysGen) that allows users to run the full or part of a SysGen design on the FPGA and increase the simulation speed dramatically. SysGen already includes HWCOSIM plugins for commonly used DSP demo boards. Users can easily use the SysGen Board Description Builder (SBDBuilder) to create new HWCOSIM plugins for unsupported boards or unsupported features (for example non-memory mapped or NMM ports) on existing boards. Below are step-by-step instructions on how to create a new HWCOSIM plugin with NMM ports using ML506 as an example.

Step 1: Open "System Generator" properties window and select "New Compilation Target".

Step 2: The SBDBuilder window pops up.
Board Name: use a descriptive name so you know what the target is later.
System Clock Frequency/Pin Location: enter the actual clock frequency and pin location for your board.
JTAG Options Boundary Scan Position: the position of the target device in the JTAG chain. You can use IMPACT to help fill this in (see a snapshot below for the JTAG chain detected by IMPACT). As shown in the JTAG chain snapshot, the target device xc5vsx50t is the 5th in the chain.
JTAG Options IR Lengths: click the "Detect" button next to it auto-fill it.
Target Devices: click "Add" button to select the target device.

Step 3: Click "Add" button in the "Non-Memory Mapped Ports" section to add NMM ports for HWCOSIM. This brings up the "Configure a Port" window below. Enter a port name, select port direction, Pin LOC and select PULLUP or PULLDOWN if needed. Click "Add Pin" button and the newly added pin will show up in the Pin List below. Click "Save and Start New" button if you want to add more pins or click "Save and Close" if you are done adding NMM ports.

Step 4: The SBDBuilder with all information entered is shown below. Click the "Install" button to install the new board configuration to the SysGen plugins directory.

Step 5: A window with tokens for the NMM ports will pop up once the installation is complete.

Step 6: Save the library with the NMM port tokens and they can now be used in your SysGen model like any other SysGen block. A test model is shown below.

Step 7: Open "System Generator" properties window again and now you should see the newly created board "ML506 JTAG NMM" in the HWCOSIM target list. Select it as the compilation target.

Step 8: That's it. The rest of steps to use the new compilation target are the same as any other HWCOSIM. The only difference is that Simulink no longer has control/visibility of the two NMM ports. They are now implemented as IOs on FPGA. In this example, while the simulation is running, if you toggle the GPIO SW1 on the board, it will turn on/off the GPIO LED0.

IFFT in System Generator

2009-11-28T10:58:00.075-05:00

The FFT block in Xilinx Blockset can be used to calculate both DFT and IDFT because the two equations are almost identical:

By default, the FFT block is configured to calculate DFT. The setup and timing of control/data signals for IDFT are the same as DFT except for two things:

The FFT block needs to be set up for IDFT by setting fwd_inv_we signal to 1 and fwd_inv signal to 0 before the start of the transform
The FFT output needs to be manually scaled to account for the factor 1/N in Equation 2 above. The scaling can be done either by using the scaling schedule input or shifting the FFT output if the FFT block is set to "unscaled".

The picture below shows the timing of control/data signals at the beginning of a data frame.

Now let's use a simple 8-point IDFT example to show how everything is put together. Below is the IDFT calculation of a test vector xn_re in Matlab:

>>xn_re=[0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8];
>>ifft(xn_re)
ans =
Columns 1 through 5
0.4500  -0.0500-0.1207i  -0.0500-0.0500i  -0.0500-0.0207i 0.0500          

Columns 6 through 8
-0.0500+0.0207i  -0.0500+0.0500i  -0.0500+0.1207i

The idft_test simulink/sysgen model for the 8-point can be downloaded here. The model includes a block called WaveScope, which is a "hidden" gem in System Generator for debugging SysGen designs, especially for hardware engineers who are used to viewing waveforms in HDL simulators.

The picture below shows the waveform at the beginning of the simulation in Wavescope. fwd_inv_we=1 and fwd_inv=0 for 1 cycle to set up the block for IDFT. Also the scale_sch is set to "010101" at the beginning to scale the FFT result down by 8 (the 1/N factor in Equation 2).

The picture below shows the waveform in Wavescope at the end of simulation, which shows that the xk_re and xk_im outputs when dv=1 match the Matlab results above when taking the quantization errors into account.

Really impressed with 7-Zip

2009-11-24T21:39:00.054-05:00

Update Aug 20, 2011: Just found out that 7-Zip can also extract CD/DVD image files (.iso). Nice! Below are all the file formats it supports:

Packing / unpacking: 7z, XZ, BZIP2, GZIP, TAR, ZIP and WIM
Unpacking only: ARJ, CAB, CHM, CPIO, CramFS, DEB, DMG, FAT, HFS, ISO, LZH, LZMA, MBR, MSI, NSIS, NTFS, RAR, RPM, SquashFS, UDF, VHD, WIM, XAR and Z.

I have been using Winzip to compress files for as long as I can remember. One of my colleagues mentioned another compression tool called 7-Zip to me a couple of weeks ago and I am really impressed with the high compression ratio achieved by 7-Zip. Besides it's free and supports all compression file formats (.zip, .rar, .gz, .7z) that I know of. Below is a chart that compares the compressed file sizes between Winzip 10 and 7-Zip 4.65 on several files that I use for my daily work:

File	Uncompressed	.zip	.7z	%smaller
Virtex-6 UG365	15.8MB	5.4MB	4MB	26%
ADEPT 0.38.6	12.6MB	5.3MB	4.4MB	17%
SP601 Base Reference Design rdf0003	56.3MB	17.5MB	10MB	43%

Don't optimize my LUT please!

2009-10-27T05:40:00.006-04:00

Sometimes you manually instantiate a LUT primitive (e.g. LUT6_2) to add routing delays to the signal path or precisely control the routing resources used but only to find out that the tool either optimizes it out or swaps pins. This can be prevented by using the LOCK_PINS and SAVE NET FLAG (S) constraints (Xilinx Constrants Guide). Below are the code snippets for Verilog and VHDL that work in ISE 11.3:

Verilog Example (download luts_vlog.v):
(* S="TRUE" *) reg [5:0] lut_in_r;

(* LOCK_PINS="ALL", BEL="A6LUT" *)
LUT6_2 #(
    .INIT (64'h0000_0000_0000_0001)
) LUT_U0 (
    .I0 (lut_in_r[0]),
    .I1 (lut_in_r[1]),
    .I2 (lut_in_r[2]),
    .I3 (lut_in_r[3]),
    .I4 (lut_in_r[4]),
    .I5 (1'b1       ),
    .O5 (lut_out5_d ),
    .O6 (lut_out6_d )
);

VHDL Example (download luts_vhd.vhd):
attribute LOCK_PINS : string;
attribute BEL       : string;
attribute S         : string;
attribute BEL       of LUT_U0   : label is "A6LUT";
attribute LOCK_PINS of LUT_U0   : label is "ALL";
attribute S         of lut_in_r : signal is "TRUE";

LUT_U0: LUT6_2
    generic map (
        INIT => X"0000000000000001"
    )
    port map (
        I0 => lut_in_r(0),
        I1 => lut_in_r(1),
        I2 => lut_in_r(2),
        I3 => lut_in_r(3),
        I4 => lut_in_r(4),
        I5 => '1',
        O5 => lut_out5_d,
        O6 => lut_out6_d
    );

After synthesis, you should see messages like below showing that XST picked up the design constraints:
Set user-defined property "S = TRUE" for signal .

Set user-defined property "BEL =  A6LUT" for instance  in unit .

Set user-defined property "LOCK_PINS =  ALL" for instance  in unit .

After the implementation is done, open the design in FPGA_EDITOR and check that the placement of the LUT and the pin order match the source code. Below is a snapshot of what it looks like for the example above:

Wait, what about DDR OFFSET IN/OUT using DCM clock with phase shift?

2009-10-11T16:19:00.001-04:00

I recently wrote two blogs about DDR OFFSET constraints:

Looks like I'm going to make a career out of talking about the OFFSET constraints on DDR IOs ;). Here comes another one on DDR IOs clocked by DCM clock with phase shift.

The design example used here is exactly the same as in DDR OFFSET IN/OUT constraints with DCM except that a 30 degree phase shift is added to the DCM CLK0 output. The clock period in this example is 20ns, so 30 degrees phase shift translates to ~1.7ns (20ns*30/360). The timing reports on the OFFSET constraints are almost the same. The only difference is that now a ~1.7ns delay added to the time when the clock rising and falling edges.

Below are the timing reports showing the effect of the 30 degree (or 1.7ns) phase shift (highlighted in red) from the DCM:

Timing constraint: TIMEGRP "TN_ddr_in_pads" OFFSET = IN 5 ns VALID 10 ns BEFORE COMP "clk_i"         "RISING";
1 path analyzed, 1 endpoint analyzed, 0 failing endpoints
0 timing errors detected. (0 setup errors, 0 hold errors)
Minimum allowable offset is   2.718ns.
--------------------------------------------------------------------------------
Slack (setup path):     2.282ns (requirement - (data path - clock path - clock arrival + uncertainty))
Source:               ddr_d_i (PAD)
Destination:          IDDR2_inst (FF)
Destination Clock:    clk1 rising at 1.641ns
Requirement:          5.000ns
Data Path Delay:      2.724ns (Levels of Logic = 2)
Clock Path Delay:     -1.515ns (Levels of Logic = 4)
Clock Uncertainty:    0.120ns

Timing constraint: TIMEGRP "TN_ddr_in_pads" OFFSET = IN 5 ns VALID 10 ns BEFORE COMP "clk_i"         "FALLING";
1 path analyzed, 1 endpoint analyzed, 0 failing endpoints
0 timing errors detected. (0 setup errors, 0 hold errors)
Minimum allowable offset is   2.729ns.
--------------------------------------------------------------------------------
Slack (setup path):      2.271 ns (requirement - (data path - clock path - clock arrival + uncertainty))
Source:                ddr_d_i (PAD)
Destination:           IDDR2_inst (FF)
Destination Clock:    clk1 falling at 1.641ns
Requirement:          5.000ns
Data Path Delay:      2.724ns (Levels of Logic = 2)
Clock Path Delay:     -1.526ns (Levels of Logic = 4)
Clock Uncertainty:    0.120ns

Timing constraint: TIMEGRP "TN_ddr_out_pads" OFFSET = OUT 8 ns AFTER COMP "clk_i" "RISING";
1 path analyzed, 1 endpoint analyzed, 0 failing endpoints
0 timing errors detected.
Minimum allowable offset is   6.846ns.
--------------------------------------------------------------------------------
Slack (slowest paths):   1.154 ns (requirement - (clock arrival + clock path + data path + uncertainty))
Source:                ODDR2_inst (FF)
Destination:           ddr_d_o (PAD)
Source Clock:         clk1 rising at 1.641ns
Requirement:          8.000ns
Data Path Delay:      3.561ns (Levels of Logic = 1)
Clock Path Delay:     1.524ns (Levels of Logic = 4)
Clock Uncertainty:    0.120ns

Timing constraint: TIMEGRP "TN_ddr_out_pads" OFFSET = OUT 8 ns AFTER COMP "clk_i" "FALLING";
1 path analyzed, 1 endpoint analyzed, 0 failing endpoints
0 timing errors detected.
Minimum allowable offset is   6.850ns.
--------------------------------------------------------------------------------
Slack (slowest paths):   1.150 ns (requirement - (clock arrival + clock path + data path + uncertainty))
Source:                ODDR2_inst (FF)
Destination:           ddr_d_o (PAD)
Source Clock:         clk1 falling at 1.641ns
Requirement:          8.000ns
Data Path Delay:      3.579ns (Levels of Logic = 1)
Clock Path Delay:     1.510ns (Levels of Logic = 4)
Clock Uncertainty:    0.120ns

DDR OFFSET IN/OUT constraints with DCM

2009-10-11T15:29:00.005-04:00

UG612: Xilinx Timing Constraints User Guide shows two options to constrain the OFFSET for DDR inputs and outputs. The option 1 is how OFFSET values for DDR IOs are constrained in ISE 9.x and earlier versions. Although it still works in the latest ISE versions (i.e. 10.x and 11.x), but it has always been difficult and painful to use because of a couple of reasons:

The offset values in the OFFSET constraints for the falling edge need to be manually adjusted as the reference point (i.e. time 0) is always the rising edge of the clock.
If the clock for the DDR IOs comes from a DCM, you need to watch out in the ngdbuild report for the TIMESPEC on the DCM input clock not propagated through the DCM due the TNM used in more than one constraint.

With that, I highly recommend the option 2 for people using the latest IDS. Below is a Spartan6 example with IDDR, ODDR, and DCM:

Design top level:

module ss_ddr (
     input  clk_i,
     input  rst_i,
     input  ddr_d_i,
     output ddr_d_o
);

wire clk0, clk180;
wire clkgen1_locked;
wire d_rising_d, d_falling_d;
reg d_rising_r, d_falling_r;

clkgen_dcm clkgen1 (
   // Clock in ports
  .CLK_IN1 (clk_i),
  // Clock out ports
  .CLK_OUT1 (clk1),
  .CLK_OUT2 (clk2),
  // Status and control signals
  .RESET    (rst_i),
  .LOCKED   (clkgen1_locked)
 );

assign clk0 = clk1;
assign clk180 = ~clk1;
    
IDDR2 #(
   .DDR_ALIGNMENT ("NONE"), // Sets output alignment to "NONE", "C0" or "C1" 
   .INIT_Q0       (1'b0), // Sets initial state of the Q0 output to 1'b0 or 1'b1
   .INIT_Q1       (1'b0), // Sets initial state of the Q1 output to 1'b0 or 1'b1
   .SRTYPE        ("SYNC") // Specifies "SYNC" or "ASYNC" set/reset
) IDDR2_inst (
   .Q0 (d_rising_d), // 1-bit output captured with C0 clock
   .Q1 (d_falling_d), // 1-bit output captured with C1 clock
   .C0 (clk0), // 1-bit clock input
   .C1 (clk180), // 1-bit clock input
   .CE (1'b1), // 1-bit clock enable input
   .D  (ddr_d_i),   // 1-bit DDR data input
   .R  (1'b0),   // 1-bit reset input
   .S  (1'b0)    // 1-bit set input
);


always @(posedge clk0)
    d_rising_r <= d_rising_d;

always @(posedge clk180)
    d_falling_r <= d_falling_d;


ODDR2 #(
      .DDR_ALIGNMENT ("NONE"), // Sets output alignment to "NONE", "C0" or "C1" 
      .INIT          (1'b0),    // Sets initial state of the Q output to 1'b0 or 1'b1
      .SRTYPE        ("SYNC") // Specifies "SYNC" or "ASYNC" set/reset
   ) ODDR2_inst (
      .Q  (ddr_d_o),   // 1-bit DDR output data
      .C0 (clk0),   // 1-bit clock input
      .C1 (clk180),   // 1-bit clock input
      .CE (1'b1), // 1-bit clock enable input
      .D0 (d_rising_r), // 1-bit data input (associated with C0)
      .D1 (d_falling_r), // 1-bit data input (associated with C1)
      .R  (1'b0),   // 1-bit reset input
      .S  (1'b0)    // 1-bit set input
 );

endmodule

UCF constraints:

NET "clk_i" TNM_NET = "TN_clk_i";
TIMESPEC TS_clk_i = PERIOD "TN_clk_i" 20 ns HIGH 50%;

#UG612: Option 2
INST "ddr_d_i" TNM = TN_ddr_in_pads;
TIMEGRP "TN_ddr_in_pads" OFFSET = IN 5 ns VALID 10 ns BEFORE "clk_i" RISING;
TIMEGRP "TN_ddr_in_pads" OFFSET = IN 5 ns VALID 10 ns BEFORE "clk_i" FALLING;

INST "ddr_d_o" TNM = TN_ddr_out_pads;
TIMEGRP "TN_ddr_out_pads" OFFSET = OUT 8 ns AFTER "clk_i" RISING;
TIMEGRP "TN_ddr_out_pads" OFFSET = OUT 8 ns AFTER "clk_i" FALLING;

Timing reports: (only OFFSET OUT reports are shown below. Please check this older blog for the OFFSET IN reports)

Timing constraint: TIMEGRP "TN_ddr_out_pads" OFFSET = OUT 8 ns AFTER COMP "clk_i" "RISING";
 1 path analyzed, 1 endpoint analyzed, 0 failing endpoints
 0 timing errors detected.
 Minimum allowable offset is   5.205ns.
--------------------------------------------------------------------------------
Slack (slowest paths):  2.795ns (requirement - (clock arrival + clock path + data path + uncertainty))
  Source:               ODDR2_inst (FF)
  Destination:          ddr_d_o (PAD)
  Source Clock:         clk1 rising at 0.000ns
  Requirement:          8.000ns
  Data Path Delay:      3.561ns (Levels of Logic = 1)
  Clock Path Delay:     1.524ns (Levels of Logic = 4)
  Clock Uncertainty:    0.120ns

  Clock Uncertainty:          0.120ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.120ns
    Phase Error (PE):           0.060ns

  Maximum Clock Path: clk_i to ODDR2_inst
    Location             Delay type         Delay(ns)  Logical Resource(s)
    -------------------------------------------------  -------------------
    N4.I                 Tiopi                 1.140   clk_i
                                                       clkgen1/clkin1_buf
                                                       ProtoComp0.IMUX
    BUFIO2_X1Y15.I       net (fanout=1)        0.418   clkgen1/clkin1
    BUFIO2_X1Y15.DIVCLK  Tbufcko_DIVCLK        0.070   SP6_BUFIO_INSERT_ML_BUFIO2_5
    DCM_X0Y1.CLKIN       net (fanout=1)        0.854   clkgen1/dcm_sp_inst_ML_NEW_DIVCLK
    DCM_X0Y1.CLK0        Tdmcko_CLK           -3.868   clkgen1/dcm_sp_inst
    BUFGMUX_X2Y3.I0      net (fanout=1)        0.943   clkgen1/clk0
    BUFGMUX_X2Y3.O       Tgi0o                 0.239   clkgen1/clkout1_buf
    OLOGIC_X0Y10.CLK0    net (fanout=7)        1.728   clk1
    -------------------------------------------------  ---------------------------
    Total                                      1.524ns (-2.419ns logic, 3.943ns route)

  Maximum Data Path: ODDR2_inst to ddr_d_o
    Location             Delay type         Delay(ns)  Logical Resource(s)
    -------------------------------------------------  -------------------
    OLOGIC_X0Y10.OQ      Tockq                 0.775   ODDR2_inst
    V3.O                 net (fanout=1)        0.296   ddr_d_o_OBUF
    V3.PAD               Tioop                 2.490   ddr_d_o_OBUF
                                                       ddr_d_o
    -------------------------------------------------  ---------------------------
    Total                                      3.561ns (3.265ns logic, 0.296ns route)
                                                       (91.7% logic, 8.3% route)

iming constraint: TIMEGRP "TN_ddr_out_pads" OFFSET = OUT 8 ns AFTER COMP "clk_i" "FALLING";
 1 path analyzed, 1 endpoint analyzed, 0 failing endpoints
 0 timing errors detected.
 Minimum allowable offset is   5.209ns.
--------------------------------------------------------------------------------
Slack (slowest paths):  2.791ns (requirement - (clock arrival + clock path + data path + uncertainty))
  Source:               ODDR2_inst (FF)
  Destination:          ddr_d_o (PAD)
  Source Clock:         clk1 falling at 0.000ns
  Requirement:          8.000ns
  Data Path Delay:      3.579ns (Levels of Logic = 1)
  Clock Path Delay:     1.510ns (Levels of Logic = 4)
  Clock Uncertainty:    0.120ns

  Clock Uncertainty:          0.120ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter (TSJ):  0.000ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.120ns
    Phase Error (PE):           0.060ns

  Maximum Clock Path: clk_i to ODDR2_inst
    Location             Delay type         Delay(ns)  Logical Resource(s)
    -------------------------------------------------  -------------------
    N4.I                 Tiopi                 1.140   clk_i
                                                       clkgen1/clkin1_buf
                                                       ProtoComp0.IMUX
    BUFIO2_X1Y15.I       net (fanout=1)        0.418   clkgen1/clkin1
    BUFIO2_X1Y15.DIVCLK  Tbufcko_DIVCLK        0.070   SP6_BUFIO_INSERT_ML_BUFIO2_5
    DCM_X0Y1.CLKIN       net (fanout=1)        0.854   clkgen1/dcm_sp_inst_ML_NEW_DIVCLK
    DCM_X0Y1.CLK0        Tdmcko_CLK           -3.868   clkgen1/dcm_sp_inst
    BUFGMUX_X2Y3.I0      net (fanout=1)        0.943   clkgen1/clk0
    BUFGMUX_X2Y3.O       Tgi0o                 0.239   clkgen1/clkout1_buf
    OLOGIC_X0Y10.CLK1    net (fanout=7)        1.714   clk1
    -------------------------------------------------  ---------------------------
    Total                                      1.510ns (-2.419ns logic, 3.929ns route)

  Maximum Data Path: ODDR2_inst to ddr_d_o
    Location             Delay type         Delay(ns)  Logical Resource(s)
    -------------------------------------------------  -------------------
    OLOGIC_X0Y10.OQ      Tockq                 0.793   ODDR2_inst
    V3.O                 net (fanout=1)        0.296   ddr_d_o_OBUF
    V3.PAD               Tioop                 2.490   ddr_d_o_OBUF
                                                       ddr_d_o
    -------------------------------------------------  ---------------------------
    Total                                      3.579ns (3.283ns logic, 0.296ns route)
                                                       (91.7% logic, 8.3% route)

OK, I know this blog is long, but here comes the reward for those who stick around: the complete ISE project targeting Spartan6 6slx45t is available for download here.

OFFSET IN constraints for source synchronous DDR inputs

2009-10-05T22:38:00.010-04:00

There are several ways to set up OFFSET IN constraints for source synchronous DDR inputs. Personally I like to put all inputs into a timing group and add OFFSET IN constraint on the timing group. There are several advantages with this method:

Inputs with different names can be easily grouped together.
Only one (SDR) or two (DDR) OFFSET IN constraints are required for each timing group.
Timing report is more concise because of fewer OFFSET IN constraints required.

Below is a Spartan6 design example with just one IDDR2 primitive instantiated:

module ss_ddr_in (
     input  clk_i,
     input  ddr_d_i,
     output d_rising_o,
     output d_falling_o
);

wire clk0, clk180;

assign clk0 = clk_i;
assign clk180 = ~clk_i;
    
IDDR2 #(
   .DDR_ALIGNMENT ("NONE"), // Sets output alignment to "NONE", "C0" or "C1" 
   .INIT_Q0       (1'b0), // Sets initial state of the Q0 output to 1'b0 or 1'b1
   .INIT_Q1       (1'b0), // Sets initial state of the Q1 output to 1'b0 or 1'b1
   .SRTYPE        ("SYNC") // Specifies "SYNC" or "ASYNC" set/reset
) IDDR2_inst (
   .Q0 (d_rising_o), // 1-bit output captured with C0 clock
   .Q1 (d_falling_o), // 1-bit output captured with C1 clock
   .C0 (clk0), // 1-bit clock input
   .C1 (clk180), // 1-bit clock input
   .CE (1'b1), // 1-bit clock enable input
   .D  (ddr_d_i),   // 1-bit DDR data input
   .R  (1'b0),   // 1-bit reset input
   .S  (1'b0)    // 1-bit set input
);

endmodule

Below are UCF constraints for the data input.

NET "clk_i" TNM_NET = clk_i;
TIMESPEC TS_clk_i = PERIOD "clk_i" 20 ns HIGH 50%;

INST "ddr_d_i" TNM = TN_ddr_in_pads;
TIMEGRP "TN_ddr_in_pads" OFFSET = IN 5 ns VALID 10 ns BEFORE "clk_i" RISING;
TIMEGRP "TN_ddr_in_pads" OFFSET = IN 5 ns VALID 10 ns BEFORE "clk_i" FALLING;

Timing report on the OFFSET constraints:

Timing constraint: TIMEGRP "TN_ddr_in_pads" OFFSET = IN 5 ns VALID 10 ns BEFORE COMP "clk_i"         "RISING";
 1 path analyzed, 1 endpoint analyzed, 0 failing endpoints
 0 timing errors detected. (0 setup errors, 0 hold errors)
 Offset is  -0.666ns.
--------------------------------------------------------------------------------
Slack (setup path):     5.666ns (requirement - (data path - clock path - clock arrival + uncertainty))
  Source:               ddr_d_i (PAD)
  Destination:          IDDR2_inst (FF)
  Destination Clock:    clk_i_BUFGP rising at 0.000ns
  Requirement:          5.000ns
  Data Path Delay:      2.724ns (Levels of Logic = 2)
  Clock Path Delay:     3.390ns (Levels of Logic = 2)
  Clock Uncertainty:    0.000ns

  Maximum Data Path: ddr_d_i to IDDR2_inst
    Location             Delay type         Delay(ns)  Logical Resource(s)
    -------------------------------------------------  -------------------
    W4.I                 Tiopi                 1.140   ddr_d_i
                                                       ddr_d_i_IBUF
                                                       ProtoComp0.IMUX.1
    ILOGIC_X0Y7.D        net (fanout=1)        0.128   ddr_d_i_IBUF
    ILOGIC_X0Y7.CLK0     Tidock                1.456   ProtoComp2.D2OFFBYP_SRC
                                                       IDDR2_inst
    -------------------------------------------------  ---------------------------
    Total                                      2.724ns (2.596ns logic, 0.128ns route)
                                                       (95.3% logic, 4.7% route)

  Minimum Clock Path: clk_i to IDDR2_inst
    Location             Delay type         Delay(ns)  Logical Resource(s)
    -------------------------------------------------  -------------------
    N4.I                 Tiopi                 1.049   clk_i
                                                       SP6_AUTOBUF_BUFGP_ML_IBUF_4
                                                       ProtoComp0.IMUX
    BUFGMUX_X3Y13.I0     net (fanout=1)        0.747   SP6_AUTOBUF_BUFGP_ML_IBUF_4_ML_NEW_I
    BUFGMUX_X3Y13.O      Tgi0o                 0.220   clk_i_BUFGP
    ILOGIC_X0Y7.CLK0     net (fanout=2)        1.374   clk_i_BUFGP
    -------------------------------------------------  ---------------------------
    Total                                      3.390ns (1.269ns logic, 2.121ns route)
                                                       (37.4% logic, 62.6% route)

Timing constraint: TIMEGRP "TN_ddr_in_pads" OFFSET = IN 5 ns VALID 10 ns BEFORE COMP "clk_i"         "FALLING";
 1 path analyzed, 1 endpoint analyzed, 0 failing endpoints
 0 timing errors detected. (0 setup errors, 0 hold errors)
 Offset is  -0.666ns.
--------------------------------------------------------------------------------
Slack (setup path):     5.666ns (requirement - (data path - clock path - clock arrival + uncertainty))
  Source:               ddr_d_i (PAD)
  Destination:          IDDR2_inst (FF)
  Destination Clock:    clk_i_BUFGP falling at 0.000ns
  Requirement:          5.000ns
  Data Path Delay:      2.724ns (Levels of Logic = 2)
  Clock Path Delay:     3.390ns (Levels of Logic = 2)
  Clock Uncertainty:    0.000ns

  Maximum Data Path: ddr_d_i to IDDR2_inst
    Location             Delay type         Delay(ns)  Logical Resource(s)
    -------------------------------------------------  -------------------
    W4.I                 Tiopi                 1.140   ddr_d_i
                                                       ddr_d_i_IBUF
                                                       ProtoComp0.IMUX.1
    ILOGIC_X0Y7.D        net (fanout=1)        0.128   ddr_d_i_IBUF
    ILOGIC_X0Y7.CLK1     Tidock                1.456   ProtoComp2.D2OFFBYP_SRC
                                                       IDDR2_inst
    -------------------------------------------------  ---------------------------
    Total                                      2.724ns (2.596ns logic, 0.128ns route)
                                                       (95.3% logic, 4.7% route)

  Minimum Clock Path: clk_i to IDDR2_inst
    Location             Delay type         Delay(ns)  Logical Resource(s)
    -------------------------------------------------  -------------------
    N4.I                 Tiopi                 1.049   clk_i
                                                       SP6_AUTOBUF_BUFGP_ML_IBUF_4
                                                       ProtoComp0.IMUX
    BUFGMUX_X3Y13.I0     net (fanout=1)        0.747   SP6_AUTOBUF_BUFGP_ML_IBUF_4_ML_NEW_I
    BUFGMUX_X3Y13.O      Tgi0o                 0.220   clk_i_BUFGP
    ILOGIC_X0Y7.CLK1     net (fanout=2)        1.374   clk_i_BUFGP
    -------------------------------------------------  ---------------------------
    Total                                      3.390ns (1.269ns logic, 2.121ns route)
                                                       (37.4% logic, 62.6% route)

Please note that ISE continues to improve the constraint syntax and report format, so you may see things work slightly differently in previous versions of ISE.

Below is a list of references that can be very useful:

OFFSET IN constraints on diff inputs ignored in IDS 11.3. Fixed in 12.4

2009-09-28T21:28:00.005-04:00

Below is a simple test case with differential input clock and data.

`timescale 1ns / 1ps

module s3a_ibufds (
    input  clk_i_p, clk_i_n,
    input  d_i_p, d_i_n,                      
    output d_o_p, d_o_n                      
    );


wire d_in, clk_in;
reg d_r1, d_r2;

IBUFDS #(
   .IBUF_DELAY_VALUE("0"),    // Specify the amount of added input delay for
                              //    the buffer: "0"-"16" (Spartan-3A)
   .IFD_DELAY_VALUE("AUTO"),  // Specify the amount of added delay for input
                              //    register: "AUTO", "0"-"8" (Spartan-3A)
   .IOSTANDARD("DEFAULT")     // Specify the input I/O standard
) IBUFDS_clk (
   .O  (clk_in),  // Buffer output
   .I  (clk_i_p),  // Diff_p buffer input (connect directly to top-level port)
   .IB (clk_i_n) // Diff_n buffer input (connect directly to top-level port)
);

IBUFDS #(
   .IBUF_DELAY_VALUE("0"),    // Specify the amount of added input delay for
                              //    the buffer: "0"-"16" (Spartan-3A)
   .IFD_DELAY_VALUE("AUTO"),  // Specify the amount of added delay for input
                              //    register: "AUTO", "0"-"8" (Spartan-3A)
   .IOSTANDARD("DEFAULT")     // Specify the input I/O standard
) IBUFDS_d (
   .O  (d_in),  // Buffer output
   .I  (d_i_p),  // Diff_p buffer input (connect directly to top-level port)
   .IB (d_i_n) // Diff_n buffer input (connect directly to top-level port)
);


always @(posedge clk_in) begin
    d_r1 <= d_in;
    d_r2 <= d_r1;
end

assign d_o_p = d_r2;

endmodule

When the OFFSET IN constraints are specified with input nets, they are simply ignored by the timing analyzer in ISE 11.3 (see UCF constraints and TA snapshot below):

NET "clk_i_p" TNM_NET = clk_i_p;
TIMESPEC TS_clk_i_p = PERIOD "clk_i_p" 20 ns HIGH 50%;
NET "d_i_p" OFFSET = IN 2 ns VALID 4 ns BEFORE "clk_i_p" RISING;
NET "d_i_n" OFFSET = IN 2 ns VALID 4 ns BEFORE "clk_i_p" RISING;

This is probably caused by a bug in TA. As a workaround, the OFFSET IN constraints can be also specified with TIMEGRP and the tool will correctly analyze the timing constraint (see the UCF constraints and TA snapshot below).
[Update Feb 10th, 2011: Verified that the bug has been fixed in IDS 12.4] The project archive can be downloaded here in case anybody is interested.

NET "clk_i_p" TNM_NET = clk_i_p;
TIMESPEC TS_clk_i_p = PERIOD "clk_i_p" 20 ns HIGH 50%;

INST "d_i_p" TNM = TN_d_pads;
INST "d_i_n" TNM = TN_d_pads;
TIMEGRP "TN_d_pads" OFFSET = IN 2 ns VALID 4 ns BEFORE clk_i_p;

Virtex6 Configuration Examples

2009-09-23T23:56:00.008-04:00

The web links below will bring you directly to the block diagram for the selected configuration mode from the "Virtex6 FPGA Configuration User Guide" (UG360 v2.0 Nov 15, 2009). This is also the landing page for ADEPT (website and blog) when the "Example" button on the "Special Pin Setup" window is pressed.

Virtex4 ODDR tristate control

2009-09-18T22:19:00.000-04:00

The tristate control of the tristate buffer in IOB is active low. It's important to code this in RTL for the tool to correctly implement it in HW. e.g.

assign dqbit = (ts_ddrbit == 1'b0) ? out_ddrbit : 1'bz;

A code example with IDDR, ODDRs for both the data and tristate control in Virtex4 is shown below. It's tested with Xilinx IDS 11.3.


`timescale 1ns / 1ps

module tristate_oddr(
    input iddr_clk,
    input oddr_clk,
    inout dqbit,
    input ts_ddrbit1,
  input ts_ddrbit2,
  input dq_bit1,
  input dq_bit2,
 
    output test_out1,
  output test_out2
    );

wire out_ddrbit, ts_ddr_bit;

ODDR #(
    .DDR_CLK_EDGE("OPPOSITE_EDGE"), // "OPPOSITE_EDGE" or "SAME_EDGE"
    .INIT   (1'b0), // Initial value of Q: 1’b0 or 1’b1
    .SRTYPE ("SYNC") // Set/Reset type: "SYNC" or "ASYNC"
) oddr_out_ddrbit (
    .Q  (out_ddrbit), // 1-bit DDR output
    .C  (oddr_clk), // 1-bit clock input
    .CE (1'b1), // 1-bit clock enable input
    .D1 (dq_bit1), // 1-bit data input (positive edge)
    .D2 (dq_bit2), // 1-bit data input (negative edge)
    .R  (1'b0), // 1-bit reset
    .S  (1'b0) // 1-bit set
);

ODDR #(
    .DDR_CLK_EDGE("OPPOSITE_EDGE"), // "OPPOSITE_EDGE" or "SAME_EDGE"
    .INIT   (1'b0), // Initial value of Q: 1’b0 or 1’b1
    .SRTYPE ("SYNC") // Set/Reset type: "SYNC" or "ASYNC"
) oddr_ts_ddrbit (
    .Q  (ts_ddrbit), // 1-bit DDR output
    .C  (oddr_clk), // 1-bit clock input
    .CE (1'b1), // 1-bit clock enable input
    .D1 (ts_ddrbit1), // 1-bit data input (positive edge)
    .D2 (ts_ddrbit2), // 1-bit data input (negative edge)
    .R  (1'b0), // 1-bit reset
    .S  (1'b0) // 1-bit set
);


//IMPORTANT: the tristate control of the tristate buffer in IOB is active low.
assign dqbit = (ts_ddrbit == 1'b0) ? out_ddrbit : 1'bz;


IDDR #(
    .DDR_CLK_EDGE ("OPPOSITE_EDGE"), // "OPPOSITE_EDGE", "SAME_EDGE"
    // or "SAME_EDGE_PIPELINED"
    .INIT_Q1 (1'b0), // Initial value of Q1: 1’b0 or 1’b1
    .INIT_Q2 (1'b0), // Initial value of Q2: 1’b0 or 1’b1
    .SRTYPE  ("SYNC") // Set/Reset type: "SYNC" or "ASYNC"
) IDDR_dqbit (
    .Q1 (test_out1), // 1-bit output for positive edge of clock
    .Q2 (test_out2), // 1-bit output for negative edge of clock
    .C  (iddr_clk), // 1-bit clock input
    .CE (1'b1), // 1-bit clock enable input
    .D  (dqbit), // 1-bit DDR data input
    .R  (1'b0), // 1-bit reset
    .S  (1'b0) // 1-bit set
);

endmodule

Below is what the implementation looks like in FPGA_EDITOR:

IDDR, ODDR and IOBUF:

Inside ODDR:

Inside IOB: