IRC logs for #openrisc Thursday, 2017-02-23

--- Log opened Thu Feb 23 00:00:13 2017
shorneI updated some docs on qemu running on linux here:06:56
shornewallento: thanks for following up on the gcc stuff09:53
olofkpsychotrope: You can try too. It's a javascript implementation of OpenRISC. Works well enough to run Linux and XWindows10:14
olofkRegarding non-volatile storage, there are a few options, but it's not that straight-forward10:14
olofkFor the de0 nano specifically, you could perhaps use the rest of the on-board Flash for storage. Don't know how difficult it is to map that in Linux though, and you need to make sure you don't overwrite the linux or FPGA images stored there10:16
olofkSD card is perhaps a better solution. When I was working for ORSoC we released a board that was quite similar to de0 nano, but with ethernet and an microSD slot10:16
olofkde0 nano doesn't have any of those built-in, but I think it shouldn't be too hard to solder on some pins on an SD card and put that on the pin headers10:17
olofkBeen thinking of doing that for quite a while10:17
olofkI know stekern has a lot of custom peripherals for his board10:18
olofkAarrgh.. I forgot that stupid old ISE bug where $clog2 works form parameters but not localparam10:41
olofk...except if they are compiled in SystemVerilog mode, I think10:42
kc5tjaIf anyone's here, I just have an idle curiosity: how many 4LUTs or 6LUTs does a typical Or1K CPU capable of running Linux take up?14:01
ZipCPUHi kc5tja.14:06
ZipCPUI had that information lying around somewhere, but can't seem to find it right now.  I got it from olofk ...14:06
kc5tjaI was just curious, nothing to worry too much about.14:20
kc5tjaMore along the lines of, "If I improve my RISC-V CPU to the point where it should run Linux, and it's 3x bigger than OR1K+MMU, then I'm probably doing something wrong."14:20
ZipCPUWell ... ok, but ... wouldn't you want to compare against other risc-v CPU's?  Or not, because you are using the 64-bit instruction set?14:25
kc5tja32-bit vs 64-bit will have an influence, to be sure, but it shouldn't impact things like decoder size, MMU state machine logic, and the like.14:32
kc5tjaAt any rate, I'm a long ways from definitely needing to know.14:34
ZipCPUHmm ... I might beg to differ, but ... okay.  I guess what I'm wondering is ...14:34
ZipCPUwouldn't a measure of the PicoRV or the Rocket-RV be a more appropriate comparison?14:34
ZipCPUOr even ... heheh .... the boomCPU?14:34
kc5tjaThe problem with Boom and Rocket is that they're ASIC-optimized, not FPGA optimized.14:35
kc5tjaPicoRV is already known smaller than my CPU, since it's only 32-bit.14:35
kc5tjaAnd it doesn't conform with privilege ISA specs.14:36
ZipCPUSure, but it's at least a measure.  Besides, the or1k was at one time part of an ASIC project ... so I'm not sure how much is ASIC vs FPGA optimized.14:36
psychotropeolofk: is that board still availible?14:53
psychotropeI'd really like both of those hardware ports on my system14:53
olofkpsychotrope: stekern is usually around here, but I can't see him now. I'll do some searching if he doesn't return soon18:24
olofkpsychotrope: Oh, and the board I was talking about was called ordb2a. It was a pretty nice board for its time, but (IMO) we abandoned it way too early. Don't think you can get it anymore. Still have mine though18:25
olofkThis is the one
olofkkc5tja: Hmm.. don't have any numbers unfortunately. Also, I don't think anyone has ever implemented a 64-bit or1k18:26
olofkI think it's a big gap in the RISC-V world where they are either small 32-bit MCU class (like RI5CY and picorv32) or full-blown ones like Rocket and Boom. Don't know any good middle ground18:27
olofkMaybe you can look through the standard FuseSoC core library. I've packaged six or seven riscv cores there18:28
olofkOnly five cores actually: opa, picorv32, ri5cy, ridecore, vscale18:29
kc5tjaAll of them MCU-class cores.18:51
kc5tjaOh well.  I'll just have to trail-blaze.  :)18:51
psychotropeolofk: thanks19:11
--- Log closed Fri Feb 24 00:00:14 2017

Generated by 2.15.2 by Marius Gedminas - find it at!