"快速模型参考手册1: 版本11.14更新历史与文档信息"

需积分: 0 142 浏览量更新于2024-04-17 收藏 10.41MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

1.3.3 Bus traffic in Fast Models

PVBus can simulate the behavior of individual bus transactions passing through a hierarchy of bus

fabric, but it employs several techniques to optimize this process.

1. PVBus generally decodes the path between a bus master and the bus slave the first time a transaction

is issued. All subsequent transactions to the same address are automatically sent to the same slave,

without passing through the intervening fabric.

2. For accesses to normal memory, the master can cache a pointer to the (host) storage that holds the

data contents of the memory. The master can read and write directly to this memory without

generating bus-transactions.

3. For instruction-fetch, and for operations such as repeated DMA from framebuffer memory, PVBus

provides an optimization called “snooping”, that informs the master if anyone else could have

modified the contents of memory. If no changes have occurred the master can avoid the need to re-

read memory contents.

If a piece of bus fabric wants to intercept and log all bus transactions, it can defeat these optimizations by

claiming to be a slave device. It can then log all transactions and can reissue identical transactions on its

own master port. However, doing this slows all bus transactions and significantly impacts simulation

performance.

Note

If direct accesses to memory by the CT engine are intercepted by the fabric, the processor is forced to

single step. Execution is much slower than normal operation with translated code.

The bus traffic generated by a processor is not representative of real traffic:

Timing differences

Re-ordering and buffering of memory accesses, out-of-order execution, speculative prefetch and

drain-buffers can cause timing differences. They are not modeled, since they are not visible to

the programmer except in situations where a cluster program contains race conditions that

violate serial-consistency expectations.

Bus contention

Fast Models do not model the time taken for a bus transaction, so they cannot model the effects

of multiple transactions contending for bus availability.

Size of access

Fast Models do not attempt to generate the same types of burst transaction from the processor

for accesses to multiple consecutive locations.

Instruction fetch

The behavior of the instruction prefetch unit of a processor is not modeled to match the

hardware implementation.

Behavioral differences

In some software, the trace of instruction execution is dependent on timing effects. For example,

if a loop polls a device waiting for a 10ms time-out, the number of iterations of the polling loop

depends on the rate of instruction execution.

Related references

1.3.4 Instruction prefetch in Fast Models on page 1-16

1.3.4 Instruction prefetch in Fast Models

The CT engine in the processor models relies on Fast Models PVBus optimizations. It only performs

code-translation if it has been able to prefetch and snoop the underlying memory. It then need not issue

bus transactions until the snoop handling detects an external modification to memory.

If the CT engine cannot get prefetch access to memory, it drops to single-stepping. This single-stepping

is very slow (~1000x slower than translated code execution).

1 Introduction

1.3 Fast Models accuracy

reserved.

1-16

Non-Confidential

Real processors attempt to prefetch instructions ahead of execution and predict branch destinations to

keep the prefetch queue full. The instruction prefetch behavior of a processor can be observed by a

program that writes into its own prefetch queue (without using explicit barriers). The architecture does

not define the results.

The CT engine processes code in blocks. The effect is as if the processor filled its prefetch queue with a

block of instructions, then executed the block to completion. As a result, this virtual prefetch queue is

sometimes larger and sometimes smaller than the corresponding hardware. In the current

implementation, the virtual prefetch queue can follow small forward branches.

With an L1 instruction cache turned on, the instruction block size is limited to a single cache-line. The

processor ensures that a line is present in the cache at the point where it starts executing instructions from

that line.

In real hardware, the effects of the instruction prefetch queue are to cause additional fetch transactions.

Some of these are redundant because of incorrect branch prediction. This causes extra cache and bus

pressure.

Related references

1.3.3 Bus traffic in Fast Models on page 1-16

1.3.5 Out-of-order execution and write-buffers in Fast Models

Hardware memory is Weakly Ordered, but Fast Models memory is Strongly Ordered.

The CT implementation executes instructions sequentially. One instruction is retired before the next

starts to execute. In a real processor, multiple memory accesses can be outstanding, and can complete in

a different order from their program order. Writes can also be delayed in a write-buffer.

The programmer visible effects of these behaviors is defined in the architecture as the Weakly Ordered

memory model, which the programmer must be aware of when writing lock-free cluster code.

Within Fast Models, memory accesses happen in program order, effectively as if all memory is Strongly

Ordered.

1.3.6 Caches in Fast Models

Fast Models with cache-state modeling enabled can replicate some types of failure-case, but not all types.

The effects of caches are programmer visible because they can cause a single memory location to exist as

multiple inconsistent copies. If caches are not correctly maintained, reads can observe stale copies of

locations, and flushes/cleans can cause writes to be lost.

There are three ways in which incorrect cache maintenance can be programmer visible:

From the D-side interface of a single processor

The only way of detecting the presence of caches is to create aliases in the memory map, so that

the same range of physical addresses can be observed as both cached and non-cached memory.

From the D-side of a single processor to its I-side

Stale instruction data can be fetched when new instructions have been written by the D-side.

This can either be because of deliberate self-modifying code, or as a consequence of incorrect

OS demand paging.

Between one processor and another device

For example, another processor in a non-coherent MP system, or an external DMA device.

Fast Models with cache-state modeling enabled can replicate all of these failure-cases. However, they do

not attempt to reproduce the following effects of caches:

• Changes to timing behavior of a program because of cache hits/misses (because the timing of

memory accesses is not modeled).

• Ordering of line-fill and eviction operations.

• Cache usage statistics (because the models do not generate accurate bus traffic).

1 Introduction

1.3 Fast Models accuracy

reserved.

1-17

Non-Confidential

• Device-accurate allocation of cache victim lines (which is not possible without accurate bus traffic

modeling).

• Write-streaming behavior where a cache spots patterns of writes to consecutive addresses and

automatically turns off the write-allocation policy.

The Cortex

‑A9 and Cortex‑A5 models do not model device-accurate MESI behavior. The Cortex‑A15

and Cortex‑A7 models do simulate hardware MOESI state handling, and can handle cache-to-cache

snoops. In addition, they model the AMBA

4 ACE cache-coherency protocols over their PVBus ports,

so can be connected to a model of an ACE Coherent Interconnect (such as the CCI-400 model) to

simulate coherent sharing of cache contents between processors.

It is not possible to insert devices between the processor and its L1 caches. In particular, you cannot

model L1 traffic, although you can tell the model not to model the state of L1 caches.

1.3.7 Global exclusive monitor in Fast Models

This section describes the behavior of the global exclusive monitor, when cache-state-modelled is

false and when it is true.

Whether cache-state-modelled is false or true, when the system enables the data caches, they

implement the monitor for cacheable nonshared and shared memory using the cache coherency protocol.

The monitor includes other clusters that are connected with a cache coherent interconnect. Most global

monitor behavior, like exclusive granule size, is the same whether cache-state-modelled is false or

true. In particular, the data caches follow behavior that the Arm architecture prescribes in both cases.

However, some behaviors do rely on the full modeling of cache functionality. An example is that the

clearing of a monitor as a result of a cache line eviction does not happen with cache-state-modelled as

false.

The RAMDevice component and PVBus to AMBAPV bridges do not contain global monitors. As a

result, exclusive stores that reach a RAMDevice fail unless they go through an exclusive monitor. Some

platforms might need a global monitor outside of the cache coherency domains. These platforms must

include a system level monitor in the same place in the bus hierarchy as in the hardware. See the

FVP_VE and FVP_Base example platforms for examples of how to use the PVBusExclusiveMonitor

component.

1 Introduction

1.3 Fast Models accuracy

reserved.

1-18

Non-Confidential

1.4 Processor implementation

This section outlines the differences between the code translation models and the hardware.

This section contains the following subsections:

• 1.4.1 Mapping PMU events to MTI trace sources on page 1-19.

• 1.4.2 Caches in PV models on page 1-20.

• 1.4.3 GICv3 in PV models on page 1-22.

• 1.4.4 CP14 Debug coprocessor on page 1-22.

• 1.4.5 MicroTLBs on page 1-22.

• 1.4.6 TLBs in PV models on page 1-22.

• 1.4.7 Memory access in PV models on page 1-23.

• 1.4.8 Timing in PV models on page 1-23.

• 1.4.9 VIC ports in PV models on page 1-24.

1.4.1 Mapping PMU events to MTI trace sources

In Fast Models, many PMU events are modeled using MTI trace sources. These events are exposed

through the standard PMU interface. The user does not need to interface with MTI.

The following tables show which PMUv1 and PMUv2 events are modeled, and which MTI trace sources

are used to model them. The associated event numbers are as listed in the Arm Architecture Reference

Manual Armv7‑A and Armv7‑R edition, section C12.8.2 Common event numbers.

Table 1-1 PMUv1 event mappings

PMUv1 event MTI trace sources Notes

Software increment (0x00) - Modeled, but not using MTI.

Level 1 instruction cache refill (0x01)

ALLOC_LINEFILL

Level 1 instruction TLB refill (0x02)

MMU_TLB_FILL

Level 1 data cache refill (0x03)

ALLOC_LINEFILL

Level 1 data cache access (0x04) CACHE_READ_HIT, CACHE_READ_MISS

CACHE_WRITE_HIT,

CACHE_WRITE_MISS

Level 1 data TLB refill (0x05)

MMU_TLB_FILL

Load (0x06) CORE_LOADS, NV2_CORE_LOADS,

MEMTAG_LOAD_INST, SVE_LD_RETIRED

Store (0x07) CORE_STORES, NV2_CORE_STORES,

MEMTAG_STORE_INST,

SVE_ST_RETIRED

Instruction architecturally executed

(0x08)

- Modeled, but not using MTI.

Exception taken (0x09)

EXCEPTION

Exception return (0x0A)

EXCEPTION_RETURN_PREBRANCH

Write to CONTEXTIDR (0x0B)

CONTEXTIDR

Software change of the PC (0x0C) BRA_DIR, BRA_INDIR. -

Immediate branch (0x0D) BRA_DIR, BRA_DIR_FAIL. -

Procedure return (0x0E)

BRA_RET

1 Introduction

1.4 Processor implementation

reserved.

1-19

Non-Confidential

Table 1-1 PMUv1 event mappings (continued)

PMUv1 event MTI trace sources Notes

Unaligned load or store (0x0F) UNALIGNED_LDST_RETIRED,

SVE_UNALIGNED_LDST_RETIRED

Mispredicted or not predicted branch

speculatively executed (0x10)

BRANCH_MISPREDICT

Only if the BranchPrediction plug-in is loaded.

Cycle count (0x11) - Modeled, but not using MTI.

Predictable branch speculatively

executed (0x12)

- Not modeled.

Table 1-2 PMUv2 event mappings

PMUv2 event MTI source Notes

Data memory access (0x13) - Not modeled.

Level 1 instruction cache access (0x14) CACHE_READ_HIT, CACHE_READ_MISS -

Level 1 data cache write-back (0x15) - Not modeled.

Level 2 data cache access (0x16) CACHE_READ_HIT, CACHE_READ_MISS,

CACHE_WRITE_HIT, CACHE_WRITE_MISS

Level 2 data cache refill (0x17)

ALLOC_LINEFILL

Level 2 data cache write-back (0x18) - Not modeled.

Bus access (0x19) CORE_LOADS, CORE_STORES,

MEMTAG_LOADS, MEMTAG_STORES

Memory error (0x1A) - Not modeled.

Instruction speculatively executed (0x1B) - Not modeled.

Write to TTBR (0x1C)

TTBR_WRITE

Bus cycle (0x1D)

INST

This value is an approximation.

Related information

Arm Architecture Reference Manual ARMv7-A and ARMv7-R edition

1.4.2 Caches in PV models

Some processor models have PV-accurate caches, but others do not model Level 1 or Level 2 caches.

Cores that have PV-accurate cache implementation provide a functionally-accurate model. For more

information, see the processor component descriptions.

Other PV models do not model Level 1 or Level 2 caches. The system coprocessor registers related to

cache operations permit cache aware software to work, but in most cases they only check register access

permissions.

The registers affected on all code translation processor models are:

• Invalidate and/or Clean Entire ICache/DCache.

• Invalidate and/or Clean ICache/DCache by MVA.

• Invalidate and/or Clean ICache/DCache by Index.

• Invalidate and/or Clean Both Caches.

• Cache Dirty Status.

• Data Write Barrier.

1 Introduction

1.4 Processor implementation

reserved.

1-20

Non-Confidential

剩余3035页未读，继续阅读

苗苗小姐

粉丝: 40
资源: 328

会员权益专享

"快速模型参考手册1: 版本11.14更新历史与文档信息"

Model Shell for Fast Models 参考手册1

（中英对照）特斯拉Tesla ModelS 维修手册.电路图.零件手册.维修工时.车主手册.pdf

tensorflow目标检测models库安装手册1

fast models

unimodal models and multimodal models

import torchvision.models as models

slowfast 代码复现 windows

fast rcnn代码pytorch

models 包怎么下载

安装的tensorflow与models

import torchvision.models as models什么意思

将slowfast中resnet50替换为resnext50

Python 导入models模块

tensorflow.keras.models和keras.models的区别

ModuleNotFoundError: No module named 'models.Models'

import models ModuleNotFoundError: No module named 'models'

a = mdb.models['stress_Analysis'].rootAssembly r1 = a.instances['rigid_2'].referencePoints refPoints1=(r1[2], ) a.Set(referencePoints=refPoints1, name='Set-2') 这段代码为什么是第三号参考点，前两个参考点是什么

from models import RCF

会员权益专享

最新资源