FFT Core Settings v.s Resources and Performance

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 different FFT architectures, bit widths, output orders, etc.

Set up Xilinx IDS environment for non-IDS tools

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.

IFFT with Symmetric Input in System Generator

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

SysGen xlGenerateButton function example

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:

1. Open the model system_period_test 
2. Select the System Generator token by clicking on it
3. 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

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.