Why don't you also ask about using eeprom/flash/otp to replace the little ROM too, or at least some of it?
Then the boot code could be changed too. I would modify the boot code to boot directly from SD without requiring a SPI Flash chip to boot.
Complete removal of the pre-boot ROM means you then need some external means to program the EEPROM on a blank device.
Next you add the issue of how do you field-recover from a 'bricked' device ?
There may be a mixed solution here :
What size is the present pre-boot code ?
How much pre-boot ROM is spare ?
How much code do you need to add SD load ?
It seems the internal EEPROM could nudge up a little in size, and allow the pre-boot ROM to check that, for boot-patch ?
..or even if it cannot go up in size, maybe it can add a signature-block bit pattern, (256b, 512b? ) that the SPI mode booter can simply seek-for on a most-basic SD read,
The EEPROM can certainly disable some boot steps (defaults to all-steps-checked when erased/new)
Looks like SPI eeprom is not as high-volume-use as i2c eeprom, and SPI flash is close to the same price, for MUCH more storage.
Appears there is room for i2c memory, as that is both much smaller and much cheaper - maybe that 32kb SOT23 part gives another way to manage SD boot ?
If it's possible to get more EEPROM, even just 16-32K. (assuming there is no way there is room for something properly big (MBs))
Then the ROM could be setup to allow programming that and optionally booting from it instead of the external flash.
I can imagine a LOT of very nice possibilities with a setup like that.
I don't see EEPROM being viable as ROM substitute. If Chip's figure of 8x32 bit instance scales up even close, then a mere 8kB comes out to maybe 26 mm2. That's around 1/3 of the silicon.
I don't see EEPROM being viable as ROM substitute. If Chip's figure of 8x32 bit instance scales up even close, then a mere 8kB comes out to maybe 26 mm2. That's around 1/3 of the silicon.
They might have much denser flash arrays available, too. I will ask.
"The 1Gb MRAM is produced in 28nm CMOS on 300mm wafers in partnership with GlobalFoundries, Inc., utilizing Everspin's patented perpendicular magnetic tunnel junction (pMTJ) technology. The rapid development of the 1Gb part is a direct result of the degree of scalability of the pMTJ, moving from 40nm to 28nm processes in less than one year through close partnership with GlobalFoundries."
Mmmm, nice. I suppose older fabrication lines will never receive the love though. We'll just have to buy enough Prop2's so that Parallax can do a 28 nm Prop3 design!
There is some mention about needing a very stable VREF input, which requires a bandgap reference with trimming bits of its own. I'm asking them about this now. This seems a little complicated.
Are you going to ask about the requirements of the VREF input, or are you going to ask if they can include a bandgap reference? A trimmable internal bandgap reference that could be used also for the adc/dac circuit or smart-pins would be a nice gift.
There is some mention about needing a very stable VREF input, which requires a bandgap reference with trimming bits of its own. I'm asking them about this now. This seems a little complicated.
Are you going to ask about the requirements of the VREF input, or are you going to ask if they can include a bandgap reference? A trimmable internal bandgap reference that could be used also for the adc/dac circuit or smart-pins would be a nice gift.
Alternatively, a shunt 1.25V to 2.5V bandgap reference could be provided externally, connected to the /Reset input.
2.5V could be used if the /Reset pin was designed to sense 3.3V Cmos logic levels; 1.25V if it was meant to sense 1.8V ones.
Vref could be derived from such a stable input voltage.
During an active reset, Vref will not be used internally, so it don't mind to receive near 0V as an input.
Independently of the way Chip chooses to feed Vref to the EEprom sense amplifiers, some way to protect the EEprom bits for being corrupted during erase/write must be provided, in order to avoid bricking a P2, by having one (or many) bits of the security key in some sort of misprogrammed state.
A possible option would be erasing at least one more bit, whose attribution could be to flag the security code as not to be trusted, until verifyed.
Only after a successful programming/verify cycle of the security code, the extra EEprom position could be finally programmed, signalling the validity of the security key.
I've been going over the EE block from OnSemi. This is not a trivial matter to include into a design. There is an expectation that the internals of the circuit will be probed during wafer testing. This is maybe more than I want to deal with. We don't have spare pins for this, though it should be possible to place probe pads near the IP, but at a significant area cost. I'm not liking the whole thing.
In the bigger picture, I've always been nervous about putting security features into the design which could cause chips to be dead-on-arrival, due to some oversight, or become "bricked" in the user's hands. I really like simple. Keeping non-volatile memory out of the Prop2 keeps the chip, itself, most reliable. And I did ask about higher-density memories, but they don't have anything more for the ONC18 process.
At this moment, I want to get this project done and not mess around with any "iffy" stuff. So, I know some will suppose this is horrendous, but I'm going to proceed without built-in code security. The fuses that are already laid out, which require 5V and are not that reliable, anyway, will be permanently disabled.
At this moment, I want to get this project done and not mess around with any "iffy" stuff. So, I know some will suppose this is horrendous, but I'm going to proceed without built-in code security. The fuses that are already laid out, which require 5V and are not that reliable, anyway, will be permanently disabled.
Seems reasonable. Does that mean that the fuses are coming out entirely (or, at maybe just being disconnected to avoid re-working the ring circuitry)? And the HMAC stuff is being taken out as well? Will this open up ROM space for more boot options?
The control signals to the fuses will be wired "off", so it will be as if they are not there.
The HMAC stuff can stay, for cases where you want a signed loader, but the key will be 0. It frees up some ROM room, but not much. Mainly, it just simplifies things a little bit.
I've always been nervous about putting security features into the design which could cause chips to be dead-on-arrival, due to some oversight, or become "bricked" in the user's hands.
I concur.
Warning, anecdote ahead...
Some years ago, pre-arduino, I realized I had not toyed with micro-controllers for an awful long time and decided to do some catching up. I acquired a bunch of PICs and AVRs. The PICs were soon rejected as there was no Open Source C compiler available and the assembly language is fugly. That left the AVRs, with the avr-gcc compiler, some Open Source programmer tools and home made programmer hardware.
Soon I had a pile of dead AVRs. Fuses set wrongly. Perhaps recoverable with a high voltage programmer. I gave up. That's when I discovered the Propeller...
I really like simple.
KISS is the cardinal rule around here. Is it not ?
At this moment, I want to get this project done and not mess around with any "iffy" stuff. So, I know some will suppose this is horrendous...
Excellent.
I have no way to know for sure but my gut tells me that despite calls for code security the market loss by not having it will be tiny. Less than the loss due to any delay caused by implementing it. The guys that really need that stuff will not be looking at the P2 anyway.
I've been going over the EE block from OnSemi. This is not a trivial matter to include into a design. There is an expectation that the internals of the circuit will be probed during wafer testing. This is maybe more than I want to deal with. We don't have spare pins for this, though it should be possible to place probe pads near the IP, but at a significant area cost. I'm not liking the whole thing.
Hmm, you lose calibrate and serialize, as well as secure, which is all adding up...
I'd want more numbers on this before jumping one way or the other... and there may be other ways to manage this...
- How much area does this need, and is that Top-layer only impact ?
- What is the expected Yield of the EE block ? - ie WHY exactly do they need to probe at wafer test
- That yield means failure to Pgm/Erase, right ?
- Surely that can also be tested after wafer probe ?
If the EE block has some yield < 100%, can you create two P2 part numbers ?
One has no EEPROM, and defaults to no security, and the other has EEPROM, for those needing Calibrate/Secure/Serial features.
Given it seems the Fuses will also have some Yield value < 100%, and cannot be tested, until 'the user finds out late in production', a Tested EE CELL has clear benefits to end user production yields.
In the bigger picture, I've always been nervous about putting security features into the design which could cause chips to be dead-on-arrival, due to some oversight, or become "bricked" in the user's hands. I really like simple. Keeping non-volatile memory out of the Prop2 keeps the chip, itself, most reliable. And I did ask about higher-density memories, but they don't have anything more for the ONC18 process.
Certainly the design should default-safe, so a brand new EE block, cannot stop the part from working with blank cells.
At this moment, I want to get this project done and not mess around with any "iffy" stuff. So, I know some will suppose this is horrendous, but I'm going to proceed without built-in code security. The fuses that are already laid out, which require 5V and are not that reliable, anyway, will be permanently disabled.
You can get more precise stats on the fuses with the shuttle run, right ?
Before binning the idea entirely, I'd run tests on the test-die you will soon have, to get a much larger sampling fuse curve, and a yield number too.
Then, Vpp type decisions can be made.
Even if you can only use them for factory calibrate and Serial Numbers, and not as user-fuses, that still gives some benefits.
The current needed to blow a fuse is more than an on-chip charge pump could reasonably produce.
Our custom pad frame layout has been done for a few months now, with all the improvements. There is no provision in it for tuning the RC oscillator, so NV bits wouldn't be of any use there.
There's another problem with implementing these NV bits, and that is that OnSemi has not been very prompt about answering prickly questions about how to implement their oddball IP, like this NV block, or even how fuses are supposed to work. Without answers, it's hard to proceed. Anyway, I'm tired of asking questions regarding odd things that nobody seems to have definitive answers for. I want to proceed with what I have confidence in.
Our custom pad frame layout has been done for a few months now, with all the improvements.
There is no provision in it for tuning the RC oscillator, so NV bits wouldn't be of any use there.
I was meaning to store a measured frequency value. Not quite as clean as a trim-osc, but still much better than no cal at all.
From another thread, can the RCFAST feed the PLL ok ? - can you test that on the test chips ?
There's another problem with implementing these NV bits, and that is that OnSemi has not been very prompt about answering prickly questions about how to implement their oddball IP, like this NV block, or even how fuses are supposed to work. Without answers, it's hard to proceed..
Maybe this NV decision needs a face-to-face at OnSemi, given it's a fairly pivotal system question ?
There's another problem with implementing these NV bits, and that is that OnSemi has not been very prompt about answering prickly questions about how to implement their oddball IP, like this NV block, or even how fuses are supposed to work. Without answers, it's hard to proceed..
Maybe this NV decision needs a face-to-face at OnSemi, given it's a fairly pivotal system question ?
Perhaps we could have that conversation with them, in time.
We are now waiting for word from them about when they can proceed with the synthesis work. Here is the work we need them to do:
- RTL input, Synthesize to ON Semi ONC18 Netlist
- SCAN Insertion, SCAN Pattern Generation
- Digital Place & Route
- Memory instance, create layout placeholders for each memory
- Full chip layout
- Post layout verification
And then there's the matter of integrating all this core work into the padframe with physical hookups and timing data.
Our custom pad frame layout has been done for a few months now, with all the improvements.
There is no provision in it for tuning the RC oscillator, so NV bits wouldn't be of any use there.
I was meaning to store a measured frequency value. Not quite as clean as a trim-osc, but still much better than no cal at all.
From another thread, can the RCFAST feed the PLL ok ? - can you test that on the test chips ?
I see what you were thinking. Just having a constant to tell us the approximate frequency would be nice.
I did not make the RCFAST able to drive the PLL. I figured that running fast also means running precisely, with a crystal. I thought about it, though.
I see what you were thinking. Just having a constant to tell us the approximate frequency would be nice.
I did not make the RCFAST able to drive the PLL. I figured that running fast also means running precisely, with a crystal. I thought about it, though.
On this 'with a crystal' angle, do you have logic added yet to check for an External oscillator present ?
Common across many MCUs and driven by IEC standards, is the need for MCUs to have oscillator-fail handling.
On-chip Osc's allow most of this, with some small additional logic.
I'd agree most uses would be Xtal/Osc-based, but some uses might benefit from RCOsc -> PLL for faster fall-back speeds.
Does RCOsc -> PLL need a change to outer design area, or is it verilog possible ?
-various physical checks and parasitic extraction
-static timing analysis
-logical equivalence checks (LEC)
-gate level simulation of scan/membist logic
-stuff that I'm forgetting???
I believe that you don't do any RTL simulation of the P2? You might want to ask them what they expect of you during post layout verification. Typically this does involve some gate level simulation of the DUT in physical mode. Which presumes that you have RTL simulations available that you can draw on. Remember that the insertion of test logic can break your design. Hopefully LEC catches problems, but sometimes gate sims find things that LEC misses.
I see what you were thinking. Just having a constant to tell us the approximate frequency would be nice.
I did not make the RCFAST able to drive the PLL. I figured that running fast also means running precisely, with a crystal. I thought about it, though.
On this 'with a crystal' angle, do you have logic added yet to check for an External oscillator present ?
Common across many MCUs and driven by IEC standards, is the need for MCUs to have oscillator-fail handling.
On-chip Osc's allow most of this, with some small additional logic.
I'd agree most uses would be Xtal/Osc-based, but some uses might benefit from RCOsc -> PLL for faster fall-back speeds.
Does RCOsc -> PLL need a change to outer design area, or is it verilog possible ?
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.
-various physical checks and parasitic extraction
-static timing analysis
-logical equivalence checks (LEC)
-gate level simulation of scan/membist logic
-stuff that I'm forgetting???
I believe that you don't do any RTL simulation of the P2? You might want to ask them what they expect of you during post layout verification. Typically this does involve some gate level simulation of the DUT in physical mode. Which presumes that you have RTL simulations available that you can draw on. Remember that the insertion of test logic can break your design. Hopefully LEC catches problems, but sometimes gate sims find things that LEC misses.
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.
Comments
Complete removal of the pre-boot ROM means you then need some external means to program the EEPROM on a blank device.
Next you add the issue of how do you field-recover from a 'bricked' device ?
There may be a mixed solution here :
What size is the present pre-boot code ?
How much pre-boot ROM is spare ?
How much code do you need to add SD load ?
It seems the internal EEPROM could nudge up a little in size, and allow the pre-boot ROM to check that, for boot-patch ?
..or even if it cannot go up in size, maybe it can add a signature-block bit pattern, (256b, 512b? ) that the SPI mode booter can simply seek-for on a most-basic SD read,
The EEPROM can certainly disable some boot steps (defaults to all-steps-checked when erased/new)
I did find this in a search for most-basic SD-read handling ?
http://www.microchip.com/forums/m530149.aspx
An update check on serial memory finds
FT25C08A-USR-T Fremont SPI EEPROM 8KBIT 20MHZ 8SOIC $0.139/3k
FT25H04S-RT Fremont SPI FLASH 4MBIT 120MHZ 8SOP $0.148/3k
FT25H16S-RT Fremont SPI FLASH 16MBIT 120MHZ 8SOP $0.2046/3k
AT24C08D-XHM-B Microchip i2c EEPROM 8KBIT 1MHZ 8TSSOP $0.0345/3k
AT24C32D-STUM-T Microchip i2c EEPROM 32KBIT 1MHZ SOT23-5 $0.066/3k
Looks like SPI eeprom is not as high-volume-use as i2c eeprom, and SPI flash is close to the same price, for MUCH more storage.
Appears there is room for i2c memory, as that is both much smaller and much cheaper - maybe that 32kb SOT23 part gives another way to manage SD boot ?
Then the ROM could be setup to allow programming that and optionally booting from it instead of the external flash.
I can imagine a LOT of very nice possibilities with a setup like that.
They might have much denser flash arrays available, too. I will ask.
Just for you !! ( - but not on the OnSemi 180nm process... )
https://www.storagenewsletter.com/2017/08/14/flash-memory-summit-everspin-sampling-1gb-st-mram-product/
"The 1Gb MRAM is produced in 28nm CMOS on 300mm wafers in partnership with GlobalFoundries, Inc., utilizing Everspin's patented perpendicular magnetic tunnel junction (pMTJ) technology. The rapid development of the 1Gb part is a direct result of the degree of scalability of the pMTJ, moving from 40nm to 28nm processes in less than one year through close partnership with GlobalFoundries."
There we go, 2MB of MRAM in the equivalent of a Prop2 process tech. No idea the die size but I doubt it was as big as the Prop2.
Are you going to ask about the requirements of the VREF input, or are you going to ask if they can include a bandgap reference? A trimmable internal bandgap reference that could be used also for the adc/dac circuit or smart-pins would be a nice gift.
Alternatively, a shunt 1.25V to 2.5V bandgap reference could be provided externally, connected to the /Reset input.
2.5V could be used if the /Reset pin was designed to sense 3.3V Cmos logic levels; 1.25V if it was meant to sense 1.8V ones.
Vref could be derived from such a stable input voltage.
During an active reset, Vref will not be used internally, so it don't mind to receive near 0V as an input.
Independently of the way Chip chooses to feed Vref to the EEprom sense amplifiers, some way to protect the EEprom bits for being corrupted during erase/write must be provided, in order to avoid bricking a P2, by having one (or many) bits of the security key in some sort of misprogrammed state.
A possible option would be erasing at least one more bit, whose attribution could be to flag the security code as not to be trusted, until verifyed.
Only after a successful programming/verify cycle of the security code, the extra EEprom position could be finally programmed, signalling the validity of the security key.
Henrique
In the bigger picture, I've always been nervous about putting security features into the design which could cause chips to be dead-on-arrival, due to some oversight, or become "bricked" in the user's hands. I really like simple. Keeping non-volatile memory out of the Prop2 keeps the chip, itself, most reliable. And I did ask about higher-density memories, but they don't have anything more for the ONC18 process.
At this moment, I want to get this project done and not mess around with any "iffy" stuff. So, I know some will suppose this is horrendous, but I'm going to proceed without built-in code security. The fuses that are already laid out, which require 5V and are not that reliable, anyway, will be permanently disabled.
It's a rough choice, but probably for the best at this point.
Seems reasonable. Does that mean that the fuses are coming out entirely (or, at maybe just being disconnected to avoid re-working the ring circuitry)? And the HMAC stuff is being taken out as well? Will this open up ROM space for more boot options?
The HMAC stuff can stay, for cases where you want a signed loader, but the key will be 0. It frees up some ROM room, but not much. Mainly, it just simplifies things a little bit.
Warning, anecdote ahead...
Some years ago, pre-arduino, I realized I had not toyed with micro-controllers for an awful long time and decided to do some catching up. I acquired a bunch of PICs and AVRs. The PICs were soon rejected as there was no Open Source C compiler available and the assembly language is fugly. That left the AVRs, with the avr-gcc compiler, some Open Source programmer tools and home made programmer hardware.
Soon I had a pile of dead AVRs. Fuses set wrongly. Perhaps recoverable with a high voltage programmer. I gave up. That's when I discovered the Propeller... KISS is the cardinal rule around here. Is it not ? Excellent.
I have no way to know for sure but my gut tells me that despite calls for code security the market loss by not having it will be tiny. Less than the loss due to any delay caused by implementing it. The guys that really need that stuff will not be looking at the P2 anyway.
Hmm, you lose calibrate and serialize, as well as secure, which is all adding up...
I'd want more numbers on this before jumping one way or the other... and there may be other ways to manage this...
- How much area does this need, and is that Top-layer only impact ?
- What is the expected Yield of the EE block ? - ie WHY exactly do they need to probe at wafer test
- That yield means failure to Pgm/Erase, right ?
- Surely that can also be tested after wafer probe ?
If the EE block has some yield < 100%, can you create two P2 part numbers ?
One has no EEPROM, and defaults to no security, and the other has EEPROM, for those needing Calibrate/Secure/Serial features.
Given it seems the Fuses will also have some Yield value < 100%, and cannot be tested, until 'the user finds out late in production', a Tested EE CELL has clear benefits to end user production yields.
Certainly the design should default-safe, so a brand new EE block, cannot stop the part from working with blank cells.
You can get more precise stats on the fuses with the shuttle run, right ?
Before binning the idea entirely, I'd run tests on the test-die you will soon have, to get a much larger sampling fuse curve, and a yield number too.
Then, Vpp type decisions can be made.
Even if you can only use them for factory calibrate and Serial Numbers, and not as user-fuses, that still gives some benefits.
Anyway to implement a charge pump to bring the 3.3 V up to 5 V just for the fuses?
Our custom pad frame layout has been done for a few months now, with all the improvements. There is no provision in it for tuning the RC oscillator, so NV bits wouldn't be of any use there.
There's another problem with implementing these NV bits, and that is that OnSemi has not been very prompt about answering prickly questions about how to implement their oddball IP, like this NV block, or even how fuses are supposed to work. Without answers, it's hard to proceed. Anyway, I'm tired of asking questions regarding odd things that nobody seems to have definitive answers for. I want to proceed with what I have confidence in.
From another thread, can the RCFAST feed the PLL ok ? - can you test that on the test chips ?
Perhaps we could have that conversation with them, in time.
We are now waiting for word from them about when they can proceed with the synthesis work. Here is the work we need them to do:
- RTL input, Synthesize to ON Semi ONC18 Netlist
- SCAN Insertion, SCAN Pattern Generation
- Digital Place & Route
- Memory instance, create layout placeholders for each memory
- Full chip layout
- Post layout verification
And then there's the matter of integrating all this core work into the padframe with physical hookups and timing data.
I see what you were thinking. Just having a constant to tell us the approximate frequency would be nice.
I did not make the RCFAST able to drive the PLL. I figured that running fast also means running precisely, with a crystal. I thought about it, though.
On this 'with a crystal' angle, do you have logic added yet to check for an External oscillator present ?
Common across many MCUs and driven by IEC standards, is the need for MCUs to have oscillator-fail handling.
On-chip Osc's allow most of this, with some small additional logic.
I'd agree most uses would be Xtal/Osc-based, but some uses might benefit from RCOsc -> PLL for faster fall-back speeds.
Does RCOsc -> PLL need a change to outer design area, or is it verilog possible ?
>Post layout verification
I guess includes:
-various physical checks and parasitic extraction
-static timing analysis
-logical equivalence checks (LEC)
-gate level simulation of scan/membist logic
-stuff that I'm forgetting???
I believe that you don't do any RTL simulation of the P2? You might want to ask them what they expect of you during post layout verification. Typically this does involve some gate level simulation of the DUT in physical mode. Which presumes that you have RTL simulations available that you can draw on. Remember that the insertion of test logic can break your design. Hopefully LEC catches problems, but sometimes gate sims find things that LEC misses.
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.
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.