New P2 Silicon

11920212325

Comments

  • evanhevanh Posts: 8,958
    edited 2019-12-14 - 04:33:29
    So, the Wikipedia link wasn't helpful at all. A little more reading of other links tells me it is usually used to portray the CPU facilities that are available to the programmer, the flow of execution and addressing. Things like bank switching and segmentation. MMU's will be a major player. Register sets obviously.

    Harvard vs Von Neumann are quoted as educational examples.

  • evanhevanh Posts: 8,958
    edited 2019-12-14 - 05:10:37
    I tell you what, the number of buses data or address paths in the prop2 is scary. Chip would probably have trouble identifying them all.

  • Here is one:

    http://members.casema.nl/hhaydn/howel/parts/6809_prog_model.htm

    Yes. While I think the Wikipedia position on this is a bit painful, you expressed the basic idea.

    I think I am going to start on one. SVG format so it can be hacked on, until it is representative. I get the feeling the moment one is started, all of the, "yes, but it needs", and "nope, that should be" chatter will get us one quickly.

    The Prop 2 is challenging!

    May need to do it from multiple perspectives.

    Chip
    COG COGEX
    COG HUBEX
    HUB

    Smart PIN

    While most of us grok the internals, we may find this sort of thing helps others.

    When learning a new CPU, this is the first thing I went for.


  • I guess one thing that a programming model does not include is timing information.
  • It has to eventually. But maybe not to start on just what everything is, and how it's related, etc...



  • Was just reading an article about a bunch of galaxies that, preliminarily, have no dark matter in them. That got me thinking about the static of untuned radios and old analogue TV receivers and noted that uninitialised DRAM also looks that way.

    Question: Is hubRAM also this random on power up? I think it might be. Count this as a reminder to look tomorrow.

  • evanh wrote: »
    Was just reading an article about a bunch of galaxies that, preliminarily, have no dark matter in them. That got me thinking about the static of untuned radios and old analogue TV receivers and noted that uninitialised DRAM also looks that way.

    Question: Is hubRAM also this random on power up? I think it might be. Count this as a reminder to look tomorrow.

    From my experiments with power-cycling the P2 for brief periods of time after loading an picture into hubram and then displaying it with VGA, hubram ends up pretty much random after being powered off for enough time. I don't know whether certain bits tend to default to the same state on every power-up or whether it's actually random every time.
  • There may be some amount of capacitive bias in a bit cell design which causes one side to drag down more than the other during power-up, causing that bit to usually take on a certain state. I remember on my old Apple ][, memory would typically power up with a run of $FF's, followed by a run of $00's, repeating.
  • My Apple was the same. I do not think the contents of a P2 will be that random on cold start. Parts of it will be.

  • I saw the same thing with un-initiated VGA buffer... I assumed it was totally random... I'd be surprised if it turned out to be fixed...
    If it is, would almost be like a serial number... Would any two P2's be the same?
  • It will likely be "mostly fixed"

  • Each smartpin has a different GIO and VIO calibration value, eg GIO is typically around 11000 and VIO around 55000 when using 16 bit ADC counts.

    I've been thinking it should be possible to use these as a kind of digital thumbprint. You could certainly do a linear regression style fit to do the matching.

    What would be neat is to turn this information into a code (serial number) that is sufficiently robust and unchanging.
  • The print probably stays the same relatively but I suspect you'd also have to accommodate some offset for temperature.

  • TonyB_TonyB_ Posts: 1,456
    edited 2019-12-16 - 13:44:39
    cgracey wrote: »
    msrobots wrote: »
    why would you want to do that anyway?

    Mike

    I've got my reasons. It's part of the Spin2 interpreter's inline PASM feature. You can load code into $000..$167 and execute it. That code sequence is for loading PASM code of some length, starting at some register, executing it, and then resuming bytecode execution from where the PASM binary left off. I needed PTRA to stay current.

    Here is how this interpreter code looks now:
    '
    '
    ' a: In-line PASM
    ' b: REGEXEC(hubadr)
    ' c: REGLOAD(hubadr)
    ' d: CALL(anyadr)
    '
    inline_pasm	setq	#16-1			'a		load local variables from hub into buff
    		rdlong	buff,dbase		'a
    		bith	v,#31			'a		set flag to later restore local variables to hub
    
    		mov	ptrb,pb			'a		get bytecode ptr into ptrb
    		skip	##%11100100000111	'a	x2	begin inline_pasm skip pattern
    
    regexec_	skip	##%1111000000		'| b	x2	begin REGEXEC skip pattern
    regload_	mov	ptrb,x			'| b c		get hubadr into ptrb
    
    		rdword	w,ptrb++		'a b c		read start register
    		rdword	y,ptrb++		'a b c		read length of pasm code, minus 1
    
    		setq	y			'a b c		read in code
    		altd	w			'a b c
    		rdlong	0,ptrb++		'a b c		altd causes ptrb++ to inc by 1*4, not by (y+1)*4
    
    	_ret_	popa	x			'| | c		REGLOAD done, pop stack
    
    		shl	y,#2			'a |		update bytecode ptr for inline_pasm
    		add	y,ptrb			'a |
    
    call_pasm	mov	w,x			'| |   d	get CALL address
    		popa	x			'| b   d	pop stack
    
    		mov	y,pb			'| b   d	save bytecode ptr
    		mov	z,ptra			'a b   d	save ptra
    
    		call	w			'a b   d	call pasm code (can use pa/pb/ptra/ptrb/stack)
    
    		testb	v,#31		wc	'a b   d	if inline_pasm, restore local variables to hub
    	if_c	setq	#16-1			'a b   d
    	if_c	wrlong	buff,dbase		'a b   d
    
    		mov	ptra,z			'a b   d	restore ptra
    	_ret_	mov	pb,y			'a b   d	restore bytecode ptr
    
    Some questions related to a, In-line PASM:

    Q1. Is the skip pattern correct?

    Q2. For max speed, couldn't rflong be used to read w and y together? More longs but quicker?

    Q3. Is pb a copy of the bytecode ptr, or the actual ptr and must always point to current bytecode before doing _ret_ for the next one?

    Q4. The inline PASM is copied to cog RAM and executed there, but what if, in other cases, there is no room in the cog and therefore inline code must be run in situ in hub RAM?

    The last question is a general one about how to escape from bytecode to P2 code, then return to bytecode.
  • cgraceycgracey Posts: 12,609
    edited 2019-12-16 - 16:52:53
    TonyB_ wrote: »
    cgracey wrote: »
    msrobots wrote: »
    why would you want to do that anyway?

    Mike

    I've got my reasons. It's part of the Spin2 interpreter's inline PASM feature. You can load code into $000..$167 and execute it. That code sequence is for loading PASM code of some length, starting at some register, executing it, and then resuming bytecode execution from where the PASM binary left off. I needed PTRA to stay current.

    Here is how this interpreter code looks now:
    '
    '
    ' a: In-line PASM
    ' b: REGEXEC(hubadr)
    ' c: REGLOAD(hubadr)
    ' d: CALL(anyadr)
    '
    inline_pasm	setq	#16-1			'a		load local variables from hub into buff
    		rdlong	buff,dbase		'a
    		bith	v,#31			'a		set flag to later restore local variables to hub
    
    		mov	ptrb,pb			'a		get bytecode ptr into ptrb
    		skip	##%11100100000111	'a	x2	begin inline_pasm skip pattern
    
    regexec_	skip	##%1111000000		'| b	x2	begin REGEXEC skip pattern
    regload_	mov	ptrb,x			'| b c		get hubadr into ptrb
    
    		rdword	w,ptrb++		'a b c		read start register
    		rdword	y,ptrb++		'a b c		read length of pasm code, minus 1
    
    		setq	y			'a b c		read in code
    		altd	w			'a b c
    		rdlong	0,ptrb++		'a b c		altd causes ptrb++ to inc by 1*4, not by (y+1)*4
    
    	_ret_	popa	x			'| | c		REGLOAD done, pop stack
    
    		shl	y,#2			'a |		update bytecode ptr for inline_pasm
    		add	y,ptrb			'a |
    
    call_pasm	mov	w,x			'| |   d	get CALL address
    		popa	x			'| b   d	pop stack
    
    		mov	y,pb			'| b   d	save bytecode ptr
    		mov	z,ptra			'a b   d	save ptra
    
    		call	w			'a b   d	call pasm code (can use pa/pb/ptra/ptrb/stack)
    
    		testb	v,#31		wc	'a b   d	if inline_pasm, restore local variables to hub
    	if_c	setq	#16-1			'a b   d
    	if_c	wrlong	buff,dbase		'a b   d
    
    		mov	ptra,z			'a b   d	restore ptra
    	_ret_	mov	pb,y			'a b   d	restore bytecode ptr
    
    Some questions related to a, In-line PASM:

    Q1. Is the skip pattern correct?

    Q2. For max speed, couldn't rflong be used to read w and y together? More longs but quicker?

    Q3. Is pb a copy of the bytecode ptr, or the actual ptr and must always point to current bytecode before doing _ret_ for the next one?

    Q4. The inline PASM is copied to cog RAM and executed there, but what if, in other cases, there is no room in the cog and therefore inline code must be run in situ in hub RAM?

    The last question is a general one about how to escape from bytecode to P2 code, then return to bytecode.

    1) Yes, the SKIP pattern is correct. Note that the first SKIP pattern must skip over the second SKIP which uses AUGD.
    2) A RDLONG could be done, but then it would take 3 more instructions to split the words. Not worth it, I thought.
    3) There is a short routine that calls this code which uses PB as a storage for the bytecode pointer which gets used in a RDFAST later.
    4) The supposition is that in-line PASM, REGEXEC, and REGLOAD all use available register space. If you want to call to hub-exec code, just do a CALL(hubaddr).

    All PASM code gets free use of PA/PB/PTRA/PTRB and six hardware stack levels. The in-line PASM is special because it gets to access the first 16 parameters, results, and local variables by name, since they are temporarily moved into registers $1E0..$1EF.
  • cgraceycgracey Posts: 12,609
    edited 2020-01-17 - 08:46:39
    ON Semi contacted us today and let us know that the new wafers are already out of the fab and being sorted, so they can be sent off for packaging at Amkor. Wendy let me know that our new test program is working fine, too, so they are able to fully test the new silicon. It will take until March 3 to receive the newly packaged chips from Amkor, though. It's amazing how quickly these last wafers got built.
  • Great news Chip!
  • Fantastic news :smiley:
  • Is that the whole lot, that wasn't expected until late April, even into May?

  • RaymanRayman Posts: 10,433
    edited 2020-01-17 - 11:14:09
    Sounds like some chips already passed the test program?

    That’d be great news.
    Hopefully the adc issue is fixed and everything else is the same...
  • There is another lot of wafers coming at the end of March, but we will have lots of packaged chips before that.

    I'm glad they used the test program that I modified for the new silicon. They were talking like they weren't going to use it because the risk was too high, but they did use it and it worked okay.
  • 10 chips on March 3rd. A few thousand at end of March (many of which are booked already) with several thousand more end of April. The whole schedule was pulled in by a few weeks.
  • Ken Gracey wrote: »
    10 chips on March 3rd. A few thousand at end of March (many of which are booked already) with several thousand more end of April. The whole schedule was pulled in by a few weeks.

    Yay, so I may have a P2 for my birthday instead of chipmas.
  • kwinn wrote: »
    Ken Gracey wrote: »
    10 chips on March 3rd. A few thousand at end of March (many of which are booked already) with several thousand more end of April. The whole schedule was pulled in by a few weeks.

    Yay, so I may have a P2 for my birthday instead of chipmas.

    The best gift you could get.

    Good luck!

    Mike
  • Today we received ten (10) of the revision C P2 silicon chips. They're being mounted on a couple of Propeller 2 ES Evaluation Boards and Chip is on his way to pick them up.

    Ken Gracey
  • PublisonPublison Posts: 11,282
    edited 2020-02-24 - 22:29:52
    Ken Gracey wrote: »
    Today we received ten (10) of the revision C P2 silicon chips. They're being mounted on a couple of Propeller 2 ES Evaluation Boards and Chip is on his way to pick them up.

    Ken Gracey

    Cool Beans!
    Closer to a roll-out party!
  • Good Luck! This is big!
  • The new P2 silicon seems fine.
  • Awesome!
Sign In or Register to comment.