| --- Log opened Tue Dec 02 00:00:53 2014 | ||
| stekern | why do I suck at writing Makefiles so much? | 11:34 |
|---|---|---|
| olofk | Why does writing Makefiles suck so much? | 11:55 |
| stekern | yeah, that too... | 11:58 |
| olofk | So basically you suck at doing sucky things. I think that might be a good thing, but I'm not sure | 12:19 |
| olofk | Ok, for writing, I can see how lowering stb would work, but what about reads? | 13:00 |
| olofk | If 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 |
| stekern | ack can't be always asserted | 13:07 |
| olofk | oh right. Of course. The slave knows when data is valid | 13:18 |
| stekern | there is one case where ack can be asserted when stb is deasserted though | 13:22 |
| stekern | if you deassert stb in the middle of a burst, the slave is allowed to ack that terminated access | 13:22 |
| stekern | iirc | 13:22 |
| olofk | stekern: Yes, that was the case I was thinking about | 20:06 |
| stekern | olofk: but, is that a problem though? it should have ack deasserted on the coming cycle after that then | 20:32 |
| olofk | But the slave will keep ack asserted, right? | 20:45 |
| stekern | no, I don't think you are then allowed to keep it asserted the clock cycle after stb has been deasserted | 20:56 |
| olofk | Check out figure 4-7 in the b3 spec | 20:57 |
| stekern | you can't implement delayed ack and comb ack at the same time | 20:58 |
| olofk | Not following you here | 20:59 |
| olofk | comb ack is for cti=000, right? | 21:00 |
| stekern | no, it's just two different ways of implementing the ack | 21:02 |
| stekern | you'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 burst | 21:04 |
| olofk | That will work fine for writes even for incremental bursts. It basically says that slave has accepted data on (stb & ack) | 21:05 |
| olofk | It's trickier for reads, but there aren't any examples of that situation | 21:06 |
| stekern | yeah, 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 010 | 21:14 |
| stekern | so, let's start over... what is the problem with reads? | 21:16 |
| olofk | And if I got things right, that would mean that the master doesn't really know when to latch data from the slave | 21:16 |
| stekern | why not? it can use the registered value of its own stb and the ack from the slave | 21:17 |
| olofk | hmm.. | 21:17 |
| olofk | I think you're right | 21:18 |
| stekern | when you deassert stb in an incrementing burst, you should hold the address from the previous cycle | 21:19 |
| olofk | True, and I will also not check for acks any cycle following a deasserted stb | 21:29 |
| olofk | Because those will not indicate valid data | 21:29 |
| stekern | well, they actually do | 21:30 |
| stekern | don't they? | 21:30 |
| stekern | hmm, maybe this is more complicated than I first thought. | 21:31 |
| stekern | the 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 cycle | 21:33 |
| stekern | when stb get asserted again, it accepts the data the slave is providing (if the slave is asserting ack) | 21:34 |
| stekern | assuming reads here | 21:34 |
| olofk | Yes, assume reads. Writes aren't a problem | 21:47 |
| olofk | I 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 asynchronously | 21:51 |
| olofk | Do 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 accesses | 21:53 |
| stekern | the biggest problem is to solve how to write into the cache I think | 22:05 |
| olofk | Write from the CPU? | 22:09 |
| stekern | olofk: I mean during refill | 23:03 |
| stekern | since the cache is a dpram, I'd need one 64-bit port and one 32-bit port | 23:04 |
| --- Log closed Wed Dec 03 00:00:54 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!