IRC logs for #openrisc Monday, 2017-03-06

--- Log opened Mon Mar 06 00:00:30 2017
olofkstekern: 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 orpsocv207:24
stekernwhat test is it?07:25
olofkalignillegalinstruction07:27
olofkIt never completes07:27
olofkThere are five tests right now that never completes, actually07:28
olofkI think the other four rely on intgen being mapped (which I should add to mor1kx-generic)07:28
stekernyeah, I was thinking about the intgen07:29
stekernbut if that's not it07:29
olofkHmm.. I think it's because it doesn't recover from a bad l.jalr07:31
olofkAdded l.nop 1 to bisect my way to the failure :)07:31
olofkDebug more later, but I think I'm close now07:36
stekernI think some tests made some assumptions that may not be true with the store buffer enabled07:53
stekernnot saying that it's the case here, but worth knowing07:54
olofkstekern: 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 failure14:45
olofkstekern: I think the problem is that mor1kx doesn't abort the wishbone transaction when it receives an err on the wishbone ibus14:55
olofkrunning with B3_REGISTERED_FEEDBACK at least. Haven't tried the other ones15:00
stekernhmm, do you mean that it continues the request after the err?15:02
stekernthat sounds like a bug15:02
stekernerr should act as an ack15:03
olofkah wait.15:51
olofkMy interconnect keeps err raised as long as cyc/stb are raised. I guess both are waiting for the other to do something15:52
olofkI somewhat suspect that my interconnect is at fault here. Anyone knows straight away how err is supposed to work in wb?15:52
olofkNahh.. I think the error is in mor1kx anyway. Looking at the wb spec, I find two things15:57
olofk1. err must be asserted and negated in response to stb15:58
olofk2. masters must support cores which have ack always asserted. Doesn't say anything about err, but I'd say it's analogous15:58
olofkAny feedback appreciated :)16:01
olofkBut I'm leaning towards converting cpu_err into a edge-triggered signal inside of mor1kx16:02
olofkhmm.. not sure that helps here. I think the problem is that the fetch unit gets stuck in IC_REFILL16:28
olofk...which probably makes the whole thing a bit more complicated16:29
olofkWhat's the solution here? Can we abort a refill somehow?16:32
-!- Netsplit *.net <-> *.split quits: LoneTech16:35
olofkNow I'm leaning towards just filing a bug and leave it :)16:36
ZipCPUolofk: 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
olofkZipCPU: 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 code16:50
ZipCPUI can offer you an example of a cache that does it ... ;)16:51
olofkhaha16:51
ZipCPUWould you believe I was dealing with a similar issue with the ZipCPU earlier today?16:51
ZipCPUIt's not that uncommon.16:52
olofkGiving up is not that uncommon either :)17:24
ZipCPUOn a problem this easy?  Never!  :D17:36
ZipCPUCome on, there are plenty of harder problems to work on.17:36
ZipCPULet'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
ZipCPUThe "way" needs to be marked "valid" on the first error, lest you try again.17:39
olofkI got interested in the refill_valid vector. If that is zeroed out, I think it will refetch from memory17:40
ZipCPUBut 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
olofkBut, it also needs to give up trying to fetch from that address and instead read from the address defined in the exception vector17:40
olofkSeems like we agree :)17:40
olofkGot to sleep now. Will have a handful of kids to take care of early in the morning17:41
ZipCPUYeah ... 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!