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.
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,
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.
[
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.
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.
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.
The test chip shuttle is scheduled for September 15th. That's still four weeks away. We intended to run our latest test chip on there.
What values of Crystal Load C are available in P2 ?
I see in today's news, Abracon have new families of lower CL, Lower ESR crystals.
As might be expected, the smallest packages cost more than the larger ones....
Mouser look to have stocks of 11 Freqs, (all 4pF CL) 12~40MHz, in the ±10ppm 3.2 mm x 2.5 mm I searched ( ~ 33c/3k)
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.
So the lowest P2 support Xtal Cap is ~9pF (15pF+1.5pF+~1.5pF PCB Stray)/2
which could be a Xtal like this one (tightest tolerance, lowest price SMD)
TSX-3225 16.0000MF09Z-AC0 EPSON 16.00 MHZ 9PF SMD Stock : 54,000 $0.255@ 3000 ±9ppm ±10ppm 9pF 60 Ohm -20°C ~ 75°C
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.
It has always been a pleasure to observe and participate.
I must thank you for sharing your thoughts and concerns in such a way and extent that invites us for the joy of study, learn and think.
Though a little bit heavier (in the sense of the mathematics involved), the following document could be of great value too.
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.
Comments
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.
I guess users can always add an external watchdog, and claim their system design has oscillator fail features that way.
What do you mean, Evanh?
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.
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,
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.
I dunno.
Not exactly sure that fuses solve a problem that can't be solved with software.
I have some stuff that I want protected. Seems like a software problem to me:)
The more serious the problem, the more inventive the solution can be.
Dongles now. Dongles forever.
I would avoid PKE for the time being:) Seems like someone solved that.
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
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.
________________
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
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.
https://newae.com/tools/chipwhisperer/
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.
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.
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.
I see in today's news, Abracon have new families of lower CL, Lower ESR crystals.
As might be expected, the smallest packages cost more than the larger ones....
Mouser look to have stocks of 11 Freqs, (all 4pF CL) 12~40MHz, in the ±10ppm 3.2 mm x 2.5 mm I searched ( ~ 33c/3k)
https://www10.edacafe.com/nbc/articles/1/1529951/Abracon-announces-new-IoT-optimized-quartz-crystal-series-with-lowest-CL-lowest-ESR-available-market
http://abracon.com/Support/flyer/IoT_Quartz-Crystal-NEW.pdf
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.
While I've never used it an AT88SCxxx, a 66 cent part looks like it could provide security for those who need it.
Right. There are options for 15pF and 30pF per leg, but the crystal sees half that. Each pin adds about 1.5pF, I believe.
So the lowest P2 support Xtal Cap is ~9pF (15pF+1.5pF+~1.5pF PCB Stray)/2
which could be a Xtal like this one (tightest tolerance, lowest price SMD)
TSX-3225 16.0000MF09Z-AC0 EPSON 16.00 MHZ 9PF SMD Stock : 54,000 $0.255@ 3000 ±9ppm ±10ppm 9pF 60 Ohm -20°C ~ 75°C
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 raising increasing cathode's temperature gradient a little bit, as it will have a similar action as the copper mesh has, during a solder wicking operation.
Henrique
P.S. some references could be found at
paris.utdallas.edu/ssiri08/Tonti_SSIRI_eFuse_V2.pdf
Thank you for bringing this up, Henrique.
It has always been a pleasure to observe and participate.
I must thank you for sharing your thoughts and concerns in such a way and extent that invites us for the joy of study, learn and think.
Though a little bit heavier (in the sense of the mathematics involved), the following document could be of great value too.
https://ulsites.ul.ie/macsi/sites/default/files/macsi_an_investigation_into_the%20_physics_of_blowing_polysilicon_fuses.pdf
nice plots, and I like the idea of the 'wings' on cathode.
Their anode is much smaller than Chip's but any vias are unclear here.
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.