P2 Flash - Is it possible with On Semi ?
Cluso99
Posts: 18,069
I noticed that On Semi make Flash Memory (they acknowledge a license to another manufacturer).
I wondered if this process is available to Parallax and if so, would there be enough room on the die to add a small amount (say 4KB+) for boot code?
The boot code could then either contain the monitor or boot from SPI Flash or SD or whatever.
There are probably many reasons not to do this, in particular delays, but thought it was worth asking anyway.
I wondered if this process is available to Parallax and if so, would there be enough room on the die to add a small amount (say 4KB+) for boot code?
The boot code could then either contain the monitor or boot from SPI Flash or SD or whatever.
There are probably many reasons not to do this, in particular delays, but thought it was worth asking anyway.
Comments
For a tiny amount, it is not worth it.
I think OTP is more possible/practical, ( see XMOS), but that is also a separate cell.
The trade off is more cells is more die area, and more to go wrong.
The Present boot rom, is hand-stuck RAM cells, which is compact and fast and simple.
Downside, is the manual patching, and so changes are (I think) not even top-metal only as most ROM is, but need a multiple layer re-spin.
That means checking ROM is going to be very important.
That means checking ROM is going to be very important." - It doesn't really matter what layer it is, you still have to fabricate ALL layers. We have however created our ROM cell, so that it can be set to a "1" or cleared to a "0" depending on the position of a contact .... or single layer ... which means that only one mask needs to be changed. The ROM bits (contacts) are also placed with a script, so any changes can be automated in just a couple of seconds.
As far as Flash or OTP, your right, that means more layers, and more layers equals more $$$. Additionally, the current process that we have targeted does not support Flash without significant changes.
In classic ROM parts, that was a top layer. Which layer is it in the Prop 2
Short term it does not matter much, but longer term you may find volume customers, willing to pay the mask prices.
I guess that works for any size ROM ?
Is that flow die-proven / tested yet - or did the last pass not allow that level of testing ?
"Is that flow die-proven / tested yet - or did the last pass not allow that level of testing ?" - A similar script was used for an earlier test die and yes that proved to be correct. The same script was used for that as was in P2, but the pitch and step positions were adjusted accordingly.
See
http://www.onsemi.com/PowerSolutions/content.do?id=16558
Some interesting split voltages shown in the tables there.
http://www.onsemi.com/PowerSolutions/content.do?id=16617
http://www.onsemi.com/PowerSolutions/content.do?id=16622
OnSemi also has the ex-Sanyo Microcontroller & other semi lines
http://www.onsemi.com/PowerSolutions/taxonomy.do?id=101533
The process points also apply to MRAM, which, imho, is by far the superior option over Flash since it would fully replace HubRAM but at a higher density.
Multi-ported MRAM anyone? Build CogRAM out of it too ...
?? You mean Magnetic memory ? - that needs extra fab steps and it has speed and lifecycle issues.
High MHz is going to be one of the important leverage points of P2, and that excludes FLASH.
SRAM is really the only choice, cheap and fast and proven.
Other companies do that, but their flash size decisions tend to be defined for them (eg FPGA).
In Prop 2, it gets hard to compete in price on the smallest Flash parts, and for larger flash, finding room and selecting a size make it hard to hit critical mass in a product-line basis.
Because RAM is so valuable (/costly), during discussion on ROM size, there was talk of a separate boot-device, but you still need some tiny ROM to talk to that, so the final choice of 'smallest practical' ROM is best.
Chip seemed to always pack more into less space, and I'm not sure of the final ROM size post-threading.
It does mean Fonts and Spin have to go from the ROM, but they can be more compile-time managed.
I see some long term potential with large customers in the Prop 2 ROM flows, but first get a std part working....
But doesn't exclude MRAM.
MRAM is a good choice for many reasons but it's also more expensive for the time being.
Which MRAM are you talking about ?
I see Everspin give a lower clock speed for read, unlike most other technologies, maybe because read needs the sense-amps ?
In their parallel series there is nothing showing under 35ns.
I was of course talking about number of writes (wearing the part out), nothing at all to do with access times. That said, while I can't say for sure how fast MRAM would be as a process replacement for HubRAM your reference is like comparing external SRAM chips with internal caching, not quite apples with apples.
The claims are that MRAM is close to SRAM access speeds on a one-to-one footing. Most super fast SRAM these days will be using much finer processes than 180 nm. What is the expected access times for the Prop2 HubRAM SRAM cells?
To avoid any talk of wait-states, it needs to be <5ns cycle times to allow adjacent 200MHz COG slots.
MRAM is academic, is it too expensive, so no one checked the speed, but that looks to be too slow as well.
Given it has to read a magnetic state, it is no real surprise it is slower. (cheap SRAM comes down to 8ns, async)
Either shortcoming is enough to kill it, it does not take both.
What Chip & Beau have done for the small ROM is to effectively hardwire the SRAM, so the SRAM layout done only had minimal changes. This is again, quite smart.
For anyone interested, IIRC it is in the main Prop thread.
Can we close this discussion now.