| --- Log opened Thu May 12 00:00:02 2016 | ||
| SMDwrk | Hi, everyone. I glimpsed at mor1kx verilog code and I have to ask(disclaimer: I'm not good rtl coder at all) has it been done that way on purpose? | 07:27 |
|---|---|---|
| stekern | I guess it depends what you refer to with "that way" ;) | 07:29 |
| SMDwrk | I'm confused with alu and decoder parts: they seem a bit messy and are hard to read | 07:32 |
| SMDwrk | Or maybe I don't see the whole picture | 07:34 |
| SMDwrk | I.e. if you have time, please, take a look at my approach with mips cpu: https://bitbucket.org/spacemonkeydelivers/mips/src/67438d4629dfebd1c4fe402ef50d8008b7f0ffb5/src/new_control.v?at=pipeline&fileviewer=file-view-default - that's sort of decode thing in mor1kx | 07:35 |
| stekern | well, apart from extensive use of tick-define macros, it's not terribly different from: https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_decode.v | 07:37 |
| stekern | (+ or1k has a bit messy instruction encoding...) | 07:39 |
| SMDwrk | Yep, I'm confused that there is a output for every existing opcode(decode_op_div_o, decode_op_jr_o, etc) | 07:41 |
| stekern | that is on purpose, otherwise you will have to further "decode" down the pipeline | 07:42 |
| mithro | Kind of a weird question. If I have say a 20bit to 20bit lookup table, is there an way to work out an efficient minimal implementation of the table? | 07:44 |
| SMDwrk | stekern: Ok then, and another question: alu, which executes most of things in parallel and then correct result is chosen upon operation wires, is better than giant switchcase based on "alu opcode"? | 07:50 |
| SMDwrk | Giant mux is not a good idea though | 07:50 |
| ZipCPU|Laptop | SMDwrk: What's wrong with a giant mux? In RTL, you are stuck with doing every operation anyway, what's wrong with just selecting the correct answer from among the possibilities? | 07:55 |
| SMDwrk | ZipCPU|Laptop: I mean giant mux is smth like https://bitbucket.org/spacemonkeydelivers/mips/src/67438d4629dfebd1c4fe402ef50d8008b7f0ffb5/src/alu.v?at=pipeline&fileviewer=file-view-default so selecting correct answer could be a good idea | 07:57 |
| ZipCPU|Laptop | Are you suggesting that approach, or suggesting against it? | 07:59 |
| SMDwrk | ZipCPU|Laptop: actually I'm not suggesting but asking what's better and why | 08:00 |
| ZipCPU|Laptop | Not sure I have a good answer for you. They both look roughly equivalent to me, save that I don't see anything switching on the clock in the OpenRISC code. That's got to be elsewhere. | 08:04 |
| SMDwrk | In my case there should be let's say 32 way mux while in orisc one it could be 8 way. There is mul/div working on the clk and fpu as far as I can see. Logic and shifts are done in continuous assignments. | 08:10 |
| ZipCPU|Laptop | Let's see if I've captured the question well: In approach 1) all of the instructions have their own flags indicating which instruction will be done, | 08:13 |
| ZipCPU|Laptop | in approach 2) all instructions are done and selected between via a big case/mux statement based upon the opcode. | 08:14 |
| ZipCPU|Laptop | Did I capture the difference? | 08:14 |
| SMDwrk | yep | 08:17 |
| ZipCPU|Laptop | In the case of #1, you set your self up for concurrent execution--multiple instructions can be executed at once, given that the operands are ready. | 08:29 |
| ZipCPU|Laptop | (I don't know if or1k does this ... anyone?) | 08:30 |
| ZipCPU|Laptop | If you don't do concurrent execution, though, then you may need to maintain (via flip-flops/registers) the decoded state until you finally use it. | 08:31 |
| stekern | SMDwrk: part of it goes down to coding style too, you could construct your alu opcode to be onehot to achieve the same result | 08:46 |
| stekern | I largely used the same style when I did this: https://github.com/skristiansson/eco32f | 08:47 |
| stekern | which is a lot simpler than mor1kx | 08:48 |
| SMDwrk | Ok, thanks! | 09:00 |
| ZipCPU|Laptop | stekern: Were you the one who had worked on the pipelined ECO32? I heard it was only partially successful. Can you tell me if it ever fully worked? | 09:42 |
| stekern | the link above is to a pipelined version of eco32 | 09:43 |
| stekern | it worked enough to boot linux at least | 09:43 |
| shorne | olofk: wallento: looking at the g++ virtual construction, I traced it down to __do_global_ctors_aux, I believe the virtuals should be contructed in here. But the constructor list in my binary is empty. Looking into more details. | 09:45 |
| ZipCPU|Laptop | stekern: Can you tell me whether all of the instruction set was fully implemented? | 09:47 |
| stekern | as far as I remember, yes | 09:48 |
| stekern | at least as it was defined at that point in time | 09:48 |
| stekern | I don't know if there has been any changes/additions since then | 09:48 |
| ZipCPU|Laptop | Okay. I had just heard something different from Hellwig, that his last student had not been able to complete a pipelined version and so the project was ongoing and still needing to be completed. | 09:48 |
| stekern | ah, that's probably a seperate story, I was never a student of Hellwig | 09:50 |
| ZipCPU|Laptop | No wonder. That explains things then. | 09:52 |
| wallento | shorne: is that newlib specific | 10:01 |
| wallento | because at this time we used uclibc because of c++ support | 10:01 |
| wallento | We needed to compile a bulky kernel (FIASCO.OC microkernel) | 10:01 |
| shorne | wallento: I was thinking it might be | 10:22 |
| wallento | okay, I am not sure about c++ in newlib at all to be honest | 10:23 |
| wallento | I will try the example with the musl toolchain | 10:23 |
| wallento | but anyways, you are right, it is probably not related | 10:23 |
| shorne | I need to try the whole thing with musl too | 10:24 |
| shorne | need to build musl | 10:24 |
| olofk | shorne: Sorry for not being more helpful. Been a lot on my plate lately, but I'll help you out when I get the time | 10:42 |
| olofk | But not with the c++ stuff. That stuff is just too weird :) | 10:42 |
| shorne | No worries, hopefully after this I can get back to the dma controller stuff | 10:43 |
| olofk | Yeah. That would be great too | 10:46 |
| olofk | But this reg testing has been great as it revealed several bugs in other components too. We should perhaps file some bugs before we forget about them | 10:47 |
| olofk | But of course, we still have everything recorded in the grand OpenRISC documentation database at http://www.juliusbaxter.net/openrisc-irc/ :) | 10:47 |
| olofk | Note to future olofk: We need to implement the rest of the reentrant functions in newlib, find out why sys/mman.h is missing, fix the c++ virtual stuff, understand why gdb-python isn't always enabled | 10:49 |
| olofk | shorne: Building musl was pretty straight-forward last time I tried. | 10:51 |
| olofk | Hmm.. wallento. You removed the build instructions from opencores wiki, and I can't find them now | 10:51 |
| wallento | which one? | 10:52 |
| wallento | (the idea of the wiki is that you can see the old version in the history by the way ;) | 10:53 |
| wallento | oh, the musl toolchain | 10:54 |
| wallento | it has moved, but was not completed apparently: https://github.com/openrisc/musl-cross/wiki | 10:54 |
| wallento | I will complete now | 10:54 |
| wallento | the link is here: http://openrisc.io/software | 10:54 |
| olofk | cool | 10:56 |
| olofk | The old instructions are here in the meantime http://opencores.org/wiki1/index.php?title=OpenRISC_GNU_tool_chain&oldid=1399#Linux_.28musl.29_toolchain_.28or1k-linux-musl.29 | 10:56 |
| wallento | sneak peak: clone the repo and run build.sh | 10:56 |
| wallento | :) | 10:56 |
| wallento | olofk: https://github.com/openrisc/musl-cross/wiki | 10:59 |
| shorne | olofk: the build is in progress, it seems straight forward enough no failures yet | 11:01 |
| shorne | wallento: clone and build is what I did | 11:02 |
| olofk | wallento: Great. One less dependency on opencores | 12:58 |
| wallento | olofk: yeah, that was my ambitious plan with deleting stuff | 13:03 |
| wallento | only legacy stuff should remain :) | 13:04 |
| olofk | wallento: Yeah, I've been meaning to do the same for quite some time. Just got a bit suprised when I couldn't find the instructions at the new site | 13:07 |
| SMDwrk | what's wrong with opencores.org btw? | 13:20 |
| olofk | SMDwrk: Lack of maintenance makes it hard to rely upon. We have already lost the bug tracker and the mailing list | 13:46 |
| SMDwrk | oh, then, as I've already suggested, I can share my 16 amd cores workstation: you could loose something there tooo | 14:00 |
| olofk | SMDwrk: Yes. We're grateful for the offer. Unfortunately we don't have any ready workloads to run there right now :/ | 14:26 |
| shorne | need some work to get gdb working woth or1k-linux-musl (the traps are not implemented) https://github.com/stffrdhrn/binutils-gdb/blob/or1k-sim/sim/or1k/traps-linux.c | 17:32 |
| shorne | I think most can come from the newlib implementations. I need to see what though | 17:35 |
| shorne | Ill, get back to that later. I think this c++ thing should work, olofk's test ran with newlib and it worked. SOmething is wrong on myside/myversion Ill try to bisect it | 17:45 |
| shorne | olofk: Can you check one thing on your testsuite, there should be a file ./gdb/testsuite/outputs/gdb.cp/virtfunc/virtfunc | 18:21 |
| shorne | Can you run or1k-elf-objdump -s ./gdb/testsuite/outputs/gdb.cp/virtfunc/virtfunc | grep -C5 '\.ctors' | 18:21 |
| shorne | for me I get: | 18:21 |
| shorne | Contents of section .ctors: 32cbc ffffffff 00000000 ........ | 18:21 |
| shorne | meaning (no global initializers) | 18:22 |
| shorne | better yet run: or1k-elf-objdump -s -j .ctors ./gdb/testsuite/outputs/gdb.cp/virtfunc/virtfunc | 18:36 |
| --- Log closed Fri May 13 00:00:04 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!