Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] Design compiler weird behavior

Status
Not open for further replies.

Jupiter_2900

Junior Member level 3
Joined
Oct 11, 2009
Messages
29
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,763
hi everyone
i have faced a problem with design compiler

i programed a simple circuit comprise of sequential and combination logic via verilog language , and after synthesis with design compiler, i use model sim in order to post simulation and everything is fine , but the problem is : when i divide my design in two separate module ( one module contains only combinational logic of my design and the other module contains only sequential logics of my design) and this time i simulate with model sim first and my outputs are fine but when i did post synthesis simulation( after synthesis via DC ) my outputs are 'X' . i just separate my design into two module why my output must go x ??? do i have to set any parameter for design compiler to prevent this behavior ???
 

Are you sure you are driving all the i/p to their proper values?
 

Are you sure you are driving all the i/p to their proper values?
More likely is they don't have all the necessary inputs and outputs between the sequential and combinational logic in the ports so something is no longer connected and is removed from the synthesized design.

But as Jupiter_2900 has supplied no useful information we can only make time wasting conjectures. I shouldn't have even wasted the time to type this.
 

dear ads-ee
i don't get your saying about "i has not supplied useful information", what information would you like ? i think my question was quite clear then please if you don't want to help then don't
 

dear dpaul
as i said my design is same in both scenarios, ( i used same test bench ), in second scenario i just split it into two separate module , in fact because i want to measure power trace of each part (sequential and combinational) separately i had no other choice but split my code into two module because as i know prime time can give me power trace of each module seprately.
 

this is a piece of my code

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
module lookup ( indexX, indexY , clk  ,out_port);
output [7:0] out_port ;
wire [7:0] out_port ;  
input [3:0] indexX ;
wire [3:0] indexX ;
input [3:0] indexY;
wire [3:0] indexY;
reg [7:0] intermediate;
input clk;always@(posedge clk )
    begin 
     begin
       case (intermediate)
         8'h0:
           intermediate = 8'h63;
         8'h01:
           intermediate = 8'h7c;
         8'h02:
           intermediate = 8'h77;
         8'h03:
           intermediate = 8'h7b;
         8'h04:
           intermediate = 8'hf2;
         8'h05:
             ...
            8'hfe:
          intermediate = 8'hbb;
        8'hff:
          intermediate = 8'h16;
        default: 
          intermediate = 8'h00;     
       endcase
 
    end 
assign out_port = intermediate;
endmodule


above code is a simple lookup table that work well , and post synthesis simulation have no problem at all but after i change it to:
1)combinational module

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
module mem (IndexX,indexY,intemediate);
input [3:0] indexX ;
wire [3:0] indexX ;
input [3:0] indexY;
wire [3:0] indexY;
output [7:0] intermediate;
reg [7:0] intermediate;
 
always @(*)
begin
case (intermediate)
         8'h0:
           intermediate = 8'h63;
         8'h01:
           intermediate = 8'h7c;
         8'h02:
           intermediate = 8'h77;
         8'h03:
           intermediate = 8'h7b;
         8'h04:
           intermediate = 8'hf2;
         8'h05:
             ...
            8'hfe:
          intermediate = 8'hbb;
        8'hff:
          intermediate = 8'h16;
        default: 
          intermediate = 8'h00;     
       endcase
end
endmodule


2) sequential module

Code Verilog - [expand]
1
2
3
4
5
6
7
8
module regOut(inp,clk,out_port);
input [7:0] inp;
input clk;
output [7:0] out_port;
reg [7:0] out_port;
always @(posedge clk)
out_port = inp;
endmodule


3) bind these two module together

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
module lookup(indexX, indexY , clk  ,out_port);
input [3:0] indexX;
input [3:0] indexY;
input  clk;
output out_port;
 
wire [7:0] temp;
 
mem insMem(.IndexX(indexX),.indexY(indexY),.intemediate(temp));
regOut insRegOut(.inp(temp),.clk(clk),.out_port(out_port));
 
endmodule



second senario have correct answer in pre synthesis (just like first senario ) but post synthesis shows x in all outputs
actually i trace up in post synthesis scheme generated by Design compiler and i guess something is wrong with combinational module or there is some parameter that in this new scenario must have been set ???
 
Last edited by a moderator:

dear ads-ee
as i said my design after changing in two separate module, has correct functionality in modelsim simulation, but after synthesis and post-synthesis simulation something go wrong , then i don't think problem be something like the problem can be "binding or instantiation"
 

