New P2 Silicon Observations

11719212223

Comments

  • I couldn't read the current with my meter but it looks like it is less than 100na although I should be able to use a very high resistance pulldown to work out what the current is. but that might need a 100M resistor!

    This is a quick test in TAQOZ showing the pin going high a little while after I float it:
    TAQOZ# 32 LOW 32 FLOAT BEGIN 32 PIN@ 1 AND . KEY UNTIL 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    0000000000000000000000000000000000000000000000000000000000000000000000001010101111111111111111111111111111111111111111111111111111111111111111111
    1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
    1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
    111111111111111111111111111111111111111111111111111111111111111111111111
    

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • I couldn't read the current with my meter but it looks like it is less than 100na although I should be able to use a very high resistance pulldown to work out what the current is. but that might need a 100M resistor!

    This is a quick test in TAQOZ showing the pin going high a little while after I float it:
    TAQOZ# 32 LOW 32 FLOAT BEGIN 32 PIN@ 1 AND . KEY UNTIL 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    0000000000000000000000000000000000000000000000000000000000000000000000001010101111111111111111111111111111111111111111111111111111111111111111111
    1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
    1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
    111111111111111111111111111111111111111111111111111111111111111111111111
    

    Well, that's not a bad thing. It means that the input inverter won't be biased around the midpoint, causing current draw.
  • cgracey wrote: »
    jmg wrote: »
    cgracey wrote: »
    Then there must be some slight leakage to VIO, probably in the nano amp range.

    Does the boot loader exit with a light pullup as default on all pins, or do all pins float ?

    The pins are floating.

    Is that a good idea ?
    It means floating during the whole boot time, so any critical pins will need PCB resistors added to define their states, something users might find out rather late in the design flow...
    Maybe there is no way around this, if the pins float during RESET and reset exit ?
    Reports seem to be P2 pins 'float' lightly high, but very lightly.... May just be all the VIO traces nearby ?
  • cgraceycgracey Posts: 10,173
    edited November 6 Vote Up0Vote Down
    The pins all float during reset and then until they are configured to drive.

    It seems to me that pulling either high or low during that time is making some possibly unwelcome assumptions about what people are doing with the chip.

    There must be some very slight leakage in either the P clamp diodes or the PFET drivers.
  • I'll have a go at measuring that leakage and report back
  • Some interesting results with the pins when tri-state...

    Using OUTA and DIRA with the streamer reading the pins (testing P8-15 on P2D2)

    Before setting the pins, the streamer reads all pins as all 1's
    When OUTA sets all 0's before tri-stating with DIRA, the streamer reads the pins as all 0's.
    When OUTA sets all 1's before tri-stating with DIRA, the streamer reads the pins variously (often $43 or $47)

    From reset,
    DRVL pins 7 & 6 & 5, the streamer reads pins 7 & 6 & 5 as 0's AND 4 as 0 too. But pin 4 does not drive an LED attached, so it is effectively tri-state.

    From this, I would say floating pins read as undefined, unlike the P1 where we can reliably say they read 0.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Some interesting results with the pins when tri-state...

    Using OUTA and DIRA with the streamer reading the pins (testing P8-15 on P2D2)

    Before setting the pins, the streamer reads all pins as all 1's
    When OUTA sets all 0's before tri-stating with DIRA, the streamer reads the pins as all 0's.
    When OUTA sets all 1's before tri-stating with DIRA, the streamer reads the pins variously (often $43 or $47)

    From reset,
    DRVL pins 7 & 6 & 5, the streamer reads pins 7 & 6 & 5 as 0's AND 4 as 0 too. But pin 4 does not drive an LED attached, so it is effectively tri-state.

    From this, I would say floating pins read as undefined, unlike the P1 where we can reliably say they read 0.

    When you tristate all those pins, OUT goes low before DIR in many cases, causing the pins to variously drive downward before floating. This is the problem we've been having with the boot pins. Given time, those pins may blow in the electrical field breeze or settle low or high. From what some have said, pins seems to float high over time.
  • Some more results...

    With 10K pullup on pin 30...

    DRVL
    WAITX 1us
    FLTL or FLTH

    At 20MHz, pin 30 pulls high within 1-2 clocks
    At 200MHz, pin 30 takes an extra 15 clocks, so ~75ns to be pulled high

    With 10K pulldown on pin 30...

    DRVH
    WAITX 1us
    FLTL or FLTH

    At 20MHz, pin 30 pulls low within 2-3 clocks
    At 200MHz, pin 30 takes an extra 17 clocks, so ~85ns to be pulled low

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • evanhevanh Posts: 5,664
    edited November 8 Vote Up0Vote Down
    Cluso,
    Try some other pins. Due to the glitching, you should get faster pull-downs, combined with slower pull-ups, on some.

    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • MODCZ Instruction(s)

    Not the silicon, but pnut compiler.

    In the short form
    MODCZ/MODZ _SET/_CLR {WC/WZ/WCZ}
    I see the WC/WZ is still required. Seemed to me that this is implied by the short form instruction and that the WC/WM modifier should not be required.

    Perhaps an ever shorter form might be better
    MODZSET, MODZCLR, MODCSET, MODCCLR ?
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • I made it so that you can always scan the outer right column and find the WC/WZ/WCZ effects to know quickly where the flags are being affected. The only exceptions are the return/resume-from-interrupt instructions.
  • Cluso99Cluso99 Posts: 14,165
    edited November 11 Vote Up0Vote Down
    Ok. Makes sense, but imho an error should report missing WC/WZ.
    But that's for another day ;)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Ok. Makes sense, but imho an error should report missing WC/WZ.
    But that's for another day ;)

    I agree.
  • Chip,
    What do you think is the best way to replace the P1 REV instruction?
    I am thinking in an automated conversion program where you don't know it's usage.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Chip,
    What do you think is the best way to replace the P1 REV instruction?
    I am thinking in an automated conversion program where you don't know it's usage.

    You need to do a SHL+REV or a REV+SHR.
  • Cluso99Cluso99 Posts: 14,165
    edited November 11 Vote Up0Vote Down
    Thanks Chip. I kept overthinking the S value in P1 as needing to be subtracted from 32 :(

    CALLD INx,IRETx
    I have been thinking about the way interrupts work and other uses of the calls.

    What was interesting is the use of INA/INB as write only (shadow) registers. Got me thinking...
    Wouldn't the RETIx/RESIx instructions corrupt INA/INB when they are use as the Debug Registers ???
    I am presuming that the write to INA/INB actually takes place when the RETIx/RESIix instructions (which are CALLD INB,IRETx instructions?

    Tricks
    So my trick that I expect will work is this...
    For normal instructions that in reality work on a single operand, such as NEG, MOV, etc, can simulate the "NR" feature of the P1 and set Z & C flags.
    The caveat is you cannot be using Debug Interrupts in this cog.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Wouldn't the RETIx/RESIx instructions corrupt INA/INB when they are use as the Debug Registers ???
    I am presuming that the write to INA/INB actually takes place when the RETIx/RESIix instructions (which are CALLD INB,IRETx instructions?
    During debug INA/INB become debug status registers.
    The pin states can be switched in/out during interrupt using SETBRK

    %G: 1 = make INA/INB read pin states, not RAM

    Melbourne, Australia
  • Your original torture code, is that SPIN1 or SPIN2?
  • Ran some frequency tests across 2 boards, temperature points -40C and 25C

    12-Nov-18
    P2 OSC FREQ CHECKS AT DIFFERENT TEMPERATURES
    34461A meter in freq mode, 10V range, >20Hz AC filter, 100ms gate time
    /1000 P2 CODE (ie MHz becomes kHz,

    BOARD# OSC FREQ AT -40C FREQ AT 25 C
    1 RCSLOW 26700 20460
    2 RCSLOW 26600 20555
    1 RCFAST 23281000 23650000
    2 RCFAST 23193000 23600000
  • Tubular wrote: »
    Ran some frequency tests across 2 boards, temperature points -40C and 25C

    12-Nov-18
    P2 OSC FREQ CHECKS AT DIFFERENT TEMPERATURES
    34461A meter in freq mode, 10V range, >20Hz AC filter, 100ms gate time
    /1000 P2 CODE (ie MHz becomes kHz,

    BOARD# OSC FREQ AT -40C FREQ AT 25 C
    1 RCSLOW 26700 20460
    2 RCSLOW 26600 20555
    1 RCFAST 23281000 23650000
    2 RCFAST 23193000 23600000

    I make that

    SLOW tempco :
    ((26700/20460)-1)/(25+40) = -30.49% = -0.469 %/°C
    ((26600/20555)-1)/(25+40) = -29.41% = -0.452 %/°C

    FAST tempco :
    (1-23281000/ 23650000)/(25+40) = 1.560% = +240 ppm /°C
    (1-23193000/23600000)/(25+40) = 1.724% = +265 ppm /°C

    Sample to sample variation
    FAST: 1-(23281000/23193000) = 0.379% Cold 1-23650000/23600000 = 0.212% Room temp
    SLOW: 1-26700/26600 = 0.376% cold 1-20460/20555 = 0.462% Room temp

    Not a large sample set, but looking quite good overall there.
  • Here's some captures of some ADC bitstreams.
    You can see the sequential configuration of the pin mode.
    Three captures showing GIO,VIO and PinA 1x mode.

    One thing I observed is as each ADC was enabled the current rises ~800uA @ 80 Mhz and ~1.2mA per pin @ 250 MHz. I will collect more data on this.
    800 x 600 - 143K
    800 x 600 - 142K
    800 x 600 - 144K
    Melbourne, Australia
  • Chop

    Here's the code snippet to set 16 pins to ADc mode.
    		mov	pin,#base_pin
    .loop		wrpin	##%100011_0000000_00_00000_0,pin	'ADC,PinA 1x
    		incmod	pin,#base_pin+15 wz
    	if_nz	jmp	#.loop
    
    Is there a reason why the bitstream time to start from config varies as shown in this capture.
    800 x 600 - 141K
    Melbourne, Australia
  • cgraceycgracey Posts: 10,173
    edited November 13 Vote Up0Vote Down
    That has to do with the initial integrator voltage. It can be kind of random, and if it's off from threshold a ways, it could take a while to balance.

    That routine you've got there will become one or two instructions in the next rev of the silicon.
  • cgracey wrote: »
    That has to do with the initial integrator voltage. It can be kind of random, and if it's off from threshold a ways, it could take a while to balance.

    That routine you've got there will become one or two instructions in the next rev of the silicon.

    Ok + Cool :)
    Melbourne, Australia
  • TubularTubular Posts: 3,252
    edited November 13 Vote Up0Vote Down
    I'm not sure what I'm more excited about seeing; the bitstreams, or the tool that views them at 1 horizontal pixel per clock.

    Great to have your P2 based logic analyzer working again
  • cgraceycgracey Posts: 10,173
    edited November 13 Vote Up0Vote Down
    Tubular wrote: »
    I'm not sure what I'm more excited about seeing; the bitstreams, or the tool that views them at 1 horizontal pixel per clock.

    Great to have your P2 based logic analyzer working again

    Yes, that is super useful.

    I've been thinking about a logic-analyzer mode for the streamer that will only write on changes and store 16 pins with a 16-bit timestamp. If it times out at 2^16 clocks, it issues the same data with $0000 for time. If no changes were occurring, it would write one long every 2^16 clocks. At 250MHz, that's only 15KB per second.
  • That sounds really useful. If you had glitches/debounce issues, it'd still capture them
  • At the present construction, is it imperative for the write pointer to keep advancing, even in cases were input data persists, sample after sample?

    Because, if captured data persists, its value keeps the same as the last captured value, when the last change was observed.

    This could free the sampling bits to further expand the "no new activity being perceived" counter, further reducing memory bandwidht needs.

    Only a thought...
  • Brian,
    Can you post your latest logic analyzer code? I am eager totry it out :)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • cgraceycgracey Posts: 10,173
    edited November 13 Vote Up0Vote Down
    Yanomani wrote: »
    At the present construction, is it imperative for the write pointer to keep advancing, even in cases were input data persists, sample after sample?

    Because, if captured data persists, its value keeps the same as the last captured value, when the last change was observed.

    This could free the sampling bits to further expand the "no new activity being perceived" counter, further reducing memory bandwidht needs.

    Only a thought...

    Yes!!! We could use the LSB of the time to indicate 'no change', in which case the timestamp is 31 bits. So, it would only take one long every 8.59 seconds. That could get pretty boring.
Sign In or Register to comment.