9054 DMA传输（SG方式）依然不稳定，问题比想象的要严重，而且感觉与主机端程序的进程优先级有关（windows 2000），不知所措：（

曾经发过一个关于该问题的帖子，后来改了fpga上的程序，自以为问题解决了，后来才发现当dma读写循环（就是调用sdk中的PlxDmaSglTransfer，先写，然后立刻读取，每次4096 bytes）数万次后，有上千次的读写数据不一致，这样的错误率（约有 1/20）真是令人不可忍受.......

目前发现，错误率与两个因素有关：
1. 循环的次数：
   几百次时（全对）
   几千次时（1～3次 错，错误率约1/1000，偶尔全对）
   几万次时（有上千次错，错误率约1/20）
2.主机程序的进程优先级
  当主机程序的优先级达到“实时”时，错误率有所下降，但只是下降，仍无法消除。                

现在真是不知所措：（

另：
pci卡上的时钟为50M，采用continue burst mode，传输速度倒是挺理想的，我在想是不是因为pci端跟不上local端，导致9054的fifo被读空或写满造成的

首先没有理由怀疑操作系统或者SDK，我这里的测试要求几乎是极限，但从来不出问题；
测试软件的编写一般也没有什么大问题，但切忌多线程同时操作硬件；
最大的可能仍然是FPGA，这方面设计出错的很多，建议先设计简单的非burst时序，排除其他方面的问题。

首先没有理由怀疑操作系统或者SDK，我这里的测试要求几乎是极限，但从来不出问题；
测试软件的编写一般也没有什么大问题，但切忌多线程同时操作硬件；
最大的可能仍然是FPGA，这方面设计出错的很多，建议先设计简单的非burst时序，排除其他方面的问题。

松涛兄，我有一个疑问：plx SDK3.0里面关于分散集中模式的例子，好像没有涉及“DMA描述符寄存器”里“下一个描述符地址”这一段，是不是说可以不用填写这一段的内容？
谢谢！

感谢版主的关心：）

前面所描述的现象，现在看来其实是一个假象，传输出错的次数其实与文件的长度没有必然联系，而是与文件的内容紧密联系的。现在刻意制造了内容为：
00 00 00 00 FF FF FF FF 00 00 00 00 FF FF FF FF 00 00 00 00 FF FF FF FF 00 00 00 00 FF FF FF FF 00 00 00 00 FF FF FF FF 00 00 00 00 FF FF FF FF 00 00 00 00 00 00

的文件，发现传输该文件（仅几十个字节）每次必错。

现在初步判断是硬件线路本身不稳定，不过还不敢完全排除VHDL代码的时序问题（仅从quartus的仿真来看是没什么问题）.............

[quote]首先没有理由怀疑操作系统或者SDK，我这里的测试要求几乎是极限，但从来不出问题；
测试软件的编写一般也没有什么大问题，但切忌多线程同时操作硬件；
最大的可能仍然是FPGA，这方面设计出错的很多，建议先设计简单的非burst时序，排除其他方面的问题。

松涛兄，我有一个疑问：plx SDK3.0里面关于分散集中模式的例子，好像没有涉及“DMA描述符寄存器”里“下一个描述符地址”这一段，是不是说可以不用填写这一段的内容？
谢谢！ [/quote]
这些寄存器的控制具体都是驱动程序在底层完成的，你自己一般不需要再关心。