| --- Log opened Wed May 18 00:00:11 2016 | ||
| shorne | hmm, strange maybe this is some bug in the simulator. the instruction found causing issue is `l.lwz r3,0(r14)` | 00:27 |
|---|---|---|
| shorne | The result is r3 is loaded with 0x21000001 | 00:27 |
| shorne | But, it I look at memory location r14, it should be 0x00000003 | 00:28 |
| shorne | i.e. (gdb) x/1xw $r14 | 00:28 |
| shorne | 0x7fd570: 0x00000003 | 00:29 |
| shorne | something strange going on there | 00:29 |
| shorne | Next instruction `l.lwz r4,4(r14)`, has no issue | 00:30 |
| shorne | getting the same results on or1ksim | 00:58 |
| stekern | SMDhome: 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 modules | 02:48 |
| SMDhome | stekern: you suggest to move new one to separate file and than instantiate it in that file? | 02:50 |
| stekern | yes, and move the current one into a separate file as well | 02:51 |
| stekern | and let the current file instantiate the correct one according to parameters | 02:52 |
| shorne | like is done for cpu in mor1kx_cpu.v | 02:52 |
| SMDhome | ok, will do | 02:52 |
| stekern | that was my initial plan for the branch predictors, but it felt silly to break it out when there was only one implementation | 02:54 |
| olofk | shorne: Damn tricky, this one. Didn't get the chance to look at your findings yesterday | 02:54 |
| SMDhome | stekern: ok, anything else? | 02:55 |
| shorne | olofk: yeah, I think I got everything working in my patch except varargs. Not looking into varargs until I get the others working | 02:56 |
| shorne | I think variadic will require a bit rewrite | 02:56 |
| shorne | but want to get basics working first | 02:56 |
| shorne | everything is working but that crazy `l.lwz r3,0(r14)` instruction | 02:57 |
| stekern | SMDhome: I didn't look to careful at the implementation yet. | 02:57 |
| SMDhome | ok | 02:57 |
| stekern | But you asked about how to test it? I think I did most of branch prediction testing with fusesoc + verilator | 02:58 |
| stekern | I even had some instrumentation which printed mis-predictions and so forth | 02:58 |
| olofk | stekern: Interesting. Did you implement an instruction tracer, or something specialized to look at predictions? | 03:00 |
| SMDhome | stekern: I have plans to implement perfomance counters system btw. | 03:01 |
| olofk | And was it directly in the verilator tb, or analysing some logs after the sim? | 03:01 |
| stekern | olofk: I have no memory whatsoever how I did it ;) | 03:01 |
| stekern | I remember that I had a dump of # branches and of hits and misses after the simulation ended | 03:02 |
| SMDhome | I 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 |
| olofk | SMDhome: You have the VCD file, which is actually kind of doing that | 03:06 |
| olofk | But it's not a very user-friendly format for just looking at the pipeline perhaps | 03:07 |
| olofk | Maybe we should just write a small tool that can hook into the CPU and export to json for wavedrom | 03:08 |
| SMDhome | olofk: 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 |
| SMDhome | So it looks like this: /-----* / | 03:10 |
| SMDhome | I guess parsing VCD file could give way more information though | 03:10 |
| SMDhome | Let 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 parser | 03:14 |
| olofk | Hmm.. 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 useful | 03:14 |
| olofk | SMDhome: Sure. Let me know if you need any help getting started with FuseSoC | 03:14 |
| SMDhome | olofk: ok, I'm going to try it today if I don't have too much work to do | 03:15 |
| SMDhome | thanks | 03:15 |
| -!- _florent__ is now known as _florent_ | 04:46 | |
| -!- mithro_ is now known as mithro | 04:56 | |
| shorne | interesting, the values thats incorrectly getting returned (21000001) is the exact same as the trace instruction | 09:06 |
| SMDwrk | stekern: http://pastebin.com/3fJWcbjm and others, please, take a look | 09:07 |
| SMDwrk | At least branch_prediction.v could be built with iverilog and my patch. Will run soc later this evening | 09:09 |
| -!- rah_ is now known as rah | 13:13 | |
| stolar | what is the difference beetwen instruction l.div and l.divu? | 14:07 |
| wallento | u=unsigned | 14:10 |
| wallento | otherwise the MSB is treated as sign | 14:10 |
| wallento | you can find the whole instruction set here: https://github.com/openrisc/doc/raw/master/openrisc-arch-1.1-rev0.pdf | 14:11 |
| stolar | wallento: maybe you know what does mean: or1k_mstats.byteadd++; from the end of l.add instruction https://github.com/openrisc/or1ksim/blob/or1k-master/cpu/or32/insnset.c | 14:42 |
| shorne | stolar: the mstats struct is used to store statistics. It seems that is used to store the add instruction statistics | 16:38 |
| shorne | but to me it looks broken | 16:38 |
| shorne | i.e. those stats are now handled by the general instruction stats | 16:41 |
| stolar | How to generate new opcode for new instruction? Is there some rule? or1ksim | 17:06 |
| --- Log closed Thu May 19 00:00:13 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!