qizhi请进

qizhi真的很谢谢你!
我现在基本上逻辑没有大问题了,今天早上DMA读数都对了我做了实验对LCLK做不做延迟好象都可以.
还有点小问题就是在DMA寄存器设置好之后这次启动DMA读的数和下次启动DMA读的数不连贯(写进去是连贯的)没事这个我再继续努力了.
总之非常感谢! :P :P

yunyanrong:
   你太客气了。我也为我能够给你实际的帮助而高兴。
“在DMA寄存器设置好之后这次启动DMA读的数和下次启动DMA读的数不连贯(写进去是连贯的)”我不太明白，难道是对FIFO的两次读操作中间的数据不连贯？如果是可能需要注意：BLAST和BTERM，它们可能涉及到上一次数据操作的最后一个。

是的,FIFO的两次读操作中间的数据不连贯.不过我现在有点信心了不象以前很苦恼的样子.继续努力!

不是客气调出来了真的心里很高兴很谢谢.
是的,FIFO的两次读操作中间的数据不连贯.BTERM我直接上拉了,BLAST用于产生READY的.不过我现在有点信心了不象以前很苦恼的样子.继续努力!

qizhi不好意思调试了几天还没有解决两次DMA数据不连续的问题。我想问题会不会出在这里：WEN在FIFO满后就不起作用了，而我要往FIFO中写的测试数据还在一直递增（是一个8位计数器的输出，一直使能计数），所以在我手动DMA读的间隔数据就会不连续，你认为呢？
BTERM、BLAST我不知道还能如何处理，使能BTERM并且用BTERM来产生READY也是一样。

还有我用DMA工具读测试数据时可以读0x10000个数据，可是接上实际信号时却只能读0x4000个，超过此值，DMAISDONE位就一直为0，WHY?
我怎么老是遇见一些莫名其妙的问题。

谢谢你的Large分！
我同意你的观点，即：如果FIFO满了而你没有停止写，则后来的数据只能被忽略了。一般FIFO的FF（满）信号可以用来禁止WEN信号的产生，这样不至于丢失数据（如果前面有缓存）；也可以用HF请求DMA（Demand方式），这样，每当FIFO写了一半时，自动发出DMA请求，然后，数据被读到主机内存，循环往复，只要PC保存数据的能力比较强，则不会丢数据了。
BTERM我没有用过，不知道。Blast为9054发出，似乎原来的READY信号已经用了部分功能，其它我也没有用过其它的了。
最后关于读数的问题，可能与你的系统注册表分配的内存、你的程序申请的内存大小有关，请查看一下是否与此相关。我的测试中就嫌原来的内存太小，没有办法，修改了注册表后，可以得到大的内存了PLXMon的Block、SGL、Shuttle方式的传送全部与此相关。只不过每个需要修改不同的注册表设置。参见PLX SDK说明书。
  

qizhi：还是有问题，你是用什么写的逻辑。我的是Foundation3.0用原理图画的逻辑，你可不可以帮我看一下？我实在是没辙了。

qizhi：还是有问题，你是用什么写的逻辑。我的是Foundation3.0用原理图画的逻辑，你可不可以帮我看一下？我发到你信箱里？我实在是没辙了。

qizhi:单次DMA数据量大的话比如0xd000,则到后面大约0xc000处数据会漏,可以申请0xf000大的空间

我用的是Lattice画的CPLD的逻辑图，Foundation3.0用是XILINX公司的？我没有，你最好作成PDF我或许可以帮你看看。

“单次DMA数据量大的话比如0xd000,则到后面大约0xc000处数据会漏,可以申请0xf000大的空间”我不知道你用的哪个程序测试或者什么DMA方式，我也发现了此问题，且靠修改注册表的方法做了尝试，似乎可以了。我无法全部比较数据，但是抽部分数据测试了。

qizhi上面提到的DMA的问题应该算解决了希望这次是真的没问题了是我的FIFO读使能不对不应该用LWR.

再问一下你是用的Demand方式?是不是直接把FIFO的HF给9054的DREQ0#脚并且设置DMAMODE0的B[12]=1?这样的话启动DMA就是自动的了?那么是HF有效就启动DMA一次就传完呢,还是读的HF不再有效了(有可能只读几个)再等HF有效后再继续传?
还有一种方式:通过HF来触发LOCAL端中断(再映射为PCI中断)在ISR中启动DMA,DMA结束后再触发PCI中断.这种情况就是有两个中断效率不高吧?

