very large clocked process makes it impossible to bring out non-clocked signals about picorv32 HOT 6 CLOSED

Hmm.. Does Quartus handle the memory fine if you use this pre-synthesized version of the design?
http://scratch.clifford.at/picorv32_syn.v

(PicoRV32 in its default configuration, generated with yosys -p 'prep -nomem -top picorv32; memory -nomap; opt' -o picorv32_syn.v picorv32.v.)

from picorv32.

I don't have quartus installed to test this, but I think commit 82d837b might solve the issue. Please give it a try and let me know if it does.

from picorv32.

With our picorv32_syn.v file, Quartus infers not one but two cpuregs, a block memory not MLABs. They'r each dual ported too, 32-wide and 32-deep. I think that's progress. :-)

However the commit 82d837b synthesizes to FFs.

BTW: one other reasons to make cpuregs an explicit RAM is because it's the only way to go forward when using a non-FPGA synthesis flow. Those typically don't support automated RAM inference.

from picorv32.

It's uplifting (or depressing, depending on once pov) that a tool like Yosys is better at this than Quartus!

Looks like I should install Yosys for experimentation.

from picorv32.

Quartus infers not one but two cpuregs

That's to be expected. The PicoRV32 default configuration is to infer a register file with two read ports (ENABLE_REGS_DUALPORT), which is usually implemented from two block rams.

However commit 82d837b synthesizes to FFs.

What's about commit c9519df?

one other reasons to make cpuregs an explicit RAM is because it's the only way to go forward when using a non-FPGA synthesis flow.

Well... with Yosys you can infer custom RAM resources pretty easily. Also: on an ASIC the area difference between a memory generated by a memory compiler and the memory from FFs that the synth tool creates is nowhere near what you would have on an FPGA. Usually it's not worth the effort for a 1 kBit memory like the RV32 register file. Especially when considering that usually you have something like a program memory right next to the CPU, and that will have to hold much more than just 32 words.

from picorv32.

What's about commit c9519df?

Success!

That's to be expected. The PicoRV32 default configuration is to infer a register file with two read ports (ENABLE_REGS_DUALPORT), which is usually implemented from two block rams.

From quick inspection of the code, I thought that there weren't cases where you read and write to the register files during the same cycle (cpu_state_fetch. In that case, a single dualported memory with 2 RW ports would have been sufficient. But I see now that this is not the case. Carry on. :-)

With this, the issue can be closed. If one day, I really need to hand-instantiate a small RAM, it's only a minor change in the code.

from picorv32.