Can't pack into OLOGIC

Nov 10, 2005 10 Replies

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?


IOB : YES

represents the FF: attribute IOB of iob_t : label is "TRUE";

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!

__ / /\/\ Aurelian Lazarut \ \ / System Verification Engineer / / \ Xilinx Ireland \_\/\/ phone: 353 01 4032639 fax: 353 01 4640324

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.

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...

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

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)

John,

tristate_enable_reg(i) thanks for help.

sorry I mistyped!

obviously it is: tristate_enable_reg(i)

also registered there,

OLOGIC (Virtex 4).

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:

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

-- -- 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";

-- -- 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 'Z' );

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

if rising_edge(clk) then

-- -- IOB registers -- ram_dat_reg

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.

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.

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 to avoid any unused inputs:

-- seg_dp

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required