6,127
社区成员
发帖
与我相关
我的任务
分享请教大神！CPCI总线传输的过程出现的丢数问题！！！
我现在做的是利用自己画的PCB板与CPCI机箱实现通讯和传数。桥接芯片是PCI9054；本地总线控制模式为：C模式；PCI9054的PCI总线与本地总线的传输模式为：DMA模式。DMA方式选择的是S/G DMA。
问题情况描述：
使用PCI9054作为桥接芯片利用DMA方式将本地端FPGA中FIFO内的数据缓存至PC机上。上位机采集程序中预设每次采数Terminal count值，并在采集程序人机接口设置连续采数次数，实际现象，在每段Terminal count数据量内部没有数据丢失，但是两两Terminal count段之间有不明数量的数据丢失。
可能原因分析：
导致这一现象的表观原因：在完成一次Terminal count设置数据量的DMA传输后，PCI9054对于本地总线的请求Lhold信号长时间失效，即不发出任何本地总线申请，导致FPGA中FIFO溢出并丢失数据。根据9054的芯片手册，9054失去对于本地总线控制权（失效Lhold信号）存在以下几种可能：
1.9054的FIFO已经写满了 2.采集程序预设值terminal count 到了 3. 本地总线Latency Timer被使能且计数值到了 4.PCI9054控制信号BREQi有效 5. Direct PCI—to-Local Bus request is pending 。
而9054恢复对本地总线控制权的条件：1.9054的FIFO有足够的空条目可用 2. 针对Latency Timer导致的Lhold失效，一直等待本地总线Pause Timer到时间。以下针对我的使用情况进行说明。
针对可使LHOLD失效的5种情况，首先，我们的BREQi是人为用下拉电阻连到地的，也就是失效状态，所以可能4排除；针对Direct PCI—to-Local Bus request is pending可能5，由于工作在DMA模式且工作过程中采集程序除了对部分内部寄存器进行初始化外，没有新的对于寄存器的修改，应该也不会突然有另外一种形式的request吧？这方面不是很确定，如果问题出在这里望了解的大神们指出。
后面针对于其他三种可能用本地端FPGA的signal Tap II抓到的控制信号说明问题。
图一，这个指出的是出现问题的Lhold信号，这里由于资源问题，STP只观察到32K数据，Terminal count设置为2048，箭头处lhlold看似不够长而且可能存在由于PCI9054的FIFO写满导致的，所以再找一个Terminal count为500的作为对比，其STP长度仍旧为32K，见图二
图二，由图二可见，Terminal count下降4倍，可排除9054的FIFO写满这个可能1，且在比整个传输周期更长的时间内，下一组传输需要的Lhold信号依旧没有置位。（难道DMA传输每两次Terminal count传输之间的等待时间就是特别长？这点因为在网上找得到的资料以及手册上面都·没有说明，所以如果哪位大神了解请指出）
下面对于图一再给两个局部图。
图三，由于在图一Terminal count=2048的情况下，Lhold信号变化可分为三大段，每个打断内又可分为若干小段，图三截取的是图一中第一大段中的一部分来说明问题，图三箭头处Lhold每12个周期会失去一次控制，这个应该是前面提到的可能三导致的，9054对应的EEPROM中写入的内部寄存器初始值地址为1Ch，1Eh的对应MARBR寄存器，其低8位我们项目中是0Ch，对应就是这个12，所以这个应该是正常的，而且这种对本地总线控制权的恢复也是有规律且很短的。
下面的图四，针对的是图一中三大段之间的lhold失效现象。由于我们采用的是比BLOCK DMA更加高效的S/G模式，所以在采集程序中调用API函数进行PCI9054一些其他内部寄存器初始化时会有一些关于S/G每段长度的设定，针对我们的传输，Terminal count=2048（分三大段）或者=8000（分为9大段）时，除了头尾的两大部分，中间部分Lhold的有效周期都是78*13个，所以认为这种段间的Lhold失效是由于S/G DMA模式的设定导致的（这块不是太确定，如果有懂的还望指出我可能存在的问题）
图四
综上，完成一次Terminal count之后末尾的LHOLD信号长时间不响应的原因暂时锁定在了Terminal count设定上面，两次打包传输之间这个长间隔是PCI9054什么内部决定的无法缩短，该问题解决不了还是我们哪里设定或者信号控制有问题导致的呢？
有没有做过这方面的大神望指导，如果能在论坛上指导那太感谢了，如果问题复杂但是有大神有经验可以解决的同时又有时间，可以接这个私活也请进一步联系QQ：。
我的邮箱是2016203215@tju.edu.cn
问题情况描述：
使用PCI9054作为桥接芯片利用DMA方式将本地端FPGA中FIFO内的数据缓存至PC机上。上位机采集程序中预设每次采数Terminal count值，并在采集程序人机接口设置连续采数次数，实际现象，在每段Terminal count数据量内部没有数据丢失，但是两两Terminal count段之间有不明数量的数据丢失。
可能原因分析：
导致这一现象的表观原因：在完成一次Terminal count设置数据量的DMA传输后，PCI9054对于本地总线的请求Lhold信号长时间失效，即不发出任何本地总线申请，导致FPGA中FIFO溢出并丢失数据。根据9054的芯片手册，9054失去对于本地总线控制权（失效Lhold信号）存在以下几种可能：
1.9054的FIFO已经写满了 2.采集程序预设值terminal count 到了 3. 本地总线Latency Timer被使能且计数值到了 4.PCI9054控制信号BREQi有效 5. Direct PCI—to-Local Bus request is pending 。
而9054恢复对本地总线控制权的条件：1.9054的FIFO有足够的空条目可用 2. 针对Latency Timer导致的Lhold失效，一直等待本地总线Pause Timer到时间。以下针对我的使用情况进行说明。
针对可使LHOLD失效的5种情况，首先，我们的BREQi是人为用下拉电阻连到地的，也就是失效状态，所以可能4排除；针对Direct PCI—to-Local Bus request is pending可能5，由于工作在DMA模式且工作过程中采集程序除了对部分内部寄存器进行初始化外，没有新的对于寄存器的修改，应该也不会突然有另外一种形式的request吧？这方面不是很确定，如果问题出在这里望了解的大神们指出。
后面针对于其他三种可能用本地端FPGA的signal Tap II抓到的控制信号说明问题。
图一，这个指出的是出现问题的Lhold信号，这里由于资源问题，STP只观察到32K数据，Terminal count设置为2048，箭头处lhlold看似不够长而且可能存在由于PCI9054的FIFO写满导致的，所以再找一个Terminal count为500的作为对比，其STP长度仍旧为32K，见图二
图二，由图二可见，Terminal count下降4倍，可排除9054的FIFO写满这个可能1，且在比整个传输周期更长的时间内，下一组传输需要的Lhold信号依旧没有置位。（难道DMA传输每两次Terminal count传输之间的等待时间就是特别长？这点因为在网上找得到的资料以及手册上面都·没有说明，所以如果哪位大神了解请指出）
下面对于图一再给两个局部图。
图三，由于在图一Terminal count=2048的情况下，Lhold信号变化可分为三大段，每个打断内又可分为若干小段，图三截取的是图一中第一大段中的一部分来说明问题，图三箭头处Lhold每12个周期会失去一次控制，这个应该是前面提到的可能三导致的，9054对应的EEPROM中写入的内部寄存器初始值地址为1Ch，1Eh的对应MARBR寄存器，其低8位我们项目中是0Ch，对应就是这个12，所以这个应该是正常的，而且这种对本地总线控制权的恢复也是有规律且很短的。
下面的图四，针对的是图一中三大段之间的lhold失效现象。由于我们采用的是比BLOCK DMA更加高效的S/G模式，所以在采集程序中调用API函数进行PCI9054一些其他内部寄存器初始化时会有一些关于S/G每段长度的设定，针对我们的传输，Terminal count=2048（分三大段）或者=8000（分为9大段）时，除了头尾的两大部分，中间部分Lhold的有效周期都是78*13个，所以认为这种段间的Lhold失效是由于S/G DMA模式的设定导致的（这块不是太确定，如果有懂的还望指出我可能存在的问题）
图四
综上，完成一次Terminal count之后末尾的LHOLD信号长时间不响应的原因暂时锁定在了Terminal count设定上面，两次打包传输之间这个长间隔是PCI9054什么内部决定的无法缩短，该问题解决不了还是我们哪里设定或者信号控制有问题导致的呢？
有没有做过这方面的大神望指导，如果能在论坛上指导那太感谢了，如果问题复杂但是有大神有经验可以解决的同时又有时间，可以接这个私活也请进一步联系QQ：。
我的邮箱是2016203215@tju.edu.cn
...全文
请发表友善的回复…
发表回复
