Hello,
first of all thanks for your reply.
I will make an example, that sould make the things a bit clearer.
1. Test: Set frequency in the simulation script (se.py) to 2 GHz.
Simulation is successfully exiting @ cycle 17036500.
2. Test: Set frequency in the simulation script to 1 GHz. Simulation is
successfully exiting @ cycle 19130000.
3. Test: Set frequency in the simulation script to 1 GHz. During the
simulation I change the frequency to 2 GHz directly before the
event->process() routine (in eventq.cc) is called for the first time. So
I change the frequency before the first "tick" is executed. But now the
simulation is successfully exiting @ cycle 17192500. But in my eyes it
should also be 17036500.
4. Test: Set frequency in the simulation script to 1 GHz. During the
simulation I change the frequency to 2 GHz, before the "real simulation"
(output of Simulation.py) is executed. Now the simulation is
successfully exiting @ cycle 17036500.
So, our primary problem is this unequality in runtime, not the changing
of frequency. It seems that some parts do not detect the frequency change.
I hope things are clearer now.
Best wishes
Fabian
Am 22.07.2010 11:25, schrieb Gabe Black:
What do you mean when you say "no dynamic scaling is possible"? Do you
mean the change you're making during initialization isn't reflected in
the stats? It could be that you're writing the value too early and the
version from python is overwriting it. If you change it later as well
and that doesn't seem to change anything I'm not sure what's happening.
It looks like that should work, although there may be a subtle problem
I'm not seeing.
Gabe
[email protected] wrote:
Hello,
I hope this is the right place for asking my question :)
We want to implement dynamic frequency scaling in m5. In the end the
frequency should be decreased when the processor is idle and increased
if instructions are executed.
At the moment we are using the Alpha ISA and the O3CPU in SE-mode
Our first intention was to use the cpu.cc in src/cpu/o3. In the
routine FullO3CPU<Impl>::tick() we wanted to implement the frequency
changing (by changing the clock variable). So far this is working but
we discovered one problem. If we change the frequency only once in the
first cycle before the first "tick" is executed (meaning before
fetch.tick() is executed for the first time), the simulator needs a
different amount of cycles for program execution compared to a run in
which we just change the frequency in the simulator script (without
dynamic frequency scaling). If we change the frequency in the
initialization phase of the simulator the amount of cycles is correct,
but in that case no dynamic scaling is possible.
I hope that you understand our problem, and that you can give some
advices how to solve this problem.
Thanks in advance
Fabian
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
--
Karlsruhe Institute of Technology (KIT)
Chair of Dependable Nano Computing (CDNC)
Institut für Technische Informatik (ITEC)
Dipl.-Math. techn. Fabian Oboril
Research Associate
Haid-und-Neu-Str. 7
Building 07.21
76131 Karlsruhe, Germany
Phone: +49 721 608-4859
Fax: +49 721 608-3962
Email: fabian.oboril∂kit edu
Web: http://cdnc.itec.kit.edu/
KIT – University of the State of Baden-Wuerttemberg and
National Research Center of the Helmholtz Association
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
