Shop OBEX P1 Docs P2 Docs Learn Events
Full-chip integration at On Semi - Page 13 — Parallax Forums

Full-chip integration at On Semi

1910111315

Comments

  • WBA ConsultingWBA Consulting Posts: 2,933
    edited 2018-05-10 16:43
    In my opinion, poor QFN sales are directly related to the fact that the Propeller is not really designed for low power usage, so small-sized end applications are not a mainstream market for the Propeller. As such, real estate is not a concern normally, so space savings is not a factor to drive a QFN vs QFP choice. Also, QFN packages seem to thwart the DIY/hobbyist/low volume avenues for the Propeller so they just aren't chosen. QFPs are much easier to rework with a standard soldering iron. On the flip side, because I have appropriate equipment, all of the Propeller based products I have designed have used the QFN package.

    evanh: I will agree in non-commercial usage (for example toaster oven reflow), BGA and QFN packages do have issues in the field, but from a professional manufacturing environment, BGA and QFN packages are very reliable.

    My impression from the current P2 discussions is that users desire the QFP and 2 layer boards for any use of the P2. That's a good start, but I would hope Parallax has bigger dreams for the P2.
  • cgraceycgracey Posts: 14,131
    edited 2018-05-10 21:07
    After going back and forth with OnSemi, I made new markings like Peter's, but without the "P2" being italicized, since I think it looks fuller without the slant. On the part number, I got rid of the "-" and used an "X" to make it more searchable.

    marking_visual.png

    2204 x 1942 - 210K
    1400 x 1400 - 36K
    1400 x 1400 - 34K
  • jmgjmg Posts: 15,140
    Many vendors build the die revision into the part code , and most user a Letter.
    I've just seen one click up to Rev 'G', but that wont be P2, right ? ;)
  • ±
    jmg wrote: »
    Many vendors build the die revision into the part code , and most user a Letter.
    I've just seen one click up to Rev 'G', but that wont be P2, right ? ;)

    Where have you been??? We're already at Rev 'Z'! ;)
  • jmgjmg Posts: 15,140
    Seairth wrote: »
    ±
    jmg wrote: »
    Many vendors build the die revision into the part code , and most user a Letter.
    I've just seen one click up to Rev 'G', but that wont be P2, right ? ;)

    Where have you been??? We're already at Rev 'Z'! ;)

    Hehe, well yes.... ;) but I was meaning actual silicon mask revisions, not FPGA revisions, or build numbers ?
    (Does Chip even keep a build counter ? )
  • That looks nice to me.
  • Thats great, Chip. Hit send...
  • Looks great Chip.
    Looking forward to getting my first tracking number verifying "P2's on route!" :cool:
  • cgracey wrote: »
    After going back and forth with OnSemi, I made new markings like Peter's, but without the "P2" being italicized, since I think it looks fuller without the slant. On the part number, I got rid of the "-" and used an "X" to make it more searchable.

    marking_visual.png

    A few thoughts:

    1. It would be much better with the OnSemi "AWLYYWWW CCCCC" on a single line and their dummy text would fit at the size shown.

    2. The big "P2" looks too squashed vertically and (1) would allow room for it be taller.

    3. There is very little gap between characters in "P2X8C4M64P" and if a tiny bit smaller they could fit in the same width but be more legible.



  • cgraceycgracey Posts: 14,131
    edited 2018-05-11 01:08
    TonyB_, I agree. It is OnSemi's policy to have TWO lines for their own markings. No getting around this. It doesn't even seem worth asking them if they could, at least, center justify those lines.
  • I detected Chip's hint about liking the non-italicized "P2" marking a few days back, but nobody took the bait and encouraged him to go with it (partly since a couple had stated a preference for the italicized version). But good on you, Chip, for going with your gut (even if your gut feeling changes). Both versions are good: one fills space better to stand out that way, the other uses an edgy slant to stand out. There's no right or wrong as such. Anyway, seeing the artwork on a package diagram has got to be a good sign with respect to progress.
  • I detected Chip's hint about liking the non-italicized "P2" marking a few days back, but nobody took the bait and encouraged him to go with it (partly since a couple had stated a preference for the italicized version). But good on you, Chip, for going with your gut (even if your gut feeling changes). Both versions are good: one fills space better to stand out that way, the other uses an edgy slant to stand out. There's no right or wrong as such. Anyway, seeing the artwork on a package diagram has got to be a good sign with respect to progress.

    I prefer italicized but I'm easy going as long as it makes some sense, which it does. We have a good and meaningful part number, a bold P2 with matching font, and Parallax Inc. This is Chip's chip and with the support of forumistas it is something to be really really proud of, a thing we would call being "chuffed", like a proud happy father.

    Now, I am going to do up some "P2 Inside" stickers as well as finish off some pcb designs, but not before I test and finish the ROM.

  • Finishing the rom sounds promising. Is cluso close? Happy to hook up some boot devices and do some testing once we get to that point
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-11 08:15
    Tubular wrote: »
    Finishing the rom sounds promising. Is cluso close? Happy to hook up some boot devices and do some testing once we get to that point

    Thanks Lachlan.

    To test you will need to put...

    A SPI Flash part on P61-58 as CS, CLK, MOSI, MISO with a pullup on CS - make the pullup linkable

    An SD card on P61-58 as CLK, CS, MOSI, MISO (no pullups)

    Both Flash and SD can be combined

    P58 & P59 may also have pullups for other options (more later) - make these pullups linkable

    Standby as Chip said OnSemi require the code Monday!!!

    Forgot to answer. Yes, TAQOZ, SD and Monitor are all working nicely sandboxed.

    We are still doing tweeks (saving a few longs here and there, nothing risky)
  • cgraceycgracey Posts: 14,131
    edited 2018-05-11 09:16
    Cluso and Peter,

    I'm going through my ROM_Booter code, separating SPI_DI and SPI_DO.

    I've got a check in place for a pull-up on SPI_CK (also SD_CS) which will branch to Cluso's SD code.

    My pinout is as follows:
    P61 =	SPI_CS	SD_CK
    P60 =	SPI_CK	SD_CS
    P59 =	SPI_DI	SD_DI
    P58 =	SPI_DO 	SD_DO
    
    If pull-up on P60
        branch to SD booter
    
    If pull-up on P61
        attempt to load from SPI
        if SPI data okay
            if pull-up on P59
                immediately run SPI code
            allow 100ms serial window before running SPI code
    
    allow 60s serial window
    

    If a certain character sequence is received during the serial window, a branch to TAQOZ occurs.

    Does this sound okay Cluso and Peter?
  • Cluso99Cluso99 Posts: 18,066
    Pinouts correct but please don't put the SD card on the pins with verilog. We need to connect our own hardware.

    Here is the code section we have been working towards for the pullup tests..
    { BOOT SEQUENCE
          SERIAL
        +----------------
    P63 |   RX                                     else = 4th boot SERIAL
    P62 |   TX             ASSERT TXD PU ??????
    
           FLASH    SD
         +---------------
    P61  |  CSn     CLK            spi_cs | sd_ck    pu = 4th boot FLASH (APP) (no pd)
    P60  |  CLK     CSn            spi_ck | sd_cs    pu = 3rd boot SD (no pd)
    P59  |  DI      DI     MOSI    spi_dq | sd_di    pu = 2nd boot SERIAL
    						NOTE: could use pd here to disable serial & TAQOZ for security conscious product
    P58  |  DO      DO     MISO    spi_do | sd_do    pu = 1st boot FLASH (TEST)
    }
    
    ' WARNING: The following code does not set c & z correctly to go to #main !!!
    
                    callpa  #spi_do,#check_pullup   'spi_dq pull-up?  load from FLASH (ROM)     <<<<<<<<<<<<<<<<<<<<<<<<<< peter to do !!!!
            if_c    jmp     #FLASHROM
    		callpa	#spi_dq,#check_pullup
    	if_c	jmp	#\try_serial		' Force serial'
                    callpa  #spi_ck,#check_pullup   'spi_ck pull-up?  load from SDcard
            if_c    jmp     #@_SDcard_boot          'y:               (hubexec)
                    callpa  #spi_cs,#check_pullup   'spi_cs pull-up?  load from FLASH (APP)
            if_c    jmp     #\try_flash             'y:
    .doserial       cmp     x,x              wc     ' c=0
                    jmp     #\try_serial            '                 load from SERIAL
    
    FLASHROM
    		rdlong	x,#bootflg                                                         '<<<<<<<<<<<<<<<<<< peter to complete
    		mov	y,#romsig
    		cmp	x,y wz
    		wrlong	y,#bootflg
    	if_z	jmp     #\try_serial  				' skip - already loaded ROM from Flash '
    
    '+-----------------------------------------------------------------------------+
    '+      FLASH: Load from SPI memory, if present (c=1)                          +
    '+-----------------------------------------------------------------------------+
    try_flash       drvh    #spi_cs                 'make spi_cs high (pbj)
                    '''dirh    #spi_cs                 'make spi_cs output                  <<<<<<<<<<<<<<<<<<<<<<<<<< chip to verify happy to do this
                    drvl    #spi_ck                 'make spi_ck output
    
                    neg     pb,#1                   'set command bits to all 1's
                    callpa  #2,#spi_cmd             'send exit-quad command
                    callpa  #8,#spi_cmd             'send exit-quad command
                    callpa  #16,#spi_cmd            'send exit-dual command
    
                    callpb  #$66,#spi_cmd8          'send reset-enable command
                    callpb  #$99,#spi_cmd8          'send reset command
                    waitx   ##rc_max/20_000         'wait 50us
    
                    callpb  #$04,#spi_cmd8          'send write-disable command to clear WEL
    
    .wait           callpb  #$05,#spi_cmd8          'send read-status command
                    call    #spi_in                 'get status
                    testbn  x,#1            wz      'if WEL high, no SPI memory
            if_nz   jmp     #.float
                    testbn  x,#0            wz      'if BUSY high, wait for erase/write to finish
            if_nz   jmp     #.wait
    
                    mov     pa,#32                  'send read-from-start command
                    callpb  #$03,#spi_cmd
    
    		cmp	bootflg,#romsig wz	' ok to rom boot?'                      '<<<<<<<<<<<<<<<<<< peter to complete/comment
    	if_z	decod	y,#14			' read 16kB'
    	if_z	wrfast	#0,##_hubrom		' to hubrom '
            if_nz   decod   y,#10                   'ready to input $400 bytes from SPI
            if_nz   wrfast  #0,#0                   'ready to write bytes to hub
    .data           call    #spi_in                 'get byte
                    wfbyte  x                       'store byte into hub
                    djnz    y,#.data                'loop for next byte (y=0 after)
    		cmp	bootflg,#romsig wz	' ok to run rom boot?'
    	if_z	coginit	#0,##_hubrom		' just run this code '                 '<<<<<<<<<<<<<<<<<< peter to complete/comment
    
                    rdfast  #0,#0                   'ready to read longs from hub
                    rep     #2,#$100                'ready to read and sum $100 longs
                    rflong  z                       'read long
                    add     y,z                     'sum long
    
                    cmp     y,csum          wz      'verify checksum, z=1 if okay
    
            if_z    bith    flags,#spi_ok           'if program verified, set spi_ok flag
    {{
            if_z    callpa  #spi_ck,#check_pullup   'check pull-up on spi_ck, c=1 if pull-up  '<<<<<<<<<<<<<<<<<<<<<<<?????
    }}
    .float  if_nz   dirl    #spi_cs                 'if no SPI memory or program didn't verify, float SPI pins
            if_nz   dirl    #spi_ck
    .nospi
                    jmp     #main                   'jump to main program in lut, if z=c=1 then run SPI program
    

    and the checking for the autoboard sequences...
    get_command     getct   x                       'reset serial timeout in case SPI program ready
                    addct1  x,timeout_per
    
                    mov     z,#0                    'reset string buffer
    
    .byte           call    #get_rx                 'get byte
    
                    cmp     x,#_TAQOZ_     wz       'PBJ
            if_z    call    #\reset_pins            'RR    disable booter serial/autobaud/interrupts
            if_z    jmp     #@TAQOZ                 'PBJ - jump to TAQOZ (hubexec?)                    <<<<<<<<<<<<<<<<< peter to check !!!!!
                    cmp     x,#_SDcard_     wz      'RR
            if_z    call    #\reset_pins            'RR    disable booter serial/autobaud/interrupts
            if_z    jmp     #@_SDcard_boot          'RR  - jump to SD boot (hub)
                    cmp     x,#_Monitor_    wz      'RR
            if_z    call    #\reset_pins            'RR    disable booter serial/autobaud/interrupts
            if_z    jmp     #@_Start_Monitor        'RR  - jump to Monitor (hub)
    
                    rolbyte y,z,#3                  'scroll byte into 2-long/8-byte string buffer
                    rolbyte z,x,#0
    
                    cmp     y,text_prop     wz      '"Prop"?
            if_nz   jmp     #.byte
    
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-11 10:10
    And these are the constants
    CON
    _TAQOZ_   =       $1B     '<esc>  ' <esc>   goto TAQOZ
    _SDcard_  =       $02     '<stx>  ' <Ctl-B> goto SD Boot
    _Monitor_ =       $04     '<eot>  ' <Ctl-D> goto Monitor/Debug
    
    bootflg	= 0		  ' '
    romsig	= $1A5		' check sig for romboot'
    
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    My pinout is as follows:
    P61 =	SPI_CS	SD_CK
    P60 =	SPI_CK	SD_CS
    P59 =	SPI_DI	SD_DI
    P58 =	SPI_DO 	SD_DO
    
    If pull-up on P60
        branch to SD booter
    
    If pull-up on P61
        attempt to load from SPI
        if SPI data okay
            if pull-up on P59
                immediately run SPI code
            allow 100ms serial window before running SPI code
    
    allow 60s serial window
    

    That code looks to disturb 2 pins, before it decides to start serial ?
    Is that the lowest practical impact that can be achieved ?


  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
      NOTE: could use pd here to disable serial & TAQOZ for security conscious product
    
    Considering such security conscious product, has been largely overlooked & is important to include.

  • cgracey wrote: »
    jmg wrote: »
    :)
    Does this need a package suffix in there, for the TQFP100 ?
    Demand might see a QFN or BGA version offered in the future (same die) ?
    You could ask OnSemi what size BGA package this could drop into ?

    Well, this package is needed for its heat-dissipating ability. Other packages won't have the same ability and won't be usable for this chip. I think this package is going to be the only one.

    But 4 years ago the solution was to use a BGA package?

    I saw 3.6W absolute max for a Maxim part in TQFP100-EP.
  • The P1 was P8X32A.
    Propeller/8-Core/32-IO Pins/Model or Revision A(I think there was to be a version of the P1 with 64 IO Pins. Specified from OUTB in Spin documentary)

    The P2 should be:
    P2-Core #(I think it is still 8)X-IO Pin #-Revision#
    Something like:
    P2-8X68A
  • That's just my opinion. :smile:
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-14 19:18
    I've been trying to finish off testing the boot ROM code but found I really needed a better hardware setup for my CVA9 board, especially in terms of being able to test the SD and Flash on different pins to rule out any peculiarities with the FPGA and its pcb. The code seems to be running well, I just want to be able to test it a bit more. I was worried that there was a problem with the SD and Flash on the same 4-pins but it seems to boot fine. The logic analyzer is causing the ROM to see pull-downs on all the lines so I will have to check this with the 4-ch scope next.

    I want to do some more testing but I've been up all night and it's now 5AM so I figure I will try to catch a few hours sleep for now.

    Here are some captures plus a session with TAQOZ setting up serial Flash on P0..P3 for testing and checking Flash IDs and dumping etc as well as checking the I/O pin states.
    ------------------------------------------------------------------------------
      Parallax Propeller II  .:.:--TAQOZ--:.:.  V1.0-180514.2330 V32 FPGA         
    ------------------------------------------------------------------------------
    TAQOZ# $00.02.01.03 SFPINS  ok
    TAQOZ# SFJID .B $EF ok
    TAQOZ# SFSID .L SPACE .L $0751.5F27 $C862.4077 ok
    TAQOZ# 0 $40 SF DUMP 
    00.0000: FF FF FF FF FF FF FF FF FF FF FF FF 39 0A 39 0A    ............9.9.
    00.0010: 74 68 73 0D 0D 09 49 20 40 46 54 49 4D 45 20 2B    ths...I @FTIME +
    00.0020: 20 57 40 20 2E 46 54 49 4D 45 0D 0D 2D 2D 2D 09     W@ .FTIME..---.
    00.0030: 50 72 69 6E 74 20 74 68 65 20 66 69 6C 65 20 6E    Print the file n ok
    TAQOZ# lsio 
    PINS 
    P:00000000001111111111222222222233333333334444444444555555555566
    P:01234567890123456789012345678901234567890123456789012345678901
    =:h~~h~d~~~~~~~~~~~~~~~~~dd~~~d~~~~~~~hhhhh~~~d~d~~~hdhhdd~~~~~~ ok
    TAQOZ#
    

    I have the 5V power going to a mains remote outlet that I power on and off with a foot-switch while I also have a reset button on the breakout too.
    990 x 1230 - 230K
    1349 x 612 - 239K
    1349 x 612 - 199K
    1349 x 612 - 212K
  • A minor point but I suggest you change your banner to say "Parallax Propeller 2" instead of "Parallax Propeller II" since the official name of the chip seems to be "P2".
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-14 19:47
    David Betz wrote: »
    A minor point but I suggest you change your banner to say "Parallax Propeller 2" instead of "Parallax Propeller II" since the official name of the chip seems to be "P2".
    True true true, I've been concentrating on code but I also see this in Chip's code:
    '****************************************
    '*                                      *
    '*      Propeller II ROM Booter         *
    '*                                      *
    '*      5/12/2018 - v32d                *
    '*                                      *
    '****************************************
    

    I think we are probably going to refer to this chip as the P2 rather than the Propeller 2.


    EDIT: simplified splash string
    ----------------------------------------------------------------
      Parallax P2  .:.:--TAQOZ--:.:.  V1.0         
    ----------------------------------------------------------------
    

    P2 BOOT ROM Dropbox folder
  • jmgjmg Posts: 15,140
    Here are some captures plus a session with TAQOZ setting up serial Flash on P0..P3 for testing and checking Flash IDs and dumping etc as well as checking the I/O pin states.
    Looking good.

    Is serial boot still tested ?

    Does flash boot now support a Size.Offset header, or do users still have to manage and load two flash images ?

    Can serial boot, call into Flash loader ? (and I guess SD loader ?)



  • jmg wrote: »
    Here are some captures plus a session with TAQOZ setting up serial Flash on P0..P3 for testing and checking Flash IDs and dumping etc as well as checking the I/O pin states.
    Looking good.

    Is serial boot still tested ?

    Does flash boot now support a Size.Offset header, or do users still have to manage and load two flash images ?

    Can serial boot, call into Flash loader ? (and I guess SD loader ?)

    Serial hasn't changed but I am looking for lockout conditions.

    Chip has his reasons for the two stage boot and one of them is that the first stage can switch to whatever faster speed there is and continue to read 1-bit mode from Flash or switch bit modes. I'd still like to see a block method read into hub supported too though.

    It doesn't look like Cluso has any command to load SD from serial though. TAQOZ has serial Flash support and can backup and restore etc but doesn't bother trying to access SD.


  • Dumb question, but does On-semi have IP for fusible links? Seems like they should know their own processes and have ready-made IP for these things.
  • cgraceycgracey Posts: 14,131
    pedward wrote: »
    Dumb question, but does On-semi have IP for fusible links? Seems like they should know their own processes and have ready-made IP for these things.

    Yes, we looked into that, but integration into the design seemed quite complicated. It was more than I felt I could deal with at the time.
  • Cluso99Cluso99 Posts: 18,066
    jmg wrote: »
    Here are some captures plus a session with TAQOZ setting up serial Flash on P0..P3 for testing and checking Flash IDs and dumping etc as well as checking the I/O pin states.
    Looking good.

    Is serial boot still tested ?

    Does flash boot now support a Size.Offset header, or do users still have to manage and load two flash images ?

    Can serial boot, call into Flash loader ? (and I guess SD loader ?)

    Serial hasn't changed but I am looking for lockout conditions.

    Chip has his reasons for the two stage boot and one of them is that the first stage can switch to whatever faster speed there is and continue to read 1-bit mode from Flash or switch bit modes. I'd still like to see a block method read into hub supported too though.

    It doesn't look like Cluso has any command to load SD from serial though. TAQOZ has serial Flash support and can backup and restore etc but doesn't bother trying to access SD.

    Of course you can boot SD from the Monitor, which can be entered from serial like TAQOZ. It's the "R"un command.
Sign In or Register to comment.