Software engineers can sometimes find it difficult as with a HDL you (should) describe hardware that exhibits the intended behaviour, rather than just directly describing the behaviour.
HDLs have familiar syntax that makes it seem like you can just program algorithms imperatively (for loops, if statements, functions etc) but it's all just a mean trick to catch software people out, and generally won't give the results you expect.
On top there's then the fact everything happens at the same time, the faff of making everything synchronised and making sure it meets timing and fighting the frankly awful tooling every step of the way.
Once you get it, it's fine, but you have to unlearn a lot of software muscle memory and keep the actual design work (boxes and lines) almost entirely separate from the implementation (typing your boxes and lines into a text editor).
Airborne Electronic Hardware Design Assurance: A Practitioner's Guide to RTCA/DO-254 by Randall Fulton and Roy Vandermolen
Might sound a bit niche, and it is, but even if you ignore the stuff about actually certifying stuff to fly, it has some extremely useful and interesting tidbits about how to go about running very large and highly complex hardware/firmware projects in safety critical industries.
The chapter on requirements is especially useful, and the whole thing is written in a (relatively, for the topic) light-hearted way.
I love seeing teardowns of old space tech. Having worked on safety critical projects I know that if something is proven and works it is generally not replaced unless something substantially better comes along, so I wonder if the soyuz still flies with these electromechanical wonders.
These perovskites are notoriously difficult to deposit at scale in a uniform enough layer to be effective, with small variances causing dramatic drops in efficiency.
On the cool side, it's theoretically possible to make them translucent (without the silicon substrate ofc) which could make for cool power generating windows in the future.
On the not so cool side you really don't want the materials anywhere near you or your water table in the event of a panel being damaged. Lead halide perovskites, methylammonium lead iodide, are insanely toxic and a race to the bottom on price if they become widespread could be an environmental disaster waiting to happen.
Not to take from the achievements described here, but there isn't any mention of it. There is some hope in taking the lead out (tin based perovskites) but that tends to result in a drop in efficiency.
On the whole, at this point in time, I agree. For general purpose NVM stuff you're better off going with the less exotic, but SRAM isn't suitable for this specific use case. Some eNVMs are essentially analogue (CBRAM, OxRAM, PCM etc) whereby you can partially set a single memory cell much like a variable resistor. MRAM obviously had its specific two states so is unsuitable for neuromorphic computation, and SRAM is the same.
I disagree though that 22nm is the limit for (STT) MRAM and ReRAM, they both have excellent scalability.
SRAM scales nicely but is volatile, takes up lots of area and obviously isn't BEOL compatible. You can stack MTJs between metal layers just fine.
https://en.wikipedia.org/wiki/Royal_cypher