Why does Synopsys DC need Inverters and Buffers if my RTL only has XOR logic?

[hw2000]

My RTL code is nothing but a bunch of XOR operations similar to this:

module h3(input[255:0] x, output[260:0] hash);
wire[27-1:0] temp;
assign temp[0] = x[32]^x[190]^x[84]^x[219]^x[247]^x[8]^x[86]^x[61]^x[34]^x[12]^x[19]^x[44]^x[245]^x[100]^x[23]^x[145]^x[157]^x[236]^x[91]^x[25]^x[158]^x[99]^x[235]^x[237]^x[206]^x[142]^x[144]^x[104]^x[148]^x[180]^x[132]^x[18]^x[170]^x[155]^x[238]^x[128]^x[9]^x[189]^x[80]^x[68]^x[211]^x[136]^x[172]^x[94]^x[130]^x[126]^x[21]^x[214]^x[198]^x[192]^x[55]^x[162];
assign temp[1] = x[224]^x[199]^x[232]^x[238]^x[112]^x[157]^x[59]^x[151]^x[250]^x[66]^x[27]^x[194]^x[221]^x[211]^x[119]^x[88]^x[152]^x[163]^x[102]^x[186]^x[178]^x[237]^x[251]^x[115]^x[21]^x[18]^x[189]^x[45]^x[72]^x[165]^x[125]^x[249]^x[77]^x[234]^x[11]^x[169]^x[13]^x[179]^x[46]^x[99]^x[255]^x[86]^x[177]^x[200]^x[203]^x[193]^x[201]^x[171]^x[40]^x[69]^x[161]^x[62];
assign temp[2] = x[254]^x[217]^x[116]^x[110]^x[214]^x[165]^x[20]^x[44]^x[201]^x[65]^x[184]^x[112]^x[157]^x[50]^x[74]^x[136]^x[196]^x[160]^x[38]^x[98]^x[48]^x[81]^x[233]^x[109]^x[191]^x[85]^x[220]^x[1]^x[37]^x[12]^x[68]^x[129]^x[146]^x[13]^x[10]^x[141]^x[207]^x[11]^x[178]^x[35]^x[23]^x[3]^x[212]^x[21]^x[39]^x[83]^x[59]^x[45]^x[49]^x[221]^x[78]^x[188];
...
assign temp[26] = x[143]^x[12]^x[89]^x[84]^x[26]^x[112]^x[73]^x[8]^x[166]^x[220]^x[41]^x[103]^x[219]^x[235]^x[142]^x[114]^x[11]^x[211]^x[178]^x[30]^x[17]^x[134]^x[67]^x[160]^x[38]^x[156]^x[56]^x[144]^x[163]^x[133]^x[222]^x[228]^x[180]^x[130]^x[137]^x[138]^x[126]^x[95]^x[63]^x[240]^x[139]^x[39]^x[131]^x[164]^x[238]^x[190]^x[118]^x[206]^x[169]^x[181]^x[184]^x[13];

assign hash[0] = temp[9];
assign hash[1] = temp[11];
assign hash[2] = temp[19];
assign hash[3] = temp[20];
...
assign hash[259] = temp[5];
assign hash[260] = temp[14];
endmodule

When I am synthesizing this using Nangate's 45nm library on Synopsys Design Compiler, it reports a netlist that has inverters and buffers. I did not understand why these were needed. So, I relaxed all my load and time constraints and compiled it again, this time disabling the inverter cells using the "set_dont_use" command. Now, DC reports that it is not able to complete mapping. It says that "An inverter is required for mapping. (OPT-101)". Can someone teach me why inverters and buffers are required to synthesize this kind of logic, and if/how I can avoid it?

 

[oratie]

It does not related to your RTL code. The DC just check inverter availability before starting synthesis. Take it as is.

 

[hw2000]

It does not related to your RTL code. The DC just check inverter availability before starting synthesis. Take it as is.

