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 parameter used in the RubyCache_Controller object--the default value is 35, however, most of the cache protocol configurations set a value based on the command-line options.ports parameter which has a default value of 4. I understand the intuition that this could represent the number of memory requests from the core serviced per cycle (which is why options.ports is used) but this is less intuitive for me when reasoning about the L2 or L3 cache controllers. Based on recent processor designs, what are some sensible values for transitions_per_cycle for an L1, L2 & L3 controller in a multicore configuration? Any insight would be appreciated -- Timothy Hayes Senior Research Engineer Arm Research Phone: +44-1223405170 [email protected] IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
