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.
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.
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.
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.
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 ?
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"
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.
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.
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
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.
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.
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
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.
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.
Comments
Being able to calibrate the RC osc will be more important, to those trying to lower P2 usage power.
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 ?
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.
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.
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 ?
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"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.
No. The currents are set by a resistor/MOS combo. It's not super accurate, but in the ballpark.
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.
Stable 300MHz is amazing. Good stuff.
Cool, some under-clocking numbers too
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 ?
12.5MHz works okay. That's not even 4x colorburst.
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.
So 300MHz was just showing off ?
27MHz seems to be a common clock for composite chips ?
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.
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.
With a little freeze spray (4'C to 8'C reading) that climbed to 22.8kHz
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.
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.
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 ?)
Does it run indefinitely this way?
No. By maximizing power on a continuous basis, the P2 can do its part to combat global cooling.
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.
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.
What can it do with external supply providing 1.8 volts?