0

In reference to this recent question: I'm seeing a problem with that scheme (the second figure, using the FIFOs as "circular buffers", or shift-registers so that old samples are extracted as discarded once it's full):

When I'm writing to one buffer, the RD signal (as in, the read-clock signal) never arrives to that buffer, so even though I feed the (WE & FULL) signal to the RdEnable, the reads never happen, and the incoming values are lost.

Notice that it's not a matter of using the same RdEnable AND trick with the RdClock (which I assume should never be done anyway — the output of a combinational block used to clock FFs). The point is, the Read is issued externally and asynchronously; when a buffer fills, the external system (an MCU) is notified, and an unknown amount of time will pass before that external system starts to issue any reads. Even then, the reads will happen at a completely different speed and 100% asynchronously to the writes (that was the whole point of using the FIFO_DC modules)

Any suggestions?

[EDIT for further explanation]

I have an ADC capturing at fast rate. A CPU needs only certain small chunks of those ADC samples, when some (easy to detect) condition occurs. The FPGA buffers the ADC data in a double-buffer, so that when the condition triggers, I save the snapshot. This is done by switching to the other buffer, and then the CPU will have some time to read the "saved" buffer. So, the WrClock in my case is the ADC output-clock (it's a pipelined ADC), and the RdClock is the CPU's bus RD/ signal. On the write side, no problem (the pipelined ADC outputs an uninterrupted clock); but on the read side, I don't have an always-present clock that I can feed and control it through the RdEN.

Now, the two key aspects related to the problem I'm facing are:

  • When the condition to capture the chunk of ADC data has not triggered, I need the writeable buffer to behave as a shift-register, where each new incoming value kicks out the oldest value in the FIFO (that's what Dave Tweed addressed in his answer to the recent question I linked above). But that part is not working; the simulation revealed the bug: when the buffer is full, the incoming samples are being lost (because there is no RdClock for that FIFO)
  • The RdClock is the RD/ signal from the CPU parallel bus interface; so, it is not always present; when the condition to save the chunk is triggered, the FPGA will notify the CPU, and some time later, the CPU will perform the reads, emptying the FIFO that contains the saved snapshot.

[END EDIT]

Cal-linux
  • 2,029
  • 2
  • 20
  • 37
  • 1
    I am quite familiar with the MachXO3 and their FIFO_DC should be the same as the MachXO2 but honestly I cannot follow your explanation. Can you provide some code/simulation waveform to help understanding the issue? E.g. what you mean with RD? My FIFOs have the following wires: Data, WrClock, RdClock, WrEn, RdEn, Reset, RPReset, Q, Empty, Full, AlmostEmpty, AlmostFull. So generally speaking one feed the clocks and use the En to control the writing flow. No need to do any "tricks"... – Christian B. Sep 20 '19 at 05:19
  • @ChristianB. ‒ I edited the question to address your request for further explanation. – Cal-linux Sep 20 '19 at 11:49

1 Answers1

0

It would seem like the path I was taking is simply "broken".

We actually switched to a pair of RAM_DQ modules acting as circular buffers; their addresses are simply cycling counters (i.e., 10-bit counters that cycle when they do integer overflow); have a fast-enough master clock, and synchronize the RD's and WR's to this master clock so that now we can put logic that decides which of the signals (RD or WR) are going to increase which of the addresses (depending on which buffer is being filled, and which holds the saved snapshot.

The solution to the original structure would have been similar, perhaps: synchronize the RD and WR clocks to some fast-enough master clock, and then I could have placed logic to route clocks wherever needed.

Cal-linux
  • 2,029
  • 2
  • 20
  • 37