I was working on this from Chip 'The test chip shuttle is scheduled for September 15th."
- but you may be right, as I now see that does not say packaged and delivered to Parallax
On July 6 Chip said 4 weeks to go into the shuttle run and then 10 weeks after. So it actually ended up being 10 weeks to go into the shuttle run. And then it's another 10 weeks to get the chip back? So that would make it November 24.
If the schematic isn't changing presumably there are still bespoke fuses in the pin pads, but I gather the mask rom code will ignore their state
The test chip due in a few days has a full set of fuses, so it can be used to get a real fuse curve histogram of Vcc/blow %.
If the tests show the fuses work fine ( good yields ), but need some special Vcc that is outside easy field use, they can still be usefully use to factory store a Serial Number, and oscillator measured-values.
If I am not wrong the previous chip had (perhaps) the full ring of pins made in but not connected to outer pins. All the sorrounding pins was used to operate only 2 real pins because there was no logic inside and all the comms for pin testin was made on "parallel bus" connected all around the test chip.
So where does this leave things? If the schematic isn't changing presumably there are still bespoke fuses in the pin pads, but I gather the mask rom code will ignore their state
I am not sure about the fate of the fuses. I want to hear if the foundry will let us narrow them to 120nm. That would be quite the unusual sign-off.
Did you build some redundancy into the fuses? That might help make your case. Worst case what would happen if a device came back with random #'s of fuses effectively blown due to yield issues? Could you end up with code protection accidentally enabled with an unknown key and thus a bricked part?
I am not sure about the fate of the fuses. I want to hear if the foundry will let us narrow them to 120nm. That would be quite the unusual sign-off.
Did you build some redundancy into the fuses? That might help make your case. Worst case what would happen if a device came back with random #'s of fuses effectively blown due to yield issues? Could you end up with code protection accidentally enabled with an unknown key and thus a bricked part?
Since the fuse programming/blowing process could be interrupted or fail by many reasons, including hard or even impossible to be blown ones; accidental blowing unintended/wrong ones and even power outages, at least one of the 256 should be ellected as the master validator one.
This is not meant to be interpreted as a harware enforced resource, but one that software could rely on.
Only after the whole programming/burning and read verifying could be confirmed as complete, the master validator should then be programmed and verifyed.
IMHO, this is one of the possible approaches, if not the best, to avoid device bricking.
Evidently, if the master validator fuse itself fails to blow then there are at least two options:
- Destinate another fuse, in the sequency, as an alternate to the master, and thus, at least one of them must be confirmed as blown, in order to consider the whole security as functional;
- In cases where both fuses are reluctant to be blown, consider the affected device as an unsecureable one and reserve it to be used for internal test/development purposes (perhaps laser marking/color strip painting into a high volume production line). Either way, something as a "Non-fatal error - Unsecurable device" case.
obvious question time, instead of a less wide (thinner) fuse why not change its length?
If it is too long, sufficient heat won't develop anywhere to blow it, requiring higher voltage. If it is too short, heat would wick to the ends and they would act as thermal dampers, requiring more current to blow it. The ideal length/width ratio seems to be around 8, from all the papers I've seen.
This 8:1 ratio might also insure sufficient geometry to gracefully accommodate whatever changes, be it melted or electro-migrated silicide.
If there is another analogue test shuttle in the future then maybe filling the empty silicon with an array of experimental fuses, to empirically find workable parameters, would be an option.
Many blowing fuse images. Also some blowing current meassurement screenshots.
Text search indicates that the samples were made under 50 and 100nm design rules, but its only a guess, based on the understandable characters present in the text.
It also has unprogrammed, under-programmed, optimally, and overprogrammed fuse images.
Solely by the pictures it contains, worths taking a look!
Each picture has its own explanatory text (in english).
Perhaps some forum member could translate it from korean language or has acces to it, thru the many academic/technical networks (perhaps IEEE Xplore or Arvix).
Many blowing fuse images. Also some blowing current meassurement screenshots.
Again.... worths looking at.
Some good plots there.
The Fig 8 shows 99%, Median and 1% profiles, and shows current range, vs fuse resistance. - unclear here if there is any special pulse width, or only current varies ?
If it is only current, the 1% worst fuses 'sweet spot' is not large in % terms, maybe 10.5 ~ 12.75mA
- but Fig 6 shows time durations, and suggests some ideal time-width, but currents differ so it is unclear if those are the same test fuses.
The images do also suggest an ideal fuse energy, as the 'over splatted' ones do look over-done.
Fig 5a hints at a some fuse-break-voltage, on a ramping Vcc, but Fig 6 has less step in the current profile ?
Comments
Did you build some redundancy into the fuses? That might help make your case. Worst case what would happen if a device came back with random #'s of fuses effectively blown due to yield issues? Could you end up with code protection accidentally enabled with an unknown key and thus a bricked part?
Since the fuse programming/blowing process could be interrupted or fail by many reasons, including hard or even impossible to be blown ones; accidental blowing unintended/wrong ones and even power outages, at least one of the 256 should be ellected as the master validator one.
This is not meant to be interpreted as a harware enforced resource, but one that software could rely on.
Only after the whole programming/burning and read verifying could be confirmed as complete, the master validator should then be programmed and verifyed.
IMHO, this is one of the possible approaches, if not the best, to avoid device bricking.
Evidently, if the master validator fuse itself fails to blow then there are at least two options:
- Destinate another fuse, in the sequency, as an alternate to the master, and thus, at least one of them must be confirmed as blown, in order to consider the whole security as functional;
- In cases where both fuses are reluctant to be blown, consider the affected device as an unsecureable one and reserve it to be used for internal test/development purposes (perhaps laser marking/color strip painting into a high volume production line). Either way, something as a "Non-fatal error - Unsecurable device" case.
obvious question time, instead of a less wide (thinner) fuse why not change its length?
If it is too long, sufficient heat won't develop anywhere to blow it, requiring higher voltage. If it is too short, heat would wick to the ends and they would act as thermal dampers, requiring more current to blow it. The ideal length/width ratio seems to be around 8, from all the papers I've seen.
This 8:1 ratio might also insure sufficient geometry to gracefully accommodate whatever changes, be it melted or electro-migrated silicide.
Many blowing fuse images. Also some blowing current meassurement screenshots.
Text search indicates that the samples were made under 50 and 100nm design rules, but its only a guess, based on the understandable characters present in the text.
It also has unprogrammed, under-programmed, optimally, and overprogrammed fuse images.
Solely by the pictures it contains, worths taking a look!
Each picture has its own explanatory text (in english).
Perhaps some forum member could translate it from korean language or has acces to it, thru the many academic/technical networks (perhaps IEEE Xplore or Arvix).
Again.... worths looking at.
ocean.kisti.re.kr/downfile/volume/ishm/MOKRBW/2012/v19n3/MOKRBW_2012_v19n3_21.pdf
Henrique
The Fig 8 shows 99%, Median and 1% profiles, and shows current range, vs fuse resistance. - unclear here if there is any special pulse width, or only current varies ?
If it is only current, the 1% worst fuses 'sweet spot' is not large in % terms, maybe 10.5 ~ 12.75mA
- but Fig 6 shows time durations, and suggests some ideal time-width, but currents differ so it is unclear if those are the same test fuses.
The images do also suggest an ideal fuse energy, as the 'over splatted' ones do look over-done.
Fig 5a hints at a some fuse-break-voltage, on a ramping Vcc, but Fig 6 has less step in the current profile ?