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.
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
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
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
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?
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.
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.
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.
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 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.
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....
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.
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 ?
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.
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 ?
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.
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 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 ?
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.
Comments
By 10MHz, there is severe phase lag and attenuation.
Nice!
The Sinc3 version stops at diff3 and ignore diff4.
It's Evan's diagram in code.
EDIT: And true, acc3 is just a copy of the real thing so it can be z.
Sinc3:
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
It took good insight to break it down so nicely. That reveals the concept better, actually. Wow!
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:
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.
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.
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.
These are 8-clock samples @240MHz, making 30M samples/second.
The analog input is a 1.2MHz sawtooth.
Here is Sinc3:
And here is Sinc6!!!:
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.
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.
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.
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 ?
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.
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 ?
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.
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 ...
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 ?
This Sinc3 thing is different enough that it's going to become its own mode. There's no overlap with other modes, almost.