--- Log closed Tue Nov 27 06:00:32 2012 | ||
--- Log opened Tue Nov 27 06:00:45 2012 | ||
-!- Irssi: #openrisc: Total of 20 nicks [1 ops, 0 halfops, 0 voices, 19 normal] | 06:00 | |
-!- Irssi: Join to #openrisc was synced in 23 secs | 06:01 | |
stekern | bah, this is annoying, I'm trying to run the stuff on real metal, and couldn't even get a simple hello world working | 10:10 |
---|---|---|
stekern | so I threw in a signaltap and now it works... | 10:10 |
stekern | ah, running some other code in between gets it in the same kind of state | 10:19 |
@juliusb | yeah we need some good reset to launch code, that's always a problem | 12:00 |
stekern | seeing all kinds of inconsistent behaviour | 12:51 |
stekern | loads that has 1 bit flipped etc | 12:51 |
stekern | hmm, u-boot gives some fun info at least | 12:56 |
stekern | unhandled exception, 0x500 tick timer | 12:56 |
stekern | it at least prints something ;) | 13:00 |
@juliusb | :) better than nothing | 13:13 |
@juliusb | but i hate that bad behaviour from a newly hacked-together CPU | 13:14 |
stekern | yeah, you start chasing some bug and when you thought you've almost caught it, if you just could get that extra little piece of information. so you change something to get that and the bug have changed completely... | 13:45 |
stekern | hmm, are the serial shifters default now? | 13:45 |
stekern | I'm seeing long stalls on srai and slli | 13:45 |
stekern | but I think I see the bug now at least, looks like a hazard bug | 13:55 |
stekern | rfa_o has the right value during the first cycle of an stall by the fetcher, then it changes to something wrong | 13:56 |
@juliusb | stekern: good question about the serial shifters. if we had some implementation-specific registers we could put a bit in to indicate what the configuration is and dump it out of the synthesised build to see exactly how it was configured :) | 14:05 |
@juliusb | I don't think they're default, though, no | 14:05 |
@juliusb | barrel should be | 14:05 |
stekern | I'll check it, could be that it's fetch that just happened to stall at the same time | 14:07 |
stekern | I'm thinking about the "random" bus access times again | 14:09 |
@juliusb | oh yes | 14:09 |
@juliusb | for testing? | 14:09 |
stekern | it would be really good to have them while running tests | 14:09 |
stekern | I'm thinking something in the line of: first access 1-cycle delay, second access 2-cycle delay etc | 14:10 |
@juliusb | sure, it's easy enough to put into the RAM model I believe | 14:10 |
stekern | it will be deterministic, but probably will shake out bugs | 14:10 |
stekern | exactly, very simple | 14:10 |
@juliusb | that sounds good - my solution uses an LFSR-based delay randomisation | 14:11 |
stekern | like, go up to ten cycle delay as max and start over at 0 | 14:11 |
@juliusb | probably another nice feature would be to add built-in latency generation patterns | 14:11 |
stekern | you already have an LFSR delay randomizer? | 14:13 |
@juliusb | yes | 14:14 |
stekern | in mor1kx-dev-env? | 14:15 |
stekern | yes you do | 14:16 |
@juliusb | https://github.com/juliusbaxter/mor1kx-dev-env/blob/master/rtl/verilog/ram_wb/ram_wb_b3.v#L74 | 14:16 |
@juliusb | just switch on that parameter, and it should work | 14:16 |
@juliusb | haven't fully tested it for a few weeks, I think, though | 14:16 |
stekern | I really should update my mor1kx-dev-env, shouldn't I? | 14:17 |
stekern | :) | 14:17 |
@juliusb | ah, the comment on line 327 says "Random ACK negation" which is what it was used for initially | 14:17 |
@juliusb | but now it's a random access latency for bursts | 14:18 |
@juliusb | well, for any access actually, but all appear to be bursts | 14:18 |
@juliusb | it would be easy enough to add on another system to add a base delay to that\ | 14:18 |
stekern | true | 14:22 |
stekern | that would shake stuff around a bit | 14:22 |
@juliusb | you're running with caches on the whole time, too? | 14:23 |
stekern | mmm, whenever the caches are enabled | 14:30 |
stekern | interesting or1k-shortbranch fails now, while it passed before I updated mor1kx-dev-env | 14:30 |
stekern | ah, but you've done "Lots of additions." to that ;) | 14:33 |
stekern | https://github.com/juliusbaxter/mor1kx-dev-env/blame/39bb46d4389df1d57abbfccf34c1373cecea8e89/sw/tests/or1k/sim/or1k-shortbranch.S | 14:33 |
@juliusb | oh yes a lot of additions to the mor1kx-dev-env sw test library :) | 14:34 |
@juliusb | more torture for the cores | 14:34 |
stekern | it's great | 14:34 |
stekern | I have a little lsu test too | 14:34 |
stekern | that cbasic test is good torture, but should really be shopped down to several smaller ones | 14:36 |
stekern | I noticed it's a pain when that fails | 14:37 |
* juliusb agrees | 14:37 | |
stekern | *chopped | 14:37 |
* juliusb got that :) | 14:37 | |
stekern | shopping is for the wife ;) | 14:37 |
@juliusb | there's nothing to say she couldn't also refactor cbasic :) | 14:39 |
@juliusb | I suspect we'd be quicker though | 14:39 |
stekern | nah, she's really fast | 14:40 |
stekern | ... but sloppy as hell ;) | 14:40 |
@juliusb | haha | 14:41 |
stekern | nice, with the latest hazard fix u-boot boots | 14:41 |
stekern | speaking about the wife, I'm pretty proud to say that she's using only open source tools for her profession | 14:42 |
stekern | gimp, inkscape, libre office etc | 14:42 |
@juliusb | no way! | 14:42 |
@juliusb | very cool | 14:43 |
stekern | she even turned down an "intern" since she had no gimp experience, only photoshop ;) | 14:43 |
@juliusb | haha, hilarious | 14:43 |
@juliusb | probably not for the prospective intern, they'll learn hopefully | 14:43 |
@juliusb | bbl | 14:44 |
stekern | yup | 14:44 |
stekern | same here | 14:44 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!