Shop Learn
New P2 Silicon Observations - Page 8 — Parallax Forums

New P2 Silicon Observations

1568101123

Comments

  • cgraceycgracey Posts: 13,627
    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
    
    floatglitch.png
    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?
  • jmgjmg Posts: 14,820
    edited 2018-10-03 20:36
    cgracey wrote: »
    Peter, do you have the actual chips, already, or is this on the FPGA?
    yes, this is p2 silicon. See also the p2d2 thread
  • Peter,

    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.

  • cgraceycgracey Posts: 13,627
    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.
  • jmgjmg Posts: 14,820
    cgracey wrote: »
    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.

    Henrique

  • 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 )
  • RaymanRayman Posts: 12,259
    edited 2018-10-03 22:18
    Wonder what happens with a second dirl…

    Or, if it's just the DRVH to DIRL transition...

    Maybe split DRVH into DIRH and OUTH...
  • Hi Peter Jakacki

    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
  • Doesn't DRVx and FLTx have to do two writes?
    So what writes first, the DIRx or the OUTX?
  • jmgjmg Posts: 14,820
    edited 2018-10-03 22:41
    Yanomani wrote: »
    .... 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 ?
    Rayman wrote: »
    Wonder what happens with a second dirl…
    Good question, worth checking & easy to do.

  • cgraceycgracey Posts: 13,627
    ozpropdev wrote: »
    Doesn't DRVx and FLTx have to do two writes?
    So what writes first, the DIRx or the OUTX?

    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 Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,057
    edited 2018-10-03 23:05
    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?

    -Phil
  • jmgjmg Posts: 14,820
    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.
    
  • evanhevanh Posts: 11,889
    Hmm, DRVxx instructions too. Good point JMG. :(
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-10-03 23:38
    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
    P2%20IO%20GLITCH.png


    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.
    800 x 480 - 39K
  • RaymanRayman Posts: 12,259
    edited 2018-10-03 23:36
    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?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-10-03 23:43
    Rayman wrote: »
    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.



  • RaymanRayman Posts: 12,259
    Actually, it'd be interesting to see if fltx did the same thing...
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-10-04 00:03
    VonSzarvas wrote: »
    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.

  • jmgjmg Posts: 14,820
    ... 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 ?

  • If I switch to 228MHz and toggle P59 low high and then float, this is what it looks like:
    30PF PLLEN 12 XIDIV 228 VCOMUL 1 PLLDIV USEPLL
    59 PIN L H F
    
    P2%20IO%20GLTICH%20228MHZ.png
    800 x 480 - 38K
  • Cluso99Cluso99 Posts: 17,972
    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.
  • cgraceycgracey Posts: 13,627
    edited 2018-10-04 03:10
    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?
    600 x 450 - 1M
  • cgraceycgracey Posts: 13,627
    Cluso99 wrote: »
    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, Ray, instead of doing a FLTL, try a DIRL.
  • Chip, make it a video and upload to youtube?
  • cgracey wrote: »
    Cluso99 wrote: »
    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, Ray, instead of doing a FLTL, try a DIRL.

    I already do a DIRL.
    ' F - float pin
    F               _ret_   dirl    pinreg
    
  • cgraceycgracey Posts: 13,627
    edited 2018-10-04 03:34
    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
    
  • jmgjmg Posts: 14,820
    cgracey wrote: »
    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.


Sign In or Register to comment.