regarding usage of IOBs and Warning XST 2036

V

Vivek Menon

Guest
I am implementing a design using Virtex-6 Device:XC6VLX550T Package:FF1759 and Speed:-2.

My top module instantiates 16 units, where each unit instantiates 18x8 multiplier 49 times. This means that my design is using 784 multipliers. The number of DSP48 modules available on the Virtex-6 device is 864 which means that less than 100% of resources are used.

However, when I synthesize my design, I see this information:
Primitive and Black Box Usage:
------------------------------
# IO Buffers : 26946
# IBUF : 6562
# OBUF : 20384
# Others : 784
# xcorr_mult_18x8 : 784

Device utilization summary:
---------------------------

Selected Device : 6vlx550tff1759-2


Slice Logic Utilization:

Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 0
Number with an unused Flip Flop: 0 out of 0
Number with an unused LUT: 0 out of 0
Number of fully used LUT-FF pairs: 0 out of 0
Number of unique control sets: 0

IO Utilization:
Number of IOs: 26946
Number of bonded IOBs: 26946 out of 840 3207% (*)


The Mapping report shows:
Interim Summary
---------------
Slice Logic Utilization:
Number of Slice Registers: 0 out of 687,360 0%
Number of Slice LUTs: 0 out of 343,680 0%

Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 0

IO Utilization:
Number of bonded IOBs: 26,946 out of 840 3207% (OVERMAPPED)

Specific Feature Utilization:
Number of RAMB36E1/FIFO36E1s: 0 out of 632 0%
Number of RAMB18E1/FIFO18E1s: 0 out of 1,264 0%
Number of BUFG/BUFGCTRLs: 0 out of 32 0%
Number of ILOGICE1/ISERDESE1s: 0 out of 1,440 0%
Number of OLOGICE1/OSERDESE1s: 0 out of 1,440 0%
Number of BSCANs: 0 out of 4 0%
Number of BUFHCEs: 0 out of 216 0%
Number of BUFOs: 0 out of 72 0%
Number of BUFIODQSs: 0 out of 144 0%
Number of BUFRs: 0 out of 72 0%
Number of CAPTUREs: 0 out of 1 0%
Number of DSP48E1s: 784 out of 864 90%
Number of EFUSE_USRs: 0 out of 1 0%
Number of FRAME_ECCs: 0 out of 1 0%
Number of GTXE1s: 0 out of 36 0%
Number of IBUFDS_GTXE1s: 0 out of 18 0%
Number of ICAPs: 0 out of 2 0%
Number of IDELAYCTRLs: 0 out of 36 0%
Number of IODELAYE1s: 0 out of 1,440 0%
Number of MMCM_ADVs: 0 out of 18 0%
Number of PCIE_2_0s: 0 out of 2 0%
Number of STARTUPs: 1 out of 1 100%
Number of SYSMONs: 0 out of 1 0%
Number of TEMAC_SINGLEs: 0 out of 4 0%


Mapping completed.
See MAP report file "xcorr_pixel_channel_map.mrp" for details.
Problem encountered during the packing phase.

Design Summary
--------------
Number of errors : 2
Number of warnings : 0

Section 1 - Errors
------------------
ERROR:pack:2309 - Too many bonded comps of type "IOB" found to fit this device.
ERROR:Map:237 - The design is too large to fit the device. Please check the Design Summary section to see which resource requirement for your design exceeds the resources available in the device. Note that the number of slices reported may not be reflected accurately as their packing might not have been completed.

NOTE: An NCD file will still be generated to allow you to examine the mapped design. This file is intended for evaluation use only, and will not process successfully through PAR.
=====================
How can I reduce the number of Bonded IOBs?

Note: I have not specified an User Constraint File (.ucf) yet, as I am determining whether the design will fit or not on the selected FPGA.

Thanks in advance.
 
In article <c7672a44-b425-4842-81cb-808300f85b7b@glegroupsg2000goo.googlegroups.com>,
Vivek Menon <comp.arch.fpga@googlegroups.com> wrote:
I am implementing a design using Virtex-6 Device:XC6VLX550T Package:FF1759 =
and Speed:-2.

