Closed podhrmic closed 2 years ago
I can't provide any more help without the design. It is likely that some of the RAM isn't being mapped correctly to EBR but that could either be a design issue or a prjtrellis issue.
@gatecat understood. I am using RegFileLoad.v - for instruction memory as:
RegFileLoad #(.file("dmem_contents.memhex32"),
.addr_width(32'd30),
.data_width(32'd32),
.lo(30'd0),
.hi(30'h00003000),
...
and for the data memory as:
RegFileLoad #(.file("imem_contents.memhex32"),
.addr_width(32'd30),
.data_width(32'd32),
.lo(30'd0),
.hi(30'h00007000),
.binary(1'd0))
...
Is this information helpful?
Those are very big, multi port memories with async reads so they won't in general map to EBR. You should do something with a synchronous (clocked) read instead.
@gatecat adding an output register as suggested in Figure 7: RAM with Registered Output in Verilog in Lattice Synthesis Engine for Diamond User Guide did the trick, even without adding explicit verilog attributes. Thank you!
hello!
I have a simple SoC design (a nerv CPU with some memory and IO), and I am targeting the ECP5 development board. The issue I am getting is device utilization over 100%, even though the design should comfortably fit on the FPGA.
The SoC uses 36kB of RAM, which should comfortably fit on LFE5UM-85 with 468kB of RAM (see below):
However, after the synthesis
yosys synth_ecp5...
andnextpnr-ecp5 --um5g-85k --package CABGA381 ...
I end up with the following:and
Naively I would expect using more
DP16KD
elements, given they are dual port RAM?Is there some setting I am missing? Is this potentially a bug in
prjtrellis
? I haven't tried synthesis with the Lattice Diamond tool yet, so I cannot compare.