1

Is It possible using different "genvar" in a loop? Is there an alternative mode to realize it?

I try with this example:

genvar i;
genvar j;
genvar k;

generate 
    k=0;
    for (i = 0; i < N; i = i + 1) 
    begin: firstfor
            for (j = 0; j < N; j = j + 1)
            begin: secondfor
                if(j>i) 
                begin 
                    assign a[i+j*N] = in[i] && p[k];
                    k=k+1;      
                end
            end
    end 
endgenerate

And when I run "Check Syntax" display this error:

Syntax error near "=". (k=k+1)
tshepang
  • 12,111
  • 21
  • 91
  • 136
leoc7
  • 119
  • 1
  • 1
  • 3

2 Answers2

1

I like this question because unless very familiar with generates it looks like it should work, however there is a similar question which tries to use an extra genvar.

The syntax is not allowed because of how the generates are unrolled. Integers can only be used inside always/initial processes.

If it is just combinatorial wiring rather than parametrised instantiation you might be able to do what you need just using integers (I would not normally recommend this):

integer i;
integer j;
integer k;

localparam N = 2;
reg [N*N:0] a ;
reg [N*N:0] in ;
reg [N*N:0] p ;

always @* begin 
  k=0;
  for (i = 0; i < N; i = i + 1) begin: firstfor
    for (j = 0; j < N; j = j + 1) begin: secondfor
      if(j>i) begin 
        a[i+j*N] = in[i] && p[k];
        k=k+1;      
      end
    end
  end
end 

Not sure how synthesis will like this but the assignments are static, it might work.

Community
  • 1
  • 1
Morgan
  • 19,934
  • 8
  • 58
  • 84
  • Morgan -- I just added an answer here. I am inexperienced in creating Verilog and wonder about the practical implications in avoiding `always @*` -- other than "hey, neat trick" is it necessary/useful? – stevesliva Mar 12 '18 at 19:09
1

It is possible to avoid always @* when you want to do more advanced math with genvar loops. Use localparam and a function.

Make k a localparam derived from the genvars with a function, and use k as originally intended.

The getk function seems to violate the principles of code reuse by basically recreating the loops from the generate block, but getk allows each unrolled loop iteration to derive the immutable localparam k from genvars i and j. There is no separate accumulating variable k that is tracked across all the unrolled loops. Both iverilog and ncvlog are happy with this.

(Note that the original example could optimize with j=i+1 as well, but there is still an issue with deriving k.)

module top();

localparam N=4;

function automatic integer getk;
  input integer istop;
  input integer jstop;
  integer i,j,k;
  begin
    k=0;
    for (i=0; i<=istop; i=i+1) begin: firstfor
      for (j=i+1; j<((i==istop)? jstop : N); j=j+1) begin: secondfor
        k=k+1;
      end
    end
    getk=k;
  end
endfunction

genvar i,j;
generate
  for (i = 0; i < N; i = i + 1) begin: firstfor
    for (j = i+1; j < N; j = j + 1) begin: secondfor
      localparam k = getk(i,j);           
      initial $display("Created i=%0d j=%0d k=%0d",i,j,k);
    end
  end
endgenerate

endmodule

Output:

$ iverilog tmptest.v 
$ ./a.out
Created i=0 j=1 k=0
Created i=0 j=2 k=1
Created i=0 j=3 k=2
Created i=1 j=2 k=3
Created i=1 j=3 k=4
Created i=2 j=3 k=5

I discovered the 'trick' of using functions to derive values from the genvars here: https://electronics.stackexchange.com/questions/53327/generate-gate-with-a-parametrized-number-of-inputs

stevesliva
  • 5,351
  • 1
  • 16
  • 39
  • I think this is a better solution, for generating static values (localparam). if you wanted to create an assignment mapping ie combinatorial logic you would need the `assign` or `always @*`. – Morgan Mar 13 '18 at 08:36
  • @Morgan - thanks. I have done mostly schematic->structural verilog work. I am playing with `generate` because I have a schematic-oriented mindset. But I think I'm overusing it, and creating too-elaborate structure (hierarchy+wires) for combinatorial functionality that can be simpler with an `always` and a specific sensitivity list. – stevesliva Mar 13 '18 at 14:46