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

New P2 Silicon Observations

1111214161723

Comments

  • jmgjmg Posts: 14,847
    edited 2018-10-07 23:59
    cgracey wrote: »
    Plus, they are only enabled when in use.
    Yes, but these are config MUX bits, so 'in use' here includes mapped to a smart pin. ie the set config bit also enables the Osc.

    Being able to calibrate the RC osc will be more important, to those trying to lower P2 usage power.
    cgracey wrote: »
    Jmg, the current oscillators are designed to be temperature-invariant.
    Most MCUs try to lower temperature shifts, and generally do better at that on the HFOSC than the LFOSC.
    That means there is usually a difference of the curves, that can be measured.
    It's a little rough, sure.
    Maybe the Analog IO can give a better means of Temperature capture ?
    You just need to find something that varies predictably with temperature, that can be measured.
    (ideally, without external parts, & without consuming a pin, tho a SPI pin might be dual-tasked if a pin must be used ?)

    Looking some more at Temp Sense :
    There are small, linear sensors from ~20c, smallest at Digikey is SNT4A (DFN 1.2 x 1.6mm) S-5813A with -11.04mV/°C
    Or TI/microchip have larger ones (SC70 -5 2.1x 2.4mm) with 10mV/°C or 19.5mV/°C choices.
    Linear are simple, and can meter-check too, but the P2 Analog errors become Temperature errors.

    Or, i2c ones can come in DFN8(2x3 0.5mm) packages, for similar prices. eg LM75BTP has an exposed pad too.

    The appeal of the smallest packages, is they can get closer to the P2 thermal pad, but still place on the top.

    Maybe Chip's board can include 1-2 temp sensors ?
  • I'm here with Ozprop and first up this morning we're looking at Pin driving impedance of the P2.

    Preliminary figures indicate
    16 ohms N-fet ("sinking") resistance, and
    19 ohms P-fet ("sourcing) resistance,
    at a load current around 25~28mA (and using 3v3 supply as is standard).

    These figures are really great, its a significantly stronger drive compared with the P8x32A, though the P and N are not as closely matched as the P8x32A had. For most purposes that doesn't matter

    Its going to be possible to power a small external module (eg an accelerometer or IMU) from this kind of strong drive. Eg an external 3v3 module that draws 20mA is still going to have 2.92V available to it when powered from a P2 pin. Sure it might need a bit of extra capacitance as reservoir if it draws spiky current, but thats easy to implement.

    I know Chip is proposing to turn both DAC and ADC on at the same time to measure interesting things, but the DAC has a higher drive resistance. Can the ADC be switched on when just doing a strong digital OUT, Chip? Because then you could measure current drawn by the external module, too.

    Looking good.
  • cgraceycgracey Posts: 13,631
    Tubular wrote: »
    I'm here with Ozprop and first up this morning we're looking at Pin driving impedance of the P2.

    Preliminary figures indicate
    16 ohms N-fet ("sinking") resistance, and
    19 ohms P-fet ("sourcing) resistance,
    at a load current around 25~28mA (and using 3v3 supply as is standard).

    These figures are really great, its a significantly stronger drive compared with the P8x32A, though the P and N are not as closely matched as the P8x32A had. For most purposes that doesn't matter

    Its going to be possible to power a small external module (eg an accelerometer or IMU) from this kind of strong drive. Eg an external 3v3 module that draws 20mA is still going to have 2.92V available to it when powered from a P2 pin. Sure it might need a bit of extra capacitance as reservoir if it draws spiky current, but thats easy to implement.

    I know Chip is proposing to turn both DAC and ADC on at the same time to measure interesting things, but the DAC has a higher drive resistance. Can the ADC be switched on when just doing a strong digital OUT, Chip? Because then you could measure current drawn by the external module, too.

    Looking good.

    Yes! Look at the mode table. All the ADC modes can drive if DIR=1, and you get to select %HHHLLLL.

    PAD_IO_modes.png
    1223 x 779 - 49K
  • cgraceycgracey Posts: 13,631
    I designed the pins to be equal in sink and source strength, but I think I made them equal at VIO/2, not at the rails.
  • jmgjmg Posts: 14,847
    cgracey wrote: »
    Yes! Look at the mode table. All the ADC modes can drive if DIR=1, and you get to select %HHHLLLL.

    What is the expected ADC resistor values, tolerances, and ADC offset errors ?

  • cgraceycgracey Posts: 13,631
    edited 2018-10-08 00:35
    jmg wrote: »
    cgracey wrote: »
    Yes! Look at the mode table. All the ADC modes can drive if DIR=1, and you get to select %HHHLLLL.

    What is the expected ADC resistor values, tolerances, and ADC offset errors ?

    The ADC impedance is about 540k ohms to roughly VIO/2.

    There are GIO and VIO calibration modes you can see in the mode table.

    To make conversions, you first must calibrate using GIO and VIO modes, which connect the ADC input to GND and VIO. Once you have GIO and VIO readings, you can determine scale and offset. Scale is the difference between VIO and GIO readings and offset is the GIO reading. Then you can use the 1x modes to get full-scale readings from either the pin or its odd/even partner pin.

    The 3.16x, 10x, 31.6x, and 100x modes are magnification modes and must be capacitor-coupled to allow the ADC to set the center bias to around VIO/2, which is a simple inverter's logic threshold inside the converter (there's no faster high-gain amplifier than a few digital inverters connected in series). The magnification modes can utilize the scale computation, but for offset would use the average of the GIO and VIO calibration readings (the floating center point, not the GND level). The magnification modes are maybe only practical for AC signals. The 100x mode is ~VIO/100 full-scale, or ~33mV.
  • jmgjmg Posts: 14,847
    edited 2018-10-08 00:46
    cgracey wrote: »
    Yes! Look at the mode table. All the ADC modes can drive if DIR=1, and you get to select %HHHLLLL.

    I think that means you can drive 100uA and measure the pin voltage ?

    Looking at differing means to measure die temperature, another possible idea is use OnSemi MAX1720 (TSOT-23-6) low cost charge pump.
    If you current drive those, they can act as a 'voltage reflector', where +Vin ~tracks whatever -Vout clamps at.

    The idea is to drive -Vout into a spare pin (TEST?) in current mode, and use the negative die clamp diode as a temp sense.
    MAX7120 needs ~ 40uA to operate sub 1.5V, leaving 60uA for clamping and ~ 50uA test drive into the -ve clamp diode.
    ADC then reads the +ve voltage, expected something under 1V. Hopefully, P2 does not care about 50uA into the Test pin clamp diode.

    The temperature drift of the 100uA & MAX1720 will matter, but the clamp nature of a diode helps here.
    Spice suggests 18mV of dV for a 2:1 current range, which maps to an equivalent of roughly 8'C

    Are there any estimates for the 100uA tolerance and temperature drift ?
  • cgraceycgracey Posts: 13,631
    edited 2018-10-08 00:57
    I modified my NTSC program so that the I and Q coefficients were zero'd out in the colorspace modulator, so that no modulation would occur (modulator has sign-extension problems). This yielded a monochrome NTSC signal.

    I made ALL 64 pins output using their 75-ohm 2.0V DACs, which become 1.0V when the TV's 75 ohms to ground is introduced.

    I fed 2.0V into VDD to allow high speed.

    So, the whole thing worked at 300MHz, with every pin outputting an NTSC signal from cog 0's colorspace converter. There was 970mA at 2.0V for VDD and 475mA at 3.3V for VIO. Total dissipation is ~3.5W and it runs indefinitely on the P2D2 board without any special heat dissipation.

    I wanted to try this because I wanted to see if there were any setup/hold problems between the core and our I/O pad, which registers the lower 8 bits of the 13-bit configuration word inside the DAC. No apparent data errors. I'll try lower voltages and speeds, too, to make sure no data is being missed.

    Here is the code:
    '*******************************
    '*  NTSC 256 x 192 x 8bpp-lut  *
    '*******************************
    
    CON
    
      f_color	= 3_579_545.0		'colorburst frequency
      f_scanline	= f_color / 227.5	'scanline frequency
      f_pixel	= f_scanline * 400.0	'pixel frequency for 400 pixels per scanline
    
      f_clock	= 300_000_000.0		'clock frequency
    
      f_xfr		= f_pixel / f_clock * float($7FFF_FFFF)
      f_csc		= f_color / f_clock * float($7FFF_FFFF) * 2.0
    
      s		= 90			'scale DAC output (s = 0..128)
      r		= s * 1000 / 1646	'precompensate for modulator expansion of 1.646
    
      mody		= ((+38*s/128) & $FF) << 24 + ((+75*s/128) & $FF) << 16 + ((+15*s/128) & $FF) << 8 + (110*s/128 & $FF)
      modi		= ((+00*r/128) & $FF) << 24 + ((-00*r/128) & $FF) << 16 + ((-00*r/128) & $FF) << 8 + (100*s/128 & $FF)
      modq		= ((+00*r/128) & $FF) << 24 + ((-00*r/128) & $FF) << 16 + ((+00*r/128) & $FF) << 8 + 128
    
      dacpin	= 1
    
    
    DAT		org
    '
    '
    ' Setup
    '
    		hubset	##%1_000000_0000001110_1111_10_00	'enable crystal+PLL, stay in 20MHz+ mode
    		waitx	##20_000_000/100			'wait ~10ms for crystal+PLL to stabilize
    		hubset	##%1_000000_0000001110_1111_10_11	'now switch to PLL
    
    		rdfast	#0,##$1000-$400		'load .bmp palette into lut
    		mov	x,#0
    		rep	@.end,#$100
    		rflong	y
    		shl	y,#8
    		wrlut	y,x
    		add	x,#1
    .end
    		rdfast	##256*192/64,##$1000	'set rdfast to wrap on bitmap
    
    		setxfrq ##round(f_xfr)		'set transfer frequency
    		setcfrq	##round(f_csc)		'set colorspace converter frequency
    
    		setcy	##mody			'set colorspace converter coefficients
    		setci	##modi
    		setcq	##modq
    
    		setcmod	#%11_1_0000		'set colorspace converter to YIQ mode (composite)
    
    .pin		wrpin	dacmode,pinx
    		drvl	pinx
    		djnf	pinx,#.pin
    '
    '
    ' Field loop
    '
    field           mov	x,#35			'top blanks
    		call	#blank
    
                    mov     x,#192			'set visible lines
    line	        call	#hsync			'do horizontal sync
    		xcont	m_rf,#0			'visible line
    		xcont	m_av,#1			'after visible spacer
    		djnz    x,#line           	'another line?
    
                    mov     x,#27			'bottom blanks
    		call	#blank
    
    		mov	x,#6			'high vertical syncs
    .vlow		xcont	m_hl,#2
    		xcont	m_hh,#1
    		djnz	x,#.vlow
    
    		mov	x,#6			'low vertical syncs
    .vhigh		xcont	m_ll,#2
    		xcont	m_lh,#1
    		djnz	x,#.vhigh
    
    		mov	x,#6			'high vertical syncs
    .vlow2		xcont	m_hl,#2
    		xcont	m_hh,#1
    		djnz	x,#.vlow2
    
                    jmp     #field                  'loop
    '
    '
    ' Subroutines
    '
    blank		call	#hsync			'blank lines
    		xcont	m_vi,#0
    		xcont	m_av,#1
    	_ret_	djnz	x,#blank
    
    hsync		xcont	m_sn,#2			'horizontal sync
    		xcont	m_bc,#1
    		xcont	m_cb,c_cb
    	_ret_	xcont	m_ac,#1
    '
    '
    ' Initialized data
    '
    pinx		long	63
    dacmode		long	%0000_0000_000_1011100000000_01_00000_0
    
    m_sn		long	$CF000000+29		'sync
    m_bc		long	$CF000000+7		'before colorburst
    m_cb		long	$CF000000+18		'colorburst
    m_ac		long	$CF000000+40		'after colorburst
    m_vi		long	$CF000000+256		'visible
    m_av		long	$CF000000+50		'after visible (400 total)
    
    m_rf		long	$7F000000+256		'visible rflong 8bpp lut
    
    m_hl		long	$CF000000+15		'vertical sync high low 
    m_hh		long	$CF000000+185		'vertical sync high high (200 total)
    
    m_ll		long	$CF000000+171		'vertical sync low low
    m_lh		long	$CF000000+29		'vertical sync low high (200 total)
    
    c_cb		long	$507000_01		'colorburst reference color
    
    x		res	1
    y		res	1
    '
    '
    ' Bitmap
    '
    		orgh	$1000 - $436	'justify pixels at $1000, pallete at $1000-$400
    		file	"bitmap.bmp"
    
    1114 x 815 - 511K
  • We just started looking at tempco of the oscillators

    RCFAST stability seems nothing short of amazing - couldn't budge the frequency using freeze spray nor hair dryer.

    RCSLOW exhibits a gentle negative tempco - faster kHz at cooler temps.

  • cgraceycgracey Posts: 13,631
    jmg wrote: »
    Are there any estimates for the 100uA tolerance and temperature drift ?

    No. The currents are set by a resistor/MOS combo. It's not super accurate, but in the ballpark.
  • cgraceycgracey Posts: 13,631
    edited 2018-10-08 01:18
    On the NTSC test, I've got it running at 80MHz with:

    VDD = 1.10V @ 135mA
    VIO = 2.0V @268mA

    That's with all pins in 75-ohm DAC mode, though at VIO = 2.0V, the DAC only outputs 1.21V, instead of 2.0V. The impedance is still 75 ohms, though.
  • cgraceycgracey Posts: 13,631
    The chip seems pretty robust, so far. I thought I had ruined it a few times, but it was just setup problems, usually due to the low-quality SIP receptacles that I soldered onto the P2D2. The glitch problem is a source of headaches, too.
  • cgracey wrote: »
    I fed 2.0V into VDD to allow high speed.

    So, the whole thing worked at 300MHz, with every pin outputting an NTSC signal from cog 0's colorspace converter. There was 970mA at 2.0V for VDD and 475mA at 3.3V for VIO. Total dissipation is ~3.5W and it runs indefinitely on the P2D2 board without any special heat dissipation.

    Stable 300MHz is amazing. Good stuff.
  • jmgjmg Posts: 14,847
    cgracey wrote: »
    On the NTSC test, I've got it running at 80MHz with:

    VDD = 1.10V @ 135mA
    VIO = 2.0V @268mA

    That's with all pins in 75-ohm DAC mode, though at VIO = 2.0V, the DAC only outputs 1.21V, instead of 2.0V. The impedance is still 75 ohms, though.

    Cool, some under-clocking numbers too :) Those are impressively low voltages... and the DAC still worked ok !

    Was that just above Vdd's where 80MHz stopped working ?

    Compared with that 300MHz 2V test
    970*2 = 1940mW
    135*1.1 = 148.5mW
    or a 13:1 power range.

    ... and compare 13mA*3.3V*8 = 343.2mW for P1

    What MHz does NTSC need to operate well enough ?
  • cgraceycgracey Posts: 13,631
    edited 2018-10-08 01:55
    jmg wrote: »
    What MHz does NTSC need to operate well enough ?

    12.5MHz works okay. That's not even 4x colorburst.
  • jmgjmg Posts: 14,847
    Tubular wrote: »
    We just started looking at tempco of the oscillators

    RCFAST stability seems nothing short of amazing - couldn't budge the frequency using freeze spray nor hair dryer.

    RCSLOW exhibits a gentle negative tempco - faster kHz at cooler temps.

    Sounds good. What rough % variation on RCSLOW ? how does it vary from sample to sample ? (IIRC Chip said 20.6kHz ?)


    How do they Vary with Vcore,Vio ?
    Attached are the data curves for Nuvoton part, sounds pretty much the same, ie with better fast osc than slow osc.

    480 x 470 - 43K
  • jmgjmg Posts: 14,847
    cgracey wrote: »
    jmg wrote: »
    What MHz does NTSC need to operate well enough ?

    12.5MHz works okay. That's not even 4x colorburst.

    So 300MHz was just showing off ? ;)

    27MHz seems to be a common clock for composite chips ?

    What Vcore can 12.5MHz work down to ?
  • cgraceycgracey Posts: 13,631
    edited 2018-10-08 02:11
    jmg wrote: »
    What Vcore can 12.5MHz work down to ?

    Around where the 80MHz voltages were. Once you get that low of voltage, it's the level shifters that start failing.
  • I wonder if you can drive false-color mode with the broken color modulator? That would at least give you Apple II graphics :smile:
  • jmg wrote: »
    Tubular wrote: »
    We just started looking at tempco of the oscillators

    RCFAST stability seems nothing short of amazing - couldn't budge the frequency using freeze spray nor hair dryer.

    RCSLOW exhibits a gentle negative tempco - faster kHz at cooler temps.

    Sounds good. What rough % variation on RCSLOW ? how does it vary from sample to sample ? (IIRC Chip said 20.6kHz ?)


    How do they Vary with Vcore,Vio ?
    Attached are the data curves for Nuvoton part, sounds pretty much the same, ie with better fast osc than slow osc.

    RCSLOW - just measuring using Rigol CRO's frequency measurement,
    at nominal room temp pin 1 output square wave was 5.15 kHz.
    with freeze spray got up to 5.5 kHz
    with hair dryer went down as far as 4.95 kHz.

    RCFAST - really couldn't budge it. Looks really good.
  • If I setup a pin as timing reference by typing 0 PIN 40 MHZ (which assumed the clock frequency was 80Mhz at the time) then the output frequency is exactly half the clock frequency. Typing in RCSLOW I then read 10kHz so that is precisely 20kHz clock speed for RCSLOW :)
    With a little freeze spray (4'C to 8'C reading) that climbed to 22.8kHz
  • jmgjmg Posts: 14,847
    edited 2018-10-08 02:52
    Tubular wrote: »
    RCSLOW - just measuring using Rigol CRO's frequency measurement,
    at nominal room temp pin 1 output square wave was 5.15 kHz.
    with freeze spray got up to 5.5 kHz
    with hair dryer went down as far as 4.95 kHz.

    RCFAST - really couldn't budge it. Looks really good.

    Thanks. So that's RCSLOW/4 at the pin, confirming Chips 20.6KHz exactly ?

    A rough compare (based on guesstimate dT's ) with Nuvoton gives
    P2 5.5/5.15 6.8% vs N76 ~10.5/9.6 9.375%
    P2 5.15/4.95 4.04% vs N76 ~9.6/8.5 12.94%
    P2 swing ~ 11%, vs N76 swing ~ 22%

    So P2 is similar ballpark, but better.
    There does look enough variation to use to measure die temperature, provided P2 could self-measure RCSLOW, or ratio RCFAST to RCSLOW.

  • cgraceycgracey Posts: 13,631
    edited 2018-10-08 03:10
    Jmg, the problem in monitoring RCFAST or RCSLOW is that it would require a schematic and GDS change to the clock pad design. RCFAST and RCSLOW are only enabled when they are in use. There's no way to make a Verilog change to do what you are talking about, even though it would be a great feature.

    You had asked me about doing this long before things were sewn up and thought about it, but I was overwhelmed just getting things basically functional.
  • jmgjmg Posts: 14,847
    cgracey wrote: »
    Jmg, the problem in monitoring RCFAST or RCSLOW is that it would require a schematic and GDS change to the clock pad design. RCFAST and RCSLOW are only enabled when they are in use. There's no way to make a Verilog change to do what you are talking about, even though it would be a great feature.
    Bummer. I think you are saying the SysCLK mux is buried in the full custom layout and RCFAST/RCSLOW do not cross the boundary themselves ?
    That's pretty much a brick wall then, for internal calibrate.

    For external calibrate I think a 74AHC1G421x can be used, tho that still dictates SysCLK be changed during measurements.
    When enabled/disabled, what happens to the P2 Xtal pins ? do they get PU/PD applied when off, FB when on ?

    Using dual slope integration on a pin, might allow frequency ratio RCFAST/RCSLOW, by running one on each slope, but that's quite a clock imposition to force on a design - most use cases I think would prefer external temperature assist.

    For better timing, users can apply sub 10kHz oscillators to a pin, and run doze at RCSLOW.

    Did you measure RCSLOW and ICC, at the 1.10V min indicated Vcore ? (and also at 2.0V Max ?)
  • I've stuck a small 5V fan on my board just so I don't fry the chip while I do more tests. So far I can take it to 360MHz using the onboard regulators or 371MHz by hooking in a 2V supply. At 371MHz the 2V supply is definitely around 1.2A or so. I wrote a loop just to step the clock up each iteration of a fibos test. It bombed at 371Mhz but the 2V supply is via a few inches of lead and the supply is set to 2A limit as I don't really want anything to smoke. Perhaps with shorter leads it might perform better.
    380 300 DO I @MHZ  46 .fibo LOOP CRUISE
    
    fibo(46) = 3,305 cycles = 9,180ns @360MHz result =1836311903
    fibo(46) = 3,305 cycles = 9,155ns @361MHz result =1836311903
    fibo(46) = 3,305 cycles = 9,129ns @362MHz result =1836311903
    fibo(46) = 3,305 cycles = 9,104ns @363MHz result =1836311903
    fibo(46) = 3,305 cycles = 9,079ns @364MHz result =1836311903
    fibo(46) = 3,305 cycles = 9,054ns @365MHz result =1836311903
    fibo(46) = 3,305 cycles = 9,030ns @366MHz result =1836311903
    fibo(46) = 3,305 cycles = 9,005ns @367MHz result =1836311903
    fibo(46) = 3,305 cycles = 8,980ns @368MHz result =1836311903
    fibo(46) = 3,305 cycles = 8,956ns @369MHz result =1836311903
    fibo(46) = 3,305 cycles = 8,932ns @370MHz result =1836311903
    fibo(46) = 3,305 cycles = 8,908ns @371MHz result =1836311903
    fibo(46) = 3,305 cycles = 8,884
    
  • cgraceycgracey Posts: 13,631
    Awesome, Peter!!!

    Does it run indefinitely this way?
  • ErNaErNa Posts: 1,672
    wouldn't it be sufficient as it runs as long as it took to run?
  • cgraceycgracey Posts: 13,631
    ErNa wrote: »
    wouldn't it be sufficient as it runs as long as it took to run?

    No. By maximizing power on a continuous basis, the P2 can do its part to combat global cooling.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-10-09 15:45
    cgracey wrote: »
    Awesome, Peter!!!

    Does it run indefinitely this way?

    My only chip that I'm already taking chances with :)
    I've got it off the 2V supply now and just running with on-board regulators while leaving the fan connected I can run sustained 355MHz but the fan slows down since it's powered from the USB serial cable.
    TAQOZ# lsio 
    P:00000000001111111111222222222233333333334444444444555555555566
    P:01234567890123456789012345678901234567890123456789012345678901
    =:ddd~d~~~~~~ddd~ddd~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~h~h ok
    TAQOZ#   ok
    TAQOZ# 46 .fibo 
    fibo(46) = 3,305 cycles = 9,309ns @355MHz result =1836311903 ok
    TAQOZ# .SF $EF40_1400 $270B_7025_$E666_5893 ok
    TAQOZ#   ok
    TAQOZ# 0 $40 SF DUMP 
    00000: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................'
    00010: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................'
    00020: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................'
    00030: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................' ok
    

    EDIT: 350MHz sustained with all 8 cogs running Tachyon. So that's a regulator limitation. It gets snarly when run close to its limits but I'm really impressed with this little integrated switcher that's much smaller than the SOT-89 LDOs that it sits next to.
  • evanhevanh Posts: 12,022
    edited 2018-10-09 15:48
    [doh!] Just read your edit Peter.

    What can it do with external supply providing 1.8 volts?
Sign In or Register to comment.