But if I allow the standard cell of inverter and buffer to be used, it creates a netlist that uses inverters and buffers and takes more area and I don't understand why it is required. Can you tell me how I can force synopsys to just use XOR gates to synthesise this RTL?

 

[dick_freebird]

Maybe your timing constraints (?) demand buffering
due to excessive fanout, or asking it to be faster
than technology really delivers at "normal" fanout
& wireload?

 

[oratie]

Try to synthesize your design without timing constarinats. Than, set attr dont_touch on all nets, size_only on all cells, apply timing constrains and run incremental synthesis. As a hint.

 

[ThisIsNotSam]

Your input already looks like a netlist (it is almost structural Verilog, barely looks like RTL). Why wouldn't you simply instantiate XORs by hand if that is what you really want?

 

[hw2000]

Thank you @ThisIsNotSam and @oratie. I think DC was just aggressively trying to cut down the max delay from input to output, even after I relaxed the delay constraints. So, what I did is the following:
1. As ThisisNotSam mentioned, I created my Verilog itself as a netlist instantiating Nangate's XOR cells. I did not know a straight forward way to do it, so I made DC compile without target library mapping which created a netlist with the ideal GTECH XOR gates and no other inverters/buffers. I used this netlist and replaced all the GTECH XOR gate instantiations with Nangate's XOR cell instantiation.

2. Following oratie's advice, I then used the set_dont_touch on all nets so that DC would synthesize just like I wanted.

The only difference between this compiled design and the original one that DC was outputting is that DC's version had ~0.1 ns less delay in the critical path. But this came at a huge cost in area and power.

 

[mmrakshith]

Thank you @ThisIsNotSam and @oratie. I think DC was just aggressively trying to cut down the max delay from input to output, even after I relaxed the delay constraints. So, what I did is the following:
1. As ThisisNotSam mentioned, I created my Verilog itself as a netlist instantiating Nangate's XOR cells. I did not know a straight forward way to do it, so I made DC compile without target library mapping which created a netlist with the ideal GTECH XOR gates and no other inverters/buffers. I used this netlist and replaced all the GTECH XOR gate instantiations with Nangate's XOR cell instantiation.

2. Following oratie's advice, I then used the set_dont_touch on all nets so that DC would synthesize just like I wanted.

The only difference between this compiled design and the original one that DC was outputting is that DC's version had ~0.1 ns less delay in the critical path. But this came at a huge cost in area and power.

You needn't do a compile without the target library, you could have hard instantiated the XOR cells in the RTL and it would pick the appropriate standard cell from the LIB . If its hard instantiated then DC has no choice but to insert the cells. It would be a lot of effort in case you had a huge number of cells and you had to change everything manually. May be try a run where in you still supply the timing constraints, this time as it knows the cell transition times from the .LIB it would optimize more effectively and you could meet your area requirements also.

 

[ThisIsNotSam]

You needn't do a compile without the target library, you could have hard instantiated the XOR cells in the RTL and it would pick the appropriate standard cell from the LIB . If its hard instantiated then DC has no choice but to insert the cells. It would be a lot of effort in case you had a huge number of cells and you had to change everything manually. May be try a run where in you still supply the timing constraints, this time as it knows the cell transition times from the .LIB it would optimize more effectively and you could meet your area requirements also.

this behavior is not guaranteed. if the design gets elaborated and the cells are not marked as dont_touch, DC is allowed to replace them.

 

[mmrakshith]

this behavior is not guaranteed. if the design gets elaborated and the cells are not marked as dont_touch, DC is allowed to replace them.

Yes, I agree with this.
DC can replace the cells after they’ve been inserted.

My POV was that, hw2000 said he re-instantiated all the GTECH cells into XOR cells which is laborious, so hard instantiating them is simpler. I guess you also meant the same in your previous reply.

 

[ThisIsNotSam]

Correct, I did. there was no need to use the GTECH middle step.