qizhi好消息我们采用DEMAND DMA方式也调试成功了，不过上面我问的问题我还是有点不太明白，看来DREQ0是可以启动DMA的了，是这样的吗。
我每次复位板子或加电后读的第一个数据总是0，虽然上电后前面两次DMA数据可以不要但是这样好像也不太爽，你认为呢

我没有发现你说的每次从FIFO读到的数据都是0的问题。你在查吧。
如果Local侧没有CPU可能只能靠DEMAND方式发起DMA，这时实际上是向9054发出请求的，9054再向PC请求。这时，DEQQO（9054）用来请求DMA，且当用HF请求是，如果读到HF无效了，DREQ如果无效则暂时停止DMA，待HF有效时，重新发出DREQ，又重新进入DMA。但是，知道你的DMA请求的Transfer Size到0，上述过程一直是一个不用软件干预。
我的方法是，用HF发出DREQ信号，而当EF来时，DREQ暂时无效，直到下次HF有效。这样，可以有效地利用FIFO的深度，保证每次DREQ有效可以传递一个尽可能的长度。我认为在大数据量、高速数据传递时，这是一个好的设计思路。

qizhi我的demand方式没有用对，因为采的数据有时候对有时候错（高低16位反了个个）。
请问你的DREQ是如此给的吗：HF下降沿来有效，EF下降沿来无效？那么你的DMA COUNT是多少还是FIFO大小的一半吗？
我用HF、EF作为二选一电路的输入，输出为 DREQ的DFF的时钟，这样来产生DREQ，DMA COUNT＝FIFO的一半，数据有时还是会高低16位颠倒。
紧急求救！

数据反了个个是否是ENDIAN模式用成了BIG模式？似乎应该用LITTLE模式。
DREQ是你说的那样。
DMA的COUNT可以是几MB，不是FIFO的大小，这是最为重要的一点。
你的错误估计是逻辑错误所致，未对准？

设成DEMAND模式是不是还要再设DMA的启动位 DMAMODE0[1]？今天测试：DREQ按那样生成，但是如果不设置 DMAMODE0[1]就没有数据。
应该不用再设置了吧？
ENDIAN模式我是设对的，用PLXMON测总是对的，可是用自己写的驱动就是有时错有时对，错的时候要么16位颠倒、要么32位颠倒、要么8位颠倒，我觉得应该是逻辑的问题可是分析了好久没查出问题。真郁闷！真是不能高兴的太早哦。

用PLXMON测总是对的那就确认是软件的问题了。
具体那位请仔细检查9054的手册的定义。除了Demnad模式为，如果你是FIFO应该同时选择本地地址恒定，而不是增加。
但是，需要注意：你自己的程序所调用的函数，如果是PLX的SDK的API，一定注意参数定义。

LOCAL地址是设成固定不变的，虽然用PLXMOM测总对但我还是觉得是逻辑的问题因为数据读出来的表现总是前后颠倒。我的数据入口是8位的，往两个16位FIFO中写，何时写到16位FIFO的高字节何时写到16位FIFO的低字节、何时写1#FIFO何时写2#FIFO,都是由逻辑定的，所以我觉得应该是逻辑的问题，是这样吧？
而且有时候在一次DMA中前面数据顺序对后面不对，我用测试数据都是OK的，可能是实际数据跟时钟的关系没有理解对。

设成Demand模式是不是还要再设DMA的启动位，再程序启动DMA？

自己的驱动测试程序上电后LOCAL寄存器是我设置的值但是再运行一次后就是复位后的值了，怎么回事我没有在程序中做复位操作呀。

这样说确实有可能是FIFO控制逻辑的问题.其实,现在看有这样几种可能:1是写逻辑8~16~32的问题,2是你用FIFO的HF\\EF信号产生DREQ,那么到底是哪个在起作用.
设成Demand模式是不是还要再设DMA的启动位，再程序启动DMA？是.

自己的驱动测试程序上电后LOCAL寄存器是我设置的值但是再运行一次后就是复位后的值了，怎么回事我没有在程序中做复位操作呀。
可能与你用的函数有关,检查一下吧!

2是你用FIFO的HF\\EF信号产生DREQ,那么到底是哪个在起作用.
用HF有效启动DREQ低有效,用EF有效启动DREQ无效,是这样的吧
数据颠倒我就怕当HF或EF时恰好不是写了整32位这样一来读时就会错位,我用低16位FIFO的HF信号能保证吗先写高16位FIFO?
PLXMON测试与自己驱动的区别就是一个是手动启动DMA,一个是DEMAND方式.