Multiplexing inputs into ADC and reading the digitized outputs with XEM6010

Spartan-6 USB 2.0 Modules
1

I’m having trouble with a specific application. My hardware looks like this:

→ One 16-to-1 multiplexer with independently programmable input channels
→ The output of the mux is connected to the input of a 14-bit, parallel ADC, and each of the ADC bits [13:0] is wired up to the XEM6010 module.
→ ADC sampling rate ~1 MHz, slow enough to avoid settling issues with the multiplexed ADC system.

I am trying to multiplex all 16 inputs in real-time and to capture all chunks of data in one data stream. My test case is to ground the first 15 the inputs (which I can effectively do on my PCB), and bias the last input with a DC voltage (e.g. 3.2 Volts).

HDL:
In my Verilog HDL, I have a so-called wrapper module which switches the multiplexer select lines (mux_sel[3:0]) on one positive edge of a clk, and subsequently samples the ADC on the following positive edge. I am using a simple 64k, 16-bit wide FIFO to pipe data out; for simplicity, I use a PipeOut to read data from my relatively large FIFO block. Top-level code is listed here for reference: Dropbox - Error. The ‘realtime_mux_counter_2’ module simply guarantees that selecting the proper mux select lines never coincides with sampling the ADC, as described before.

Python:
I am using Python to communicate with the Opal Kelly, but I am trouble recovering the data in a bitstream. With my contrived example from before, I expect something like this to appear in the computer (units in Volts): [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3.2]. This does not happen reliably.

Does any one have any insight as to what may be going wrong? Any feedback or further comments are appreciated.

2

Note that resetGlob is technically on the TI_CLK domain, but you’re using it on the CLK2 domain in some places. It’s good practice to synchronize it to the new domain for reliability.

Have you checked EMPTY or FULL to see if the FIFO is overflowing or underflowing?

ChipScope may also be helpful in finding any synchronization or overflow/underflow situations.

3

Thank you for the prompt reply. I sent the EMPTY and FULL flags to the LEDs, so that I can monitor them effectively. This is certainly helping with my debugging process.

With regards to your comment on my reset signal, how can I ensure tat the CLK2 domain controls the reset? Are you simply implying I use synchronous reset with CLK2? Since this is a slower frequency than TI_CLK, once the CLK2 signal resets, the TI_CLK should have already reset some time early…

4

Yes, you should synchronize your reset to whatever clock domain logic is using. Otherwise, you can have a situation where some registers exit reset a cycle earlier than other registers, wreaking havoc on a state machine.