Author Topic: Why not CMOS?  (Read 6441 times)

0 Members and 1 Guest are viewing this topic.

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1764
  • Country: us
Re: Why not CMOS?
« Reply #25 on: February 01, 2022, 04:30:46 pm »
Battery-backed SRAM is still a thing. Thanks to EEPROM and flash, not as much as it used to be, but still.

Another use of battery-backed RAM that's going the way of the dodo is on RAID disk controllers. These typically have several GB of RAM that's used as a cache. If the power fails, all of the dirty data still in the cache will not be written to the disk(s) and this can lead to data loss and filesystem corruption. The traditional solution was to put a battery (NiCad at first, then NiMH, and then Li) on the controller and use it keep the RAM powered until power was restored, after which the contents of cache would be written to the disk(s). When I was at LSI working on MegaRAID controllers, we typically sized the batteries to power the cache RAM over a three-day weekend (which we considered the worst case). These batteries were much bigger than a coin cell, and were a major headache for operators of big data centers because the batteries would have to be replaced every few years.

The solution to the battery replacement problem was to move to a new approach where the battery is replaced by a supercapacitor and FLASH. The supercap stores enough charge to power the board for around 30 seconds, which is enough time to write all of cache RAM to FLASH. After that the controller could stay powered down indefinitely without losing data. When power is eventually restored, the controller will write the contents of the FLASH to the disk(s).
"That's not even wrong" -- Wolfgang Pauli
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 13216
Re: Why not CMOS?
« Reply #26 on: February 01, 2022, 04:31:29 pm »
FRAM has its own issues - reads are destructive i.e. during or after every read cycle the on-chip controller *MUST* re-write the location to preserve the contents.   If power glitches during a read cycle or drops out of spec, you can expect data corruption.   e.g. https://www.eevblog.com/forum/projects/the-other-downside-to-fram/
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 17427
  • Country: us
  • DavidH
Re: Why not CMOS?
« Reply #27 on: February 01, 2022, 09:49:49 pm »
The solution to the battery replacement problem was to move to a new approach where the battery is replaced by a supercapacitor and FLASH. The supercap stores enough charge to power the board for around 30 seconds, which is enough time to write all of cache RAM to FLASH. After that the controller could stay powered down indefinitely without losing data. When power is eventually restored, the controller will write the contents of the FLASH to the disk(s).

Before Flash memory existed we had SONOS which is what I used to replace the Dallas NVSRAMs in my Tektronix 2440 DSO.  It consists of a SRAM array in parallel with an EEPROM array and when power is lost, the entire SRAM array is copied into the EEPROM array in one step.

https://www.infineon.com/cms/en/product/memories/nvsram-non-volatile-sram/
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 17427
  • Country: us
  • DavidH
Re: Why not CMOS?
« Reply #28 on: February 01, 2022, 09:50:51 pm »
FRAM has its own issues - reads are destructive i.e. during or after every read cycle the on-chip controller *MUST* re-write the location to preserve the contents.   If power glitches during a read cycle or drops out of spec, you can expect data corruption.   e.g. https://www.eevblog.com/forum/projects/the-other-downside-to-fram/

And FRAM requires a precharge cycle on every read so it is not always a direct replacement for JEDEC SRAM.
 
The following users thanked this post: Ian.M

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Why not CMOS?
« Reply #29 on: February 03, 2022, 09:46:27 pm »
And FRAM requires a precharge cycle on every read so it is not always a direct replacement for JEDEC SRAM.

That's the issue I ran into. On a hardware level it is a direct replacement, but the software must be designed to meet the specific needs of FRAM.
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 10034
  • Country: gb
Re: Why not CMOS?
« Reply #30 on: February 03, 2022, 10:02:43 pm »
FRAM has its own issues - reads are destructive i.e. during or after every read cycle the on-chip controller *MUST* re-write the location to preserve the contents.   If power glitches during a read cycle or drops out of spec, you can expect data corruption.   e.g. https://www.eevblog.com/forum/projects/the-other-downside-to-fram/
Every FRAM device I know of has elaborate "anti-tearing" hardware inside, to ensure no read or write cycle ever starts unless there is enough energy on chip to complete it. This is designed and tested to deal with extreme EMI induced noise, as well as the power simply turning off. So, if you ever get corruption of an FRAM's contents, which you are certain was not due to the rest of your system doing dodgy writes when the power isn't clean, complain to the vendor.
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 17427
  • Country: us
  • DavidH
Re: Why not CMOS?
« Reply #31 on: February 03, 2022, 10:09:50 pm »
And FRAM requires a precharge cycle on every read so it is not always a direct replacement for JEDEC SRAM.

That's the issue I ran into. On a hardware level it is a direct replacement, but the software must be designed to meet the specific needs of FRAM.

