IOBs in Spartan 2 exceeded

[Nikolai]

how to assign pin for pq208 spartan 2

I have a problem here. My design is of a 2-D DCT processor.
In that im using two 1-D DCT processors and a transpose memory.

Now i have finished my design for a 1-D DCT processor and i wish to test it (timing,PAR,etc).

Now the problem is that i have a spartan2 PQ-208 FPGA with 140 IOs and my utilisation is 145 IOs.

Ofcourse i dont intend to assign pins to all 145 IOs but i simply want to run a full test on the design.

During the Map process i get this error that i have exceeded the IOs.

So is there any way to get around it ??

 

[echo47]

When synthesizing FPGA logic, an I/O is a physical pin connection. An I/O that's not connected to a pin seems like a contradiction. Or are you hoping to use the unbonded IOBs in the FPGA?

Is your "full test" a hardware test or just simulation? Behavioral simulation doesn't care about having too many I/Os.

I don't think there's any way to tell the ISE mapper to ignore the error and continue. It has encountered an impossible situation, so it aborts.

 

[shawndaking]

what are you expecting to get ?

 

[Nikolai]

I wish to conduct a Post PAR simulation on my design.

heres the VHDL code for the 1-D DCT

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_SIGNED.ALL;
use work.Components.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity DCT1 is
Port ( I0 : in STD_LOGIC_VECTOR (7 downto 0);
I1 : in STD_LOGIC_VECTOR (7 downto 0);
I2 : in STD_LOGIC_VECTOR (7 downto 0);
I3 : in STD_LOGIC_VECTOR (7 downto 0);
I4 : in STD_LOGIC_VECTOR (7 downto 0);
I5 : in STD_LOGIC_VECTOR (7 downto 0);
I6 : in STD_LOGIC_VECTOR (7 downto 0);
I7 : in STD_LOGIC_VECTOR (7 downto 0);
O0 : out STD_LOGIC_VECTOR (7 downto 0);
O1 : out STD_LOGIC_VECTOR (7 downto 0);
O2 : out STD_LOGIC_VECTOR (7 downto 0);
O3 : out STD_LOGIC_VECTOR (7 downto 0);
O4 : out STD_LOGIC_VECTOR (7 downto 0);
O5 : out STD_LOGIC_VECTOR (7 downto 0);
O6 : out STD_LOGIC_VECTOR (7 downto 0);
O7 : out STD_LOGIC_VECTOR (7 downto 0);
OE1 : in STD_LOGIC;
OE2 : in STD_LOGIC_VECTOR (1 downto 0);
OE3 : in STD_LOGIC_VECTOR (1 downto 0);
OE4 : in STD_LOGIC_VECTOR (1 downto 0));
end DCT1;

architecture Behavioral of DCT1 is

begin

-- First Stage

BU1 : Butterfly
port map(I0,I7,BU1O0,BU1O1,OE1);

BU2 : Butterfly
port map(I1,I6,BU2O0,BU2O1,OE1);

BU3 : Butterfly
port map(I2,I5,BU3O0,BU3O1,OE1);

BU4 : Butterfly
port map(I3,I4,BU4O0,BU4O1,OE1);

-- Second Stage

BU5 : Butterfly
port map(BU1O0,BU4O0,BU5O0,BU5O1,OE2(0));

BU6 : Butterfly
port map(BU2O0,BU3O0,BU6O0,BU6O1,OE2(0));

A1 : Quad_multiplier_A1
port map(BU3O1,BU2O1,A1O0,A1O1,OE2(1));

A2 : Quad_multiplier_A2
port map(BU4O1,BU1O1,A2O0,A2O1,OE2(1));

-- Third Stage

BU7 : Butterfly
port map(BU5O0,BU6O0,O0,O4,OE3(0));

A3 : Quad_multiplier_A3
port map(BU6O1,BU5O1,A3O0,A3O1,OE3(1));

BU8 : Butterfly
port map(A2O0,A1O1,BU8O0,BU8O1,OE3(0));

BU9 : Butterfly
port map(A2O1,A1O0,BU9O0,BU9O1,OE3(0));

-- Fourth Stage

CM1 : Constant_multiplier
port map(A3O0,O2,OE4(0));

CM2 : Constant_multiplier
port map(A3O1,O6,OE4(0));

