--- Quote Start ---
There were no reported timing problems for this circuit. If the timing did not pass, I would expect the design to fail over a period of time, but it does not. Only at the beginning. The rdreq is effectively used to create a single clock pulse in the middle of the rdreq pulse. The rdclk clock pulse simply looks like a delayed rdreq pulse, so it is guaranteed to clock in the middle of the asynchronous rdreq pulse. The problem as I see it is that if I use a fixed clock input for the rdclk signal, I may or may not get a clock edge during the period when rdreq is actively high, so the words do not clock through the fifo during the read. I tried this originally and I could see on my logic analyzer that the rdreq pulse was not synchronized to any clock and if I used a faster rdclk, I sometimes got more than one clock edge when rdreq was asserted. This caused data loss at the output. The rdreq pulse is generated by PCI local bus register read, so the rdreq timing is dependent upon the PCI local bus cycle. At the moment I am thinking of creating two dummy reads of the fifo in hardware, immediately after doing an aclr, instead of handling dummy reads of the fifo in software. Am I explaining it ok ?
--- Quote End ---
When you say rdreq is decided by PCI then surely it is asking for data read relevant to some clock (not just rdreq) then use that clock as rd clock and use rdreq as it is rdreq. what stops you doing that.
Moreover I feel your write clk is also not a clean 4MHz clock but some combinatorial clk based on 32MHz clk.
If it works then I wouldn't worry now but problems could pop up later.
Honored Contributor