My top module instantiates 16 units, where each unit instantiates 18x8 mult=
iplier 49 times. This means that my design is using 784 multipliers. The nu=
mber of DSP48 modules available on the Virtex-6 device is 864 which means t=
hat less than 100% of resources are used.=20
I suspect you're instantiating a unit whose multipliers have the
output and one input marked as connected to the outside world; you
seem to have about eight inputs and 18+8 outputs per multiplier.

Obviously the FPGA doesn't have the thirty thousand pins that would imply!

Tom
 
On 02/28/2011 01:55 PM, Thomas Womack wrote:
In article<240bfd78-c71f-497b-a093-ba23f37c8e40@glegroupsg2000goo.googlegroups.com>,
Vivek Menon<comp.arch.fpga@googlegroups.com> wrote:
My port definition is as follows:
--Inputs
clk : in std_logic;
ce : in std_logic;
pixel_in : in std_logic_vector(17 downto 0);
refim_in : in std_logic_vector(391 downto 0); -- 49 inputs of 8 bits each

-- Outputs
xcorr_prod_out : out std_logic_vector(1273 downto 0); --49 outputs of 26 bits each

Yes, so if you're instantiating those without connecting them
together, all those ins and outs are mapped to pins, and
unsurprisingly you're using thirty times as many pins as the chip has.

Add another component which has a single input and feeds that into a
shift register which drives the pixel_in and refim_in of all the
machines, takes out the xcorr_prod_out of all the machines and (eg)
xors its bits together. Connect the out of that to some LED-driving
pin, and you have a large and complicated device which has only two
pins. Then you can discover whether the routing fits on the FPGA.

Tom
I was going to suggest that you connect them all to a device that
ignores them -- but then they'll get optimized out of existence,
wouldn't they?

Wouldn't XOR-ing all the outputs together use up tons-o-real estate? It
seems like it'd take less real estate to load up shift registers with
those outputs, and shift the result out a single pin.

Either way, I suppose you'll be able to see in the device map output how
much of the chip is going away to your "glue".

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
 
My port definition is as follows:
--Inputs
clk : in std_logic;
ce : in std_logic;
pixel_in : in std_logic_vector(17 downto 0);
refim_in : in std_logic_vector(391 downto 0); -- 49 inputs of 8 bits each

-- Outputs
xcorr_prod_out : out std_logic_vector(1273 downto 0); --49 outputs of 26 bits each

component mult_18x8
port (
clk : in std_logic;
a : in std_logic_vector(17 downto 0);
b : in std_logic_vector(7 downto 0);
ce : in std_logic;
p : out std_logic_vector(25 downto 0));
end component;

---------------------------------

I thought it would be easier for naming and connection by building a single signal of 1274 bits rather than having 49 signals of 26 bits.
 
In article <240bfd78-c71f-497b-a093-ba23f37c8e40@glegroupsg2000goo.googlegroups.com>,
Vivek Menon <comp.arch.fpga@googlegroups.com> wrote:
My port definition is as follows:
--Inputs
clk : in std_logic;
ce : in std_logic;
pixel_in : in std_logic_vector(17 downto 0);
refim_in : in std_logic_vector(391 downto 0); -- 49 inputs of 8 bits each

-- Outputs
xcorr_prod_out : out std_logic_vector(1273 downto 0); --49 outputs of 26 bits each
Yes, so if you're instantiating those without connecting them
together, all those ins and outs are mapped to pins, and
unsurprisingly you're using thirty times as many pins as the chip has.

Add another component which has a single input and feeds that into a
shift register which drives the pixel_in and refim_in of all the
machines, takes out the xcorr_prod_out of all the machines and (eg)
xors its bits together. Connect the out of that to some LED-driving
pin, and you have a large and complicated device which has only two
pins. Then you can discover whether the routing fits on the FPGA.

Tom
 
THanks for the tip.

I am currently only setting the LSB as the output pin. Started the Synthesis procedure and waiting to see the Synthesis report if the 26946 IOB utilization disappears. I am using a transceiver to receive the input data, so that has minimum pin usage.
 

Welcome to EDABoard.com

Sponsor

Back
Top