cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
silverpike
Visitor
Visitor
6,022 Views
Registered: ‎07-28-2011

auto-uniquify problems

Hello all,

 

I am using Xilinx ISE 12.4, and I'm having issues with the synthesis step.  I want to preserve my module hierarchy, so I enable the "Keep hierarchy" option to XST.  When I do this, I get output that seems to be auto-uniquified.  For example, if I have a module named "prim_add4" and it's instantiated 10 times in the RTL, I get 10 different definitions of "prim_add4" in the simulation model (Verilog) output after synthesis, all of the variety "prim_add4_INSTn".  This is not what I want!  I want a single module definition of "prim_add4" and 10 instantiations, like the RTL has.

 

I have 2 questions:

1. Why is XST auto-uniquifying things?

2. Is there any setting for XST which can prevent this behavior?

 

Help!

 

0 Kudos
5 Replies
austin
Scholar
Scholar
6,020 Views
Registered: ‎02-27-2008

s,

What is it you want to do?

What you think "should" happen doesn't fit reality, so I would suggest you read what the options actually do in the synthesis guide. Then, perhaps, there are options that could be used to do what you want.

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
silverpike
Visitor
Visitor
6,008 Views
Registered: ‎07-28-2011

Holy cow, what an incredibly rude response.  Given that I have no other options, I'm going to continue asking here.

 

Austin, your claim of "doesn't fit reality" is outlandish.  Have you ever used an ASIC synthesis tool like DC or RC? I assure you companies tape out across the world daily without the need to auto-uniquify modules.  Indeed, this is the default, and you only get module copies by manually specifying the uniquify synthesis attribute.

 

I have scoured the XST manual from top to bottom, and the only synthesis setting I can see affecting hierarchy is the "keep hierarchy" attribute.  What I still don't understand is why, if the hierarchy is kept, everything is uniquified.  I suspect from reading the docs, since no mention is made of this anywhere, that this output is the only output generated by XST and getting resolution here will be futile.

 

Probability notwithstanding, I have generated an example to show my problem.

 

Input code:

module test_top(i_a, i_b, o_z);

	input [31:0]	i_a;
	input [31:0]	i_b;
	output [31:0]	o_z;
	
	
	wire [31:0] 	t1;
	wire [31:0] 	t2;
	wire [31:0] 	t3;
	
	prim_add32	u0(.i_a(i_a), .i_b(i_b), .o_z(t1));
	prim_add32	u1(.i_a(t1), .i_b(i_b), .o_z(t2));
	prim_add32	u2(.i_a(t2), .i_b(i_b), .o_z(o_z));
	
endmodule


module prim_add32(i_a, i_b, o_z);

	input [31:0]	i_a;
	input [31:0]	i_b;
	output [31:0]	o_z;
	
	assign o_z = i_a + i_b;
endmodule

 

Desired (expected?) results (basically looks like the RTL):

module test_top(i_a, i_b, o_z);

	input [31:0]	i_a;
	input [31:0]	i_b;
	output [31:0]	o_z;
	
	
	wire [31:0] 	t1;
	wire [31:0] 	t2;
	wire [31:0] 	t3;
	
	prim_add32	u0(.i_a(i_a), .i_b(i_b), .o_z(t1));
	prim_add32	u1(.i_a(t1), .i_b(i_b), .o_z(t2));
	prim_add32	u2(.i_a(t2), .i_b(i_b), .o_z(o_z));
	
endmodule


module prim_add32(i_a, i_b, o_z);

	input [31:0]	i_a;
	input [31:0]	i_b;
	output [31:0]	o_z;
	
	assign o_z = i_a + i_b;
endmodule

 

Actual results:

...

  prim_add32   u2 (
    .o_z({o_z_31_OBUF_664, o_z_30_OBUF_663, o_z_29_OBUF_661, o_z_28_OBUF_660, o_z_27_OBUF_659, o_z_26_OBUF_658, o_z_25_OBUF_657, o_z_24_OBUF_656, 
o_z_23_OBUF_655, o_z_22_OBUF_654, o_z_21_OBUF_653, o_z_20_OBUF_652, o_z_19_OBUF_650, o_z_18_OBUF_649, o_z_17_OBUF_648, o_z_16_OBUF_647, 
o_z_15_OBUF_646, o_z_14_OBUF_645, o_z_13_OBUF_644, o_z_12_OBUF_643, o_z_11_OBUF_642, o_z_10_OBUF_641, o_z_9_OBUF_671, o_z_8_OBUF_670, o_z_7_OBUF_669, 
o_z_6_OBUF_668, o_z_5_OBUF_667, o_z_4_OBUF_666, o_z_3_OBUF_665, o_z_2_OBUF_662, o_z_1_OBUF_651, o_z_0_OBUF_640}),
    .i_a({t2[31], t2[30], t2[29], t2[28], t2[27], t2[26], t2[25], t2[24], t2[23], t2[22], t2[21], t2[20], t2[19], t2[18], t2[17], t2[16], t2[15], 
t2[14], t2[13], t2[12], t2[11], t2[10], t2[9], t2[8], t2[7], t2[6], t2[5], t2[4], t2[3], t2[2], t2[1], t2[0]}),
    .i_b({i_b_31_IBUF_600, i_b_30_IBUF_599, i_b_29_IBUF_597, i_b_28_IBUF_596, i_b_27_IBUF_595, i_b_26_IBUF_594, i_b_25_IBUF_593, i_b_24_IBUF_592, 
i_b_23_IBUF_591, i_b_22_IBUF_590, i_b_21_IBUF_589, i_b_20_IBUF_588, i_b_19_IBUF_586, i_b_18_IBUF_585, i_b_17_IBUF_584, i_b_16_IBUF_583, 
i_b_15_IBUF_582, i_b_14_IBUF_581, i_b_13_IBUF_580, i_b_12_IBUF_579, i_b_11_IBUF_578, i_b_10_IBUF_577, i_b_9_IBUF_607, i_b_8_IBUF_606, i_b_7_IBUF_605, 
i_b_6_IBUF_604, i_b_5_IBUF_603, i_b_4_IBUF_602, i_b_3_IBUF_601, i_b_2_IBUF_598, i_b_1_IBUF_587, i_b_0_IBUF_576})
  );
  prim_add32_INST_1   u1 (
    .o_z({t2[31], t2[30], t2[29], t2[28], t2[27], t2[26], t2[25], t2[24], t2[23], t2[22], t2[21], t2[20], t2[19], t2[18], t2[17], t2[16], t2[15], 
t2[14], t2[13], t2[12], t2[11], t2[10], t2[9], t2[8], t2[7], t2[6], t2[5], t2[4], t2[3], t2[2], t2[1], t2[0]}),
    .i_a({t1[31], t1[30], t1[29], t1[28], t1[27], t1[26], t1[25], t1[24], t1[23], t1[22], t1[21], t1[20], t1[19], t1[18], t1[17], t1[16], t1[15], 
t1[14], t1[13], t1[12], t1[11], t1[10], t1[9], t1[8], t1[7], t1[6], t1[5], t1[4], t1[3], t1[2], t1[1], t1[0]}),
    .i_b({i_b_31_IBUF_600, i_b_30_IBUF_599, i_b_29_IBUF_597, i_b_28_IBUF_596, i_b_27_IBUF_595, i_b_26_IBUF_594, i_b_25_IBUF_593, i_b_24_IBUF_592, 
i_b_23_IBUF_591, i_b_22_IBUF_590, i_b_21_IBUF_589, i_b_20_IBUF_588, i_b_19_IBUF_586, i_b_18_IBUF_585, i_b_17_IBUF_584, i_b_16_IBUF_583, 
i_b_15_IBUF_582, i_b_14_IBUF_581, i_b_13_IBUF_580, i_b_12_IBUF_579, i_b_11_IBUF_578, i_b_10_IBUF_577, i_b_9_IBUF_607, i_b_8_IBUF_606, i_b_7_IBUF_605, 
i_b_6_IBUF_604, i_b_5_IBUF_603, i_b_4_IBUF_602, i_b_3_IBUF_601, i_b_2_IBUF_598, i_b_1_IBUF_587, i_b_0_IBUF_576})
  );
  prim_add32_INST_2   u0 (
    .o_z({t1[31], t1[30], t1[29], t1[28], t1[27], t1[26], t1[25], t1[24], t1[23], t1[22], t1[21], t1[20], t1[19], t1[18], t1[17], t1[16], t1[15], 
t1[14], t1[13], t1[12], t1[11], t1[10], t1[9], t1[8], t1[7], t1[6], t1[5], t1[4], t1[3], t1[2], t1[1], t1[0]}),
    .i_a({i_a_31_IBUF_536, i_a_30_IBUF_535, i_a_29_IBUF_533, i_a_28_IBUF_532, i_a_27_IBUF_531, i_a_26_IBUF_530, i_a_25_IBUF_529, i_a_24_IBUF_528, 
i_a_23_IBUF_527, i_a_22_IBUF_526, i_a_21_IBUF_525, i_a_20_IBUF_524, i_a_19_IBUF_522, i_a_18_IBUF_521, i_a_17_IBUF_520, i_a_16_IBUF_519, 
i_a_15_IBUF_518, i_a_14_IBUF_517, i_a_13_IBUF_516, i_a_12_IBUF_515, i_a_11_IBUF_514, i_a_10_IBUF_513, i_a_9_IBUF_543, i_a_8_IBUF_542, i_a_7_IBUF_541, 
i_a_6_IBUF_540, i_a_5_IBUF_539, i_a_4_IBUF_538, i_a_3_IBUF_537, i_a_2_IBUF_534, i_a_1_IBUF_523, i_a_0_IBUF_512}),
    .i_b({i_b_31_IBUF_600, i_b_30_IBUF_599, i_b_29_IBUF_597, i_b_28_IBUF_596, i_b_27_IBUF_595, i_b_26_IBUF_594, i_b_25_IBUF_593, i_b_24_IBUF_592, 
i_b_23_IBUF_591, i_b_22_IBUF_590, i_b_21_IBUF_589, i_b_20_IBUF_588, i_b_19_IBUF_586, i_b_18_IBUF_585, i_b_17_IBUF_584, i_b_16_IBUF_583, 
i_b_15_IBUF_582, i_b_14_IBUF_581, i_b_13_IBUF_580, i_b_12_IBUF_579, i_b_11_IBUF_578, i_b_10_IBUF_577, i_b_9_IBUF_607, i_b_8_IBUF_606, i_b_7_IBUF_605, 
i_b_6_IBUF_604, i_b_5_IBUF_603, i_b_4_IBUF_602, i_b_3_IBUF_601, i_b_2_IBUF_598, i_b_1_IBUF_587, i_b_0_IBUF_576})
  );

