> 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
