Divider being infered by DC doesn't work?

[smaz]

Hello

I have written a program in VHDL as given below. The pre-synthesis simulation works properly. but the circuit being inferred by DC as “/” is not working properly
and giving the incorrect answers even if the fL_hlp11 is Equal to 0.

ffrocess(clk,reset)
begin
if reset='1' then
fL_hlp111<=(others=>'0');
elsif rising_edge(clk) then
fL_hlp111<=fL_hlp11/3;
end if;
end process ff;
[/QUOTE]

for example you can see the simulation results as shown below.

 

[rca]

do you have a sign control?

 

[smaz]

do you have a sign control?

If you mean the input is a signed number, fL_hlp11 is an unsigned value.
And I tried for different combinations but it still doesn't work.
Could you please give me more helps?
Thanks.

 

[FvM]

Missing points:
- involved data types
- imported libraries
- reset and clock in simulation

 

[soloktanjung]

Missing points:
- involved data types
- imported libraries
- reset and clock in simulation

Yes I agree. the problem might be not in the code you have posted. Please post a complete code to track the problem.

 

[smaz]

Hello All

Thanks for your helps. this is the code and the simulation results.

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity QAP is
	port(clk,reset:in std_logic;fL_hlp11:in unsigned(11 downto 0);
	fL_hlp111:out unsigned(11 downto 0));
end QAP;

architecture struct of QAP is 

begin 
	
	ff:process(clk,reset)
		
	begin 
	if reset='1' then
		fL_hlp111<=(others=>'0');
	elsif rising_edge(clk) then

		fL_hlp111 <= fL_hlp11/3;
	end if;
	end process ff;		
end struct;

I have written the same code in verilog but it also gives the same incorrect answers as shown below:

module QAP( clk,reset,fL_hlp11,fL_hlp111);
	input  clk, reset;
	input  [11:0] fL_hlp11;
	output [11:0] fL_hlp111;
	reg    [11:0] fL_hlp111;
	wire    [11:0] fL_hlp;

    always @(posedge clk or posedge reset) begin
            if (reset) begin 
		fL_hlp111 <= 12'b0;
	     end else begin
		fL_hlp111 <= fL_hlp;
	     end
    end
    assign fL_hlp= fL_hlp11/3;
endmodule

the simulation result is :



and this is my dc setup file:

set search_path [list {*} /.automount/vlsiserver/root/usr1/library/CSM/chrt018IC_12222/csm18ic_sc/aci/sc-x/synopsys {synopsys_root + “/dw/sim_ver”}]
set target_library [list scx_csm_18ic_ss_1p62v_125c.db]
set synthetic_library dw_foundation.sldb
set link_library [list {*} scx_csm_18ic_ff_1p98v_m40c.db scx_csm_18ic_tt_1p8v_25c.db $synthetic_library]
set symbol_library [list /.automount/vlsiserver/root/usr1/library/CSM/chrt018IC_12222/csm18ic_sc/aci/sc-x/symbols/synopsys/csm18ic.sdb]
set source_path "./src/"

 

[FvM]

Looks like a functional simulation. Are you sure that you are simulating the synthesized netlist?

Apart from this point, the code seems correct.

 

[smaz]

Looks like a functional simulation. Are you sure that you are simulating the synthesized netlist?

Apart from this point, the code seems correct.

Yes I am simulating the synthesized netlist.
Something interesting happened, I tried to make the code as simple as possible as below:

library ieee, DWARE;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use DWARE.DW_Foundation_comp_arith.all;
use work.lp_package.all;

entity QAP is
	port(clk,reset:in std_logic;fL_hlp11:in std_logic_vector(11 downto 0);
	fL_hlp111:out std_logic_vector(11 downto 0));
end QAP;

architecture struct of QAP is 
	  signal remainder   : std_logic_vector(11 downto 0);
         signal divide_by_0 : std_logic;
         signal fL_hlp,fl_hlp1: std_logic_vector(11 downto 0);
	
begin 
	
	
       fL_hlp111<=std_logic_vector(abs(signed(fL_hlp11))/"000000000011");
	
		
end struct;

now it works correctly. here is the simulation results:

once I connect it to the register it will go crazy.

What is your suggestion?

 

[FvM]

fL_hlp111<=std_logic_vector(abs(signed(fL_hlp11))/"000000000011");

Now it's a confuse type mix, using unknown libraries. But if I understand right, the data types don't matter, why did you change it?

Now we also see that it's a timing simulation. That's the case for the previous (registered) simulation, too? The delays are so small that they can't be seen in the waveforms.

According to your informations, it looks like a synthesis error.

 

[smaz]

fL_hlp111<=std_logic_vector(abs(signed(fL_hlp11))/"000000000011");

Now it's a confuse type mix, using unknown libraries. But if I understand right, the data types don't matter, why did you change it?

Now we also see that it's a timing simulation. That's the case for the previous (registered) simulation, too? The delays are so small that they can't be seen in the waveforms.

According to your informations, it looks like a synthesis error.

I changed it in that way because "/" in VHDL is only defined to signed or unsigned numbers. So I had to do type-casting.
I have disabled all the timing checks. The changes that we can see I think that they are related to the interval result of the divider.
What do you suggests?

Thanks

 

[FvM]

I changed it in that way because "/" in VHDL is only defined to signed or unsigned numbers. So I had to do type-casting.

unsigned = unsigned / natural is defined as a operator in ieee.numeric_std

 

[smaz]

unsigned = unsigned / natural is defined as a operator in ieee.numeric_std

I have also tried this but still doesn't work ;(

 

[FvM]

Presumed this is a synthesis error, it won't vanish by using functionally identical types.

But the original code is synthesizable and gives correct results with other synthesis tools. In so far, it's obviously a problem of design compiler or specific synthesis settings.

 

[smaz]

I read the docs related to divider inferred by DC but I couldn't get any specific synthesis settings.
it's really strange.
But I did some other tests which may be useful later for my freinds here. I synthesized the same code with Cadence RTL Compiler and it works properly.
I think But I am not sure that my library has a kind of problem with DC. I don't know whether it makes sense or not.

 

[rca]

are you able to run a LEC tool with the "wrong" netlist to check the LEC tool should detect also the issue?
and report that to Synopsys (solvnet).