| --- Log opened Wed Aug 19 00:00:06 2015 | ||
| -!- _franck_1 is now known as _franck_ | 05:45 | |
| olofk | andrzejr: Are you using wb_bfm to verify the DRAM interface? | 05:57 |
|---|---|---|
| andrzejr | olofk, I'm temporarily using a slightly modified rs232_syscon + uart_stim/decoder as a debugging i/f. It has exposed a fault in my ddr2 i/f but I cannot debug it because rs232_syscon enters a combinational loop. | 07:33 |
| andrzejr | I'll try wb_bfm later | 07:35 |
| andrzejr | olofk, looks like there is a mismatch between the sim and fpga testing. I will have to build a smaller testbench using your wb_bfm and simulate it with isim | 08:43 |
| andrzejr | for iverilog orpsoc simulations I have replaced the encrypted phy with a dummy so might have missed something. | 08:44 |
| olofk | andrzejr: Yeah, those memory interfaces are hopeless to use in simulations unless you have a real {questa,model}sim license :/ | 09:02 |
| olofk | Please let me know if you want any help setting up the wb_bfm testbench. I would recommend using the testbench from wb_ram or wb_sdram_ctrl as a template | 09:05 |
| olofk | ...or the wb_bfm testbench. https://github.com/olofk/wb_bfm/blob/master/bench/wb_bfm_tb.v That one is most up-to-date | 09:09 |
| poke53281 | Still unsure, if I should join the orconf this time. | 09:52 |
| olofk | oh.. I realize that you will run into one problem though. It's possible to prevent the transactor from sending certain cycle types (CTI), but there's currently no way to disable some of the BTEs. I remember you said that you only supported bte=10 or something like that | 09:53 |
| olofk | poke53281: I think you should. | 09:54 |
| poke53281 | The lowRISC workshop sounds interesting. | 09:56 |
| poke53281 | But I probably won't be able to give a talk. I am applying at the moment and there is so much other stuff. | 09:57 |
| poke53281 | I could not even finish one of my intended improvements for jor1k or openrisc. | 10:01 |
| olofk | Yeah, it's not easy to find time to do everything :) I hope that you'll show up though. Always fun to hang out and talk about tech stuff for a weekend | 10:01 |
| olofk | poke53281: Aha. In that case you're not welcome. EVER! | 10:02 |
| poke53281 | Instead we have now a new RISCV emulator :) | 10:02 |
| poke53281 | Ok, parallelization and sound was not included in my last talk :) | 10:03 |
| olofk | I guess the RISCV stuff has been given a little higher priority, especially with the GSoC stuff and all | 10:04 |
| poke53281 | Yes, my student needed a lot of help. I forgot how much knowledge you need to do this. | 10:05 |
| Shentino | will openrisc support hardware assisted virtualization? :) | 10:16 |
| olofk | Shentino: Hmm.. I'm no expert on these things, but I don't think there are anything planned in that area | 10:41 |
| poke53281 | Title "About the pain to emulate a sound device in an environment, which only has a ms timer and no interrupts at all" | 11:37 |
| poke53281 | olofk: I can easily talk half an hour about this ;) | 11:37 |
| poke53281 | btw, with the same optimizations like openrisc, riscv is half the speed. | 11:43 |
| olofk | is half the speed due to lack of 64-bit javascript? | 12:59 |
| olofk | Perhaps you should rewrite jor1k in Flash instead. I hear that's the hot new thing :) | 13:00 |
| poke53281 | *shootatolofk* NEVER IN MY LIFE, I WANT TO HEAR ANYMORE SOMETHING ABOUT FLASH. | 13:02 |
| poke53281 | Nope, I emulate right at the moment only the 32-Bit version. 64-Bit is on my list. | 13:03 |
| olofk | :) | 13:04 |
| poke53281 | It is related to the more complex encoding. For or1k I need only one switch statement in average to find the correct instruction. | 13:04 |
| poke53281 | For riscv I need two. | 13:04 |
| poke53281 | the immediate values of the instruction are separated to several bitfields. | 13:05 |
| poke53281 | Up to four within one instruction. | 13:05 |
| olofk | yikes | 13:05 |
| poke53281 | imm = (((ins >> 21) & 0x3FF) | (((ins >> 20) & 0x1) << 10) | (((ins >> 12) & 0xFF) << 11) | ((ins >> 31) << 19) ) << 1; | 13:06 |
| olofk | I guess there's a reason for that | 13:06 |
| poke53281 | Yes, the used register indices are the same in almost every instruction. | 13:07 |
| poke53281 | I mean the position in the instruction | 13:07 |
| poke53281 | r[((ins >> 5) & 0x7C) >> 2] | 13:08 |
| poke53281 | You can find this line in basically every instruction. | 13:08 |
| olofk | So from a hardware point of view, it's probably simpler to decode then | 13:08 |
| poke53281 | Yes, that's the point | 13:08 |
| poke53281 | One instruction, which would be nice for or1k would be auipc. Add a imm to the pc and write it into a register. | 13:09 |
| poke53281 | For pic code. | 13:09 |
| poke53281 | I don't like the jump solution in openrisc | 13:09 |
| olofk | Not sure what you mean. Isn't that just l.addi <target>, <pc>, <imm> ? | 13:10 |
| olofk | Or would it move the pc as well? | 13:10 |
| poke53281 | and how do you get the pc? | 13:10 |
| olofk | oh... the pc isn't a gpr | 13:11 |
| olofk | Right | 13:11 |
| olofk | That wouldn't be a problem if we could store the pc in the cloud | 13:11 |
| poke53281 | cloud? | 13:11 |
| olofk | Then you could just use a REST API to get the PC value | 13:11 |
| poke53281 | REST API? | 13:12 |
| olofk | Sorry :) | 13:12 |
| poke53281 | There is slow, but constant work on the toolchain. Unfortunately the 32-Bit part is not well tested. I am the first one, who is able to run 32-Bit Linux. Shared libraries doesn't seem to work. | 13:18 |
| poke53281 | And what's even more astonishing is, that they don't (want to) support MMIO. | 13:19 |
| poke53281 | So, all my devices don't work. | 13:19 |
| olofk | I've seen the MMIO discussions. Seems to me like they suffer a bit from NIH and think that they can just create all the stuff they need themselves | 13:39 |
| poke53281 | NIH | 13:44 |
| poke53281 | NIH? | 13:45 |
| poke53281 | Well, they can support their own interface and MMIO until they think, they have support for all standard devices. | 13:45 |
| poke53281 | They had already support for MMIO, but it was removed. | 13:46 |
| poke53281 | with the result that also QEMU is no longer working. | 13:47 |
| poke53281 | the grass is not always greener on the other side :) | 13:48 |
| andrzejr | poke53281, my impression of RISC-V/lowrisc is that it is a strongly research driven project. Been there before, basically you have to have novel stuff even if better solution already exists. | 19:12 |
| andrzejr | Many of other design decisions are also questionable. For example, denser instruction set is not necessarily better if it adds latency to fetch/decode. Bandwidth and cache are relatively cheap and scale much better than latency and power efficiency. | 19:15 |
| andrzejr | IMHO MIPS-like architecture is still the best choice for power efficient 32b CPU core. | 19:16 |
| poke53281 | Well, it is still an university. Of course it is research driven. | 20:03 |
| robtaylor | andrzejr: i'd suggest having a read through http://riscv.org/workshop-jun2015/riscv-intro-workshop-june2015.pdf | 20:03 |
| poke53281 | For me riscv looks like a solid architecture with a well-thought.out instruction set. | 20:04 |
| * robtaylor notes that commercial drivers are happening now | 20:04 | |
| robtaylor | (including wallento's new gig ;)) | 20:05 |
| poke53281 | I think I saw the talk last year. | 20:05 |
| poke53281 | or at least a previous version | 20:05 |
| andrzejr | robtaylor, thank you, that is interesting | 20:05 |
| robtaylor | andrzejr: you're welcome :) | 20:06 |
| poke53281 | the instruction set is less dense than arm for example. And much much much cleaner. | 20:06 |
| poke53281 | No history related stuff. | 20:06 |
| * robtaylor is mainly interested because of the rate of work being done around it | 20:07 | |
| robtaylor | two out of order implementations already! | 20:07 |
| andrzejr | what ultimately matters for CPU is the toolchain and deployment (availability). If RISC-V can reach critical mass (so far it is doing very well) people will use it. | 20:08 |
| poke53281 | well, that's natural :) | 20:08 |
| poke53281 | the toolchain is developed. Every week there are a few patches. | 20:09 |
| olofk | I also agree that it seems to be a little too much on the academic side sometimes. The CPU itself looks fine, but I'm not convinced of all the system-level stuff (inventing new buses and not supporting MMIO are two examples) | 20:09 |
| robtaylor | andrzejr: yep | 20:09 |
| robtaylor | olofk: yeah, i'm still unsure how the privilage seperation stuff is supposed to work | 20:10 |
| poke53281 | I think they are still working on the subtleties. | 20:12 |
| andrzejr | OTOH academic development model pays for tools and tapeouts | 20:12 |
| poke53281 | The MMIO part is not implemented, because it is rather difficult to trap it with virtualization. At least this was one reason. | 20:13 |
| robtaylor | well, yeah, they were talking about having abstracted devices a-la virtio | 20:13 |
| robtaylor | that's the bit I don't think I fully understand... | 20:14 |
| poke53281 | Yeah, me too. | 20:14 |
| poke53281 | Well, Linux is supposed to run not in the highest privilege level in the CPU. | 20:15 |
| olofk | I think they should have an activeX component as the highest privilege | 20:15 |
| poke53281 | And only the highest instance (proxy-kernel) is supposed to access the hardware. | 20:15 |
| Shentino | btw, does openrisc use hardware page tables or just a TLB? | 20:16 |
| * Shentino was thinking of porting seL4 | 20:16 | |
| olofk | Shentino: I think wallento might be our seL4 expert here. | 20:17 |
| poke53281 | So this type of design is Ok. | 20:17 |
| poke53281 | Nowadays a lost of virtualized machines access the hardware via the Linux virtio drivers. | 20:17 |
| poke53281 | The problem ist just the reality. You have to develop all drivers from scratch to access some interface to proxy-kernel. | 20:19 |
| Shentino | I like how clean seL4 is, but kinda wish it had a higher level memory abstraction instead of just foisting the management of page tables onto userspace | 20:19 |
| Shentino | and there are some CPUs out there that don't even have page tables | 20:19 |
| poke53281 | Shentino: the tlb must be filled manually via an exception routine. | 20:20 |
| Shentino | which makes me wonder how you'd implement seL4 | 20:23 |
| Shentino | since they assume page tables are hardware implemented | 20:26 |
| --- Log closed Thu Aug 20 00:00:07 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!