If they also don't charge for the mating Ferrari...
as you say, not anywhere near low-cost, or easily available to end users.
TQFP100 with EPAD does not look like a complex retool - there is relatively large space, and room for many redundant pins on the EPAD.
A pin of the correct height may not be a standard product ?
At 3.3V & using the 35mA from before, that's ~ 53% of the power in the fuse, appears across the MOSFET (ignoring dT effects, which are probably significant)
Halving that Rds, increases the power into the fuse area by ~36%, Halve Rds and nudge Vcc to 3.6V, and you have +61.5% more power.
What sample size of failures do you have ? Is the hardest fuse the same location each time ?
Seems it would be worth storage scope capturing the blow current profile, of every single fuse, one at a time, on the samples you have.
The dI/dT on blow could be high ?
Some reasonable delay between Zaps would allow time to cool, to avoid thermal crosstalk effects.
I noticed in the IP notes, they mention ECC so that a single fuse failure does not scrap the part.
At 3.3V & using the 35mA from before, that's ~ 53% of the power in the fuse, appears across the MOSFET (ignoring dT effects, which are probably significant)
Halving that Rds, increases the power into the fuse area by ~36%, Halve Rds and nudge Vcc to 3.6V, and you have +61.5% more power.
What sample size of failures do you have ? Is the hardest fuse the same location each time ?
Seems it would be worth storage scope capturing the blow current profile, of every single fuse, one at a time, on the samples you have.
The dI/dT on blow could be high ?
Some reasonable delay between Zaps would allow time to cool, to avoid thermal crosstalk effects.
I noticed in the IP notes, they mention ECC so that a single fuse failure does not scrap the part.
I've only blown 24 fuses. There were four per test chip and we built six boards with test chips. That was 24 fuses to test. Only one seemed reluctant to blow at 3.3V.
I don't understand the problem with connecting an external power supply. You could have a small molex KK header, or if you can't even spare the expense of a header then two mask free testpads on the pcb that are used for a springloaded set of contacts to provide the voltage will work. It is a one time thing usually at the time of programming. I say who cares if fuse pwr is external. Would there ever be a requirement to blow a fuse while not connected to a computer? Are not most all programming of the P2 done via usb? Why not just use the 5V available from the computer/usb. Flip a switch on the board to select 5v from usb to the pins needing higher voltage for fuse blowing.
Though not limited to the aspect ratio, other fuse geometry-related concerns are shown and discussed.
E. g., the geometry of both cathode and anode regions can (and will) affect the end result, including the a eventual and parcial reconection in a latter time (though the readout circuit you had posted, seems to well address any possibility of a false reading).
Several phenomena seems to be taking place, either simultaneously or in sequence, but the proccess seems to be well described in both papers.
I've also linked the fuse layout and the blowing/readout circuit you have posted at "Prop2 Analog Test Chip Arrived!" for reference purposes.
Thanks, Henrique, for getting all that stuff together. I have a few pdf's on efuses that I based our design on, but these two are new to me. I will read them both.
? I can't remember, but this was probably covered before - why use a P-FET instead of a more efficient N-FET as the main fuse-blow device ?
Seems a N-FET buys more margin, at no die cost ?
I've only blown 24 fuses. There were four per test chip and we built six boards with test chips. That was 24 fuses to test. Only one seemed reluctant to blow at 3.3V.
ECC may be an alternative to higher VPP.
Hmm, a small sample, and not the final full-fuse-set layout tested either - less than ideal, I can see why another test run is planned.
I don't understand the problem with connecting an external power supply. You could have a small molex KK header, or if you can't even spare the expense of a header then two mask free testpads on the pcb that are used for a springloaded set of contacts to provide the voltage will work. It is a one time thing usually at the time of programming. I say who cares if fuse pwr is external. Would there ever be a requirement to blow a fuse while not connected to a computer? Are not most all programming of the P2 done via usb? Why not just use the 5V available from the computer/usb. Flip a switch on the board to select 5v from usb to the pins needing higher voltage for fuse blowing.
You are talking here about Vpp on a dedicated pin (or RSTn), but not on VIO.
Yes, that is certainly more tolerable than spiking every VIO pin, but still less than ideal.
it's me the one that need to thank you, by being sharing so many thoughts and concerns, ideas and brilliant solutions with us all, giving to each one the opportunity to learn and contribute.
Whithout your efforts and dilicence, perhaps I would be raising roots under my brown right foot while I was trying to kick the pileing dust at the backside with the white left one, looking, thru fogged windows, the high passing clouds in the sky, waiting for tomorrow's newspaper.
I feel as an ant among sacred elephants,
and no one tries to smash me, under its feet,
cause their gender is kind, like the ones
who provided this place, our's to share.
I'll keep marching, proudly, in the herd,
cause I feel, I'm as tall and as heavy as they are.
P.S. I'm nor part neither I have anything to do with the Salvation Army!!!
Thanks, Henrique, for getting all that stuff together. I have a few pdf's on efuses that I based our design on, but these two are new to me. I will read them both.
I heard back from OnSemi today and they do have a complete fuse block that contains 128 fuses. We'd need two of them. I'm waiting for the description now.
I heard back from OnSemi today and they do have a complete fuse block that contains 128 fuses. We'd need two of them. I'm waiting for the description now.
I heard back from OnSemi today and they do have a complete fuse block that contains 128 fuses. We'd need two of them. I'm waiting for the description now.
Hi Chip
Theese are good news, for sure.
Yesterday night (brazilian time, GMT-3) I've found another option but I felt asleep before I can post it.
Though not described into the ONC18 G/MS documents I'd posted before, OnSemi does also have another qualified fuse option, besides custom-generated e-fuses or Sidense IP OTP.
It's know as I-Fuse, from Attopsemi Technology, and relyes on a diode-resistor combo to implement the fuse cell.
Described into a OnSemi-hosted panphlet, as being available as part of OnSemi BCD process, so, it's yet to be determined if they would be also available at the same process P2 will be using.
To me the whole lack of co-operation with onsemi is weird.
It's is like they never looked what the general concept of P2 is, and gave inputs as to not reinvent the wheel.
Is $250K chump change to them? that only gets you a few minutes of tech support.
To me the whole lack of co-operation with onsemi is weird.
It's is like they never looked what the general concept of P2 is, and gave inputs as to not reinvent the wheel.
Is $250K chump change to them? that only gets you a few minutes of tech support.
They've been slow on this fuse issue, but they always answer emails. They also let us run our last test chip for free. I'm hoping for that deal, again.
IIRC there may be enough die space left for another 128KB of HUB RAM.
RAM typically uses 6T while I gather FLASH uses 1T. On this basis, putting FLASH on the P2 could have enough die space for 512KB of HUB FLASH. This could fit nicely with the 512KB HUB RAM. Fuses could take a tiny bit of this space, which would be blocked out if security was in operation.
Now I gather that FLASH runs slower than RAM. If it was half the speed, then why not only allow every second cog to access the HUB FLASH?
Most micros these days have FLASH memory as code space, and there are quite a number that have 1MB or more!!! Even some PIC32MX series have 1MB or more together with lots of RAM like up to 512KB.
Just how much extra cost is putting FLASH in the P2? I thought the outer ring pin logic required an extra metal layer or two. Would these do for the additional layer(s) that FLASH requires? If so, then perhaps there is no additional cost at all. OnSemi FLASH should be proven. The egg-beater logic should work equally well with cogs and HUB-EXEC too, even if only half the cogs get access to hub flash.
Personally I would even settle for 8 COGs, or only 8 COGs with HUB access and 8 COGs without any HUB access (by using the shared LUT RAM to the "blind" COGs).
FLASH "should" actually simplify the boot process, speed up the boot process, and give the P2 twice the hub space - 512KB RAM and 512KB FLASH.
The question really needs to be asked of OnSemi and TreeHouse !!!
While, due to process simplicity, a small sequentially loaded OTP bolstering the mask ROM may have it's place. Hub addressable Flash, on the other hand, would definitely be a substantially inferior option to MRAM.
While, due to process simplicity, a small sequentially loaded OTP bolstering the mask ROM may have it's place. Hub addressable Flash, on the other hand, would definitely be a substantially inferior option to MRAM.
This MRAM news had me thinking of you... Completely different process to P2, but still interesting.
Now I gather that FLASH runs slower than RAM. If it was half the speed, then why not only allow every second cog to access the HUB FLASH?
Ugh... What may be possible, would be adding a ready line, and have FLASH access valid every 2nd or 3rd eggbeater fly-around.
Noe that adding extra MUX's to decide RAM/FLASH would slow down RAM speed too...
Of course, once you add "Slow-Memory-Path" support, that also helps XIP memory**, and you are probably smarter to improve External Flash access over shoe-horning in internal flash.
The same Slow Memory usage caveats apply, only now you can attach any size flash to P2, and the RAM speed impact is removed.
Stacked die can also be used, to give low cost, one-package solutions. (see NUC505 below)
Most micros these days have FLASH memory as code space, and there are quite a number that have 1MB or more!!! Even some PIC32MX series have 1MB or more together with lots of RAM like up to 512KB.
Of course, large Micros have continued to get larger, and yes mainstream MCUs have FLASH.
However, an increasing number of MCUs do not have Flash in the main memory plane.
Some examples:
ESP32, ESP8266 - external Boot flash
FTDI's FX900, FT51x - internal boot flash, SRAM execute
XMOS - Small OTP on chip, external FLASH
NUC505 - Stacked die SPI Flash, gives low cost high speed USB MCU + M4 MCU TZxxx series from Toshiba are external boot, on chip FLASH to 1MB TZ1200 has 2.2MB SRAM, in 8.0 × 8.0mm package
ADSP-SC572 ARM+DSP Dual Core, OTP + 384kB+256kB+1MB RAM, HS-USB, 17x17mm package,
** XIP memory has a number of forms :
Simplest is QuadSPI, with DTR (double edge) also expanding.
HyperFLASH is an octal DTR form, broadly similar to 2 x QuadSPI.DTR
Then, there are SRAM choices, which seem to be expanding at ISSI Serial SRAM and Low Pin Count SRAM
and also HyperRAM - good price per bit, but not the easiest to use for random access tasks.
Better XIP support ? :
Maybe the best way to manage this is a Memory-ready bit that can auto-wait whilst a dedicated COG serves up the next byte(s).
As in, one COG can issue a RDLONG outside of on-chip space, and that simply pauses until the co-operating COG has data ready.
The caller code thinks it has easy to use, flat memory space, & the memory-link COG handles the bus-timing/bit-level details, to any mix of off-chip memory.
Better XIP support ? :
Maybe the best way to manage this is a Memory-ready bit that can auto-wait whilst a dedicated COG serves up the next byte(s).
As in, one COG can issue a RDLONG outside of on-chip space, and that simply pauses until the co-operating COG has data ready.
The caller code thinks it has easy to use, flat memory space, & the memory-link COG handles the bus-timing/bit-level details, to any mix of off-chip memory.
And the memory-link COG could also add a level of memory mapping. Then we could run Linux! :-)
While, due to process simplicity, a small sequentially loaded OTP bolstering the mask ROM may have it's place. Hub addressable Flash, on the other hand, would definitely be a substantially inferior option to MRAM.
This MRAM news had me thinking of you... Completely different process to P2, but still interesting.
"Everspin's perpendicular (pMTJ) STT-MRAM" - Hehe, that's quite the number of additional letters in the name.
The same Slow Memory usage caveats apply, only now you can attach any size flash to P2, and the RAM speed impact is removed.
Stacked die can also be used, to give low cost, one-package solutions. (see NUC505 below)
There is one big difference with the Prop2, it needs 16 channels of that to make it fully functional XIP. That's upwards of 960 pins without any power or ground.
The same Slow Memory usage caveats apply, only now you can attach any size flash to P2, and the RAM speed impact is removed.
Stacked die can also be used, to give low cost, one-package solutions. (see NUC505 below)
There is one big difference with the Prop2, it needs 16 channels of that to make it fully functional XIP. That's upwards of 960 pins without any power or ground.
Wow, 60 !? pins a channel, that's some unusual XIP memory you have selected there....
A practical P2 design is unlikely to need 16 channels of XIP - the Multicore parts I've seen with XIP, do not consider it vital to have every core accessing XIP memory, at the same instant.
Most code would load into RAM, then Run, but there are large array cases where it is easier in the tools, if off-chip memory is made simpler to access.
This is the Propeller. XIP implies actual hardware implementation. That hardware is symmetrical on the Propeller.
Says who ?
Other vendors do not tie themselves into the same philosophical knots, they live in a more practical world.
Speed vs reach trade-offs are very common across the MCU/MPU space, close in memory, or registers, are always faster than further away memory.
It is about making the best use of what memories you can get.
XIP is a question customers will ask, because other suppliers can do it.
Even more pressing, is customers can see memory on their PCBs, that they expect to be able to access.
There is clearly just one Loader Flash memory, they do not expect 16 COGs to have simultaneous access to it.
Comments
Take a look at Yamaichi
yeu.com/products/test-solutions/test-sockets/custome-made
They have a custom made line ("custome-made"???).
It's advertised as having contacts at top and bottom sides of IC package (spring-loaded).
I believe it'll not be cheap, but... who knows?
If they last enough to spread the costs along (a thousand; ten thousand?) units tested/programmed...
Henrique
One line they advertise does specifies 50.000+ insertions!
Another one, 500.000+!!!!!!!!
If they also don't charge for the mating Ferrari...
https://yamaichi.de/products/test-solutions/contacting-semiconductor/test-contactors/test-contactors-for-bgacspqfnlgaqfpso.html
Yes, Yamaichi do have nice looking products, but...
as you say, not anywhere near low-cost, or easily available to end users.
TQFP100 with EPAD does not look like a complex retool - there is relatively large space, and room for many redundant pins on the EPAD.
A pin of the correct height may not be a standard product ?
I think about 33 ohms.
Halving that Rds, increases the power into the fuse area by ~36%, Halve Rds and nudge Vcc to 3.6V, and you have +61.5% more power.
What sample size of failures do you have ? Is the hardest fuse the same location each time ?
Seems it would be worth storage scope capturing the blow current profile, of every single fuse, one at a time, on the samples you have.
The dI/dT on blow could be high ?
Some reasonable delay between Zaps would allow time to cool, to avoid thermal crosstalk effects.
I noticed in the IP notes, they mention ECC so that a single fuse failure does not scrap the part.
I've only blown 24 fuses. There were four per test chip and we built six boards with test chips. That was 24 fuses to test. Only one seemed reluctant to blow at 3.3V.
ECC may be an alternative to higher VPP.
Though it's not stated on the following (linked) documents, sure there are excellent reasons to keep the 8:1 ratio.
paris.utdallas.edu/ssiri08/Tonti_SSIRI_eFuse_V2.pdf
https://people.maths.ox.ac.uk/fowler/papers/2010.6.pdf
Though not limited to the aspect ratio, other fuse geometry-related concerns are shown and discussed.
E. g., the geometry of both cathode and anode regions can (and will) affect the end result, including the a eventual and parcial reconection in a latter time (though the readout circuit you had posted, seems to well address any possibility of a false reading).
Several phenomena seems to be taking place, either simultaneously or in sequence, but the proccess seems to be well described in both papers.
I've also linked the fuse layout and the blowing/readout circuit you have posted at "Prop2 Analog Test Chip Arrived!" for reference purposes.
Hope it helps.
Henrique
forums.parallax.com/discussion/download/119021/Fuse_layout.png
forums.parallax.com/discussion/download/119017/Poly_Fuse.png
? I can't remember, but this was probably covered before - why use a P-FET instead of a more efficient N-FET as the main fuse-blow device ?
Seems a N-FET buys more margin, at no die cost ?
Hmm, a small sample, and not the final full-fuse-set layout tested either - less than ideal, I can see why another test run is planned.
Yes, that is certainly more tolerable than spiking every VIO pin, but still less than ideal.
it's me the one that need to thank you, by being sharing so many thoughts and concerns, ideas and brilliant solutions with us all, giving to each one the opportunity to learn and contribute.
Whithout your efforts and dilicence, perhaps I would be raising roots under my brown right foot while I was trying to kick the pileing dust at the backside with the white left one, looking, thru fogged windows, the high passing clouds in the sky, waiting for tomorrow's newspaper.
I feel as an ant among sacred elephants,
and no one tries to smash me, under its feet,
cause their gender is kind, like the ones
who provided this place, our's to share.
I'll keep marching, proudly, in the herd,
cause I feel, I'm as tall and as heavy as they are.
P.S. I'm nor part neither I have anything to do with the Salvation Army!!!
Hi Chip
Theese are good news, for sure.
Yesterday night (brazilian time, GMT-3) I've found another option but I felt asleep before I can post it.
Though not described into the ONC18 G/MS documents I'd posted before, OnSemi does also have another qualified fuse option, besides custom-generated e-fuses or Sidense IP OTP.
It's know as I-Fuse, from Attopsemi Technology, and relyes on a diode-resistor combo to implement the fuse cell.
Described into a OnSemi-hosted panphlet, as being available as part of OnSemi BCD process, so, it's yet to be determined if they would be also available at the same process P2 will be using.
onsemi.com/site/pdf/ON-Semiconductor-0.18um-BCD-IP-v5.pdf
According to IP provider's, they use less space and enable much more available current to blow the fuses, when compared to e-fuse technologies.
I'm not sure they are available in such small instance (128 x 1), but for 4k x 8b they are known as AT4K8O180GN0AA.
The only drawback i've noticed was in the read access time: spec'ed at 25nS (<20nS in another part of the panphlet).
Programm is spec'ed at 10uS (1~10uS in another part of the spec); for an OTP, it also seems to be very good.
Henrique
It's is like they never looked what the general concept of P2 is, and gave inputs as to not reinvent the wheel.
Is $250K chump change to them? that only gets you a few minutes of tech support.
They've been slow on this fuse issue, but they always answer emails. They also let us run our last test chip for free. I'm hoping for that deal, again.
RAM typically uses 6T while I gather FLASH uses 1T. On this basis, putting FLASH on the P2 could have enough die space for 512KB of HUB FLASH. This could fit nicely with the 512KB HUB RAM. Fuses could take a tiny bit of this space, which would be blocked out if security was in operation.
Now I gather that FLASH runs slower than RAM. If it was half the speed, then why not only allow every second cog to access the HUB FLASH?
Most micros these days have FLASH memory as code space, and there are quite a number that have 1MB or more!!! Even some PIC32MX series have 1MB or more together with lots of RAM like up to 512KB.
Just how much extra cost is putting FLASH in the P2? I thought the outer ring pin logic required an extra metal layer or two. Would these do for the additional layer(s) that FLASH requires? If so, then perhaps there is no additional cost at all. OnSemi FLASH should be proven. The egg-beater logic should work equally well with cogs and HUB-EXEC too, even if only half the cogs get access to hub flash.
Personally I would even settle for 8 COGs, or only 8 COGs with HUB access and 8 COGs without any HUB access (by using the shared LUT RAM to the "blind" COGs).
FLASH "should" actually simplify the boot process, speed up the boot process, and give the P2 twice the hub space - 512KB RAM and 512KB FLASH.
The question really needs to be asked of OnSemi and TreeHouse !!!
Yes, a valid question - Costs and Speeds would be good to know, before a finally layout is started, just to confirm "Current status of Flash"
Ugh... What may be possible, would be adding a ready line, and have FLASH access valid every 2nd or 3rd eggbeater fly-around.
Noe that adding extra MUX's to decide RAM/FLASH would slow down RAM speed too...
Of course, once you add "Slow-Memory-Path" support, that also helps XIP memory**, and you are probably smarter to improve External Flash access over shoe-horning in internal flash.
The same Slow Memory usage caveats apply, only now you can attach any size flash to P2, and the RAM speed impact is removed.
Stacked die can also be used, to give low cost, one-package solutions. (see NUC505 below)
Of course, large Micros have continued to get larger, and yes mainstream MCUs have FLASH.
However, an increasing number of MCUs do not have Flash in the main memory plane.
Some examples:
ESP32, ESP8266 - external Boot flash
FTDI's FX900, FT51x - internal boot flash, SRAM execute
XMOS - Small OTP on chip, external FLASH
NUC505 - Stacked die SPI Flash, gives low cost high speed USB MCU + M4 MCU
TZxxx series from Toshiba are external boot, on chip FLASH to 1MB
TZ1200 has 2.2MB SRAM, in 8.0 × 8.0mm package
ADSP-SC572 ARM+DSP Dual Core, OTP + 384kB+256kB+1MB RAM, HS-USB, 17x17mm package,
** XIP memory has a number of forms :
Simplest is QuadSPI, with DTR (double edge) also expanding.
HyperFLASH is an octal DTR form, broadly similar to 2 x QuadSPI.DTR
Then, there are SRAM choices, which seem to be expanding at ISSI Serial SRAM and Low Pin Count SRAM
and also HyperRAM - good price per bit, but not the easiest to use for random access tasks.
Better XIP support ? :
Maybe the best way to manage this is a Memory-ready bit that can auto-wait whilst a dedicated COG serves up the next byte(s).
As in, one COG can issue a RDLONG outside of on-chip space, and that simply pauses until the co-operating COG has data ready.
The caller code thinks it has easy to use, flat memory space, & the memory-link COG handles the bus-timing/bit-level details, to any mix of off-chip memory.
Wow, 60 !? pins a channel, that's some unusual XIP memory you have selected there....
A practical P2 design is unlikely to need 16 channels of XIP - the Multicore parts I've seen with XIP, do not consider it vital to have every core accessing XIP memory, at the same instant.
Most code would load into RAM, then Run, but there are large array cases where it is easier in the tools, if off-chip memory is made simpler to access.
Other vendors do not tie themselves into the same philosophical knots, they live in a more practical world.
Speed vs reach trade-offs are very common across the MCU/MPU space, close in memory, or registers, are always faster than further away memory.
It is about making the best use of what memories you can get.
XIP is a question customers will ask, because other suppliers can do it.
Even more pressing, is customers can see memory on their PCBs, that they expect to be able to access.
There is clearly just one Loader Flash memory, they do not expect 16 COGs to have simultaneous access to it.