飞思卡尔半导体公司
估计最坏情况下的延迟
计算
。系统设计人员应估计SPRAM的百分比的访问
系统，这将导致微引擎等待状态。这个百分比被称为RAM中
碰撞率（ RCR ） 。与直接主机每次碰撞访问到SPRAM中，
微引擎等待2个系统时钟。
在所述的eTPU相干双参数控制器（CDC ）也可以访问SPRAM为
两个参数的原子转移。该微引擎的eTPU
可等待此操作
（如果它
是在服务时间），直到传输完成。疾病预防控制中心总是转移两个参数，
使得连续四次访问（读，写，读，
写一个系统时钟的每一个） 。
该
系统设计人员应估计SPRAM的比例在系统中会访问
结果在微引擎等待由于相干传递，并与平均值乘以
系统的时钟数的微引擎等待每次传输。这个百分比被称为
相干参数碰撞率（ CPCR ） 。
此外，微引擎对微引擎的多个参数相干通信，
使用硬件信号量，可以容纳一个微引擎正在等待锁定
而另一个微引擎是抱着它信号灯。
这种等待是由于软件循环，
不是硬件等待状态。
需要注意的是单一的参数访问的一个微引擎不
其他微引擎的定时影响由于SPRAM时间交错。这意味着
单个参数微引擎对微引擎的通信不影响
性能。该等待信号量将循环直到它被释放的微引擎
由其它微引擎。这个时间依赖于的eTPU应用。系统设计
应该估计的百分比微引擎对微引擎相干多
参数相干通信，这将导致在所述的eTPU ，并与它乘以
系统时钟平均数的微引擎停转的每一个这样的转移。这
百分比称为CCR （通信冲突率）。
100％的碰撞率对一个系统是理论上最坏的情况。在许多系统中，但是，
在RCR ， CPCR和CCR的将是非常低的，有时甚至是接近0％ 。这是因为
中的eTPU能够服务功能最需要一个独立的处理器。因此，该
主机很少需要访问的eTPU参数RAM 。还一致
多个参数的微引擎对微引擎通信可以是罕见的。对
找到一个现实的RCR与CPCR ，系统设计人员应评估主机代码，找到
的时间百分比它访问的eTPU参数RAM使用或不使用的
疾病预防控制中心。这一比例提供了良好的RCR和心肺脑复苏。所述的eTPU申请提供了一种
良好的估计CCR的。
记
投票的编程实践中的eTPU标志
SPRAM导致非常高的RCR ，应该避免在
高性能系统。
后发现的碰撞速率为一个系统，它可以被应用到WCL计算
每个通道。系统设计人员可以使用碰撞百分比和数量
飞思卡尔半导体公司...
12-10
的eTPU参考手册
初步-如有更改，恕不另行通知
欲了解更多有关该产品，
转到： www.freescale.com
摩托罗拉
