Shop OBEX P1 Docs P2 Docs Learn Events
New P2 Silicon - Page 25 — Parallax Forums

New P2 Silicon

1222325272832

Comments

  • evanhevanh Posts: 15,126
    David Betz wrote: »
    Are there any differences between B and C other than the pin coupling fix?
    No, that one alone was a much cheaper fix than any of the others.

  • cgracey wrote: »
    The new P2 silicon seems fine.

    To celebrate, Ken has put the P2-ES Eval Rev B boards and the P2-ES Rev B 4-packs on sale:......
    Does that mean that the “One Eval Board per customer” restriction has been rescinded?

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    ke4pjw wrote: »
    Were the pads reworked to resolve the latchup "problem"? I can't recall. Problem in quotes because latchup only occurs well above spec.

    Will Rev. C Eval boards be available? Hoping to have a full collection :)

    We did not put the guard rings around certain n-wells because it would have been a very expensive all-layer change. We're just going to rate the part for 4.0V, absolute max.

    I did not see injection current levels specified for latchup ? - Just a lowering of the Abs Max Vcc value ?
    Other vendors spec their MCUs like this
    VHBM[*1]      Electrostatic discharge,human body mode      -8000 - +8000 V
    VCDM[*2]      Electrostatic discharge,charge device model  -1000 - +1000 
    LU[*3]        Pin current for latch-up[*3]                 -400  - +400 mA
    VEFT[*4] [*5] Fast transient voltage burst                 -4.4  - +4.4 kV
    
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    The new P2 silicon seems fine.

    How much process variation are you seeing in a new batch ?

    are leakage, mA/MHz and maximum SysCLK significantly different, or ~exactly the same ?

  • doggiedoc wrote: »
    cgracey wrote: »
    The new P2 silicon seems fine.

    To celebrate, Ken has put the P2-ES Eval Rev B boards and the P2-ES Rev B 4-packs on sale:......
    Does that mean that the “One Eval Board per customer” restriction has been rescinded?

    Yes, both those restrictions have been lifted for around a month
  • doggiedoc wrote: »
    cgracey wrote: »
    The new P2 silicon seems fine.

    To celebrate, Ken has put the P2-ES Eval Rev B boards and the P2-ES Rev B 4-packs on sale:......
    Does that mean that the “One Eval Board per customer” restriction has been rescinded?

    Yes, please buy what you'd like! Multiple boards per customer are now allowed since we've been able to put at least one in the hands of each interested developer [who expressed interest in the P2].

    Ken Gracey
  • Cluso99Cluso99 Posts: 18,066
    evanh wrote: »
    David Betz wrote: »
    ke4pjw wrote: »
    Will Rev. C Eval boards be available? Hoping to have a full collection :)
    If you're really going to have a full collection you'll have to get someone to sell you one of the ultra rare glob top boards.
    There was both revA and revB editions of those. I have a revB. I don't think Chip gave out any of the revA glob-tops.
    IIRC there were only 10 glob top Rev A chips. One got drilled/destroyed by Chip during assembly of the first board(s) :(
    I think they were only built on Peter's P2D2 Rev1 boards, not the P2-EVAL boards which were not done at the time.

    Peter J and I have RevA glob tops because we needed to verify our ROM code. I think one may have gone to the Melbourne guys.
    Peter may have put a couple on the first P2D2's he built??

    So, out of 10, 1 destroyed, 1 each to Chip, Peter, myself, and melbourne. So 5 whereabouts unknown.

    BTW I won't be selling mine.

    FWIW there were ~120 Rev A with production packaging.
  • Cluso99 wrote: »
    So, out of 10, 1 destroyed, 1 each to Chip, Peter, myself, and melbourne. So 5 whereabouts unknown.

    Two ended up down here, and sadly the good smoke escaped out of both of them. :(
    The cause was a nasty firmware bug in a bench top supply that changed ranges from 5V to 36V.


  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    The new P2 silicon seems fine.

    How much process variation are you seeing in a new batch ?

    are leakage, mA/MHz and maximum SysCLK significantly different, or ~exactly the same ?

    Well, we've got TWO P2 Eval boards with Rev C silicon on them. That's it, at this point. I haven't done any measuring.
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    ke4pjw wrote: »
    Were the pads reworked to resolve the latchup "problem"? I can't recall. Problem in quotes because latchup only occurs well above spec.

    Will Rev. C Eval boards be available? Hoping to have a full collection :)

    We did not put the guard rings around certain n-wells because it would have been a very expensive all-layer change. We're just going to rate the part for 4.0V, absolute max.

    I did not see injection current levels specified for latchup ? - Just a lowering of the Abs Max Vcc value ?
    Other vendors spec their MCUs like this
    VHBM[*1]      Electrostatic discharge,human body mode      -8000 - +8000 V
    VCDM[*2]      Electrostatic discharge,charge device model  -1000 - +1000 
    LU[*3]        Pin current for latch-up[*3]                 -400  - +400 mA
    VEFT[*4] [*5] Fast transient voltage burst                 -4.4  - +4.4 kV
    

    ON ran their standard latch-up test and the P2 passed. Let me see if I can find the results...

    LatchUpTest.png
    704 x 117 - 30K
  • cgraceycgracey Posts: 14,133
    And here are the ESD test results:

    ESDTest.png
    659 x 205 - 45K
  • Any new info for Rev. C?



    Bill M.
  • cgraceycgracey Posts: 14,133
    Any new info for Rev. C?



    Bill M.

    It's all the same. Just a resistor within the ADC mux was disconnected to stop noise coupling.
  • evanhevanh Posts: 15,126
    edited 2020-03-12 05:52
    There'll be one or two B-pin selections within the WRPIN "P" field bits that no longer work.

    EDIT: Maybe just the ADC ... P=%100_010_xxxxxxx

  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    There'll be one or two B-pin selections within the WRPIN "P" field bits that no longer work.

    EDIT: Maybe just the ADC ... P=%100_010_xxxxxxx

    Right. Now, if you select that mode, you can measure the zero-bias point of the ADC, which is potentially useful for measuring very small currents.
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2020-03-12 08:51
    @cgracey,
    in the docs for the wrpin mode TT bits it says this:
    for all smart pin modes (%MMMMM > %00000):
                 x0 = output disabled, regardless of DIR
                 x1 = output enabled, regardless of DIR
    
    In my testing with pwm_triangle and pwm_sawtooth modes, I found that the output would be driven once I raised DIR even if TT = 00.
    Either I don't understand something, or the docs are not complete/correct.


    I was thrown off by the extra 0 in the bottom bit. /sigh sorry.
  • evanhevanh Posts: 15,126
    Working as per the docs for me. I'd say you've got something interfering.

  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2020-03-12 08:53
    Nevermind, I was wrong. I need to stop doing this kind of stuff late at night when I am tired.
  • evanhevanh Posts: 15,126
    Cool, I couldn't compile your example anyway. My Fastspin was out of date for C support and when updated it couldn't find a certain libc/unix/bufio.c file. I'm guessing the spin2cpp master tree is in limbo, atm. I'll probably have to build it from the FlexGUI master sources instead.

  • evanhevanh Posts: 15,126
    Roy Eltham wrote: »
    I was thrown off by the extra 0 in the bottom bit. /sigh sorry.
    Here's a collection of some constants I include with every program now
    
    
    ' Pin modes
    '   ***********************************************************
    '   ***** PIN MODES INCOMPLETE ***** ONLY HAS WHAT I USED *****
    '   ***********************************************************
    	P_REGD		= (%1 << 16)		' turn on clocked digital I/O (registered pins)
    	P_IINV		= (%1 << 15)		' invert digital input
    	P_OINV		= (%1 << 14)		' invert digital output
    	P_NFB		= (%0001 << 17)		' negative feedback, in -> not out
    
    	P_FLOAT		= (%111111 << 8)	' float digital output
    	P_1K5R		= (%001001 << 8)	' 1.5 kiloOhm digital output
    	P_15KR		= (%010010 << 8)	' 15 kiloOhm digital output
    	P_1mA		= (%100100 << 8)	' 1 milliAmp digital output
    
    	P_COGDAC	= (%01 << 6)		' select a cog/streamer for DAC level, smartpin must be off
    	P_BITDAC	= (%10 << 6)		' preset for DAC level (split in revB), smartpin off (default for smartpins when DACMODE)
    
    	PM_DAC		= (%101 << 18)		' DAC output (with optional ADC input), preset level
    	PM_DAC_990	= PM_DAC |(%00 << 16)	' 990 Ohm, 3.3 Volt range
    	PM_DAC_124	= PM_DAC |(%10 << 16)	' 124 Ohm, 3.3 Volt range
    	PM_DAC_600	= PM_DAC |(%01 << 16)	' 600 Ohm, 2.0 Volt range
    	PM_DAC_75	= PM_DAC |(%11 << 16)	' 75 Ohm, 2.0 Volt range
    
    	PM_COMPDAC	= (%1100 << 17)		' Analogue comparator with DAC as preset reference
    
    	PM_ADC		= (%100 << 18)		' turn on custom pin ADC input
    	PM_ADC_GIO	= PM_ADC | (%000 << 15)
    	PM_ADC_VIO	= PM_ADC | (%001 << 15)
    	PM_ADC_B1	= PM_ADC | (%010 << 15)
    	PM_ADC_A1	= PM_ADC | (%011 << 15)
    	PM_ADC_A3	= PM_ADC | (%100 << 15)
    	PM_ADC_A10	= PM_ADC | (%101 << 15)
    	PM_ADC_A30	= PM_ADC | (%110 << 15)
    	PM_ADC_A100	= PM_ADC | (%111 << 15)
    
    
    	AF_PLUS1	= (%0001 << 28)
    	AF_PLUS2	= (%0010 << 28)
    	AF_PLUS3	= (%0011 << 28)
    	AF_MINUS1	= (%0111 << 28)
    	AF_MINUS2	= (%0110 << 28)
    	AF_MINUS3	= (%0101 << 28)
    	AF_OUT		= (%0100 << 28)
    	AF_NOT		= (%1000 << 28)
    	AF_PLUS1NOT	= (%1001 << 28)
    	AF_PLUS2NOT	= (%1010 << 28)
    	AF_PLUS3NOT	= (%1011 << 28)
    	AF_MINUS1NOT	= (%1111 << 28)
    	AF_MINUS2NOT	= (%1110 << 28)
    	AF_MINUS3NOT	= (%1101 << 28)
    	AF_OUTNOT	= (%1100 << 28)
    
    	BF_PLUS1	= (%0001 << 24)
    	BF_PLUS2	= (%0010 << 24)
    	BF_PLUS3	= (%0011 << 24)
    	BF_MINUS1	= (%0111 << 24)
    	BF_MINUS2	= (%0110 << 24)
    	BF_MINUS3	= (%0101 << 24)
    	BF_OUT		= (%0100 << 24)
    	BF_NOT		= (%1000 << 24)
    	BF_PLUS1NOT	= (%1001 << 24)
    	BF_PLUS2NOT	= (%1010 << 24)
    	BF_PLUS3NOT	= (%1011 << 24)
    	BF_MINUS1NOT	= (%1111 << 24)
    	BF_MINUS2NOT	= (%1110 << 24)
    	BF_MINUS3NOT	= (%1101 << 24)
    	BF_OUTNOT	= (%1100 << 24)
    
    
    ' Smartpin modes
    	SP_OUT		= (%1 << 6)		' enable digital output when DIR operates smartpin
    
    	SPM_OFF		= 0				' smart pin off (default)
    	SPM_REPOSITORY	= %00001_0			' long repository (P[12:10] != %101)
    
    	SPM_DAC_RANDOM	= %00001_0 |SP_OUT|PM_DAC	' DAC noise (P[12:10] = %101)
    	SPM_DAC_RND	= %00010_0 |SP_OUT|PM_DAC	' DAC 16-bit dither, noise (P[12:10] = %101)
    	SPM_DAC_PWM	= %00011_0 |SP_OUT|PM_DAC	' DAC 16-bit dither, PWM (P[12:10] = %101)
    
    	SPM_PULSES	= %00100_0 |SP_OUT		' pulse/cycle output
    	SPM_STEPS	= %00101_0 |SP_OUT		' transition output
    	SPM_NCO_FREQ	= %00110_0 |SP_OUT		' NCO frequency
    	SPM_NCO_DUTY	= %00111_0 |SP_OUT		' NCO duty
    	SPM_PWM_TRI	= %01000_0 |SP_OUT		' PWM triangle
    	SPM_PWM_SAW	= %01001_0 |SP_OUT		' PWM sawtooth
    	SPM_PWM_SAW_FB	= %01010_0 |SP_OUT		' PWM switch-mode power supply, V and I feedback
    
    	SPM_CNT_QUAD	= %01011_0		' count: A-B quadrature encoder
    	SPM_CNT_UP_ENA	= %01100_0		' count: A clock up, B enable
    	SPM_CNT_DIR	= %01101_0		' count: A clock, B direction
    	SPM_CNT_UP	= %01110_0		' count: (Y=%0) A clock up
    	SPM_CNT_UP_DN	= %01110_0		' count: (Y=%1) A clock up, B clock down
    	SPM_ACC_UP	= %01111_0		' accumulate: (Y=%0) A up
    	SPM_ACC_UP_DN	= %01111_0		' accumulate: (Y=%1) A up, B down
    	SPM_TIM_STEP	= %10000_0		' interval: of most recent step duration
    	SPM_TIM_PULSE	= %10001_0		' interval: of most recent pulse duration
    	SPM_TIM_MANY	= %10010_0		' interval: (Y=%0xx) of X number of accum/pulses/steps
    	SPM_TIMEOUT	= %10010_0		' interval: (Y=%1xx) since most recent high/rise/edge, with X compare
    	SPM_TIM_PULS	= %10011_0		' interval: of X number of A-B pulses/steps
    	SPM_ACC_PULS	= %10100_0		' accumulate: pulses/steps, of X number of A-B pulses/steps
    	SPM_TIM_OVER	= %10101_0		' interval: of A-B pulses/steps, for at least X duration
    	SPM_ACC_OVER	= %10110_0		' accumulate: A-B pulses/steps, for at least X duration
    	SPM_CNT_OVER	= %10111_0		' count: A-B pulses/steps, for at least X duration
    
    #ifdef PROP2_REVA
    	SPM_USB_HOSTL	= %11000_0 |SP_OUT		' USB host, low-speed (even/odd pin pair = DM/DP)
    	SPM_USB_HOSTH	= %11001_0 |SP_OUT		' USB host, high-speed (even/odd pin pair = DM/DP)
    	SPM_USB_DEVL	= %11010_0 |SP_OUT		' USB device, low-speed (even/odd pin pair = DM/DP)
    	SPM_USB_DEVH	= %11011_0 |SP_OUT		' USB device, high-speed (even/odd pin pair = DM/DP)
    #endif
    #ifdef PROP2_REVB
    	SPM_ADC_ISINC	= %11000_0			' ADC sample/filter/capture, internally clocked
    	SPM_ADC_ESINC	= %11001_0			' ADC sample/filter/capture, externally clocked
    	SPM_ADC_SCOPE	= %11010_0			' ADC scope-mode, with trigger, internally clocked
    
    	SPM_USB		= %11011_0 |SP_OUT		' USB v1.0 host or device, (even/odd pin pair = DM/DP)
    #endif
    	SPM_SSER_TX	= %11100_0 |SP_OUT		' sync serial transmit (A-data, B-clock)
    	SPM_SSER_RX	= %11101_0			' sync serial receive (A-data, B-clock)
    	SPM_ASER_TX	= %11110_0 |SP_OUT		' async serial transmit (baud)
    	SPM_ASER_RX	= %11111_0			' async serial receive (baud)
    
    	SSTX_STOP	= (%1 << 5)			' sync serial transmit first bit direct when empty (start-stop mode)
    	SSRX_LATE	= (%1 << 5)			' sync serial receiver post-clock sampling
    
    
  • evenh,
    Yeah the current spin2cpp code in github is missing the bufio.c file, I just made one with stub functions to get it to compile. I also have local changes/fixes that are waiting in pull requests for Eric's return.
    If you still have the code you can see that I was setting mode to 0x00000050 which indeed sets the TT bits to 01. I was mentally shifting it because of the unused bottom bit.
  • evanhevanh Posts: 15,126
    potatohead wrote: »
    Did we ever make a programmer's model of a COG, similar to the ones published for many other CPUs?
    Is there one even for the prop1?

  • evanhevanh Posts: 15,126
    edited 2020-04-02 02:38
    Ugh! Chip, why does BMASK have that +1 to S operand? I keep having to -1 to my parameters. And it would've been convenient for me if a value of zero meant no bits getting set.

    EDIT: Funnily, I've managed to minimise the impact. It's a good reference for future similar cases:
    '64-bit summation truncated to 32-bit with a chosen bit-shift parameter
    		bmask	pa, .gain			'setup number of high bits to shift down
    		shr	pa, #1				'compensate for BMASK's offset
    		setq	pa
    		muxq	.firval, .firval2		'move high bits
    		ror	.firval, .gain			'rotate them to high bit positions
    
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Ugh! Chip, why does BMASK have that +1 to S operand? I keep having to -1 to my parameters. And it would've been convenient for me if a value of zero meant no bits getting set.

    EDIT: Funnily, I've managed to minimise the impact. It's a good reference for future similar cases:
    '64-bit summation truncated to 32-bit with a chosen bit-shift parameter
    		bmask	pa, .gain			'setup number of high bits to shift down
    		shr	pa, #1				'compensate for BMASK's offset
    		setq	pa
    		muxq	.firval, .firval2		'move high bits
    		ror	.firval, .gain			'rotate them to high bit positions
    

    It just does what the same PASM instruction does. I could make it like you want, but I'd have to give it another name. Any ideas? BITMASK?
  • evanhevanh Posts: 15,126
    edited 2020-04-02 04:38
    Ah, I am talking about pasm/machine code. Just seems the wrong way to me is all. No biggie, applying the post-op shifting compensation is a short simple fix which also provides the null I was after too.
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Ah, I am talking about pasm/machine code. Just seems the wrong way to me is all. No biggie, applying the post-op shifting compensation is a short simple fix which also provides the null I was after too.

    All the instructions which deal with bits have been harmonized to use S[4:0] or D[4:0] as the bit chooser to avoid ambiguity that would have come from incorporating higher bits in the process.
  • evanhevanh Posts: 15,126
    edited 2020-04-02 07:52
    Right, I did notice the commonality. In hindsight, making them all with S=0 producing a null effect would have been better, imho.

  • cgraceycgracey Posts: 14,133
    edited 2020-04-02 11:54
    evanh wrote: »
    Right, I did notice the commonality. In hindsight, making them all with S=0 producing a null effect would have been better, imho.

    I know, but then that would have required one more bit to accommodate the ADDPINS/ADDBITS field and rendered the 32..63 values all same. For many things, it would have just necessitated extra code to handle the edge case. There was no clear win here.
  • evanhevanh Posts: 15,126
    cgracey wrote: »
    ... that would have required one more bit to accommodate the ADDPINS/ADDBITS field ...
    Oh, that's just sunk in. Zero value is one pin. Ha, I was always thinking of that as an optional field. Yeah, I see what you mean, that effect is true for all those encoded fields, so can't have both ways.

  • evanh wrote: »
    potatohead wrote: »
    Did we ever make a programmer's model of a COG, similar to the ones published for many other CPUs?
    Is there one even for the prop1?

    I do not think so.
Sign In or Register to comment.