instantiation problem with sequential blocks in verilog

[naveenkumarmadala]

hi,
i am trying to write a verilog code to generate TPG's.while i simulating the code it is showing the error as "Instantiation is not allowed in sequential area except checker instantiation".here i am attaching my code.please give me suggestion to remove the error.

---

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
57
58
59
60
61
62
63
module mnk(clk,rst,in,out);
input clk,rst;
input [7:0]in;
output reg[7:0]out; 
wire [7:0]w1;
wire [7:0]w2;
wire [7:0]w3;
wire [7:0]w4;
wire [7:0]w5;
wire [7:0]w6;
wire [7:0]w7;
 
 
always@(posedge clk or rst)
begin
if(rst)
              begin
                 out[7:0]<=8'b0;
               end
else 
begin   
        ca90 dut0(clk,rst,in,w1);
        ca90 dut1(clk,rst,w1,w2);
        ca90 dut2(clk,rst,w2,w3);
        ca90 dut3(clk,rst,w3,w4);
        ca90 dut4(clk,rst,w4,w5);
        ca90 dut5(clk,rst,w5,w6);
        ca90 dut6(clk,rst,w6,w7);
        ca90 dut7(clk,rst,w7,out);
    
end  
 
end
endmodule
 
 
module ca90(clk,rst,s,q);
input clk,rst;
input [7:0]s;
output reg[7:0]q; 
always@(posedge clk or rst)
begin
 
if(rst)
              begin
                 q[7:0] =8'b0;
               end
 
else 
 
begin
 q[0]=0^s[1];
 q[1]=s[0]^s[2];
 q[2]=s[1]^s[3];
 q[3]=s[2]^s[4];
 q[4]=s[3]^s[5];
 q[5]=s[4]^s[6];
 q[6]=s[5]^s[7];
 q[7]=s[6]^0;
end  
        
end
endmodule

---

if i remove always block it is not showing any error but i am not getting proper output( debug problem).please help me.

thanks and regards
naveen

 

[FvM]

TPG means? Forum rules say don't use technical abbrevations that aren't universally known.

I believe that you get unexpected results, but why do you think to solve the problem by instantiating modules in sequential code? Apart from being no legal Verilog syntax, what's the idea behind it?

 

[ads-ee]

Verilog isn't a software language, it is a hardware description language. Constructs like "calling" a DUT aren't allowed in sequential blocks.

The entire always block needs to be removed and replaced with just the ca90 dut0...ca90 dut7 lines.

From what I can tell you want to create multiple copies of the dut with each output feeding the next input. Except you think that Verilog works like a software language and you can "call" your dut in the sequential code like you would with a subroutine call in something like C.

 

[naveenkumarmadala]

i am sorry for that.my original idea is first i have to design a module(A) which has 8 bit input and 8 bit output.with such module(A) i want to generate another module(B) with 8 bit input and 8 bit output by instantiating 8 first module(A) provided output of each module is input to the next module.

here i am attaching 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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
module mnk_kr(
    input clk,rst,
   input [7:0]in,
    output reg[7:0]out); 
    
    wire [7:0]w1;
    wire [7:0]w2;
    wire [7:0]w3;
    wire [7:0]w4;
    wire [7:0]w5;
    wire [7:0]w6;
    wire [7:0]w7;
 
        ca90 dut0(clk,rst,in,w1);
        ca90 dut1(clk,rst,w1,w2);
        ca90 dut2(clk,rst,w2,w3);
        ca90 dut3(clk,rst,w3,w4);
        ca90 dut4(clk,rst,w4,w5);
        ca90 dut5(clk,rst,w5,w6);
        ca90 dut6(clk,rst,w6,w7);
        ca90 dut7(clk,rst,w7,out);
        
endmodule
 
module ca90(
    input clk,rst,
    input [7:0]s,
    output reg[7:0]q); 
 
 
always@(posedge clk , posedge rst)
    begin
        if(rst)
            begin
              q[7:0] =8'b0;
            end
        else 
        begin
            q[0]=0^s[1];
            q[1]=s[0]^s[2];
            q[2]=s[1]^s[3];
            q[3]=s[2]^s[4];
            q[4]=s[3]^s[5];
            q[5]=s[4]^s[6];
            q[6]=s[5]^s[7];
            q[7]=s[6]^0;
        end  
        
    end
endmodule

---

in testbench i generated a clock in such a way that it repeats for for every 50ns delay

---

Code Verilog - [expand]
1
2
3
4
5
6
initial begin
    clk = 0;
    forever begin
      #50 clk = !clk;
    end
end

---

in simulation waveform i am getting "xxxxxxxx" as output.

please solve my problem

 

[FvM]

Everything looks O.K., except for the test bench.
- not operating rst
- generating no input data
- placing the clk generation in initial block

 

[ads-ee]

- placing the clk generation in initial block

There's nothing wrong with generating your clock in an initial block. I do this but I don't use the logical NOT (!) I use the bitwise NOT (~). You just have to be aware that anything after the forever will never be evaluated and the initial block never finishes.

The problem the OP is having is due to not driving or initializing any of their inputs to their mnk_kr DUT in the testbench.

naveenkumarmadala, post the entire testbench file you are using, if we don't know what you are trying to run, we can't help you fix the testbench.

 

[naveenkumarmadala]

hi,here i am sending my testbench.please refer it once.

---

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
module mnk_kr_tb;
 
    reg clk;
    reg rst;
    reg [7:0] in;
 
    wire [7:0] out;
 
 
    mnk_kr uut (
        .clk(clk), 
        .rst(rst), 
        .in(in), 
        .out(out)
    );
 
    initial begin
    
        rst = 1;
        in = 8'b10100110;
        #100;
        rst = 0;
        in = 8'b10100110;
 
    end
    initial begin
    clk <= 0;
    
        forever begin
      #5 clk <= ~clk;
        end
    end
