| --- Log opened Wed Jun 25 00:00:49 2014 | ||
| wallento | stekern: will continue the asynchrounous communication :) | 06:38 |
|---|---|---|
| wallento | the implementation does not necessarily need to stall the pipeline on a snoop hit | 06:39 |
| wallento | it writes the tag memory and the cache state machine is accordingly changed to stall the pipeline only if there is a conflict | 06:40 |
| wallento | this works easily for a read and an invalidation, refill is not a problem at all | 06:40 |
| wallento | the only left is writes | 06:40 |
| wallento | here the problem i described yesterday comes up, but it is more an LSU thing than a pipeline thing I am sure now | 06:41 |
| wallento | the issue is obvious when using the normal tag memory | 06:42 |
| wallento | if you are sure we don't want to follow this any more (always extra snoop memory, maybe with the option OPTION_CACHE_SNOOP == "ENABLED") then it works now. I can remove all code that is related to tag memory multiplexing and we are fine, but I can also keep it in and continue documentation and add comments why the tag memory multiplexing did not work | 06:44 |
| wallento | regarding the documentation: I will continue my large comment on top with everything I understood now regarding the cpu->lsu->cache interfaces, hopefully you can check it for correctness :) | 06:45 |
| wallento | finally one suggestion: lets make operator precedence explicit. It always needs extra thinking to check what a | b & c & !d means now, especially multiline assignments should also be structured (using brackets to logically group statements). I think that makes changing the code for an outsider much easier | 06:46 |
| wallento | stekern: I did a clean restart here: https://github.com/wallento/mor1kx/tree/wip_coherency_simple | 08:28 |
| wallento | only with extra tag memory | 08:28 |
| wallento | I will continue tomorrow, I think I may have missed small pieces, but this should be generally it | 08:28 |
| wallento | With the elf I uploaded, the first snoop hit exactly happens during a sequence of four writes @144.18 us. At the moment one is simply lost, maybe we can take up the discussion at this state then, maybe we can also arrange a time where we both are online :-D | 08:30 |
| stekern | "if there is a conflict" isn't there always a conflict? | 08:38 |
| stekern | I mean, there's only one write port on the tag mem, and you write to it on every cycle | 08:38 |
| stekern | operator precedence, personally, I think the brackets make the code harder to read... | 08:40 |
| stekern | that said, there are maybe some multiline statements that would be more clear with brackets somewhere | 08:42 |
| stekern | and cases that the statements can be broken down into smaller sub-statements for that matter too | 08:45 |
| wallento | conflict is only if there is a cache access, I mean you only should stall pipeline if there is also a cache access | 08:50 |
| wallento | I assume lsu_valid_o is only used when there is an lsu access, then you are right | 08:51 |
| stekern | ah, yes. of course | 08:52 |
| stekern | and it is | 08:52 |
| wallento | perfect | 08:52 |
| stekern | I tried that on your old code, but it didn't quite work though | 08:52 |
| wallento | by simple &ing lsu_valid_o and snoop_hit I get the same issue as before | 08:52 |
| wallento | meaning I need to handle addresses differently, what should be possible | 08:53 |
| wallento | _but_ | 08:53 |
| stekern | http://pastie.org/9322111 | 08:53 |
| wallento | I did this: assign lsu_valid_o = (lsu_ack | access_done) & !tlb_reload_busy & !dc_snoop_hit; | 08:54 |
| wallento | now to my but | 08:54 |
| wallento | we will get a very long critical path | 08:54 |
| wallento | I can see that req_i goes down immediately, so it is combinational with lsu_valid | 08:55 |
| stekern | the problem is that the writes to storebuffer will go through if you just connect it straight to lsu_valid | 08:55 |
| wallento | ah, yes, I also put it into store_buffer_write | 08:55 |
| wallento | sorry | 08:56 |
| stekern | yeah, at least since you use stb to determine the snoop | 08:56 |
| wallento | the critical path starts in pipeline, depends on an expensive comparison and goes back into the pipeline and back to cache | 08:56 |
| wallento | it seems now, but I need to think it through | 08:56 |
| stekern | you shouldn't really do that, connect ack & stb | 08:56 |
| wallento | ack & stb? | 08:57 |
| wallento | in the bus? | 08:57 |
| stekern | yeah, but I realised that that isn't related to the critical path you are speaking about | 08:58 |
| stekern | the critical path shouldn't be any more critical than the current dc_ack path, no? | 08:59 |
| wallento | ack | 08:59 |
| wallento | ;) | 08:59 |
| stekern | =) | 08:59 |
| stekern | but yeah, it's gonna make more critical paths, for sure. Don't think you can avoid that though | 09:00 |
| wallento | maybe we can handle stuff more complex in cache to break the critical path | 09:00 |
| wallento | write down which are early and which are late signals | 09:01 |
| wallento | and req_i seems the very latest and should not depend on the snoop comparison, I assume | 09:01 |
| stekern | I think even snoop_hit could be registered | 09:01 |
| stekern | I mean, it's not like cache coherency can be expected to be atomic, right? | 09:02 |
| wallento | yes, if the current write address is registered then accordingly | 09:02 |
| stekern | yes, of course | 09:02 |
| wallento | no, but is more the problem of that the pipeline advances, but the write did not properly take effect | 09:02 |
| wallento | then we can delay the next write implicitly and take the old address | 09:03 |
| wallento | this should be possible | 09:03 |
| stekern | right, but that's just a bug that needs fixing ;) | 09:03 |
| wallento | yep | 09:03 |
| wallento | it is something in the WRITE: ... in the sequential part :-D | 09:04 |
| wallento | but I am not sure what ;) | 09:04 |
| stekern | in the lsu or cache? | 09:04 |
| wallento | cache | 09:04 |
| wallento | or in the dc_adr = .. in the LSU | 09:04 |
| wallento | but fortunately it is much easier to develop now without the tag memory multiplexing | 09:05 |
| wallento | i will continue it later tonight, need to do some work now :) | 09:06 |
| olofk | I'm considering reverting the move of the section submodule to a .py in FuseSoC. It seems to cause a lot of problems for people upgrading and it doesn't really add any value | 11:03 |
| arokux | hi guys, what projects are you currently working on? | 13:09 |
| olofk | arokux: Currently working on removing everything in the house up to one meter that is either sharp or could be swallowed | 13:57 |
| arokux | :) | 13:57 |
| arokux | olofk: and if asked about openrisc? | 13:58 |
| olofk | Not much lately, but extending and bugfixing FuseSoC, making ports for a few new boards and wishbone infrastructure stuff | 13:59 |
| arokux | I see | 14:15 |
| wallento | stekern: First test passes again | 15:43 |
| wallento | [CfE - Call for Elfs] Needs more testing now | 15:44 |
| wallento | ~400 snoop hits for newlib setup, two mallocs and counting on the same cache line | 15:46 |
| olofk | ääǻ' | 15:48 |
| olofk | Sorry. Baby on the keyboard | 15:48 |
| wallento | you have a ǻ on your keyboard? | 15:49 |
| wallento | ;) | 15:49 |
| olofk | Apparently. She has managed to find all kinds of crazy shortcuts and symbols :) | 15:49 |
| wallento | ah, like this turn windows desktop upside down combination grandmas find :) | 15:50 |
| olofk | Exactly like that :) | 16:02 |
| olofk | btw wallento. I think we should start sending out invitations to orconf soon, but you will have to have the final word on how many people we can fit in | 16:03 |
| wallento | we can fit in as many as you want | 16:03 |
| wallento | we should definitely start inviting people | 16:04 |
| wallento | optimal is something around 30-40, as they fit in our seminar room | 16:04 |
| olofk | Sounds reasonable. | 16:04 |
| olofk | I'll prepare some special invitations for the people I wrote down in the mail some time ago, and we can go out with an official invitation and event registration when we get around to that | 16:05 |
| wallento | we can also get an auditorium with arbitrary number of places, as they are mostly free on weekends | 16:06 |
| wallento | but I think a seminar setting is much better | 16:06 |
| wallento | plus there is a coffee machine, table soccer and beer | 16:06 |
| olofk | Yes, most people are probably there both for the talks and to get some work done | 16:06 |
| olofk | WOOHOOO!!!! | 16:06 |
| * olofk is calm now | 16:06 | |
| wallento | there is also a room with 18 computer places on the same floor | 16:07 |
| wallento | and a separate discussion room with 12 places | 16:07 |
| wallento | i think this fits the conference setting well | 16:08 |
| olofk | I think that aiming for 30-40 is a good idea, but it sounds like there are possibly other options if we have seriously under- or overestimated the interest | 16:08 |
| wallento | exactly | 16:08 |
| wallento | I can find an alternative on pretty short notice as it is a non-profit event | 16:09 |
| olofk | That sounds very good | 16:09 |
| olofk | So... we'll start a first round of invitations then. And if someone wants to set up a dedicated site, just ping me and I'll reroute the orconf.org domain there | 16:10 |
| olofk | Bonus points if someone hosts it on an FPGA board running OpenRISC :) | 16:12 |
| olofk | extra bonus points if the web server is written in verilog | 16:13 |
| olofk | sb0: You are on my list of people to invite to orconf, but as I have noticed that you hang around here nowadays I just say that we would be delighted to have you join us either as a presenter or as a regular visitor | 18:28 |
| olofk | That doesn't mean I'm excluding any of you other people in here. You are of course all very welcome to join us | 18:29 |
| sb0 | October in Munich? hmm... I'll have moved to Hong Kong. I'll think about it, though it'll probably be difficult to come. thanks for the invite :) | 18:29 |
| olofk | You mentioned moving there some time ago. Have you settled down now? Is it all you hoped for? ;) | 18:30 |
| sb0 | not yet - but the date is set, July 29 :) | 18:31 |
| olofk | Well, I hope that your future self will enjoy it there then :) | 18:34 |
| Findeton | when/where is it going to take place? | 19:27 |
| Findeton | oh, reading it: october in munich | 19:28 |
| Findeton | well by october I might be living there actually lol | 19:28 |
| olofk | Findeton: Then you have no excuse to miss out :) | 19:34 |
| olofk | I should dust off my book on data structures | 21:33 |
| olofk | juliusb: Nice picture of München :) | 22:16 |
| olofk | I think I can add mail aliases to the orconf.org domain as well. Should we use that perhaps? Like info@orconf.org | 22:18 |
| juliusb | olofk: that's a great idea. I wasn't sure about our personal emails on there | 22:52 |
| juliusb | info@orconf and organisers@ (maybe the American spelling, too, in case Wilson Snyder decides to email us) | 22:52 |
| --- Log closed Thu Jun 26 00:00:51 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!