This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

The problem of modifying the cache parameter in the Canvas

I want to modify cache latency parameter in system canvas，and I use FVP_Base_Neoverse-N1 to build my system，so is it correct to modify the cache parameters like this?

Parents

0 Rob Kaye over 4 years ago
Hi, thanks for the question. By default, cache modelling is disabled in Fast Models / FVPs. For the most part the presence - or otherwise - of a cache does not affect software functionality and modelling the caches in a programmer's view model like Fast Models has an impact on the simulation performance. However, you do need to switch cache modelling on in order simulate cache access and have the timing parameters to take effecy.

In the Base FVPs such as Neoverse-N1 there is a top level parameter called "cache_state_modelled" that switches on (or off) the modelling of all caches. Each cache in the platform can be enabled or disabled individually, but generally you would either want all on, or all off. There are several ways to set this parameter. I generally use a command line switch when running the FVP: "-C cache_state_modelled=1".

Another option is to set it in System Canvas and rebuild the platform. To do this:

open the project

with the top level LISA file (FVP_Base_Neoverse-N1.lisa) open, click "properties"

select the "parameters" tag

change the default value of cache_state_modelled to 1

save

build

Now when you run the FVP cache modelling will be on by default. You could then turn it off if needed by adding "-C cache_state_modelled=0" to the command line.

The second stage of adding delays to the cache transactions in the model. A Neoverse-N1 has:

l1 dcache, l1 icache, l2 cache per core

l3 cache shared between all cores

Each of these has a set of parameters for hit/miss, read/write, snoop and maintenance latency. The methods for setting them are the same as those for the global cache state modelled paramter.

on the command line, add (for example) "-C cluster0.dcache-hit_latency=<value>"

edit the value in the LISA by:

right click on the Neoverse model (called "cluster0")

select "object properties"

select "parameters" tab

edit the value of all the cache operations that you want to assign a latency

(or you could double-click on the "cluster0" model to open the LISA for that model and edit the parameters in the source code)

save

rebuild

There is one final step to get these values recognized when you run the FVP. By default, all latencies are ignored when a fast model runs. To enable them, you need to set an Environment Variable called FASTSIM_DISABLE_TA. Set this to "0" for the latencies to applied in the simulation before running the FVP.

The documentation for Fast Models Timing Annotation can be found here: developer.arm.com/.../timing-annotation.

Regards,

Rob.
Cancel
Up 0 Down

Cancel

Reply

0 Rob Kaye over 4 years ago
Hi, thanks for the question. By default, cache modelling is disabled in Fast Models / FVPs. For the most part the presence - or otherwise - of a cache does not affect software functionality and modelling the caches in a programmer's view model like Fast Models has an impact on the simulation performance. However, you do need to switch cache modelling on in order simulate cache access and have the timing parameters to take effecy.

In the Base FVPs such as Neoverse-N1 there is a top level parameter called "cache_state_modelled" that switches on (or off) the modelling of all caches. Each cache in the platform can be enabled or disabled individually, but generally you would either want all on, or all off. There are several ways to set this parameter. I generally use a command line switch when running the FVP: "-C cache_state_modelled=1".

Another option is to set it in System Canvas and rebuild the platform. To do this:

open the project

with the top level LISA file (FVP_Base_Neoverse-N1.lisa) open, click "properties"

select the "parameters" tag

change the default value of cache_state_modelled to 1

save

build

Now when you run the FVP cache modelling will be on by default. You could then turn it off if needed by adding "-C cache_state_modelled=0" to the command line.

The second stage of adding delays to the cache transactions in the model. A Neoverse-N1 has:

l1 dcache, l1 icache, l2 cache per core

l3 cache shared between all cores

Each of these has a set of parameters for hit/miss, read/write, snoop and maintenance latency. The methods for setting them are the same as those for the global cache state modelled paramter.

on the command line, add (for example) "-C cluster0.dcache-hit_latency=<value>"

edit the value in the LISA by:

right click on the Neoverse model (called "cluster0")

select "object properties"

select "parameters" tab

edit the value of all the cache operations that you want to assign a latency

(or you could double-click on the "cluster0" model to open the LISA for that model and edit the parameters in the source code)

save

rebuild

There is one final step to get these values recognized when you run the FVP. By default, all latencies are ignored when a fast model runs. To enable them, you need to set an Environment Variable called FASTSIM_DISABLE_TA. Set this to "0" for the latencies to applied in the simulation before running the FVP.

The documentation for Fast Models Timing Annotation can be found here: developer.arm.com/.../timing-annotation.

Regards,

Rob.
Cancel
Up 0 Down

Cancel

Children

0 qiqi over 4 years ago in reply to Rob Kaye

Dear Rob

Thanks for your answer, I get it！

Best regards

