Can't pack into OLOGIC

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?

Reply to
john
Loading thread data ...

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
Reply to
Aurelian Lazarut

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.

Reply to
fastgreen2000

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

Reply to
fastgreen2000

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

Reply to
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)

Reply to
john

John,

tristate_enable_reg(i) thanks for help.

Reply to
Symon

sorry I mistyped!

obviously it is: tristate_enable_reg(i)

Reply to
john

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

Reply to
Brian Davis

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.

Reply to
john

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

Reply to
Brian Davis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.