It seems that if I pull a pin low then high and then float it that instead of the high state decaying gradually it instead drops immediately to 1.78V and then decays from there taking 120us to reach 1V. So Chip what part of the I/O structure could be doing that?
TAQOZ# 0 PIN L H F ok
This is the F word in TAQOZ:
' F - float pin
F _ret_ dirl pinreg
It seems if I do this to P59 where I have a 10k pullup then this strange thing happens:
TAQOZ# 59 PIN L H F ok
It's as if "dirl" is also driving the pin low briefly.
Peter, do you have the actual chips, already, or is this on the FPGA?
Can you post a similar pic for floating from a driven low state? ( H L F)
Is there a capacitance listed on your cro probe? A quick/poor guestimation if you have a 10k pullup it looks like 25~30 pF total capacitance on the rise.
I see what you mean about the unexpected transition on DIRL though.
Peter, if you run at the default 25MHz, do you see a whole clock period of low before floating? I'm not sure what frequency you are running at, so I can't tell from your scope picture if this is a glitch or a whole clock period of low before floating.
Peter, if you run at the default 25MHz, do you see a whole clock period of low before floating? I'm not sure what frequency you are running at, so I can't tell from your scope picture if this is a glitch or a whole clock period of low before floating.
I don't think it gets fully low, it is related to this Peter reports " instead of the high state decaying gradually it instead drops immediately to 1.78V and then decays from there taking 120us to reach 1V."
ie a glitch, but even there, a somewhat voltage-related glitch.
Quite strange.
I wonder if all VIO are properly connected, or if that 1.78V is related to the Vcore , or if all pins do it ? (seems to be pin0, pin59)
If you run those TAQOZ scripts on your device, do you see the same 1.78 step-effect ?
Perhaps, doing a carefull reading at the data available at that screen could shade some light about what we are really seeing.
As for the voltage levels we are seeing in it:
The AY = 1.780 V reading is showing how HIGH has signal excursion reached, from the solid black line reference level (suposed to be the ZERO reference level, according to the numeric calculations Rigol's scope processor has done, whose results are shown at the screen);
The BY = - 1.920 V reading is showing how LOW has signal excursion reached, from the same solid black line (or ZERO reference level);
(BY - AY = - 3.700 V); so, take its modulus, and we get something that is fully compatible with a 3.3V signal excursion, with about an overshoot of + 0.2 V, and also an undershoot of - 0.2 V. In other words: at least to me, it seems to be quite we could expect to see, in terms of a full 3.3V logic level excursion, with a bit of overshoot and undershoot too.
I'm yet trying to interpret what we are seeing when it comes for signal timings.
Sorry, I had an early night last night, I went to bed at 2AM.
Yes, this is at 20MHz default (actually 22.8MHz) and the scope diagram would explain why we need a pullup on P59 since the change to float using dirl seems to drive the pin low down to 1.8V briefly before actually floating. So the scope shot on P59 shows the pullup pulling it back up again after this glitch but without a pullup this pin already appears pulled down.
The test in TAQOZ is basically:
59 PIN L H F
Breaking that down:
59 PIN ( select pin 59 )
L ( drive the selected pin LOW = drvl )
H ( drive the selected pin HIGH = drvh )
F ( Float the selected pin = dirl )
Does the glitch(s) also appear, when pin drivers are switched from driving high to float, and then back to driving high, and back to float, repeteadly?
And if you does:
59 PIN F H F H F
or
59 PIN H F H F H
Does beggining and ending the command line (hence, starting the pin and ending it at the same logic/drive level) modifies what you see at the scope?
.... In other words: at least to me, it seems to be quite we could expect to see, in terms of a full 3.3V logic level excursion, with a bit of overshoot and undershoot too.
Not quite - what is unexpected is the active (glitch) pin behaviour, when the pin is switched from DRIVE to FLOAT.
That should be quite passive, when looking at a pin - minimal change to Open-drain activity.
Be interesting to see if CHhp can duplicate that on another P2, and even if the earlier PAD ring test run shows the same effect ?
If two registers (DIRL and DIRH) have to be modified to float a pin -- even if they're written simultaneously -- isn't that the kind of behavior you would expect if they don't both disable their respective pin drivers at exactly the same time?
If two registers (DIRL and DIRH) have to be modified to float a pin -- even if they're written simultaneously -- isn't that the kind of behavior you would expect if they don't both disable their respective pin drivers at exactly the same time?
Yes, anything that tried to change both the PIN and DIR on the same edge, is exposed to path skew effects.
Special break-before-make design would be needed to ensure no overlaps.
However, that's likely for other tests, as this one seems to fail on a single destination opcode ?
DIRL {#}D {WCZ} DIR bit of pin D[5:0] = 0. C,Z = DIR bit.
The opcodes that would need skew attention, are the dual-destination ones
FLTL {#}D {WCZ} OUT bit of pin D[5:0] = 0. DIR bit = 0. C,Z = OUT bit.
FLTH {#}D {WCZ} OUT bit of pin D[5:0] = 1. DIR bit = 0. C,Z = OUT bit.
FLTC {#}D {WCZ} OUT bit of pin D[5:0] = C. DIR bit = 0. C,Z = OUT bit.
FLTNC {#}D {WCZ} OUT bit of pin D[5:0] = !C. DIR bit = 0. C,Z = OUT bit.
FLTZ {#}D {WCZ} OUT bit of pin D[5:0] = Z. DIR bit = 0. C,Z = OUT bit.
FLTNZ {#}D {WCZ} OUT bit of pin D[5:0] = !Z. DIR bit = 0. C,Z = OUT bit.
FLTRND {#}D {WCZ} OUT bit of pin D[5:0] = RND. DIR bit = 0. C,Z = OUT bit.
FLTNOT {#}D {WCZ} OUT bit of pin D[5:0] = !bit. DIR bit = 0. C,Z = OUT bit.
DRVL {#}D {WCZ} OUT bit of pin D[5:0] = 0. DIR bit = 1. C,Z = OUT bit.
DRVH {#}D {WCZ} OUT bit of pin D[5:0] = 1. DIR bit = 1. C,Z = OUT bit.
DRVC {#}D {WCZ} OUT bit of pin D[5:0] = C. DIR bit = 1. C,Z = OUT bit.
DRVNC {#}D {WCZ} OUT bit of pin D[5:0] = !C. DIR bit = 1. C,Z = OUT bit.
DRVZ {#}D {WCZ} OUT bit of pin D[5:0] = Z. DIR bit = 1. C,Z = OUT bit.
DRVNZ {#}D {WCZ} OUT bit of pin D[5:0] = !Z. DIR bit = 1. C,Z = OUT bit.
DRVRND {#}D {WCZ} OUT bit of pin D[5:0] = RND. DIR bit = 1. C,Z = OUT bit.
DRVNOT {#}D {WCZ} OUT bit of pin D[5:0] = !bit. DIR bit = 1. C,Z = OUT bit.
Here is the same test using explicit pin numbers so we can set one pin and then another in this sequence:
59 LOW 0 LOW 59 HIGH 0 HIGH 59 FLOAT 0 FLOAT
So P59 with the pullup will pull low and trigger the scope in this capture then P0 will follow then P59 will go high followed by P0 before they float. BTW, it makes no difference how times I repeat the float, the glitch only occurs on a transition from an output to an input.
So when P0 (the red trace) switches from a high output to an input (at the end of the sequence) it should still be high but discharging, however it drops immediately to roughly half supply before floating. This seems to be the glitch we see in the top trace just prior to this that must discharge the pin briefly.
P59 Blue trace
P0 Red trace
btw - the new forum software seems to repeat private messages and when I insert an image it does it five times, so I have to delete 4 links each time.
Well, it kinda looks bad. Not sure it is actually a problem in a real application though... Is it?
Also, does this go away at 200 MHz?
One does not normally switch from output to input and expect the pin to actually be floating which we do during boot, so this is not normally a problem. This happens independently of the frequency.
Also this has nothing to do with the FLTx instructions since this is simply using a DIRL instruction to switch the pin to an input.
So when P0 (the red trace) switches from a high output to an input (at the end of the sequence) it should still be high but discharging, however it drops immediately to roughly half supply before floating
I wonder if the pins are constructed with fets (I think they are), and the voltage you are seeing is caused by the intrinsic body diode. At turn off, if one of the diodes (in one of the fets on the smart pin) is still conducting for some moments, that could pull the level straight down to the sort of voltage your seeing.
So when P0 (the red trace) switches from a high output to an input (at the end of the sequence) it should still be high but discharging, however it drops immediately to roughly half supply before floating
I wonder if the pins are constructed with fets (I think they are), and the voltage you are seeing is caused by the intrinsic body diode. At turn off, if one of the diodes (in one of the fets on the smart pin) is still conducting for some moments, that could pull the level straight down to the sort of voltage your seeing.
CMOS are Complementary ( as in N and P channel ) Metal Oxide Semiconductor FETS so technically should be called CMOSFET as in the familiar term MOSFET but is shortened to CMOS. Typically the drive and sink MOSFETs are gated by the DIR register so this has to be enabled for either transistor to turn on. Using the instruction DIRL should disable all and any drive. Even if there was a race condition it wouldn't explain the sinking glitch. It would be good to be able to glimpse the Verilog but on reflection this must be a silicon implementation problem since the FPGAs worked.
... Even if there was a race condition it wouldn't explain the sinking glitch. It would be good to be able to glimpse the Verilog but on reflection this must be a silicon implementation problem since the FPGAs worked.
That's why I wondered if the test PAD Ring chip has the same issues ?
Another test would be to complement the whole operation, so the pin is low when floated, and see if any glitch (+ve going) appears then ?
IIRC the I/O pin structure is done by Parallax. It is not an OnSemi block, and it's NOT the same as the FPGA which cannot simulate the pin precisely. Remember, this has Parallax's analog and pull-ups and pulldowns on the pin.
I thought this section of the chip was the purpose and was fully tested in the last test silicon about 6 months ago.
I've got all the sign-extension stuff rewritten to exclude "$signed()" wherever possible.
The last sign-related thing to test was the Goertzel circuitry, which tests lots of other stuff, too. Here is a gif of the P2 running at 200MHz, measuring 100 cycles of 10MHz (10us per measurement). A swept sine signal is being driven into a pin in ADC mode, going from 9.5MHz to 10.5MHz over 1ms. You can see that there is pretty good discrimination.
Well, I can't seem to get the .gif to work. Any ideas?
IIRC the I/O pin structure is done by Parallax. It is not an OnSemi block, and it's NOT the same as the FPGA which cannot simulate the pin precisely. Remember, this has Parallax's analog and pull-ups and pulldowns on the pin.
I thought this section of the chip was the purpose and was fully tested in the last test silicon about 6 months ago.
Now that I'm done with the sign-extension stuff, I'll look into this I/O glitch.
IIRC the I/O pin structure is done by Parallax. It is not an OnSemi block, and it's NOT the same as the FPGA which cannot simulate the pin precisely. Remember, this has Parallax's analog and pull-ups and pulldowns on the pin.
I thought this section of the chip was the purpose and was fully tested in the last test silicon about 6 months ago.
Now that I'm done with the sign-extension stuff, I'll look into this I/O glitch.
Peter, I'm seeing the same thing on P59, but not on a few other pins that I tried.
There seems to be a 4ns glitch. Not sure what causes it, yet, but that other pins don't exhibit this problem makes me think it's the synthesized logic causing it.
If you enable clocking in the pin, the glitch goes away. This only registers the OUT signal, not the DIR signal, inside the pin. So, OUT is glitching low on P59 due to the synthesized logic. We will be able to eliminate this on the next spin, once we identify the cause. Try this:
con pin = 59
dat org
'wrpin clkena,#pin 'uncomment to eliminate glitch
.loop drvl #pin
drvh #pin
dirl #pin
jmp #.loop
clkena long %0000_0000_000_0000100000000_00_00000_0
If you enable clocking in the pin, the glitch goes away. This only registers the OUT signal, not the DIR signal, inside the pin. So, OUT is glitching low on P59 due to the synthesized logic. We will be able to eliminate this on the next spin, once we identify the cause.
hmm, but why does OUT even come into play here, as DIRL claims to only write to one register ?
Clocked or not, should not matter if the OUT is properly untouched.
Still looks like some unwanted/unexpected crosstalk somewhere.
It could be in the PAD Ring logic, but sometimes the pulse difference is small enough to not make it through.
Comments
Peter, do you have the actual chips, already, or is this on the FPGA?
Can you post a similar pic for floating from a driven low state? ( H L F)
Is there a capacitance listed on your cro probe? A quick/poor guestimation if you have a 10k pullup it looks like 25~30 pF total capacitance on the rise.
I see what you mean about the unexpected transition on DIRL though.
I don't think it gets fully low, it is related to this Peter reports " instead of the high state decaying gradually it instead drops immediately to 1.78V and then decays from there taking 120us to reach 1V."
ie a glitch, but even there, a somewhat voltage-related glitch.
Quite strange.
I wonder if all VIO are properly connected, or if that 1.78V is related to the Vcore , or if all pins do it ? (seems to be pin0, pin59)
If you run those TAQOZ scripts on your device, do you see the same 1.78 step-effect ?
As for the voltage levels we are seeing in it:
The AY = 1.780 V reading is showing how HIGH has signal excursion reached, from the solid black line reference level (suposed to be the ZERO reference level, according to the numeric calculations Rigol's scope processor has done, whose results are shown at the screen);
The BY = - 1.920 V reading is showing how LOW has signal excursion reached, from the same solid black line (or ZERO reference level);
(BY - AY = - 3.700 V); so, take its modulus, and we get something that is fully compatible with a 3.3V signal excursion, with about an overshoot of + 0.2 V, and also an undershoot of - 0.2 V. In other words: at least to me, it seems to be quite we could expect to see, in terms of a full 3.3V logic level excursion, with a bit of overshoot and undershoot too.
I'm yet trying to interpret what we are seeing when it comes for signal timings.
Henrique
Yes, this is at 20MHz default (actually 22.8MHz) and the scope diagram would explain why we need a pullup on P59 since the change to float using dirl seems to drive the pin low down to 1.8V briefly before actually floating. So the scope shot on P59 shows the pullup pulling it back up again after this glitch but without a pullup this pin already appears pulled down.
The test in TAQOZ is basically:
Breaking that down:
59 PIN ( select pin 59 )
L ( drive the selected pin LOW = drvl )
H ( drive the selected pin HIGH = drvh )
F ( Float the selected pin = dirl )
Or, if it's just the DRVH to DIRL transition...
Maybe split DRVH into DIRH and OUTH...
And if you do something in the line:
59 PIN H F H F
Does the glitch(s) also appear, when pin drivers are switched from driving high to float, and then back to driving high, and back to float, repeteadly?
And if you does:
59 PIN F H F H F
or
59 PIN H F H F H
Does beggining and ending the command line (hence, starting the pin and ending it at the same logic/drive level) modifies what you see at the scope?
Henrique
So what writes first, the DIRx or the OUTX?
That should be quite passive, when looking at a pin - minimal change to Open-drain activity.
Be interesting to see if CHhp can duplicate that on another P2, and even if the earlier PAD ring test run shows the same effect ?
Good question, worth checking & easy to do.
They should both be written at the same clock edge.
I'm still verifying the sign-extension edits on the FPGA, but I'll be onto this next.
-Phil
Yes, anything that tried to change both the PIN and DIR on the same edge, is exposed to path skew effects.
Special break-before-make design would be needed to ensure no overlaps.
However, that's likely for other tests, as this one seems to fail on a single destination opcode ?
DIRL {#}D {WCZ} DIR bit of pin D[5:0] = 0. C,Z = DIR bit.The opcodes that would need skew attention, are the dual-destination ones
FLTL {#}D {WCZ} OUT bit of pin D[5:0] = 0. DIR bit = 0. C,Z = OUT bit. FLTH {#}D {WCZ} OUT bit of pin D[5:0] = 1. DIR bit = 0. C,Z = OUT bit. FLTC {#}D {WCZ} OUT bit of pin D[5:0] = C. DIR bit = 0. C,Z = OUT bit. FLTNC {#}D {WCZ} OUT bit of pin D[5:0] = !C. DIR bit = 0. C,Z = OUT bit. FLTZ {#}D {WCZ} OUT bit of pin D[5:0] = Z. DIR bit = 0. C,Z = OUT bit. FLTNZ {#}D {WCZ} OUT bit of pin D[5:0] = !Z. DIR bit = 0. C,Z = OUT bit. FLTRND {#}D {WCZ} OUT bit of pin D[5:0] = RND. DIR bit = 0. C,Z = OUT bit. FLTNOT {#}D {WCZ} OUT bit of pin D[5:0] = !bit. DIR bit = 0. C,Z = OUT bit. DRVL {#}D {WCZ} OUT bit of pin D[5:0] = 0. DIR bit = 1. C,Z = OUT bit. DRVH {#}D {WCZ} OUT bit of pin D[5:0] = 1. DIR bit = 1. C,Z = OUT bit. DRVC {#}D {WCZ} OUT bit of pin D[5:0] = C. DIR bit = 1. C,Z = OUT bit. DRVNC {#}D {WCZ} OUT bit of pin D[5:0] = !C. DIR bit = 1. C,Z = OUT bit. DRVZ {#}D {WCZ} OUT bit of pin D[5:0] = Z. DIR bit = 1. C,Z = OUT bit. DRVNZ {#}D {WCZ} OUT bit of pin D[5:0] = !Z. DIR bit = 1. C,Z = OUT bit. DRVRND {#}D {WCZ} OUT bit of pin D[5:0] = RND. DIR bit = 1. C,Z = OUT bit. DRVNOT {#}D {WCZ} OUT bit of pin D[5:0] = !bit. DIR bit = 1. C,Z = OUT bit.So when P0 (the red trace) switches from a high output to an input (at the end of the sequence) it should still be high but discharging, however it drops immediately to roughly half supply before floating. This seems to be the glitch we see in the top trace just prior to this that must discharge the pin briefly.
P59 Blue trace
P0 Red trace
btw - the new forum software seems to repeat private messages and when I insert an image it does it five times, so I have to delete 4 links each time.
Also, does this go away at 200 MHz?
One does not normally switch from output to input and expect the pin to actually be floating which we do during boot, so this is not normally a problem. This happens independently of the frequency.
Also this has nothing to do with the FLTx instructions since this is simply using a DIRL instruction to switch the pin to an input.
I wonder if the pins are constructed with fets (I think they are), and the voltage you are seeing is caused by the intrinsic body diode. At turn off, if one of the diodes (in one of the fets on the smart pin) is still conducting for some moments, that could pull the level straight down to the sort of voltage your seeing.
Another test would be to complement the whole operation, so the pin is low when floated, and see if any glitch (+ve going) appears then ?
I thought this section of the chip was the purpose and was fully tested in the last test silicon about 6 months ago.
The last sign-related thing to test was the Goertzel circuitry, which tests lots of other stuff, too. Here is a gif of the P2 running at 200MHz, measuring 100 cycles of 10MHz (10us per measurement). A swept sine signal is being driven into a pin in ADC mode, going from 9.5MHz to 10.5MHz over 1ms. You can see that there is pretty good discrimination.
Well, I can't seem to get the .gif to work. Any ideas?
Now that I'm done with the sign-extension stuff, I'll look into this I/O glitch.
Peter, Ray, instead of doing a FLTL, try a DIRL.
I already do a DIRL.
There seems to be a 4ns glitch. Not sure what causes it, yet, but that other pins don't exhibit this problem makes me think it's the synthesized logic causing it.
If you enable clocking in the pin, the glitch goes away. This only registers the OUT signal, not the DIR signal, inside the pin. So, OUT is glitching low on P59 due to the synthesized logic. We will be able to eliminate this on the next spin, once we identify the cause. Try this:
hmm, but why does OUT even come into play here, as DIRL claims to only write to one register ?
Clocked or not, should not matter if the OUT is properly untouched.
Still looks like some unwanted/unexpected crosstalk somewhere.
It could be in the PAD Ring logic, but sometimes the pulse difference is small enough to not make it through.