qiqi
Cancel
Up 0 Down

Cancel
0 Rob Kaye over 4 years ago in reply to qiqi

great! if you have more questions, let me know!
Cancel
Up 0 Down

Cancel
0 qiqi over 4 years ago in reply to Rob Kaye

Hi Rob

I have another problem now.

I set cache_state_modelled=1,dcache-state_modelled=1,icache-state_modelled=1,dcache-hit_latency=0x4,cpu0.l2cache-hit_latency=0x10 in LISA, and build,then I set environment value FASTSIM_DISABLE_TA="0". Then start FVP.

I use lmbench to test the fixed model on FVP, Lmbench is a miniature assessment tool(link is here: http://www.bitmover.com/lmbench/), and I use lat_mem_rd(memory read latency benchmark) to get mem_load_latency(link is here: http://www.bitmover.com/lmbench/lat_mem_rd.8.html). The memory size of the test is set to 128MB, but the result of mem-load-latency test is always about 10ns, the fixed parameter seems to be not enable.

The test file is here,the first column is the memory range, and the second column is the mem_load_latency.

mem_load_latency.txt
Memsize latencytime 0.00049 10.729 0.00098 10.719 0.00195 10.719 0.00293 10.72 0.00391 10.72 0.00586 10.72 0.00781 10.72 0.00977 10.72 0.01172 10.72 0.01367 10.563 0.01562 10.565 0.01758 10.566 0.01953 10.567 0.02148 10.565 0.02344 10.567 0.02539 10.512 0.02734 10.513 0.0293 10.516 0.03125 10.514 0.03516 10.514 0.03906 10.487 0.04297 10.487 0.04688 10.486 0.05078 10.472 0.05469 10.472 0.05859 10.473 0.0625 10.462 0.07031 10.462 0.07812 10.457 0.08594 10.45 0.09375 10.449 0.10156 10.444 0.10938 10.445 0.11719 10.442 0.125 10.437 0.14062 10.435 0.15625 10.434 0.17188 10.431 0.1875 10.429 0.20312 10.428 0.21875 10.427 0.23438 10.426 0.25 10.425 0.28125 10.423 0.3125 10.422 0.34375 10.423 0.375 10.419 0.40625 10.419 0.4375 10.419 0.46875 10.418 0.5 10.418 0.5625 10.417 0.625 10.416 0.6875 10.416 0.75 10.416 0.8125 10.416 0.875 10.414 0.9375 10.413 1 10.415 1.125 10.417 1.25 10.415 1.375 10.415 1.5 10.411 1.625 10.416 1.75 10.415 1.875 10.414 2 10.412 2.25 10.412 2.5 10.414 2.75 10.412 3 10.411 3.25 10.415 3.5 10.413 3.75 10.411 4 10.412 4.5 10.411 5 10.415 5.5 10.414 6 10.412 6.5 10.414 7 10.412 7.5 10.413 8 10.414 9 10.413 10 10.413 11 10.408 12 10.41 13 10.415 14 10.414 15 10.411 16 10.415 18 10.413 20 10.413 22 10.411 24 10.412 26 10.411 28 10.412 30 10.411 32 10.414 36 10.411 40 10.412 44 10.412 48 10.41 52 10.411 56 10.411 60 10.411 64 10.412 72 10.409 80 10.413 88 10.412 96 10.41 104 10.411 112 10.412 120 10.412 128 10.412
Cancel
Up 0 Down

Cancel
0 Rob Kaye over 4 years ago in reply to qiqi

setting the cache modelling on, and timing annotation on, allows you to annotate estimated delays on cache accesses. however, adding delay estimates to the memory accesses - which I think is what you are looking for - requires an additional step.

to annotate delays to the memory access, requires that the memory model be implemented in SystemC and connected to the Fast Model through an AMBA-PV port. Fast Models uses the time parameter on the b_transports as defined in the TLM 2.0 specifications to annotate the estimated delays.

You will need to modify the FVP source example you are using to make this possible as within the FVP the memory is currently modelled within the Fast Models subsystem. This is quite a complex subject: if you would like to continue I think we should move this discussion to our support channel rather than using the forum.

One other question to ask: does the application code that are running on the FVP configure and enable the caches? As well as enabling the cache models in the FVP the code itself needs to implement the correct cache setup code before instructions and data are saved in the caches in the model (in the same way that it would need to be set up on a hardware target),
Cancel
Up 0 Down

Cancel
0 qiqi over 4 years ago in reply to Rob Kaye

Hi Rob

Thanks a lot and sorry for the late reply. the application code that are running on the FVP don't need to configure the caches. And I have created a case-Adding delay estimates to the memory accesses on Surpport, can we move to there to discuss?

regards

qiqi
Cancel
Up 0 Down

Cancel