I would not call it a software issue.  In practice it means that at the hardware level, -CS (chip select) must be toggled between every read access which is what activates precharge on a FRAM.  On a SRAM there is no such requirement and in some systems, continuous reads are done without togging chip select so those will not work with FRAM.
 

Offline Benta

  • Super Contributor
  • ***
  • Posts: 6420
  • Country: de
Re: Why not CMOS?
« Reply #32 on: February 03, 2022, 10:28:28 pm »
Before Flash memory existed we had SONOS which is what I used to replace the Dallas NVSRAMs in my Tektronix 2440 DSO.  It consists of a SRAM array in parallel with an EEPROM array and when power is lost, the entire SRAM array is copied into the EEPROM array in one step.

https://www.infineon.com/cms/en/product/memories/nvsram-non-volatile-sram/

SONOS blahblah. Infineon marketing.
The nvSRAM was made by ZMD (later ZMDI, acquired by Infineon at some point). Brilliant parts. IIRC, a US company was following the same idea, but I don't recall the name.
That Infineon presents itself as the great inventor here is laughable.
« Last Edit: February 03, 2022, 10:32:06 pm by Benta »
 

Offline srb1954

  • Super Contributor
  • ***
  • Posts: 1124
  • Country: nz
  • Retired Electronics Design Engineer
Re: Why not CMOS?
« Reply #33 on: February 03, 2022, 11:35:32 pm »
SONOS blahblah. Infineon marketing.
The nvSRAM was made by ZMD (later ZMDI, acquired by Infineon at some point). Brilliant parts. IIRC, a US company was following the same idea, but I don't recall the name.
That Infineon presents itself as the great inventor here is laughable.
Xicor had a chip, the XC22C12, that did this function nearly 30 years ago. It was quite small at only 1kbits but would still have been useful in many small systems.
« Last Edit: February 04, 2022, 12:05:07 am by srb1954 »
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 5050
  • Country: si
Re: Why not CMOS?
« Reply #34 on: February 04, 2022, 06:42:20 am »
We have FRAM chips that work like SRAM these days, like the Cypress CY15B102N:
https://www.infineon.com/dgdl/Infineon-CY15B102N_2-Mbit_(128K_X_16)_Automotive_F-RAM_Memory-DataSheet-v05_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ecf917749ed

Page 8 of the datasheet clearly mentions it as being a SRAM drop in replacement by using what they call "Page read" mode with no limitation of actually staying within a page or column, but you can increase the speed if you access it in the way the FRAM finds it convenient.

Not like parallel bus FRAM is all that relevant these days. Modern designs use MCUs that have everything they need inside so running a async memory bus on a PCB has fallen out of fashion due to the huge number of pins and board space it requires. So if you are going to use FRAM these days it will likely be SPI or QSPI interface. It still runs plenty fast (you can get 500Mbit/s from 133MHz QSPI) while they act pretty much like SPI SRAM where you can just start writing/reading at any location and keep going until the end of the memory area.

This detail is only really a factor in retrofitting battery backed SRAM with FRAM. I did replace all the battery backed SRAM chips with FRAM in a HP 3458A and it ran great, but in some of the other gear just sticking in FRAM indeed does not work due to how the CS is used and how fast the memory is running.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Why not CMOS?
« Reply #35 on: February 05, 2022, 08:25:48 pm »
I would not call it a software issue.  In practice it means that at the hardware level, -CS (chip select) must be toggled between every read access which is what activates precharge on a FRAM.  On a SRAM there is no such requirement and in some systems, continuous reads are done without togging chip select so those will not work with FRAM.

All of that is determined by software, at least in the systems I've seen. It would be easy enough to write the firmware to toggle the CS line between every access.
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 17427
  • Country: us
  • DavidH
Re: Why not CMOS?
« Reply #36 on: February 06, 2022, 12:16:35 am »
I would not call it a software issue.  In practice it means that at the hardware level, -CS (chip select) must be toggled between every read access which is what activates precharge on a FRAM.  On a SRAM there is no such requirement and in some systems, continuous reads are done without togging chip select so those will not work with FRAM.

All of that is determined by software, at least in the systems I've seen. It would be easy enough to write the firmware to toggle the CS line between every access.

I have never seen a system that allows firmware to change that behavior.  Decoding the high part of the address in hardware produces the chip select signal so repeated accesses to the same chip may or may not toggle chip select depending on exactly how the decoding is implemented.  Some systems always toggle chip select between accesses and some do not when sequential accesses are to the same chip.

What software could do is perform a read to a different chip between accesses to the FRAM, but this would fail for multiword accesses which would just have to be disallowed.

None of this matters in a legacy application.  Either it works or it doesn't because nobody is going to be modifying the firmware to fix it.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 5050
  • Country: si
