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

1138140142143144

Comments

  • pjvpjv Posts: 1,903
    Cluso99 wrote: »
    IMHO this will mean only the most hardened customers will use fuses. Many customers will consider the P2 a failed chip with this impediment, and won't even use it even if they don't want the fuses anyway. At least that's the way I would consider it if I were considering the P2 in a commercial design.

    On the other hand, there are those commercial applications that absolutely require some security such as fuses. And P2 would be bypassed in those.

    Cheers,
    Peter (pjv)

  • Tubular wrote:
    Overshoot is *real*, Phil!

    It's real enough as far as the scope is concerned. But that's only due to the inductance of the scope lead and the oscillating potential differences across it. And it's not what the Prop itself sees relative to its own PCB ground plane.

    The attached image shows the difference. In the left-hand pair of images, a standard ground clip is used to probe the Prop's P3 pin, which is outputting a square wave. You can see the overshoot. In the right-hand pair, the ground lead is removed from the scope probe and replaced with a very short length of bare wire. The overshoot all but disappears. It's even better to solder the short wire directly to the PCB.

    -Phil
    922 x 692 - 852K
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Is code protect so vital? If our implementation is so troublesome, what if we just didn't have it?
  • jmgjmg Posts: 13,788
    cgracey wrote: »
    Is code protect so vital? If our implementation is so troublesome, what if we just didn't have it?

    Depends on your value of 'vital' I guess ?

    IIRC Ken has rated security up near the top of the P1+ lists.

    If OnSemi OTP is not viable for some reason, alternatives for handling what you have now could be

    * To factory code a random ID number, so every chip is serialised, that ID number can be used to lock.
    Possibly also a date code for batch-type security ?
    This does not need special tracking codes or labeling.

    * To offer factory Locking to some user provided full key - parts shipped 100% tested, in trays.
    This does make each chip-lot unique, and needs some means of tracking/labeling.
  • Oh man am I the last one to fight for code protection?
  • @Phil I tightened up the gnd much like your photo, but still see a considerable overshoot (+ringing). I'm measuring on a Flip because I'm frankly more interested in the switchmode recovery, but will post pics and cro caps later - have a broken system that needs attention.

    But backing up a step, most of the time probing one starts with the flying croc clip ground, and this added load and parasitics does indeed result in node voltages above 3v3, albeit briefly, and things still work after the probe is moved to some other unsuspecting node. Ie I think systems are more robust to (sub 5v) excursions than is bring portrayed here

  • jmgjmg Posts: 13,788
    Tubular wrote: »
    .... Ie I think systems are more robust to (sub 5v) excursions than is bring portrayed here
    The P1 is quite an old process, and more tolerant.
    Newer parts spec down as low as 4V ABS MAX.

  • evanhevanh Posts: 7,533
    edited 2017-08-24 - 10:05:11
    Is there any alternative to the fuses actually up for offer?

    There have been many who have asked for code protection. If OTP or whatever isn't an option then it's best to stick with the existing fuses and document a reliable procedure for popping them. Better that than nothing at all I'd think.

    EDIT: After all, code-protection is a finished product exercise that has the single purpose of making the customer's life more difficult. Maybe it's a little karma. :D
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • TorTor Posts: 1,980
    Roy is spot on, I think.
    About using a jumper - that doesn't sound feasible. How would that be handled for mass production? A robot inserting a jumper, then removing it? Are such things done in production lines?
  • jmgjmg Posts: 13,788
    evanh wrote: »
    Is there any alternative to the fuses actually up for offer?

    OnSemi do have a range of Config-type memories.
    The exact terms/die costs/interfaces have not been fully defined, but they do exist.
    OTP you can expect to be the smallest and cheapest, with erasable cells next up the curve.

  • evanhevanh Posts: 7,533
    edited 2017-08-24 - 11:24:34
    Options available is different to up for offer.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • Chip,
    I thought that code protection was extremely high on the list. IMHO another solution is required!
    I am extremely disappointed that despite my urging, you haven't bothered to even ask about the other possible solutions such as flash/eeprom/OTP despite my continual urging to do so. Seriously, it's a real embarrassment to get to this stage and find out about the fuse problems now.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • And MRAM. You missed that off your list again Cluso. ;)

    The fuse problem was known for a while now. And apparently is common for low voltage parts under 5 Volts like this.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • Cluso99 wrote: »
    Chip,
    I thought that code protection was extremely high on the list. IMHO another solution is required!
    I am extremely disappointed that despite my urging, you haven't bothered to even ask about the other possible solutions such as flash/eeprom/OTP despite my continual urging to do so. Seriously, it's a real embarrassment to get to this stage and find out about the fuse problems now.

    I'm sorry for my hesitation. I've been worried about process changes that likely accompany these other memory solutions. We really can't afford to redo everything at this point.

    I've asked OnSemi to tell us today how big, in square mm, their smallest NV memory instance is that contains its own charge pump, so that there is no VPP pin requirement.

    Let's see what they say.
  • octettaoctetta Posts: 50
    edited 2017-08-24 - 16:54:00
    Full disclosure: I have no need or desire for code protection, but I would really hate to delay the P2 for this reason.

    Biased opinion:

    My own experience as an engineer that has literally shipped hundreds of millions of digital devices is that the <1% of customers who wanted to hack my products were going to be successful no matter what the safeguards.
  • jmgjmg Posts: 13,788
    cgracey wrote: »
    ... I've been worried about process changes that likely accompany these other memory solutions. We really can't afford to redo everything at this point.
    I'm not sure there is any process change for the OTP cells, from reading OnSemi's offerings.
    There may be a small area impact.

    It's very common for chips to need SOME level of config or cal, so these cells should be well proven - even lower risk than fuses..
  • I don't see why mass production could have either a header for programming that provided the 5V or a spring loaded programmer contact. For me I would put a miles connector that included the power on an extra pin.
  • cgraceycgracey Posts: 11,536
    edited 2017-08-24 - 22:17:36
    We heard from OnSemi.

    Their EEPROM only requires the MiM cap option in the ONC18 process. An 8x32 bit instance would be 695um x 240um, which is small enough. No VPP pin needed. It runs off the core 1.8V supply. It has an expected 15-year data retention at 135 degrees Celsius.

    The maximum bit array size is 16 bits x 64 words, or 1K bits. We only need 256 bits, of course.

    So, this looks like it would solve the problem and allow easier development of a whole family of Prop2 chips, since we could always have the needed 256 bits of EEPROM without needing 64 I/O pins which each contain 4 fuses.

    There are no extra costs to use this.

    We will use it.
  • That is excellent news Chip.
  • ctwardell wrote: »
    That is excellent news Chip.

    We must thank Cluso99 for his prodding to check into this. I didn't think anything so simple was likely to exist.
  • cgraceycgracey Posts: 11,536
    edited 2017-08-24 - 22:35:53
    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.
  • JRetSapDoogJRetSapDoog Posts: 792
    edited 2017-08-24 - 22:52:45
    Thanks, Cluso99 for your repeated prodding haranguing. :smile: You saved the day! Prop day. And don't worry about those rumors about messengers bearing bad news being killed; that's only if no solutions exist. **Update** Hmm...I may have spoken too soon. Well, perhaps there's still a OTP route if the EEPROM one doesn't work out.
  • Yes, nice prodding Cluso! Its amazing what solutions are only 'asking the right person the right question' away

    Now how to resist thinking about what to use the remaining 768 bits for...

  • Sounds like we might end up with a much better solution overall, if the VREF input can be sorted.
  • that stability is probably only to get 15 years at 135C...
    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 13,788
    cgracey wrote: »
    We heard from OnSemi.

    Their EEPROM only requires the MiM cap option in the ONC18 process. An 8x32 bit instance would be 695um x 240um, which is small enough. No VPP pin needed. It runs off the core 1.8V supply. It has an expected 15-year data retention at 135 degrees Celsius.

    The maximum bit array size is 16 bits x 64 words, or 1K bits. We only need 256 bits, of course.

    There are no extra costs to use this.

    We will use it.
    Sounds very good, this is EEPROM too, not OTP ?
    How many Erase cycles Endurance ? What size Erase ?
    Q : can it have a Write-Protect bit ?
    Some forms of security want to prevent Trojan horse type attacks, where the Key and code are BOTH changed, and the product 'looks' the same ....

    1k bits min is fine, as you want 256 bits plus calibrate storage for RC Osc's, plus unique serial number, plus some user space....
    cgracey wrote: »
    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.
    Seems a little unusual, as most EEPROM cells are MOSFET threshold based, and that usually is sensed with another mosfet, given it varies with temperature.
    Maybe that Vref sets a read current level ?

  • jmgjmg Posts: 13,788
    cgracey wrote: »
    We must thank Cluso99 for his prodding to check into this. I didn't think anything so simple was likely to exist.

    It is very common for Chips to need SOME programming, so such problems are likely to have been solved before

  • The EEPROM block is spec'd at 10k writes at 85 degrees Celsius. That should be quite sufficient.
  • Fantastic news Chip!

    I expected OnSemi would have a solution. Bet they have a solution for larger blocks too!

    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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Hi Cluso99

    If the SD boot code could be merged within the actual SPI Flash chip reading routines and still fit inside the limits of the ROM code, a single EEPROM bit could be used to select between them. Both worlds could fit into one solution.

    Only a thought...

    Henrique
    Cluso99 wrote: »
    Fantastic news Chip!

    I expected OnSemi would have a solution. Bet they have a solution for larger blocks too!

    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.

Sign In or Register to comment.