| --- Log opened Mon Mar 06 00:00:30 2017 | ||
| olofk | stekern: I haven't got to the bottom of it. The testcase is a bit messy, and I'm afraid it might rely a bit on timing and things that were different in orpsocv2 | 07:24 |
|---|---|---|
| stekern | what test is it? | 07:25 |
| olofk | alignillegalinstruction | 07:27 |
| olofk | It never completes | 07:27 |
| olofk | There are five tests right now that never completes, actually | 07:28 |
| olofk | I think the other four rely on intgen being mapped (which I should add to mor1kx-generic) | 07:28 |
| stekern | yeah, I was thinking about the intgen | 07:29 |
| stekern | but if that's not it | 07:29 |
| olofk | Hmm.. I think it's because it doesn't recover from a bad l.jalr | 07:31 |
| olofk | Added l.nop 1 to bisect my way to the failure :) | 07:31 |
| olofk | Debug more later, but I think I'm close now | 07:36 |
| stekern | I think some tests made some assumptions that may not be true with the store buffer enabled | 07:53 |
| stekern | not saying that it's the case here, but worth knowing | 07:54 |
| olofk | stekern: Yeah, I've been thinking about the store buffer too. In addition to the five tests that doesn't complete, I think there are also some that exits with failure | 14:45 |
| olofk | stekern: I think the problem is that mor1kx doesn't abort the wishbone transaction when it receives an err on the wishbone ibus | 14:55 |
| olofk | running with B3_REGISTERED_FEEDBACK at least. Haven't tried the other ones | 15:00 |
| stekern | hmm, do you mean that it continues the request after the err? | 15:02 |
| stekern | that sounds like a bug | 15:02 |
| stekern | err should act as an ack | 15:03 |
| olofk | ah wait. | 15:51 |
| olofk | My interconnect keeps err raised as long as cyc/stb are raised. I guess both are waiting for the other to do something | 15:52 |
| olofk | I somewhat suspect that my interconnect is at fault here. Anyone knows straight away how err is supposed to work in wb? | 15:52 |
| olofk | Nahh.. I think the error is in mor1kx anyway. Looking at the wb spec, I find two things | 15:57 |
| olofk | 1. err must be asserted and negated in response to stb | 15:58 |
| olofk | 2. masters must support cores which have ack always asserted. Doesn't say anything about err, but I'd say it's analogous | 15:58 |
| olofk | Any feedback appreciated :) | 16:01 |
| olofk | But I'm leaning towards converting cpu_err into a edge-triggered signal inside of mor1kx | 16:02 |
| olofk | hmm.. not sure that helps here. I think the problem is that the fetch unit gets stuck in IC_REFILL | 16:28 |
| olofk | ...which probably makes the whole thing a bit more complicated | 16:29 |
| olofk | What's the solution here? Can we abort a refill somehow? | 16:32 |
| -!- Netsplit *.net <-> *.split quits: LoneTech | 16:35 | |
| olofk | Now I'm leaning towards just filing a bug and leave it :) | 16:36 |
| ZipCPU | olofk: Solution: On a cache line fill, if you get a bus error, void the entire cache line and end the bus request. Mark the cache as invalid due to an error, and wait to be told to do something different. ;) | 16:41 |
| olofk | ZipCPU: Yeah, that's what I would go for too. Just haven't got a clue how hard it would be to fix with the current code | 16:50 |
| ZipCPU | I can offer you an example of a cache that does it ... ;) | 16:51 |
| olofk | haha | 16:51 |
| ZipCPU | Would you believe I was dealing with a similar issue with the ZipCPU earlier today? | 16:51 |
| ZipCPU | It's not that uncommon. | 16:52 |
| olofk | Giving up is not that uncommon either :) | 17:24 |
| ZipCPU | On a problem this easy? Never! :D | 17:36 |
| ZipCPU | Come on, there are plenty of harder problems to work on. | 17:36 |
| ZipCPU | Let's see ... every "way" within mor1kx_icache.v would need an error flag associated with it, indicating the attempt to load that cache line ended in error ... | 17:38 |
| ZipCPU | The "way" needs to be marked "valid" on the first error, lest you try again. | 17:39 |
| olofk | I got interested in the refill_valid vector. If that is zeroed out, I think it will refetch from memory | 17:40 |
| ZipCPU | But that's the problem ... if it refills from an invalid address, and you zero it, and it goes to refill from an invalid address, then it gets into a loop tying up your bus. | 17:40 |
| olofk | But, it also needs to give up trying to fetch from that address and instead read from the address defined in the exception vector | 17:40 |
| olofk | Seems like we agree :) | 17:40 |
| olofk | Got to sleep now. Will have a handful of kids to take care of early in the morning | 17:41 |
| ZipCPU | Yeah ... it also seems like there's no *error* line coming out of the icache to tell the CPU that something's wrong with the cache line. | 17:41 |
| ZipCPU | 'nite. | 17:41 |
| --- Log closed Tue Mar 07 00:00:31 2017 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!