MAX10 ADC Core Channel Sequence Issue

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.