--- Log opened Sat Jun 28 00:00:54 2014 | ||
mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/17629543b1608604010dd5cef3272f94b5fa5624 | 00:25 |
---|---|---|
mor1kx | mor1kx/master 1762954 Stefan Kristiansson: cappuccino/lsu: let stores go through to dcache when disabled... | 00:25 |
olofk_ | stekern: Cool stuff | 06:06 |
olofk_ | What's the coremark for a single CPU? | 06:14 |
stekern | olofk_: under Linux, 1.66 coremark/MHz | 07:00 |
stekern | olofk_: what's the status on your de0 nano fixes btw? | 07:23 |
stekern | I've got some changes I'd like to add, but they clash with yours so, should I: | 07:25 |
stekern | 1) just do my changes and ignore you | 07:25 |
stekern | 2) pick up the clashing patch and fix my comments and commit that and then do my changes | 07:26 |
stekern | 3) wait for you, because you've just fixed them | 07:27 |
olofk_ | Wait for me sounds like the worst idea ever | 08:25 |
olofk_ | Do your stuff and I'll rebase when I have the time | 08:26 |
stekern | ok, cool, thanks | 08:38 |
olofk_ | But if any of my patches are helpful, feel free to change and apply them | 09:05 |
stekern | yeah, I think I have something that need wb_intercon regeneration, so it's mostly related to that | 09:06 |
stekern | and the only comment that needed some change there was the size from dec->hex | 09:08 |
juliusb | hello from ehsm! | 09:40 |
juliusb | stekern: that's some impressive coremark! | 09:41 |
juliusb | dual core linux? | 09:41 |
juliusb | it took less than 10 minutes from saying hello sb0 to us discussing lm32 vs or1k ;) | 09:44 |
stekern | juliusb: yup, dual core linux | 09:51 |
juliusb | way cool. I will quote those numbers toay | 09:55 |
juliusb | you can watch live as I do it if you like http://webcast.desy.de/live/mainauditorium.html | 09:56 |
stekern | at what time? | 09:58 |
stekern | and, will there be non-live recordings available? | 09:58 |
juliusb | ummm, 2:30 Germany time | 09:58 |
juliusb | almost certainly | 09:58 |
juliusb | but in about 2.5 hours I think. It's just coming up to midday here | 09:58 |
stekern | ok, I'll probably be afk then :( | 10:05 |
juliusb | well, will make a shout-out anyway in case you are | 10:06 |
juliusb | is a XILINX variable required in your path when running FuseSoC for the atlys (or other Xilinx target boards?) | 10:10 |
stekern | yes, you need to do the source /path/to/ISE/settings64.sh dance | 10:10 |
juliusb | OK | 10:11 |
juliusb | well, I didn't have /path/to/ISE/bin/lin in my $PATH, maybe that's all that is required? | 10:11 |
juliusb | yes, that appeared to be all that was reqired | 10:12 |
juliusb | gah! license file required to build for atlys with ISE14.6?! http://pastie.org/9334188 | 10:21 |
juliusb | Bloody Xilinx, honestly... | 10:22 |
juliusb | is it possible I'm not using the right ISE? Or even then, do I require a license? | 10:24 |
stekern | you always need license files | 10:29 |
stekern | but, you shouldn't have /path/to/ISE/bin/lin in your path, the source /path/to... handles that | 10:39 |
juliusb | ok | 11:33 |
juliusb | obviously haven't used ISE on this machine in a while (ever??) | 11:33 |
juliusb | well that's less painless to do than I remember. just download a file and point LM_LICENSE_FILE at it | 11:47 |
juliusb | they're not even really node locked anymore, what's the point Xilnix? | 11:48 |
poke53281 | blueCmd: I tried to chroot into the debian environment. Unfortunately I get a segmentation fault after a while. | 11:50 |
poke53281 | I tried it with your Linux version: https://github.com/bluecmd/or1k-linux | 11:50 |
poke53281 | According to your debian it should work with or1ksim. Is this true? | 11:53 |
juliusb | I seem to recall there was a nice diagram done of the debugging possibilities of OR1K systems | 12:02 |
juliusb | olofk_: I found this one by trawling the archives: https://www.dropbox.com/s/b8t2zx0kbhv9cl3/or1k%20stack.png | 12:02 |
juliusb | it's a good picture | 12:02 |
juliusb | did you ever do another spin or did it ever go up in print anywhere? | 12:03 |
olofk_ | juliusb: I haven't done anything more with that pic, but I had in mind to do a blog post where I could use it to explain some concept. Haven't done that yet | 12:15 |
juliusb | well, do you mind if I use it in the presentatino? | 12:16 |
juliusb | I think it's the goods | 12:16 |
olofk_ | Sure. Use it | 12:17 |
olofk_ | I tuned into the live stream now. You're up in 15, right? | 12:17 |
juliusb | yep | 12:17 |
* olofk_ will make popcorn | 12:18 | |
juliusb | and thanks | 12:18 |
olofk_ | Blast them away with the OpenRISC greatness, and always remember why we are doing this ;) | 12:18 |
juliusb | groupies | 12:18 |
juliusb | and money | 12:18 |
juliusb | preferrably groupies with money | 12:18 |
olofk_ | Break a leg | 12:24 |
olofk_ | Woohoo!! It's starting | 12:31 |
olofk_ | Is that mor1kx explanation an afterthought? :) | 12:33 |
sb0 | juliusb, no, we discussed making yet another most probably failing open softcore vs. fixing the existing ones | 12:41 |
sb0 | juliusb, and that chisel is an academic toy | 12:42 |
sb0 | the or1k gcc is not upstream | 12:46 |
sb0 | the lm32 gcc has bugs | 12:47 |
sb0 | the or1k llvm is not upstream, and the inline asm lacks features (that might have been done and need merging) | 12:47 |
sb0 | mor1kx is bloated | 12:47 |
sb0 | the lm32 verilog code is a tad ugly | 12:48 |
sb0 | all this stuff could be rewritten in migen | 12:48 |
sb0 | it's not like there isn't work to do on the existing stuff... | 12:48 |
olofk_ | I LOVE the ecosystem picyure :) | 12:48 |
sb0 | and yeah, or1k arch has flags and delay slots that could be nice to remove | 12:48 |
sb0 | and heck, I could even spend some m-labs money on getting some of this done. we're not groupies, we just want to have excellent tech. | 12:50 |
olofk_ | Hi, I'm watching :) | 12:51 |
* olofk_ applauds as well | 12:57 | |
juliusb | sb0: I paraphrased | 13:44 |
juliusb | sb0: I thought that ecosystem picture could have been laced with more humor but I couldn't think of more | 13:45 |
juliusb | but I hope you noticed the "software" label very close to a load of bugs ;) | 13:45 |
juliusb | whoops, ecosystem comment for olofk_ I meant | 13:46 |
sb0 | juliusb, seriously, forget academia. or just name one successful EDA tool or IP core they released. | 13:48 |
sb0 | all they can do is buy zynq boards | 13:48 |
juliusb | MIPS and SPARC came out of academia | 13:48 |
sb0 | yeah, right. last time I checked, you needed a virtex-5 110 board to run opensparc, and it'll still be slow | 13:52 |
juliusb | that implementation came out of industry, the ISAs came out of acaedmia | 13:54 |
sb0 | I said 'IP core'. not ISA. | 13:54 |
sb0 | and every single actual core coming out of academia is not usable | 13:55 |
juliusb | well, I mentioned RISC-V today in terms of it being a good-looking ISA | 13:55 |
juliusb | there is a core available, but it's written in Chisel, and I'm not the biggest fan of that, something in Verilog would be good, but anyway, these were observations, not statements of intent | 13:56 |
juliusb | I will drink a beer | 13:56 |
juliusb | that is a statement of intent | 13:56 |
juliusb | and a true one | 13:56 |
olofk_ | sb0: I'm inclined to agree here. There are a lot of concepts, ISAs, new languages and stuff coming from academia, but I can't think of a single core actually :) | 14:10 |
-!- rfajardo is now known as rschmidlin | 15:11 | |
stekern | sb0: re mor1kx bloat, with a fresh release out and me poking around the source for a bit lately I think now might be a good moment to poke at that | 17:05 |
stekern | one thing I have in mind for your typical use case is to go over mor1kx_ctrl_cappuccino.v and make some things optional, some might be 'mandatory' by the spec, but at the same time very specific implementations might not be interested in them | 17:07 |
stekern | for instance some things like the existance of the npc (which is a rather large mux) is only of high importance if you have a debug unit present | 17:10 |
stekern | *of the npc spr | 17:10 |
olofk_ | stekern: If you only execute one instruction, you can probably throw away the complete npc | 18:37 |
stekern | olofk_: the point is, the npc spr is only used for exactly one thing, the spr register | 18:42 |
stekern | internally 'the next pc' is a complete different story | 18:43 |
stekern | ...and since it's 'disallowed' to read the npc spr from software, it's really just a du thing | 19:09 |
olofk_ | I'm starting to wonder what options we would have to do more invasive changes to the spec | 19:11 |
stekern | but since there's sw that we care about around that disobey that rule, so it's been left in as unconditional default | 19:11 |
olofk_ | Like marking mandatory things as optional | 19:11 |
olofk_ | ah ok | 19:11 |
olofk_ | Out of curiousity, what software is cheating? | 19:11 |
stekern | our newlib/libgloss code | 19:12 |
olofk_ | Only that? | 19:12 |
stekern | I think so, I've been meaning to fix that forever | 19:13 |
stekern | but people tend to try to use the npc spr from sw all the time, _franck_ did it just a week ago | 19:13 |
stekern | (marking mandatory things as optional) we have to remember that it's one thing to be "or1k spec compliant" and for people to want to use an or1k ISA core that can be configured to bend some rules | 19:15 |
stekern | mandatory things should of course always be default on, but that doesn't mean that someone might want to opt out things because they simply don'y need them for a specific use case | 19:16 |
olofk_ | All very true | 19:23 |
stekern | all the overflow stuff is one other thing, it's mostly pretty useless for most use cases | 19:26 |
stekern | I think most of that is optional in mor1kx already though, and I can't remember how much, if any, of it is actually mandatory | 19:27 |
stekern | hmm, mibuild seems to miss the -detail map option as well | 20:28 |
--- Log closed Sun Jun 29 00:00:55 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!