PCIE-message

latency tolerance reporting message

用于报告读写设备之间的latency；

Bit15：requirement，仅在此bit为1的情况下，后续的latency value，latency scale才有效；

具体的latency值为latency_value * latencyscale，范围在1ns~225*(210-1)的范围之间；

针对latency本身的一些说明：

（1）需要考虑使用clock power mangement引起的delay（assert CLKREQ#到设备收到有效的clock信号之间的时间）；

（2）针对non-posted request，latency是从发送tlp的最后一个symbol到收到第一个cpl之间的延迟；

（3）由于flow control的反压机制，发了一个posted request之后，不能再次发送另一个posted request的情况下，Latency是从发送上一个posted request的最后一个symbol到收到dllp的credit的第一个symbol之间的时间。

一些需要注意的点：

（1）一旦设备进入到DL_Down状态，port之前记录的latency value均变成无效的了；

（2）建议ep在LTR机制enable之后’shortly’发送LTR message；

（3）建议设备不要在500us之间发送超过两个的LTR message；

（4）为什么又snoop和no-snoop两种latency？应该是区分device设备，可能存在这两种设备

一些发送message的时间点：

（1）当通过写PMCSR寄存器进入到一个non-D0状态的话，如果设备最近传输过LTR message（自从上次从DL_down状态变为DL_up状态），并且这个message中的latency field只要有一个requirement为1，那么此时在进入到D0状态前必须要发送一个LTR message，并且这个message的latency field中的两个requirement必须均为0；

（2）参考controller中关于cfg write个FLR实现对LTR机制的关闭准则；

关于multi function中的LTR：

待补充；

关于switch中的LTR：

待补充；

关于RC中的LTR：

RC运行delay处理收到的TLP请求，但是需要注意的是，假如收到了一些列的TLP请求，在这个过程中latency requirement更新了，需要先更新layency的数值，在处理随后的请求，更新的latency value值起作用的时间必须在之前更新的lantency值之内。

controller：

主动产生LTR meesage的几种方式：

（1）通过SII：app_ltr_message_req；

App_ltr_msg_latency：指示发送的meesage内容？那为什么还有app_ltr_func_num这个信号线？

Output信号线，作为输出显示当前使用的latency是多少。

（2）直接在XALI0/1/2接口上发送msg；

补充:关于XAL0 interfcae的说明：

Client0_tlp_byten_en[7:0]:

针对first dword的tlp和last的dword的Byte_enable；

Client0_tlp_addr[63:0]:

发送cpl的时候[6:0]作为cpl中lower address域；

发送MEM 32/IO/CFG三种操作的时候，存在3-dword；第三个dword是[31:0];

发送MEM 64/MSG，第四个dword是[31:0]，第三个dword是[63:32];

前两个dword通过信号clinet_tlp_tc/attr/fmt/type/ep/byte_len/th/td/attr等信号表示。

（3）通过在XALI0/1/2上发送I/O或mem tlp，通过iATU转换成LTR message；

当MEM tlp的地址成功匹配+tlp的type field是IATU_REGION_CTRL_1_OFF_OUTBOUND_I，此时message code会从IATU_REGION_CTRL_2_OFF_OUTBOUND_I寄存器中获取，长度为0的mem wr转变为msg，非0的转变为msgd。

这里有问题，没理解。

自动产生message的几种方式：

（1）通过写Power Management Control and Status register中的Power State field使得function到达一个non-D0状态（LTR机制在上次从DL down到DL up的过程中就被active了）；这一点对应协议

（2）通过cfg write或者FLR实现对Device Control 2中的LTR Mechanism Enable写0可以关闭LTR机制，如果关闭该机制的话，并且此前在DL_down转变为DL_up之后发送了LTR message，这个message的requirement设为1了，那么设备需要重新发送一个新的LTR message，并且requirement为0；

通过设置MISC_CONTROL_1_OFF中的DISABLE_AUTO_LTR_CLR_MSG为1，自动产生LTR clear message的机制可以被关闭

LTR机制是否使能是通过cfg_ltr_m_en这个信号新显示；另外需要注意的是当Device Control 2 Register中的LTR Mechanism Enable为0的时候，不能发送LTR meesage（通过系统侧），此时controller是不会block产生的LTR message。