← Back to context

Comment by jeffbee

2 days 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.

How 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.

  • > 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.

I'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.

  • The 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.