-
Notifications
You must be signed in to change notification settings - Fork 0
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
Resources Usage #2
Comments
naxRiscv 32bitsIntel Agilex5E board
|
naxRiscv 64bits
|
NaxRiscv 32-bit on Artix7:./sqrl_acorn.py --integrated-main-ram-size=0x100 --cpu-type=naxriscv --with-fpu --with-rvc --build
|
VexRiscv SMP on Artix7:./sqrl_acorn.py --integrated-main-ram-size=0x100 --cpu-type=vexriscv_smp --build --with-rvc --with-fpu --with-wishbone-memory
|
VexiiRiscv 32bits (rv32imafc) on Intel Agilex5E boardtime ./intel_agilex5e_065b_premium_devkit.py --bus-standard=axi-lite \
--cpu-type=vexiiriscv --cpu-variant=linux --vexii-args="--with-rvc --with-rvf" \
--with-coherent-dma --build
|
Hi ^^
So yes, now i'm sure there is some memory not being properly infered into mlab / blockram. Especialy when comparing the number of registers : I will take a look at this. |
VexiiRiscv 32bits (rv32imafc) on Artix7
|
Hmm same story for vexiiRiscv, it is less showing than for naxriscv, but for sure, some memory aren't being infered as memory. |
Found a few issues :
This reduce the gap quite a lot. |
Thanks @Dolu1990 for the first analysis! |
I pushed the current WIP (enjoy-digital/litex#2011) |
Good, thanks! |
./intel_agilex5e_065b_premium_devkit.py --cpu-type=naxriscv --with-fpu --with-rvc --build
real 40m10.748s
user 113m37.792s
sys 1m12.900s
So, ALM usage reduced by 53%. But there is still something wrong. I will take a look. |
Updated enjoy-digital/litex#2011 NaxRiscv lost some weight :
|
@Dolu1990 This is great insight. Can you summarize what needed to change, or point to the changes you made in the repo for this? I would like to share this with our tools team. |
@gsteiert Related to the lack of MLAB inferation I had to :
That was mostly it. The "MLAB Add Timing Constraints For Mixed-Port Feed-Through Mode Setting Don't Care" isn't fixed as far as i know, that would be a thing to handle in the quartus project itself. |
Note that the SpinalHDL blackboxification of memories will decompose the 1 write + 3 async read into 3 * blackbox(1 write + 1 async read) |
More generaly, when i have this verilog : always @ (posedge clk) begin
if(wr_en) begin
ram_block[wr_addr] <= wr_data;
end
end
assign rd_data = ram_block[rd_addr]; I do assume that the synthesis tools would infer things into lut based RAM and that :
I did had some issue with xilinx tool in the past, where they were infering it as a block ram (by merging the register which drive rd_addr) and violating the rule :
I have to say, it is nice that NaxRiscv worked on Altera FPGA without having to debug things ^.^ |
I may have missed the reasons why without the (* ramstyle = "MLAB *) tag, quartus refused to infer things as mlab. |
VexRiscv SMP
Intel Agilex5E board
The text was updated successfully, but these errors were encountered: