18 ms·

Unlikely. The cost savings probably wouldn't be as dramatic as you hope. You'd still need some sort of controller for serdes -- NAND flash chips tend to use bi

Unlikely. The cost savings probably wouldn't be as dramatic as you hope. You'd still need some sort of controller for serdes -- NAND flash chips tend to use big parallel busses which aren't suited for off-board connectors -- and, at that point, it's not that much of a jump to make that controller handle wear leveling and error correction. (Having the storage device handle those tasks is pretty convenient, anyways. It means you don't have to perform error correction on the main CPU -- which is a nontrivial ask -- and it means the SSD can behave as a bootable device.)

londons_explore 6y ago
Wear levelling and error correction are pretty different problems. Error correction is well suited to hardware, whereas wear levelling in my opinion is not. My ideal design would have basic hardware error detection and correction (hopefully configurable for how many data bits Vs ECC bits), and maybe with a few heirarchical levels. Wear levelling and management of data layouts would all be done in software. You could imagine a "bulk read" API which is given a block number to start at, with a bunch of ECC parameters, which would DMA a large block of error-corrected data to RAM, together with information about the error rate in each word/block read.
- st_goliath 6y ago
  > You could imagine a "bulk read" API which is given a block number to start at, with a bunch of ECC parameters, which would DMA a large block of error-corrected data to RAM, together with information about the error rate in each word/block read. There are a lot of existing SoCs that have built in flash controller hardware that can interface with an external flash chip and, from a driver perspective, are controlled pretty much the way you describe it.
sprash 6y ago
The margins on flash media are razor thin already. This is a high volume operation where subcents per unit count. If you can shave off a little more by using a dumb controller that does not contain any IP that needs to be licensed it is very easy to calculate how high the volume has to be in order to be profitable.
- duskwuff 6y ago
  Consider that Olympus/Fujifilm tried this in the early 2000s with XD-Picture Card. (The cards were literally just a NAND flash chip wired up to the pins.) Even though this theoretically reduced the BOM cost for the cards, XD lost in the market to other solutions like Compact Flash and SD, which embedded a controller.
  - sprash 6y ago
    xD failed because it was a proprietary standard used exclusively by FujiFilm and Olympus and were generally more expensive to the consumers than the completely open and free SD-format. The lack of a flash translation layer was a major advantage.

londons_explore 6y ago

Wear levelling and error correction are pretty different problems. Error correction is well suited to hardware, whereas wear levelling in my opinion is not. My ideal design would have basic hardware error detection and correction (hopefully configurable for how many data bits Vs ECC bits), and maybe with a few heirarchical levels. Wear levelling and management of data layouts would all be done in software. You could imagine a "bulk read" API which is given a block number to start at, with a bunch of ECC parameters, which would DMA a large block of error-corrected data to RAM, together with information about the error rate in each word/block read.

st_goliath 6y ago
> You could imagine a "bulk read" API which is given a block number to start at, with a bunch of ECC parameters, which would DMA a large block of error-corrected data to RAM, together with information about the error rate in each word/block read. There are a lot of existing SoCs that have built in flash controller hardware that can interface with an external flash chip and, from a driver perspective, are controlled pretty much the way you describe it.

sprash 6y ago

The margins on flash media are razor thin already. This is a high volume operation where subcents per unit count. If you can shave off a little more by using a dumb controller that does not contain any IP that needs to be licensed it is very easy to calculate how high the volume has to be in order to be profitable.

duskwuff 6y ago
Consider that Olympus/Fujifilm tried this in the early 2000s with XD-Picture Card. (The cards were literally just a NAND flash chip wired up to the pins.) Even though this theoretically reduced the BOM cost for the cards, XD lost in the market to other solutions like Compact Flash and SD, which embedded a controller.
- sprash 6y ago
  xD failed because it was a proprietary standard used exclusively by FujiFilm and Olympus and were generally more expensive to the consumers than the completely open and free SD-format. The lack of a flash translation layer was a major advantage.