> 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. > > Andreas Hansson wrote: > 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?
Added the changes requested: Doxygen comment and some clarification to the bytes_valid variable with a comment. Also updated the code in src/mem/packet.cc to behave as intended, it could gather stale data because the did not cross-reference the bytes_valid bitvector while copying data, now it does do the cross-reference and only copy data that hasn't been found yet. To the best of my knowledge all requests that are not of the magic functional variety are broken up into multiple requests if they need to be block aligned or are bigger than the block size. Functional accesses don't need this as they are a software interface into the memory state of M5. - Geoffrey ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/915/#review1700 ----------------------------------------------------------- On 2011-11-29 08:18:07, Geoffrey Blake wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/915/ > ----------------------------------------------------------- > > (Updated 2011-11-29 08:18:07) > > > 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
