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

Quartus can't infer RAM memory blocks when preloading data from file #1

Open
Oxore opened this issue Apr 20, 2019 · 2 comments
Open

Comments

@Oxore
Copy link

Oxore commented Apr 20, 2019

Hi!

I am using DE0-nano board with Cyclone IV chip. It turns out that Quartus is not able to infer RAM blocks and it performs LAB-based synthesis for this memory implementation. I tried to use (* ramstyle = "M9K" *) attribute and create assignments of type "Infer RAMs from Raw Logic" for wb_ram_generic in Assignment Editor, but no luck.

I found out that this by-byte writing implementation in wb_ram_generic.v causes the problem:

   reg [31:0] 	 mem [0:depth-1];

   always @(posedge clk) begin
      if (we[0]) mem[waddr][7:0]   <= din[7:0];
      if (we[1]) mem[waddr][15:8]  <= din[15:8];
      if (we[2]) mem[waddr][23:16] <= din[23:16];
      if (we[3]) mem[waddr][31:24] <= din[31:24];
      dout <= mem[raddr];
   end

If I implement writing the whole four bytes as single action, by any of we signals, then I get proper RAM inferring in Quartus. No additional verilog attributes or assignments are needed. I actually decided to stick with this option for my purposes:

  reg [31:0] 	 mem [0:depth-1];

  always @(posedge clk) begin
     if (|we)
        mem[waddr] <= din;
     dout <= mem[raddr];
  end

Also splitting mem in four 8-bit wide reg arrays works fine for memory inferring in Quartus, but then I can't find a way to load data from file using the $readmemh function:

   reg [7:0] 	 mem0 [0:depth-1];
   reg [7:0] 	 mem1 [0:depth-1];
   reg [7:0] 	 mem2 [0:depth-1];
   reg [7:0] 	 mem3 [0:depth-1];

   always @(posedge clk) begin
      if (we[0]) mem0[waddr] <= din[7:0];
      if (we[1]) mem1[waddr] <= din[15:8];
      if (we[2]) mem2[waddr] <= din[23:16];
      if (we[3]) mem3[waddr] <= din[31:24];
      dout <= {mem3[raddr], mem2[raddr], mem1[raddr], mem0[raddr]};
   end

I didn't test this implementation, because I don't know how to load my data in this case, but Quartus looks fine with it and shows pretty compact footprint in Chip Planner.

So, I don't know how to solve this problem properly, according to initial design intents, but anyway, I want this information to be available for anyone who face this problem.

@ghanashyamprabhu
Copy link

ghanashyamprabhu commented Apr 20, 2019

Can you try the following code? I looked at the Cyclone IV data sheet and it seems to have explicit write enable signal apart from the bytenb signal for byte enable

reg [31:0]   mem [0:depth-1];
wire wr_en;

// assert a write enable only if there is atleast one byte to write 
assign wr_en = (|we);

   always @(posedge clk) begin
      if(wr_en) begin
          if (we[0]) mem[waddr][7:0]   <= din[7:0];
          if (we[1]) mem[waddr][15:8]  <= din[15:8];
          if (we[2]) mem[waddr][23:16] <= din[23:16];
          if (we[3]) mem[waddr][31:24] <= din[31:24];
      end
      dout <= mem[raddr];
   end

@Oxore
Copy link
Author

Oxore commented Apr 20, 2019

Hi, Ghanashyam! Thanks for participating.

I've just tried to compile your code and unfortunately it does not solve the problem. Quartus generates the same logic-based bloated footprint.

However I tried the original design and your solution without loading memory from file at all and it works well. So I think this is the root of the problem. Looks like we need to find other way to preload data in this memory implementation to make it properly inferred as memory by Quartus.

@Oxore Oxore changed the title Quartus can't infer RAM memory blocks Quartus can't infer RAM memory blocks when preloading data from file Apr 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants