qizhi请进

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

有许多种。
要开关式的还是线性的。线性的简单点就是7905。开关式的我还没有用过，但我相信一定可以找到，如MAXIM、TI等都应该有。
电流大时注意散热。电流不大也可以用稳压管加电阻实现。

qizhi你知道有没有-12V转-5V的变压器？

对，应该用地址译码，事实上，我已经这么做了。FIFO所占的地址空间很少。

需要再设计一块PCI卡，LOCAL端有两个FIFO，一个用于PCI->LOCAL，一个用于LOCAL->PCI，还有一个器件需要PC通过9054设置。速率要求不高。这样可以吗？可是9054的LOCAL空间只有两个呀（不太想用9050或其它，不熟）而我需要3个。而且两个FIFO的片选怎么办？都必须做地址译码吗？（我现在一个FIFO就没管译码）

qizhi我给你发了邮件

如果你方便高速我你的手机好，我们可以用短信及时联系，如果短信写困难可以在发出邮件后发短信通知。
我的EF、HF信号的产生与你有区别，我是靠异步逻辑自动产生的，与LCLK无关。感觉你说的问题似乎不存在。因为数据不可能在总线上残存太久。请再检查。

主要是这样问问题太慢还得等一两天。
写FIFO侧我的刚好和你的相反，先写高16位再写低16位，然后用低16位FIFO的HF、EF按照以前的说法产生DREQ信号，读FIFO的信号和READY信号一样。感觉有的32位数据会重复一次，这会不会是读空了而DREQ还有效，又读了总线上残余的该数？EF后应该立马让DREQ无效。你就是按照将HF、EF做为时钟二选一电路来产生DREQ的吗？

yunyanrong:
抱歉，我密友QQ号，一般没有时间去聊天。可以发邮件给我。
qizhi_liu@263.net.
关于DMA的问题，我想我们可能理解的不一样，既然是DMA，看是否可以将DMA的块大小增加？128K似乎小了点，这样你靠中断去通知主机一次DMA传送的结束就会比较频繁。例如：如果你的DMA速度是20MB/S，是否可以干脆将DMA的块大小设置成8MB、16M等，这样1S只需要1~2次中断，应该比较少，主机响应可能会更加及时。
你说的INTA#频率与示波器测量的频率不对应我说不太清楚，可能有软件的问题，示波器测量频率准确码？如果一定测量其频率最好用频率计。

qizhi我进数据的速率是20MB,DMA的大小是128KB，那么DMA中断的频率应该是20M/128K＝160HZ，可是我用示波器量INTA#却是145～151Hz左右，频率值不对而且还不停的在该范围内变，这应该不对吧。
能不能交个朋友？我的OICQ是23090113。

我未发现你说的问题，但我可能测试不全面？
我的写FIFO侧可以保证先写低16位再写高16位，然后用高16位FIFO的HF、EF按照我以前的说法产生DREQ信号，我未发现颠倒问题。我认为关键是写FIFO的顺序与读FIFO的信号的关系。按照我的设计，可以保证，只有有信号就有写好的数据，只要保证CPLD的控制逻辑没有问题。建议再查一下你的逻辑。

今天发现如果用HF和EF则数据会出现各种颠倒，但是如果只是简单的将DREQ=HF，则数据OK。这是为什么？
但是这种效率肯定低也不知道如何评测性能够不够。

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

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

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

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

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

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

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

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

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

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

我没有发现你说的每次从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有效可以传递一个尽可能的长度。我认为在大数据量、高速数据传递时，这是一个好的设计思路。