| --- Log opened Fri Aug 12 00:00:21 2016 | ||
| kc5tja | Note to self: never EVER use iverilog packages in your Linux distro. Always, ALWAYS, build from source. | 02:00 |
|---|---|---|
| kc5tja | I now have casez support. | 02:00 |
| kc5tja | So that's a massive improvement over what I had before. | 02:01 |
| kc5tja | Alas, it still does not appear to support defaults in an always @(*) block. *sigh* | 02:03 |
| -!- oleg-nenashev_ is now known as oleg-nenashev | 04:39 | |
| vidya | Can anyone tell me how does the UART connection map to pins on the OR1K processor on de0nano once we program the board? | 04:46 |
| kc5tja | Well, 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 |
| kc5tja | In 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 |
| kc5tja | I couldn't successfully get ADDI X1, X0, 1234 working in a month's worth of (part-time, admittedly) effort. | 10:50 |
| ZipCPU | A moment of silence, please, for kc5tja 's RISC-V implementation. | 11:50 |
| ZipCPU | kc5tja: Did you study other RISC-V designs at all in order to know how you might do it? | 11:52 |
| kc5tja | Yes. | 13:50 |
| kc5tja | picorv32 in particular. | 13:50 |
| kc5tja | Trying 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 |
| kc5tja | brb -- meeting. | 13:52 |
| kc5tja | Back (for now). | 14:19 |
| ZipCPU | kc5tja: Did picorv32 implement the 64-bit instruction set you were hoping to build your Kestrel CPU around? | 15:06 |
| kc5tja | No, nor does it support version 1.9 of the machine-mode privileged specifications. | 15:06 |
| ZipCPU | kc5tja: Having worked with it for a while, do you believe the RISC ISA was well laid out? | 15:27 |
| kc5tja | In 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 |
| kc5tja | s/logical/clean/ | 15:29 |
| kc5tja | It's logical in the conceptual sense. | 15:29 |
| kc5tja | But when the rubber meats the road, you run into weird edge-cases and inconveniences that are like, wtf would you DO this? | 15:29 |
| kc5tja | Also, I should point out that Berkeley created a higher-level hardware description language, Chisel, to implement their design with. | 15:30 |
| ZipCPU | <Groan> | 15:30 |
| kc5tja | So, working with Verilog is something most of the students never had to deal with. | 15:30 |
| ZipCPU | kc5tja: Have you taken a look at all at the ZipCPU's ISA? http://opencores.org/project,zipcpu | 15:31 |
| kc5tja | It's cool; I get that we need HDL innovation. But, that isolated them from the realities of their design I think. | 15:31 |
| kc5tja | Not yet. | 15:31 |
| ZipCPU | I like to think it's a *lot* simpler. | 15:31 |
| ZipCPU | I'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 |
| ZipCPU | You 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 |
| kc5tja | That's what my MISC architecture is. :) | 15:39 |
| kc5tja | 64-bit wide with support for 8, 16, 32, and 64 bit loads (signed and unsigned) and stores. | 15:39 |
| kc5tja | All ALU ops are 64-bits wide. | 15:40 |
| kc5tja | Just got LxMU and LxMS instructions finished (where x in the set B, H, W, and D). | 15:40 |
| kc5tja | So, S64X7 is now technically Turing complete, given I have a supporting set of memory-addressible registers. :) | 15:40 |
| kc5tja | So far about 420 lines of Verilog. | 15:41 |
| kc5tja | I 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 |
| kc5tja | Then on top of the MISC core, I'm going to implement a software emulator for RISC-V instruction set. | 15:42 |
| kc5tja | That should get me going (at a snail's pace) enough to demo an FPGA-based computer at the RISC-V Workshop. | 15:43 |
| kc5tja | After that, I'll look into hardware acceleration for RISC-V instruction decoding. | 15:43 |
| kc5tja | Next step is to integrate the RISC-V ALU I wrote up and create instructions for driving it. | 15:46 |
| kc5tja | No 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 | |
| kc5tja | Integer operations complete. | 19:08 |
| ZipCPU | For your MISC CPU? | 21:17 |
| kc5tja | Yep. | 21:24 |
| ZipCPU | How many ALU operations? | 21:24 |
| kc5tja | I didn't implement the RISC-V ALU just yet, but I have a "reference" model to test with. | 21:24 |
| kc5tja | 14 total. | 21:24 |
| ZipCPU | All capable of handling 8, 16, 32, and 64 bit ops? | 21:24 |
| kc5tja | 64-bit only. | 21:24 |
| kc5tja | Once data is inside the CPU, all operations are full word width. | 21:25 |
| ZipCPU | Do these operations set flags at all? | 21:25 |
| kc5tja | (same with RISC-V) | 21:25 |
| kc5tja | Flags are generated, but are not stored. | 21:25 |
| ZipCPU | Okay ... | 21:25 |
| kc5tja | Most Forth CPUs just use subtraction and jump if zero/non-zero/high-bit set. | 21:25 |
| kc5tja | RISC-V uses the flags to implement a compare-and-branch instruction (single instruction). | 21:26 |
| ZipCPU | Let'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 |
| ZipCPU | That is, are you implementing them as part of your ALU? | 21:28 |
| kc5tja | add, sub, lsl, slt (a<b), sltu (a<b unsigned), sge (a>=b), sgeu (unsigned), seq (a=b), sne, xor, lsr, asr, or, and | 21:28 |
| kc5tja | Not yet. | 21:28 |
| ZipCPU | That'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 |
| kc5tja | lte and gt can be synthesized from what's there by just swapping the operands. | 21:30 |
| ZipCPU | Do you plan on any way of testing for overflow? The "V" condition if you will? | 21:30 |
| kc5tja | My current thoughts are to expose the flags via a processor-specific register. | 21:31 |
| kc5tja | I don't have any plans for a BVS or BVC type instruction, no. | 21:32 |
| ZipCPU | Sigh. 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 |
| kc5tja | I'm trying to debug why the CPU thinks the branch target address is 8 bytes past where I put it. | 21:38 |
| kc5tja | Kind of annoying. | 21:38 |
| kc5tja | OH.... | 21:38 |
| ZipCPU | What's your instruction size? | 21:38 |
| kc5tja | How do you mean? | 21:40 |
| kc5tja | Oh. | 21:40 |
| kc5tja | Umm...about that. | 21:40 |
| kc5tja | I pack multiple instructions into a 64-bit packet. | 21:40 |
| kc5tja | See http://scale.eecs.berkeley.edu/papers/hat-cases2001.pdf ; this is where I got the idea for the encoding from. | 21:42 |
| ZipCPU | I was just asking because the current PC plus the instruction size often combine to create a branch target address. | 21:49 |
| ZipCPU | But I like the reference! | 21:49 |
| kc5tja | Yep; that's how the S16X4 CPU worked (my Kestrel-2 CPU, also a MISC engine). | 21:57 |
| kc5tja | But 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 |
| kc5tja | Except for interrupts, CSRs, and privilege levels, this CPU is =done=. | 22:03 |
| kc5tja | Two days. Flat. | 22:03 |
| kc5tja | Heh, now I need to make a compiler for it. | 22:03 |
| kc5tja | Well, whoops, also forgot the data stack and return stacks. Heh. | 22:04 |
| kc5tja | I'll work on those tonight. | 22:04 |
| kc5tja | But for now, I'm heading home. Yay for office commutes. | 22:04 |
| ZipCPU | Drive safe! | 22:06 |
| kc5tja | I take the train. :) Driving in San Francisco is clinically insane except when absolutely necessary. | 22:08 |
| kc5tja | (Especially around Market street!) | 22:08 |
| ZipCPU | No wonder why you stay up so late: pacific time! | 22:08 |
| ZipCPU | There's other things that could be said about San Fransisco and clinically insane as well ... | 22:08 |
| kc5tja | Still beats where I came from. :) | 22:11 |
| kc5tja | Anyway, packing up. Back in about an hour or two (gonna get dinner too). | 22:12 |
| ZipCPU | I'll be gone by then. L8r. | 22:12 |
| kc5tja | Heh, back. | 23:35 |
| kc5tja | Adieu. | 23:35 |
| --- Log closed Sat Aug 13 00:00:23 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!