Not exactly. Let's say the CPU executes an unaligned write to an address and then functionally I want to read that address aligned. The first request it found floating it the memory system would be the unaligned write which would satisfy say two of the 4 byte request with the mshr in the l1. The rest is coming from some other level of the memory hierarchy. To get the latest data the functional requests need to know that two bytes have been satisfied when it goes looking for last two.
Ali Sent from my ARM powered mobile device On Nov 29, 2011, at 7:41 AM, "Andreas Hansson" <[email protected]> wrote: > > >> On 2011-11-29 03:01:47, Andreas Hansson wrote: >>> src/mem/packet.hh, line 278 >>> <http://reviews.m5sim.org/r/915/diff/1/?file=15577#file15577line278> >>> >>> Ok maybe I got things confused here. Is the idea that you can have an >>> address that is not aligned to any word (e.g. only byte aligned) and that >>> any bytes could be valid within the burst (hence the mask)? Do the bytes >>> have to come in whole words or can they be partial? Do the valid bytes all >>> reside at the beginning of the burst, i.e. from the start address or could >>> they be anywhere? >>> >>> I am merely trying to understand if this is indeed a byte enable (and if >>> so how organised) or if it is more a way of having smaller than >>> "getBlockSize()" bursts. >>> >>> Does that make sense? >> >> Ali Saidi wrote: >> This has nothing to do with byte enables, bursts, or masks in the ense >> you're thinking. The issue is that functional accesses go hunting in the >> memory system for a version of the block that they can use to satisfy a >> request. Up to this point, if a block with some of the request was found, >> but not all of it, that would cause the simulator to panic, because it could >> only satisfy parts of the request and there was no way to indicate that it >> old dome but not all the bytes. You couldn't just satisfy the whole thing at >> the next level, because it might have stale data. This change adds a status >> per byte of functional accesses ich fixes that issue. > > Sorry for the misunderstanding. So a functional request is made to an address > that is not aligned to the "system" block size boundary, or not of the > "system" block size? Should this not be addressed with a ChunkGenerator at > the source port making the request? Could there be non-functional requests > that have these properties? > > > - Andreas > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/915/#review1700 > ----------------------------------------------------------- > > > On 2011-11-28 09:05:53, Geoffrey Blake wrote: >> >> ----------------------------------------------------------- >> This is an automatically generated e-mail. To reply, visit: >> http://reviews.m5sim.org/r/915/ >> ----------------------------------------------------------- >> >> (Updated 2011-11-28 09:05:53) >> >> >> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and >> Nathan Binkert. >> >> >> Summary >> ------- >> >> Packet: Enable functional reads of partial data to packet class >> >> This patch fixes a long standing defficiency in the packet class where >> it was unable to handle finding data that partially satisfied a request. >> >> This splits out changes made to the packet class in the checkercpu patch as >> requested by Ali. >> >> >> Diffs >> ----- >> >> src/mem/packet.hh 62dee0c98d53 >> src/mem/packet.cc 62dee0c98d53 >> >> Diff: http://reviews.m5sim.org/r/915/diff >> >> >> Testing >> ------- >> >> Compiles. No functional changes made from CheckerCPU patch to this patch for >> packet class, and CheckerCPU fully exercised this code path during testing. >> >> >> Thanks, >> >> Geoffrey >> >> > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
