IRC logs for #openrisc Monday, 2014-02-17

--- Log opened Mon Feb 17 00:00:43 2014
stekernpgavin: yeah, I don't think you need to worry about flushing lru logic02:44
stekernfwiw, there are patches floating around that adds assoc > 2 to mor1kx as well02:45
stekernif you only write the target on mispredicted branches, you will never store unconditional branches =)02:55
stekernI guess those are excluded from taht statement02:55
stekernbut I don't know if saving a 30-bit != is worth the trouble with manually flushing the tables03:00
pgavinstekern: a direct jump is never taken the first time it's seen, that counts as a misprediction03:51
pgavinand I'm currently trying to make sure my lru logic will work even if the state is inisially random03:52
pgavinwell, I think I've modified it so it will work. I still need to test it :)03:52
pgavinstekern: oh, that should be "a direct jump is never *predicted* taken the first time"03:54
stekernare your pipeline so deep that a BTB will make a big difference? or is it just for the fun of it?04:05
stekernoh, right... without the delay slot you sure need it04:05
pgavinI'm designing this core as part of my dissertation04:08
pgavinand the dissertation involves the branch predictor04:09
pgavinand yeah, without a delay slot it's a bit more necessary04:09
stekernyes, but you can predict branches without predicting branch targets ;)04:12
stekernI think in mor1kx cappuccino, I'll just do dynamic branch prediction, and skip the BTB's04:12
pgavinis that because you can resolve the target earlier than you can the condition?04:16
pgavinresolving the condition is pretty easy though because of the way the flag register is used04:16
pgavinmy 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 branch04:18
pgavinbecause the sf* instruction will be at M when the branch instruction is at E, of course :)04:19
pgavinI 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 cycle04:20
wkoszekAny updates on GSOC?04:22
wkoszekOnline Verilog regression system owuld be interesting.04:22
stekernpgavin: I'm resolving l.sf in E, but the target calculations happens in D06:07
stekernmoving the target calculation to E might have it's benefits, but I'm not sure if the effort needed for target prediction outweighs it06:10
stekernin mor1kx I mean06:10
stekernthe l.sf resolving was a much huger critical path for us06:11
pgavinstekern: 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 cycle06:43
pgavinbut I still haven't done any real timing analysis, because I want to complete the l1 caches first, since that would probably change everything anyways06:45
blueCmdwkoszek: Accepted Orgs Announced In:12:29
blueCmdFebruary 24 at 19:00 UTC12:29
olofk_cool. Hope we get accepted12:36
blueCmdwell, next time we should probably plan it more than 20 hours before the deadline xD12:38
olofk_At least we are before the deadline this time, so we're getting there :)12:58
jtdesousahi, does anybody know how to set the or1ksim config file so that it stops to get scanf input?14:48
jtdesousait simply executes it without stopping although I have some magic config files where it does stop14:49
jtdesousaI am using xterm as IO14:50
blueCmdI'm not sure what you mean. scanf i14:53
jtdesousanormally scanf("%d", &x) should stop and wait for you to enter a number14:55
jtdesousait doesn't14:55
blueCmdright, blocking reads - you mean that or1ksim spins a non-blocking scanf?14:56
blueCmdbecause if it does, that does sound lika a bug to me14:56
jtdesousalooks like so,its not a bug   but it must have to do with the configuration of or1ksim or the -mboard compile option14:57
xlrohi 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 purpose18:36
olofkxlro: de0 nano18:54
olofkHey, controversial idea. Could we drop the or32-master branch of or1ksim on github?19:08
olofkOr at least explain how the fuck I can get both the or1k-master and or32-master branches in my local repÃo19:08
olofkEither is fine19:08
olofkaha! I think I made it.19:13
olofkStill... I'm inclined to leave all the or32-* stuff at the old opencores mega-repo and put that in maintenance mode19:14
olofkmaintenance mode=don't touch unless paid for it19:15
pgavinolofk: I think there are some changes in the or32-master branch that haven't made it back to the mega-repo19:18
pgavinnot sure that's a concern though19:18
pgavinjeremy asked me to make separate branches for the changes I made to or1ksim19:18
pgavinbut that was a long time ago now19:18
olofkpgavin: 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 benefits19:21
pgavinyeah, that's my thought19:26
olofkjeremybennett: What's your take on this? It's been mostly your baby over the last years19:26
olofkHmm.. I can confirm the non-blocking or1ksim issue19:33
olofkwith uart over socket19:38
xlrothanks olofk19:41
blueCmdstill sounds like a bug to me, or am I missing something?20:03
olofkblueCmd: 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 strange20:04
olofkDoes telnet send anything during connect?20:13
olofkI think I remember that it does and that it can be turned off, but I can't find anything now20:13
blueCmdit does20:30
blueCmdor maybe not20:31
blueCmdI seemed to remember that it did, but I can't find anything backing it20:31
olofkInstalled netcat now, and that man page seems to indicate that telnet is a bit chatty20:46
olofkok, I seriously don't understand what's going on here21:01
olofkohh..... 0 is not less than 0. That explains a lot21:04
olofkHmm... still doesn't make sense. 0 is definitely <= 021:09
olofkok, I managed to make it blocking now, but I'm really not sure this is done correctly21:33
olofkhmm.. should really linux work in or1ksim if we had that problem there?21:47
pgavinI've never tried it using a network socket21:50
pgavinwhich is where it sounds like the problem was, correct?21:51
pgavinin the driver for that?21:51
olofkor1ksim can emulate a UART with either an xterm, files for reading and writing or use a socket21:52
olofkI don't have xterm installed, so my only chance of testing this is the socket mode (which I usually use anyway)21:52
pgavinI suppose I've only used xterm21:53
pgavinor stdin/stdout21:53
olofkYeah, I think that's default21:53
olofkAlways found that a bit shaky21:53
pgavinstdin/stdout should be default, IMO21:53
olofkYeah, I guess that makes sense. It might be actually. Can't really remember21:54
pgavinit's been a while since I've used it :)21:55
olofkhmm... can't find a stdio mode at all actually21:55
olofkYeah, me too21:55
pgavinI think I used files with /dev/std{in,out}21:55
pgavincan't remember now21:55
olofkRight 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 time21:56
pgavin  channel  = "fd:"21:56
pgavinin the config21:56
olofkAnd then what?21:56
olofkJust that?21:57
pgavinit emulates the uart over stdin/stdout21:57
pgavinsection uart21:57
pgavin  enabled  = 121:57
pgavin  baseaddr = 0x9000000021:57
pgavin  channel  = "fd:"21:57
pgavin  irq      = 221:57
pgavin  16550    = 121:57
pgavin 21:57
pgavinthe whole section21:57
olofkah ok. So no need to specify values for fd?21:57
pgavinI suppose not21:57
olofkSeems to work21:58
olofkGreat. Thanks21:59
pgavinnp :)21:59
olofkNah... I give up and leave this to someone who actually has a clue about what they are doing22:04
pgavinI notice the tcp socket is set to nonblocking by default22:06
pgavinthat doesn't sound right22:07
pgavinbut I'm not a socket programmer lol22:07
olofkpgavin: 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 background22:09
olofkShould probably be a config setting really22:09
pgavinmaybe there should be a separate "wait for connect" setting22:24
pgavinwhen does it block? before the simulation starts? or when the first character is read/written?22:25
jtdesousaon the scanf non-blocking issue it was my fault. After compiling it with -mboard=or1ksim-uart it blocked with xterm22:47
wkoszekblueCmd: I suggest we keep polishing the ideas list.23:31
wkoszekRight now his list is a piece of crap.23:32
wkoszekWe should also post some coordination stuff.23:32
wkoszekPlease where community meets/talks/discusses etc..23:32
wkoszekI'd put necessary skills/tools.23:33
wkoszekMaybe somebody could install VM @ EC2 with iVerilog etc..23:33
wkoszekI'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 2.15.2 by Marius Gedminas - find it at!