问题描述
一般问题描述：
PCI或PCI-X Core的吞吐量或带宽是多少？
解决/修复方法
PCI或PCI-X Core的吞吐量取决于用户应用程序。除了大约5或6个时钟周期（取决于传输类型）的事务开销之外，数据直接通过核心流水线化。换句话说，总线上的任何内容都会出现在循环的背面，反之亦然。您没有PCI的流程控制（acks / naks）概念，这可能会像使用其他标准（如RapidIO或HyperTransport）那样从链接的角度降低吞吐量。但是，您确实有等待状态，断开连接和事务开销。
如果您的用户应用程序可以承受长时间突发，并且您正在通话的器件可以在不断开连接或插入等待状态的情况下维持突发，那么您可以开始达到正在运行的总线大小/速度的理论最大带宽。
32/33 PCI的最大理论带宽为132 MB /秒，但您很少能达到100％。这假定无限长的突发，没有等待状态，没有总线延迟。但在PCI中，您有初始事务开销，可能的等待状态以及可能发生的断开连接。如果要查找设计可以达到的确切数字，则必须计算传输的数据量除以传输数据所需的时间。
例如，您的用户应用程序希望在32位/ 33 MHz总线上执行256 Dword或1024字节的内存写入。有5个周期的事务开销（这不准确）。如果没有等待状态，则可以每30 ns传输1个Dword;如果你可以在一个突发中完成所有操作，那么你可以在7680 ns内传输256个Dword。添加5个周期的开销（5 * 30），在7830 ns或大约130 MB /秒内传输1024个字节。
假设您的用户应用程序无论出于何种原因都无法维持此突发长度，并将其分为两个128 Dword突发。在这种情况下，您将获得2 128个Dword传输，每个30 ns，每次传输时间为3840 ns，加上10个周期的开销，产生300 ns的开销，为1024字节数据提供总共7980 ns，或128 MB /秒。这不计入转移之间的时间，这将使其更低。
用户应用程序是限制因素，而不是核心。如果您知道用户应用程序的工作情况，那么您可以计算吞吐量。您可以查看设计指南，以确定核心在各种事务类型上引入的事务开销。这将在每次转移时保持一致。
没有回复内容