Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with behavioural SRAM model bigger than 64-bit #1266

Closed
veripoolbot opened this issue Jan 22, 2018 · 1 comment
Closed

Issue with behavioural SRAM model bigger than 64-bit #1266

veripoolbot opened this issue Jan 22, 2018 · 1 comment
Labels
resolution: no fix needed Closed; no fix required (not a bug)

Comments

@veripoolbot
Copy link
Contributor


Author Name: Florian Zaruba (@zarubaf)
Original Redmine Issue: 1266 from https://www.veripool.org


Hi,

I am having an issue with my behavioural SRAM model:

module sram #(
     int unsigned DATA_WIDTH = 64,
     int unsigned NUM_WORDS  = 1024
)(
    input  logic                          clk_i,

    input  logic                          req_i,
    input  logic                          we_i,
    input  logic [$clog2(NUM_WORDS)-1:0]  addr_i,
    input  logic [DATA_WIDTH-1:0]         wdata_i,
    input  logic [DATA_WIDTH-1:0]         be_i,
    output logic [DATA_WIDTH-1:0]         rdata_o
);
     localparam ADDR_WIDTH = $clog2(NUM_WORDS);

     logic [DATA_WIDTH-1:0] ram [NUM_WORDS-1:0];
     logic [ADDR_WIDTH-1:0] raddr_q;

     always_ff @(posedge clk_i) begin
         if (req_i) begin
             if (!we_i)
                 raddr_q <= addr_i;
             else
                 for (int i = 0; i < DATA_WIDTH; i++)
                     if (be_i[i]) ram[addr_i][i] <= wdata_i[i];
         end
     end

     assign rdata_o = ram[raddr_q];

endmodule
</code>

The interesting thing: When compiling with default parameter values e.g.: 64-bit and below everything works fine. When increasing the loop count to 65 and above I am getting

Error-BLKLOOPINIT: src/util/behav_sram.sv:42: Unsupported: Delayed assignment to array inside for loops (non-delayed is ok - see docs)
</code>

which seems to suggest that something is incorrect with the loop unrolling. It seems to be quite an artificial limitation that is the reason why I am posting here.

Thanks, Florian

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-01-22T17:53:28Z


Use --unroll-count 256

Note this is why it says to see the documentation ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: no fix needed Closed; no fix required (not a bug)
Projects
None yet
Development

No branches or pull requests

1 participant