Hey Andreas,
Thanks for the quick reply.
In the long term, I would suggest sticking to specifying the latency in
> cycles, especially if the module in questions might be subject to DVFS,
> i.e. We would use a relative metric rather than an absolute metric.
>
So, in this case, I'm making my own tweaks to the Ruby memory controller,
which currently uses cycle timing for the memory banks. In real hardware,
the bank timings are specified as some number of cycles, but they are
directly related to the frequency: The underlying bank latency is a fixed
amount of time (e.g. ns), so if you double the frequency of the memory, the
bank timings also double. Even with DVFS, I think we should be able to
easily model this type of component timing.
Sounds like the long term solution in this type of situation would be to
pass the latency as a time to the component, and have it derive cycle
counts in the C++ code based on that fixed latency and the current
frequency of the component.
That said, for now you should be able to simply grab the parents clock
> parameter, which holds the clock period.
>
This works, though it's pretty funky in that the clock.period is stored as
a float to represent seconds rather than ticks. It looks like the clock
parameter value doesn't resolve the period ticks until the simulation binds
the tick conversion before instantiating components?
Thanks,
Joel
On 23/08/2012 04:42, "Joel Hestness" <[email protected]> wrote:
>
> >Hey guys,
> > I'm trying to specify a latency parameter for an object in ns, but I
> >need
> >it converted to cycles of the parent object during Python parameter setup.
> > I'd like to grab the cycle period in ticks from the parent's Python clock
> >parameter to convert the ns value to number of cycles, so I don't have to
> >modify the C++ code of an existing gem5 object to pass in the ns
> >parameter.
> > Can someone recommend the best way to do this?
> >
> > Thanks,
> > Joel
> >
> >
> >--
> > Joel Hestness
> > PhD Student, Computer Architecture
> > Dept. of Computer Science, University of Wisconsin - Madison
> > Dept. of Computer Science, University of Texas - Austin
> > http://www.cs.utexas.edu/~hestness
> >_______________________________________________
> >gem5-dev mailing list
> >[email protected]
> >http://m5sim.org/mailman/listinfo/gem5-dev
> >
>
>
> -- 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
>
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
Dept. of Computer Science, University of Texas - Austin
http://www.cs.utexas.edu/~hestness
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
