Hi Timothy,
The timing latencies usually come from the enqueue operations in the SLICC,
which may or may not be the same as the Tag/DataAccessLatency. You would
have to dig into the protocol specification to know for sure. The
Tag/DataAccessLatency is mostly used in the bandwidth model, and it not
*
build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-switcheroo-full:
FAILED!
* build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3:
FAILED!
* build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3-dual:
FAILED!
* build/NULL/tests/opt/quic
The RubyCache object takes separate latency parameters for the tag and the data
arrays (TagAccessLatency/DataAccessLatency). Are tag and data lookups done in
parallel or serially? Are they different so it is possible to know if a miss
occurred sooner?
Regarding the transitions_per_cycle paramet
See /z/m5/regression/regress-2019-08-16-03:00:01 for details.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev