TonyB_, I don't know why it should be, but that Tukey 16*/33 is noisier than the Tukey 17*/32. It must have something to do with the frequency of data cycling in the ADC bitstream as it interacts with the side lobes of the window.
That appears to be the opposite of the spectrum analysis. Tukey16 has a deep null where the noise is highest. Yet it's only better on 9 of 16 tests.
I would be interested to know if the noise peaks tend to stay at a fixed ratio with the system clock, or if their absolute frequency is relatively constant.
Chip,
Tony explained it enough for me, pruning creates bigger steps so smoothness is harmed.
JMG,
Yep, polarity and source are well covered in the general smartpin config.
Just the mode itself has to have edge counting option is all, ie: the bit-level becomes an enable for counting clock pulses. Chip has separated gated edge counting and level counting into separate modes, %01100 and %01111 respectively, for Sinc1.
Not sure if Chip plans to merge the two or have two modes same as Sinc1.
3dB bandwidth rises from 3.4MHz to 5.8MHz. 6dB bandwidth rises from 4.6MHz to 7.9MHz. Both of these neglect the effects of the analog circuitry.
It should be cheap to do. Just add a MUX to switch the input into the 31 on the end. So the bits can go through the full flat section in the middle or just part. And an AND after the third 32 in the center. This would prevent the bits in the bypassed section from affecting the output. (after enough clocks to flush them out)
I won't ask for the output to be rescaled. It would just multiply the noise.
3dB bandwidth rises from 3.4MHz to 5.8MHz. 6dB bandwidth rises from 4.6MHz to 7.9MHz. Both of these neglect the effects of the analog circuitry.
It should be cheap to do. Just add a MUX to switch the input into the 31 on the end. So the bits can go through the full flat section in the middle or just part. And an AND after the third 32 in the center. This would prevent the bits in the bypassed section from affecting the output. (after enough clocks to flush them out)
I won't ask for the output to be rescaled. It would just multiply the noise.
Saucy, perfect!!!
We needed something like this to accommodate higher bandwidth, and a reduction in resolution is to be expected. I like the idea of not rescaling the output, but making 128 the peak, to keep absolute noise constant.
We will use the single, unused 'cfg' bit 6 to select this mode.
And this can all occur at the D inputs of the 'tap' flops with a mux, in order to avoid lengthening the filter computation time.
Chip,
Tony explained it enough for me, pruning creates bigger steps so smoothness is harmed.
JMG,
Yep, polarity and source are well covered in the general smartpin config.
Just the mode itself has to have edge counting option is all, ie: the bit-level becomes an enable for counting clock pulses. Chip has separated gated edge counting and level counting into separate modes, %01100 and %01111 respectively, for Sinc1.
Not sure if Chip plans to merge the two or have two modes same as Sinc1.
Evanh, I'll post the new mode map shortly.
I compacted the main USB modes from four down to two, making the low/full-speed mode selectable by X[15] via WXPIN.
The two SINC3 modes sit where the first two USB modes were. The first SINC3 mode accumulates PinA on every clock, while the second SINC3 mode accumulates PinA only when PinB rises, making it externally clockable. I will post the code soon, as it has changed slightly.
Has the logic for the different modes been combined as much as possible yet?
In Sinc3, acc1 can be a counter, so only need adders for acc2 and acc3. jmg has asked a couple of times whether acc2 could use an existing NCO adder, leaving just acc3 as a new adder.
The Sinc3 logic could also do Sinc1 and Sinc2 if half the adder inputs are held low, so that acc3=acc2=acc1 or acc3=acc2.
EDIT:
The last sentence shows how to Integrate and Dump, to reset acc3 after it has been read. Has this been applied to Sinc3 and maybe other modes?
TonyB_, yes, at the end of a measurement period, acc3 is loaded with acc2, instead of acc3+acc2. This way, we effectively reset acc3 without losing the next acc2 delta.
As far as commonizing wide adders and gated counters, we have done that and it seems impervious to further logic savings.
Saucy, your ADC bitstream noise spectrum is good to see. It's apparent that most ADC data cycles in 5, 6, or 7 clocks.
Those periods are a pure function of input current vs feedback current at full-scale VIO and GIO readings. If you go above or below the rails, duty will soon reach 1/8 or 7/8, making 1/8 relative frequency the peak in the noise spectrum.
I'm trying to think what kind of other similar ADC topology might be possible where we parallelize something cheap in the circuit, like the currently-single-bit feedback, to make it multi-bit, instead, but not with exactly known values, but just something known only to be coarsely different, but consistent. Then, in the wash, out come better results that are giving us effectively more than one bit per clock, but not an integral amount, but something whole and fractional. Maybe digital pseudo-random noise could be used to choose each feedback strength, from clock to clock, with the data being tracked to know what caused the outcome in a rolling sampling scenario.
Would there be any obvious advantage to shattering the noise profile?
We could have multiple/smaller integrator caps that we run at slightly different feedback currents, in order to get more data. If we had 7, for example, we could add them up each clock to get 0..7 (3 bits) out, which could be considered as 0..1 in 7 steps. Just more data reporting could have value.
Or, those 7 bits could all be output each clock, in order to be individually calibrated before some final sense could be made of all their data, together.
Don't think so, initial responses to reset are identical.
So, we will provide a third-order filter, but there's really no reason to bother with a second-order filter, right? If we have a third-order, who cares about a second-order? Any second-order implementation would rather have been a third-order, given the resources were available. That's how I see it.
3dB bandwidth rises from 3.4MHz to 5.8MHz. 6dB bandwidth rises from 4.6MHz to 7.9MHz. Both of these neglect the effects of the analog circuitry.
It should be cheap to do. Just add a MUX to switch the input into the 31 on the end. So the bits can go through the full flat section in the middle or just part. And an AND after the third 32 in the center. This would prevent the bits in the bypassed section from affecting the output. (after enough clocks to flush them out)
I won't ask for the output to be rescaled. It would just multiply the noise.
Saucy, perfect!!!
We needed something like this to accommodate higher bandwidth, and a reduction in resolution is to be expected. I like the idea of not rescaling the output, but making 128 the peak, to keep absolute noise constant.
We will use the single, unused 'cfg' bit 6 to select this mode.
And this can all occur at the D inputs of the 'tap' flops with a mux, in order to avoid lengthening the filter computation time.
Just perfect!
A Tukey without a plateau is a Hann window, so bit 6 would select Tukey/Hann mode.
So, we will provide a third-order filter, but there's really no reason to bother with a second-order filter, right? If we have a third-order, who cares about a second-order? Any second-order implementation would rather have been a third-order, given the resources were available. That's how I see it.
Yep. That's how I see it too. If Sinc3 fits on the die then Sinc2 is redundant.
TonyB_, yes, at the end of a measurement period, acc3 is loaded with acc2, instead of acc3+acc2. This way, we effectively reset acc3 without losing the next acc2 delta.
As far as commonizing wide adders and gated counters, we have done that and it seems impervious to further logic savings.
Don't think so, initial responses to reset are identical.
So, we will provide a third-order filter, but there's really no reason to bother with a second-order filter, right? If we have a third-order, who cares about a second-order? Any second-order implementation would rather have been a third-order, given the resources were available. That's how I see it.
SincX has "passband droop" and the greater the cascading the more the droop. I think one of Saucy's graphs shows how the droop increases. It can be corrected in software but it's more work than a couple of sub/add combos. The higher the oversampling, the lower the droop.
Sinc2 would be an almost zero-cost option in logic, simply load acc3 with acc2 all the time, if there is a config bit to spare.
SINC3 topology is significant because the filter first becomes gaussian-shaped, after being triangular at SINC2 and rectangular at SINC1. Beyond SINC3, it becomes a little more gaussian, but at huge added expense. SINC3 is the sweet spot.
At this point, the various modes give great coverage. People have pretty great options. For the few niches that may show up, particularly after people have an interest in all this and use the on chip features, an external circuit will make sense for those.
We can still get the bitstream in the way you captured it on the Rev A chips, right? As long as that remains true, further software work can be done. That's going to end up covering a few of those "yet to be seen" niche cases. People can run it in bursts, with some trigger, process. Or, they can run it slower, instrumentation style.
That's the problem, TonyB_, there are no more bits for anything. What the acc's don't use, the reloadable counter uses.
Tukey/Hann is a better use for the last config bit.
I'm wondering what you get with two diffs not three with Sinc3? Of course with Integrate and Dump it would be only one in software. Would that give you Sinc2 or gobbledegook2?
Is there still a simple integrator Sinc1 mode and does it use Integrate and Dump?
Is there still a simple integrator Sinc1 mode and does it use Integrate and Dump?
Yes there is two modes, one clocked (%01100), one not clocked (%01111). Both 32-bit and both have a dedicated Z latch for capturing a sample, and both have decimation + diff'ing as hardware option.
At this point, the various modes give great coverage. People have pretty great options. For the few niches that may show up, particularly after people have an interest in all this and use the on chip features, an external circuit will make sense for those.
We can still get the bitstream in the way you captured it on the Rev A chips, right? As long as that remains true, further software work can be done. That's going to end up covering a few of those "yet to be seen" niche cases. People can run it in bursts, with some trigger, process. Or, they can run it slower, instrumentation style.
Yes, you can always catch the bitstreams, so any kind of ADC filtration can be achieved (or developed, in our current case), just not in real time.
USB modes have been compressed down to two, to accommodate two SINC3 modes. The USB slow/full-speed switch is now X[15] of WXPIN, which was an NCO bit that was always programmed with '0', anyway.
Comments
An osciiloscope shows real-time votage activity. Useful for seeing what is going on at the analog/pin level.
Once a solid Sinc3 is there, it's just the housekeeping stuff, like clock polarity, clock source, and sample sizes but I think those are covered ?
I would be interested to know if the noise peaks tend to stay at a fixed ratio with the system clock, or if their absolute frequency is relatively constant.
row 1 Tukey17*/32 row 2 Tukey16*/33 row 3 Tukey13*/32 means = 45.367 48.506 44.407 45.596 43.596 43.394 48.906 46.799 212.372 214.971 214.590 214.560 211.250 212.677 215.867 215.058 45.066 48.493 44.623 45.319 43.732 43.481 48.903 46.842 212.437 214.981 214.588 214.558 211.068 212.789 215.867 215.062 45.263 48.518 44.639 45.468 43.547 43.279 48.900 46.828 212.528 214.828 214.498 214.471 211.224 212.813 215.792 214.905 dev = 0.55194 0.51324 0.55921 0.50285 0.53237 0.61839 0.35290 0.47419 0.72835 0.40526 0.52742 0.53002 0.49377 0.54610 0.40421 0.31277 0.24906 0.53602 0.48472 0.46626 0.49502 0.62979 0.34789 0.39828 0.77249 0.41905 0.52930 0.53399 0.38639 0.49519 0.40087 0.31946 0.47926 0.51273 0.48960 0.50584 0.58546 0.68958 0.34295 0.50020 0.71697 0.52653 0.53534 0.53314 0.54762 0.49039 0.44996 0.49394Tony explained it enough for me, pruning creates bigger steps so smoothness is harmed.
JMG,
Yep, polarity and source are well covered in the general smartpin config.
Just the mode itself has to have edge counting option is all, ie: the bit-level becomes an enable for counting clock pulses. Chip has separated gated edge counting and level counting into separate modes, %01100 and %01111 respectively, for Sinc1.
Not sure if Chip plans to merge the two or have two modes same as Sinc1.
Does anyone else want a bandwidth adjustment in the filter?
The Tukey17/32 could be shortened like this: Sum is 512. Full scale output would be 128.
3dB bandwidth rises from 3.4MHz to 5.8MHz. 6dB bandwidth rises from 4.6MHz to 7.9MHz. Both of these neglect the effects of the analog circuitry.
It should be cheap to do. Just add a MUX to switch the input into the 31 on the end. So the bits can go through the full flat section in the middle or just part. And an AND after the third 32 in the center. This would prevent the bits in the bypassed section from affecting the output. (after enough clocks to flush them out)
I won't ask for the output to be rescaled. It would just multiply the noise.
Saucy, perfect!!!
We needed something like this to accommodate higher bandwidth, and a reduction in resolution is to be expected. I like the idea of not rescaling the output, but making 128 the peak, to keep absolute noise constant.
We will use the single, unused 'cfg' bit 6 to select this mode.
And this can all occur at the D inputs of the 'tap' flops with a mux, in order to avoid lengthening the filter computation time.
Just perfect!
Evanh, I'll post the new mode map shortly.
I compacted the main USB modes from four down to two, making the low/full-speed mode selectable by X[15] via WXPIN.
The two SINC3 modes sit where the first two USB modes were. The first SINC3 mode accumulates PinA on every clock, while the second SINC3 mode accumulates PinA only when PinB rises, making it externally clockable. I will post the code soon, as it has changed slightly.
In Sinc3, acc1 can be a counter, so only need adders for acc2 and acc3. jmg has asked a couple of times whether acc2 could use an existing NCO adder, leaving just acc3 as a new adder.
The Sinc3 logic could also do Sinc1 and Sinc2 if half the adder inputs are held low, so that acc3=acc2=acc1 or acc3=acc2.
EDIT:
The last sentence shows how to Integrate and Dump, to reset acc3 after it has been read. Has this been applied to Sinc3 and maybe other modes?
As far as commonizing wide adders and gated counters, we have done that and it seems impervious to further logic savings.
Does SINC2 have any special appeal?
Those periods are a pure function of input current vs feedback current at full-scale VIO and GIO readings. If you go above or below the rails, duty will soon reach 1/8 or 7/8, making 1/8 relative frequency the peak in the noise spectrum.
I'm trying to think what kind of other similar ADC topology might be possible where we parallelize something cheap in the circuit, like the currently-single-bit feedback, to make it multi-bit, instead, but not with exactly known values, but just something known only to be coarsely different, but consistent. Then, in the wash, out come better results that are giving us effectively more than one bit per clock, but not an integral amount, but something whole and fractional. Maybe digital pseudo-random noise could be used to choose each feedback strength, from clock to clock, with the data being tracked to know what caused the outcome in a rolling sampling scenario.
Would there be any obvious advantage to shattering the noise profile?
Or, those 7 bits could all be output each clock, in order to be individually calibrated before some final sense could be made of all their data, together.
Don't think so, initial responses to reset are identical.
So, we will provide a third-order filter, but there's really no reason to bother with a second-order filter, right? If we have a third-order, who cares about a second-order? Any second-order implementation would rather have been a third-order, given the resources were available. That's how I see it.
No. I'm just thinking about future development here. You are right, that is way too big a can to open, at this point.
A Tukey without a plateau is a Hann window, so bit 6 would select Tukey/Hann mode.
Yep. That's how I see it too. If Sinc3 fits on the die then Sinc2 is redundant.
SincX has "passband droop" and the greater the cascading the more the droop. I think one of Saucy's graphs shows how the droop increases. It can be corrected in software but it's more work than a couple of sub/add combos. The higher the oversampling, the lower the droop.
Sinc2 would be an almost zero-cost option in logic, simply load acc3 with acc2 all the time, if there is a config bit to spare.
Yes, best to do a search for the details.
We can still get the bitstream in the way you captured it on the Rev A chips, right? As long as that remains true, further software work can be done. That's going to end up covering a few of those "yet to be seen" niche cases. People can run it in bursts, with some trigger, process. Or, they can run it slower, instrumentation style.
Tukey/Hann is a better use for the last config bit.
I'm wondering what you get with two diffs not three with Sinc3? Of course with Integrate and Dump it would be only one in software. Would that give you Sinc2 or gobbledegook2?
Is there still a simple integrator Sinc1 mode and does it use Integrate and Dump?
I think this will simply be the 3-clock lag again. I don't see how that can be a concern for nominal uses of smartpins.
Yes there is two modes, one clocked (%01100), one not clocked (%01111). Both 32-bit and both have a dedicated Z latch for capturing a sample, and both have decimation + diff'ing as hardware option.
Yes, you can always catch the bitstreams, so any kind of ADC filtration can be achieved (or developed, in our current case), just not in real time.
USB modes have been compressed down to two, to accommodate two SINC3 modes. The USB slow/full-speed switch is now X[15] of WXPIN, which was an NCO bit that was always programmed with '0', anyway.
Here is the SINC3 smart pin mode Verilog code: