How extensive is this crosstalk problem? Does it apply to all A-to-D conversions, or just certain modes/instructions? And "paired pins" means "an even/odd pair, having only the LSB of their pin numbers different"?
Sounds like this could become a HUGE amount of time for many people in the chain to spend on something that can be solved in no time at all by simply using non-pairs, or even non-group pins, with the current mask. Not to mention opportunity cost, as you'll be distracted from Spin2/etc..
Did you find some really compelling reason to consider the mod ?
Otherwise, what you said above "Or, tying your analog signal to both pins, in which case you can get an extra bit of resolution.".....
That seems like a fine reason to keep your design as-is, and document that recommendation as a feature.
Seems like that's a good feature to me: Joined pairs for highest resolution, alternate pins for medium resolution, and adjoining pins for lower resolution.
I really like the "you can get an extra bit of resolution."..... by tying the 2 pins together. Of course my bias comes from wanting @cgracey to finish Official Spin2!! That's a big milestone that I think is close. Time to re-write the test program and the extra investment on a chip that seems pretty solid sounds like feature creep. Besides I don't see this as that big of a deal because as @jmg said, other MCUs have special rules for using the ADCs. As long as it's well documented I think it's fine.
I'm getting the test program rewritten to work without Pin B mode.
The crosstalk becomes apparent at about 4 bits down in a conversion. So, I suppose you could say it's level is -24dB full-scale. It is quite significant.
Perhaps the concern is less with doing the fix itself, and I'm assuming it solves the issue, but the risk that any metal/mask change will be taken as an opportunity to tweak other things on the same layer to improve other aspects... Can/should anything stop that?
Perhaps the concern is less with doing the fix itself, and I'm assuming it solves the issue, but the risk that any metal/mask change will be taken as an opportunity to tweak other things on the same layer to improve other aspects... Can/should anything stop that?
This would involve changing either the M2 or VIA2 mask. Mode %010 would become 'floating', instead of PinB.
There's really not much possible by changing just one layer. All you can do is break a connection or make another connection to something nearby on the same layer, assuming you don't break any design rule. Opening up a wire is no problem, and that's what we need to do.
If you decide to do this Chip, how would that impact a May 2020 launch?
I'd suppose the date could drift a bit whilst OnSemi & Parallax manage the process and approvals/etc..?
(Even if the initial step just points to a little mask scratch, these things have tended to get more involved in the past?)
Is there any way to clarify what the actual end-to-end impact would be before the final call is made?
I'm thinking in terms of "other stuff" in progress, dates would be pretty crucial info to get figured out.
And also for everyone visiting that might be lining up holiday time or business trips around May. There could be some knock-on impact for a lot of people to a delay, whether intentional or not, that would need a bit of communication as early as you can fathom a new hard date to count down the 22 weeks from.
(Sorry to add another task to your thoughts- just I think this is an important aspect to add to the mix)
Are the guard rings you wanted also on this metal layer?
It would take many layers to implement the guard rings. Not practical at this time.
This M2 change will not impact the wafer run because it is likely two months before they even get to fabricating the metal layers. We just need to slip a new M2 mask into the stack.
I made my appeal to ON Semi this morning in an email. I explained everything:
(ON contacts),
I've discovered a disaster within the ADC in each PAD_IO pin. There is a huge crosstalk issue between adjacent pins. The problem is due to the input selector design which picks among several primary-pin resistors and a single adjacent-pin resistor. The signals first go into a common-centroid resistor array and then get mux'd. There is a lot of parasitic coupling within the resistor array between the primary-pin and adjacent-pin signals that is making a mess of things. I never realized this before, but should have designed the front end with the switches first, resistors second.
By getting rid of a single resistor connection via an M2 cut, we can keep the adjacent-pin signal out of the array and go without that mux-select possibility. This will totally fix the problem and that feature won't be missed.
So, I would like to make a new M2 mask which has a certain M2 wire cut in each PAD_IO instance. This could also be achieved, instead, by making a new VIA2 mask which eliminates four vias from each PAD_IO instance.
This change has no effect on any ESD testing, latch-up testing, or ROM code. There is no need to retest or resimulate anything. This will, though, require swapping out the current custom I/O test pattern with the new version (attached) which I made and thoroughly tested today. It is the same data size and takes the same time as the current pattern, so that swapping it in is as simple as I can make it. This program needed to change because it was using the adjacent-pin mux-select, which won't work with the M2 wire cut. I was able to code it differently without any performance loss. It's even better now and tests over a wider voltage range. There should be no hiccups in employing it.
Attached is a picture of what I'd like to do. Also, there is an image which shows the crosstalk problem.
The Propeller 2 actually has oscilloscope features, where it can continuously filter the delta-sigma ADC outputs from pins, record them into memory, and sense trigger conditions. Because the Propeller 2 can drive all kinds of displays (HDMI, VGA, component, baseband, etc), it can actually display the waveforms, as you see in the picture. I really want this to work properly after all the work that's gone into it.
I hope we can do this.
Thanks.
Chip
Wendy is already making the new test pattern from my updated ATE-tester program, which had to be rewritten to not use the PinB input to the ADC. No problem, it turned out. Those new SINC2 filters came in really handy. The voltage range for the test program actually grew quite a bit. Now we just have to see what ON says.
@cgracey
and any one else to answer the question, thanks
I am interested in running this code. Learned alot from it. Just want to make sure that I can run the rev b board hdmi to my t.v.
and not hurt the rev b board.
btw having so much fun. You are a genius.
@cgracey
and any one else to answer the question, thanks
I am interested in running this code. Learned alot from it. Just want to make sure that I can run the rev b board hdmi to my t.v.
and not hurt the rev b board.
btw having so much fun. You are a genius.
There should be no problem. The worst you might experience is temporary trouble with the USB connection due to a ground loop, in case you're operating your TV and computer from different AC circuits. Glad you're having fun!
I recall the old days when there was a FIB to cut layers. Is there a way to outsource such an experiment
We could, but the outcome is pretty well understood: We won't be able to select the adjacent pin as an input to the ADC, but we will not have to suffer it polutting the main pin's input to the ADC. So, each pin's ADC will work independently.
For highest-resolution measurements, it may still help to use a pin pair, instead of any pin with a noisy neighbor. By cutting that M2 trace, though, separation will be vastly improved and the lower impedance the input signal, the less effect the adjacent pin will have. Right now, the coupling problem cannot be overcome by any external impedance lowering.
I still think it would be better to leave as-is, and recommend tying pin pairs together to get 1-bit extra resolution, or ground the pin-pair. I don't think this will cause any problems for users.
I still think it would be better to leave as-is, and recommend tying pin pairs together to get 1-bit extra resolution, or ground the pin-pair. I don't think this will cause any problems for users.
But our awesome SCOPE mode would be all compromised, since the streamer captures four channels on four contiguous pins. Fixing this also makes all pins into independent ADC's, like they ought to be.
Comments
How sure are you that this change will fix the problem?
I really like the "you can get an extra bit of resolution."..... by tying the 2 pins together. Of course my bias comes from wanting @cgracey to finish Official Spin2!! That's a big milestone that I think is close. Time to re-write the test program and the extra investment on a chip that seems pretty solid sounds like feature creep. Besides I don't see this as that big of a deal because as @jmg said, other MCUs have special rules for using the ADCs. As long as it's well documented I think it's fine.
The crosstalk becomes apparent at about 4 bits down in a conversion. So, I suppose you could say it's level is -24dB full-scale. It is quite significant.
The results looked perfect...
I think below -70dB.
This would involve changing either the M2 or VIA2 mask. Mode %010 would become 'floating', instead of PinB.
There's really not much possible by changing just one layer. All you can do is break a connection or make another connection to something nearby on the same layer, assuming you don't break any design rule. Opening up a wire is no problem, and that's what we need to do.
I'd suppose the date could drift a bit whilst OnSemi & Parallax manage the process and approvals/etc..?
(Even if the initial step just points to a little mask scratch, these things have tended to get more involved in the past?)
Is there any way to clarify what the actual end-to-end impact would be before the final call is made?
I'm thinking in terms of "other stuff" in progress, dates would be pretty crucial info to get figured out.
And also for everyone visiting that might be lining up holiday time or business trips around May. There could be some knock-on impact for a lot of people to a delay, whether intentional or not, that would need a bit of communication as early as you can fathom a new hard date to count down the 22 weeks from.
(Sorry to add another task to your thoughts- just I think this is an important aspect to add to the mix)
It would take many layers to implement the guard rings. Not practical at this time.
This M2 change will not impact the wafer run because it is likely two months before they even get to fabricating the metal layers. We just need to slip a new M2 mask into the stack.
I made my appeal to ON Semi this morning in an email. I explained everything:
Wendy is already making the new test pattern from my updated ATE-tester program, which had to be rewritten to not use the PinB input to the ADC. No problem, it turned out. Those new SINC2 filters came in really handy. The voltage range for the test program actually grew quite a bit. Now we just have to see what ON says.
and how is the result if you tie both pins?
There'd be no foreign signal, but you'd only have half of the ADC channels.
and any one else to answer the question, thanks
I am interested in running this code. Learned alot from it. Just want to make sure that I can run the rev b board hdmi to my t.v.
and not hurt the rev b board.
btw having so much fun. You are a genius.
There should be no problem. The worst you might experience is temporary trouble with the USB connection due to a ground loop, in case you're operating your TV and computer from different AC circuits. Glad you're having fun!
We could, but the outcome is pretty well understood: We won't be able to select the adjacent pin as an input to the ADC, but we will not have to suffer it polutting the main pin's input to the ADC. So, each pin's ADC will work independently.
Did you run some capacitance calculations to see what kind of coupling would still remain after you make that change?
Yes! There is some capacitance there that we can't get rid of, but it's much better than a bunch of high impedance resistors knotted together.
Where we cut the trace is not going to make much of a difference.
You just need to be very,very,very sure you do cut the right ones !!
But our awesome SCOPE mode would be all compromised, since the streamer captures four channels on four contiguous pins. Fixing this also makes all pins into independent ADC's, like they ought to be.