is it a bug of Design Compiler ?

[jinruan]

search output design compiler

there is such a code in my design, but when i synthesize the code, i find the result is wrong. What's the problem? is it the problem of my code or it's a bug of DC? the target library is slow/CSM25.

the code:

always @ ( posedge clk or negedge rst_n)
if(!rst_n)
dout<=1'b0;
else if(en)
dout<=1'b0;
else
dout<=din ;

the synthesize result:
SDFFRX1 ( .SI(en), .SE(din), .D(1'b0), .CK(clk), .RN(rst_n), .Q(dout));

i think the result should be:
SDFFRX1 ( .SI(din), .SE(en), .D(1'b0), .CK(clk), .RN(rst_n), .Q(dout));

 

[leeenghan]

sdf design compiler bug

Hi Jinruan,

Be patience and trace through the logic. Both are the same.

Consider the result from Synopsys, and consider the case where din==0 and din==1, and you will see how smart Synospsy is!

By the way, the tool uses scan FF to implement the logic. This might not be a good idea if you want to insert scan later, or sometime the timing from the SI path can give surprise (e.g. very long setup time).

Regards,
Eng Han

 

[jinruan]

but when "din" reach the cell slower than "en“ or when din is "x" state sometimes , the dynamic simulation indicate that dout will always be in "x" state.

 

[leeenghan]

Hi Jinruan,

>> but when "din" reach the cell slower than "en“

If this is the case your design is running too slow for the clock speed. There is a reason why DC create the logic that this. Most probably the circuit is smaller/faster compare to the one you expected.

>> when din is "x" state sometimes

If you have this problem, you need to improve the model for the FF. If "en" is "X" but both the other 2 inputs of the mux are both "0" or "1", then the output should be the value of the input. It is possible to model this behaviour by using gate (although I cannot remember off-hand).

Regards,
Eng Han

 

[joe2moon]

>> but when "din" reach the cell slower than "en?

It doesn't matter "din" or "en" signal reach first, as long as both of them are stable before the clk(clock) rising edge.

So if your synthesis met the timing, then you should not see "x"(unknown) appear at the dout(output).
---------------------------------------------------------------------------------------
>> there is such a code in my design, but when i synthesize the code, i find the result is wrong.

By the way, it maybe better to do the logic equivalence check by tool rather than do it manually. (Ex. Conformal-LEC or Formality can do this well.)

And do the STA(static timing analysis) to make sure the gate-level netlist and corresponding SDF(standard delay format) file meets the timing.

Finally, if there still gate-level simulation problems exist in the design, then compare the simulation result(maybe the waveform) between the "expected" result and the "incorrect" one to find out the reason.
----------------------------------------------------------------------------------------
Hope above information can help more or less.

 

[ManojG]

Hi Eng Han,

Please forgive my ignorance. I have one doubt regarding the statement SDFFRX1 ( .SI(en), .SE(din), .D(1'b0), .CK(clk), .RN(rst_n), .Q(dout)); == SDFFRX1 ( .SI(din), .SE(en), .D(1'b0), .CK(clk), .RN(rst_n), .Q(dout));

As per the RTL whenever the en == 1'b1 dout <= 1'b0; As per the synthesis result when din == 1'b1 and en == 1'b1 the dout is going to be 1'b1; So how the synthesis result is same as the RTL? I don't have the CSM25 library data sheet, instead i used TSMC0.13G datasheet for the SDFFRX1 functionality. Will you pleae clarify?

Thanks and Regards
Manoj

 

[AH Ling]

always @ ( posedge clk or negedge rst_n)
if(!rst_n)
dout<=1'b0;

//modification choice 1
else begin //if rst_n == 1
if(en)
dout<=1'b0;
else
dout<=din ;
end
//modification choice 2
else begin
case(en)
1'b0:dout<=din;
1'b1:dout<1'b0;
endcase
end

i am not sure what u are designing but from your coding seemed like bit not so good for synthesizer...by modify ur code like above either choice 1 or 2, synthesizer may be able to synthesize better especially if your code is long....good way of coding is important for efficient synthesis as told by a senior engineer ...always know what kind of hardware you want to generate...i would say choice 2 is better as it don't use priority but the hardware generated will be parallel...btw, correct me if i am wrong

 

[jinruan]

i have synthesize the code with the three coding style , and found that the result is the same.

 

[tony_taoyh]

I think, you can try to use:
//synopsys async_set_reset "rst_n"
//synopsys sync_set_reset "en"

always @ ( posedge clk or negedge rst_n)
if(!rst_n)
dout<=1'b0;
else if(en)
dout<=1'b0;
else
dout<=din ;

 

[heartfree]

Can you paste the behaviour model of SDFFRX1 in your library?
I have same puzzle with ManojG