IRC logs for #openrisc Tuesday, 2014-12-02

--- Log opened Tue Dec 02 00:00:53 2014
stekernwhy do I suck at writing Makefiles so much?11:34
olofkWhy does writing Makefiles suck so much?11:55
stekernyeah, that too...11:58
olofkSo basically you suck at doing sucky things. I think that might be a good thing, but I'm not sure12:19
olofkOk,  for writing, I can see how lowering stb would work, but what about reads?13:00
olofkIf ack is always asserted, how can the master know when to expect valid data?13:01
olofk...or did I manage to confuse myself again now?13:01
stekernack can't be always asserted13:07
olofkoh right. Of course. The slave knows when data is valid13:18
stekernthere is one case where ack can be asserted when stb is deasserted though13:22
stekernif you deassert stb in the middle of a burst, the slave is allowed to ack that terminated access13:22
olofkstekern: Yes, that was the case I was thinking about20:06
stekernolofk: but, is that a problem though? it should have ack deasserted on the coming cycle after that then20:32
olofkBut the slave will keep ack asserted, right?20:45
stekernno, I don't think you are then allowed to keep it asserted the clock cycle after stb has been deasserted20:56
olofkCheck out figure 4-7 in the b3 spec20:57
stekernyou can't implement delayed ack and comb ack at the same time20:58
olofkNot following you here20:59
olofkcomb ack is for cti=000, right?21:00
stekernno, it's just two different ways of implementing the ack21:02
stekernyou're right, figure 4.7 suggest that the slave can hold ack asserted. I wonder if that's intended to only be valid for constant address burst21:04
olofkThat will work fine for writes even for incremental bursts. It basically says that slave has accepted data on (stb & ack)21:05
olofkIt's trickier for reads, but there aren't any examples of that situation21:06
stekernyeah, I think I was wrong, seems like it's allowed to keep ack asserted as long as cyc is asserted and the previous cti was 001 or 01021:14
stekernso, let's start over... what is the problem with reads?21:16
olofkAnd if I got things right, that would mean that the master doesn't really know when to latch data from the slave21:16
stekernwhy not? it can use the registered value of its own stb and the ack from the slave21:17
olofkI think you're right21:18
stekernwhen you deassert stb in an incrementing burst, you should hold the address from the previous cycle21:19
olofkTrue, and I will also not check for acks any cycle following a deasserted stb21:29
olofkBecause those will not indicate valid data21:29
stekernwell, they actually do21:30
stekerndon't they?21:30
stekernhmm, maybe this is more complicated than I first thought.21:31
stekernthe deasserted stb is an indication from the master that it can't handle the data that the slave (may or may not) ack at that cycle21:33
stekernwhen stb get asserted again, it accepts the data the slave is providing (if the slave is asserting ack)21:34
stekernassuming reads here21:34
olofkYes, assume reads. Writes aren't a problem21:47
olofkI have two other options for my upsizer use case. 1) Always use cti=111 since there will always be a gap between two reads, or 2) just route read acceses through asynchronously21:51
olofkDo you have a feeling for how much work it would take to implement 64 bit buses for mor1kx btw? As long as we are using caches, I guess it would be quite straight-forward to halve the number of accesses21:53
stekernthe biggest problem is to solve how to write into the cache I think22:05
olofkWrite from the CPU?22:09
stekernolofk: I mean during refill23:03
stekernsince the cache is a dpram, I'd need one 64-bit port and one 32-bit port23:04
--- Log closed Wed Dec 03 00:00:54 2014

Generated by 2.15.2 by Marius Gedminas - find it at!