BU10 : Butterfly
port map(BU9O0,BU8O0,O1,O7,OE4(1));

CM3 : Constant_multiplier
port map(BU8O1,O5,OE4(0));

CM4 : Constant_multiplier
port map(BU9O1,O3,OE4(0));


Now I0 to I7 are seperate 8 bit inputs but in the top Level entity, i plan use a demux to distribute an 8 bit input to these seperate (I0 to I7) inputs one after the other. But i need to perform a Post PAR simulation on this unit.

 

[echo47]

I'm not sure why you want to connect so many signals to I/O pads if you don't intend to do that in the final hardware. Maybe you believe that I/O signals are the only signals visible in the simulator? The simulator can display signals located anywhere in your design hierarchy.

If you really need all those I/O pads for some reason, and since it's just simulation, how about temporarily selecting a different FPGA package, such as FG256 instead of PQ208? That will give you 176 I/Os instead of 140.

 

[Nikolai]

The attached image might clarify my intentions..

So as u can see in the top level design only 8 bit input and 8 bit output will be connected to the pins.

One option could be to use "buffer" type for the ports of DCT1 instead of "in" or "out"..
But i heard thats bad practice and can cause some synthesis errors.

Yes, the option of changing the package worked. Was wondering if the same problem occurs in more complex designs requiring many input and output ports..

 

[echo47]

Ok good. I see the 16 signals that need to connect to I/O pins.

I'm still fuzzy about the other 129 signals . . .
1. Are you deliberately connecting them to I/O pins? If yes, then why?
2. Are they mysteriously connecting themselves to I/O pins against you wishes, and you are trying to stop that from happening?

I'm a Verilog guy, and don't know VHDL well enough to understand "buffer" "in" "out". Maybe someone else can answer that question.

Normally, the number of I/O pins is very straightforward. If I need 16 I/O signals between the FPGA and other electronics on the PC board, then I declare those 16 signals as inputs or outputs at my top level HDL module. The FPGA mapper/router connects those 16 I/O pins, and sets all the other I/O pins to "unused".

 

[Nikolai]

The remaining 129 are ofcourse internal signals in the top level design.

But when im doing the PAR on just the DCT1 module, those are considered as signals to be connected to pins.. (ofcourse i do not intend that)

My top level design will have only 16 signals connected to pins.
But i wish to test the internal modules individually, which unfortunately have many inputs and outputs.

 

[echo47]

Now I understand! You want to do post-route simulation of individual modules.

I rarely do that in my projects because it requires significant extra work, but if I really need to do it, I will design special data-generating and data-checking modules that connect to the inputs and outputs of the module being tested. That becomes a self-contained design that requires only a clock input and a pass/fail outputs. It's easy to synthesize and download into a real FPGA, or easy to run a post-route simulation.

By using that arrangement, the module under test iconnects to other nearby modules, just like it in the final full project. From a timing and mapping point of view, that's a more realistic scenario than connecting the module to I/O pins which have different routing and timing properties.

 

[Nikolai]

OK, so you're saying that it is better to first get all the modules together and do the PAR,timing analysis on the top level rather than on individual modules..

I have somehow managed to bring down the pin count, so it is working fine now.

Im not quite aware of the programming & testing paradigms in FPGA, this being my first FPGA based project.

Is there thr any book on the "know-how" of Xilinx FPGAs or is just sheer experience..

All thanx, nevertheless.

 

[echo47]

In most projects, there are many satisfactory ways to test an individual module. As the project progresses, you can decide how thorough each individual test need to be, and how much time you can afford to spend designing test fixtures, unless those choices are dictated by project management requirements.

Sometimes I spend very little time testing a module because I know I can easily test it later when it's connected to the entire system. Other times, I know that a module will be difficult to test while buried inside the system, so I'll build a special test fixture for it, either inside or outside the FPGA. Occasionally I spend extra time building an elaborate test fixture simply because the module is interesting or fun, or because I wish to demonstrate it to someone else.

I suppose there are as many ways to test a module as there are ways to design the module. Sometimes behavioral simulation is sufficient to test a module. Sometimes I'll connect all the module's I/Os to FPGA pins, but if that is likely to mess up timing too much, or if I don't have a convenient way to drive/monitor all those pins, then I'll build test fixtures inside the FPGA. Every designer has his/her own favorite way of doing things!