IRC logs for #openrisc Wednesday, 2016-05-18

--- Log opened Wed May 18 00:00:11 2016
shornehmm, strange maybe this is some bug in the simulator.  the instruction found causing issue is `l.lwz r3,0(r14)`00:27
shorneThe result is r3 is loaded with 0x2100000100:27
shorneBut, it I look at memory location r14, it should be 0x0000000300:28
shornei.e. (gdb) x/1xw $r1400:28
shorne0x7fd570:       0x0000000300:29
shornesomething strange going on there00:29
shorneNext instruction `l.lwz r4,4(r14)`, has no issue00:30
shornegetting the same results on or1ksim00:58
stekernSMDhome: I took a quick look at your patch yesterday. An initial comment, I think it'd be nice if the different branch predictors would be split up into seperate modules02:48
SMDhomestekern: you suggest to move new one to separate file and than instantiate it in that file?02:50
stekernyes, and move the current one into a separate file as well02:51
stekernand let the current file instantiate the correct one according to parameters02:52
shornelike is done for cpu in mor1kx_cpu.v02:52
SMDhomeok, will do02:52
stekernthat was my initial plan for the branch predictors, but it felt silly to break it out when there was only one implementation02:54
olofkshorne: Damn tricky, this one. Didn't get the chance to look at your findings yesterday02:54
SMDhomestekern: ok, anything else?02:55
shorneolofk: yeah, I think I got everything working in my patch except varargs. Not looking into varargs until I get the others working02:56
shorneI think variadic will require a bit rewrite02:56
shornebut want to get basics working first02:56
shorneeverything is working but that crazy `l.lwz r3,0(r14)` instruction02:57
stekernSMDhome: I didn't look to careful at the implementation yet.02:57
stekernBut you asked about how to test it? I think I did most of branch prediction testing with fusesoc + verilator02:58
stekernI even had some instrumentation which printed mis-predictions and so forth02:58
olofkstekern: Interesting. Did you implement an instruction tracer, or something specialized to look at predictions?03:00
SMDhomestekern: I have plans to implement perfomance counters system btw.03:01
olofkAnd was it directly in the verilator tb, or analysing some logs after the sim?03:01
stekernolofk: I have no memory whatsoever how I did it ;)03:01
stekernI remember that I had a dump of # branches and of hits and misses after the simulation ended03:02
SMDhomeI think it's great to be able to visualize pipeline and how instructions pass through it, having this tool really helps with perfomance analysis. But we have clock precise simulator to generate such logs.03:04
olofkSMDhome: You have the VCD file, which is actually kind of doing that03:06
olofkBut it's not a very user-friendly format for just looking at the pipeline perhaps03:07
olofkMaybe we should just write a small tool that can hook into the CPU and export to json for wavedrom03:08
SMDhomeolofk: it's simplified one. I mean it shows point instruction was fetched, when it was ready to execute(all operands are ready), execution(and things like misses) and when it was commited.03:10
SMDhomeSo it looks like this: /-----*     /03:10
SMDhomeI guess parsing VCD file could give way more information though03:10
SMDhomeLet me split predictor as stekern suggested, than test it in a simple manner with printing number of barnches and hit/miss count, than implement perfomance counters and finally maybe writing VCD parser03:14
olofkHmm.. I didn't think of the possibility to parse the VCD file and extract something simpler. The benefit of doing that is of course that all sims output vcd, so it should be more useful03:14
olofkSMDhome: Sure. Let me know if you need any help getting started with FuseSoC03:14
SMDhomeolofk: ok, I'm going to try it today if I don't have too much work to do03:15
-!- _florent__ is now known as _florent_04:46
-!- mithro_ is now known as mithro04:56
shorneinteresting, the values thats incorrectly getting returned (21000001) is the exact same as the trace instruction09:06
SMDwrkstekern: and others, please, take a look09:07
SMDwrkAt least branch_prediction.v could be built with iverilog and my patch. Will run soc later this evening09:09
-!- rah_ is now known as rah13:13
stolarwhat is the difference beetwen instruction l.div and l.divu?14:07
wallentootherwise the MSB is treated as sign14:10
wallentoyou can find the whole instruction set here:
stolarwallento: maybe you know what does mean: or1k_mstats.byteadd++; from the end of l.add instruction
shornestolar: the mstats struct is used to store statistics. It seems that is used to store the add instruction statistics16:38
shornebut to me it looks broken16:38
shornei.e. those stats are now handled by the general instruction stats16:41
stolarHow to generate new opcode for new instruction? Is there some rule? or1ksim17:06
--- Log closed Thu May 19 00:00:13 2016

Generated by 2.15.2 by Marius Gedminas - find it at!