| @juliusb | _franck_: regarding the bitbang JTAG driver, yes I believe I had read that somewhere before. I agree, though, it's at a low level however it'd be interesting to see the difference in speed between the to | 11:44 |
|---|---|---|
| @juliusb | stekern: are you sorting exceptions due to lengthening the pipeline? | 11:47 |
| @juliusb | if so, my sympathies | 11:47 |
| @juliusb | :) | 11:47 |
| @juliusb | stekern: I'll push some patches soon which factor out the tick timer and PIC | 11:48 |
| @stekern | juliusb: mmm, and I understand your sympathy ;) | 11:48 |
| @juliusb | and, as well, all of the CFGRs | 11:48 |
| @stekern | push it, push it | 11:48 |
| @stekern | I'm making progress in the early mornings on the pipeline rework, got a pipeline forwarding problem related to exceptions sorted out this morning | 11:49 |
| @stekern | tests up to or1200-simple are passing | 11:49 |
| @juliusb | nice :) | 11:50 |
| @juliusb | so, ok you'll need to hold my hand again | 11:50 |
| @juliusb | i'm ona branch | 11:50 |
| @juliusb | locally | 11:50 |
| @juliusb | from the openrisc/mor1kx repo | 11:50 |
| @juliusb | it's called spr-unit-splitout | 11:50 |
| @stekern | still haven't pulled your latest mor1kx-devenv with the new tests though | 11:50 |
| @juliusb | to push to openrisc do I just do git push spr-unit-splitout openrisc/masteR? | 11:50 |
| @stekern | git push openrisc spr-unit-splitout:master | 11:52 |
| @juliusb | hmm OK | 11:52 |
| @juliusb | that's not obvious :) | 11:52 |
| @stekern | it is ;) | 11:53 |
| @stekern | kinda | 11:53 |
| @juliusb | haha | 11:53 |
| @juliusb | ok pushing | 11:53 |
| mor1kx | [mor1kx] juliusbaxter pushed 7 new commits to master: http://git.io/3b4Gdw | 11:53 |
| mor1kx | mor1kx/master ef17b75 Julius Baxter: cappuccino: put tick timer and PIC in own modules | 11:53 |
| mor1kx | mor1kx/master 5a81a79 Julius Baxter: ctrl_espresso: replace PIC logic with module | 11:53 |
| mor1kx | mor1kx/master 1fa7b5b Julius Baxter: ctrl_espresso: replace tick timer logic with module | 11:53 |
| @juliusb | oh no! | 11:53 |
| @stekern | the syntax is: git push <remote> <src-branch>:<dest-branch> | 11:53 |
| @juliusb | ah right OK | 11:54 |
| @juliusb | cool | 11:54 |
| @juliusb | what happened to mr mor1kx? | 11:54 |
| @stekern | he's a hit'n'runner :) | 11:55 |
| @juliusb | ah right :) | 11:56 |
| @juliusb | speaking of, I'll have to hit you with that patch and run myself, back later | 11:56 |
| @stekern | ;) see you | 11:57 |
| @stekern | it's nice cleanup btw | 12:09 |
| @stekern | +a | 12:09 |
| @juliusb | and everything still works :) | 12:33 |
| @juliusb | so if you update mor1kx-dev-env you'll see 2 new tests, or1k-intloop and or1k-tickloop | 12:38 |
| @juliusb | cappuccino fails one or both, I can't recall, due to the incorrect EPCR being saved | 12:39 |
| @juliusb | it also fails the DSX test, I don't know why | 12:39 |
| @juliusb | not the same reason I think | 12:39 |
| @juliusb | so on a branch currently the cappuccino deasserts the i'm-in-a-delay-slot signal when the fetch stage takes the new branch target | 12:40 |
| @stekern | yeah, I'll take a look at that when I pass all the other tests | 12:41 |
| @stekern | might be that it just works then :) | 12:41 |
| @juliusb | but, if the exception occurs around there (while we're fetching the instruction at the address we're bracnhing to) the EPCR should be the address we're branching to, but instead it takes the address of the delay slot | 12:41 |
| @stekern | branch target/detection have already got some changes | 12:41 |
| @juliusb | ok cool | 12:41 |
| @juliusb | I had come up with a patch (basically detecting that situation) but it got lost in my tree :-S | 12:42 |
| @juliusb | i committed it to my repo | 12:42 |
| @juliusb | and I wasn't on a branch | 12:42 |
| @juliusb | and now I can't find it again | 12:42 |
| @stekern | ah, ok | 12:42 |
| @juliusb | so I had checked out a remote branch | 12:42 |
| @juliusb | but not branched it locally | 12:42 |
| @juliusb | and committed, and then it ust got lost when I branched away | 12:43 |
| @juliusb | it said I was in that (no branch) state or whatever | 12:43 |
| @juliusb | meh | 12:43 |
| @juliusb | it wasn't massive change, but it sucks how git does that, and for git retards like me it can be scary haha | 12:43 |
| @stekern | I've seen some odd behaviour with ppc while reworking | 12:43 |
| @juliusb | OK | 12:43 |
| @stekern | could be related to that, but that could also be related to my rework | 12:44 |
| @juliusb | cool | 12:47 |
| @juliusb | so my next set of work will involve setting up the versioning stuff correctly | 12:48 |
| @juliusb | i want to put the relevant bits in the architecture spec (update it according to what we discussed at ORCONF) | 12:48 |
| @juliusb | and then put in the appropriate stuff to the mor1kx | 12:48 |
| @juliusb | hence the nice factoring of the cfgr SPRs | 12:48 |
| @juliusb | that can be done easily | 12:48 |
| @juliusb | well, relatively easily | 12:49 |
| @juliusb | and then i'd like to release | 12:49 |
| @stekern | nice | 12:52 |
| jonibo | juliusb: git reflog is your friend if you end up branching away from an unnamed head... it shows you all the commits that you've had at the HEAD of your tree, from most to least recent... it's just a matter of doing a 'git log <commit>' on all the commits in that list until you find your patch | 12:53 |
| @juliusb | ahhh ok cool thanks jonibo ! | 12:54 |
| @olofk | Being sick sucks! I thought I would get loads of things done on orpsoc, but I'm just sleeping all the time :( | 15:01 |
| LoneTech | agreed. get well soon | 15:20 |
| @olofk | Thanks LoneTech | 15:25 |
| @juliusb | haha, yeah i know how you feel olofk , take it easy man, orpsoc will get done | 15:38 |
| @stekern | juliusb (and olofk): I've been thinking about a different approach to the instruction tracing | 18:35 |
| @stekern | what about creating a (synthesizable) rtl module that is doing the snooping, that can then output the necessary information in a "binary format" that a parser can feed to or1ktrace | 18:37 |
| @stekern | that'd be pretty cool, since then you could choose to do (small) traces in real hardware | 18:38 |
| @stekern | and log them to blockram and dump them | 18:38 |
| @juliusb | oh yes, thatd be cool | 18:54 |
| @juliusb | could also have things like l.nops loggable via that, too | 18:54 |
| @juliusb | it wouldn't be easy though | 18:55 |
| @juliusb | although, maybe it would | 18:55 |
| @juliusb | what i'm doing now is almost synthesisable (just using hierarchical references) | 18:55 |
| @juliusb | replace the get-gpr function with something which knows what bus the outputted register value will be on | 18:56 |
| -!- jeremy_bennett is now known as jeremybennett | 19:00 | |
| @stekern | juliusb: yeah, that's what got me started thinking along those lines, you've done most of the grunt work already ;) | 19:01 |
| @stekern | the l.nops 8 and l.nops 9 I'd find extremely usable to be able to use on real hw | 19:01 |
| @stekern | *l.nop | 19:02 |
| @juliusb | but even the ability to sort of have a "debug" printing interface, like l.nop 0x2 but have that go to the trace output | 19:02 |
| @juliusb | that would be bloody handy | 19:02 |
| @juliusb | you'd just need to figure out a reasonably compact way of storing that in some block RAMs for dumping off later | 19:02 |
| @juliusb | because you'll potentially have (for a load/store op), 32-bits of binary plus 32-bits of calculated address plus 32-bits of data-bus result | 19:04 |
| @juliusb | best case you just have 32-bits of binary for the instruction | 19:04 |
| @juliusb | oh, PC too | 19:04 |
| @juliusb | so, best case is 64-bits of stuff per cycle | 19:04 |
| @juliusb | anyway, you may be doing up to 128-bits per cycle into a RAM, but most likely just 96 | 19:05 |
| @juliusb | then you need a way to get that off fast | 19:05 |
| @juliusb | or, is this just a logger, turn on and turn off | 19:05 |
| @juliusb | turn on and run until full maybe | 19:05 |
| @juliusb | yeah, that'd be a handy mode | 19:05 |
| @juliusb | that'd be a fun project | 19:06 |
| @juliusb | if you have ethernet you could do somethign which is compatible with the OpenCores MAC and provides DMA to the buffer memory from the Wishbone bus | 19:10 |
| @juliusb | actually, that would be perfect | 19:10 |
| @juliusb | make sure that memory is readable from the bus, then you could even dump it via GDB | 19:10 |
| @juliusb | or have something which adds on IP headers and sends it out to whatever IP you want | 19:11 |
| @juliusb | but the simpler and still very useful solution is just some memory which you enable with a l.nop and dump to and can then be read via the debug interface later, or, even disassembled by the CPU itself and spat out to the screen | 19:13 |
| @stekern | exactly, I've had that kind of thing, logging signals and a wb-if and the cpu dumps it via uart | 19:17 |
| @juliusb | olofk: I've looked over the mor1kx-dev-env patch for the monitor trace file output, it all looks good | 19:40 |
| @juliusb | I'll apply it ASAP | 19:40 |
| @olofk | Yeah, I'll been thinking about that kind of hardware tracing too. Dump to ethernet, pci, or whatever bus is available | 19:52 |
| @olofk | A bit of huffman or RLE would be nice too. I guess that could decrease the bandwidth quite a bit | 19:54 |
| @juliusb | ya there's a lot of zeros in or1k instructions | 20:49 |
| @juliusb | it would be interesting to do a simple RLE encoding thing for zeroes on the or1k instructino set | 20:49 |
| @juliusb | well, on or1k binary | 20:50 |
| pgavin | hey guys | 21:15 |
| @olofk | hi pgavin | 22:31 |
| @juliusb | pgavin: hey man! | 22:58 |
| @juliusb | been a while | 22:58 |
| ams | juliusb: beer? | 23:31 |
| @juliusb | ams: does the pope have a balcony? | 23:48 |
| ams | juliusb: I wouldn't know, but I hope he has beer. | 23:49 |
| * juliusb agrees | 23:49 | |
| ams | (or at least red wine) | 23:49 |
| ams | Sleep, cheers! | 23:49 |
| @juliusb | later mate | 23:49 |
| @juliusb | So I'm finally sacrificing my development time to read up on some of this git stuff | 23:50 |
| ams | Nice.. | 23:50 |
| ams | I'm trying to prioritise and see if I can do that gdb stuff... | 23:50 |
| @juliusb | Ah no worries man, has anyone given you the steer to our port source? | 23:51 |
| ams | I uhm, don't remeber.. | 23:51 |
| ams | I checked out some repo, or1k-src/gcc or something .. | 23:51 |
| @juliusb | My git problem was that I keep checking out the remote branch (non-local branch) and not creating a local branch, then working on it, and the repo is then in detatched head state | 23:51 |
| @juliusb | ah yes, the git one on github.com/openrisc | 23:51 |
| ams | git is a bit tricky ... | 23:52 |
| ams | You reading one of the more fun pieces on git? | 23:52 |
| ams | http://eagain.net/articles/git-for-computer-scientists/ | 23:52 |
| @juliusb | cool, if you want to nkow more about the gdb port (I believe pgavin had a bit of a port update under way but it hasn't seen the light day of yet, I could be wrong though) | 23:52 |
| ams | Will do! | 23:53 |
| @juliusb | this is what has enlightened me: http://sitaramc.github.com/concepts/detached-head.html | 23:53 |
| ams | Nod.. i tend to use detached head's for lots of experimental stuff. | 23:54 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!