endmodule

---

 

[naveenkumarmadala]

i sent whatever i have written,if you have changed anything in test bench please send me the code and here i am attaching my simulation results done in Xilix.please tell me where i should change my code.

thank you

 

[FvM]

The testbench is fine, I don't see a "xxxxxxxx" problem.

- - - Updated - - -

I'm not using Xilinx, the results look like mnk_kr hasn't been compiled to the design, there should be a warning.

 

[ads-ee]

Using Vivado xsim...

>xvlog mnk_kr_tb.v
INFO: [VRFC 10-2263] Analyzing Verilog file "mnk_kr_tb.v" into library work
INFO: [VRFC 10-311] analyzing module mnk_kr
INFO: [VRFC 10-311] analyzing module ca90
INFO: [VRFC 10-311] analyzing module mnk_kr_tb

>xelab -debug all mnk_kr_tb
Vivado Simulator 2014.3
Copyright 1986-1999, 2001-2014 Xilinx, Inc. All Rights Reserved.
Running: C:/Xilinx/Vivado/2014.3/bin/unwrapped/win64.o/xelab.exe -debug all mnk_kr_tb
Multi-threading is on. Using 2 slave threads.
Starting static elaboration
ERROR: [VRFC 10-529] concurrent assignment to a non-net out is not permitted [mnk_kr_tb.v:21]
ERROR: [XSIM 43-3322] Static elaboration of top level Verilog design unit(s) in library work failed.

You had the following code posted:

---

Code Verilog - [expand]
1
2
3
4
5
6
module mnk_kr(
    input clk,rst,
   input [7:0]in,
    output reg[7:0]out);
 
ca90 dut7(clk,rst,w7,out);

---

which results in a problem in elaboration, since you can't connect an output of a instance to an output port using reg. You need to use wire...

---

Code Verilog - [expand]
1
2
3
4
module mnk_kr(
    input clk,rst,
   input [7:0]in,
    output [7:0]out);

---

After fixing by removing reg...

>xvlog mnk_kr_tb.v
INFO: [VRFC 10-2263] Analyzing Verilog file "mnk_kr_tb.v" into library work
INFO: [VRFC 10-311] analyzing module mnk_kr
INFO: [VRFC 10-311] analyzing module ca90
INFO: [VRFC 10-311] analyzing module mnk_kr_tb

>xelab -debug all mnk_kr_tb
Vivado Simulator 2014.3
Copyright 1986-1999, 2001-2014 Xilinx, Inc. All Rights Reserved.
Running: C:/Xilinx/Vivado/2014.3/bin/unwrapped/win64.o/xelab.exe -debug all mnk_kr_tb
Multi-threading is on. Using 2 slave threads.
Starting static elaboration
Completed static elaboration
Starting simulation data flow analysis
Completed simulation data flow analysis
Time Resolution for simulation is 1ps
Compiling module work.ca90
Compiling module work.mnk_kr
Compiling module work.mnk_kr_tb
Waiting for 2 sub-compilation(s) to finish...
0 sub-compilation(s) remaining...
Built simulation snapshot work.mnk_kr_tb

****** Webtalk v2014.3.1 (64-bit)
  **** SW Build 1034051 on Fri Oct  3 17:14:12 MDT 2014
  **** IP Build 1028902 on Fri Sep 26 17:35:13 MDT 2014
    ** Copyright 1986-2014 Xilinx, Inc. All Rights Reserved.

source xsim.dir/work.mnk_kr_tb/webtalk/xsim_webtalk.tcl -notrace
INFO: [Common 17-186] 'xsim.dir/work.mnk_kr_tb/webtalk/usage_statistics_ext_xsim.xml' has been successfully sent to Xi
linx on Tue Mar 17 12:30:39 2015. For additional details about this file, please refer to the WebTalk help file at C:/Xilinx/Vivado/2014.3/doc/webtalk_introduct
ion.html.
INFO: [Common 17-206] Exiting Webtalk at Tue Mar 17 12:30:39 2015...

>xsim -gui mnk_kr_tb

****** xsim v2014.3.1 (64-bit)
  **** SW Build 1034051 on Fri Oct  3 17:14:12 MDT 2014
  **** IP Build 1028902 on Fri Sep 26 17:35:13 MDT 2014
    ** Copyright 1986-2014 Xilinx, Inc. All Rights Reserved.

start_gui

Here is the simulation output:


I suspect that ISIM is probably ignoring the incorrectly specified reg on the output port (assuming that you are using ISE as you neglected to specify). XSIM has an different Verilog parser.

Next time be careful where you post your questions...this thread actually belongs in the Programmable Logic forum not the ASIC one.

 

[FvM]

which results in a problem in elaboration, since you can't connect an output of a instance to an output port using reg. You need to use wire...

Altera Quartus and Modelsim have apparently no problems with output ports connected to a reg data type. Neither a warning nor problems in simulating the design. This may be a concession to SystemVerilog that allows variable types (e.g. reg) connected to output ports.

 

[ads-ee]

I see you are referring to 23.3.3.2 Port connection rules for variables in 1800-2012.

The problem the OP is having seems to be a partial implementation of that rule in ISE, whereas Vivado just declares it an error (no support for SV, didn't try it with the undocumented -sv switch).

 

[FvM]

It's O.K. that the Vivado simulator enforces classical Verilog rules with no SV support enabled, just wasn't aware of the conflict as my toolchain ignored it. The error message is however clear enough to fix the problem fastly.

I don't believe that the said "xxxxxxxx" problem is related to net versus wire type, rather expect a trivial explanation as supposed.