MAX10 ADC Core Channel Sequence Issue

[Altera_Forum]

Hi All, 

 I am having a small issue with the ADC Core-only IP. I have two channels enabled (11 and 12) and a controller that sequences between them: Once 11 is converted, it starts 12, then 11, and so on.   The problem is that when response_channel is 11, and response_valid is 1 response_data is showing the ADC count that corresponds to channel 12.  Here is a screenshot from the Signal Tap I have setup. The Signal Tap clock is 100 MHz, ADC Clock is 10 MHz https://i.imgur.com/ytuzpyc.png  I was tying channel 12 (ADC1IN12, PAD F2 on 10M04DAF256C8G) low and tying channel 11 (ADC1IN11, PAD E3 on 10M04DAF256C8G) to the analog supply voltage. As you can see from the waveform, the ADC is reporting that channel 11 is low and channel 12 is tied high.  Any ideas why this might be happening? This seems like a fairly simple interface and my control signals seem to match that of the user manual. Any help would be greatly appreciated.  - Sam

[Altera_Forum]

There is a latency between when you access a channel and when the data for that channel is available. See the timing diagram in the ADC timing section of the user guide. You're seeing what is referred to as the t2 timing, I believe: 

 3 ×ADC soft IP clock + (2/sampling rate) + (1/Sampling rate)

[Altera_Forum]

I don't see how the t2 timing would be the culprit. 

 The IP that controls the ADC core is quite simple: It sets the command_valid signal high, and increments the command_channel after command_ready goes high. The other signals I am looking at with the signal tap.  I just did another test where I issued commands in the following sequence: 11, 11, 12, 12 and got the data in this sequence: 12, 11, 11, 12  So that does support the notion of latency, but based on the ADC timing diagram, my design _should_ account for that.   Thank you for the response.

[Altera_Forum]

Instead of doing an even number of reads, do an odd number (3 for 1 channel, 1 for the other). That would prove latency definitively.

[Altera_Forum]

I can try that. 

 I am really confused by "response_valid", "response_channel", and "response_data".  Based on what I am reading in the User Guide, when response_valid goes high that data on response_data will correspond to the response_channel.  I don't see how a latency issue (command_valid is held high, and I simply increment the command_channel when command_ready is asserted - all I control is command_channel, nothing else) could cause response_data to be for a channel other than response_channel...   adc_inst : component adc_core port map ( clock_clk => clk10, reset_sink_reset_n => '1', adc_pll_clock_clk => clk10, adc_pll_locked_export => pll_lock, command_valid => '1', command_channel => adc_command_channel, -- Set this on adc_command_ready command_startofpacket => '0', -- Unused on ADC core command_endofpacket => '0', -- Unused on ADC core command_ready => adc_command_ready, response_valid => adc_response_valid, response_channel => adc_response_channel, response_data => adc_response_data response_startofpacket => open, -- Unused on ADC core response_endofpacket => open -- Unused on ADC core );     response_valid, response_channel, and response_data are just signals used for the Signal Tap LA. adc_command_channel is incremented when adc_command_ready goes high.  I have tried delaying the reset and command_valid signals several thousand clock cycles after pll_lock goes high, but this did not make any difference.   The control is so simple, that even if I am dealing purely with a latency issue the only way I see around it is to either keep track of which channel is really getting reported from the ADC, or just convert each channel twice. Doing a double conversion is not desirable because it would cut our sampling rate in half.

[Altera_Forum]

Sorry, I think I somehow missed that you were getting the opposite voltage measurement for the two channels. 

 There's still latency for when a value becomes available, but yes, the voltage should correspond to the appropriate response channel. Any chance you accidentally have the analog input pins swapped?

[Altera_Forum]

That was my first thought, but the EE's assure me that the schematic that I have is the correct one. I have been beating my head against this longer than I would like to admit.  

 Also, when I do a single channel (say, channel 11) it works as expected - That is decent proof that electrically the sources are tied to the correct pads.  Thank you for your help, - Sam

[Altera_Forum]

OK, that's really weird. 

 As the timing diagram shows, are you seeing the command_ready signal at the end of the t1 time (with no response yet; response_valid is low) when you first access the first channel?

[Altera_Forum]

--- Quote Start ---  OK, that's really weird.  As the timing diagram shows, are you seeing the command_ready signal at the end of the t1 time (with no response yet; response_valid is low) when you first access the first channel?  --- Quote End ---    Yes, everything looks like it is working as expected other than the response_data being for a different channel than response_channel shows. Unfortunately time is short, so I have been asked just to register the command_channel and correct the address that way.  Thank you for taking the time to think about it. If I get some more time I will cycle back on it and see what I can figure out.