<swetland>
maybe more of a vexriscv than litex question --- vexriscv appears to implement lr/sc but not amo*, which does not seem unreasonable, *but* it also seems to hang forever on amo* instructions which is annoying. any ideas if there's an easy fix for this?
<swetland>
hmmm. weird. I'll have to dig a bit deeper and figure out what I'm doing wrong
<swetland>
I wish vexriscv had a csr with a bitfield indicating which features were present so I could interrogate a generated core ^^
<swetland>
okay.... updated my litex checkout to latest git versions and now running the target python script doesn't generate the build/$target/... stuff and compile the firmware
<swetland>
ah... it now wants --build... but now the design no longer fits in the icesugar-pro... uses a lot more DP16K than before I updated. not sure why
<swetland>
ah. misplaced my patch to reduce the video fifo depth
<cr1901>
On one hand, the number of RV extensions is... bad. On the other, I think the base ISA is excellent minimalism for putting smol cores in smol places (no MUL/DIV).
<cr1901>
So I'm torn :P
<swetland>
yeah RV32I is a nice baseline and even RV32IMA is pretty light to run a slightly larger system without a lot of cruft
<cr1901>
weren't you doing a 16-bit RISC a long time ago? Would be curious if anything came of the hardware impl
<cr1901>
all CPUs are friends :)
<swetland>
gatecat: found it: bugs with linker script and bss init code resulted in failure to zero some variables -- qemu memory appears to be zero on boot, but not so on the actual sdram
<swetland>
cr1901: I was! haven't had time to play with it for a while
<cr1901>
Still would be curious to see it completed eventually, to add to the "me-too" RISC pile :)
<swetland>
at the moment I'm getting setup for some little workshops I'm doing on how-oses-work / how-to-write-an-os. using RV32IMA w/ U/S/M + MMU on Qemu and ECP5 (Litex/VexRISCV) as the platform
<cr1901>
I like RV's base ISA a LOT, and... not much else. And I kinda buy the conspiracy theory that RV was designed to require insn fusion for high performance. And the insn fusion for RV was patented.
<swetland>
I had not heard that. interesting. I like it as a "real" modern ISA with solid gcc/clang support and readily available soft implementations. nice teaching tool. not deeply invested in it otherwise as yet
<cr1901>
Well, don't take me too seriously re: the conspiracy theory. The patent part is true, the rest is just speculation b/c nothing would surprise me anymore :P
<swetland>
it's nice to get people up to speed and hands-on with something supported, documented, reasonably clean, and not yet burdened with a few decades of evolution (say vs x86/x64/arm/etc)