The New 16-Cog, 512KB, 64 analog I/O Propeller Chip

Comments

Chip,
I do not believe OnSemi cannot provide working IP for at least one of Flash/EEPROM/OTP.

You are not talking to the right person!

You need to get the person you are talking to at OnSemi to put you onto the right person for this. I found this happened a lot to many semi companies (Motorola, Rockwell, AMD, SGS, etc). IMHO you should follow this up as it would make the world of difference for the P2, not just for fuse replacement, but a small section of boot code storage at least.

While security will not effect me, it is becoming a more prevalent thing in micros these days to be able to lock down a design. It was a prime objective for the P2 design (ask Ken), so to abandon it just because you haven't found the right person to ask in OnSemi seems like a major flaw, at least in my mind. Remember, OnSemi make a lot of EEPROM and FLASH chips, so they have to understand how they are doing that - I use their EEPROMS in my P1 designs.

While security will not effect me, it is becoming a more prevalent thing in micros these days to be able to lock down a design.

To the detriment of every end user.

"We suspect that ALMA will allow us to observe this rare form of CO in many other discs. By doing that, we can more accurately measure their mass, and determine whether scientists have systematically been underestimating how much matter they contain."

Both of these things you are suggesting would require schematic changes. They could be done, but reopening that box would cost another three weeks and more money. I don't think it's worth doing. Even if it would not cost anything, I kind of like things the way they are.

If they are not verilog accessible, I'd skip them, unless you find you need to make other schematic changes.
I guess users can always add an external watchdog, and claim their system design has oscillator fail features that way.

Chip,
I do not believe OnSemi cannot provide working IP for at least one of Flash/EEPROM/OTP.

You are not talking to the right person!

You need to get the person you are talking to at OnSemi to put you onto the right person for this. I found this happened a lot to many semi companies (Motorola, Rockwell, AMD, SGS, etc). IMHO you should follow this up as it would make the world of difference for the P2, not just for fuse replacement, but a small section of boot code storage at least.

While security will not effect me, it is becoming a more prevalent thing in micros these days to be able to lock down a design. It was a prime objective for the P2 design (ask Ken), so to abandon it just because you haven't found the right person to ask in OnSemi seems like a major flaw, at least in my mind. Remember, OnSemi make a lot of EEPROM and FLASH chips, so they have to understand how they are doing that - I use their EEPROMS in my P1 designs.

You're probably right, but I'm kind of exhausted on the whole issue. This is something we can address later on another rev, not to minimize the issue. I've just got other things that I need to push forward, that I CAN push forward.

While security will not effect me, it is becoming a more prevalent thing in micros these days to be able to lock down a design.

To the detriment of every end user.

What???

Companies have the right to protect their IP if they wish. There are far too many crooks wanting to steal everything instead of making an honest living. Then there are the others who just want to break things, such as making viruses.

While a lot of people want to hack Apple iPhones and iPads, others like me, want the devices locked down. That's why I buy them. No viruses, at least to speak of, is a byproduct of this lockdown. That's also a reason many hospitals are using iPads to record your medical records (taken at your bedside and forwarded to the servers).

If Parallax made multiple versions of the P2 available, for different prices for different features, but all used a single locked down chip to enable the features, I suppose you would object. It's just a marketing thing that has existed in the computer arenas for decades. We all win because the volume goes up, so prices can come down earlier,

Secure lock-down is quite different to product lock-in. And one does not require the other. Most lock-ins are extremely insecure devices.

"We suspect that ALMA will allow us to observe this rare form of CO in many other discs. By doing that, we can more accurately measure their mass, and determine whether scientists have systematically been underestimating how much matter they contain."

However, the main reason people ask for code protection is for lock-in function. They generally don't have any concern for security even when deployed as IOT device.

"We suspect that ALMA will allow us to observe this rare form of CO in many other discs. By doing that, we can more accurately measure their mass, and determine whether scientists have systematically been underestimating how much matter they contain."

[
Yes, I've read about this matter. I think someone posted something about this here a while back. I've not been there before, so we'll have to venture into that when the time comes.

It's good to do a little trail blazing if you can. Thinking about this more maybe you are in decent shape to run gate sims given the nature of your design. In gate simulation you could substitute a test ROM (or multiple test ROMs for different tests) in place of the boot ROM and bypass the lengthy boot process. It might be nice to simulate boot but that will obviously take longer, and more effort on your part.

I haven't thought about this much, but if you were to use Verilator then perhaps you could get help from some forum members without having to give out your Verilog. (You would have to look and see it what it generates is too close to verilog, and if so then maybe you could deliver an object file instead.) There are probably some people that you trust who would help out. Plus that might like to have to model regardless. It would also be quite useful for those wanting to build simulators. It's been discussed in the context of P1 on the forum already. Some ideas here - http://zipcpu.com/zipcpu/2017/07/26/cpu-sim-debugger.html

Not exactly sure that fuses solve a problem that can't be solved with software.

I don't believe that anyone has solved this on the P1 with software. Take a look what other processors and even FPGAs do to solve this problem.

As an aside there are some interesting problems related to all of this, and I'm not sure if they've all been solved. e.g. how do you provision secure software and FPGA bitstreams onto machines such as Amazon F1 instances, or Microsoft Azure servers. What if you don't trust Amazon or Azure insiders? The whole idea of fixed keys burned into parts falls apart there. I think that work is being done. I know that the latest Ultrascale FPGAs have a lot more security features.

'Been following this discussion at a distance. But it occurs to me that code security can be had without fuses, internal EEPROM, etc. In essence, the P2 would have an unreadable ROM bootloader that decrypts incoming EEPROM code using a fixed private key known only to Parallax. The external EEPROM contents would be encrypted with the complementary public key that Parallax publishes -- Diffie-Hellman style. No need for serialization, user-generated keys, or the like. Of course, the security depends entirely upon the secrecy and security of Parallax's private key. This entails strict policy protocols at Parallax, which they may or may not be equipped to implement.
________________

Code security is something that even the cheapest micros offer. Although I do not personally care one way or the other whether the P2 includes such a feature, I'm sure there are plenty of potential high-volume customers who do. But there appear to be two possible motives for not including it:

1. "Just get it done." (I've been saying this for years.) It's a good product -- even without security -- that deserves to see the light of day! Yes, it's been 11 years, and getting it "done" with good sales potential will surely see high fives in marketing, and the champagne corks will be flying.

2. "Just get it over with. I'm tired of dealing with it." Um, not so much. Fatigue is hardly a sales motivator, and I can't portend too much excitement at the marketing level. "Build it, and they will come," just doesn't work here. There has to be a positive reason for every feature inclusion or exclusion.

IOW, "get it done" and "get it over with" are two separate and mutually-exclusive motives.

So I guess my takeaway is this: include security if it's feasible; delete it if it's infeasible and if there's still a good market for the chip without it. (If such a market does not exist, it might be time to reconsider finishing the project at all.) But don't omit security just because of developer fatigue. The project has come too far for that.

-Phil

Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery

If there's only one private key then it's break once break everywhere. Not sure that those who really care about security will accept it. Say you were setting up ssh access to a bunch of servers. Would you use the same fixed key for all of them?

Regardless Parallax needs to do an analysis to determine that there aren't any side channel attacks that trivially expose the key.

If you search on youtube then you can find videos of this being done with various pieces of consumer electronics. Unfortunately also note that for public key cryptography there are potentially IP issues to preventing side channel attacks.

The fuses/EEPROM aren't being asked for for network security. Their primarily use is copy protection lock-in.

"We suspect that ALMA will allow us to observe this rare form of CO in many other discs. By doing that, we can more accurately measure their mass, and determine whether scientists have systematically been underestimating how much matter they contain."

The fuses/EEPROM aren't being asked for for network security. Their primarily use is copy protection lock-in.

I know. But the implementation still needs to be secure for interested customers to value it. Do you agree with the following? Using the same private key in every device is not preferred. There are well known side channel attacks against public key cryptography that would enable the recovery of the private key in a naive implementation.

Agreed, a singular fixed key is bad security. Better to leave that to other methods.

And it's even mostly worthless for lock-ins too, because a major feature of lock-ins is prevention of third party equipment duplication. A singular key does nothing in that respect.

"We suspect that ALMA will allow us to observe this rare form of CO in many other discs. By doing that, we can more accurately measure their mass, and determine whether scientists have systematically been underestimating how much matter they contain."

Is that the Crystal Target CL, or the internal added cap choices, per pin ? What is the expected per-pin C result (ESD, bonding, leadframe included )?
A 4pF Xtal is going to (ideally) expect 8pF total per PCB routed pin.

Is that the Crystal Target CL, or the internal added cap choices, per pin ? What is the expected per-pin C result (ESD, bonding, leadframe included )?
A 4pF Xtal is going to (ideally) expect 8pF total per PCB routed pin.

Right. There are options for 15pF and 30pF per leg, but the crystal sees half that. Each pin adds about 1.5pF, I believe.

Is that the Crystal Target CL, or the internal added cap choices, per pin ? What is the expected per-pin C result (ESD, bonding, leadframe included )?
A 4pF Xtal is going to (ideally) expect 8pF total per PCB routed pin.

Right. There are options for 15pF and 30pF per leg, but the crystal sees half that. Each pin adds about 1.5pF, I believe.

I talked to one of the OnSemi guys today and asked him if we could reduce our fuse dimensions by 1/3. This would mean that the silicided poly fuse would go from 180nm wide (the process minimum) down to 120nm. That would lower the programming voltage from 5V to 3.3V, or something like that. This would be a drastic design rule violation, but it would probably fabricate okay. The 180nm rule is to ensure that millions of instances of 180nm-wide poly on a die are reliably-enough fabricated that maybe 75% of chips are good. So, 120nm wouldn't be viable for millions of instances, but might be okay for only 256 instances. I think the probability of a fabrication failure would be pretty low per chip. This is not the kind of design-rule violation that people typically ask to sign off on, though.

I talked to one of the OnSemi guys today and asked him if we could reduce our fuse dimensions by 1/3. This would mean that the silicided poly fuse would go from 180nm wide (the process minimum) down to 120nm. That would lower the programming voltage from 5V to 3.3V, or something like that. This would be a drastic design rule violation, but it would probably fabricate okay. The 180nm rule is to ensure that millions of instances of 180nm-wide poly on a die are reliably-enough fabricated that maybe 75% of chips are good. So, 120nm wouldn't be viable for millions of instances, but might be okay for only 256 instances. I think the probability of a fabrication failure would be pretty low per chip. This is not the kind of design-rule violation that people typically ask to sign off on, though.

Sounds like the sort of change that really needs to be tested. You could also try a necked fuse, assuming their litho processing can handle that ?

Meanwhile the test chips should allow much better Fuse-Stats, right ?
You should be able to run a few hundred at (eg 3.795V) (3v3 + 15%), and get Current/Time profiles on each blow, to catch what constitutes a failure ?

Sounds like the sort of change that really needs to be tested. You could also try a necked fuse, assuming their litho processing can handle that ?

Meanwhile the test chips should allow much better Fuse-Stats, right ?
You should be able to run a few hundred at (eg 3.795V) (3v3 + 15%), and get Current/Time profiles on each blow, to catch what constitutes a failure ?

IMHO, it's also important to enhance the cathode layout, in order to increase the area available for reflow during the electromigration of the molten fuse.
Perhaps a little more cathode area could help, without so many stitching vias into its immediate vicinity, thus raisingincreasing cathode's temperature gradient a little bit, as it will have a similar action as the copper mesh has, during a solder wicking operation.

Sounds like the sort of change that really needs to be tested. You could also try a necked fuse, assuming their litho processing can handle that ?

Meanwhile the test chips should allow much better Fuse-Stats, right ?
You should be able to run a few hundred at (eg 3.795V) (3v3 + 15%), and get Current/Time profiles on each blow, to catch what constitutes a failure ?

IMHO, it's also important to enhance the cathode layout, in order to increase the area available for reflow during the electromigration of the molten fuse.
Perhaps a little more cathode area could help, without so many stitching vias into its immediate vicinity, thus raisingincreasing cathode's temperature gradient a little bit, as it will have a similar action as the copper mesh has, during a solder wicking operation.

IMHO, it's also important to enhance the cathode layout, in order to increase the area available for reflow during the electromigration of the molten fuse.
Perhaps a little more cathode area could help, without so many stitching vias into its immediate vicinity, thus raisingincreasing cathode's temperature gradient a little bit, as it will have a similar action as the copper mesh has, during a solder wicking operation.

That does give a current profile, which could be a great help in setting up capture equipment.
Looks like they use 6V and need 90mA peak, for a 350nm x 1.5um fuse, & it seems to have two weakening zones.