sub architecture selection

I doubt much can be done. Once you change the default it simply looks like a comment so I cannot imagine the tool doing anything about it.

gh-

Grasshopper,

thank you very much for your kind help. The setting of the said attribute is used only for inline pragmas. But despite that I can achieve the same effect by setting user_sub_arch to booth for all synthetic operators implied for multipliers [find / -subdesign mult*signed*].

However this is not explicitly stated in Cadence documents. Cadence documents do not tell me that I have to set architecture selection of these synthetic operators. Instead, the document tells me that I just need to set the attribute to the module.

When RTL Compiler sees an arithmetic operation during elaboration time, it infers syntetic operators. However the names of these operators (inferred submodules) are unknown by the user during elaboration time.

Therefore the user only can know the name of the module in which the multiplier is implied, nothing more. In my case above it is "mult_kernel". Then you might think it must be OK to set the multiplier architecture for the said module (done after elaboration):

rc:/> set_attr user_sub_arch booth [find / -subdesign mult_kern*]
Setting attribute of subdesign 'mult_kernel_WIDTH_A5_WIDTH_B10': 'user_sub_arch' = booth

However, when you look at the design, synthetic operator will not take Booth architecture selection.

rc:/> foreach item [find / -subdesign *] { puts "[basename $item] -> [get_attr user_sub_arch $item]" }
mult_kernel_WIDTH_A5_WIDTH_B10 -> booth
mult_unsigned ->
mux ->
mux_59 ->
mux_78 ->

rc:/> foreach item [find / -subdesign *] { puts "[basename $item] -> [get_attr sub_arch $item]" }
mult_kernel_WIDTH_A5_WIDTH_B10 -> booth
mult_unsigned -> non_booth
mux ->
mux_59 ->
mux_78 ->
rc:/>

Therefore the architecture will never be Booth.

To my point "name of synthetic operators are unknown by user during runtime":

This behaviour can be controlled by gen_module_prefix attribute. If we set this attribute before elaboration, then the synthetic operators generated during elaboration time will have this prefix. Very good.

The side effect of this attribute is that any uniquification will take this prefix, too. Therefore to identify operators in your uniquified design for debugging purposes, this attribute (gen_module_prefix) must be set some other value right before any uniquificaton.