I am getting error when check my systemverilog code in quartus II

Question

I have this simple code checked with Quartus II. First, It gives me error 5000 iterations for loop limit then I try to change verilog constant loop limit variable in settings and now it is giving me this error

Error (293007): Current module quartus_map ended unexpectedly. Verify that you have sufficient memory available to compile your design. You can view disk space and physical RAM requirements on the System and Software Requirements page of the Intel FPGA website ( http://dl.altera.com/requirements/ ).

Is this something related to tool limitation or am I doing something wrong with my code?

Here is my code:

 module Branch_status_table #(parameter BST_length = 16383) //16383
(
    output reg [2:1] status,
    output reg [32:1] PC_predict_o,
    
    input wire [2:1] status_update,
    input wire [32:1] PC_in, PC_update,
    input wire [32:1] PC_predict_update,
    input wire clk,en_1,RST
);
    wire [14:1] PC_index, PC_index_update;


    //Internal memory
    reg [2:1] status_bits [BST_length:0];
    reg [32:1] PC_predict [BST_length:0];
    reg [16:1] PC [BST_length:0];


    //Combinational
    
    assign PC_index = PC_in [16:3];
    assign PC_index_update = PC_update [16:3];


    //
    initial begin
        for ( int i=0; i <= BST_length; i=i+1) begin
                status_bits[i] <= 0;
                PC_predict[i] <= 0;
                PC[i]<=0;
        end
    end
    //Prediction
    always_ff @(posedge clk) begin
        
        if ( (PC[PC_index]==PC_in[32:17]) && (status_bits[PC_index]!=0) ) begin
            status <= status_bits [PC_index];
            PC_predict_o <= PC_predict [PC_index];
        end
        else begin
            status <= 0;
            PC_predict_o <= 0;
        end
    end
    //Update
    always_ff @(posedge clk) begin
            if (en_1==1) begin
                status_bits[PC_index_update] <= status_update;
                PC [PC_index_update] <= PC_update[32:17] ;
                PC_predict[PC_index_update] <= PC_predict_update;
            end
            else begin
                status_bits[PC_index_update] <= status_bits[PC_index_update] ;
                        PC [PC_index_update] <= PC [PC_index_update] ;
                        PC_predict[PC_index_update] <= PC_predict[PC_index_update] ;
            end
        
    end 
endmodule

Answer 1

There is at one least coding issue here and maybe a resource utilization issue.
The coding issue:
Your code is inferring block ram, and trying to initialize/reset it.
In general you can't reset block rams using a single initial block.
That style of initialization can be done in a testbench, not in RTL.
Synthesis tools have physical limits.

To reset/initialize a block ram you must write 0 to each address. You must use the same type of synchronous process (always @(posedge clk)) because the memory is a synchronous device. Put a mux in front of the write port and use a state machine a start up to write 0's to every address, then when the state machine finishes that move to a operational state where the BRAM behaves like you normally want it to.

This page discusses the issue.
https://www.edaboard.com/threads/how-to-clear-reset-my-bram-in-vhdl-xilinx.247572/
This is a Xilinx related answer; other vendors work the same way.

Summarizing the coding issue: You probably don't need to initialize and you can't do it this way:

    initial begin
        for ( int i=0; i <= BST_length; i=i+1) begin
                status_bits[i] <= 0;
                PC_predict[i] <= 0;
                PC[i]<=0;
        end
    end

Potential Utilization Issue:
FPGAs' have finite resources.
The tool may be trying to indicate the code infers more block ram than the part has. To verify this premise, change parameter BST_length from 16K to something small like 8 and see if the utilization issue ("insufficient memory) goes away. If it goes away then you need to re-design with less memory.

You could also analyze this by hand by understanding how much BRAM the part has and how much you are attempting to infer. Don't infer more than the part has.

I think the tool is confused because of two issues related to the same inference of BRAM. When you change your code a little the tool switches trying to tell you about the other issue.