You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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) beginif (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) beginif (|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:
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.
The text was updated successfully, but these errors were encountered:
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
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
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
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" forwb_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: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:Also splitting
mem
in four 8-bit widereg
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: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.
The text was updated successfully, but these errors were encountered: