Have we decided on a quick way to detect RevB vs RevA silicon?

Peter Jakacki · 2019-11-10 02:30

I'm sure there is a simple test I can do with the instructions but have we come up with a quick and easy and standard way of detecting the new silicon?

evanh · 2019-11-10 02:39

I've settled on Tony's idea of using the revised XORO32 output

'silicon rev A/B detect
		mov	pa, #1
		xoro32	pa
		cmp	pa, 0-0		wc	'C = 1 if revA (D = $42a01290  S = $50ad0021), C = 0 if revB (D = $84908405  S = $62690201)
	if_c	mov	hw_rev, #01		'revA
	if_nc	mov	hw_rev, #02		'revB

Eric uses a difference in instruction encodings using PTRx ops. Weren't you doing the same?

Peter Jakacki · 2019-11-10 02:48

I hadn't looked into it yet, and while there are many ways to slice and dice, this might lead to compatibility problems later on if we don't standardize. I'm happy to go with Tony's method but I'd like to hear Eric's opinion too.

ozpropdev · 2019-11-10 06:10

	mov	ptra,#1
	rdlut	pa,ptra++

Retutns 1 for RevA and 2 for RevB

evanh · 2019-11-10 08:29

Oh, PTRA itself. That's cool, so small it doesn't need stored. EDIT: Err, or not. Messing with PTRA can be awkward ... and still need a subsequent CMP to set a flag when deciding in later program.

Still, the storing code is smaller at least.

'silicon rev A/B detect
		mov	ptra, #1
		rdlut	pa,ptra++
		mov	hw_rev, ptra		'1 = revA, 2 = revB

Oh, bugger, of course, that RDLUT is illegal when using revA assembly! I suppose revA assembly mode should be reserved for old code only anyway. New sources will always be assuming revB with crafted conditionals for revA comparing.

iseries · 2019-11-10 10:00

Why bother, revA is dead and never made it to production.

Anybody who has one has a nice paper weight or add a fan and have a desk top heater.

Mike

ersmith · 2019-11-10 10:41

ozpropdev wrote: »
	mov	ptra,#1
	rdlut	pa,ptra++
Retutns 1 for RevA and 2 for RevB

I like this ptra check much better than the xoro32 check, because it will keep working if there's ever a RevC or RevD. Depending on the values of a PRNG seems dangerous to me.

My code for checking revA vs revB uses another COG, so it doesn't disturb the current one. It's more verbose, but seems pretty robust and is what I used in MicroPython and my VGA driver:

DAT
	org	0
	' code used to check hardware revision
	' in rev A (the original silicon) setq + rdlong pa, ptrb++ 
	'  increments ptrb only once
	' in rev B (revised silicon) it will increment ptrb appropriately
        '
hwcheck_pasm
	mov	pb, ptrb
	setq	#1
	rdlong	$1e0, ptrb++
	subr	pb, ptrb
	shr	pb, #2 wz
  if_z	mov	pb, #1
  	wrlong	pb, ptra
	cogid	pa
	cogstop	pa

' check the hardware revision
' return 1 for original silicon, 2 for new silicon

PUB check_hw_rev | tmp
  tmp := 0
  cognew(@hwcheck_pasm, @tmp)
  repeat while tmp == 0
  return tmp

evanh · 2019-11-10 10:50

ersmith wrote: »

I like this ptra check much better than the xoro32 check, because it will keep working if there's ever a RevC or RevD. Depending on the values of a PRNG seems dangerous to me.

That seems like a good reason to explicitly use XORO32, since it has a chance of distinguishing multiple revisions of the silicon.

ersmith · 2019-11-10 11:43

evanh wrote: »

ersmith wrote: »

I like this ptra check much better than the xoro32 check, because it will keep working if there's ever a RevC or RevD. Depending on the values of a PRNG seems dangerous to me.

That seems like a good reason to explicitly use XORO32, since it has a chance of distinguishing multiple revisions of the silicon.

It depends on what you're trying to detect. For many cases you'll want to determine whether the silicon is >= some revision, not exactly equal to some revision. The xoro check shown above only works to detect a specific revision. I suppose you could add a case for "unknown revision", but the code as presented doesn't do that -- it's just checking the high bit of the generated random number and deciding revA / revB based on that, which will fail if revC happens to generate the same high bit as revA.

evanh · 2019-11-10 11:55

Fair call, that particular compare is cheaply done.

TonyB_ · 2019-11-10 13:18

ersmith wrote: »

evanh wrote: »

ersmith wrote: »

I like this ptra check much better than the xoro32 check, because it will keep working if there's ever a RevC or RevD. Depending on the values of a PRNG seems dangerous to me.

That seems like a good reason to explicitly use XORO32, since it has a chance of distinguishing multiple revisions of the silicon.

It depends on what you're trying to detect. For many cases you'll want to determine whether the silicon is >= some revision, not exactly equal to some revision. The xoro check shown above only works to detect a specific revision. I suppose you could add a case for "unknown revision", but the code as presented doesn't do that -- it's just checking the high bit of the generated random number and deciding revA / revB based on that, which will fail if revC happens to generate the same high bit as revA.

Unlike RDLUT, XORO32 could be deliberately different for each revision, just need to test more than one bit if RevC and above.

ersmith · 2019-11-10 13:42

TonyB_ wrote: »

Unlike RDLUT, XORO32 could be deliberately different for each revision, just need to test more than one bit if RevC and above.

You'd need to check all 32 bits -- which is fine, but please, let's not take shortcuts that can break in future revisions (like testing only 1 or 2 bits).

Rayman · 2019-11-10 14:22

I'm with Mike... Just forget about Rev. A...

Peter Jakacki · 2019-11-10 14:34

Rayman wrote: »

I'm with Mike... Just forget about Rev. A...

Yep, anyone can just forget if they want but don't forget that there are 100 revA EVAL boards out there that would be rendered useless by a simple "just forget about them".

It's only because there are people who do things the hard way first that it ends up easy for the rest, whereas if we did things the easy way first, it ends up hard for the rest.

JRoark · 2019-11-10 16:46

Peter Jakacki wrote: »

It's only because there are people who do things the hard way first that it ends up easy for the rest, whereas if we did things the easy way first, it ends up hard for the rest.

That is an essential truth right there, and its downright sig-worthy.

Cluso99 · 2019-11-10 19:57

evanh wrote: »
Oh, PTRA itself. That's cool, so small it doesn't need stored. EDIT: Err, or not. Messing with PTRA can be awkward ... and still need a subsequent CMP to set a flag when deciding in later program.

Still, the storing code is smaller at least.
'silicon rev A/B detect
		mov	ptra, #1
		rdlut	pa,ptra++
		mov	hw_rev, ptra		'1 = revA, 2 = revB
Oh, bugger, of course, that RDLUT is illegal when using revA assembly! I suppose revA assembly mode should be reserved for old code only anyway. New sources will always be assuming revB with crafted conditionals for revA comparing.

IIRC this works because rev 1 did not inc ptra, so this should work

    mov     Ptra,#0
    rdlut   pa,ptra++
    mov     ptra,ptra    wz    ‘0=rev1, 1=rev2

I wonder if the rdlut instruction RDLUT PTRA,PTRA++ would work, meaning we wouldn’t need to overwrite PA.
Note using PTRB++ would also work.

IMHO I think ignoring those rev1 boards is a mistake for those who ponied up many $ for their boards. It’s way too early to leave them behind where possible. Of course, some things (instructions) just will not work on rev1.
Remember, same could happen to this rev if an obscure major bug turns up. Just sayin...

Off topic
Damn forum sw just kicked me off when I tried to post this and then decided it was time to renter my logon credentials. Lucky for me I have learnt to copy my post to the clipboard

samuell · 2019-11-10 20:16

Peter Jakacki wrote: »

Rayman wrote: »

I'm with Mike... Just forget about Rev. A...

Yep, anyone can just forget if they want but don't forget that there are 100 revA EVAL boards out there that would be rendered useless by a simple "just forget about them".

It's only because there are people who do things the hard way first that it ends up easy for the rest, whereas if we did things the easy way first, it ends up hard for the rest.

Indeed, especially when 100 people invested $150 each (giving a grand total of $15000) in rev. A boards, that are still very capable and should not be rendered useless by software. Software is way cheaper than hardware, and it costs next to nothing to support rev. A boards.

On another note, I have no idea that the assembly/instruction set had changed. I thought it was already set on stone. I hope there will be a rev. C of the chip that passes the OnSemi requirements, though I was happy to see that the new chips consume half the power when compared to the previous iteration. That is already a big improvement, considering that rev. A chips are already low power and good for embedded applications. I'll have to do a current consumption comparison between the two versions, considering a real life use case (prime numbers, eheh).

Kind regards, Samuel Lourenço

Cluso99 · 2019-11-10 20:33

@samuell,
Evan did a quite thorough power consumption between rev1 and rev2 chips. The scaremongering P2 power consumption was way overstated for the first rev, and basically the new rev2 has pretty much halved that

BTW I’m not expecting a rev3. If all goes well, that $80K IIRC can be saved including the additional 3 months IIRC again.

The rev2 added a few extra variant instruction to allow the bit instructions to also do a bit range - only applicable if the upper bits b8:5 were not zero, the PTR++ style instructions were fixed and expanded, the streamer mode bits were changed, and there were some ADC changes and additions. It’s all in Chips documents. Oh, and the signed bugs were fixed.

Dave Hein · 2019-11-10 20:38

If there are any future revisions of the P2 it would be nice if the rev number could be read from a register.

Cluso99 · 2019-11-10 20:56

Dave Hein wrote: »

If there are any future revisions of the P2 it would be nice if the rev number could be read from a register.

Currently it is available in a fixed location in hub ram loaded from the serial rom (see the listing as it’s defined as a constant
“G” IIRC). Of course this can be overwritten so it would need to be saved somewhere.

JRoark · 2019-11-10 21:04

It might be worth pulling an Intel and including a couple of MSRs (model-specific registers) that would give product, model and stepping information. Maybe Chip can put this on the list for the P3.

cgracey · 2019-11-10 23:13

All my future efforts will be exclusively for the Rev B silicon, since it's the final product, without bugs and with significant new features. Rev A was the stepping stone to get to Rev B, which turned out to be the completion point.

It would be a drag to carry Rev A baggage forward into every new effort, since there will always be only 120 of the Rev A chips in the world, amid hopefully millions of Rev B chips.

cgracey · 2019-11-10 23:23

Perhaps we can have a program where anyone interested can send in their Rev A P2 Eval board and we can replace the P2 with a Rev B chip. The problem is that it takes an awful lot of labor to do that. Our assembly crew is busy enough, already. We'd have to charge at least $50. It's probably better to just buy a Rev B Eval board with all the updated stuff on it.

evanh · 2019-11-10 23:48

For me, it's just about the porting and testing of older code onto the revB. Often I find I'm building it first on revA just to prove I've got the setup to work the way it had historically. Then I'll start trying to find why it isn't working with revB. This is easier if the program can be used on both without having to fork it.

After the compatibilities are ironed out, and I understand the differences, then I'm okay with leaving revA to rot.

Gary's USB code was a good example. Not that it was me putting the effort in. A large piece of code and there was literally only a couple edits to make, as recommended by Gary, and yet it wasn't working. Being able to flick back and forth between the two boards to confirm nothing else was messed up helped with building certainty of where the problem didn't lie.

samuell · 2019-11-11 00:26

Cluso99 wrote: »

@samuell,
Evan did a quite thorough power consumption between rev1 and rev2 chips. The scaremongering P2 power consumption was way overstated for the first rev, and basically the new rev2 has pretty much halved that
...

Well, I still want to make my own tests. I have to test the USB test switch too (mainly its current measurement ability).

cgracey wrote: »

All my future efforts will be exclusively for the Rev B silicon, since it's the final product, without bugs and with significant new features. Rev A was the stepping stone to get to Rev B, which turned out to be the completion point.

It would be a drag to carry Rev A baggage forward into every new effort, since there will always be only 120 of the Rev A chips in the world, amid hopefully millions of Rev B chips.

That's a bad route Chip, IMHO. That has the same effect of planned obsolescence. I was expecting the instruction set to be set on stone by this date.

cgracey wrote: »

