3 ms·
Sure, and I agree with that goal. In fact I would like NVMe controllers to simply not exist. The operating system should manage raw flash, using host algorithms
by jeffbee 1y ago
Sure, and I agree with that goal. In fact I would like NVMe controllers to simply not exist. The operating system should manage raw flash, using host algorithms that I can study in the the source code.
- mixmastamyk 1y agoInteresting… I see no reason to be downvoted.
- nine_k 1y agoHow do you think it would be electrically connected to the CPU? Same thing with DDR5: the electrical layer is a beast, it's a reason enough to require its own controller.
- daneel_w 1y ago> How do you think it would be electrically connected to the CPU? On the CPU's PCIe bus. NVMe drives are PCIe devices, designed specifically to facilitate such interfacing. Edit: Pardon, misread the actual statement you responded to. Of course one shouldn't hook NAND directly to the CPU. I'll leave my response for whatever value the info has.
- gruturo 1y agoI'm with you, but.... no. At the level where the controller is operating, things are no longer digital. Capacity (as in farads, not bytes), voltage, crosstalk, debouncing, traces behaving like antennas, terminations, what have you. Analog values, temperature dependencies, RF interference. Stuff best dealt with custom logic placed as close as possible to it.
- jeffbee 1y agoThe physical interface controller can exist to that extent, of course. But I think the command interface it should present to the host system should be a physical one, not a logical translation. The host should be totally aware of the layout of the flash devices, and should command the things that the devices are actually capable of doing: erase this, write that, read this. We already see the demand for this in the latest NVMe protocol spec that allows the host to give placement hints. But this is a half-measure that suggests what systems really want, which is not to vaguely influence the device but instead to tell it exactly what to do.