-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1809/#review4542
-----------------------------------------------------------



src/mem/cache/cache_impl.hh
<http://reviews.gem5.org/r/1809/#comment4280>

    Why is this here and not in base.cc?
    
    Alternatively, move all the things from base.hh to cache.hh, I honestly do 
not know which is more suitable. I would actually guess the latter.



src/mem/cache/cache_impl.hh
<http://reviews.gem5.org/r/1809/#comment4281>

    Same as above. How come this is not in base.cc?



src/mem/cache/cache_impl.hh
<http://reviews.gem5.org/r/1809/#comment4282>

    Will this not create problems?
    
    If there is a retry event scheduled, then surely we should not get another 
attempt at giving us a new packet. If we "sink" the second request then there 
will only be a single retry and the protocol would break down. Should this not 
say assert(!sendRetryEvent.scheduled()); and then schedule a send retry?
    
    


A few more things that are popping up. Thanks for all the updates. It would be 
great if Ali or Steve could also have a look before we ship this.

- Andreas Hansson


On July 19, 2013, 11:13 p.m., Xiangyu Dong wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1809/
> -----------------------------------------------------------
> 
> (Updated July 19, 2013, 11:13 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 9816:2d9b611c12bc
> ---------------------------
> mem: model data array bank in classic cache
> The classic cache does not model data array bank, i.e. if a read/write is 
> being
> serviced by a cache bank, no other requests should be sent to this bank.
> This patch models a multi-bank cache.  Features include:
> 1. detect if the bank interleave granularity is larger than cache line size
> 2. add CacheBank debug flag
> 3. Differentiate read and write latency
> 3a. read latency is still named as hit_latency
> 3b. write latency is named as write_latency
> 4. Add write_latency, num_banks, bank_itlv_bit into the Python parser
> Not modeled in this patch:
> Due to the lack of retry mechanism in the cache master port, the access form
> the memory side will not be denied if the bank is in service. Instead, the 
> bank
> service time will be extended. This is equivalent to an infinite write buffer
> for cache fill operations.
> 
> 
> Diffs
> -----
> 
>   configs/common/O3_ARM_v7a.py 3b3b94536547 
>   configs/common/Caches.py 3b3b94536547 
>   configs/common/CacheConfig.py 3b3b94536547 
>   configs/common/Options.py 3b3b94536547 
>   src/mem/cache/BaseCache.py 3b3b94536547 
>   src/mem/cache/SConscript 3b3b94536547 
>   src/mem/cache/base.hh 3b3b94536547 
>   src/mem/cache/base.cc 3b3b94536547 
>   src/mem/cache/cache_impl.hh 3b3b94536547 
>   src/mem/cache/tags/Tags.py 3b3b94536547 
> 
> Diff: http://reviews.gem5.org/r/1809/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Xiangyu Dong
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to