Re: [gem5-dev] Ruby Parameters

2019-08-16 Thread Jason Lowe-Power
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

[gem5-dev] Cron /z/m5/regression/do-regression --scratch all

2019-08-16 Thread Cron Daemon
* 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

[gem5-dev] Ruby Parameters

2019-08-16 Thread Timothy Hayes
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

[gem5-dev] Cron /z/m5/regression/do-regression quick

2019-08-16 Thread Cron Daemon
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