Bandpass characteristics:
Every clock we decide, if the input voltage is above or below the internal caps voltage. So every clock we just can gain 1 bit of information. If this information toggles, we know, that the input voltage is balanced by the compensation pulses, so the ADC is tracking properly. If we want to have a higher resolution, we have, as the input voltage changes, to wait, until the toggling starts, otherwise the cap is not balanced yet, we have no information.
So we can measure slops only as far, as we can see, that the compensation pulses can keep the comparator toggling. And the higher the resolution is, the longer we have to wait. So we should just decide, what frequency we want to measure, calculate the maximal resolution and sampling rate and then we can filter the data stream that way, that the noise is damped optimally. I think, noise can be filtered nicely averaging 64 or 128 clocks, so the sampling rate will be about 1 MHz, what seems to be adequat.
Good point about measuring from edges to match the integrator toggling. This relates to Jmg's reciprocal counter methodology.
The measurement makes sense at this point. It should be done to validate the filters aren't actually limiting basic capability, right?
Right. I want to wrap this up soon, for now, and want to be sure we are optimal in performance/gates.
I think you are very close.
The next thing I would suggest, is to confirm test the filter by connecting to one of those external ADC's I've referenced, & maybe with a digital microphone too.
As more MCUs add these Sinc3 filters, more analog front ends seem to be coming out, so supporting those for the 16b and above performance levels, is an added benefit of this work.
ie it not only improves P2 ADC sample rates, but also opens up a whole new connected-ADC arena.
I have no dog in this fight...but I think it would be neat if there was enough ADC BW to sample a composite NTSC signal. Even though NTSC is dead, there are still A LOT of surveillance cameras sold with NTSC output.
That's just one example of things that still use NTSC.
I have no dog in this fight...but I think it would be neat if there was enough ADC BW to sample a composite NTSC signal. Even though NTSC is dead, there are still A LOT of surveillance cameras sold with NTSC output.
That's just one example of things that still use NTSC.
I agree. Our problem is that the ADC's analog front-end has attenuated the signal when you get up around 3.58 MHz.
It is possible to build single-pin external-integrator ADCs using internal resistor drive with clocked negative feedback (modes %0000_1010xx0xx_00_00000_0), and they shouldn't suffer the same bandwidth limitation. I'm going to try it right now...
My results are indeterminate. I need a smaller capacitor than the 100nF I've got on hand.
My rolling 3-bit count of the last seven ADC samples didn't improve things much, at all. I'll stick with what we've got. It's way cheaper to implement in silicon, anyway.
So, I'm going to implement a SETADCS instruction which sets up 4-channel live ADC operation, a GETDACS instruction which reads the 4 channels, then I'll feed those 4 channels into the streamer and wrap the streamer up.
Chip, your idea of using multiple ADC bits got me thinking.
Sinc3 acc1 can have more than 1 bit as its input and if we could use two ADC bits then maybe we could run the Sinc3 logic at sysclock/2. This would have two effects:
1. The decimation rate R could not be odd, but a CIC filter works better with even R anyway, according to something I read the other day. R/4 an integer is better, R/8 an integer better still, etc.
2. The acc2 and acc3 adders could be replaced, in theory, by a single adder with one of the operands muxed. Adder operations (syntax deliberate):
acc2 := acc2 + acc1
acc3 := acc2 + acc3
The single adder could have acc2 as one operand always and either acc1 or acc3 as the other operand every other clock. The adder output connects to both acc2 and acc3 registers with write enabled every other clock again. The counter that increments acc1 is unchanged and can count on every clock, depending on the the ADC bit.
The aim is to save logic but have the same functionality, apart from the even R caveat.
How is a multi-bit modulator meant to exist? I get the impression that all the advantages a sigma-delta has will vanish the moment any attempt made to introduce independent digitisers.
How is a multi-bit modulator meant to exist? I get the impression that all the advantages a sigma-delta has will vanish the moment any attempt made to introduce independent digitisers.
Evan, the ADC bits are part of the same bitstream from a single pin, but that does not mean this idea will work in practice.
What I meant is, for example, an 8-bit flash ADC uses 256 independent digitisers that are then encoded into a byte. Going down this road with sigma-delta seems to me to be breaking the magic that makes it a sigma-delta.
Chip, your idea of using multiple ADC bits got me thinking.
Sinc3 acc1 can have more than 1 bit as its input and if we could use two ADC bits then maybe we could run the Sinc3 logic at sysclock/2. This would have two effects:
1. The decimation rate R could not be odd, but a CIC filter works better with even R anyway, according to something I read the other day. R/4 an integer is better, R/8 an integer better still, etc.
2. The acc2 and acc3 adders could be replaced, in theory, by a single adder with one of the adder operands muxed. Adder operations (syntax deliberate):
acc2 := acc2 + acc1
acc3 := acc2 + acc3
The single adder could have acc2 as one operand always and either acc1 or acc3 as the other operand every other clock. The adder output connects to both acc2 and acc3 registers with write enabled every other clock again. The acc1 counter could stay as a counter, I think, with either a count of 1 or a count of 2 every clock, depending on the two ADC bits.
The aim is to save logic but have the same functionality, apart from the even R caveat.
Very interesting!
Would adding acc1 into acc2 on every other clock change the filtering in any qualitative way, aside from necessitating an even number of effective clocks?
Chip, your idea of using multiple ADC bits got me thinking.
Sinc3 acc1 can have more than 1 bit as its input and if we could use two ADC bits then maybe we could run the Sinc3 logic at sysclock/2. This would have two effects:
1. The decimation rate R could not be odd, but a CIC filter works better with even R anyway, according to something I read the other day. R/4 an integer is better, R/8 an integer better still, etc.
2. The acc2 and acc3 adders could be replaced, in theory, by a single adder with one of the adder operands muxed. Adder operations (syntax deliberate):
acc2 := acc2 + acc1
acc3 := acc2 + acc3
The single adder could have acc2 as one operand always and either acc1 or acc3 as the other operand every other clock. The adder output connects to both acc2 and acc3 registers with write enabled every other clock again. The counter that increments acc1 is unchanged and can count on every clock, depending on the the ADC bit.
The aim is to save logic but have the same functionality, apart from the even R caveat.
Very interesting!
Would adding acc1 into acc2 on every other clock change the filtering in any qualitative way, aside from necessitating an even number of effective clocks?
Probably not, to be honest. It needs to be proven to give the same end result before taking it any further and I can't prove that it does. Two bits producing only three states bothers me. I have to stop again now and whatever the outcome I think the idea was worth mentioning.
2. The acc2 and acc3 adders could be replaced, in theory, by a single adder with one of the operands muxed. Adder operations (syntax deliberate):
acc2 := acc2 + acc1
acc3 := acc2 + acc3
The single adder could have acc2 as one operand always and either acc1 or acc3 as the other operand every other clock. The adder output connects to both acc2 and acc3 registers with write enabled every other clock again. The acc1 counter could stay as a counter, I think, with either a count of 1 or a count of 2 every other clock, depending on the two ADC bits.
Did you mean a single adder, plus MUX's and latches ?
It then becomes a question of if the muxes and latches are smaller (and not slower) than the adder logic ?
I think you would need the latches too, to keep the unique acc2, acc3 values but I think you could time-multiplex the adder, if that saved significant logic.
Tonight I did an experiment where I ganged ADC pins together to see if there was any resolution increase if they were all fed the same signal and their output bits were summed together.
This exercise indicates what kind of performance increase we could expect if each ADC had multiple integrators, which would be simple to do. Instead of 1 huge integrator cap in the ADC (which is already 20x bigger than necessary), we could have 15 smaller caps, each fed by a flop with a uniquely-biased sense amp driving its data input, so they don't all coalesce. Then, we add up their output states to form a 4-bit word on each clock. It looks like the improvement would be quite dramatic.
In this test, the short Hann-type window was used for maximum slew rate and a 1MHz square wave was fed into the ADCs. On every clock cycle, a new sample is output.
Here is 1 pin:
Here are 4 pins:
And here are 16 pins:
You can see the improvement is quite good by summing multiple integrators.
This cannot go into the next silicon, but will go into a future design. The ADC input bandwidth needs to be increased dramatically, as well. Then, we'll have much faster and more accurate ADCs.
Its a shame the ADC doesn't have better frequency response. But hey, we have what we have, and what P2 does is amazing.
Always nice to have better, so next time the ring frame is changed you can try again. Maybe 110nm won't be a costly exercise by then, and we'd get 1MB Hub too
What about feeding in higher frequencies and plotting the response so we can see it's limitations - say 10MHz, 50MHz and 100MHz ?
The one-pin thing we've got working now is still pretty decent.
Agreed.
Can you make sure to test what you have now, with the external ADC's that need Digital Filters, to confirm they meet their spec connected to a P2.
That give a cross check on the filter, as well as confirming it does work with other parts, opening up more uses.
If the 3dB point is 6MHz as Chip mentioned above, that should be enough for some reasonable analog video sampling, shouldn't it? Colour may be an issue if the 3.58MHz is all lost but if it is still present maybe there is enough amplitude to somehow decode and use it? Otherwise monochrome video is still probably useful...
The one-pin thing we've got working now is still pretty decent.
Agreed.
Can you make sure to test what you have now, with the external ADC's that need Digital Filters, to confirm they meet their spec connected to a P2.
That give a cross check on the filter, as well as confirming it does work with other parts, opening up more uses.
Do they come on development boards that you can connect the clock and data to?
.. but will go into a future design: A very good decision! If what is now reached is not enough, nothing will be! While there are always limits, we didn't reach the end of P1 yet! And don't thing about applications that already exist. Search for those problems and solutions, ONLY a propeller can be applied for. Let us create a WWW of propellers to measure environment. Any number of ADC's on just one chip. Or, or, or ....
When the transputer came up, it was a swiss knive. But extremely expensive. When they focused on set top boxes, application specific silicon devises could easily outperform and kill the transputer. So a killer application can kill an idea. Diversity has to be a goal. One P2 can do a lot of different things AND combine them. Like a smoke detector with ears and humidity detector measuring temperature and airflow to have a true home control unit not connected to the cloud!
I got the Tukey filter working on the FPGA with the pad ring test chip, which contains two complete I/O pins.
I wanted to see how things worked in real-time. I am really surprised to see that things are looking way better than I expected.
The FPGA is running at 80MHz, with one analog I/O pin configured as an ADC input and the other pin configured as a DAC output. I'm using a function generator to feed the ADC pin. Its bit stream goes through the Tukey filter whose 8-bit output samples go out to the DAC pin, one per clock.
Look at this 200KHz ramp:
And here's a 100KHz sine wave:
I think this signal quality is quite adequate. Hopefully, it works as well on the real chip.
One other nice thing... When I put all four Tukey filters into the cogs, they went from 82 ALM's each down to 70 each. Maybe some logic was able to be reused.
2. The acc2 and acc3 adders could be replaced, in theory, by a single adder with one of the operands muxed. Adder operations (syntax deliberate):
acc2 := acc2 + acc1
acc3 := acc2 + acc3
The single adder could have acc2 as one operand always and either acc1 or acc3 as the other operand every other clock. The adder output connects to both acc2 and acc3 registers with write enabled every other clock again. The acc1 counter could stay as a counter, I think, with either a count of 1 or a count of 2 every other clock, depending on the two ADC bits.
Did you mean a single adder, plus MUX's and latches ?
It then becomes a question of if the muxes and latches are smaller (and not slower) than the adder logic ?
I think you would need the latches too, to keep the unique acc2, acc3 values but I think you could time-multiplex the adder, if that saved significant logic.
The registers are there already, so it's a 30-bit mux replacing a 30-bit adder plus a little extra logic and I don't know how much the total saving would be. I know this isn't desired, but if we are forced to because of lack of space we could make everything 24-bit for 16-bit accuracy.
What I'm proposing is a preliminary decimation by 2 that is equivalent to a Sinc1 CIC with integrate and dump. It would be helpful to have some test bitstreams, either as files or precise details of how to create them.
Simple question? What happens if you take the output of the comparator and run in through a single clock delay, and then use a half adder to obtain a two bit signal by computing sigma(z, z^-1) as a two bit value running a clock rate, I.e. creating a {1,1} convolutional kernel. Repeating the process would give a three bit signal at clock rate with an effective kernel of {1,2,1}, and then {1,3,3,1}, and then {1,4,6,4,1}, etc., according to the co-efficients of the binomial theorem. a.k.a. Pascal's triangle. Those familiar with the convolution theorem will recognize that convolution in the time domain is the same as multiplication in the frequency domain, and thus the various sinc^N functions can be obtained, as well as approximate Gaussian modes, because the co-effecients of Pascal's triangle approach the shape of exp(-z*z) as a limit as N approaches infinity.
Note this code is under development, as a simulation of how the ADCs might work, so that I and run tests on a Pentium; and it is still quite broken as to the later stages, i.e. when trying to push for speed by doing things by bit-weaving the logic in SIMD like fashion. Yet there are things that come to mind, such as that I should be possible to get the proposed P2 architecture A-D rate up to something much faster than 1 MSample/second for 8 bit and higher USABLE resolution … for certain types of signals. Note the word USABLE resolution; since it should be easy to get 6, 7 or even 8 noisy bits of data at 62 Mhz (or 31) based on simple delay and add, delay and add, delay, and add semantics, using the minimum number gates.
Then the magic happens, (warm maybe) lets say if you are trying to process the R-Y and B-Y signals of an S-video link, where you are getting your stream at the output of an analog 3.5795454Mhz bandpass filter (just a coil and capacitor or video grade op amp circuit) - then -- since you might be able to use multiple a-d inputs to guess at the amplitude swings of a plurality of bandwidth limited signals, without requiring a bunch of sample and hold circuits or ring modulators (such as LM1496 or equivalent) to mix the chroma channels or whatever down to baseband; although that is also an option.
Broken code follows - this is a work in progress …
#define EVEN_BITS (0x55555555)
#define ODD_BITS (0xaaaaaaaa)
#define EVEN_PAIRS (0x33333333)
#define ODD_PAIRS (0xcccccccc)
#define EVEN_NIBBLES (0xf0f0f0f0)
#define ODD_NIBBLES (0x0f0f0f0f)
#define EVEN_BYTES (0x00ff00ff)
#define ODD_BYTES (0xff00ff00)
DWORD propeller_adc::decimate (DWORD input)
{
static bool carry;
DWORD q0, q1, q2, q3;
DWORD r0, r1, r2, r3;
DWORD s0, s1;
DWORD acc = 0;
// format b31.....b0, even bits have weight = 1
// odd bits have weight = 0.5*2, phase one - decimate by 2 using
// a [1,2,1] convolutional kernel yielding 16 3 bit values from a
// sigle DWORD containing 32 individual one bit input samples
q0 = input&EVEN_BITS;
q1 = input&ODD_BITS;
q2 = q0<<1;
q3 = (q1+q1<<2)>>1;
r0 = q2&EVEN_PAIRS;
r2 = q3&EVEN_PAIRS;
s0 = r0+r2;
r1 = q2&ODD_PAIRS;
r3 = q3&ODD_PAIRS;
s1 = r1+r3;
// phase two - apply the same transformation
// to the 16 three bit values, yielding
// eight five bit values, having a range [0..32]
q0 = s0&EVEN_NIBBLES;
q1 = s0&ODD_NIBBLES;
q2 = s1&EVEN_NIBBLES;
q3 = s1&ODD_NIBBLES;
// HMMM... FIXME?
s0 = q0+q2<<1+q3>>4;
s1 = q1+q3;
// phase three - apply the same transformation
// to the eight five bit values, yielding
// four seven bit values, having a range [0..64]
// finally repack into a 32 bit register
// for in input rate of 250Mbps - this results
// in an initial output rate of 31.25
return acc;
}
You just jogged my memory. I never did do anything with it but maybe now I will.
EDIT: The photo is incorrect, or at least it must be pre-rev.A board. The rev.A design files match the board I have. And I have to say rev.A has MDAT test point on wrong side of U3. I've got a wire soldered to pin 11 of U2.
EDIT2: Here's the layout for rev.A board as imported to Diptrace:
Comments
I think we are -3dB at ~6MHz.
Good point about measuring from edges to match the integrator toggling. This relates to Jmg's reciprocal counter methodology.
Right. I want to wrap this up soon, for now, and want to be sure we are optimal in performance/gates.
I think you are very close.
The next thing I would suggest, is to confirm test the filter by connecting to one of those external ADC's I've referenced, & maybe with a digital microphone too.
As more MCUs add these Sinc3 filters, more analog front ends seem to be coming out, so supporting those for the 16b and above performance levels, is an added benefit of this work.
ie it not only improves P2 ADC sample rates, but also opens up a whole new connected-ADC arena.
That's just one example of things that still use NTSC.
I agree. Our problem is that the ADC's analog front-end has attenuated the signal when you get up around 3.58 MHz.
It is possible to build single-pin external-integrator ADCs using internal resistor drive with clocked negative feedback (modes %0000_1010xx0xx_00_00000_0), and they shouldn't suffer the same bandwidth limitation. I'm going to try it right now...
My results are indeterminate. I need a smaller capacitor than the 100nF I've got on hand.
So, I'm going to implement a SETADCS instruction which sets up 4-channel live ADC operation, a GETDACS instruction which reads the 4 channels, then I'll feed those 4 channels into the streamer and wrap the streamer up.
Sinc3 acc1 can have more than 1 bit as its input and if we could use two ADC bits then maybe we could run the Sinc3 logic at sysclock/2. This would have two effects:
1. The decimation rate R could not be odd, but a CIC filter works better with even R anyway, according to something I read the other day. R/4 an integer is better, R/8 an integer better still, etc.
2. The acc2 and acc3 adders could be replaced, in theory, by a single adder with one of the operands muxed. Adder operations (syntax deliberate):
The single adder could have acc2 as one operand always and either acc1 or acc3 as the other operand every other clock. The adder output connects to both acc2 and acc3 registers with write enabled every other clock again. The counter that increments acc1 is unchanged and can count on every clock, depending on the the ADC bit.
The aim is to save logic but have the same functionality, apart from the even R caveat.
Evan, the ADC bits are part of the same bitstream from a single pin, but that does not mean this idea will work in practice.
Very interesting!
Would adding acc1 into acc2 on every other clock change the filtering in any qualitative way, aside from necessitating an even number of effective clocks?
Is this...
acc3 = acc3 + acc2
acc2 = acc2 + acc1
acc1 = acc1 + ADCbit
...the same as this?...
acc3 = acc3 + acc2
acc2 = acc2 + acc1
acc1 = acc1 + ADCbit
acc1 = acc1 + ADCbit
Probably not, to be honest. It needs to be proven to give the same end result before taking it any further and I can't prove that it does. Two bits producing only three states bothers me. I have to stop again now and whatever the outcome I think the idea was worth mentioning.
EDIT:
It works!
Did you mean a single adder, plus MUX's and latches ?
It then becomes a question of if the muxes and latches are smaller (and not slower) than the adder logic ?
I think you would need the latches too, to keep the unique acc2, acc3 values but I think you could time-multiplex the adder, if that saved significant logic.
This exercise indicates what kind of performance increase we could expect if each ADC had multiple integrators, which would be simple to do. Instead of 1 huge integrator cap in the ADC (which is already 20x bigger than necessary), we could have 15 smaller caps, each fed by a flop with a uniquely-biased sense amp driving its data input, so they don't all coalesce. Then, we add up their output states to form a 4-bit word on each clock. It looks like the improvement would be quite dramatic.
In this test, the short Hann-type window was used for maximum slew rate and a 1MHz square wave was fed into the ADCs. On every clock cycle, a new sample is output.
Here is 1 pin:
Here are 4 pins:
And here are 16 pins:
You can see the improvement is quite good by summing multiple integrators.
This cannot go into the next silicon, but will go into a future design. The ADC input bandwidth needs to be increased dramatically, as well. Then, we'll have much faster and more accurate ADCs.
Future design of what? P2?
An enhancement to the current design, and for reduced pin/cog/hub versions in the future.
Here are 16 pins:
Yeah, to process 4 bits through a Tukey window, we kind of need a smaller/faster process.
The one-pin thing we've got working now is still pretty decent.
Always nice to have better, so next time the ring frame is changed you can try again. Maybe 110nm won't be a costly exercise by then, and we'd get 1MB Hub too
What about feeding in higher frequencies and plotting the response so we can see it's limitations - say 10MHz, 50MHz and 100MHz ?
Can you make sure to test what you have now, with the external ADC's that need Digital Filters, to confirm they meet their spec connected to a P2.
That give a cross check on the filter, as well as confirming it does work with other parts, opening up more uses.
Do they come on development boards that you can connect the clock and data to?
When the transputer came up, it was a swiss knive. But extremely expensive. When they focused on set top boxes, application specific silicon devises could easily outperform and kill the transputer. So a killer application can kill an idea. Diversity has to be a goal. One P2 can do a lot of different things AND combine them. Like a smoke detector with ears and humidity detector measuring temperature and airflow to have a true home control unit not connected to the cloud!
I wanted to see how things worked in real-time. I am really surprised to see that things are looking way better than I expected.
The FPGA is running at 80MHz, with one analog I/O pin configured as an ADC input and the other pin configured as a DAC output. I'm using a function generator to feed the ADC pin. Its bit stream goes through the Tukey filter whose 8-bit output samples go out to the DAC pin, one per clock.
Look at this 200KHz ramp:
And here's a 100KHz sine wave:
I think this signal quality is quite adequate. Hopefully, it works as well on the real chip.
One other nice thing... When I put all four Tukey filters into the cogs, they went from 82 ALM's each down to 70 each. Maybe some logic was able to be reused.
The registers are there already, so it's a 30-bit mux replacing a 30-bit adder plus a little extra logic and I don't know how much the total saving would be. I know this isn't desired, but if we are forced to because of lack of space we could make everything 24-bit for 16-bit accuracy.
What I'm proposing is a preliminary decimation by 2 that is equivalent to a Sinc1 CIC with integrate and dump. It would be helpful to have some test bitstreams, either as files or precise details of how to create them.
Note this code is under development, as a simulation of how the ADCs might work, so that I and run tests on a Pentium; and it is still quite broken as to the later stages, i.e. when trying to push for speed by doing things by bit-weaving the logic in SIMD like fashion. Yet there are things that come to mind, such as that I should be possible to get the proposed P2 architecture A-D rate up to something much faster than 1 MSample/second for 8 bit and higher USABLE resolution … for certain types of signals. Note the word USABLE resolution; since it should be easy to get 6, 7 or even 8 noisy bits of data at 62 Mhz (or 31) based on simple delay and add, delay and add, delay, and add semantics, using the minimum number gates.
Then the magic happens, (warm maybe) lets say if you are trying to process the R-Y and B-Y signals of an S-video link, where you are getting your stream at the output of an analog 3.5795454Mhz bandpass filter (just a coil and capacitor or video grade op amp circuit) - then -- since you might be able to use multiple a-d inputs to guess at the amplitude swings of a plurality of bandwidth limited signals, without requiring a bunch of sample and hold circuits or ring modulators (such as LM1496 or equivalent) to mix the chroma channels or whatever down to baseband; although that is also an option.
Broken code follows - this is a work in progress …
#define EVEN_BITS (0x55555555) #define ODD_BITS (0xaaaaaaaa) #define EVEN_PAIRS (0x33333333) #define ODD_PAIRS (0xcccccccc) #define EVEN_NIBBLES (0xf0f0f0f0) #define ODD_NIBBLES (0x0f0f0f0f) #define EVEN_BYTES (0x00ff00ff) #define ODD_BYTES (0xff00ff00) DWORD propeller_adc::decimate (DWORD input) { static bool carry; DWORD q0, q1, q2, q3; DWORD r0, r1, r2, r3; DWORD s0, s1; DWORD acc = 0; // format b31.....b0, even bits have weight = 1 // odd bits have weight = 0.5*2, phase one - decimate by 2 using // a [1,2,1] convolutional kernel yielding 16 3 bit values from a // sigle DWORD containing 32 individual one bit input samples q0 = input&EVEN_BITS; q1 = input&ODD_BITS; q2 = q0<<1; q3 = (q1+q1<<2)>>1; r0 = q2&EVEN_PAIRS; r2 = q3&EVEN_PAIRS; s0 = r0+r2; r1 = q2&ODD_PAIRS; r3 = q3&ODD_PAIRS; s1 = r1+r3; // phase two - apply the same transformation // to the 16 three bit values, yielding // eight five bit values, having a range [0..32] q0 = s0&EVEN_NIBBLES; q1 = s0&ODD_NIBBLES; q2 = s1&EVEN_NIBBLES; q3 = s1&ODD_NIBBLES; // HMMM... FIXME? s0 = q0+q2<<1+q3>>4; s1 = q1+q3; // phase three - apply the same transformation // to the eight five bit values, yielding // four seven bit values, having a range [0..64] // finally repack into a 32 bit register // for in input rate of 250Mbps - this results // in an initial output rate of 31.25 return acc; }Oh, wow, I'd long forgotten one EVAL-CN0185-EB1Z that I'd bought many years ago - https://wiki.analog.com/resources/eval/user-guides/circuits-from-the-lab/cn0185
You just jogged my memory. I never did do anything with it but maybe now I will.
EDIT: The photo is incorrect, or at least it must be pre-rev.A board. The rev.A design files match the board I have. And I have to say rev.A has MDAT test point on wrong side of U3. I've got a wire soldered to pin 11 of U2.
EDIT2: Here's the layout for rev.A board as imported to Diptrace:
Evan, could you post your 50000 ramps as a test bitstream file?