Re: [Gems-users] Cache Parameters

[Luke Yen <lyen@xxxxxxxxxxx>]

  Hi Vince:

    Is there a reason for not using Ruby to simulate the cache hierarchy?

I have not been using Opal's cache hierarchy, but from the code I looked
at (cache.C, mshr.C) it appears that L1 I and D caches have 0 cycle hit
latencies, and on misses they incur some latency as determined by the
MSHR parameters.  Misses from the L1 I and D incur queueing delays as
determined by the L1_FILL_BUS_CYCLES (simulates waiting until the L1 to L2
bus is available), and misses from the L2 incur L2_FILL_BUS_CYCLES
(simulating L2 to main memory bus latency) in the queue.  Access latencies
to both the L2 and main memory is determined by L2_LATENCY and
MEMORY_DRAM_LATENCY.
   I am not sure what kind of system you want to simulate but changing the
FILL_CYCLES changes the latencies of the L1->L2 and L2->main memory buses.

  Luke


On Fri, 29 Apr 2005, Vince Weaver wrote:

> Hello,
>
> I'm trying to set Opal up to simulate a cache heiarchy with the following
> parameters:
>
>   Cache-to-cache latency - 400 cycles
>   L1 hit latency - 2 cycles
>   L2 hit latency - 24 cycles
>   Memory access latency - 460 cycles
>
> The latter two seem obvious:
>   opal0.setparam L2_LATENCY 24
>   opal0.setparam MEMORY_DRAM_LATENCY 460
>
> The L1 latency is more problematic... the options are a bit similar.
>
> Is the
>   opal0.setparam L1_FILL_BUS_CYCLES
> option what I want?
>
> What should L2_FILL_BUS_CYCLES be in this case?
>
> I've been going through the default config files and also the code itself
> but am a bit confused by what's going on...
>
> Thanks,
>
> Vince
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>