How far can the logic optimization of design compiler go?

Hi,

In the recent research work I want to use design compiler (DC) to reduce the number of FFs in my design (the basic idea is to compare the primary outputs (POs) of one fault-free sequential design and one copy of this design - everything is the same except that one fault is injected in specific location, and one "error" signal is generated if POs are different.)

The problem I met is that the logic synthesis of DC seems to have very limited effects on the reduction of number of FFs (almost the same as before synthesis) for the constructed two sequential designs with PO comparison.

To try one extreme case, I even constructed two EXACTLY the same modules - two instantiations with same inputs, and compare the POs (View attachment test.zip) . Theoretically all the POs are the same and the "error" should be constant 0.
I expected that DC will optimise out all the FFs in two instantiations and reduce the number of FFs to 0, with one "assign error = 1'b0" left in the generated netlist.

However, the synthesis netlist shows that all 10 FFs are still there, even with the DC command "set_optimize_registers" and "compile_ultra -retime".

It seems DC didn't explore and find the equivalence of two exactly same module, therefore just generate the normal flattened netlist.

For this obvious case, the synthesis result of DC is a little surprising. I'm not sure whether it's due to that I didn't use the right DC commands or there are intrinsic limitations of the optimisation strength of DC?

Your opinion is really appreciated!

Thanks in advance.

I think you are referring to register merging behavior.
Not sure if this will help, but you might want to try ...
-> Adding the -timing_high_effort_script option to "compile_ultra -retime", and maybe also add -ungroup_all on top of that as well.
-> Making sure the compile_enable_register_merging variable is true (e.g. in case some common-installed implicit setup script changed it to false)
And maybe also do the same with compile_enable_register_merging_with_exceptions (but should not apply in the absence of timing-exceptions).
-> Explicitly applying the set_register_merging command

I wonder if the initial mapping phase of the two sub-modules results in differently optimized logic feeding outp and overflw and stato, and could be confusing the flop equivalence analysis.
It might depend on what Synopsys' definition of "equal and opposite registers" is, specifically with non-trivial logic feeding the registers of interest.

1- your title indicate logic optimisation, and after you wrote about flop reduction, that's not the same, no? The logic optimisation for a synthesis tool is the combinational cell, it is difficult for a tool to reduce the number of flops, except if his output is never used, or data input stuck to one or zero.
2- in your case, the tool could not know that the two blocks are equivalents, because the cone of logic to generate outp & outp_f (same for overflw(_f)) come from two differents flops. The tools does not look at the cone connected to the data pin of the flops.
3- a synthesis tool want to match the setup from clock element to clock element or input to clock elements or clock elements to output or input to outputs, not to try to reduce the design over the flop which are start/stop points for him.

4- that's good to know the tool are not able to removed that logic, which is needed to safe engine to have duplicate function, or for space system (against cosmic ray).