really really sorry, actully i post wrong code, this one is use , i mistype in earlier post

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
module mem (IndexX,indexY,intemediate);
input [3:0] indexX ;
wire [3:0] indexX ;
input [3:0] indexY;
wire [3:0] indexY;
output [7:0] intermediate;
reg [7:0] intermediate;
 
always @(*)
begin
case ({indexX,indexY})
         8'h0:
           intermediate = 8'h63;
         8'h01:
           intermediate = 8'h7c;
         8'h02:
           intermediate = 8'h77;
         8'h03:
           intermediate = 8'h7b;
         8'h04:
           intermediate = 8'hf2;
         8'h05:
             ...
            8'hfe:
          intermediate = 8'hbb;
        8'hff:
          intermediate = 8'h16;
        default: 
          intermediate = 8'h00;     
       endcase
end
endmodule

 

dear ads-ee
i don't get your saying about "i has not supplied useful information", what information would you like ? i think my question was quite clear then please if you don't want to help then don't
Ask someone not familiar with the problem to critique that assessment. Unless you are very good at posing questions many people tend to not put enough detail into their questions. It's very common around here.

You supplied some information but very vague and detail less. To answer questions like this requires guessing what you may or may not have tried. Hence the reply about checking the i/p driving to the correct values, and my post assuming you screwed up the connections between the blocks. Maybe you should learn how to write questions that thoroughly describe a problem with details and supporting information, so that someone has the same information you have and can try to help you.

You say you split the module into two parts but don't specify any details on what you did, did you instatiate them them in a new file with both instances of the two modules hooked up correctly or did you use them separately and expect them to magically connect to each other? There's no code so how am I supposed to know what you did? Maybe you have a coding problem but no matter how much you look at it you'll probably never see it, since you think everything is correct, but synthesis is telling you otherwise. I'd believe DC more than I believe your assessment that your split code is correct.

I've never run across a switch in a synthesis tool that breaks designs when you split the code up into multiple files, unless the synthesis tool itself was junk. If a tool like DC has a bug that it can't synthesize a two module/component designs that are instances in a top level module then I'm sure that would be a big problem for 99.9999% of the users of DC.

- - - Updated - - -

If the 3) the binding module is exactly the same as your file then the intermediate is spelled wrong, (didn't that throw a synthesis warning?)

- - - Updated - - -

Ah, I think I see the problem...

Code Verilog - [expand]
1
2
3
4
5
always @(*)
begin
case (intermediate)
         8'h0:
           intermediate = 8'h63;



you are both using the intermediate as an input (the case selection) and as an output. This means you need storage, which in turns means this has to be a latch, when it was inside the clocked process it worked as there was a register supplying intermediate to the case select. You need another input to the comb module with the registered version out_port to use as the case selection.

Also in your first code you should be using non-blocking statements in the intermediate assignments instead of blocking assignments, same thing with the out_port = inp; assignment (should be out_port <= inp;). I think you should look up the difference between the two, but in summary use <= in edge triggered (parallel/pipeline/register logic) and = in combinational logic.
 

actually in my case there is no difference between = and <=

do you think second scenario may be violate somehow timing rule (holding time and setup time) of registers ??
 

You should use the cut and paste method instead of typing it into the reply window, because you have more typo problems as upper/lower CASE is very important in Verilog.

- - - Updated - - -

actually in my case there is no difference between = and <=
sure but it's a bad habit to have and for good reasons, you can end up with simulation synthesis mismatches in various situations. (probably not in this case)

do you think second scenario may be violate somehow timing rule (holding time and setup time) of registers ??
Why would you think that are you running a timing simulation? If you are didn't you check to see if the post synthesis result meets the timing constraints?

Are you performing a functional simulation of the DC output Verilog netlist, i.e. no timing simulation? If so did you make sure the inputs from the testbench do not occur on the rising clock edge, you should always apply the stimulus from the TB to the UUT with some delay after the clock, it's one of the only appropriate places to include delays in Verilog.
 

yeah sorry about that, i double checked and now its exactly what i have tested, any clue what maybe goes wrong ???

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
module mem (IndexX,indexY,intemediate);
input [3:0] indexX ;
wire [3:0] indexX ;
input [3:0] indexY;
wire [3:0] indexY;
output [7:0] intermediate;
reg [7:0] intermediate;
 
always @(*)
begin
case ({indexX,indexY})
         8'h0:
           intermediate = 8'h63;
         8'h01:
           intermediate = 8'h7c;
         8'h02:
           intermediate = 8'h77;
         8'h03:
           intermediate = 8'h7b;
         8'h04:
           intermediate = 8'hf2;
         8'h05:
             ...
            8'hfe:
          intermediate = 8'hbb;
        8'hff:
          intermediate = 8'h16;
        default: 
          intermediate = 8'h00;     
       endcase
end
endmodule

 

Code:
module mem ([B][COLOR="#FF0000"]I[/COLOR][/B]ndexX,indexY,intemediate);
input [3:0] [B][COLOR="#FF0000"]i[/COLOR][/B]ndexX ;
wire [3:0] [B][COLOR="#FF0000"]i[/COLOR][/B]ndexX ;

These are different signals, are you sure this is what you are using? It shouldn't even compile or synthesize.

- - - Updated - - -

Have you checked when the X's start occurring? That is usually what I do in a netlist simulation.

Or moved the inputs to the design away from the clock edge? You didn't supply the TB so I'm not sure how you might be stimulating the design and if that might be part of the problem.
 

i assure you its not the problem, actually i have two questions
1) what make DC act differently in scenario 1 and 2 ? do i have to set extra setting ?
2) why simulation results (before synthesis) are different with post syntheses simulation ? my code is so simple and there is nothing neither for optimization nor vague for DC to synths incorrectly ?!!

