IRC logs for #openrisc Wednesday, 2015-08-19

--- Log opened Wed Aug 19 00:00:06 2015
-!- _franck_1 is now known as _franck_05:45
olofkandrzejr: Are you using wb_bfm to verify the DRAM interface?05:57
andrzejrolofk, 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
andrzejrI'll try wb_bfm later07:35
andrzejrolofk, 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 isim08:43
andrzejrfor iverilog orpsoc simulations I have replaced the encrypted phy with a dummy so might have missed something.08:44
olofkandrzejr: Yeah, those memory interfaces are hopeless to use in simulations unless you have a real {questa,model}sim license :/09:02
olofkPlease 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 template09:05
olofk...or the wb_bfm testbench. That one is most up-to-date09:09
poke53281Still unsure, if I should join the orconf this time.09:52
olofkoh.. 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 that09:53
olofkpoke53281: I think you should.09:54
poke53281The lowRISC workshop sounds interesting.09:56
poke53281But 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
poke53281I could not even finish one of my intended improvements for jor1k or openrisc.10:01
olofkYeah, 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 weekend10:01
olofkpoke53281: Aha. In that case you're not welcome. EVER!10:02
poke53281Instead we have now a new RISCV emulator :)10:02
poke53281Ok, parallelization and sound was not included in my last talk :)10:03
olofkI guess the RISCV stuff has been given a little higher priority, especially with the GSoC stuff and all10:04
poke53281Yes, my student needed a lot of help. I forgot how much knowledge you need to do this.10:05
Shentinowill openrisc support hardware assisted virtualization? :)10:16
olofkShentino: Hmm.. I'm no expert on these things, but I don't think there are anything planned in that area10:41
poke53281Title "About the pain to emulate a sound device in an environment, which only has a ms timer and no interrupts at all"11:37
poke53281olofk: I can easily talk half an hour about this ;)11:37
poke53281btw, with the same optimizations like openrisc, riscv is half the  speed.11:43
olofkis half the speed due to lack of 64-bit javascript?12:59
olofkPerhaps you should rewrite jor1k in Flash instead. I hear that's the hot new thing :)13:00
poke53281Nope, I emulate right at the moment only the 32-Bit version. 64-Bit is on my list.13:03
poke53281It is related to the more complex encoding. For or1k I need only one switch statement in average to find the correct instruction.13:04
poke53281For riscv I need two.13:04
poke53281the immediate values of the instruction are separated to several bitfields.13:05
poke53281Up to four within one instruction.13:05
poke53281imm =  (((ins >> 21) & 0x3FF) | (((ins >> 20) & 0x1) << 10) | (((ins >> 12) & 0xFF) << 11) | ((ins >> 31) << 19) ) << 1;13:06
olofkI guess there's a reason for that13:06
poke53281Yes, the used register indices are the same in almost every instruction.13:07
poke53281I mean the position in the instruction13:07
poke53281r[((ins >> 5) & 0x7C) >> 2]13:08
poke53281You can find this line in basically every instruction.13:08
olofkSo from a hardware point of view, it's probably simpler to decode then13:08
poke53281Yes, that's the point13:08
poke53281One instruction, which would be nice for or1k would be auipc. Add a imm to the pc and write it into a register.13:09
poke53281For pic code.13:09
poke53281I don't like the jump solution in openrisc13:09
olofkNot sure what you mean. Isn't that just l.addi <target>, <pc>, <imm> ?13:10
olofkOr would it move the pc as well?13:10
poke53281and how do you get the pc?13:10
olofkoh... the pc isn't a gpr13:11
olofkThat wouldn't be a problem if we could store the pc in the cloud13:11
olofkThen you could just use a REST API to get the PC value13:11
poke53281REST API?13:12
olofkSorry :)13:12
poke53281There 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
poke53281And what's even more astonishing is, that they don't (want to) support MMIO.13:19
poke53281So, all my devices don't work.13:19
olofkI'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 themselves13:39
poke53281Well, they can support their own interface and MMIO until they think, they have support for all standard devices.13:45
poke53281They had already support for MMIO, but it was removed.13:46
poke53281with the result that also QEMU is no longer working.13:47
poke53281the grass is not always greener on the other side :)13:48
andrzejrpoke53281, 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
andrzejrMany 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
andrzejrIMHO MIPS-like architecture is still the best choice for power efficient 32b CPU core.19:16
poke53281Well, it is still an university. Of course it is research driven.20:03
robtaylorandrzejr: i'd suggest having a read through
poke53281For me riscv looks like a solid architecture with a well-thought.out instruction set.20:04
* robtaylor notes that commercial drivers are happening now20:04
robtaylor(including wallento's new gig ;))20:05
poke53281I think I saw the talk last year.20:05
poke53281or at least a previous version20:05
andrzejrrobtaylor, thank you, that is interesting20:05
robtaylorandrzejr: you're welcome :)20:06
poke53281the instruction set is less dense than arm for example. And much much much cleaner.20:06
poke53281No history related stuff.20:06
* robtaylor is mainly interested because of the rate of work being done around it20:07
robtaylortwo out of order implementations already!20:07
andrzejrwhat 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
poke53281well, that's natural :)20:08
poke53281the toolchain is developed. Every week there are a few patches.20:09
olofkI 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
robtaylorandrzejr: yep20:09
robtaylorolofk: yeah, i'm still unsure how the privilage seperation stuff is supposed to work20:10
poke53281I think they are still working on the subtleties.20:12
andrzejrOTOH academic development model pays for tools and tapeouts20:12
poke53281The MMIO part is not implemented, because it is rather difficult to trap it with virtualization. At least this was one reason.20:13
robtaylorwell, yeah, they were talking about having abstracted devices a-la virtio20:13
robtaylorthat's the bit I don't think I fully understand...20:14
poke53281Yeah, me too.20:14
poke53281Well, Linux is supposed to run not in the highest privilege level in the CPU.20:15
olofkI think they should have an activeX component as the highest privilege20:15
poke53281And only the highest instance (proxy-kernel) is supposed to access the hardware.20:15
Shentinobtw, does openrisc use hardware page tables or just a TLB?20:16
* Shentino was thinking of porting seL420:16
olofkShentino: I think wallento might be our seL4 expert here.20:17
poke53281So this type of design is Ok.20:17
poke53281Nowadays a lost of virtualized machines access the hardware via the Linux virtio drivers.20:17
poke53281The problem ist just the reality. You have to develop all drivers from scratch to access some interface to proxy-kernel.20:19
ShentinoI 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 userspace20:19
Shentinoand there are some CPUs out there that don't even have page tables20:19
poke53281Shentino: the tlb must be filled manually via an exception routine.20:20
Shentinowhich makes me wonder how you'd implement seL420:23
Shentinosince they assume page tables are hardware implemented20:26
--- Log closed Thu Aug 20 00:00:07 2015

Generated by 2.15.2 by Marius Gedminas - find it at!