[gem5-users] Re: Different latencies

[Shen, Fangjia via gem5-users]

Regarding the data latency, I think it depends on whether the cache is 
sequential access (access cache tags, then data) or parallel access (access 
tags and data at the same time - common optimization for the L1 cache).  See 
the code for BaseCache::calculateAccessLatency. If sequentialAccess==true,  the 
sum of tag latency and data latency is used, otherwise the greater of tag 
latency and data latency.

Regards,
Fangjia



________________________________
From: Eliot Moss via gem5-users <gem5-users@gem5.org>
Sent: Monday, May 1, 2023 7:46
To: The gem5 Users mailing list <gem5-users@gem5.org>
Cc: Eliot Moss <m...@cs.umass.edu>
Subject: [gem5-users] Re: Different latencies

---- External Email: Use caution with attachments, links, or sharing data ----


On 4/30/2023 11:33 PM, Inderjit singh via gem5-users wrote:
> Any ideas.
> Inderjit Singh
>
> On Wed, May 11, 2022 at 10:08 PM Inderjit singh <inderjitsingh.d...@gmail.com
> <mailto:inderjitsingh.d...@gmail.com>> wrote:
>
>     1. What is the difference between data/tag/response latency?
>     2. How can I add write latency (for NVM caches) in gem5, any patch?

The tag part of a cache records addresses and access/state bits, typically the
Valid bit (does this entry contain valid information - if not, the entry
should be ignored), Dirty (does the data differ from caches farther away or
the main memory), Shared (are there other copies of this line/block in other
caches), etc.

A cache first takes the address in the request (typically a read or write) and
sees if that addresses occurs is a valid entry in the cache.  The amount of
time to do this is the TAG latency.

The DATA latency is the additional time to supply (or update) the data if the
tag matches (a cache hit).

I believe the RESPONSE latency is how long it takes a cache to pass through a
response coming from beyond itself.


As for your question about write latency in NVM caches, I find the question a
little bit ambiguous.  I assume you mean volatile caches that cache
information coming from NVM.  DATA latency would be the write latency into
such a cache.  If you're talking about the internal buffers of an NVM, there
are a slew of parameters in the NVM interface (which combines all the
buffering, etc., with the actual data array).  See NVMInterface.py, but also
MemInterface.py.  To set such parameters on the command line, you have to do
it for each controller.

This bash code might give you a sense of a way to do it using a script:

# MEMORY parameters

export GEM5_MEMTYPE=${GEM5_MEMTYPE:-NVM_2400_1x64}
export MEM_CHANNELS=${MEM_CHANNELS:-8}
export GEM5_XPARAMS="${GEM5_XPARAMS} --mem-channels=${MEM_CHANNELS}"
export TOTAL_MEM_SIZE_MB=${TOTAL_MEM_SIZE_MB:-512}

## tREAD and tWRITE are guesses ...
## Other values adjusted for 2666 MHz (vs 1200MHz in default gem5)

export MEM_TCK=${MEM_TCK:-0.357ns}
export MEM_TREAD=${MEM_TREAD:-125ns}
export MEM_TWRITE=${MEM_TWRITE:-180ns}
export MEM_TSEND=${MEM_TSEND:-6.28ns}
export MEM_TBURST=${MEM_TBURST:-1.528ns}
export MEM_TWTR=${MEM_TWTR:-0.357ns}
export MEM_TRTW=${MEM_TRTW:-0.357ns}
export MEM_TCS=${MEM_TCS:-0.714ns}
export MEM_DEVICE_SIZE=${MEM_DEVICE_SIZE:=$((TOTAL_MEM_SIZE_MB / 
MEM_CHANNELS))MB}

for (( i=0 ; i < $MEM_CHANNELS ; ++i )) ; do
     export GEM5_XPARAMS="${GEM5_XPARAMS} --param 
system.mem_ctrls[$i].dram.tCK=\'${MEM_TCK}\'"
     export GEM5_XPARAMS="${GEM5_XPARAMS} --param 
system.mem_ctrls[$i].dram.tREAD=\'${MEM_TREAD}\'"
     export GEM5_XPARAMS="${GEM5_XPARAMS} --param 
system.mem_ctrls[$i].dram.tWRITE=\'${MEM_TWRITE}\'"
     export GEM5_XPARAMS="${GEM5_XPARAMS} --param 
system.mem_ctrls[$i].dram.tSEND=\'${MEM_TSEND}\'"
     export GEM5_XPARAMS="${GEM5_XPARAMS} --param 
system.mem_ctrls[$i].dram.tBURST=\'${MEM_TBURST}\'"
     export GEM5_XPARAMS="${GEM5_XPARAMS} --param 
system.mem_ctrls[$i].dram.tWTR=\'${MEM_TWTR}\'"
     export GEM5_XPARAMS="${GEM5_XPARAMS} --param 
system.mem_ctrls[$i].dram.tRTW=\'${MEM_TRTW}\'"
     export GEM5_XPARAMS="${GEM5_XPARAMS} --param 
system.mem_ctrls[$i].dram.tCS=\'${MEM_TCS}\'"
     export GEM5_XPARAMS="${GEM5_XPARAMS} --param
system.mem_ctrls[$i].dram.device_size=\'${MEM_DEVICE_SIZE}\'"
done

This is designed to allow things like MEM_TCK to be set before running this
piece of script, but otherwise to supply the default value 0.357ns (for
example).  Once all the above is done, the command line itself must include
${GEM5_XPARAMS} to expand out all of the above.  Also, I know its confusing,
but in an NVM only system, the NVM controllers have the name "dram" even
though that are of NVM type!

HTH - Eliot Moss
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org

_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org