- - - Updated - - -

this is a Tb that i have used, how comes this TB is right about single module ( scenario 1) and all of the sudden goes wrong just because i have divide my design to two module ???

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
module Tb();
    
wire [7:0] out_port ;
reg [3:0] indexX;
reg [3:0] indexY;   
reg clk;
reg [7:0] key [0:15];
reg [7:0] data [0:255];
 
 
 
integer i;
initial
    begin
        clk = 0;
        i = -1;
    end
 
always 
    #10 clk = ~clk;
 
lookup sub1( .indexX(indexX), .indexY(indexY) ,.clk(clk), .out_port(out_port) );
 
always@ (posedge clk)
begin
  key [0]=223;key [1]=230;key [2]=214;key [3]=200;key [4]=145;key [5]=216;key [6]=187;key [7]=98;
  key [8]=123;key [9]=65;key [10]=74;key [11]=34;key [12]=25;key [13]=166;key [14]=121;key [15]=13;
  
  data[0]=0;data[1]=1;data[2]=2;
...
  data[253]=253;data[254]=254;data[255]=255;
end
 
always@(posedge clk)
begin
    begin
        i <= i+1;
    
        indexX <= key[1][7:4] ^ data[i][7:4];
        indexY <= key[1][3:0] ^ data[i][3:0]; 
 
    if(i == 256)
    begin
        $display("finish"); 
        $finish;
    end
end
 
 
 
initial  
    begin 
      $monitor("%d,\t%b,\t%d,\t%d,\t%d,\t%d,\t%d",$time,clk,i,indexX,indexY,data[i],out_port);  
    end 
    
endmodule

 

i assure you its not the problem
I'm not sure you can make that claim considering the lower case i v.s. the upper case I is the difference between the first combined file and the second separated files and is also the difference between working and not working in DC versions.

Have you looked at the synthesis report and verified there is no warnings or errors that are different between the two versions of the design?

Jupiter_2900 said:
2) why simulation results (before synthesis) are different with post syntheses simulation ? my code is so simple and there is nothing neither for optimization nor vague for DC to synths incorrectly ?!!
Other than the case issue and the blocking assignment in the clocked assignment there shouldn't be any differences, I doubt the synthesis could change much either as the combonational logic doesn't change between the combined and separate versions.

I'm assuming you're performing a bottom up synthesis and then not flattening the top level? It's been decades since I used DC so I won't be able to check if you performed the correct synthesis steps even if you posted the synthesis script.

- - - Updated - - -

Just checked the code you posted in #12 doesn't compile in Modelsim, ISIM, or XSIM. It complains about the names IndexX and intemediate as being undefined, so no it's not the same code you are using, unless the simulator you are using is broken.
 

could you please explain more why should i perform "bottom up synthesis and not flattening the top level"?? i checked my script and i knew that i performed top down approach and flattening parameter is as its default !!!
 

in fact because i want to measure power trace of each part (sequential and combinational) separately i had no other choice but split my code into two module because as i know prime time can give me power trace of each module seprately.

could you please explain more why should i perform "bottom up synthesis and not flattening the top level"?? i checked my script and i knew that i performed top down approach and flattening parameter is as its default !!!
So how do you perform this power trace on aeparate modules if you've flattened the design? Seems to me it ends up the same as a single module implementation?

