UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor aponchak
Visitor
204 Views
Registered: ‎04-07-2010

Map fails for FFT v7.1, yet the Coregen reported "Resource Estimates" are well below what is actually available on the Spartan 6 LX25

Via (ISE 14.7) Core Generator, I created an FFT v7.1 core targeting a Spartan 6 LX25. The core is configured to minimize its resource utilization (its .xco is at the bottom). Coregen reports that the generated FFT core's "resource estimates" are:

9k Block RAMs, Qty 80

WIth the FFT included in the design, map fails claiming overmapping onf RAMB16BWERs:

Number of RAMB16BWERs:                        74 out of      52  142% (OVERMAPPED)
  Number of RAMB8BWERs:                          0 out of     104    0%

What's strange is that none of the RAMB8BWERs are being used, aren't these the 9k Block RAMs that Coregen is referring to?

 

In the Spartan 6 family datasheet, https://www.xilinx.com/support/documentation/data_sheets/ds160.pdf, Table 1 says:

a) The LX25 has 52 18kb Block RAMs.

b) Note 4 says "Block RAMs are fundamentally 18 Kb in size. Each block can also be used as two independent 9 Kb blocks."

 

Question:

1) If the LX25 has 52 18Kb (or RAMB16BWER), then shouldn't an FFT of size 80 9Kb (or 40 18Kb Block RAMs) map successfully?

2) Why are the 9k Block RAMs of the FFT being mapped to RAMB16BWERs? As shown in the Tranlate Report:

   'inst_controller_main/inst_fft_arb/g[0].inst_fft_cntrlr/inst_fft/blk000001b3/
   blk000001b9' of type RAMB16BWER has been changed from 'SPARTAN3ADSP' to
   'SPARTAN6' to correct post-ngdbuild and timing simulation for this primitive.
    In order for functional simulation to be correct, the value of SIM_DEVICE
   should be changed in this same manner in the source netlist or constraint
   file.

  Is this somehow related to other known issues with 9k Block RAMs, and therefore ISE is stirring away from using them?

  - Spartan-6 - 9K Block RAM Initialization Not Supported (List of Affected IP)
  https://www.xilinx.com/support/answers/39999.html
  - Spartan-6 - 9K Block RAM Initialization Not Supported (List of Affected IP)
  https://www.xilinx.com/support/answers/40529.html

3) Does the FFT core somehow not efficiently use the block RAMs? Could one of the "Not Allowed" conditions be met and thus force the use of 18K Block RAMs. In https://www.xilinx.com/support/documentation/user_guides/ug383.pdf, 9Kb Block RAMs seem to not support all configurations (simple vs true)

Thanks,

Adam

SET busformat = BusFormatAngleBracketNotRipped
SET createndf = false
SET designentry = VHDL
SET device = xc6slx25
SET devicefamily = spartan6
SET flowvendor = Other
SET formalverification = false
SET foundationsym = false
SET implementationfiletype = Ngc
SET package = fgg484
SET removerpms = false
SET simulationfiles = Behavioral
SET speedgrade = -2
SET verilogsim = false
SET vhdlsim = true
# END Project Options
# BEGIN Select
SELECT Fast_Fourier_Transform xilinx.com:ip:xfft:7.1
# END Select
# BEGIN Parameters
CSET butterfly_type=use_luts
CSET ce=true
CSET channels=1
CSET complex_mult_type=use_mults_resources
CSET component_name=xfft_v7_1_rdx2_lite_64to32k
CSET cyclic_prefix_insertion=false
CSET data_format=fixed_point
CSET implementation_options=radix_2_lite_burst_io
CSET input_data_offset=no_offset
CSET input_width=16
CSET memory_options_data=block_ram
CSET memory_options_hybrid=false
CSET memory_options_phase_factors=block_ram
CSET memory_options_reorder=block_ram
CSET number_of_stages_using_block_ram_for_data_and_phase_factors=0
CSET output_ordering=natural_order
CSET ovflo=true
CSET phase_factor_width=16
CSET rounding_modes=truncation
CSET run_time_configurable_transform_length=true
CSET scaling_options=scaled
CSET sclr=true
CSET target_clock_frequency=64
CSET target_data_throughput=50
CSET transform_length=32768
# END Parameters
# BEGIN Extra information
MISC pkg_timestamp=2012-08-28T14:48:07Z
# END Extra information
GENERATE
# CRC: 199332a2

