--- Log opened Fri Sep 19 00:00:58 2014 | ||
poke53282 | stekern: http://pastie.org/9574284 | 04:11 |
---|---|---|
poke53282 | I think this is interesting for you. I made somestatistics about the instructions used. | 04:12 |
poke53282 | Do I get a special instruction to push and pop from stack ;) | 04:13 |
stekern | poke53282: nope, I don't see much benefit of such instruction ;) | 04:36 |
stekern | you might get some minor performance increase due to fewer icache misses, but IMO it doesn't justify the added hw complexity | 04:38 |
poke53282 | I see one. I would give this instruction their own tlb lookup variables. | 04:46 |
poke53282 | in my emulator. | 04:47 |
poke53282 | we could remove the l.addi instruction per function (two times per function). | 04:48 |
stekern | yes, but again, to much added hw complexity to make it worth it | 04:50 |
stekern | *too | 04:50 |
stekern | how do you mean 'tlb lookup variables'? | 04:51 |
poke53282 | ahh, that's a way to increase the performance. https://github.com/s-macke/jor1k/wiki/Technical-details#instruction-mmu | 04:52 |
poke53282 | We have a tlb, and I have an additional ultra-fast tlb which contains only one entry. | 04:53 |
poke53282 | The same is true for the data mmu. | 04:53 |
poke53282 | all instructions which accesses the memory have their own tlb variables. | 04:54 |
poke53282 | this trick gives me at least an increase of the speed by 30%. Maybe 50%. | 04:55 |
stekern | ok, but that only makes sense in an emulator | 04:56 |
poke53282 | That's true | 04:57 |
stekern | one performance hack you could consider, since you're only running Linux anyway, is to hard code the 0xc0000000-0xffffc000 -> 0x00000000-0x3fffc000 mapping | 04:59 |
stekern | I want to test that in hw, it should be super simple to do, just haven't got around to it | 05:00 |
poke53282 | Hmm, not a bad idea | 05:01 |
poke53282 | if (addr&0xC0000000) return addr; | 05:02 |
poke53282 | if (addr&0xC0000000) return addr&0xFFFFFFF; | 05:03 |
poke53282 | probably a little bit too simple, but close | 05:04 |
stekern | shouldn't it be: if (addr&0xc0000000) return addr&0x3fffffff; | 05:09 |
poke53282 | Hmm, 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 |
poke53282 | Yes | 05:09 |
stekern | I somehow doubt it | 05:13 |
stekern | comparing with x86 might not make sense neither | 05:13 |
olofk | blueCmd: 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 port | 06:57 |
olofk | Any tips for how to get all function names and their address from a vmlinux? | 07:36 |
olofk | Is it objdump -x I'm looking for? | 07:37 |
olofk | Aha. with some extra grepping for F this should work | 07:43 |
stekern | what are you doing? | 07:50 |
olofk | Gathering statistics on time spent in different functions in linux | 07:51 |
olofk | This time with verilator. God damn, that is a lot faster than icarus | 07:51 |
stekern | ah, cool | 07:57 |
stekern | would be interesting to have that in hw | 07:58 |
olofk | Yeah, but then it would have to be something more clever than what I'm doing now. | 07:59 |
stekern | because, it's hard to get any real data except for boot with verilator | 07:59 |
olofk | true | 08:00 |
olofk | But optimizing boot speed is all we care about anyway, right? :) | 08:01 |
stekern | right | 08:04 |
_franck__ | if someone is interrested, I have a CFI peripheral for or1ksim here: https://github.com/fjullien/or1ksim/tree/cfi | 10: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 request | 10: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...64651c8af488 | 11:27 |
mor1kx | mor1kx/master d651997 Florent Kermarrec: mor1kx_ctrl_cappuccino: fix spr_access_ack[`OR1K_SPR_SYS_BASE] and clean up DEBUGUNIT | 11:27 |
mor1kx | mor1kx/master 4374e6a Florent Kermarrec: mor1kx_pic, mor1kx_ticktimer: use spr_access_i on all spr_addr check | 11:27 |
mor1kx | mor1kx/master 856da99 Stefan Kristiansson: cappuccino/ctrl: left justify generate statements | 11: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 works | 11:49 |
_florent_ | ok thanks! | 11:50 |
stekern | a couple of coding style preferences again, I tend to not use && and ||, but rather & and |. and I want to move towards // comments everywhere | 11:53 |
_florent_ | ok | 12:33 |
mor1kx | [mor1kx] skristiansson pushed 2 new commits to multicore: https://github.com/openrisc/mor1kx/compare/c539d59e1635...5085c82c430a | 12:53 |
mor1kx | mor1kx/multicore 6aaf811 Stefan Kristiansson: Merge branch 'master' of github.com:openrisc/mor1kx into multicore... | 12:53 |
mor1kx | mor1kx/multicore 5085c82 Stefan Kristiansson: Merge branch 'master' of github.com:openrisc/mor1kx into multicore... | 12:53 |
-!- Netsplit *.net <-> *.split quits: bentley` | 14:10 | |
stekern | olofk: do you know what I'd like wb_intercon_gen to be able to do? generate arrayed buses | 14:32 |
stekern | because, that's the only thing that is constraining me from making multiple cpu instantiation generic | 14:32 |
stekern | I'm trying to build a quad-core SoC now | 14:46 |
PaulfraOSAA | olofk: ping? | 15:20 |
PaulfraOSAA | I 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 8388608 | 15:25 |
-!- Hesham1 is now known as hesham | 15:27 | |
stekern | cool! it "just works(tm)" | 15:52 |
PaulfraOSAA | Ok, 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 fit | 15: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 |
stekern | PaulfraOSAA: which memory is that? | 15:58 |
stekern | I 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 backlog | 15:58 |
PaulfraOSAA | OK, It is the ram_wb as far as I can tell | 15:59 |
PaulfraOSAA | I am trying to get a uart going on his lx9_microboard stuff | 16:00 |
PaulfraOSAA | So far I have succeeded in making the LEDs not blink :) | 16:00 |
stekern | :) | 16:09 |
stekern | I still have 54% of the FPGA left, so a 8-core setup is definitely doable | 16:16 |
poke53282 | awesome | 16:18 |
poke53282 | I have to look at your smp branch to see what's new | 16:19 |
PaulfraOSAA | stekern: 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 |
stekern | I think that's supposed to be used with wb_ram (as opposed to ram_wb) | 16:21 |
stekern | but I don't know which he is using in that board port | 16:22 |
PaulfraOSAA | it has depend = wb_ram, so I'd guess... | 16:23 |
PaulfraOSAA | Only problem is that when I try to generate the core, it fails on putting stuff into the ram from .vh | 16:25 |
PaulfraOSAA | SUCESS! 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 |
PaulfraOSAA | stekern: 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 |
PaulfraOSAA | Much better :) | 17:00 |
* PaulfraOSAA is proud | 17:00 | |
mor1kx | [mor1kx] bandvig tagged fpu32_v1.0 at 53810ec: https://github.com/openrisc/mor1kx/commits/fpu32_v1.0 | 17:12 |
stekern | PaulfraOSAA: \o/ | 17:16 |
PaulfraOSAA | Now to the (somewhat more) boring part - documenting, so that I can remember half of it tomorrow or in a couple of months :) | 17:17 |
PaulfraOSAA | I'll thow a URL when I get the wikipage posted | 17:18 |
stekern | poke53282: there's not much new, changing from 2-4 cores is just a matter of changing the CONFIG_NR_CPUS option | 17: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 ones | 17:21 |
poke53282 | stekern: What was the link to the repository? | 17:33 |
poke53282 | I forgot | 17:35 |
poke53282 | Ahh, found it | 17:46 |
stekern | 6.26 coremark/MHz | 18:37 |
PaulfraOSAA | My adventures in OpenRISC land (so far) http://osaa.dk/wiki/index.php/OpenRISC | 18:59 |
PaulfraOSAA | Please comment if there is anything completly wrong (such as the fact that I link directly to olofk's dropbox) | 18:59 |
stekern | PaulfraOSAA: looks good | 19:04 |
mor1kx | [mor1kx] bandvig pushed 1 new commit to withfpu: https://github.com/openrisc/mor1kx/commit/d1932f9d70ad2e910e2cfac70c11dbbff06da8ad | 19:04 |
mor1kx | mor1kx/withfpu d1932f9 Andrey Bacherov: Merge branch 'master' into 'withfpu' | 19:04 |
poke53282 | stekern: And how many MHz do you have? | 19:09 |
poke53282 | Did you change you Mandelbrot calculator? | 19:10 |
poke53282 | Is mplayer parallelized? | 19:10 |
poke53282 | would be worth a try I think. | 19:10 |
stekern | right now I'm running at 50MHz | 19:10 |
stekern | I was running at 100 MHz, but I had some timing errors at that | 19:11 |
stekern | I didn't change the mandelbrot | 19:14 |
olofk | stekern: 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 |
olofk | PaulfraOSAA: If the lx9 port works somewhat, perhaps I should just push it | 19:49 |
PaulfraOSAA | It works, but you can't recompile the sw | 19:49 |
PaulfraOSAA | or at least you need a step between running make and getting the correct output in led_blink.vh | 19:50 |
PaulfraOSAA | Your python script (you should really name it .py) puts out the right numbers, but in the wrong format | 19:50 |
olofk | Yeah, I should fix that properly. It shouldn't generate a verilog module at all. I have another method that is a lot nicer | 19:51 |
olofk | But I'll put it on my github account for now, so it's at least easier to find than my dropbox | 19:51 |
olofk | because I will remove it from my dropbox at some point when I forgot why I put it there | 19:52 |
olofk | So 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 parameter | 19:54 |
olofk | Also, you don't need systems_root anymore. That is deprecated | 19:54 |
olofk | So your fusesoc.conf would look like this | 19:54 |
olofk | [main] | 19:54 |
olofk | cores_root=../orpsoc-cores path/to/parent/dir/of/lx9_microboard | 19:55 |
PaulfraOSAA | ah... that second line had me worried a bit :) | 19:55 |
PaulfraOSAA | I'll change it, is the git repo updated? | 19:55 |
olofk | PaulfraOSAA: https://github.com/olofk/lx9_microboard.git | 20:01 |
olofk | Time to sleep now | 20:04 |
PaulfraOSAA | goodnight | 20:05 |
PaulfraOSAA | Is it just me or is opencores.org down tonight? | 20:11 |
poke53282 | PaulfraOSAA: Yes, server not found | 22:09 |
PaulfraOSAA | ok then, I might as well turn in then :) | 22:09 |
poke53282 | Not even a DNS lookup works. | 22:10 |
poke53282 | So, it seems on purpose. | 22:11 |
poke53282 | the ip is 193.22.254.22 | 22:16 |
PaulfraOSAA | It won't even connect to the server when using that IP directly | 22:41 |
poke53282 | but ping works | 22:47 |
poke53282 | so 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!