That's 200 cycles out from trigger on the 20MHz RC oscillator. I set 'persist' mode and let it run for about 10 seconds. It only varied by ~8ns. 8ns/10us is less than 0.1% variance. This will work fine. I'll change that m=1 pmos/nmos gate cap from 6.85u x 6.85u to 4u x 4u and we'll still have >20MHz at the worst process/voltage/temperature corner. All done.
There are some strange issues here. Each test chip/board has four fuses that can be blown. One of the six boards has one fuse that won't blow. That's one out of 24 fuses. Maybe it's just a failure due to a manufacturing defect. I'm concerned, though, because as I was monitoring blow current via a 1-ohm shunt resistor between FPGA-board GND and test board GND, I saw some inconsistencies. I only witnessed blow current on three fuses. One blew in about 700us, one blew in about 10us, and one never blew. This makes me nervous.
We are going to see if On-Semi has any pointers on how fuses should be implemented. All we had was a set of fuse layout rules that defined what a fuse looks like. There was no mention of blow current or blow switches. I just designed something pretty simple that would do the job.
Today I've been having trouble getting pics from my smart phone emailed to my computer. I have some scope pictures of fuses being blown, but I can't get them onto this machine. Anyway, it seems to take ~80mA of current to blow a silicided 180nm-wide by 1.3um-long piece of poly. I need to make a few more test boards so that I can try more fuses. I'm not feeling good about them right now.
This brings up a question: What if we tossed the fuses, as fuse problems could pose a critical risk to the Prop2 even functioning? It would mean no built-in code protection. Would this be a big detriment?
Everything else on the test chip has now been proven to work fine.
There are some strange issues here. Each test chip/board has four fuses that can be blown. One of the six boards has one fuse that won't blow. That's one out of 24 fuses. Maybe it's just a failure due to a manufacturing defect. I'm concerned, though, because as I was monitoring blow current via a 1-ohm shunt resistor between FPGA-board GND and test board GND, I saw some inconsistencies. I only witnessed blow current on three fuses. One blew in about 700us, one blew in about 10us, and one never blew. This makes me nervous.
1-ohm is getting large for a series sense resistor.
Exactly how much current does the one that failed to blow, still draw ?
Maybe it has it sputtered into some no-mans land - Not cleanly open, and also not enough left to draw enough current to fuse any more.. ?
What is the design sense-level - ie what resistance remaining, reads as open ?
Three is a quite small sample size, can you do 2+ more chips, to get > 10 +?
700us & 10us seems a pretty large variation.
We are going to see if On-Semi has any pointers on how fuses should be implemented. All we had was a set of fuse layout rules that defined what a fuse looks like. There was no mention of blow current or blow switches. I just designed something pretty simple that would do the job.
This brings up a question: What if we tossed the fuses, as fuse problems could pose a critical risk to the Prop2 even functioning? It would mean no built-in code protection. Would this be a big detriment?
Do OnSemi still use Fuses ?
An alternative is to talk to OnSemi about OTP cells, before you get to the step of tossing the fuses entirely.
The fuse that never blows takes 80mA for as long as the blow signal is applied. Maybe it did not blow cleanly and is now in some kind of crashed state.
Here is the schematic of the fuse blower and reader:
B = blow, input
R= read, input
Q = state, output
When the fuse blows, it should be in the megohms. It's only being compared to ~860 ohms. The 'rnpolys' resistor is an N+ silicided poly resistor, which is very low-impedance, so that it fries.
I would be very happy to have a P2 without fuses and code protection.
My experience with AVR back in the day had me end up with a pile of unusable chips whose fuses had somehow been blown. No doubt due to the "non-official" tools I was using to program them but still annoying. That is one of the reasons I ended up looking into the Propeller in the first place!
Of course I don't imagine ever building a Propeller into a commercial product, or at least not one that requires "secret sauce".
In short, a Propeller 2 without fuses tomorrow is infinitely preferable to one with fuses in another years time! (Adjust time estimates as need).
Chip,
Please please please ask OnSemi / Treehouse about OTP/Flash/EEPROM. You likely will find a simple and reliable solution which can also be used for the ROM too.
FWIW, there have been many saying security is a prime requirement for P2. BTW it's not a requirement for me although I don't have any commercial P2 products planned.
However, if the ROM was OTP and you could test the P2 without programming any of the P2, then this could be used instead of fuses for security. It would be much simpler, and you could sell programmed OTP without security as the default.
I should have emphasized that I was talking about me personally. I don't see myself working for anyone who needs micro-controller solutions anytime soon. And I don't have any brilliant moneymaking ideas using micro-controllers that would require protected code.
Edit: I do see from time to time the possibility to use a micro-controller, including the Prop, to solve some weird problem clients have. However that would just be a small part of a bigger system and nobody would much care if the code was copied out of there or modified or not. Sadly such ideas have never progressed in recent years.
However, if the ROM was OTP and you could test the P2 without programming any of the P2, then this could be used instead of fuses for security. It would be much simpler, and you could sell programmed OTP without security as the default.
Having OTP won't remove the need for a minimal mask ROM. I could see it not changing the size of the mask ROM at all in fact.
My preference is, as I've said many times, to replace the entire hub's SRAM with the smaller MRAM.
In 2007 I had a six axis motion control engine stuffed into a single cog of the Propeller. Intelligent Motion Systems wanted to market it and developed a board that was going to be part of their product line. When they told me that their main market was China, I realized that at best, a few hundred of these boards would be sold before the design would be pirated, and that would be the end of any royalties.
Knowing that the Prop II was in development and “Only a couple of years out”... I elected to hold off until the new, code protected chip was available.
I won't go over the ups and downs of the P2 development, most of you know it all too well.
The P1, with reserved locations for a second 32 bit port was a strong indicator that there WOULD be follow up versions with at LEAST this feature in the new version. Code protection is such an obvious need that OF COURSE a version with protection would be coming along before too long.
Here we are nine years later.
Of course I was foolish to keep waiting for a processor next year, next year, next year, next year. Of course I should have used another AVAILABLE processor long ago... but the P1 was such a wonderful design... and the P2 is just a few months away.... and... well, you know.
( yes, my design has long since been left in the dust by others more sensible than me.)
No, I don't blame Parallax or Chip Gracy. The fault for misplaced faith is entirely mine. I do believe that Chip has done his best to bring the P2 to reality, but to hear that the P2 will not have the promised code protection just makes my heart sick.
NO, I don't believe my single need should keep an UN-protected P2 from being produced. There are too many others who will be able to use/play with it. If that's what it takes to get SOMETHING on the market soon, then do it that way, but for Gods sake... once done, please don't go off on a ten year P3 chase before you turn out a chip that lives up to the original promises that fools like me have waited for.
I've stopped doing new designs for the Prop. I'm using Pics for some things and even the Arduino Nano for the prototype of some new consumer products. ( the analog is nice ). If I need more horsepower I'll use an Arm, Pi, etc. I would GLADLY be using a single/reduced cog P2 for some of these designs, protected or otherwise, but unless Parallax makes a firm commitment to flesh out its product line with chips that engineers can actually embed into products with confidence and security, Parallax, and engineers wanting to be faithful to its products, will never have the market share that coulda/woulda/shoulda been so long ago.
About a day ago, when the jitter issue was causing concern, I had a gut feeling that Chip was on the verge of a breakthough. Though it'll seem odd to some, I even took a moment to pray that Chip would see the light. While I by no means claim to be that righteous man whose prayers availeth much, I figured it didn't hurt to ask (as I believe in things outside of myself). The next time I logged on, the issue had been resolved. Of course, such progress was pretty predictable based on the fact that Chip has had at least a few such breakthroughs after seemingly getting bogged down. So, I'm sure that such progress was way more a result of Chip's work ethic and talent than anything external. And I sure wouldn't be comfortable if the P2's success depended on anyone's prayers (or lack thereof). But, at the very least, I guess that I have faith in Chip's methodical and resolute approach.
Having said all that, I think that there's something to be said for gut feelings because, for example, our subconscious might be trying to tell us something important that our conscious mind has brushed off or failed to pick up on. And I have to say that I've had a GUT FEELING for about two or three years that the fuses and encryption would be the death of the P2. It wouldn't take that much in the way of a fab failure or whatever to derail the P2 to such an extent that it never really got off the ground. But please keep in mind that my gut feeling is NOT based on any chip-design knowledge or experience. Maybe I'm just being superstitious. More likely, I'm just being selfish, as I likely fear the risk that certain features (like encryption) entail that could stop or delay me from getting my hands on the chip. And I figure that all the encryption stuff has already added at least two, maybe three months to the design effort. Anyway, a gut feeling is a gut feeling, and now seeing that even the chip designer himself has some doubts only confirms to me that this subject is something worth considering; that is, whether to take the risk or not of including encryption in the first P2. I for one don't know the answer.
Obviously, this can be argued from both sides. For example, if the chip offers encryption, it will likely be much more successful with higher-volume customers, which could go a long ways towards ensuring the chip's availability and success for the rest of us that may not need encryption as much. I would guess that Ken would be worth consulting on whether the first (possibly only) P2 out the door needs encryption, or if maybe that could be targeted for down the road (with such intention being announced in advance so companies could plan accordingly).
Speaking of gut feelings, I think it's too easy to fall in love with the idea of having a whole family of chips just for the sake of having a whole family of chips, even though the smaller siblings will be significantly degraded in terms of potential. For example, is a dual-cog Propeller really a Propeller? But I could sure see a family existing for the full-featured chip: one with encryption, one without, and perhaps even one without smart pins. Yeah, that last one will come as a surprise, but if such omission allowed for going to a full meg of hub ram, it might be just the ticket for some applications. Actually, I used to worry about the added risk that the smart pins entailed, but Chip seems to have nailed down their design and the smart pins are bound to be of comparable importance to the multiple cogs. But not every app will need them (or at least not all of their power), hence the suggestion that a dumb pin or semi-smart pin version might be a legitimate candidate as a family member.
Anyway, those are just some thoughts. And in the time that it's taken me to compose this post, Chip's concerns over the fuses may have abated and/or he may have resolved a related problem that puts them back on track. If so, then so be it. But this has been my 2 1/2 cents FWIW.
Update: Gee, I wish I had started my post after reading Kbash's post, as he makes many good points (and provides an interesting history). I, too, hope that Parallax can flesh out the P2 infrastructure in timely fashion. And I certainly wouldn't be opposed to a reduced-cog, smaller and cheaper variant that allowed designers to use some (not all) of the design patterns that they might be familiar with from working with the full version. But, for now, Parallax seems to have its hands more than full, as there are software tools still to be done. It's no wonder that Chip is itching to finalize the hardware (and itchiness is a sign of healing).
Chip - for what it's worth I worked at a large company which implemented fuses in most chips. They had at least two fuses per bit for redundancy due to them not being reliable, and then error detection/correction was applied. Maybe something to think about?
I don't have experience because I never worked with them since they weren't a good fit for our designs due to some requirements that they imposed. But the default was for every chip to have them. Manufacturing liked it for RMAs because they would know the history of each serialized chip. (Which tester was used, which test program,...)
The fuse that never blows takes 80mA for as long as the blow signal is applied. Maybe it did not blow cleanly and is now in some kind of crashed state.
Here is the schematic of the fuse blower and reader:
When the fuse blows, it should be in the megohms. It's only being compared to ~860 ohms. The 'rnpolys' resistor is an N+ silicided poly resistor, which is very low-impedance, so that it fries.
What is the P-FET RDs and the Fuse R ? (is it 55.54 ohms nominal as labeled ?)
80mA maps to values like this ( % Loss assumed across PFET)
10% -> 37.125 ohms
20% -> 33 ohms
30% -> 28.875
40% -> 16.5
so maybe this N+ silicided poly resistor has a fuse-physics that includes dropping in Resistance as it cooks, before it finally opens ?
Captured current curves may show that effect ?
What can the P-FET drive into a short ?
Three is a quite small sample size, can you do 2+ more chips, to get > 10 +?
700us & 10us seems a pretty large variation.
Thought about this some more, and I think more measurements are needed. 70:1 is a big change.
Measurement Suggestions:
* Measure the initial Resistance of the Fuse and PFet, which should be possible in that circuit.
* Take 10 or even 20 chips, and test 50% at Vcc min and 50% at Vcc max
* Capture the Current-time curve for every fuse, and look for column correlations.
Chip - for what it's worth I worked at a large company which implemented fuses in most chips. They had at least two fuses per bit for redundancy due to them not being reliable, and then error detection/correction was applied. Maybe something to think about?
Do you recall any numbers for failure rates, and what design of fuse they used ?
Does 'at least 2' mean sometimes they have 3 or 4 ? ERC implies more redundant fuses ..?
Please please please ask OnSemi / Treehouse about OTP/Flash/EEPROM. You likely will find a simple and reliable solution which can also be used for the ROM too.
Agreed, they should have available multiple proven cells for OTP, with a selection of sizes and pgm features.
Depending on the OTP cell sizes and designs, it might also be used for the ROM.
However, if the ROM was OTP and you could test the P2 without programming any of the P2, then this could be used instead of fuses for security. It would be much simpler, and you could sell programmed OTP without security as the default.
Not quite following that ?
Right now, P2 cannot be tested before it is loaded, and that requires a programmed ROM.
This means one overhead of OTP-ROM, is adding a means to first load the ROM code, which means ICP pins.
These handling issues mean there are really two questions to map out, that may point to different OTP Cells.
a) OTP to replace fuses only.
b) OTP to replace both fuses and ROM
Chip - for what it's worth I worked at a large company which implemented fuses in most chips. They had at least two fuses per bit for redundancy due to them not being reliable, and then error detection/correction was applied. Maybe something to think about?
Do you recall any numbers for failure rates, and what design of fuse they used ?
Does 'at least 2' mean sometimes they have 3 or 4 ? ERC implies more redundant fuses ..?
Unfortunately I never used them, so don't recall many details. I remember that the ERC wasn't actually part of the fuse IP, it had to be implemented by the user. So that was additional fuses. I was surprised that it wasn't neatly packaged up. Some assembly required, batteries not included. I guess my main point it that the fuses at a major semi company were unreliable, so it's not entirely unexpected. These were smaller geometries though - 40 nm and below.
What if you make it so that when you initially send the command to burn the fuses, the response will specify which ones actually blew? Then, you can try to burn some fuses, see which ones actually blew, and then use that for the key. Obviously, this can only be done once, i.e. if no fuses were blown on boot.
The only disadvantage of this would be that every unit might need a different key.
Comments
Great news, what numbers do you get now on those jitter tests ?
Should be closer to the Quanta column I posted ?
good idea.
That's 200 cycles out from trigger on the 20MHz RC oscillator. I set 'persist' mode and let it run for about 10 seconds. It only varied by ~8ns. 8ns/10us is less than 0.1% variance. This will work fine. I'll change that m=1 pmos/nmos gate cap from 6.85u x 6.85u to 4u x 4u and we'll still have >20MHz at the worst process/voltage/temperature corner. All done.
There are some strange issues here. Each test chip/board has four fuses that can be blown. One of the six boards has one fuse that won't blow. That's one out of 24 fuses. Maybe it's just a failure due to a manufacturing defect. I'm concerned, though, because as I was monitoring blow current via a 1-ohm shunt resistor between FPGA-board GND and test board GND, I saw some inconsistencies. I only witnessed blow current on three fuses. One blew in about 700us, one blew in about 10us, and one never blew. This makes me nervous.
We are going to see if On-Semi has any pointers on how fuses should be implemented. All we had was a set of fuse layout rules that defined what a fuse looks like. There was no mention of blow current or blow switches. I just designed something pretty simple that would do the job.
Today I've been having trouble getting pics from my smart phone emailed to my computer. I have some scope pictures of fuses being blown, but I can't get them onto this machine. Anyway, it seems to take ~80mA of current to blow a silicided 180nm-wide by 1.3um-long piece of poly. I need to make a few more test boards so that I can try more fuses. I'm not feeling good about them right now.
This brings up a question: What if we tossed the fuses, as fuse problems could pose a critical risk to the Prop2 even functioning? It would mean no built-in code protection. Would this be a big detriment?
Everything else on the test chip has now been proven to work fine.
1-ohm is getting large for a series sense resistor.
Exactly how much current does the one that failed to blow, still draw ?
Maybe it has it sputtered into some no-mans land - Not cleanly open, and also not enough left to draw enough current to fuse any more.. ?
What is the design sense-level - ie what resistance remaining, reads as open ?
Three is a quite small sample size, can you do 2+ more chips, to get > 10 +?
700us & 10us seems a pretty large variation.
Do OnSemi still use Fuses ?
An alternative is to talk to OnSemi about OTP cells, before you get to the step of tossing the fuses entirely.
Here is the schematic of the fuse blower and reader:
B = blow, input
R= read, input
Q = state, output
When the fuse blows, it should be in the megohms. It's only being compared to ~860 ohms. The 'rnpolys' resistor is an N+ silicided poly resistor, which is very low-impedance, so that it fries.
My experience with AVR back in the day had me end up with a pile of unusable chips whose fuses had somehow been blown. No doubt due to the "non-official" tools I was using to program them but still annoying. That is one of the reasons I ended up looking into the Propeller in the first place!
Of course I don't imagine ever building a Propeller into a commercial product, or at least not one that requires "secret sauce".
In short, a Propeller 2 without fuses tomorrow is infinitely preferable to one with fuses in another years time! (Adjust time estimates as need).
I would not want to see this derailed over the fuses.
And, as mentioned, other options can be considered and tested in parallel with people using the P2.
It's extremely likely that will happen anyway.
Go with no code protect, then kick off a project to resolve code protect however it ends up making sense. That's my vote.
If a fused and fuseless Prop were available tomorrow I'd be ordering the fuseless one.
Fuses make me uneasy, too. Personally, I'd rather not have them. People have been asking for code protection since Prop1, though.
It's easy for people to ask for all kind of features. How serious are they actually?
Hmmm, I constantly fantasize about commercial products based on the Prop. Why not?
Please please please ask OnSemi / Treehouse about OTP/Flash/EEPROM. You likely will find a simple and reliable solution which can also be used for the ROM too.
FWIW, there have been many saying security is a prime requirement for P2. BTW it's not a requirement for me although I don't have any commercial P2 products planned.
However, if the ROM was OTP and you could test the P2 without programming any of the P2, then this could be used instead of fuses for security. It would be much simpler, and you could sell programmed OTP without security as the default.
No reason why not.
I should have emphasized that I was talking about me personally. I don't see myself working for anyone who needs micro-controller solutions anytime soon. And I don't have any brilliant moneymaking ideas using micro-controllers that would require protected code.
Edit: I do see from time to time the possibility to use a micro-controller, including the Prop, to solve some weird problem clients have. However that would just be a small part of a bigger system and nobody would much care if the code was copied out of there or modified or not. Sadly such ideas have never progressed in recent years.
Having OTP won't remove the need for a minimal mask ROM. I could see it not changing the size of the mask ROM at all in fact.
My preference is, as I've said many times, to replace the entire hub's SRAM with the smaller MRAM.
Knowing that the Prop II was in development and “Only a couple of years out”... I elected to hold off until the new, code protected chip was available.
I won't go over the ups and downs of the P2 development, most of you know it all too well.
The P1, with reserved locations for a second 32 bit port was a strong indicator that there WOULD be follow up versions with at LEAST this feature in the new version. Code protection is such an obvious need that OF COURSE a version with protection would be coming along before too long.
Here we are nine years later.
Of course I was foolish to keep waiting for a processor next year, next year, next year, next year. Of course I should have used another AVAILABLE processor long ago... but the P1 was such a wonderful design... and the P2 is just a few months away.... and... well, you know.
( yes, my design has long since been left in the dust by others more sensible than me.)
No, I don't blame Parallax or Chip Gracy. The fault for misplaced faith is entirely mine. I do believe that Chip has done his best to bring the P2 to reality, but to hear that the P2 will not have the promised code protection just makes my heart sick.
NO, I don't believe my single need should keep an UN-protected P2 from being produced. There are too many others who will be able to use/play with it. If that's what it takes to get SOMETHING on the market soon, then do it that way, but for Gods sake... once done, please don't go off on a ten year P3 chase before you turn out a chip that lives up to the original promises that fools like me have waited for.
I've stopped doing new designs for the Prop. I'm using Pics for some things and even the Arduino Nano for the prototype of some new consumer products. ( the analog is nice ). If I need more horsepower I'll use an Arm, Pi, etc. I would GLADLY be using a single/reduced cog P2 for some of these designs, protected or otherwise, but unless Parallax makes a firm commitment to flesh out its product line with chips that engineers can actually embed into products with confidence and security, Parallax, and engineers wanting to be faithful to its products, will never have the market share that coulda/woulda/shoulda been so long ago.
About a day ago, when the jitter issue was causing concern, I had a gut feeling that Chip was on the verge of a breakthough. Though it'll seem odd to some, I even took a moment to pray that Chip would see the light. While I by no means claim to be that righteous man whose prayers availeth much, I figured it didn't hurt to ask (as I believe in things outside of myself). The next time I logged on, the issue had been resolved. Of course, such progress was pretty predictable based on the fact that Chip has had at least a few such breakthroughs after seemingly getting bogged down. So, I'm sure that such progress was way more a result of Chip's work ethic and talent than anything external. And I sure wouldn't be comfortable if the P2's success depended on anyone's prayers (or lack thereof). But, at the very least, I guess that I have faith in Chip's methodical and resolute approach.
Having said all that, I think that there's something to be said for gut feelings because, for example, our subconscious might be trying to tell us something important that our conscious mind has brushed off or failed to pick up on. And I have to say that I've had a GUT FEELING for about two or three years that the fuses and encryption would be the death of the P2. It wouldn't take that much in the way of a fab failure or whatever to derail the P2 to such an extent that it never really got off the ground. But please keep in mind that my gut feeling is NOT based on any chip-design knowledge or experience. Maybe I'm just being superstitious. More likely, I'm just being selfish, as I likely fear the risk that certain features (like encryption) entail that could stop or delay me from getting my hands on the chip. And I figure that all the encryption stuff has already added at least two, maybe three months to the design effort. Anyway, a gut feeling is a gut feeling, and now seeing that even the chip designer himself has some doubts only confirms to me that this subject is something worth considering; that is, whether to take the risk or not of including encryption in the first P2. I for one don't know the answer.
Obviously, this can be argued from both sides. For example, if the chip offers encryption, it will likely be much more successful with higher-volume customers, which could go a long ways towards ensuring the chip's availability and success for the rest of us that may not need encryption as much. I would guess that Ken would be worth consulting on whether the first (possibly only) P2 out the door needs encryption, or if maybe that could be targeted for down the road (with such intention being announced in advance so companies could plan accordingly).
Speaking of gut feelings, I think it's too easy to fall in love with the idea of having a whole family of chips just for the sake of having a whole family of chips, even though the smaller siblings will be significantly degraded in terms of potential. For example, is a dual-cog Propeller really a Propeller? But I could sure see a family existing for the full-featured chip: one with encryption, one without, and perhaps even one without smart pins. Yeah, that last one will come as a surprise, but if such omission allowed for going to a full meg of hub ram, it might be just the ticket for some applications. Actually, I used to worry about the added risk that the smart pins entailed, but Chip seems to have nailed down their design and the smart pins are bound to be of comparable importance to the multiple cogs. But not every app will need them (or at least not all of their power), hence the suggestion that a dumb pin or semi-smart pin version might be a legitimate candidate as a family member.
Anyway, those are just some thoughts. And in the time that it's taken me to compose this post, Chip's concerns over the fuses may have abated and/or he may have resolved a related problem that puts them back on track. If so, then so be it. But this has been my 2 1/2 cents FWIW.
Update: Gee, I wish I had started my post after reading Kbash's post, as he makes many good points (and provides an interesting history). I, too, hope that Parallax can flesh out the P2 infrastructure in timely fashion. And I certainly wouldn't be opposed to a reduced-cog, smaller and cheaper variant that allowed designers to use some (not all) of the design patterns that they might be familiar with from working with the full version. But, for now, Parallax seems to have its hands more than full, as there are software tools still to be done. It's no wonder that Chip is itching to finalize the hardware (and itchiness is a sign of healing).
I don't have experience because I never worked with them since they weren't a good fit for our designs due to some requirements that they imposed. But the default was for every chip to have them. Manufacturing liked it for RMAs because they would know the history of each serialized chip. (Which tester was used, which test program,...)
80mA maps to values like this ( % Loss assumed across PFET)
10% -> 37.125 ohms
20% -> 33 ohms
30% -> 28.875
40% -> 16.5
so maybe this N+ silicided poly resistor has a fuse-physics that includes dropping in Resistance as it cooks, before it finally opens ?
Captured current curves may show that effect ?
What can the P-FET drive into a short ?
They seem less likely to blow unintended, than to not blow at all ?
(I'm excluding a user fumble here, just looking at silicon failure modes)
I would not panic just yet, but take more measurements. Present sample size is too small.
Dual fuses seems a good idea, for example.
Also, why not use a N-FET which can drive higher, with less area ?
Thought about this some more, and I think more measurements are needed. 70:1 is a big change.
Measurement Suggestions:
* Measure the initial Resistance of the Fuse and PFet, which should be possible in that circuit.
* Take 10 or even 20 chips, and test 50% at Vcc min and 50% at Vcc max
* Capture the Current-time curve for every fuse, and look for column correlations.
Does 'at least 2' mean sometimes they have 3 or 4 ? ERC implies more redundant fuses ..?
Agreed, they should have available multiple proven cells for OTP, with a selection of sizes and pgm features.
Depending on the OTP cell sizes and designs, it might also be used for the ROM.
Not quite following that ?
Right now, P2 cannot be tested before it is loaded, and that requires a programmed ROM.
This means one overhead of OTP-ROM, is adding a means to first load the ROM code, which means ICP pins.
These handling issues mean there are really two questions to map out, that may point to different OTP Cells.
a) OTP to replace fuses only.
b) OTP to replace both fuses and ROM
Unfortunately I never used them, so don't recall many details. I remember that the ERC wasn't actually part of the fuse IP, it had to be implemented by the user. So that was additional fuses. I was surprised that it wasn't neatly packaged up. Some assembly required, batteries not included. I guess my main point it that the fuses at a major semi company were unreliable, so it's not entirely unexpected. These were smaller geometries though - 40 nm and below.
The only disadvantage of this would be that every unit might need a different key.