Hey everyone, I've done some development starting from changeset 9793 (this changeset introduced clock domains). I added a function to set the clock period of a clock domain. Clocked objects can use this function to dynamically set the clock period of their clock domain at runtime.
I configured a quad-core system in SE mode, with four InOrderCPUs with private caches, running a MIPS-like ISA that I added support for. The system has four tiles but five clock domains -- one for each tile and one for a simple DVFS controller that manages the frequencies of all tiles. Sometime down the line, I'm hoping to push my changes for others to use, unless someone else does it better than I did. During my development, I'm noticing that setting the clock period of a clock domain to certain frequencies introduces latencies between the CPU and caches living in that clock domain. It looks like loads and stores take a really long time to return at the new frequency, but it seems like it will only happen for certain new frequencies. I'm only using simple memory and I don't touch the Ruby memory system. For example: Starting at a nominal frequency of 625MHz (1600 Ticks) and moving up to a frequency of 1250MHz (800 Ticks) causes cycles to occur twice as often, and memory latencies seem to scale correctly. On the other hand, when starting at a nominal frequency of 625MHz (1600 Ticks) and moving up to a frequency of 800MHz (1250 Ticks), I can easily verify from an Exec debug dump that the cycles occur at the new 1250 Tick period. However, loads and stores to and from cache suddenly take tens or hundreds of cycles to return. My best guess is that there is some kind of division operation of clock periods that loses precision in a type cast, and then is used to model latency. However, I'm not too fluent with our latency models. Does anyone know off the top of their heads whether there is some clock_period dependent calculation in the memory system that might make this happen? Thanks! Chris Torng
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
