LogiCORE RapidIO – 来自维护写入（写入新器件ID）的响应数据包具有源器件ID字段的新器件ID

问题描述

执行维护写入时，您要写入的特定寄存器是DeviceID（偏移量0x60），返回的响应将在源器件ID字段中具有新的器件ID。

RapidIO Common Transport规范第2.3节规定：

————————————————– —————————————-

当请求包的目的地生成响应时

数据包，它从请求交换源和目标字段，使得

原始来源新目的地和自己的新来源。数据包被布线

通过基于目标器件ID的结构。

————————————————– —————————————-

Xilinx RapidIO Core以这种方式生成响应数据包;但是，在维护写入和写入新器件ID的情况下，核心将首先执行对CSR / CAR的写入，然后提取新器件ID作为源。因此，使用新器件ID作为源器件ID（而不是旧器件ID）生成响应分组。

这样做是为了减少资源使用;通过不传递器件ID，这节省了100个触发器加20-40个LUT的顺序。

解决/修复方法

如果这是一个问题，以下是可能的解决方法：

1.在核心生成期间定义器件ID，无需动态更改器件ID。

2.不要求在到达的请求数据包上捕获目标ID，也不要求在传出数据包上提供源ID。 （忽略维护响应中的源ID不匹配。）

3.发送带有目标ID的维护数据包作为您正在编写的新值。

例如：

XCore初始deviceID = 0xFF

如果要更新到0x55，请将总线主机（例如，deviceID 0x00）的维护数据包发送到Xilinx Core，其中包括：

DestinationID = 0x55

SourceID = 0x00

偏移= 0x60

数据= 0x0055.0000

当Xilinx内核（仍然使用DeviceID 0xFF）收到此数据包时，它不会丢弃它（即使存在器件ID不匹配，因为内核不进行内部比较）。 Xilinx核心假设作为端点，所有收到的数据包都是针对此端点的。

来自核心的最终维护响应数据包将标记为：

DestinationID = 0x00

SourceID = 0x55

状态=确定

XCore最终DeviceID = 0x55

4.将在v4.4中更新Xilinx核心以更改此行为。有关修复程序的可用性，请联系Xilinx支持：

http://www.xilinx.com/cn/support/mysupport.htm(Xilinx 答复29936）在打开技术案例并要求RapidIO专家时。