P2 OTP vs ROM ?
Cluso99
Posts: 18,069
in Propeller 2
I noted previously that OTP is being used for the Security Fuses.
OTP uses OnSemi standard cells, just like the RAM.
ROM requires an additional mask. Does OTP save on this mask level? If so, is OTP cheaper?
I realise that OTP takes more space than ROM. Currently there is available die space.
Wouldn't OTP be better than ROM ? Or else a mix?
Could a tiny boot program be done via Verilog without requiring ROM ?
It is more conventional to use OTP and this would make the P2 better in the long run. Booting just needs to take into account the section of OTP for security.
OTP uses OnSemi standard cells, just like the RAM.
ROM requires an additional mask. Does OTP save on this mask level? If so, is OTP cheaper?
I realise that OTP takes more space than ROM. Currently there is available die space.
Wouldn't OTP be better than ROM ? Or else a mix?
Could a tiny boot program be done via Verilog without requiring ROM ?
It is more conventional to use OTP and this would make the P2 better in the long run. Booting just needs to take into account the section of OTP for security.
Comments
If we have OTP, then there is no requirement to have (fixed) boot code for external Flash/EEPROM or SD/FAT32 or whatever. This can all be programmed into the OTP. For some systems, external flash/sd may not even be required at all, depending on the OTP size.
The boot code needs to...
* check a few OTP bits for
--- unprogrammed/programmed OTP
--- security/no-security bit
--- enable/disable OTP programming
If unprogrammed, then it needs to enable some form of downloader/programmer for the OTP.
If security, then verify part of OTP meets security key, load OTP into hub ram and execute.
If no security, then load OTP into hub ram and execute.
OTP adds another yield area issue, and OTP needs to be programmed with extended loaders, so there is always some ROM needed.
However, I can see that some customers would like their own Loaders / IP in ROM, and some may even need no external loaders at all.
It would be useful to know the relative die areas of ROM and OTP, and any Vcc or operating restrictions OTP may have ?
MRAM for the win! ... Had to get another shot in there.
I think OTP is 4T (no idea how this works though) whereas RAM is 6T. But even presuming it was same size as RAM, there is easily space for 16KB of OTP, maybe more.
It should be possible to write Verilog code to do a tiny basic loader to be used for writing the OTP the first time. I am unsure how much die space this would take though.
Thinking about it, using OTP like this could make the P2 way more flexible, and even more secure, given the OTP holds the secure code and keys.
And of course, perhaps much simpler to implement, other than to basic boot/OTP program code.
Thanks Chip. While I knew that originally, somehow I thought it had changed to use OnSemi OTP.
Are the fuses in the P2 frame done by Treehouse?
The question still arises. Can the P2 use OnSemi OTP ?
There are 4 fuses in each I/O pad. Treehouse laid them out.
We are planning on using OnSemi logic cells, RAM, and ROM IP, but that's it.
Is avoiding OnSemi 1T OTP a licence/cost issue or are there other considerations?
(just trying to understand designing a chip constraints)
I never inquired about it. I just figured it was easiest to wrestle with their standard logic process, where they have routine shuttle runs and things. They do offer strict guidelines on laying out fuses, though, which we followed.
The links someone else gave, suggested there may be 2 OTP choices, one licensed in ~2012 and another ~2014 that mentioned compact OTP ?
These will be fully testable on the PAD Shuttle run ?
If they are going to be proven, and are already in 'spare space' in the PAD Ring (ie no nett die cost), then that's probably enough to keep them. If they fail testing, then OTP becomes a choice.
What are the expected programming times (one at a time?), and is that self-timed over PVT ?
Are Fuse yields expected to be 100% ?
Yes, fuse yields are going to be expected to be 100%. There will certainly be failures, but they should be rare, given what a small portion of they die they occupy.
They are blown by turning on a big 3.3V PMOS device. This was done so that reading them can always be referenced to ground. From what a few white papers stated, they should blow in about 10us...100us.
With OTP, Parallax will wait to write the "rom" image to burn to a later date and do updated reversion if needed.
And Parallax may even leave it blank for special customers who want do to something different on their own.
I hope you have better luck with your fuses than we did at company x where I used to work. If I remember correctly each fuse was really a pair for redundancy, and you still needed ecc outside. They didn't even bundle it all up as an easy to integrate block. Of course this was in 40 nm and below, but it was horrible. Manufacturing wanted OTP in every chip so they could track the chips. e.g. if a failure came back from the field they would know all about it including which revision of test vectors was used to verify it and which tester was used. But our group was able to wiggle out of using it for our high volume parts due to some of the voltage requirements which weren't consistent with what our customers wanted. (e.g. needing a 3.3V rail)