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

New P2 Silicon Observations

17810121323

Comments

  • RaymanRayman Posts: 11,996
    Neat. Be easy to copy Phil's trick for voice recognition...

    At 200 MHz and ADC, seems we could also do FFT maybe a bit better but slower...
  • cgraceycgracey Posts: 13,588
    Here is a letter I wrote to Wendy which summarizes our glitch problem:
    Wendy,

    I realize now that the reason the ROM seemed to be buggy was because of glitching that occurs when floating a high output pin.

    In the picture, you see P59 on top and P58 on the bottom. At first, they are each driving low, then driving high, then being FLOATED (DIR falls). When the float occurs on a high pin, each P0..P63 glitches to a different extent. You can see that P59 glitches almost half way down when floated (DIR falls, inducing a temporary negative spike on PO before DIR falling takes effect). Each pin is different in this regard because of the lay of the auto-generated wiring and, possibly, test logic.

    Do you have a map of what your test circuitry uses P0..P63 for? That might shed more light. It's kind of hard to imagine that an internally-driven wire could be influenced to actually change state temporarily (4ns is long!), as PO seems to, but maybe there's some intervening test logic that is doing this.

    We need to know what's causing this. Perhaps some test-circuitry mux'ing needs to be reorganized, and then we could skew-band the DIR and PO signals, as well as shield them each on the next turn.

    Thanks.

    Chip


    2048 x 1152 - 720K
  • jmgjmg Posts: 14,666
    cgracey wrote: »
    Here is a letter I wrote to Wendy which summarizes our glitch problem:

    Do you have a circuit of how the synthesis signals interface to the fixed PAD-Ring logic ? (including the wide-OR that's in there too somewhere )

    Does the synth process allow you to control P:N drive strengths ?

    You could ask onSemi for plots (or sims) of P59, P58 routing paths and cross talks on those paths.
  • cgraceycgracey Posts: 13,588
    jmg wrote: »
    cgracey wrote: »
    Here is a letter I wrote to Wendy which summarizes our glitch problem:

    Do you have a circuit of how the synthesis signals interface to the fixed PAD-Ring logic ? (including the wide-OR that's in there too somewhere )

    Does the synth process allow you to control P:N drive strengths ?

    You could ask onSemi for plots (or sims) of P59, P58 routing paths and cross talks on those paths.

    What wide-OR are you meaning? I don't know of any.

    Yes, I will ask for some data on P59's and P58's DIR and PO signals from the core.
  • jmgjmg Posts: 14,666
    edited 2018-10-04 21:39
    BTW - this is the 1.8V current I measured at different clock frequencies.
    1.8V supply current
    300MHZ 782ma FAIL
    290MHZ 760ma
    270MHZ 712ma
    228MHZ 637ma
    200MHZ 542ma
    180MHZ 492ma
    114MHZ 333ma
    RCFAST = 70ma
    

    Those look similar to Chip's - COGs (Clock tree only) values.

    I've not seen RCSLOW Icc numbers or even a confirm RCSLOW works ok ?

    The Cpd formula predicts
    Vcc=1.8; Pd = Cpd * Vcc^2 * Fi = 112uA at 20kHz,1v8 + Static Iq value

    Vcc = 1.5 Pd = 78uA
    Vcc = 1.3 Pd = 58uA + Static Iq should drop more quickly ?

    My curve fits of Chip's table gave ~5mA static Icc, but that may include Xtal-Osc and/or RCFAST overheads ?

    Another means to lower Icc below ~70mA would be to use the lowest PLL output (or just a divided Xtal, if that path exists ?)

    What is the lowest possible sysCLK using PLL ?

    Is it possible to RCSLOW and keep the Xtal running ? (IIRC Chip mentioned some HW fixed Startup time on Xtal enable?)

    I also figured a way to measure RCFAST and RCSLOW, maybe on Chip's P2 Board ?
    The NXP 74AHC1G4210/12/14 are new SOT25 Osc/Dividers, so one of those could connect to (or replace) P2 Xtal Osc, and output (eg) 732.421875Hz at 12MHz, 2^14 case.

    A ~100mS read time will resolve RCSLOW to 0.05% - I think there is a smart pin mode for measure time for X whole cycles, X = 74 here
    Expected dT value is 20k/(12M/2^14/74) = 2020.693

    Curve fit of RCFAST and RCSLOW may give a means to measure die temperature.


    Addit: low power OSC options :
    TG-5035CJ-13N 19.2000M3 gives 19.2MHz Standby (Power Down) 2ms max wakeup, 1.7 V ~ 3.6 V ±500ppb -40°C ~ 85°C < 1.5mA 91c/2.5k
    That will also need Xtal-Amplifier ON

    Other Oscillator choices :
    DSC6001 Microchip - 1.3mA typ Icc ~64c/3k/ ±50ppm
    DSC6003CI2A-012.0000T 1.25mA ~ 74c ±25ppm

    and for ~ 67c/3k, there are even lower power choices
    Current Consumption  IDD  SiT8021 1 to 26 MHz, Ultra-Small µPower Oscillator 4-UFBGA (1.54mm x 0.84mm)
    - Typ Max
    – 60  –   µA     f = 3.072 MHz, Vdd = 1.8V, no load
    – 110 130 µA     f = 6.144 MHz, Vdd = 1.8V, no load
    – 230 270 µA     f = 6.144 MHz, Vdd = 1.8V, 10 pFload
    – –   160 µA     f = 6.144 MHz, Vdd = 2.25V to 3.63V, no load
    – 160 –   µA     f = 12 MHz, Vdd = 1.8V, no load
    Standby Current[3] I_std 
    – 0.7 1.3 µA     Vdd = 1.8V, ST pin = HIGH, output is weakly pulled down
    – –   1.5 µA     Vdd = 2.25V to 3.63V, ST pin = HIGH, output is weakly pulled down 
    Startup Time T_start – 75 150 ms     Measured from the time VDD reaches 90% of its final value
    Standby Time T_stdby – –   20 µs     Measured from the time ST pin crosses 50% threshold
    Resume Time T_resume – 2    3 ms     Measured from the time ST pin crosses 50% threshold 
    InitialTolerance       f_tol  -15  – +15  ppm Frequency offset at 25°C postreflow
    FrequencyStability     f_stab -100 – +100 ppm Inclusive of initial tolerance, and variations over operating temperature, rated power supply voltage and output load.
    First Year Aging       f_1year -3    +3   ppm at 25°C 
    Contact SiTime for ±25 or ±50 ppm options.
    
    That's low enough to run continually, with modest Icc, and if the design needed to keep more precise time during RCSLOW, it looks like a 74AHC1G421x could feed a smart-pin-counter.
    (2.048MHz at 3v3 into 74AHC1G421x indicates ~89uA adder for the high-precision-sleep option. (62.5Hz edges)

    Comes down to what is Static Icc looking like ?
  • Rayman wrote: »
    This section seems to imply that you can float or drive pins:
    %P..P:  low-level pin control (needs final silicon to fully operate)
                 %0000CIOHHHLLL = digital mode (default = %0000000000000)
                          %C: 1 = clocked I/O (extra clock for IN and OUT)
                          %I: 1 = invert IN output
                          %O: 1 = invert OUT input
                      %HHH: 000 = drive high, other = float when driven high
                      %LLL: 000 = drive low,  other = float when driven low
    

    This is a really good point, you can configure the pin to have one sided drive, other side float. Then you're only toggling OUT without needing to toggle DIR. That doesn't cost the extra clock that clocked/registered I/O might need. So there are few practical workaround options available with the silicon as it is, we're just 'zoomed in' on the problem to gain maximum understanding, at the moment.

    Back on the fpga images for a moment, these also used to show up a few phantom pull up/down pins when using the LSIO command. I wonder if some understanding could be gained from this, since we could recompile the FPGA image with different constraints on those signals, or check the correlation between signal path timing and length of external glitch etc.

  • cgraceycgracey Posts: 13,588
    edited 2018-10-04 21:17
    I got word back from Wendy on the test logic insertion. It's pretty simple.

    The following pins' signals get mux'd, but the other pins' signals don't:

    P0 = tck
    P1 = trst
    P2 = tms
    P3 = tdi
    P4 = tdo
    P6 = test_reset
    P7 = shift_capture_clock
    P8 = scan_en
    P10 = scan_in
    P11 = scan_out
    P12 = scan_in
    P13 = scan_out
    P14 = scan_in
    P15 = scan_out
    P16 = scan_in
    P17 = scan_out

    So, this means:

    P5, P9, P18..P63 = unused for test, no mux'ing.

    These pins' DIR and OUT signals come from flop outputs in the core and go straight to the pins' DIR and OUT inputs, without any combinatorial logic, though buffering may exist.

    What we are seeing on P59 is purely routing and possibly buffering delays, along with crosstalk.

    The tools ensured that the OUT signal would meet setup and hold timing for the I/O pad's internal flop, but what happened outside that window was "don't-care", apparently.
  • cgraceycgracey Posts: 13,588
    I set P58 and P59 for 1.5k-ohm low output and the glitch went away, since ~4ns of 1.5k to GND doesn't have much effect.
    dat	org
    
    	wrpin	pinmode,#59	'set 1.5k low drive
    	wrpin	pinmode,#58	'set 1.5k low drive
    
    .loop
    	mov	outa,#0
    	mov	outb,#0
    	neg	dira,#1
    	neg	dirb,#1
    	waitx	#10
    	neg	outa,#1
    	neg	outb,#1
    	waitx	#10
    	mov	dira,#0
    	mov	dirb,#0
    	waitx	#10
    	jmp	#.loop
    
    pinmode	long	%0000_0000_000_0000000000001_00_00000_0 'LLL = 001 (1.5k)
    

    2048 x 1152 - 701K
  • cgraceycgracey Posts: 13,588
    Here are the %PPPPPPPPPPPPP bits for the actual P2 silicon:

    1223 x 779 - 49K
  • jmgjmg Posts: 14,666
    cgracey wrote: »
    What wide-OR are you meaning? I don't know of any.

    P1 Data says this, so I'm assuming P2 is the same OUT/DIR OR ? :
    "Pin Directions are the result of OR'ing the Direction Registers of the cogs together. Pin Outputs are the result of OR'ing the output states of the cogs together. A cog's output state consists of the bits of its I/O modules (the Counters, the Video Generator, and the I/O Output Register) OR'd together then AND'd with the bits of its Direction Register. All cogs can still access and influence the I/O pins simultaneously, without electrical contention,"

    I guess that means this effect should be checked for all COGs, to see if it varies by their 'place in that OR' ?
  • jmgjmg Posts: 14,666
    Tubular wrote: »
    This is a really good point, you can configure the pin to have one sided drive, other side float. Then you're only toggling OUT without needing to toggle DIR. That doesn't cost the extra clock that clocked/registered I/O might need. So there are few practical workaround options available with the silicon as it is, we're just 'zoomed in' on the problem to gain maximum understanding, at the moment.
    Yes, another workaround, because this is low-energy, could be to add a 100R+47pF RC snubber, to see if that reduces the step.

  • cgraceycgracey Posts: 13,588
    jmg wrote: »
    cgracey wrote: »
    What wide-OR are you meaning? I don't know of any.

    P1 Data says this, so I'm assuming P2 is the same OUT/DIR OR ? :
    "Pin Directions are the result of OR'ing the Direction Registers of the cogs together. Pin Outputs are the result of OR'ing the output states of the cogs together. A cog's output state consists of the bits of its I/O modules (the Counters, the Video Generator, and the I/O Output Register) OR'd together then AND'd with the bits of its Direction Register. All cogs can still access and influence the I/O pins simultaneously, without electrical contention,"

    I guess that means this effect should be checked for all COGs, to see if it varies by their 'place in that OR' ?

    Oh, okay. That happens in the core logic about two clocks before the final DIR and OUT signals come out.
  • jmgjmg Posts: 14,666
    cgracey wrote: »
    Here are the %PPPPPPPPPPPPP bits for the actual P2 silicon:

    Nice table,
    Other settings to check there, could be 1mA drive (expect similar to 1.5k ?) - is that 1mA nom when shorted ? ie maybe just enough to direct drive a LED ?

    That seems to be missing a 'moderate' drive choice - fastest option is often avoided in MCU designs, for a softer choice (eg) 4mA spec, but that's 4mA at < 0.5V so sub 250 ohms.


    I also see 0000_ Pin A Logic OUT
    and 0011_ pin A Schmitt OUT
    - does the out path change in those ?
    & maybe output Invert/non invert also has a slight effect ?
  • OzProp, Rog, Richard, got anything important on this arvo?
  • cgraceycgracey Posts: 13,588
    jmg wrote: »
    cgracey wrote: »
    Here are the %PPPPPPPPPPPPP bits for the actual P2 silicon:

    Nice table,
    Other settings to check there, could be 1mA drive (expect similar to 1.5k ?) - is that 1mA nom when shorted ? ie maybe just enough to direct drive a LED ?

    That seems to be missing a 'moderate' drive choice - fastest option is often avoided in MCU designs, for a softer choice (eg) 4mA spec, but that's 4mA at < 0.5V so sub 250 ohms.


    I also see 0000_ Pin A Logic OUT
    and 0011_ pin A Schmitt OUT
    - does the out path change in those ?
    & maybe output Invert/non invert also has a slight effect ?

    The modes which use OUT for output are normal. The modes which use "input" for output actually use the selected input as the output. For example, You can use the "A > B" "input" mode with the "O" bit set (inverts output) and %010 for HHH and LLL (15k-ohm drive) to build an analog follower.

    The current drive modes use real current sources and sinks. Here is how to make a Schmitt oscillator on one pin to convert capacitance to frequency. I used a 0.1uF cap:
    dat	org
    
    	wrpin	pinmode,#1	'set Schmitt w/feedback and 100uA drive
    	dirh	#1		'enable output
    	jmp	#$		'loop
    
    pinmode	long	%0000_0000_000_0100001101101_00_00000_0
    


    2048 x 1152 - 678K
  • Tubular wrote: »
    OzProp, Rog, Richard, got anything important on this arvo?

    I'm free
  • Re: P59 pullup needed for boot.
    Regardless of any glitch issue, the P2 should boot without pullups.
    A bug in the ROM is the reason for thee need for the P59 pullup.

  • The rom is correct but does not detect pulldown correctly now that since some pins exhibit this glitch in this silicon. The rom boot was designed so that unless there were pull-up and pulldown resistors, it would boot normally
  • cgraceycgracey Posts: 13,588
    Okay. The ROM can be validated by putting a small capacitor on P59 to GND. That will prevent the glitch from lowering the voltage too much.
  • The ROM checks for 3 pullups.
    If no pullups are detected it should go to serial mode and wait, this can't happen the way the ROM code is currently.
    See here
    With 3 pulldowns on my FPGA it shutdowns immediately after reset, same as silicon P2.


  • jmgjmg Posts: 14,666
    cgracey wrote: »
    The modes which use OUT for output are normal. The modes which use "input" for output actually use the selected input as the output. For example, You can use the "A > B" "input" mode with the "O" bit set (inverts output) and %010 for HHH and LLL (15k-ohm drive) to build an analog follower.

    The current drive modes use real current sources and sinks. Here is how to make a Schmitt oscillator on one pin to convert capacitance to frequency. I used a 0.1uF cap:
    dat	org
    
    	wrpin	pinmode,#1	'set Schmitt w/feedback and 100uA drive
    	dirh	#1		'enable output
    	jmp	#$		'loop
    
    pinmode	long	%0000_0000_000_0100001101101_00_00000_0
    

    Wow, that's nifty to see working. A linear sawtooth too ! :)

    Have you tried that as a Capacitive Touch Sensor ?

    It should also work with inductors, AC coupled to a LC resonant circuit, for inductive proximity detector use.

  • cgraceycgracey Posts: 13,588
    jmg wrote: »
    cgracey wrote: »
    The modes which use OUT for output are normal. The modes which use "input" for output actually use the selected input as the output. For example, You can use the "A > B" "input" mode with the "O" bit set (inverts output) and %010 for HHH and LLL (15k-ohm drive) to build an analog follower.

    The current drive modes use real current sources and sinks. Here is how to make a Schmitt oscillator on one pin to convert capacitance to frequency. I used a 0.1uF cap:
    dat	org
    
    	wrpin	pinmode,#1	'set Schmitt w/feedback and 100uA drive
    	dirh	#1		'enable output
    	jmp	#$		'loop
    
    pinmode	long	%0000_0000_000_0100001101101_00_00000_0
    

    Wow, that's nifty to see working. A linear sawtooth too ! :)

    Have you tried that as a Capacitive Touch Sensor ?

    It should also work with inductors, AC coupled to a LC resonant circuit, for inductive proximity detector use.

    I haven't tried all those things, but figured that if we made some simple provisions, they would all be easy to do.
  • cgraceycgracey Posts: 13,588
    edited 2018-10-05 02:21
    The PLL's VCO tops out at 408MHz, which gives plenty of overhead. Well, it might be the VCO divider that runs out of steam at 408MHz. Not sure, but it's plenty good enough.

    I'm going through the PLL, getting a feel for its jitter.
  • The last two days I've been reading up on how to use a variable Capacitor for Positional Feedback.
    Could this setup do that?

    J
  • jmgjmg Posts: 14,666
    thej wrote: »
    The last two days I've been reading up on how to use a variable Capacitor for Positional Feedback.
    Could this setup do that?
    I would expect so. What range of Capacitance do you need to measure ?

  • I'm not really sure. I was exploring if it was even practical.
    I would need to make my own air gapped capacitor (unless i can find one premade).

    The idea is that it would be connected to a shaft and then its value measured as the shaft turned (90 deg rotation max).
    My first real question was how to measure this kind of cap fast enough directly from a uC so that I would have reasonable resolution. Most sources I found referenced using an RC circuit and measureing the time it takes the cap to ramp up but that seems completely impractical for quick measurements.

    Perhaps the smart pin in this mode answers the speed/resolution question?

    j
  • jmgjmg Posts: 14,666
    edited 2018-10-05 03:23
    thej wrote: »
    I'm not really sure. I was exploring if it was even practical.
    I would need to make my own air gapped capacitor (unless i can find one premade).

    The idea is that it would be connected to a shaft and then its value measured as the shaft turned (90 deg rotation max).
    My first real question was how to measure this kind of cap fast enough directly from a uC so that I would have reasonable resolution. Most sources I found referenced using an RC circuit and measureing the time it takes the cap to ramp up but that seems completely impractical for quick measurements.

    Perhaps the smart pin in this mode answers the speed/resolution question?

    j

    If you are talking shaft rotation, then you can get something premade like this Differential Capacitor claims 2.7 - 19.6 pF for one.

    Differential means have two C values you measure, (use 2 pins) and at some rotation they balance for the zero.
    The P2 Current sources, and Schmitt thresholds, are error sources, but they will tend to track on adjacent pins.

    You could use the 100uA or 10uA drive levels Chip mentioned above - 10pF/100uA/1V is going to give appx 5MHz, so you need short, leads.

    Measurement speed depends on resolution, but for a ball-park a 1MHz signal can resolve to 0.1% in a 1ms measure time.

    ..and a paper on Linear Cap measurement is here
  • cgraceycgracey Posts: 13,588
    edited 2018-10-05 03:41
    The PLL works better than expected.

    It regulates a heavily-RC-filtered copy of the 1.8V supply from the 3.3V supply on the V2831 pin. So, it has a very quiet VDD-level supply to power itself from. The 20MHz+ RC oscillator uses this same supply for stability.

    I can't believe the VCO locks down to 1.25MHz! I had figured it could be conservatively rated for 100MHz-200MHz operation, but I think 25MHz would be okay, too.

    With the PLL copying the crystal frequency and dividing it by 20 using the post-VCO divider to get 1MHz, the P2 draws 3.0mA at 1.8V.

    With the PLL dividing the crystal frequency by 10 and then post-dividing that by 20 to get 100KHz, the P2 draws 354uA at 1.8V.

    Switching down to the internal ~20KHz oscillator, the P2 draws 97uA at 1.8V. So, leakage isn't much.

    Here is the program I use to play with the PLL. It's set for 180MHz. I have a 20MHz crystal attached between XI and XO:
    con	xtl_div	=	1		'crystal divider	1..64
    	vco_mul	=	9		'vco multiplier		1..1024
    
    	clkmod	=	1<<24 + (xtl_div-1)<<18 + (vco_mul-1)<<8 + %1111_10_00
    	'clkmod	=	%1_000000_0000000000_1111_10_00	'PLL mode (manual version)
    
    dat	org
    
    	hubset	##clkmod		'enable crystal+PLL, stay in 20MHz+ mode
    	waitx	##20_000_000/100	'wait ~10ms for crystal+PLL to stabilize
    	hubset	##clkmod | %11		'now switch to PLL
    
    .loop	drvnot	#1			'2	P1 = Fsys/1000
    	waitx	#500-8			'2 + #
    	jmp	#.loop			'4
    
  • cgraceycgracey Posts: 13,588
    The PLL jitter seems to be identical to the crystal jitter, which makes sense, as long as it's locked.

    Based on the value of the 6-bit crystal divider, PLL charge-pump feedback current is increasingly weakened, getting around the need for separate filter settings. It seems to work really well.
  • That's great news!

    I'm chucking at P2 running at a brisk 1mhz...

    If the next one is clock gated, seems like the power equation is going to be a lot more favorable at higher clock rates.
Sign In or Register to comment.