I've never used power trace in primetime, I don't think it existed back then, but it would seen to me you would just need to isolate the FFs in the design into a Tcl list and perform the analysis on the entire design and the subsest of the FF list and the difference is the combinational logic.
 

hi again
this time i synthesized each module separately and did post synthesis simulation for each one and there is no problem but when i bind this two module together somethings go wrong and i get x in output ?? i'm very suspect that for synthesizing separate hierachical modules i should have modified my script but how ? i use this script now , does any body have any idea ?

Code Bash - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
#################set LIBRARIES###############################
##45nm
cd /root/Desktop/V2
set target_library  "./db/NangateOpenCellLibrary_45nm.db"
set link_library    "./db/NangateOpenCellLibrary_45nm.db"
 
#############################################################
#############Define some variables###########################
#############################################################
        set my_toplevel lookup
        set my_files [list lookup.v regOut.v mem.v]         
        set my_clock_pin clk 
        set my_clk_freq_MHz 50
        set my_input_delay_ns 0
        set my_output_delay_ns 0
 
        set compile_seqmap_propa-gate_high_effort false
    set compile_seqmap_propagate_constants false
        
        define_design_lib WORK -path ./WORK
##############################################################
####################Analyze & Elaborate#######################
##############################################################
        read_verilog $my_files
    analyze -f verilog  $my_files
 
        elaborate $my_toplevel 
        current_design $my_toplevel
        link
        uniquify
        #This Command Will give a unique name for each module so the        #repeated modules won't be combined.
##################################################################
####################### Generate CLOCK############################
##################################################################
        set my_period [expr 1000 / $my_clk_freq_MHz]
                #Set the clk periode in ns e.g. 1000/200 = 5 ns which means             #200 MHz signal clk.
   
        set find_clock [find port [list $my_clock_pin]]
        if { $find_clock != [list] } {
           set clk_name $my_clock_pin
           create_clock -period $my_period $clk_name
           set_dont_touch_network $clk_name
           set_fix_hold $clk_name
        } else {
           set clk_name vclk
           create_clock -period $my_period -name $clk_name
           set_dont_touch_network $clk_name
                #do not put buffer in clk path.
           set_fix_hold $clk_name
                #want to meet hold time. 
        }       
 
 
#################################################################
############# map and optimize the design #######################
#################################################################
        
    compile -ungroup_all -map_effort medium
    compile -incremental_mapping -map_effort medium
    
    
#################################################################
############# analyze and debug the design ######################
#################################################################
 
    check_design
        remove_unconnected_ports -blast_buses [find -hierarchy cell "*"]
       
        report_constraint -all_violators > ./out/violate.txt
        set filename [format "%s%s" $my_toplevel "_dc_netlist.v"]  
              
        # %s%s determine the original name of design not the given name by design compiler!!
        write -f vhdl -output ./out/$filename -hierarchy
        set filename [format "%s%s" $my_toplevel ".sdc"]
        write_sdc ./out/$filename
        set filename [format "%s%s" $my_toplevel ".sdf"]
        write_sdf ./out/$filename
        set filename [format "%s%s" $my_toplevel ".spef"]
        write_parasitics -output ./out/$filename
        set filename [format "%s%s" $my_toplevel ".ddc"]        
        write -format ddc -hierarchy -output ./out/$filename



- - - Updated - - -

i haven't set flatten parameter at all, and i think its default will be disable. in Prime time there is an ability which will calculate each submodule power consumption
 

i haven't set flatten parameter at all, and i think its default will be disable. in Prime time there is an ability which will calculate each submodule power consumption

Which is exactly why I was wondering why you did a top down with flattening, the resultant netlist has NO hierarchy. Though I'd wager that Primetime can extract instances through Tcl grouping commands to isolate the cells you want to estimate power on, so you could probably have just used the original single file netlist.

I am wondering if the use of VHDL as your netlist output is part of the problem. VHDL is case insensitive, but Verilog is case sensitive.
 

i changed my code to lower case , my problem is not with syntax error at all,
and about hierarchy, i just set attribute "set_dont_touch" for each one of my instance in top module and i could exactly separate each module
the problem is : i googled that set_dont_touch attribute cause DC don't optimize the each module that this attribute is assign to, then if it is correct and DC only wiring between these two modules, then why each one is correct separately , but after bonding these two things go wrong? seemingly problem is with combinational logic ???? this DC drive me crazy i have set it do not change anything about each module :bang: :bang:
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top