https://www.xilinx.com/support/documentation/user_guides/ug383.pdf

0 Kudos
2 Replies
126 Views
Registered: ‎06-21-2017

Re: Map fails for FFT v7.1, yet the Coregen reported "Resource Estimates" are well below what is actually available on the Spartan 6 LX25

What else in your design is using BRAM, any FIFOs, FIR filters, PCIe, DDS?

0 Kudos
Visitor aponchak
Visitor
121 Views
Registered: ‎04-07-2010

Re: Map fails for FFT v7.1, yet the Coregen reported "Resource Estimates" are well below what is actually available on the Spartan 6 LX25

Bruce,

There are only two other FIFOs that use 2 of the 52 RAMB16BWERs of the LX25.

To get it to fit, (I reduced the # of FFTs that I was instancing, from 2 to 1, oops!) and redesigned the FFT core for data width 11 bit and phase width 8 (XCO pasted below). Coregen reported the 'Resource Estimate' to be 52 9k Block RAMS (the exact # available in LX250, which I thought would translate to RAMB8BWERs, but the translate report says otherswise as shown below:

NgdBuild - The value of SIM_DEVICE on instance 'inst_controller_main/inst_fft_arb/inst_fft_cntrlr/gen_radix_2_lite_11b.inst_fft/blk0000014b/blk00000156' of type RAMB16BWER has been changed from 'SPARTAN3ADSP' to 'SPARTAN6' to correct post-ngdbuild and timing simulation for this primitive.  In order for functional simulation to be correct, the value of SIM_DEVICE should be changed in this same manner in the source netlist or constraint file.

So while I have a work around and the design fitting successfully, my question still remains: why are 9k Block RAMS being translated to RAMB16BWERs? Is this related to the documented issues with using RAMB8BWERs in Spartan 6 device? Or is my understanding just wrong?

Thanks

# BEGIN Project Options
SET addpads = false
SET asysymbol = true
SET busformat = BusFormatAngleBracketNotRipped
SET createndf = false
SET designentry = Verilog
SET device = xc6slx25
SET devicefamily = spartan6
SET flowvendor = Other
SET formalverification = false
SET foundationsym = false
SET implementationfiletype = Ngc
SET package = fgg484
SET removerpms = false
SET simulationfiles = Behavioral
SET speedgrade = -3
SET verilogsim = true
SET vhdlsim = false
# END Project Options
# BEGIN Select
SELECT Fast_Fourier_Transform xilinx.com:ip:xfft:7.1
# END Select
# BEGIN Parameters
CSET butterfly_type=use_luts
CSET ce=true
CSET channels=1
CSET complex_mult_type=use_mults_resources
CSET component_name=xfft_v7_1_rdx2_lite_64to32k_11b
CSET cyclic_prefix_insertion=false
CSET data_format=fixed_point
CSET implementation_options=radix_2_lite_burst_io
CSET input_data_offset=no_offset
CSET input_width=11
CSET memory_options_data=block_ram
CSET memory_options_hybrid=false
CSET memory_options_phase_factors=block_ram
CSET memory_options_reorder=block_ram
CSET number_of_stages_using_block_ram_for_data_and_phase_factors=0
CSET output_ordering=natural_order
CSET ovflo=true
CSET phase_factor_width=8
CSET rounding_modes=truncation
CSET run_time_configurable_transform_length=true
CSET scaling_options=scaled
CSET sclr=true
CSET target_clock_frequency=64
CSET target_data_throughput=50
CSET transform_length=32768
# END Parameters
# BEGIN Extra information
MISC pkg_timestamp=2012-08-28T14:48:07Z
# END Extra information
GENERATE
# CRC:  3930f00

0 Kudos