The New 16-Cog, 512KB, 64 analog I/O Propeller Chip

Comments

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.

"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 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?

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.

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:

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 ?

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.

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.