Shop OBEX P1 Docs P2 Docs Learn Events
ADC Sampling Breakthrough - Page 13 — Parallax Forums

ADC Sampling Breakthrough

1101113151652

Comments

  • cgraceycgracey Posts: 14,133
    Seairth wrote: »
    cgracey wrote: »
    It's amazing what we can get in 16 clocks, but it's kind of useless when the ADC's front-end analog circuit is only good for a few MHz.

    I've only been marginally following this conversation. What do you mean when you say "only good for a few MHz"?

    By 10MHz, there is severe phase lag and attenuation.
  • SincX code can be simplified:
    	rdpin	accX,#adc	'SincX reading
    	mov	z,accX
    
    	sub	z,diff1
    	add	diff1,z
    
    	sub	z,diff2
    	add	diff2,z
    
    	sub	z,diff3
    	add	diff3,z
    
    	sub	z,diff4
    	add	diff4,z
    
    	...
    
  • If accX not needed again could use that instead of z.
  • cgraceycgracey Posts: 14,133
    TonyB_ wrote: »
    SincX code can be simplified:
    	rdpin	accX,#adc	'SincX reading
    	mov	z,accX
    
    	sub	z,diff1
    	add	diff1,z
    
    	sub	z,diff2
    	add	diff2,z
    
    	sub	z,diff3
    	add	diff3,z
    
    	sub	z,diff4
    	add	diff4,z
    
    	...
    

    Nice!
  • cgraceycgracey Posts: 14,133
    TonyB_, could you please show a Sinc3 version?
  • cgraceycgracey Posts: 14,133
    Remember there''s also SUBR, which may come in handy.
  • cgracey wrote: »
    TonyB_, could you please show a Sinc3 version?

    The Sinc3 version stops at diff3 and ignore diff4.

    It's Evan's diagram in code.
  • evanhevanh Posts: 15,126
    edited 2018-11-24 23:25
    Yes, nice improvement.

    EDIT: And true, acc3 is just a copy of the real thing so it can be z.


    Sinc3:
    	rdpin	z,#adc			'get sinc3 filter value from acc3
    
    	sub	z,diff1
    	add	diff1,z
    
    	sub	z,diff2
    	add	diff2,z
    
    	sub	z,diff3
    	add	diff3,z
    
    
  • cgracey wrote: »
    Yes, when a pin is in ADC mode, its delta-sigma stream is fed into the IN signal, regardless of any smart pin mode on top of that.

    The Sinc3 mode will look at the IN signal from the low-level pin, which could be in ADC mode or some other mode.

    It's possible to build the integrator outside the pin, using a coupling cap and clocked negative-feedback logic mode with resistive drive (%0001_101001001, I believe, for 1.5k). Then, you certainly overcome the internal bandwidth problem of the ADC, but need a lower-impedance source. I will try this in a little bit.

    Is there any hope we could, by some means, link the IN signal directly to the SERDES input, and use the synchronous serial receive smart pin mode to 'grab' up to 32 consecutive samples, in order to allow any Cog to be at least reliefed from the bit-picking-and-shifting task?

    Shure, there would be the need to compromise a nearby smart pin, in order to generate the clocking, both for the Serdes and the ADC, unless the same 'special' synchronous mode could also use the Smart pin self-contained NCO to generate a 'hidden' shift clock.

    IMHO, for some low-frequency sampling needs, it can free a Streamer at least, by allowing for the Cog to get the values and process them localy, without being 'forced' to yeld to the Hub.
  • jmgjmg Posts: 15,140
    Yanomani wrote: »
    Is there any hope we could, by some means, link the IN signal directly to the SERDES input, and use the synchronous serial receive smart pin mode to 'grab' up to 32 consecutive samples, in order to allow any Cog to be at least reliefed from the bit-picking-and-shifting task?

    Shure, there would be the need to compromise a nearby smart pin, in order to generate the clocking, both for the Serdes and the ADC, unless the same 'special' synchronous mode could also use the Smart pin self-contained NCO to generate a 'hidden' shift clock.

    IMHO, for some low-frequency sampling needs, it can free a Streamer at least, by allowing for the Cog to get the values and process them localy, without being 'forced' to yeld to the Hub.

    I'm not quite following here ?
    The streamer is used only on Rev A silicon, on Rev B (if this makes the cut), there is no 'bit-picking-and-shifting task' done by COG

    For testing tho, yes, you could use SERDES for example, to collect samples, but no faster than Streamer can now.
    Those isolated ADC's I linked above, can connect to a 32b SPI, and IIRC chip has designed SERDES so it can continually receive data
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Yes, nice improvement.

    EDIT: And true, acc3 is just a copy of the real thing so it can be z.


    Sinc3:
    	rdpin	z,#adc			'get sinc3 filter value from acc3
    
    	sub	z,diff1
    	add	diff1,z
    
    	sub	z,diff2
    	add	diff2,z
    
    	sub	z,diff3
    	add	diff3,z
    
    

    It took good insight to break it down so nicely. That reveals the concept better, actually. Wow!
  • cgraceycgracey Posts: 14,133
    edited 2018-11-25 00:07
    Yanomani wrote: »
    cgracey wrote: »
    Yes, when a pin is in ADC mode, its delta-sigma stream is fed into the IN signal, regardless of any smart pin mode on top of that.

    The Sinc3 mode will look at the IN signal from the low-level pin, which could be in ADC mode or some other mode.

    It's possible to build the integrator outside the pin, using a coupling cap and clocked negative-feedback logic mode with resistive drive (%0001_101001001, I believe, for 1.5k). Then, you certainly overcome the internal bandwidth problem of the ADC, but need a lower-impedance source. I will try this in a little bit.

    Is there any hope we could, by some means, link the IN signal directly to the SERDES input, and use the synchronous serial receive smart pin mode to 'grab' up to 32 consecutive samples, in order to allow any Cog to be at least reliefed from the bit-picking-and-shifting task?

    Shure, there would be the need to compromise a nearby smart pin, in order to generate the clocking, both for the Serdes and the ADC, unless the same 'special' synchronous mode could also use the Smart pin self-contained NCO to generate a 'hidden' shift clock.

    IMHO, for some low-frequency sampling needs, it can free a Streamer at least, by allowing for the Cog to get the values and process them localy, without being 'forced' to yeld to the Hub.

    Yanomani, I've thought, too, that it would be neat to have a serdes mode where it just serializes or deserializes on every clock. You must just keep it fed/read in software by being perfectly timely. It would not need the streamer to shift data for up to 8 pins:
    	wrfast	#0,start	'ready to record pin states
    
    	rep	#16,samples
    	rdpin	x,#pin+0	'2
    	wflong	x		'2
    	rdpin	x,#pin+1	'2
    	wflong	x		'2
    	rdpin	x,#pin+2	'2
    	wflong	x		'2
    	rdpin	x,#pin+3	'2
    	wflong	x		'2
    	rdpin	x,#pin+4	'2
    	wflong	x		'2
    	rdpin	x,#pin+5	'2
    	wflong	x		'2
    	rdpin	x,#pin+6	'2
    	wflong	x		'2
    	rdpin	x,#pin+7	'2
    	wflong	x		'2 = 32 clocks
    
    ...
    
    	rdfast	#0,start	'ready to output pin states
    
    	rep	#16,samples
    	rflong	x		'2
    	wypin	x,#pin+0	'2
    	rflong	x		'2
    	wypin	x,#pin+1	'2
    	rflong	x		'2
    	wypin	x,#pin+2	'2
    	rflong	x		'2
    	wypin	x,#pin+3	'2
    	rflong	x		'2
    	wypin	x,#pin+4	'2
    	rflong	x		'2
    	wypin	x,#pin+5	'2
    	rflong	x		'2
    	wypin	x,#pin+6	'2
    	rflong	x		'2
    	wypin	x,#pin+7	'2 = 32 clocks
    
  • evanhevanh Posts: 15,126
    cgracey wrote: »
    It took good insight to break it down so nicely. That reveals the concept better, actually. Wow!

    I've just been over and over it trying to be sure there isn't an ordering problem. It's totally one to make you second guess if it's right or not. But, yep, all is good.

  • ErNa wrote: »
    ozpropdev wrote: »
    @ErNa
    Here's some real streams from P2 silicon.
    8 channels of bitstream x 64000 clocks
    Made some first experiments. Looks indeed, 8bit in hex and every bit is a bitstream. What was the clock rate? The at 128 mhz 64ksps are about 0.5 ms?
    And 1MHz of sinusoid has 128 Samples/period?
    Clock rate was 80 MHz
  • cgracey wrote: »

    Yanomani, I've thought, too, that it would be neat to have a serdes mode where it just serializes or deserializes on every clock. You must just keep it fed/read in software by being perfectly timely. It would not need the streamer to shift data for up to 8 pins:

    Yes, it was the way I thought about using the serdes. They would be usefull to throw internal data and status, away out , thru the pins, to be captured, says, by a >500 Msps logic analyzer

    I was throwing the ADC into the mix, as another possible use case.

    That was the reason I've tryed to use the NCO, to ensure we can use a slower clock, if we need to pace things at a different rate, other than sysclock.

    And WOW! Those REP loops are a nice example of grabbing/setting eight pins, in sequence, within the same 32-sysclock time budget.
  • evanhevanh Posts: 15,126
    edited 2018-11-25 01:40
    jmg wrote: »
    I presume the sample-depths here (Up to the rollover limit) will be user selectable.

    It's inherent in whatever interval the software chooses to sample (decimate) the accumulator at. It's up to the software to keep a stable pace and perform tracking using the "diff"s.

    EDIT: So synchronous sampling of multiple smartpins won't work for Sinc3, there isn't any flops left for doing a timer and latch. Maybe this is a reason to also have a SInc2.

  • cgraceycgracey Posts: 14,133
    edited 2018-11-25 01:49
    I did some experiments to find the limits of high-speed A/D.

    These are 8-clock samples @240MHz, making 30M samples/second.

    The analog input is a 1.2MHz sawtooth.

    Here is Sinc3:
    Sinc3_8_clocks.jpg


    And here is Sinc6!!!:
    Sinc6_8_clocks.jpg
    1024 x 576 - 176K
    1024 x 576 - 160K
  • jmg wrote: »

    I'm not quite following here ?
    The streamer is used only on Rev A silicon, on Rev B (if this makes the cut), there is no 'bit-picking-and-shifting task' done by COG

    For testing tho, yes, you could use SERDES for example, to collect samples, but no faster than Streamer can now.
    Those isolated ADC's I linked above, can connect to a 32b SPI, and IIRC chip has designed SERDES so it can continually receive data

    I wasn't intending to sample the pins any faster than the streamers can do.

    In fact, I had threw the NCO into the mix, in order to time the bit-acquisition rate way slower than this.

    Sorry if the way I choose to compose it, suggested it was my intention to do it the other way.


  • evanhevanh Posts: 15,126
    That's a cool display mode on the scope.

    The ADC is tracking peak to peak in 50ns. What is the input voltage swing? The bottom corner will be truncated by that much which I guess can tell us an attenuation figure.


  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    That's a cool display mode on the scope.

    The ADC is tracking peak to peak in 50ns. What is the input voltage swing? The bottom corner will be truncated by that much which I guess can tell us an attenuation figure.


    The input voltage swing is 3.3V. I turned off vector displaying on the scope, so it just shows sampling.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Yes, when a pin is in ADC mode, its delta-sigma stream is fed into the IN signal, regardless of any smart pin mode on top of that.

    The Sinc3 mode will look at the IN signal from the low-level pin, which could be in ADC mode or some other mode.

    I think that was a yes to my external (typcailly isolated) SDM bitstream support ?
    In this case, the Sinc adder also needs to be bit-stream sync'd, not SysCLK speed. Will that be supported ?
    The examples I linked seem to use 10MHz or 20MHz as link-clocks, and some generate the clk, and some have CLK-in designs.


  • Sampling a 1.2Mhz sawtooth now, wow. It still looks fairly linear, so it will be interesting to see if/how a P2 might be able to digitize an analog NTSC/PAL video signal at some point....
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    Yes, when a pin is in ADC mode, its delta-sigma stream is fed into the IN signal, regardless of any smart pin mode on top of that.

    The Sinc3 mode will look at the IN signal from the low-level pin, which could be in ADC mode or some other mode.

    I think that was a yes to my external (typcailly isolated) SDM bitstream support ?
    In this case, the Sinc adder also needs to be bit-stream sync'd, not SysCLK speed. Will that be supported ?
    The examples I linked seem to use 10MHz or 20MHz as link-clocks, and some generate the clk, and some have CLK-in designs.


    I could add a Sinc3 mode that only updates when another pin rises. Would that be what's needed? It takes almost nothing to make that happen, since two pin mux's are already present.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I did some experiments to find the limits of high-speed A/D.

    These are 8-clock samples @240MHz, making 30M samples/second.

    The analog input is a 1.2MHz sawtooth.

    Will the rev B silicon be able to run the diff code at 30M, to keep this real time ?
    ~50ns full scale is impressive for an ADC not focused on speed, and could be useful for current sense on high speed switchers.
    That does not need so many bits, & over current is one common requirement.

    On that topic, what is the speed of the Threshold DAC + Comparator, I think you mentioned before ?


    Do we have a silicon LUT adder cost yet, for these adders in the smart pins ?

  • evanh wrote: »
    That's a cool display mode on the scope.

    The ADC is tracking peak to peak in 50ns. What is the input voltage swing? The bottom corner will be truncated by that much which I guess can tell us an attenuation figure.

    So, @240 MHz, 50 nS = 12 clock pulses.

    And a single 1.2 MHz cycle spans for 200 clock pulses.

    Funny thing: the now attenuated noise spikes appear to embody a 7-sysclock-long, phase twist effect.

    Kind of a multi-twist version of a Möebius strip.
  • jmgjmg Posts: 15,140
    rogloh wrote: »
    Sampling a 1.2Mhz sawtooth now, wow. It still looks fairly linear, so it will be interesting to see if/how a P2 might be able to digitize an analog NTSC/PAL video signal at some point....

    Depends on your expectations around colour... ?
    Video sync extract and movement detection should be possible, as should character insertion on the video.
    I wonder if some single-pin sync + character insertion is possible, with carefully time-shared ADC + DACs ?
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    I did some experiments to find the limits of high-speed A/D.

    These are 8-clock samples @240MHz, making 30M samples/second.

    The analog input is a 1.2MHz sawtooth.

    Will the rev B silicon be able to run the diff code at 30M, to keep this real time ?
    ~50ns full scale is impressive for an ADC not focused on speed, and could be useful for current sense on high speed switchers.
    That does not need so many bits, & over current is one common requirement.

    On that topic, what is the speed of the Threshold DAC + Comparator, I think you mentioned before ?


    Do we have a silicon LUT adder cost yet, for these adders in the smart pins ?

    I just grabbed a bunch of raw ADC bits and processed them afterwards. Running 8 clocks per sample would have to be totally done in hardware. Only 4 instructions could execute in that time. On the other hand, acc's and diff's would be low bit-count. It might be good to have modes in hardware for low-sample-count Sinc3 conversions. There will never be time for software to handle these computations. Then, the streamer could have modes to capture these sample runs and drop them into memory, thereby kicking the ball forward slightly and giving software another headache.
  • evanhevanh Posts: 15,126
    cgracey wrote: »
    I could add a Sinc3 mode that only updates when another pin rises. Would that be what's needed? It takes almost nothing to make that happen, since two pin mux's are already present.

    Huh, that is what mode %01100 does. For some reason I thought it didn't. I somehow manage to confuse it with mode %01111.

    I have to go fix my pin mode info again ...
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I just grabbed a bunch of raw ADC bits and processed them afterwards. Running 8 clocks per sample would have to be totally done in hardware. Only 4 instructions could execute in that time. On the other hand, acc's and diff's would be low bit-count. It might be good to have modes in hardware for low-sample-count Sinc3 conversions. There will never be time for software to handle these computations. Then, the streamer could have modes to capture these sample runs and drop them into memory, thereby kicking the ball forward slightly and giving software another headache.


    Flipping this around, if we assumed a 50% COG loading via interrupt, what would be a possible software feed rate, Sinc output to INT ?
    ie 10 LOC equivalent time, gives ~ 6.25MS/s at 50% loading ?
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    cgracey wrote: »
    I could add a Sinc3 mode that only updates when another pin rises. Would that be what's needed? It takes almost nothing to make that happen, since two pin mux's are already present.

    Huh, that is what mode %01100 does. For some reason I thought it didn't. I somehow manage to confuse it with mode %01111.

    I have to go fix my pin mode info again ...

    This Sinc3 thing is different enough that it's going to become its own mode. There's no overlap with other modes, almost.
Sign In or Register to comment.