Problem with TBUF-Placing

T

Thomas Bartzick

Guest
Hello everybody!

I have a problem with placing my tbuf-elements.
Modules using bus operations are coupled to top-level switching them
to a bidirectional bus. See, like this:

---<snip!>

entity my_struct is port (
...
BD : inout std_logic_vector(15 downto 0);
...);
end my_struct;

architecture Behavioral of my_struct is
....
signal de, di : std_logic_vector(15 downto 0);
....
begin
....
my_external_connector : process (de, BD, ext_read)
begin
if (ext_read = '1') then
BD <= de;
de <= "ZZZ...Z";
else
BD <= "ZZZ...Z";
de <= BD;
end if;
end process;
....
mod_databus_write_sync : SYNC_2xFF port map (
I => de,
O => di);
....
my_module : SOME_MODULE port map (
DIN => di,
DOUT => internal_output,
CS => ...,
...);

my_toplevel_bus_read_process: process (internal_output,
read_condition)
begin
if (read_condition = '1') then
de <= internal_output;
else
de <= "ZZZ...Z";
end if;
end process;

end Behavioral;

---<snap!>
Additional Note:
****************
There are about 3 upto 5 internal modules which make use of this
structure.
So we get a maximum of 5x16 = 80 tristate buffer lines, probably some
more.
****************

Synthezising, Translation and Mapping is always fine, but since the
implementation process comes to PAR, the placer stops after a couple
of warnings and at least one error like this:

---<snip!>

.... WARNING! Unable to place TBUF of module <#1>!
....
.... WARNING! Unable to place TBUF of module <#n>!
....
.... ERROR! Placing was not complete!
....

---<snap!>

I have read on XILINX support pages, that this problem can be worked
around by using AREA_GROUP constraints. If I have understood this in
the right way, the constraints will show the placer how I would like
to layout the tristate buffers. But all I can choose in ISE for
SPARTANII are Row and Column-statements, for which I have no idea how
to use them in a proper way.

I am using XILINX Webpack ISE 6.1 with a SPARTANII (-5) architecture.
Help or at least some hints would be very appreciated!

Bye,
Thomas.
 
t.bartzick@gmx.net (Thomas Bartzick) wrote in message news:<cdd36e13.0401251931.2f3cb1c7@posting.google.com>...
Hello everybody!

I have a problem with placing my tbuf-elements.
Modules using bus operations are coupled to top-level switching them
to a bidirectional bus. See, like this:

---<snip!

entity my_struct is port (
...
BD : inout std_logic_vector(15 downto 0);
...);
end my_struct;

architecture Behavioral of my_struct is
...
signal de, di : std_logic_vector(15 downto 0);
...
begin
...
my_external_connector : process (de, BD, ext_read)
begin
if (ext_read = '1') then
BD <= de;
de <= "ZZZ...Z";
else
BD <= "ZZZ...Z";
de <= BD;
end if;
end process;
...
mod_databus_write_sync : SYNC_2xFF port map (
I => de,
O => di);
...
my_module : SOME_MODULE port map (
DIN => di,
DOUT => internal_output,
CS => ...,
...);

my_toplevel_bus_read_process: process (internal_output,
read_condition)
begin
if (read_condition = '1') then
de <= internal_output;
else
de <= "ZZZ...Z";
end if;
end process;

end Behavioral;

---<snap!
Additional Note:
****************
There are about 3 upto 5 internal modules which make use of this
structure.
So we get a maximum of 5x16 = 80 tristate buffer lines, probably some
more.
****************

Synthezising, Translation and Mapping is always fine, but since the
implementation process comes to PAR, the placer stops after a couple
of warnings and at least one error like this:

---<snip!

... WARNING! Unable to place TBUF of module <#1>!
...
... WARNING! Unable to place TBUF of module <#n>!
...
... ERROR! Placing was not complete!
...

---<snap!

I have read on XILINX support pages, that this problem can be worked
around by using AREA_GROUP constraints. If I have understood this in
the right way, the constraints will show the placer how I would like
to layout the tristate buffers. But all I can choose in ISE for
SPARTANII are Row and Column-statements, for which I have no idea how
to use them in a proper way.

I am using XILINX Webpack ISE 6.1 with a SPARTANII (-5) architecture.
Help or at least some hints would be very appreciated!

Bye,
Thomas.

Hello Thomas,

When considering TBUF placement issues, it's necessary to understand
the placement limitations of the TBUF sets as a whole. How large a set
can the device handle? How many total sets of a particular size can it
handle? These are limitations that come into play long before the
total number of TBUF sites available becomes a factor.

Spartan-II devices can not handle multi-row TBUF placement within a
set (Virtex-II can) so the largest possible TBUF set is equal to the
number of columns in the device. The TBUF long lines can be segmented
in groups of four TBUFs, so the number of sites consumed by each set
should be rounded up to a factor of four, then the total number of
possible sets calculated. For example, if the set size is greater than
half the number of TBUFs on a long line, then the number of possible
sets is equal to two times the number of rows (two TBUFs per CLB),
even though TBUF site utilization may only be slightly greater than
50%.

If you're unsure of the size of your TBUF sets and the number of sets,
see the following Answer record for a perl script that can be used to
count them:
http://support.xilinx.com/techdocs/2872.htm

Regarding constraining TBUF placement, it's often enough to LOC a
single TBUF from each set to a site on a particular longline. The rest
of the TBUFs in the set are then implicitly LOC'd to the same long
line.

One possibility is to allow Map to transform some of the TBUFs to
slice logic by using the -tx switch.

Regards,
Bret
 
bret.wade@xilinx.com (Bret Wade) wrote in message news:<465bd4b1.0401261115.7381c509@posting.google.com>...
t.bartzick@gmx.net (Thomas Bartzick) wrote in message news:<cdd36e13.0401251931.2f3cb1c7@posting.google.com>...
Hi Bret,

well, thanks for your hints!
I could not test them yet, because I have to deal with other problems
first, but I will try your solution as soon as possible!

Bye,
Thomas.

Hello Thomas,

When considering TBUF placement issues, it's necessary to understand
the placement limitations of the TBUF sets as a whole. How large a set
can the device handle? How many total sets of a particular size can it
handle? These are limitations that come into play long before the
total number of TBUF sites available becomes a factor.

Spartan-II devices can not handle multi-row TBUF placement within a
set (Virtex-II can) so the largest possible TBUF set is equal to the
number of columns in the device. The TBUF long lines can be segmented
in groups of four TBUFs, so the number of sites consumed by each set
should be rounded up to a factor of four, then the total number of
possible sets calculated. For example, if the set size is greater than
half the number of TBUFs on a long line, then the number of possible
sets is equal to two times the number of rows (two TBUFs per CLB),
even though TBUF site utilization may only be slightly greater than
50%.

If you're unsure of the size of your TBUF sets and the number of sets,
see the following Answer record for a perl script that can be used to
count them:
http://support.xilinx.com/techdocs/2872.htm

Regarding constraining TBUF placement, it's often enough to LOC a
single TBUF from each set to a site on a particular longline. The rest
of the TBUFs in the set are then implicitly LOC'd to the same long
line.

One possibility is to allow Map to transform some of the TBUFs to
slice logic by using the -tx switch.

Regards,
Bret
 

Welcome to EDABoard.com

Sponsor

Back
Top