Perhaps we can have a program where anyone interested can send in their Rev A P2 Eval board and we can replace the P2 with a Rev B chip. The problem is that it takes an awful lot of labor to do that. Our assembly crew is busy enough, already. We'd have to charge at least $50. It's probably better to just buy a Rev B Eval board with all the updated stuff on it.

Now that I've bought the Rev. B board, I don't have any interest on getting the sample replaced. Plus, there is a historical value on maintaining the board and sample as is.

Kind regards, Samuel Lourenço

ozpropdev · 2019-11-11 00:43

Cluso99 wrote: »

I wonder if the rdlut instruction RDLUT PTRA,PTRA++ would work, meaning we wouldn’t need to overwrite PA.

Short answer No.
RevA returns random data in PTRA
RevB returns contents of LUT

jmg · 2019-11-11 00:54

samuell wrote: »

Peter Jakacki wrote: »

Rayman wrote: »

I'm with Mike... Just forget about Rev. A...

Yep, anyone can just forget if they want but don't forget that there are 100 revA EVAL boards out there that would be rendered useless by a simple "just forget about them".
It's only because there are people who do things the hard way first that it ends up easy for the rest, whereas if we did things the easy way first, it ends up hard for the rest.

Indeed, especially when 100 people invested $150 each (giving a grand total of $15000) in rev. A boards, that are still very capable and should not be rendered useless by software. Software is way cheaper than hardware, and it costs next to nothing to support rev. A boards.

I agree, those boards are not cheap, and they still work.
This is not much effort, and it expands testing, and it's nice to have all practical possible P2 chips alive and working at this stage.
Work on RevIDs will also carry forward, to future RevC etc

potatohead · 2019-11-11 01:08

Chip can target rev B with low overall impact.

Others are targeting both right now. Over a fairly short period of time, Rev A won't matter much.

Maybe a quick archive of the basic tools set aside is all Rev A needs longer term. And we have reasonable tools working on Rev A right now.

For right now, yes. Both make sense.

A few months from now when chips are moving? Does not make sense.

kwinn · 2019-11-11 05:33

cgracey wrote: »

All my future efforts will be exclusively for the Rev B silicon, since it's the final product, without bugs and with significant new features. Rev A was the stepping stone to get to Rev B, which turned out to be the completion point.

It would be a drag to carry Rev A baggage forward into every new effort, since there will always be only 120 of the Rev A chips in the world, amid hopefully millions of Rev B chips.

That's a logical and very reasonable approach IMHO.

cgracey wrote: »

Perhaps we can have a program where anyone interested can send in their Rev A P2 Eval board and we can replace the P2 with a Rev B chip. The problem is that it takes an awful lot of labor to do that. Our assembly crew is busy enough, already. We'd have to charge at least $50. It's probably better to just buy a Rev B Eval board with all the updated stuff on it.

Perhaps you could provide a discounted price for a single Rev B board to any Rev A purchaser instead. If I had purchased a Rev A board I would be mounting it in a framed display case with a write up of how it came to be and it's is capabilities as soon as I received my first Rev B board. Might even add audio and video instead of a written description.

evanh · 2019-11-12 00:34

Cluso99 wrote: »

Evan did a quite thorough power consumption between rev1 and rev2 chips. The scaremongering P2 power consumption was way overstated for the first rev, and basically the new rev2 has pretty much halved that

That revB half of revA is rough generalisation. A single cog can be as low as 35%. But if all eight cogs are worked hard then the revB numbers can exceed 80% of the revA power. And, although under one watt will be typical, the wide overclocking range has ability of raising revB above three watts. Which is the original scaremongering levels.

SaucySoliton · 2019-11-12 02:01

Peter Jakacki wrote: »

I'm sure there is a simple test I can do with the instructions but have we come up with a quick and easy and standard way of detecting the new silicon?

What about read a certain address in the ROM?

< fc560     fdb00040 _Start_SDcard   call    #@_SDcard_Init                  ' initialise & read CSD/CID
> fc560     f6079a00 _Start_SDcard   mov     skiprun,          #0            ' load/run MBR/VOL code                         \ --tweek2--

This was the first change I saw in the .lst. It may not be the best choice.

Have we decided on a quick way to detect RevB vs RevA silicon?

Comments