...

 

I dunno,maybe I answered my own question, and what I want isn't possible in XST. :mansad:

0 Kudos
mcgett
Xilinx Employee
Xilinx Employee
5,991 Views
Registered: ‎01-03-2008

Most synthesis tools, including XST, are the "big green button" type today. And by this I mean that you tell it to go and it does. In order for th synthesis tool to optimize timing and area it will uniquify (this was a Synopsys DC Compiler command) each block that is used more than once so that it can make this optimizations and an instance by instance basis.

If you want to have the same module used always then you will need to synthesis it first as a single net list then use a blackbox wrapper in your top level code. The ISE tools will not find the underlying net list in the top level net list and then search foe an EDF or NGC file of the same name and read it in
------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
wenweizha
Contributor
Contributor
5,952 Views
Registered: ‎02-25-2009

This is interesting.

 

After I do "ngc2edif", the generated edif file is uniquified. For example, the "lpf" module has two instances and in EDIF it is uniquified:

  (cell (rename lpf_NO1_filter_cos "lpf")

  (cell (rename lpf_NO1_filter_cos "lpf")

 

I checked post-syntheses Verilog model and found that the module "lpf" is already uniquified.

 

However, in the ngc schematic view, "lpf" is not uniquified - does the shematic view do some cheating on uniquify?

 

Any idea? (BTW, my Xilinx tool version is 13.1. I checked ngc2edif options and none is to control "uniquify").

0 Kudos
viviany
Xilinx Employee
Xilinx Employee
5,937 Views
Registered: ‎05-14-2008

You can try "-mhf (generate multiple hierarchical netlist files)" option of Netgen (Generate post-synthesis simulation model).

 

Vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos