[SOLVED] Sub-optimal Logic Synthesis in Encounter RTL Compiler

I am new to Encounter RTL Compiler and I have created a simple circuit in Verilog in order to gain more understanding of the environment. The circuit is a 2-bit down-counter and this is the code used:

module down_counter(out, clk);
output [1:0] out;
input clk;
reg [1:0] out;
always @(posedge clk)
begin
out <= out - 1;
end
endmodule

The most optimal way to implement such a counter is by simply using two positive-edge DFFs, where each DFF is a bit of the counter (bit 0 and bit 1). Both DFFs use their own inverted output as D input. The bit 0 DFF recieves clk input from the external clock. The bit 1 DFF recieves clk input from the noninverted output of the bit 0 DFF. In short, it is not necessary to completely understand this paragraph; it is only important to know that the optimal design requires 2 DFFs and no additional logic.

However, this is not the result after logic synthesis in Encounter RTL Compiler.
My procedure has been as follows:
Set library attribute to a library containing a positive-edge DFF cell (dff_c2mosD)
Elaborate
Synthesize to generic
Synthesize to mapped

After synthesizing, even with a high effort level the following circuit is produced:



As you can see, instead of utilizing the inverting output of the DFF on the right, the compiler uses other logic to create the DFF input, requiring the extra XNOR gate. What is causing this extra logic? In other words, why is it not producing an optimal design?

Perhaps these details will help you with what the problem isn't. Here is what I have tried:
1. Using different libraries with different DFF definitions
2. Defining power and/or timing constraints before synthesis, including using an sdc file
3. Duplicating my proceedure on other machines
4. Using different designs, such as a DFF with asynchronous clear and preset

All efforts have failed to produce an optimal design in terms of timing, power, area or gate count, so I am looking forward to hearing from some of you experts about this. Shouldn't RTL compiler optimize for at least one of these factors by default?

The "optimal" solution you want is a ripple counter, which has a delay from clock input to output. The delay increases for each counter stage, and there will be problems with setup time if you feed the outputs to other parts of a synchronous design.

The solution from the tool is fully synchronous and all outputs will switch at the same time.

Ah, thank you, you have illuminated quite a bit. Very helpful.

Suppose that I do not care about the delay introduced by the ripple counter. Is it possible to set power or area constraints so that the compiler produces this ripple counter I desire?

When you wrote this RTL you meant exactelly the same RTL Compiler made.

module down_counter(out, clk);
output [1:0] out;
input clk;
reg [1:0] out;
always @(posedge clk)
begin
out <= out - 1;
end
endmodule

If RTLC use "optimal" design it changes the function of initial RTL. You should rewrite RTL to get "optimal" RTL.

module down_counter(out, clk);
output [1:0] out;
input clk;
reg [1:0] out;

always @(posedge clk)
out[0] <= !out[0];

always @(posedge out[0])
out[1] <= !out[1];

endmodule


The little problem I see that your design doesn't have initial values so you can't model it!
out = out -1 = X(initial) -1 = still X;

I think having a reset signal in the design will fix lots of issues here. So could you please modify the code that it has reset signal and re-synthesize it.

module down_counter(out, clk, reset);
output [1:0] out;
input clk;
input reset;
reg [1:0] out;

always @(posedge clk)
if (reset ) out <= 2'b1;
else out <= out -1;

endmodule

I believe this code will be OK.

I wasn't really concerned that the design was perfect or even useful but thanks for your help. I was more interested in finding material to acquire methods and flows to manipulate the synthesis but I understand the program better now. It truly was smarter then me.

For those find themselves with similar problems as me, I found this documentation to be exactly what I was looking for.