Shop OBEX P1 Docs P2 Docs Learn Events
P2 and OnSemi capability — Parallax Forums

P2 and OnSemi capability

Last night I was reading about NAND and NOR FLASH.

From what I read I believe OnSemi have both available. And articles suggest that there should be standard charge pumps for the erase cycle.

I had thought a small block of Flash would be nice so the P2 could boot a tiny program to do whatever was initially required. This could then load from flash, eeprom, SD card, or whatever. This could save having to use an external eeprom or flash Chip in some circumstances.

What I realised though, is that Flash is tiny compared to SRAM !!!

To be able to execute from it would require NOR FLASH.

There might be even be enough die space to have 512KB of HUB FLASH.
This could be a game changer!!!

Does NOR FLASH require an extra layer over what the P2 requires? Do I recall correctly that the smart pin ring required an extra layer??? Either way, it may be a small price to pay to get 1MB of hub.

I also noted that, as IIRC jmg said, OnSemi has not only an ONC180 (180nm), but now also an ONC110 (110nm) standard process. Are the costs prohibitive to move to 110nm. I understand the "outer ring has been done with 340nm??? Geometry. But isn't that just a 110/180nm process with larger features???

IMHO this shouldn't really delay the P2, other than the time to ask OnSemi and TreeHouse.
«1

Comments

  • evanhevanh Posts: 15,126
    The obligatory "MRAM would be the superior option for NV memory type as it entirely replaces the SRAM."
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    There might be even be enough die space to have 512KB of HUB FLASH.
    This could be a game changer!!!
    Yes, given FLASH is much slower than RAM, MHz will fall, and the Price will increase. Quite the 'game changer' there.... ;)
    Cluso99 wrote: »
    I also noted that, as IIRC jmg said, OnSemi has not only an ONC180 (180nm), but now also an ONC110 (110nm) standard process. Are the costs prohibitive to move to 110nm. I understand the "outer ring has been done with 340nm??? Geometry. But isn't that just a 110/180nm process with larger features???
    Actually no.... The 110nm I mentioned was from Microchip SST Flash, not OnSemi.
    It would be great news if OnSemi had 1.8V 110nm process..

    The points I was making were
    a) It was a recent news item, that suggests the 'current lowest-cost-node' has moved/improved to 110nm
    b) Flash vendors do still target the trailing edge, as they know lowest-cost sometimes trumps highest-MHz
    Cluso99 wrote: »
    IMHO this shouldn't really delay the P2, other than the time to ask OnSemi and TreeHouse.
    OnSemi do show OTP IP for their 180nm, somewhat recent (certainly since Chip chose OnSemi 180nm), so that is worth asking about.
    However, Flash I think is impractical on-die, but I would ask OnSemi/Treehouse about stacked die, and what is needed to at least allow for that.


  • jmg wrote: »
    Cluso99 wrote: »
    There might be even be enough die space to have 512KB of HUB FLASH.
    This could be a game changer!!!
    Yes, given FLASH is much slower than RAM, MHz will fall, and the Price will increase. Quite the 'game changer' there.... ;)
    I think most high speed MCUs that have flash also have a cache these days. That would be a big addition to the P2.
  • jmgjmg Posts: 15,140
    David Betz wrote: »
    I think most high speed MCUs that have flash also have a cache these days. That would be a big addition to the P2.
    .. but not sounding like something easy to add, and so fails this test ... "IMHO this shouldn't really delay the P2"
  • tonyp12tonyp12 Posts: 1,950
    edited 2017-05-24 00:12
    News today: SST’s SmartBit OTP NVM Technology for ON Semiconductor's 110 nm CMOS

    http://www.onsemi.com/PowerSolutions/content.do?id=16649
    1301 x 374 - 74K
  • jmgjmg Posts: 15,140
    tonyp12 wrote: »
    News today: OTP NVM Technology for ON Semiconductor's 110 nm CMOS
    Well spotted. OnSemi's web site was behind that, and the earlier FEB news I quoted before was for Flash at 110nm, but generic from SST

    The specific mention of an OnSemi 110nm process, and OTP for that, are both highly P2 relevant.
    Anyone know if that SP110 is Aerospace, or low cost consumer process ?
  • jmg,

    according to this spec sheet (link below) .. yes to both questions. "SP110 targets low to high volume digital ASIC products in the Military and Aerospace, Industrial, Networking & Telecommunications, Computing and Consumer markets."

    http://www.onsemi.com/PowerSolutions/content.do?id=16649

    When I worked at National Semiconductor, the 110nm process was called CMOSX which was a transition from the 360nm to 180nm and on towards a scalable process. In 2005 we were down to a 45nm process, but based on the same scalable CMOX architecture.

  • Um, last I heard here on the forum, the foundry was changed to AMS from OnSemi. Did I miss another memo? Or was there an acquisition that slipped my attention?

    -Phil
  • TubularTubular Posts: 4,620
    edited 2017-05-24 05:28
    As a distraction, can I be the first to suggest FuseExec?

    What'd that give us? 4 instructions? 8?
  • jmgjmg Posts: 15,140
    Um, last I heard here on the forum, the foundry was changed to AMS from OnSemi. Did I miss another memo? Or was there an acquisition that slipped my attention?
    I think you have AMS from P1 Fab info ?
    The P2 has been targeting OnSemi for quite a while now, tho in the total P2 lifecycle, not a large %...

  • jmg,

    according to this spec sheet (link below) .. yes to both questions. "SP110 targets low to high volume digital ASIC products in the Military and Aerospace, Industrial, Networking & Telecommunications, Computing and Consumer markets."

    http://www.onsemi.com/PowerSolutions/content.do?id=16649

    Folks,

    That spec sheet is for Standard Cell ASIC development, but if I understand correctly P2 is Custom Foundry manufacturing.

    The relevant link for that:
    http://www.onsemi.com/PowerSolutions/content.do?id=18397

    I'm not wanting to burst anyone's bubble here, but it looks like custom foundry is still limited to 180 nm or bigger.
  • Cluso99Cluso99 Posts: 18,066
    The info I read was from OnSemi but I don't have a link. It seems OnSemi does indeed have 110nm process for customers. Is it more expensive? Probably but who knows until the question is asked!

    As for Flash, yes it's slower than SRAM. But we are not driving the 180nm process at full SRAM speed, so are we driving it at full Flash speed? We won't know until the question is asked!

  • evanhevanh Posts: 15,126
    And MRAM. :P
  • Cluso99Cluso99 Posts: 18,066
    evanh wrote: »
    And MRAM. :P
    MRAM is still new and most likely comes with a $premium for IP. But its certainly worth the ask.

    How much die space does MRAM use? ie is it a 4T, 6T or other? Flash I gather is ~1T which is why I think its a good choice for more hub.

    IMHO Flash is a requirement, no matter the size. I just don't want flash when I have an SD Card. Have you noticed, all my P1 boards now have microSD and the Eeprom is preloaded and write protected to boot from microSD. There is no requirement for the serial/USB (propplug or equiv) and reset unless serial and/or download is required.
  • evanhevanh Posts: 15,126
    edited 2017-05-24 16:14
    MRAM density is 1T equivalent, same as DRAM and lowest density Flash. Physically, it's a reasonably complex vertical structure that uses many layers. But that's fine in a block array where there is no other routes wanting passed.

    MRAM is only new as long as no one is using it. It has been available since Prop1 launch, albeit in a less refined state back then.
  • cgraceycgracey Posts: 14,133
    edited 2017-05-24 21:54
    We are quite committed, at this point, to the ONC18 logic process. To go back and try to figure out how to integrate some non-volatile memory into the design is way too complex of a proposition. We can do something like that later, though. We need to get the first chip completed on its current trajectory.

    I know everyone likes the idea of on-chip NV memory, but it would displace RAM and slow the reloading process way down. Where we are headed currently, a compile and reload may take less than one second. That is awesome for getting your code developed. Waiting 30 seconds can cause everything to spill out of your mind and break your cadence. We will be loading to RAM 100x more frequently than reprogramming that external 8-pin flash chip. I think we are on the best course, already, given our practical possibilities.
  • jmgjmg Posts: 15,140
    edited 2017-05-24 22:33
    cgracey wrote: »
    I know everyone likes the idea of on-chip NV memory, but it would displace RAM and slow the reloading process way down. Where we are headed currently, a compile and reload may take less than one second. That is awesome for getting your code devveloped. Waiting 30 seconds can cause everything to spill out of your mind and break your cadence. We will be loading to RAM 100x more frequently than reprogramming that external 8-pin flash chip. I think we are on the best course, already, given our practical possibilities.

    Plenty of others use RAM too - it is faster, and lower power than FLASH.

    There is a 3rd option for Flash, and that is to allow a P2 variant with a SPI flash die, in the same package. The ESP32 does this, as does NU505.
    Mostly, I think allowing for that can be as simple as including the bonding pads - easy enough to ask OnSemi.
  • jmg wrote: »
    There is a 3rd option for Flash, and that is to allow a P2 variant with a SPI flash die, in the same package. The ESP32 does this, as does NU505.
    Mostly, I think allowing for that can be as simple as including the bonding pads - ask OnSemi.

    This raises the question - would you need to test the Prop2 die before packaging? This would depend on the yield. If it does need to be tested before packaging, can this be done in wafer or die form? No reason that this couldn't be done as I've seen it done (testing in wafer form is quite common), but it should be explored before it's considered to be trivial. I believe that Parallax tests the Prop1 with their own setup - maybe this is wrong information.
  • Cluso99Cluso99 Posts: 18,066
    edited 2017-05-24 21:44
    cgracey wrote: »
    We are quite committed, at this point, to the ONC18 logic process. To go back and try to figure out how to integrate some non-volatile memory into the design is way too complex of a proposition. We can do something like that later, though. We need to get the first chip completed on its current trajectory.

    I know everyone likes the idea of on-chip NV memory, but it would displace RAM and slow the reloading process way down. Where we are headed currently, a compile and reload may take less than one second. That is awesome for getting your code devveloped. Waiting 30 seconds can cause everything to spill out of your mind and break your cadence. We will be loading to RAM 100x more frequently than reprogramming that external 8-pin flash chip. I think we are on the best course, already, given our practical possibilities.

    Why would loading from internal Flash take longer?

    In fact, if it is hub flash, wouldn't in fact be quicker because it would not need to be loaded - it could be executed directly as hubexec.

    You are planning 16KB of ROM. Surely it would be simpler if this were 16KB or more Flash mapped into hub space? Why would it take more die space?

    I understand your reluctance to consider ONC11, but surely it's worth the trouble to ask???

    Things have changed a lot in the past year.
  • cgraceycgracey Posts: 14,133
    If I recall, the mask set for the 110nm process is 4x as expensive as the 180nm process. We are already going to spend $150k for masks which may even need redoing later. We're not spending $600k. We don't have it.
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    If I recall, the mask set for the 110nm process is 4x as expensive as the 180nm process. We are already going to spend $150k for masks which may even need redoing later. We're not spending $600k. We don't have it.

    If that's the case, totally agree. But things may have changed. IIRC 110nm wasn't even an option at OnSemi a year or so ago. Seems as though 110nm has gained traction recently.

    In my company, I would check it out before final commitment, just as I would check out the flash options. But it's not my call so I've made my point.
  • cgraceycgracey Posts: 14,133
    Cluso99 wrote: »
    cgracey wrote: »
    If I recall, the mask set for the 110nm process is 4x as expensive as the 180nm process. We are already going to spend $150k for masks which may even need redoing later. We're not spending $600k. We don't have it.

    If that's the case, totally agree. But things may have changed. IIRC 110nm wasn't even an option at OnSemi a year or so ago. Seems as though 110nm has gained traction recently.

    In my company, I would check it out before final commitment, just as I would check out the flash options. But it's not my call so I've made my point.

    The thing is, we've probably spent $100k on layout for the 180nm process. It took several months to get that work done, not counting all my time just to tune our circuits for the 180nm process. Retargeting for 110nm would be expensive in every way.
  • cgraceycgracey Posts: 14,133
    Most chips designed today use proven hard IP blocks for things like ADCs and oscillators. It's not a big deal to switch horses late in the game if they've got what you need. We've got a whole bunch of circuitry that is not standard for any foundry customer to ask for, but will be good for the Prop2. There's no shortcut possible here.
  • cgracey wrote: »
    Cluso99 wrote: »
    cgracey wrote: »
    If I recall, the mask set for the 110nm process is 4x as expensive as the 180nm process. We are already going to spend $150k for masks which may even need redoing later. We're not spending $600k. We don't have it.

    If that's the case, totally agree. But things may have changed. IIRC 110nm wasn't even an option at OnSemi a year or so ago. Seems as though 110nm has gained traction recently.

    In my company, I would check it out before final commitment, just as I would check out the flash options. But it's not my call so I've made my point.

    The thing is, we've probably spent $100k on layout for the 180nm process. It took several months to get that work done, not counting all my time just to tune our circuits for the 180nm process. Retargeting for 110nm would be expensive in every way.
    And I imagine it would also push out the date where P2 chips would be available.

  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    Why would loading from internal Flash take longer?
    In fact, if it is hub flash, wouldn't in fact be quicker because it would not need to be loaded - it could be executed directly as hubexec.
    Chip may have been talking about programming time.

    I know when I looked at intel's MCU, it took 30+ seconds to program a meager 32K flash. (?!)
    I know that's not as fast as the more experienced MCU guys can manage, on a bytes/second basis, but it shows the general problem.
    Cluso99 wrote: »
    You are planning 16KB of ROM. Surely it would be simpler if this were 16KB or more Flash mapped into hub space? Why would it take more die space?
    Mapping Flash or OTP into hub space is non-trivial.
    You break the monolithic RAM compiler, and introduce more MUXs and likely need wait states, as well as now your FLASH block has to match the rules for HUB, which includes egg beater access.... *shudders*

    Present ROM is a serial block, that is moved into RAM.
    There may be an option to make that provided block OTP, but much more than that is impractical for P2.

  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    ...

    The thing is, we've probably spent $100k on layout for the 180nm process. It took several months to get that work done, not counting all my time just to tune our circuits for the 180nm process. Retargeting for 110nm would be expensive in every way.

    Sorry for my ignorance, but I thought the work done was to put it into software form, and that it used wider geometry, like -340nm. I had thought this could still be used around the outside ring without change using finer geometry like 110nm.
    If not, then I misunderstood. Clearly there's no way to go to 110nm then.
  • cgraceycgracey Posts: 14,133
    Cluso99 wrote: »
    cgracey wrote: »
    ...

    The thing is, we've probably spent $100k on layout for the 180nm process. It took several months to get that work done, not counting all my time just to tune our circuits for the 180nm process. Retargeting for 110nm would be expensive in every way.

    Sorry for my ignorance, but I thought the work done was to put it into software form, and that it used wider geometry, like -340nm. I had thought this could still be used around the outside ring without change using finer geometry like 110nm.
    If not, then I misunderstood. Clearly there's no way to go to 110nm then.

    For the 3.3V MOSFETs, you draw a longer gate (which means it looks wider) and you use a special layer to invoke a thicker oxide. I don't know what the 110nm process does exactly for 3.3V, but it's certainly similar, and might even be identical. One wire width/space rule change, though, can cause a whole bunch of stuff to need relayout. It's better to approach this later, once we've proven things and are selling chips. Then, we'll have revenue to do things better. It would be awesome if we could get down to 28nm someday. Imagine 1 GHz.
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    Cluso99 wrote: »
    Why would loading from internal Flash take longer?
    In fact, if it is hub flash, wouldn't in fact be quicker because it would not need to be loaded - it could be executed directly as hubexec.
    Chip may have been talking about programming time.

    I know when I looked at intel's MCU, it took 30+ seconds to program a meager 32K flash. (?!)
    I know that's not as fast as the more experienced MCU guys can manage, on a bytes/second basis, but it shows the general problem.
    Cluso99 wrote: »
    You are planning 16KB of ROM. Surely it would be simpler if this were 16KB or more Flash mapped into hub space? Why would it take more die space?
    Mapping Flash or OTP into hub space is non-trivial.
    You break the monolithic RAM compiler, and introduce more MUXs and likely need wait states, as well as now your FLASH block has to match the rules for HUB, which includes egg beater access.... *shudders*

    Present ROM is a serial block, that is moved into RAM.
    There may be an option to make that provided block OTP, but much more than that is impractical for P2.

    You explained it well.
  • cgracey wrote: »
    If I recall, the mask set for the 110nm process is 4x as expensive as the 180nm process. We are already going to spend $150k for masks which may even need redoing later. We're not spending $600k. We don't have it.

    Right. So enough talk from the peanut gallery about process changes. Let's get the current P2 to market and help Parallax make that $600K for the P3!
  • evanhevanh Posts: 15,126
    Yes. This is just the start.
Sign In or Register to comment.