| @juliusb | stekern: I'm just wondering if we really need to split out the SPR units | 01:03 |
|---|---|---|
| @juliusb | probably tick timer and PIC unit would make sense | 01:04 |
| @juliusb | the debug unit is heavily combined with the control unit | 01:04 |
| @juliusb | that's not going to be uniform across pipelines I suspect | 01:04 |
| @juliusb | OK tick timer is easy to do | 01:19 |
| @stekern | juliusb: I share your hesitation about SPR's | 04:48 |
| @stekern | the SPR read/write logic is very pipeline dependent | 04:49 |
| @stekern | when I'm done with what I'm doing now, spr reads will be 1-cycle instructions | 04:50 |
| @stekern | _franck_: you can do all those things, and you have full admin rights to openrisc/openOCD, so you should be able to do all you need there too | 04:53 |
| @stekern | but why would you rename Franck79/openOCD? | 04:53 |
| @stekern | just put what you have now in a seperate branch | 04:54 |
| @stekern | juliusb: hmm, am I confused or did you actually have the wb stage in execute as well? | 06:36 |
| _franck_ | stekern: you're right, I just don't "think git" | 08:57 |
| _franck_ | just created a new branch called next and make it the default branch | 08:58 |
| @stekern | I mostly think like a git ;) | 09:50 |
| @juliusb | stekern: yes, on cappucinno it was basically everything, memory and writeback in execute stage | 13:50 |
| @juliusb | the when t he execute stage was finished there was nothing left for that instruction to do | 13:50 |
| @juliusb | the write into the RF occurred on the "execute stage is done" signal cycle | 13:50 |
| @juliusb | stekern: SPR write/read logic waits can be handled with the ACK on the internal SPR bus | 13:51 |
| @juliusb | anyway, last night I got the PIC and TT units in nice little modules, | 13:51 |
| @juliusb | i was playing with cappuccino core | 13:51 |
| @juliusb | i found some bugs :) | 13:51 |
| @juliusb | trying to fix them | 13:51 |
| @juliusb | mainly the value of EPCR when you get a PIC or TT exception when you're branching | 13:51 |
| @juliusb | i have a nice littlet est I added, or1k-intloop and or1k-tickloop I think | 13:52 |
| @juliusb | it was a test of the prontoespresso "sleep" functionality | 13:52 |
| @juliusb | like, when we get a l.j 0 instruction, I shut down the fetch unit (in pronto) | 13:52 |
| @juliusb | but, for cappuccino it's failing | 13:52 |
| @juliusb | I found a fix, but it broke other things :-/ | 13:55 |
| @juliusb | so, still hacking on it | 13:55 |
| @stekern | cool | 14:05 |
| @stekern | so what do you reckon, should I break this stuff I'm working on now as a new pipeline implementation or "upgrade cappuccino"? | 14:06 |
| @stekern | caffe latte would be the obvious name :) | 14:06 |
| @stekern | I guess it depends how it ends up resource wise | 14:07 |
| @stekern | what would the EPCR end up as in the bug you are looking at? | 14:10 |
| @juliusb | stekern: it ends up as the PC of the delay slot I think | 14:47 |
| @stekern | ah, I haven't updated mor1kx-devenv in a while | 16:03 |
| @stekern | in a long while it seems :/ | 16:03 |
| @stekern | but that sounds like a good catch | 16:13 |
| @stekern | I just realized that the TRACE stuff probably doesn't work anymore for me | 17:10 |
| @stekern | at least not the register values, since they are not written back at the same time any more | 17:11 |
| @juliusb | ya | 17:41 |
| @juliusb | do the trick I put into espresso | 17:41 |
| @juliusb | snoop the result bus going into the RF module when the RF write signal is high | 17:41 |
| @juliusb | actually, you should probably check the write address, see if that is the one you want, if so snoop that result bus, otherwise read from the RF | 17:42 |
| @stekern | sounds reasonable, I'll have a look when it's starting to remotely to work | 17:50 |
| @stekern | right now I need to wrestle the execute bypass logic into submission | 17:51 |
| @stekern | but since I now have the alu result registered I should be able to use that instead of the one that is saved in rf | 17:55 |
| @juliusb | hmm, quite probably, yes | 17:56 |
| @juliusb | I was contacted by some Indian guys who put this paper together: http://dl.acm.org/citation.cfm?id=2183322 | 18:35 |
| @juliusb | out of interest | 18:35 |
| @juliusb | It's a hot one, Downloads (6 Weeks): 0 | 18:35 |
| @juliusb | Ah this is a direct link to the PDF: http://www.wseas.us/e-library/conferences/2012/CambridgeUK/SEPED/SEPED-15.pdf | 18:36 |
| @olofk | I haven't got a clue what that abstract is about | 20:06 |
| @olofk | or is it some kind of out-of-order algorithm? | 20:08 |
| @olofk | Seems like they managed to reduce some matrix test time by 30%. That's good | 20:14 |
| @juliusb | some bit of logic they wacked into the execute stage of the OR1200 | 20:30 |
| @stekern | very strange results | 21:04 |
| @stekern | what is that dhrystone vs coremark graph supposed to show? | 21:04 |
| @stekern | I'm probably reading table 3 wrong, but to me that looks like worse performance | 21:08 |
| @stekern | and why did they use gcc 3.4.4? (where did they even dig that out?) | 21:10 |
| @stekern | yay, execute bypass works | 21:25 |
| @stekern | now I just need to handle load->execute | 21:26 |
| @olofk | _franck_, I'm adding your jtag_vpi stuff to orpsocv3 now, but I'm getting Ignoring packet error, continuing... in GDB. Any clues? | 22:03 |
| @olofk | There's a lot of traffic between openOCD and the jtag tap even when gdb is not connected. Is that normal? | 22:25 |
| @olofk | hmm... no lucj with adb_dbg_if either | 22:44 |
| @olofk | s/lucj/luck | 22:45 |
| _franck_ | olofk: traffic is normal because openOCD is pulling the debug interface | 23:16 |
| _franck_ | did you try to did you try to clone this repo git://github.com/Franck79/orpsocv2.git | 23:17 |
| _franck_ | and try make rtl-tests TEST=or1200-led VCD=1 VPI=1 ? | 23:18 |
| _franck_ | then you can test your openOCD /gdb setup | 23:18 |
| @olofk | _franck_: Yeah, I should probably do that first | 23:43 |
| @olofk | I got busy trying to release a stable API for orpsocv3 core descriptions instead | 23:44 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!