Review Board 2.0.15


ruby: Fixes clock domains in configuration files.

Review Request #2218 - Created March 31, 2014 and submitted

Information
Emilio Castillo
gem5
Reviewers
Default 
This patch fixes the se.py script by adding the ruby clock domain.

This would cause the ruby clock domain to be set at 1GHz by default. 
Running simulations with the cpu clock set at 2GHz or 1GHz will output the same time results and could distort 
power measurements.

The patch also sets the clock domain for each coherence protocol. Now the L1 controllers and  the Sequencer shares the cpu clock domain,
while the rest of the components use the ruby clock domain. 

Thanks to Mr. Nilay Vaish for his help while figuring out what was happening.



This was tested using a timing cpu with a code that is not memory or I/O bounded such as:

#include <math.h>
#include <stdio.h>

void main()
{
   float var=0.0f;
   int i;
   for (i=0;i<800000;i++)
      var=exp(var);
   printf("var %f\n",var);
}

If CPU freq. is halved from 2GHz to 1GHz, execution time is also expected to decrease.
(This has been verified with the classic memory model).


build/X86_MESI_Two_Level/gem5.fast configs/example/se.py -n 2  -c ./a.out --cpu-type=timing --caches --cpu-clock=2GHz

sim_seconds                                  0.076027                       # Number of seconds simulated
system.cpu0.numCycles                       152035861



build/X86_MESI_Two_Level/gem5.fast configs/example/se.py -n 2  -c ./a.out --cpu-type=timing --caches --cpu-clock=1GHz

sim_seconds                                  0.152036
system.cpu0.numCycles                       152054288 


However if ruby is used (with the se.py fixed by adding the ruby clock), execution time will be the same at 2GHz and 1GHz for the cpu.

build/X86_MESI_Two_Level/gem5.fast configs/example/se.py -n 2 --ruby --num-l2cache=2 --num-dirs=2 -c ./a.out --cpu-clock=2GHz 
sim_seconds                                  0.304070
system.cpu0.numCycles                       608140702 

build/X86_MESI_Two_Level/gem5.fast configs/example/se.py -n 2 --ruby --num-l2cache=2 --num-dirs=2 -c ./a.out --cpu-clock=1GHz 
sim_seconds                                  0.304070                       # Number of seconds simulated
system.cpu0.numCycles                       304070351


Suppose the cache access cycles are set to 2 cycles at 2GHz, if the CPU freq. is also set to 2GHz then a memory access will take 
2 cycles, even for ins. fetch in the simple cpus.

If the CPU freq is now lowered to 1GHz, each memory access to the L1's will take 1 cycle seen from the cpu side. 
Ins. fetch will take now 1 Cycle, thus the number of execution cycles will be exactly twice more in the 2GHz cpu.

608140702/304070351=2.0

This patch fixes it with an approach similar taken in the classic memory model, where the l1 controllers are set to the cpu clock domain.

Issue Summary

2 1 1 0
Description From Last Updated Status
I realise this is orthogonal to this patch, but is there any chance we could factor out the generic bits ... Andreas Hansson March 31, 2014, 3:58 a.m. Open
Review request changed
Updated (Sept. 1, 2014, 2:57 p.m.)

Status: Closed (submitted)