cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
bwk
Observer
Observer
6,909 Views
Registered: ‎09-30-2010

Stop XST optimization for "useless" module

Hi,

 

we are working on our own bus. Now we want to know how much slices the bus logic will take and how the slice count changes when the generics change. For this I created an ISE Project with all the source files. The entity of the toplevel looks like this:

 

entity rcb is
generic
(
	DATA_WIDTH	: INTEGER :=  32;
	PORT_COUNT	: INTEGER :=   8;
	LANE_COUNT	: INTEGER :=   3;
	MAX_WAIT	: INTEGER :=   9;
	RESET_COUNT	: INTEGER :=   5
);
port
(
	RCB_CLK		: in	std_logic;
	RCB_RST_N	: in	std_logic;
	
	-- PLB 2 RCB Bridge Interface
	PLB_2_RCB_DATA	: in	std_logic_vector(31 downto 0);
	RCB_2_PLB_DATA	: out	std_logic_vector(31 downto 0);
	
	PLB_2_RCB_RE	: in	std_logic_vector(1 downto 0);
	PLB_2_RCB_WE	: in	std_logic_vector(1 downto 0);
	
	-- Interface for module connection
	RCB_2_Module_RST: out
		std_logic_vector(PORT_COUNT-1 downto 0);
	
	RCB_2_Module_DATA : out
		std_logic_vector(PORT_COUNT*DATA_WIDTH-1 downto 0)
	Module_2_RCB_DATA : in
		std_logic_vector(PORT_COUNT*DATA_WIDTH-1 downto 0)
);
end entity rcb;

 

Now the problem is, that big values for PORT_COUNT and DATA_WIDTH will result in an overmapping of IOBs and MAP gives an error. To solve this I wanted to create an "useless" module that I can connect to the RCB_2_Module_DATA and Module_2_RCB_DATA ports of the bus. I thought that this module could look like this:

 

entity useless is
generic
(
	DATA_WIDTH : integer := 32;
	PORT_COUNT : integer :=  4		
);
port
(
	RCB_2_Module_DATA :
		in  STD_LOGIC_VECTOR (PORT_COUNT*DATA_WIDTH-1 downto 0);
	Module_2_RCB_DATA :
		out  STD_LOGIC_VECTOR (PORT_COUNT*DATA_WIDTH-1 downto 0)	
);
end useless;

architecture IMP of useless is

	attribute KEEP : string;
	attribute KEEP of RCB_2_Module_DATA : signal is "true";
	attribute KEEP of Module_2_RCB_DATA : signal is "true";

begin

	Module_2_RCB_DATA <= (others => '0');

end IMP;

Is there a way to tell XST not to optimize the module away? I already tried the KEEP and the S attribute, but had no success. Or are there any other ideas to solve this problem?

 

Thanks for help,

bwk

0 Kudos
6 Replies
eilert
Teacher
Teacher
6,900 Views
Registered: ‎08-14-2007

Hi.

When XST is clever enough to eliminate useless stuff, why not outwit XST and implement something usefull instead?

 

How about a wide MUX/DEMUX which can be configured with generics too.

This way you keep the I/O count low. However the LUT count will increase, but there's far more LUTs than IOBs.

-edit begin-

  Or even simpler: A large shift register. Less code, uses only FFs and no LUTs, needs just one IOB.

-edit end-

 

Besides, if you just want to check the ressource usage for testing purposes why do you map the design?

The synthesis report should be sufficient for your goal.

 

Have a nice synthesis

  Eilert

0 Kudos
bwk
Observer
Observer
6,893 Views
Registered: ‎09-30-2010

Hi,

 

I didn't want to implement something usefull, because this would take more resources. I thought there would be an attribute or something else to do the trick.

 

Now I use a shift register for the input port and a multiplexer for the output port. This seems to work and the slice count is quiet easy to estimate.

 

I mapped the design to get the slice count so I can say that this bus uses for example ~400 slices on a Virtex 5 fpga. Is there another way to get the slice count?

 

Thanks for your help,

bwk

0 Kudos
rcingham
Teacher
Teacher
6,887 Views
Registered: ‎09-09-2010

The 'slice count' is not a very useful measure for a part design, as the Mapper starts amalgamating logic from different modules into slices when the utilisation reaches (some value based on a complicated measure of the design).

As Eilert wrote, the 'Device utilization summary' from the SYR should have enough to be going on with, particularly:
'Number of Slice Flip Flops'
'Number of 4 input LUTs' and its sub categories.

DO NOT pay much attention to the Timing Report in the SYR!


------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
gszakacs
Professor
Professor
6,875 Views
Registered: ‎08-14-2007

One down side to the synthesis report is that it may count resources which are subsequently

trimmed during mapping.  It's possible that in addition to the trimming that occurs because

your design did not have the I/O connected, that there is some underlying trimming of unused

resources.  This is frequently the case when you use CoreGen IP.  Often the cores have extra

logic that is always synthesized but intended to be ripped out when not used at the wrapper

level.  On the other hand if you don't see a difference in the LUT and flip-flop count between

synthesis and map reports, then you're home free.

 

-- Gabor

-- Gabor
0 Kudos
eilert
Teacher
Teacher
6,868 Views
Registered: ‎08-14-2007

Hi,

just to add a comment to the things said by rcingham and Gabor:

 

You can go the way to implement some ip-core.

Not all the way of course, just to the mapping.

 

For that you need to turn off the insertion of IO-Buffers in teh synthesis.

Same goes for Translate and maybe Map. (Whereever this option appears)

Then you have to disable the trimming of unused logic.

Maybe some other options have to be set that I'm not aware of yet, but basically thats the way.

You should end up with a synthesized and mapped core in NCD Netlist format.

Since it isn't bound to IOBs you overcome the IOB limit this way.

 

Have a nice synthesis

  Eilert

 

 

0 Kudos
bassman59
Historian
Historian
6,866 Views
Registered: ‎02-25-2008

What I do when I want to ensure that some signals (or entities) are not optimized away is to create an output port called keeper, and simply and all of the relevant signals together to drive that port. For example,

 

keeper <= foo and bar and bletch and rocky and bullwinkle;

 

I haven't tried to keep an entity from being optimized away, but the above trick is handy to ensure that FPGA input pins that end up not being used in the design are not thrown away. I generally need to do this because those signals are in the .UCF with a pin location constraint, and the tools complain if a pin or net in the UCF doesn't actually exist in the design (because it was optimized away or whatever).

----------------------------Yes, I do this for a living.
0 Kudos