@slymeat The primary intent of my earlier post was to encourage more critical analysis of the third-party information/commentary being shared on SM in support of the Weebit thesis. My critique of Weebit-related commentary was not intended as a personal attack, but was perhaps clumsily worded and not specific enough to be constructive for which I apologise. I'll try do better in this post, and hope that my words are read in the spirit of good faith critique/discussion in which they are intended and not as a personal attack.
In the interest of continuing a more concrete and productive discussion, I'll do a quick pass over the Electronic Specifier article and your straw to provide a more detailed and hopefully useful critique. I'll also note again that I am no expert in this space and have more questions than facts/answers to offer.
--------------------------------------------------------------------------------
Publisher
The article was published in a free magazine put out by ES, who would appear to use the publication as a way to earn revenue from electronics suppliers looking to generate product awareness and sales. The article provides no editorial scrutiny or context at all, and simply lets Weebit's Director of Product Marketing define the narrative, which is a partial regurgitation of a page on their website.
Flash
The article and many Weebit straws talk about flash as if it is one technology with a specific set of properties, but it is in fact an umbrella term for a whole group of technologies that have been continually refined over decades e.g. NAND vs NOR, single- vs multi- vs triple- vs quadruple- level cells, 2D vs 3D spatial orientation, different chemistries and fabrication processes, etc.
To make assertions like flash is an old stagnant technology, or that "typical flash" draws 100x more power during programming, demonstrates a lack of nuanced understanding and/or wilful oversimplification.
NVM use cases
There are probably too many NVM use cases with differing requirements to count. The article claims to be focused on the data logging space, which is barely a focus at all given the breadth of data logging use cases and requirements. For example, I would guess most data logging use cases don't have to worry about high levels of radiation, so this asserted benefit of ReRAM is only narrowly relevant. You assert that the article explains how ReRAM is a superior technology to flash without any qualification of use case and requirements. At best, the article could be said to make a case for considering the use of ReRAM in some data logging applications once it becomes commercially available.
NVM addressing & programming
As far as I understand, your commentary on flash erasure/addressing and suggestion that Weebit's selector somehow offers an advantage to ReRAM over "flash" in this regard conflates a number of concepts and is misguided.
Addressing in this context is a logical function that gives host software an abstract, common way of referencing some finite amount of data (exact number of bits depends on system architecture) in the memory array. The array controller is responsible for mapping an address to the physical cell(s) in the array that hold the data.
Let's baseline our mental model of a NAND flash device using this (simplified) diagram and description which I believe is sufficiently accurate for the job. One relevant detail not shown are the individual cells within each page, where each cell can hold one (SLC) or more (MLC,TLC,QLC,...) bits.
I believe Weebit's selector operates at the cell level i.e. selects one or more individual cells within a page to be active for a given operation. Taking them at their word, their research results suggest that their selector design allows for tighter spacing of cells than traditional transistor-based selector designs, and therefore better physical density of cells within a given area of silicon.
That is indeed a fine thing, but their selector has no bearing on the number of pages that read/write/erase operations apply to, or the number of addresses required to reference a given amount of data. For various technical reasons, I assume ReRAM cells will still be arranged in pages, pages into blocks, etc. similar to typical NAND flash devices, and therefore the erase operation will still not be capable of operating on an individual cell.
Endurance
There seems to be confusing guidance and contradictory statements about cell endurance. Weebit claim 10x-100x better endurance than typical flash's 10k cycles, but the production SkyWater specs state 10k-100k cycles. There's also a big difference between 10k and 100k - which is it? Their endurance superiority claims also appear to be FUD given that a Google search for "high endurance nand flash PE cycle" comes up with plenty of reading and product pointers.
The other thing about endurance is that it has become less and less of an issue as controllers (and the firmware which runs on them) have been improved over time. Intelligent wear leveling ensures that for many write-intensive applications, the endurance of the flash is not the primary factor limiting the device's useful working life.
Security
I would characterise the article's security discussion as FUD. A core tenet of digital security best practice is that if someone can gain physical access to your device, most if not all bets are off i.e. if someone can get close enough to monitor electric field emissions from a comms bus or shine a laser beam on your NVM, you've got bigger problems.
If someone can gain remote access to your device because it is attached to some sort of network, the physical attacks described are presumably not possible and you're reliant on software/information security mechanisms such as process isolation and data authentication/encryption rather than the electrical characteristics of your NVM.
Cost
I assume the cost delta asserted is theoretical given that the well trodden manufacturing processes and economies of scale that exist today for commodity types of flash don't exist today for ReRAM production?
--------------------------------------------------------------------------------
I'll pause here and welcome any further discussion.