Can't pack into OLOGIC

[john]

Hi,

It's a few days since I can't put a FF into IOB register:

XST (7.1.4) option: -equivalent register removal: NO -pack IO registers into IOB : YES

MAP (7.1.4) option: -pack IO registers into IOB : For inputs and outputs

moreover I applied the attribute on the name of the clocked process that represents the FF: attribute IOB of iob_t : label is "TRUE";

It is for a bidirectionnal signal: input is registered into IOB, output is also registered there, but the duplicated tristate_enable registers don't want to go inside the OLOGIC (Virtex 4). Each of them is not that far, but not into the IOB!

Any suggestion?

[Aurelian Lazarut]

John,
can you please post the MAP error message?
Thanks,
Aurash

john wrote:

--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/

phone: 353 01 4032639
fax: 353 01 4640324

[fastgr...@yahoo.com]

john wrote:

> It is for a bidirectionnal signal: input is registered into IOB, output is also registered there, but the duplicated tristate_enable registers don't want to go inside the OLOGIC (Virtex 4). Each of them is not that far, but not into the IOB!
>

- Make sure the tristate 'registers' are duplicated, not the output of
the tristate register.
- Make sure the duplicated registers have proper attribute so the
synthesis tool doesn't optimize them into a single register.

[fastgr...@yahoo.com]

You may have already done what I mentioned. One more
- make sure the tristate registers feed nothing else outside of the
IOB.

You might want to post your code if it still doesn't do it...

[john]

the

[john]

I don't have any error: I just checked with fpga_editor that I am not using both FF inside the OLOGIC.

This results in a poor timing because the routing adds to the iobuf timing

[john]

thanks for help.

I respect these three conditions. (I checked with fpgaeditor)

code is (removed reset as in teXclusive on xilinx website):

iob_t:process(CLK) begin if rising_edge(CLK) then DATA_REG(i) <= DATA(i); tristate_enable_reg(i) <= tristate_enable_reg(i); end if; end process;

well maybe I'll consider opening a webcase!

[Symon]

John,

tristate_enable_reg(i) <= tristate_enable_reg(i); ??

Is that what you wanted?

Syms

"john" <john....@gmail.com> wrote in message
news:ee91...@webx.sUN8CHnE...

[john]

sorry I mistyped!

obviously it is: tristate_enable_reg(i) <= tristate_enable(i);

[Joseph Samson]

john wrote:
> the

You might want to try:

attribute equivalent_register_removal of tristate_enable_reg: signal is
"no";

---
Joe

[Brian Davis]

john wrote:
>
> It is for a bidirectionnal signal: input is registered into IOB, output is also registered there,
> but the duplicated tristate_enable registers don't want to go inside the OLOGIC (Virtex 4).
> Each of them is not that far, but not into the IOB!
>

Last time I tried this with XST 6.3 / Spartan-3, I had to try a few
coding variants before all the data registers and tristate controls
were properly stuffed into the IOBs from non-structural HDL code.

Below are some simplified (hand edited,uncompiled!!) code snippets
from a S3 eval kit RAM test that I posted last fall, for the whole
thing see :
ftp://members.aol.com/fpgastuff/ram_test.zip

Code Snippets:

<ports>

ram_addr : out std_logic_vector(17 downto 0);
ram_dat : inout std_logic_vector(15 downto 0);

<signals>

--
-- internal ram signals
--
signal addr : std_logic_vector(17 downto 0);
signal din : std_logic_vector(15 downto 0);
signal ram_dat_reg : std_logic_vector(15 downto 0);

signal wdat_oe_l : std_logic;

--
-- IOB attribute needed to replicate tristate enable FFs in each IOB
--
attribute iob of wdat_oe_l : signal is "true";

<code>

--
-- output data bus tristate
--
-- XST seems to want tristates coded like this to push both
-- the tristate control register and the data register into IOB
-- ( had previously been coded as clocked tristate assignment )
--
ram_dat <= ram_dat_reg when wdat_oe_l = '0' else ( others => 'Z'
);

--
-- registered RAM I/O
--
process(clk)
begin

if rising_edge(clk) then

--
-- IOB registers
--
ram_dat_reg <= tdat(15 downto 0);
ram_addr <= taddr;

--
-- registered tristate control signal
-- coded this way, with IOB attribute on wdat_oe_l, so
-- XST will replicate tristate control and push into IOBs
--
if (done_p1 = '0') and ( read_write_p1 = '0') then
wdat_oe_l <= '0';
else
wdat_oe_l <= '1';
end if;

--
-- register input data
--
din <= ram_dat;

end if;

end process;

[john]

Thanks all for suggestions.

with my version of ISE, I can not put the IOB attribute on a signal: I get the error

ERROR:HDLParsers:1202 - "/home/XXX/XXX/XXX.vhd" Line 210. Redeclaration of symbol tristate_enable_reg. -->

(the same attribute on the process generates no error but no IOB register.)

My workaround is to put the clocked process into a file: register.vhd

then I put the attribute on the instantiation of the component.

[Brian Davis]

john wrote:
>
> with my version of ISE, I can not put the IOB attribute on a signal
>

I rebuilt that example 6.3 project I'd posted a link to, using 7.1SP4
The IOB attribute worked just fine (note 1); the tristate controls are
properly replicated and all registers show up in the IOBs.

>
> I get the error
> ERROR:HDLParsers:1202 - "/home/XXX/XXX/XXX.vhd" Line 210. Redeclaration of symbol tristate_enable_reg. -->
>

That message sounds like the synthesizer is choking on a coding
problem. Do you have duplicate (identical) names for both a process
and a signal, or something similar ?

Brian

Note 1:
There is a 7.1iSP4 bug with assigning IOSTANDARDs and LOCS
using HDL attributes. Unused LOC'd inputs drop their IOSTANDARD
definitions and default back to LVCMOS25, causing banking errors.
To make that example project compile, make the following change to
<ram_test.vhd> to avoid any unused inputs:

-- seg_dp <= '1';
seg_dp <= sw(5) OR sw(4) OR sw(3) OR sw(2) OR sw(1) OR sw(0)
OR pb(1) OR pb(0);