IRC logs for #openrisc Friday, 2016-08-12

--- Log opened Fri Aug 12 00:00:21 2016
kc5tjaNote to self: never EVER use iverilog packages in your Linux distro.  Always, ALWAYS, build from source.02:00
kc5tjaI now have casez support.02:00
kc5tjaSo that's a massive improvement over what I had before.02:01
kc5tjaAlas, it still does not appear to support defaults in an always @(*) block.  *sigh*02:03
-!- oleg-nenashev_ is now known as oleg-nenashev04:39
vidyaCan anyone tell me how does the UART connection map to pins on the OR1K processor on de0nano once we program the board?04:46
kc5tjaWell, after a couple of months of trying to hand-hack a RISC-V CPU, I've given up.  I've switched to using a MISC design, on top of which I intend to write a RISC-V emulator.10:50
kc5tjaIn 5 hours last night, I was able to get 8, 16, and 32-bit literal loads working, along with 8, 16, 32, and 64-bit memory stores.10:50
kc5tjaI couldn't successfully get ADDI X1, X0, 1234 working in a month's worth of (part-time, admittedly) effort.10:50
ZipCPUA moment of silence, please, for kc5tja 's RISC-V implementation.11:50
ZipCPUkc5tja: Did you study other RISC-V designs at all in order to know how you might do it?11:52
kc5tjapicorv32 in particular.13:50
kc5tjaTrying to get memory loads working (well, correction; they DO work; trying to refactor code to minimize LOC; THAT's not working at the moment).13:52
kc5tjabrb -- meeting.13:52
kc5tjaBack (for now).14:19
ZipCPUkc5tja: Did picorv32 implement the 64-bit instruction set you were hoping to build your Kestrel CPU around?15:06
kc5tjaNo, nor does it support version 1.9 of the machine-mode privileged specifications.15:06
ZipCPUkc5tja: Having worked with it for a while, do you believe the RISC ISA was well laid out?15:27
kc5tjaIn the general case, I don't believe so.  I think it just evolved out of Berkeley's ASIC designs, where proximity to transistors and power buses were an issue, but it doesn't make for a logical design.15:29
kc5tjaIt's logical in the conceptual sense.15:29
kc5tjaBut when the rubber meats the road, you run into weird edge-cases and inconveniences that are like, wtf would you DO this?15:29
kc5tjaAlso, I should point out that Berkeley created a higher-level hardware description language, Chisel, to implement their design with.15:30
kc5tjaSo, working with Verilog is something most of the students never had to deal with.15:30
ZipCPUkc5tja: Have you taken a look at all at the ZipCPU's ISA?,zipcpu15:31
kc5tjaIt's cool; I get that we need HDL innovation.  But, that isolated them from the realities of their design I think.15:31
kc5tjaNot yet.15:31
ZipCPUI like to think it's a *lot* simpler.15:31
ZipCPUI'd also suggest it as a nearly complete solution for simple 32-bit architecture, although I need to admit I keep getting hampered by the lack of byte-wise instructions.15:32
ZipCPUYou know ... another possibility available to you might be to build your own 64-bit ISA, with the same rough capability as the RISCV-64, but having laid out the ISA better instead ....15:34
kc5tjaThat's what my MISC architecture is.  :)15:39
kc5tja64-bit wide with support for 8, 16, 32, and 64 bit loads (signed and unsigned) and stores.15:39
kc5tjaAll ALU ops are 64-bits wide.15:40
kc5tjaJust got LxMU and LxMS instructions finished (where x in the set B, H, W, and D).15:40
kc5tjaSo, S64X7 is now technically Turing complete, given I have a supporting set of memory-addressible registers.  :)15:40
kc5tjaSo far about 420 lines of Verilog.15:41
kc5tjaI predict total file size will come in at about 700 lines of code after I'm done implementing the complete data and return stacks, ALU ops, and subroutine support.15:41
kc5tjaThen on top of the MISC core, I'm going to implement a software emulator for RISC-V instruction set.15:42
kc5tjaThat should get me going (at a snail's pace) enough to demo an FPGA-based computer at the RISC-V Workshop.15:43
kc5tjaAfter that, I'll look into hardware acceleration for RISC-V instruction decoding.15:43
kc5tjaNext step is to integrate the RISC-V ALU I wrote up and create instructions for driving it.15:46
kc5tjaNo point in wasting that work.  :)15:46
* kc5tja wishes that yosys toolchain would compile on his MacOS X machine. :/16:22
* kc5tja is curious to see how big the current S64X7 design is.16:23
kc5tjaInteger operations complete.19:08
ZipCPUFor your MISC CPU?21:17
ZipCPUHow many ALU operations?21:24
kc5tjaI didn't implement the RISC-V ALU just yet, but I have a "reference" model to test with.21:24
kc5tja14 total.21:24
ZipCPUAll capable of handling 8, 16, 32, and 64 bit ops?21:24
kc5tja64-bit only.21:24
kc5tjaOnce data is inside the CPU, all operations are full word width.21:25
ZipCPUDo these operations set flags at all?21:25
kc5tja(same with RISC-V)21:25
kc5tjaFlags are generated, but are not stored.21:25
ZipCPUOkay ...21:25
kc5tjaMost Forth CPUs just use subtraction and jump if zero/non-zero/high-bit set.21:25
kc5tjaRISC-V uses the flags to implement a compare-and-branch instruction (single instruction).21:26
ZipCPULet's see: 14 ops ... that would be add, sub, and, or, xor, lsl, lsr, asr,21:27
ZipCPU(Hit the return too soon ... )  Are you implementing MPY or DIVide instructions?21:27
ZipCPUThat is, are you implementing them as part of your ALU?21:28
kc5tjaadd, sub, lsl, slt (a<b), sltu (a<b unsigned), sge (a>=b), sgeu (unsigned), seq (a=b), sne, xor, lsr, asr, or, and21:28
kc5tjaNot yet.21:28
ZipCPUThat's a lot of "set on condition" commands.  ;)  and yet, there are some missing conditions, such as lte, gt, and their unsigned equivalents.21:29
kc5tjalte and gt can be synthesized from what's there by just swapping the operands.21:30
ZipCPUDo you plan on any way of testing for overflow?  The "V" condition if you will?21:30
kc5tjaMy current thoughts are to expose the flags via a processor-specific register.21:31
kc5tjaI don't have any plans for a BVS or BVC type instruction, no.21:32
ZipCPUSigh.  I put that condition into the ZipCPU, and I have yet to see them used even once.  On the other hand, I only have one unsigned condition, LTU, and I keep needing the other three unsigned conditions.  Go figure.21:35
kc5tjaI'm trying to debug why the CPU thinks the branch target address is 8 bytes past where I put it.21:38
kc5tjaKind of annoying.21:38
ZipCPUWhat's your instruction size?21:38
kc5tjaHow do you mean?21:40
kc5tjaUmm...about that.21:40
kc5tjaI pack multiple instructions into a 64-bit packet.21:40
kc5tjaSee ; this is where I got the idea for the encoding from.21:42
ZipCPUI was just asking because the current PC plus the instruction size often combine to create a branch target address.21:49
ZipCPUBut I like the reference!21:49
kc5tjaYep; that's how the S16X4 CPU worked (my Kestrel-2 CPU, also a MISC engine).21:57
kc5tjaBut for the S64X7, I want to keep as many things "RISC-V compatible" as possible, because I know I can reuse a lot of this logic later.21:57
kc5tjaExcept for interrupts, CSRs, and privilege levels, this CPU is =done=.22:03
kc5tjaTwo days.  Flat.22:03
kc5tjaHeh, now I need to make a compiler for it.22:03
kc5tjaWell, whoops, also forgot the data stack and return stacks.  Heh.22:04
kc5tjaI'll work on those tonight.22:04
kc5tjaBut for now, I'm heading home.  Yay for office commutes.22:04
ZipCPUDrive safe!22:06
kc5tjaI take the train.  :)  Driving in San Francisco is clinically insane except when absolutely necessary.22:08
kc5tja(Especially around Market street!)22:08
ZipCPUNo wonder why you stay up so late: pacific time!22:08
ZipCPUThere's other things that could be said about San Fransisco and clinically insane as well ...22:08
kc5tjaStill beats where I came from.  :)22:11
kc5tjaAnyway, packing up.  Back in about an hour or two (gonna get dinner too).22:12
ZipCPUI'll be gone by then.   L8r.22:12
kc5tjaHeh, back.23:35
--- Log closed Sat Aug 13 00:00:23 2016

Generated by 2.15.2 by Marius Gedminas - find it at!