Prop 2 Fuse conundrum - Vpp ?!
jmg
Posts: 15,173
in Propeller 2
From the other thread... thinking some more, on how designers will use P2 in volume production cases :
Thinking more on this, and how designers might use P2 in systems, the presence of a Vpp pin is less than ideal, but Chip is actually saying something much worse : "briefly drive higher voltage into the VIO of the 4-pin bank whose 16 fuses are being blown"
That means every VIO is a Vpp(over voltage) pin, and this has serious design impacts: Much of what P2 connects to, will not be 5V tolerant.
If they cannot tolerate 5V, they cannot modulate Vpp - it is a drop dead ISP problem.
This forces users into a ZIF socket, and pre-insertion programming & handling. (*ugh*)
That's a rather serious and unexpected bump in P2 deployment, seems the choices from here are to
a) Shift the Fuse supply to a single, Vpp pin, so every VIO pin does not have to 5V spike.
b) Change to an OnSemi OTP/MTP cell, for the Fuses, that does not need Vpp-Pin at all.
In 2017+, users certainly will expect MTP and no Vpp-Pin.
...
I've asked OnSemi for more fuse info, but not much has come back. So, the fuses remain the same. They are supposed to be blown at 5V,, I just learned, but we are set up for 3.3V. I had one stubborn fuse in the last test batch. Worst case, we must build a special programmer to briefly drive higher voltage into the VIO of the 4-pin bank whose 16 fuses are being blown. That sounds crazy, I know, but how else to get 5V at 35mA? We could come up with a programmable power supply circuit for common board use that normally outputs 3.3V, but can jump up briefly to 5V for the fuse blow. That would need one I/O pin and be under software control. The blow time is under 1ms.
There are quite a few parts with Vpp pins, (both Flash and OTP) in volume production today. It is just less visible than on the 2764.Brian Fairchild wrote:" cgracey : Worst case, we must build a special programmer to briefly drive higher voltage into the VIO of the 4-pin bank whose 16 fuses are being blown."
How wonderfully last century. I don't think I've used a chip that needed a special voltage to program it since the days of the 2764.
Thinking more on this, and how designers might use P2 in systems, the presence of a Vpp pin is less than ideal, but Chip is actually saying something much worse : "briefly drive higher voltage into the VIO of the 4-pin bank whose 16 fuses are being blown"
That means every VIO is a Vpp(over voltage) pin, and this has serious design impacts: Much of what P2 connects to, will not be 5V tolerant.
If they cannot tolerate 5V, they cannot modulate Vpp - it is a drop dead ISP problem.
This forces users into a ZIF socket, and pre-insertion programming & handling. (*ugh*)
That's a rather serious and unexpected bump in P2 deployment, seems the choices from here are to
a) Shift the Fuse supply to a single, Vpp pin, so every VIO pin does not have to 5V spike.
b) Change to an OnSemi OTP/MTP cell, for the Fuses, that does not need Vpp-Pin at all.
In 2017+, users certainly will expect MTP and no Vpp-Pin.
Comments
I read the post but did not make the connection (pun intended).
This is scary. Not sure how you want to use a ZIF-socket for the current planned packaging of the P2 to burn them before placing and soldering.
really bad.
Mike
Actually, the news gets worse...
I've looked for TQFP100 ZIF sockets, and yes, those do exist.
Problem is P2 is not just TQFP100, it is EPAD TQFP100 and GND is only via EPAD, so > 100 connections are needed.
I've not yet found an EPAD TQFP100 ZIF socket, but maybe you could hand-craft one from a TQFP100 and multiple spring pins on the EPAD area .. ?
Sorry Chip, but it's insane that you haven't even asked. You are about to do another expensive shuttle run and just now you discover these problems. Why weren't they discovered on the last shuttle???
Are these "fuses" similar in purpose to Microchip's config parameters used at the top of every program?
Just a little concerned...
Hal
Fuses are one time programmable bits. Once written to a P2 they can not be changed and can be hidden from the running software.
The basic idea here is code protection, but some of the fuses are supposed to be able to be used by your own software, to put in some serial numbers or whatever.
They are called fuses, because they kind of get burned away, so no recovery or reset to old state is possible.
The basic security aspect of the P2 (witch seems to be important for some customers) is that the ROM boot loader in the P2 can be set to just accept a program if it is encrypted with sha256 and the corresponding 256bit key is programmed/burned into the fuses.
if you have a key 0 in your encryption-key fuses it will accept any program, but if a key is set, the program to load has to be encrypted with that key or it will not run.
As far as I recollect there are 256 bits for the SHA-key and some (also256?) to be used for other purposes, like serial numbers, or so.
The problem now seems to be that them fuses need a higher voltage to be set/burned as the normal operation voltage of the P2. By now P2 needs already 2 supply Voltages, 1.8 Volts for the core and 3.6 for the I/O pins.
If we need a third voltage of 5V to burn the fuses, as it seems to be, we are in big trouble, because then things connected to 3.6 Volt P2 pins would need to sustain a Voltage of 5V while the fuses get burned. Not nice.
Or you would have to burn them fuses before you solder the chip on your board. Not nice either.
Mike
P2 DOCS say this about fuses :
256 programmable fuses for code security and user application
* First 128 are used for SHA-256/HMAC loader signature verification
* Next 127 can be used for AES-128 main code decryption or user application
* Last 1 write-protects the rest
Fuses can be hidden before user code executes
Other vendors use fuses to define Boot Sources, Default Pin States, Oscillator Sources, and device security.
P2 fuses are OTP, so currently are used for security and user-applications.
I am pretty sure Chip did ask them about flash and replied in one of these threads about it. If I recall right it would require a different process and lots of money.
Did someone read the following document, from OnSemi, about available ONC18 process options?
Aparently, ONC18 G/MS has all the options to satisfy P2 needs, including 5V tolerant I/O, high voltage/low Rsp PLDMOS devices (to burn the fuses) and even OTP (Sidense IP; 1kb and 128kb instances).
I've had also linked it to my post about fuses, at the other thread.
Henrique
https://onsemi.com/pub/Collateral/ONC18GMS-D.PDF
This means every P2 will have a unique key, but cryptography says this should be done anyway - otherwise, if every P2 in a given product had the same key, all it would take to crack the code protection would be for one sufficiently determined cracker with access to the appropriate expensive machinery to determine the state of the fuses via silicon surgery and distribute his results.
This suggestion, of course, would only work if half-blown fuses are reliable.
hehe, I like the Russian-sounding nature of this solution
I'm not sure a software based protection decision, is very robust ?
Seems we are there with the fuses now.
Chip found out after manually laying out the Dual Port RAM that OnSemi had a library of RAMs. Lots of wasted money and effort IMHO because questions hadn't been asked.
OnSemi make EEPROM (24C512) and FLASH. I am sure they make micros with Flash too.
Maybe they have a library, maybe they don't. Surely it's worth asking. Would also solve the fuse problem.
If the fuse problem ends up being as Chip now suggests, might as well delete them, because the P2 will be a joke if it required a higher voltage to program, and cannot be done in circuit.
If I understood it right, including the many discussions had when P2 analog test chip arrived, one of the many design goals of burying the fuses under the pad metal was to difficult any reverse engeneering efforts to read them.
Any way, if this was the design goal at the fuse area, and this is causing so much trouble, please do read Sidense explanations about their 1T antifuse IP technology and how it defends itself from reverse engeneering attempts.
If programming voltage/current are concerns, they also have an extra IP for an on-silicon power source, to programm the fuses, without stressing anything. But I must confess that I didn't follow that path too far, them I can't even talk about its programming method nor power requirements.
Try Googling "Sidense oxide rupture OTP 180nm", lots of info about them and their proccess.
Note: I have nothing to do with Sidense nor any other company or enterprise. I'm 100.0000000000000000% Parallax-blooded, by free will choice!
Continuing... If the fuses are causing so much trouble, why don't give them a try, letting everything (actual fuses) where they are and re-routing the individual bit-read lanes to a sample of their 1kbit OTP instances?
Again, please escuse me if I had understood it in an unusual way, as many times things like this has impaired my communication with some (if not all) members of the forum.
Sure i'ts my fault by having 25% brazilian canibal's blood running in my veins, 25% basque, 45% portuguese, 3% french and 2% mixed between spanish and arab (ouch!), but, I swear I don't have any intention to bite no one! (at least consciously, in case of human flesh!)
Henrique
They do have some libraries.
In the PDF linked above, under NON−VOLATILE MEMORY there are 5 lines in the table. ALL show N (None?) in the Added Masks from Base column
A little strangely, not all choices push-right, and some seem to be only one subset process
- eg High Temperature CMOS LogicEE Trim is I4T 45 V/70 V subset only.
In July 2016, MTP shows as R&D in 2 columns (but not base ONC18 G/MS ? )
There is a CMOS LogicEE Trim showing for base ONC18 G/MS, which might be ok for low-count fuse use.
I note their Poly Fuse OTP is limited to higher voltage process, so maybe they already know what Chip discovered, that 3v3 is just a bit light weight for Poly Fuse OTP ?
Actual it can not be your fault, where your heritage comes from. You had no influence on it. and your English is quite good so no need for excuses.
I personally would fear the 25% basque more then the 25% Brazilian canibal's, but that is just me, never been in Brazil, just Portugal and Spain, and as a German I avoided France somehow.
Mike
Can the reset pin be used for that purpose ? If I'm not wrong, it should be tied to Vcc with normal operations, while programming it could be raised to Vpp for the time needed.
It would require a huge amount of metal to get 35mA near 5V all around the pad frame. Each I/O pad has four fuses and a low-Z connecrion to the local VIO. I will see if OnSemi has something like a 256-fuse block. That will be better for future reduced-pin-count versions.
Or, the 3.3V supply could be variable and via a resistor connected to an I/O pin, it could be increased momentarily.
Or, a programming tool could drive 5V briefly into the 3.3V VIO net during fuse programming.
All of this requires careful design of dual supply nets, to avoid OTHER parts being damaged.
BOM goes up, and 2 layer design is getting harder.
P2 suddenly gets a lot more complex, if multiple rails must be used, and some users will simply overlook this, and need PCB respins, or worse, discover nagging failure rates in the field..
The fuses can then pull into one area, close to Vpp ? which makes family support easier than spread around ring.
-Phil
? - Parts often use RSTn as VPP, so Vpp is high which is reset-released ?
Examples:
Microchip/Atmel have Vpp pins.
On most of their new devices, Vpp is optional, and used to over-ride a fuse that make RST an IO pin.
In CPLDs Vpp over-rides the JTAG disable fuse, which releases 4 pins as IO.
Again, here current specs are modest, it is more a high threshold pin, than a power supply.
It is common for parts to not allow Vpp permanently present, as it pushes into the stress region on some.
Other parts with Vpp shipping today :
SiLabs CP210x, OTP, older series. Spec: Voltage on VPP with respect to GND during a programming operation VPP >= 5.75V (VIO > 3.3 V)
The new CP2102N is Flash based, so OTP and Vpp are gone. Much nicer to use, but does not yet cover all CP21xx family
FTDI FT4222H OTP config, Spec : VPP Supply Voltage 6.5±0.25 V
If another part that did not need Vpp was available, we would choose that instead. (NUC505 is on the short list)
However FT4222H does have some nice specs (QuadSPI and fast i2c) that force us to tolerate Vpp, and for most testing we do not need Vpp yet.
I did find this news item related to XMOS OTP, seems they use Sidense OTP cell, mentioned in OnSemi's list
http://www.eetimes.com/document.asp?doc_id=1249417
& this from March 2017 Multi-Time Programming using Sidense 1T-NVM
mentions using multi-pass OTP as MTP (or FTP, Few Times Programmable), and says ..
"The bits are physically encoded by irreversibly breaking down the gate oxide with tiny conductive holes. "
"Field programmability : Multi-time programming of all or part of an embedded memory should easily be done “in the field” without special equipment, either during chip development or when the silicon is already in the final system. This can be done using an integrated charge pump with the OTP, eliminating the need for an external voltage source and an extra power supply pad on the chip."
This could allow Parallax to include an OscCal byte, for example, and Unique ID serial numbers...
Hi jmg
Your suggestion to put all the fuses into a single area, closer to any Vpp pin sounds very good, because, if there are 256 fuses, for example, eight consecutive pins and the their surrounding Vios could be used to concentrate all the signals and current paths needed for fuse programming purposes.
If this could be restricted to a group of pins, whose I/Os where not expected to deal with high frequencies, the extra-long connections, needed to route the proggraming signals into some connector or exposed gold-flashed pad area, would not severely affect the signal integrity that any other device connected to the same pins will see, at the final product.
I'ts a pity we can't go way back up to five decades ago, when we use to have negative-biased diode switches (missing my early organ keyboards harmonic-mixers).
It would be good If we could, during programming, left the exposed GND pad floating and use negative-biasing to insulate the programming region, restricting high-current/voltage paths to a minimum die area...
Henrique
The high current metal 'came for free' with VIO, and the Fuses were spread around the die, because that used spare space for the larger Fuse-set transistors.
Moving these into one area keeps the Vpp metal to a minimum, but would have a impact because the Fuse-set drivers are not 'dropped into gaps' as much, but the plus is they are now freed from IO ring, which allows variant Size P2s.
I would expect only one fuse is 'set' at a time.
Parallax might like to consider one or more GND pins (not just the TAB) if they want to use standard sockets during factory testing ?