IRC logs for #openrisc Friday, 2014-09-19

--- Log opened Fri Sep 19 00:00:58 2014
poke53282stekern: http://pastie.org/957428404:11
poke53282I think this is interesting for you. I made somestatistics about the instructions used.04:12
poke53282Do I get a special instruction to push and pop from stack ;)04:13
stekernpoke53282: nope, I don't see much benefit of such instruction ;)04:36
stekernyou might get some minor performance increase due to fewer icache misses, but IMO it doesn't justify the added hw complexity04:38
poke53282I  see one. I would give this instruction their own tlb lookup variables.04:46
poke53282in my emulator.04:47
poke53282we could remove the l.addi instruction per function (two times per function).04:48
stekernyes, but again, to much added hw complexity to make it worth it04:50
stekern*too04:50
stekernhow do you mean 'tlb lookup variables'?04:51
poke53282ahh, that's a way to increase the performance. https://github.com/s-macke/jor1k/wiki/Technical-details#instruction-mmu04:52
poke53282We have a tlb, and I have an additional ultra-fast tlb which contains only one entry.04:53
poke53282The same is true for the data mmu.04:53
poke53282all instructions which accesses the memory have their own tlb variables.04:54
poke53282this trick gives me at least an increase of the speed by 30%. Maybe 50%.04:55
stekernok, but that only makes sense in an emulator04:56
poke53282That's true04:57
stekernone performance hack you could consider, since you're only running Linux anyway, is to hard code the 0xc0000000-0xffffc000 -> 0x00000000-0x3fffc000 mapping04:59
stekernI want to test that in hw, it should be super simple to do, just haven't got around to it05:00
poke53282Hmm, not a bad idea05:01
poke53282if (addr&0xC0000000) return addr;05:02
poke53282if (addr&0xC0000000) return addr&0xFFFFFFF;05:03
poke53282probably a little bit too simple, but close05:04
stekernshouldn't it be: if (addr&0xc0000000) return addr&0x3fffffff;05:09
poke53282Hmm, would it make sense to treat the stack differently in hardware. Have x86 CPUs a special optimization for this? I am pretty sure. Probably the stack has its own cache.05:09
poke53282Yes05:09
stekernI somehow doubt it05:13
stekerncomparing with x86 might not make sense neither05:13
olofkblueCmd: Yes, I realize that we will miss the FP stuff, but otoh, mor1kx has managed so far without an FPU, so there is still some value in providing an integer-only port06:57
olofkAny tips for how to get all function names and their address from a vmlinux?07:36
olofkIs it objdump -x I'm looking for?07:37
olofkAha. with some extra grepping for F this should work07:43
stekernwhat are you doing?07:50
olofkGathering statistics on time spent in different functions in linux07:51
olofkThis time with verilator. God damn, that is a lot faster than icarus07:51
stekernah, cool07:57
stekernwould be interesting to have that in hw07:58
olofkYeah, but then it would have to be something more clever than what I'm doing now.07:59
stekernbecause, it's hard to get any real data except for boot with verilator07:59
olofktrue08:00
olofkBut optimizing boot speed is all we care about anyway, right? :)08:01
stekernright08:04
_franck__if someone is interrested, I have a CFI peripheral for or1ksim here: https://github.com/fjullien/or1ksim/tree/cfi10:01
_franck__I tested it with barebox and Linux (was some times ago)10:01
_franck__I'd like it to be tested by someone else before I send a pull request10:02
_franck__there is no hurry at all :)10:02
mor1kx[mor1kx] skristiansson pushed 4 new commits to master: https://github.com/openrisc/mor1kx/compare/9fce8500237b...64651c8af48811:27
mor1kxmor1kx/master d651997 Florent Kermarrec: mor1kx_ctrl_cappuccino: fix spr_access_ack[`OR1K_SPR_SYS_BASE] and clean up DEBUGUNIT11:27
mor1kxmor1kx/master 4374e6a Florent Kermarrec: mor1kx_pic, mor1kx_ticktimer: use spr_access_i on all spr_addr check11:27
mor1kxmor1kx/master 856da99 Stefan Kristiansson: cappuccino/ctrl: left justify generate statements11:27
olofk_franck_: Cool. No time to test it unfortunately :(11:35
stekern_florent_: I needed to gate the other external spr units acks as well, but now it works11:49
_florent_ok thanks!11:50
stekerna couple of coding style preferences again, I tend to not use && and ||, but rather & and |. and I want to move towards // comments everywhere11:53
_florent_ok12:33
mor1kx[mor1kx] skristiansson pushed 2 new commits to multicore: https://github.com/openrisc/mor1kx/compare/c539d59e1635...5085c82c430a12:53
mor1kxmor1kx/multicore 6aaf811 Stefan Kristiansson: Merge branch 'master' of github.com:openrisc/mor1kx into multicore...12:53
mor1kxmor1kx/multicore 5085c82 Stefan Kristiansson: Merge branch 'master' of github.com:openrisc/mor1kx into multicore...12:53
-!- Netsplit *.net <-> *.split quits: bentley`14:10
stekernolofk: do you know what I'd like wb_intercon_gen to be able to do? generate arrayed buses14:32
stekernbecause, that's the only thing that is constraining me from making multiple cpu instantiation generic14:32
stekernI'm trying to build a quad-core SoC now14:46
PaulfraOSAAolofk: ping?15:20
PaulfraOSAAI get an error when trying to compile the lx9 example, it says that "Index <128> is out of range [0:127] for signal <mem>" It seems the memory isn't big enough to hold the program, but my wb_intercon.conf sets the memory to 838860815:25
-!- Hesham1 is now known as hesham15:27
stekerncool! it "just works(tm)"15:52
PaulfraOSAAOk, so if anyone is reading the history, it seems that the new compiler outputs the .vh file in a somewhat different manner and that it is requred to go into the file and delete a lot of the spaces therein, that way the file is suddenly not too big to fit15:53
_franck__stekern: so, what's your feeling ? Is it more fun when it works first try ?15:55
_franck__:)15:55
stekern_franck__: well, I must say that seeing something work after debugging it for a week is more satisfying. But I wasn't wishing for it to not work ;)15:57
stekernPaulfraOSAA: which memory is that?15:58
stekernI think that olofk did a python script to genereate the .vh from a program if it's the bootloader, but I'm sure he'll read the backlog15:58
PaulfraOSAAOK, It is the ram_wb as far as I can tell15:59
PaulfraOSAAI am trying to get a uart going on his lx9_microboard stuff16:00
PaulfraOSAASo far I have succeeded in making the LEDs not blink :)16:00
stekern:)16:09
stekernI still have 54% of the FPGA left, so a 8-core setup is definitely doable16:16
poke53282awesome16:18
poke53282I have to look at your smp branch to see what's new16:19
PaulfraOSAAstekern: He did write a python script, the sad part is it doesn't put the output in binary form in the .vh file, it puts it in verilog form in the .v file :(16:20
stekernI think that's supposed to be used with wb_ram (as opposed to ram_wb)16:21
stekernbut I don't know which he is using in that board port16:22
PaulfraOSAAit has depend = wb_ram, so I'd guess...16:23
PaulfraOSAAOnly problem is that when I try to generate the core, it fails on putting stuff into the ram from .vh16:25
PaulfraOSAASUCESS! By laboriously putting values from the .v file into the .vh file (thank TFSM for vim macros) I hav now gotten the LEDs to blink again :)16:58
PaulfraOSAAstekern: btw, that "just works(tm)" was with the setup olofk sent me without touching anything, now I have broken stuff _and_ gotten it to work again.17:00
PaulfraOSAAMuch better :)17:00
* PaulfraOSAA is proud17:00
mor1kx[mor1kx] bandvig tagged fpu32_v1.0 at 53810ec: https://github.com/openrisc/mor1kx/commits/fpu32_v1.017:12
stekernPaulfraOSAA: \o/17:16
PaulfraOSAANow to the (somewhat more) boring part - documenting, so that I can remember half of it tomorrow or in a couple of months :)17:17
PaulfraOSAAI'll thow a URL when I get the wikipage posted17:18
stekernpoke53282: there's not much new, changing from 2-4 cores is just a matter of changing the CONFIG_NR_CPUS option17:19
stekern...and you can run that option > than the actual number of cpus, it will time-out when it try to kick the non-existing ones17:21
poke53282stekern: What was the link to the repository?17:33
poke53282I forgot17:35
poke53282Ahh, found it17:46
stekern6.26 coremark/MHz18:37
PaulfraOSAAMy adventures in OpenRISC land (so far) http://osaa.dk/wiki/index.php/OpenRISC18:59
PaulfraOSAAPlease comment if there is anything completly wrong (such as the fact that I link directly to olofk's dropbox)18:59
stekernPaulfraOSAA: looks good19:04
mor1kx[mor1kx] bandvig pushed 1 new commit to withfpu: https://github.com/openrisc/mor1kx/commit/d1932f9d70ad2e910e2cfac70c11dbbff06da8ad19:04
mor1kxmor1kx/withfpu d1932f9 Andrey Bacherov: Merge branch 'master' into 'withfpu'19:04
poke53282stekern: And how many MHz do you have?19:09
poke53282Did you change you Mandelbrot calculator?19:10
poke53282Is mplayer parallelized?19:10
poke53282would be worth a try I think.19:10
stekernright now I'm running at 50MHz19:10
stekernI was running at 100 MHz, but I had some timing errors at that19:11
stekernI didn't change the mandelbrot19:14
olofkstekern: About arrayed buses, not sure what your bus structure looks like, but perhaps you could use the wb_arbiter from wb_intercon and feed the output to the regular interconnect block?19:42
olofkPaulfraOSAA: If the lx9 port works somewhat, perhaps I should just push it19:49
PaulfraOSAAIt works, but you can't recompile the sw19:49
PaulfraOSAAor at least you need a step between running make and getting the correct output in led_blink.vh19:50
PaulfraOSAAYour python script (you should really name it .py) puts out the right numbers, but in the wrong format19:50
olofkYeah, I should fix that properly. It shouldn't generate a verilog module at all. I have another method that is a lot nicer19:51
olofkBut I'll put it on my github account for now, so it's at least easier to find than my dropbox19:51
olofkbecause I will remove it from my dropbox at some point when I forgot why I put it there19:52
olofkSo a slight change in your documentation for that. Instead of dropping the lx9 stuff into orpsoc-cores/systems, you can just put them somewhere else and add a new entry to the cores_root parameter19:54
olofkAlso, you don't need systems_root anymore. That is deprecated19:54
olofkSo your fusesoc.conf would look like this19:54
olofk[main]19:54
olofkcores_root=../orpsoc-cores path/to/parent/dir/of/lx9_microboard19:55
PaulfraOSAAah... that second line had me worried a bit :)19:55
PaulfraOSAAI'll change it, is the git repo updated?19:55
olofkPaulfraOSAA: https://github.com/olofk/lx9_microboard.git20:01
olofkTime to sleep now20:04
PaulfraOSAAgoodnight20:05
PaulfraOSAAIs it just me or is opencores.org down tonight?20:11
poke53282PaulfraOSAA: Yes, server not found22:09
PaulfraOSAAok then, I might as well turn in then :)22:09
poke53282Not even a DNS lookup works.22:10
poke53282So, it seems on purpose.22:11
poke53282the ip is 193.22.254.2222:16
PaulfraOSAAIt won't even connect to the server when using that IP directly22:41
poke53282but ping works22:47
poke53282so the server seems to be online, but neither the DNS service nor the web server is running.22:55
--- Log closed Sat Sep 20 00:00:00 2014

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!