Re: Why not CMOS?
« Reply #37 on: February 06, 2022, 08:29:51 am »
Yeah for system that use a parallel interface SRAM chip are typically legacy ones that have the CPU sitting directly on the memory bus, using that bus as its main memory. Some CPUs can do the CS correctly some cant. Lots can likely be fooled into doing it by inserting an read instruction from somewhere else in memory as the data bus is typically the same number of bits as the native word size of the CPU. What would be problematic is trying to run code from this FRAM as its impossible to avoid reading it in sequence.

That being said the FRAM chip i mentioned above does not need the CS to be toggled in order to work. You just get a speed penalty of running at about 1/3 full speed if you use like like SRAM. Even with that speed penalty this particular chip can run at 10MHz so still fast enough for most such legacy systems.
 

Offline cortex_m0

  • Regular Contributor
  • *
  • Posts: 116
  • Country: us
Re: Why not CMOS?
« Reply #38 on: February 06, 2022, 01:33:48 pm »
I worked on a product a few years ago that had ~200 bytes of configuration, plus some diagnostic logging, stored in an EEPROM (CAT24 type).

The EEPROM chip was rated 1 million erase/write cycles. Presumably that's actually per page, but let's assume it's for the whole chip. At 1 write cycle every hour, that's 114 years of continuous operation.

So as long as the firmware isn't treating a memory like that as a scratchpad, the limited write cycles are not a problem.
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 7508
  • Country: va
Re: Why not CMOS?
« Reply #39 on: February 06, 2022, 02:11:28 pm »
Quote
At 1 write cycle every hour

Everyone seems to quote something similar to this, but the fact is it's misleading. If you're using the storage to save config on shutdown, you're not doing one write cycle at all but however many bytes/pages/whatever your config takes up.

Quote
So as long as the firmware isn't treating a memory like that as a scratchpad

This is the crux of it, and Tesla shows that even competent professionals get it wrong sometimes. Not to mention:

Quote
plus some diagnostic logging

Oh boy! That kind of thing is just asking to wear out a chip in next to no time. When things go wrong you tend to get lots and lots of the same error sprayed at your logging console. OK, you say, it's not going to be the same as debug info, but on the other hand there isn't going to be a developer sitting there to pull the plug when it starts shouting, just some user who perhaps helpfully will be turning it off and on rapidly.

I am not saying it's always like that (and, indeed, you sound like yours was as designed), but these are areas that tend to catch developers out until after they realise they've made a mistake, which is generally a bit late.
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 17427
  • Country: us
  • DavidH
Re: Why not CMOS?
« Reply #40 on: February 06, 2022, 03:46:53 pm »
Yeah for system that use a parallel interface SRAM chip are typically legacy ones that have the CPU sitting directly on the memory bus, using that bus as its main memory. Some CPUs can do the CS correctly some cant.

The JEDEC specifications for parallel access memory do not require toggling the chip select line between accesses.  Common FRAMs violate this so they are not JEDEC compliant.  This only became a problem when FRAM became available.

Quote
Lots can likely be fooled into doing it by inserting an read instruction from somewhere else in memory as the data bus is typically the same number of bits as the native word size of the CPU.

Except for 8-bit processors, most of the legacy systems I have seen have a data bus width smaller than the CPU word length so routinely generate multiple memory cycles for the same access.

Quote
That being said the FRAM chip i mentioned above does not need the CS to be toggled in order to work. You just get a speed penalty of running at about 1/3 full speed if you use like like SRAM. Even with that speed penalty this particular chip can run at 10MHz so still fast enough for most such legacy systems.

It has a 90 nanosecond worst case access time after an address change initiated pre-charge so should work fine in most legacy JEDEC SRAM replacement applications.
 

Offline cortex_m0

  • Regular Contributor
  • *
  • Posts: 116
  • Country: us
Re: Why not CMOS?
« Reply #41 on: February 06, 2022, 04:56:49 pm »
Quote
So as long as the firmware isn't treating a memory like that as a scratchpad

This is the crux of it, and Tesla shows that even competent professionals get it wrong sometimes. Not to mention:

Tesla wouldn't be my first example for a company which puts quality first... as a long-time Chrysler owner, it must take serious ignorance of the matter to fall below Fiat-Chrysler in initial quality metrics.  :palm:

Tesla was using eMMC, which has several orders of magnitude fewer rated write cycles - perhaps 1000 to 5000 depending on the manufacturer and density. Doing one write per hour to eMMC is very different - under the same rules of estimation I used above, eMMC would last less than one year.
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 7508
  • Country: va
Re: Why not CMOS?
« Reply #42 on: February 06, 2022, 05:13:08 pm »
fair enough :)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf