| --- Log opened Mon Feb 17 00:00:43 2014 | ||
| stekern | pgavin: yeah, I don't think you need to worry about flushing lru logic | 02:44 |
|---|---|---|
| stekern | fwiw, there are patches floating around that adds assoc > 2 to mor1kx as well | 02:45 |
| stekern | https://github.com/wallento/mor1kx/commit/5c71606c2cfaa6950758cee097abbb7f697a8da7 | 02:48 |
| stekern | if you only write the target on mispredicted branches, you will never store unconditional branches =) | 02:55 |
| stekern | I guess those are excluded from taht statement | 02:55 |
| stekern | but I don't know if saving a 30-bit != is worth the trouble with manually flushing the tables | 03:00 |
| pgavin | stekern: a direct jump is never taken the first time it's seen, that counts as a misprediction | 03:51 |
| pgavin | and I'm currently trying to make sure my lru logic will work even if the state is inisially random | 03:52 |
| pgavin | initially* | 03:52 |
| pgavin | well, I think I've modified it so it will work. I still need to test it :) | 03:52 |
| pgavin | stekern: oh, that should be "a direct jump is never *predicted* taken the first time" | 03:54 |
| stekern | ok | 04:04 |
| stekern | are your pipeline so deep that a BTB will make a big difference? or is it just for the fun of it? | 04:05 |
| stekern | oh, right... without the delay slot you sure need it | 04:05 |
| pgavin | I'm designing this core as part of my dissertation | 04:08 |
| pgavin | and the dissertation involves the branch predictor | 04:09 |
| pgavin | and yeah, without a delay slot it's a bit more necessary | 04:09 |
| stekern | yes, but you can predict branches without predicting branch targets ;) | 04:12 |
| stekern | I think in mor1kx cappuccino, I'll just do dynamic branch prediction, and skip the BTB's | 04:12 |
| pgavin | is that because you can resolve the target earlier than you can the condition? | 04:16 |
| pgavin | resolving the condition is pretty easy though because of the way the flag register is used | 04:16 |
| pgavin | my pipeline has F, D, E, M, W like a traditional pipeline. The sf* instructions resolve at E, and the target calculation happens at E as well, so I can forward the result of the sf* instruction back to the E stage to completely resolve the branch | 04:18 |
| pgavin | because the sf* instruction will be at M when the branch instruction is at E, of course :) | 04:19 |
| pgavin | I think I would have timing issues if I pushed the branch resolution back to the D stage because the result of the sf instruction comes fairly late in the cycle | 04:20 |
| wkoszek | Any updates on GSOC? | 04:22 |
| wkoszek | Online Verilog regression system owuld be interesting. | 04:22 |
| stekern | pgavin: I'm resolving l.sf in E, but the target calculations happens in D | 06:07 |
| stekern | moving the target calculation to E might have it's benefits, but I'm not sure if the effort needed for target prediction outweighs it | 06:10 |
| stekern | in mor1kx I mean | 06:10 |
| stekern | the l.sf resolving was a much huger critical path for us | 06:11 |
| pgavin | stekern: my thought when I design the pipeline was that, (for example) doing a less-than comparison using the forwarded ALU sources, then using the result of that comparison to choose the next PC to fetch from was too much to do in one cycle | 06:43 |
| pgavin | but I still haven't done any real timing analysis, because I want to complete the l1 caches first, since that would probably change everything anyways | 06:45 |
| blueCmd | wkoszek: Accepted Orgs Announced In: | 12:29 |
| blueCmd | February 24 at 19:00 UTC | 12:29 |
| olofk_ | cool. Hope we get accepted | 12:36 |
| blueCmd | well, next time we should probably plan it more than 20 hours before the deadline xD | 12:38 |
| olofk_ | At least we are before the deadline this time, so we're getting there :) | 12:58 |
| jtdesousa | hi, does anybody know how to set the or1ksim config file so that it stops to get scanf input? | 14:48 |
| jtdesousa | it simply executes it without stopping although I have some magic config files where it does stop | 14:49 |
| jtdesousa | I am using xterm as IO | 14:50 |
| blueCmd | I'm not sure what you mean. scanf i | 14:53 |
| blueCmd | input? | 14:53 |
| jtdesousa | normally scanf("%d", &x) should stop and wait for you to enter a number | 14:55 |
| jtdesousa | it doesn't | 14:55 |
| blueCmd | right, blocking reads - you mean that or1ksim spins a non-blocking scanf? | 14:56 |
| blueCmd | because if it does, that does sound lika a bug to me | 14:56 |
| jtdesousa | looks like so,its not a bug but it must have to do with the configuration of or1ksim or the -mboard compile option | 14:57 |
| xlro | hi guys, what fpga board would you recommend regarding currently best support from orpsoc etc, especially for the mor1kx cappuccino implementation? stekern, what do you use for development? main use would just be testing & playing around with modifications of the OR core, not to build an actual system for a specific purpose | 18:36 |
| olofk | xlro: de0 nano | 18:54 |
| olofk | Hey, controversial idea. Could we drop the or32-master branch of or1ksim on github? | 19:08 |
| olofk | Or at least explain how the fuck I can get both the or1k-master and or32-master branches in my local repÃo | 19:08 |
| olofk | Either is fine | 19:08 |
| olofk | aha! I think I made it. | 19:13 |
| olofk | Still... I'm inclined to leave all the or32-* stuff at the old opencores mega-repo and put that in maintenance mode | 19:14 |
| olofk | maintenance mode=don't touch unless paid for it | 19:15 |
| pgavin | olofk: I think there are some changes in the or32-master branch that haven't made it back to the mega-repo | 19:18 |
| pgavin | not sure that's a concern though | 19:18 |
| pgavin | jeremy asked me to make separate branches for the changes I made to or1ksim | 19:18 |
| pgavin | but that was a long time ago now | 19:18 |
| olofk | pgavin: I understand the origianl idea, but as you said it was a long time ago now, and I'm not sure that the maintenance overhead outweights the benefits | 19:21 |
| pgavin | yeah, that's my thought | 19:26 |
| olofk | jeremybennett: What's your take on this? It's been mostly your baby over the last years | 19:26 |
| olofk | Hmm.. I can confirm the non-blocking or1ksim issue | 19:33 |
| olofk | with uart over socket | 19:38 |
| xlro | thanks olofk | 19:41 |
| blueCmd | still sounds like a bug to me, or am I missing something? | 20:03 |
| olofk | blueCmd: Yes. I think so too. This is not really my domain, but I'm spreading printf's through the code and it looks a bit strange | 20:04 |
| olofk | Does telnet send anything during connect? | 20:13 |
| olofk | I think I remember that it does and that it can be turned off, but I can't find anything now | 20:13 |
| blueCmd | it does | 20:30 |
| blueCmd | or maybe not | 20:31 |
| blueCmd | I seemed to remember that it did, but I can't find anything backing it | 20:31 |
| olofk | Installed netcat now, and that man page seems to indicate that telnet is a bit chatty | 20:46 |
| olofk | ok, I seriously don't understand what's going on here | 21:01 |
| olofk | ohh..... 0 is not less than 0. That explains a lot | 21:04 |
| olofk | Hmm... still doesn't make sense. 0 is definitely <= 0 | 21:09 |
| olofk | ok, I managed to make it blocking now, but I'm really not sure this is done correctly | 21:33 |
| olofk | hmm.. should really linux work in or1ksim if we had that problem there? | 21:47 |
| pgavin | I've never tried it using a network socket | 21:50 |
| pgavin | which is where it sounds like the problem was, correct? | 21:51 |
| pgavin | in the driver for that? | 21:51 |
| olofk | or1ksim can emulate a UART with either an xterm, files for reading and writing or use a socket | 21:52 |
| olofk | I don't have xterm installed, so my only chance of testing this is the socket mode (which I usually use anyway) | 21:52 |
| pgavin | I suppose I've only used xterm | 21:53 |
| pgavin | or stdin/stdout | 21:53 |
| olofk | Yeah, I think that's default | 21:53 |
| olofk | Always found that a bit shaky | 21:53 |
| pgavin | stdin/stdout should be default, IMO | 21:53 |
| olofk | Yeah, I guess that makes sense. It might be actually. Can't really remember | 21:54 |
| pgavin | it's been a while since I've used it :) | 21:55 |
| olofk | hmm... can't find a stdio mode at all actually | 21:55 |
| olofk | Yeah, me too | 21:55 |
| pgavin | I think I used files with /dev/std{in,out} | 21:55 |
| pgavin | can't remember now | 21:55 |
| pgavin | ah | 21:56 |
| olofk | Right now I want to recompile a kernel with some extra files in initramfs. Looks like my build instructions have rotted since I did that the last time | 21:56 |
| pgavin | channel = "fd:" | 21:56 |
| pgavin | in the config | 21:56 |
| olofk | And then what? | 21:56 |
| olofk | Just that? | 21:57 |
| pgavin | it emulates the uart over stdin/stdout | 21:57 |
| pgavin | section uart | 21:57 |
| pgavin | enabled = 1 | 21:57 |
| pgavin | baseaddr = 0x90000000 | 21:57 |
| pgavin | channel = "fd:" | 21:57 |
| pgavin | irq = 2 | 21:57 |
| pgavin | 16550 = 1 | 21:57 |
| pgavin | end | 21:57 |
| pgavin | 21:57 | |
| pgavin | the whole section | 21:57 |
| olofk | ah ok. So no need to specify values for fd? | 21:57 |
| pgavin | I suppose not | 21:57 |
| olofk | Seems to work | 21:58 |
| olofk | Great. Thanks | 21:59 |
| pgavin | np :) | 21:59 |
| olofk | Nah... I give up and leave this to someone who actually has a clue about what they are doing | 22:04 |
| pgavin | I notice the tcp socket is set to nonblocking by default | 22:06 |
| pgavin | that doesn't sound right | 22:07 |
| pgavin | but I'm not a socket programmer lol | 22:07 |
| olofk | pgavin: Yeah, I saw that too. Setting it to blocking had the nice effect that the simulation waited for a connection. Good if you don't want to miss anything. Bad if you want to run stuff in the background | 22:09 |
| olofk | Should probably be a config setting really | 22:09 |
| pgavin | maybe there should be a separate "wait for connect" setting | 22:24 |
| pgavin | when does it block? before the simulation starts? or when the first character is read/written? | 22:25 |
| jtdesousa | on the scanf non-blocking issue it was my fault. After compiling it with -mboard=or1ksim-uart it blocked with xterm | 22:47 |
| wkoszek | blueCmd: I suggest we keep polishing the ideas list. | 23:31 |
| wkoszek | Right now his list is a piece of crap. | 23:32 |
| wkoszek | We should also post some coordination stuff. | 23:32 |
| wkoszek | e.g.: | 23:32 |
| wkoszek | Please where community meets/talks/discusses etc.. | 23:32 |
| wkoszek | I'd put necessary skills/tools. | 23:33 |
| wkoszek | Maybe somebody could install VM @ EC2 with iVerilog etc.. | 23:33 |
| wkoszek | ? | 23:33 |
| wkoszek | I'd also add: "qhasm port for OpenRISC" for Daniel Bernstein qhasm language for fast assmebly programming. | 23:34 |
| --- Log closed Tue Feb 18 00:00:44 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!