please add a simple option for dumping *all* arrays in a design about iverilog

[martinwhitaker]

A workaround for (2) is to use generate loops, e.g.

reg [7:0] memory[3:0][3:0];

genvar i, j;

for (i = 0; i < 4; i = i + 1) begin
  for (j = 0; j < 4; j = j + 1) begin
    initial $dumpvars(0, memory[i][j]);
  end  
end

This is not ideal, because it bloats the compiler output file with a lot of unnecessary scope declarations, but it's better than nothing. You do then hit the problem that Icarus flattens multi-dimensional arrays into a single dimension, so your dump file contains flattened indices, but again this requires a rework of the way multi-dimensional arrays are handled.

[martinwhitaker]

I would agree that the ability to pass an array name to $dumpvars to have it dump the entire array would be useful, but this has previously been discussed and rejected by the other Icarus developers (http://sourceforge.net/p/iverilog/feature-requests/21).

I am less convinced that having an option to automatically dump all arrays would be useful - particularly for a complex project, where you would expect to have many large arrays. At least in VCD, if not the other dump formats, I believe each array word would have to be listed as a separate signal, so the dump file would get very bloated.

For your problem with dumping the words of a multi-dimensional array, I can't reproduce the errors you are seeing. When I put your code sample into an otherwise empty module, it compiles without error. If you are still seeing this with the current head of the master branch, can you provide a complete test case, and the compiler command line options you are using.

N.B. I do see a problem at run time with your test case, which I will look into, but I fear it may not be soluble without reworking the way Icarus handles multi-dimensional arrays. This is probably needed anyway, to fix http://sourceforge.net/p/iverilog/bugs/953.

[kwantam]

Sorry that my test case was incomplete. As I've dug into this more, it turns out that I was conflating two separate but similar issues. I have posted test cases for each below.

You are right that dumping everything bloats the dumpfile. But it happens often enough that one finds a problem and doesn't want to have to re-run a simulation to chase it down that the major Verilog vendors have added options to dump everything. Yes, there's a tradeoff here between the time spent re-running a failing simulation after adding one more element to the dump list, versus the slowdown caused by dumping too much data to disk; but one can sometimes avoid both, e.g., by kicking off long-running simulations overnight---if only one can ask the simulator to do something as simple as save everything!

(For example, NCVerilog has $shm_probe(), and frankly it is far and away more useful for sprawling bug chases than anything Icarus provides. In my experience, test bench dump lists tend to dump fewer and fewer signals as they mature; but in the initial stages of development the approach is often to just dump everything.)

The last time this was discussed, Cary R. said

The more I think about this the more I'm unsure we should implement this functionality. It is trivial to make a loop to dump the elements you want from the array and making it so that a user could dump a large array by accident may not be what we want.

But the reality is that it's not trivial to write down a whole bunch of loops over a bunch of arrays buried deep in the hierarchy---and even if it were, the functionality is presently broken! And the idea that a person might invoke a command line option or system task by accident is beyond unconvincing.

But look, I realize this project has a culture around it and I'm just some random dude from the internet. So if can't convince y'all that adding an option is a sensible way to go, no problem. If I end up implementing the functionality before someone else does, I'll submit a PR, and if y'all don't like it, no worries---at least I'll be happily creating my massive bloated fst files 😃

[kwantam]

First test case covers (2), above.

module test_counter
   #( parameter ncounters = 8
    , parameter nbanks = 4
    , parameter nbits = 8
   )( input         clk
    , input         rstb
    );

integer i, j;
reg [nbits-1:0] count_reg [nbanks-1:0] [ncounters-1:0];

always @(posedge clk or negedge rstb) begin
    if (~rstb) begin
        for (i = 0; i < nbanks; i = i + 1) begin
            for (j = 0; j < ncounters; j = j + 1) begin
                count_reg[i][j] <= 0;
            end
        end
    end else begin
        for (i = 0; i < nbanks; i = i + 1) begin
            for (j = 0; j < ncounters; j = j + 1) begin
                count_reg[i][j] <= count_reg[i][j] + i * j;
            end
        end
    end
end

endmodule

module test ();

reg clk, rstb;

localparam ncounters = 8;
localparam nbanks = 4;
localparam nbits = 16;

test_counter
   #( .ncounters    (ncounters)
    , .nbanks       (nbanks)
    , .nbits        (nbits)
    ) itcount
    ( .clk          (clk)
    , .rstb         (rstb)
    );

integer i, j;
initial begin
    $dumpfile("test2.fst");
    $dumpvars;
    for (i = 0; i < nbanks; i = i + 1) begin
        for (j = 0; j < ncounters; j = j + 1) begin
            $dumpvars(0, itcount.count_reg[i][j]);
        end
    end

    clk <= 0;
    rstb <= 0;
    #1 clk <= 1;
    rstb <= 1;

    #1000 $finish;
end

always @(clk) begin
    clk <= #1 ~clk;
end

endmodule

Compiling with iverilog -g2012 test.sv works, but running the result of this compilation gives

ERROR: test.sv:53: $dumpvars cannot dump a vpiConstant.

[kwantam]

Oh, cool! Thanks for the suggestion.

[martinwhitaker]

In (3) you've hit a Verilog language limitation. From the standard:

"Names in a hierarchical path name that refer to instance arrays or loop generate blocks may be followed immediately by a constant expression in square brackets."

(my bold). Again a generate loop would solve the problem.

[kwantam]

D'oh, you're right.

I should have known that I have to use generate in that case; I've made that mistake before 😃

[martinwhitaker]

I don't think this one will get implemented, as discussed above.