Q1. 讲义第23页，讲到CPU Cluster 1和CPU Cluster 2属于一个inner domain，MASTER X和MASTER Y属于另一个inner domain，我想请问这里当这4个同时连到同一个coherent总线时，总线如何区分他们属于两个不同的inner domain，因为AxDomain信号好像只能表示是inner domain，但是无法指明是哪一个inner domain。
A:目前ARM的coherent总线无法区分inner domain 和outdomain. 更不能区分到底属于哪个innerdomain。

Q2. 讲义30页，关于ReadNoSnoop的第一种情况Non-Cacheable，
（1）这里我想请问在一个多CPU的系统中，每个CPU的page table是一样的吗，在物理上是同一份拷贝，还是不同的CPU可以有不同的page table，对同一块地址设置不同的属性？
A2.1: 一个cluster中的每个core，是允许有不同的Page table的。但实际过程中，大量的case应该是OS保证每个PE对地址的认知是相同的，否则就会出现混乱导致系统出现不可知结果。
（2）如果不同的CPU可以有不同的page table，对同一块地址设置不同的属性，那么连在当前coherent总线上的所有CPU中的page table中都必须把这块地址设置成Non-Cacheable时，才可以发起ReadNoSnoop操作，反之，如果有的CPU中的page table把这块地址设置成Non-Cacheable，而有的CPU不这么设置，就不能发起ReadNoSnoop操作，这个理解正确吗？
A2.2: 这里更多的从每个core的角度来说。假设core发出的transaction需要发到cluster外，每个core可以发出独立的transaction, (通过BIU)送往L2/SCU之后，有独立的ID表明是该core对应的transaction。因此，每个core会分别根据Page table中对地址的定义，以及当前core的状态（MMU,CACHE属性等）做出判断，是否需要发出ReadNoSnoop.
（3）这里讲的，对于一个地址有inner属性和outer属性，请问inner属性和outer属性具体是指什么意思？是inner domain和outer domain？
A2.3: 这里讲的inner 和outer是从CPU的page table中对某个地址的属性定义来说的。

3. 讲义38页，关于ReadOnce的Memory type，
   （1）提到must be modifiable，请问这里modifiable是指什么意思？
   A3.1: 这里指的是AxCACHE[1].
   （2）ReadOnce的Typical Case有access memory marked with write back no-read-allocate，我想请问有没有write-through no-read-allocate这种memory type，如果有的话，是不是也可以用ReadOnce。
   A3.2: AMBA4 协议里有write-through-no-allocate(ARCACHE=1010 AWCACHE=0110). 但是从CPU的角度看，所有write-through cache 属性的地址都会认为是normal non-cacheable的。是不会发出Readonce的。对于自己设计的IP,只要满足协议要求就可以（可以参照：ReadOnce and WriteUnique transaction constraints 相关章节表格）。
   Q4. 关于snoop filter，
   （1）我想请问snoop filter是不是一般实现在coherent 总线中，因为只有coherent总线才知道哪些地址的数据在哪些master的cache中，还是说snoop filter也可以实现在其他地方？
   A4.1: SF放在coherent总线比较合理。一方面总线最知道cache的eviction 和allocation 情况，另外对于必要的back invalidation操作，由总线发起更合适高效。
   （2）讲义中提到write back和write evict都可以用于enable snoop filter，以write back为例，这里是指总线当发现write back时，就同时write dirty cacheline to memory并enable snoop filter？还是指总线事实上不支持write back操作，当看到write back时就转义为enable snoop filter？
   A4.2: 这里更多的只write back和write evict 操作对SF的操作有影响。比如发现这两个请求，就可以将SF中对应的entry清掉。
   （3）最差情况下，snoop filter内部需要记录信息的条数等于coherent总线上连着的所有master中cache容量的总和除以cacheline大小，用以准确记录每个master中每个cache的每条cacheline对应的地址，从而可以在snoop时查询到需要snoop哪几个master，这个理解是否正确，按这个说法，对于cache容量比较大或者master数目比较多的总线所实现的snoop filter的面积岂不是会很大？
   A4.3: snoop filter的大小的确很影响system performance. 如果SF过于小，那就会引入更多的back invalidation 操作去把上游的cache invalidate掉，这个非常影响性能。至少从ARM的CCI的角度看，建议的SF的大小是上游的exclusive cache的大小之和的2倍，实际大小可以根据系统的profiling 的情况调整。
4. 讲义45页，关于write clean的Typical Case，提到Eviction of the dirty lines from L2, when the line is still present in L1，这里所说的情景是指write clean的ACE transaction发生在L1和L2cache之间，也就是coherent总线是在CPU内部的，连着多个L1和一个L2，这个理解正确吗？
   A5: 我的本意是指：L1和L2的cache 可以是exclusive的（也就是存在于L1中的cache行，可以不存在于L2中）。这样从CPU的角度看发起write clean的一个典型例子就是一个cache开始的时候同时存在于L1和L2中，但是由于某些原因导致L2的该cache 行需要被evict出去（比如L2 满之后需要继续allocation 导致的eviction).
5. 讲义46页，讲师提到对于Unique Clean的cacheline，当CPU需要替换这条cacheline时，可以在CPU内部默默的直接把他invalid操作，不用发起ACE transaction，我想说这里是不是有一个前提是系统中没有snoop filter，因为如果有snoop filter在记录着这一行Cacheline Unique Clean的信息，CPU内部默默直接invalid的操作，就会引起snoop filter中记录信息与实际情况不符的问题，这个理解正确吗？
   A6: 当系统中有SF的时候，是建议在这种case下，发出writeevict操作的。现在很多的Cortex-A processor 内部都有寄存器来控制是否发出writeevict 和/或 Evict 操作。如果没有发出，会导致SF更容易满，从而对CPU发起没有必要的back invalidation 操作来影响系统性能。 当然，即使不发，在功能上应该是没有问题的。