Typically the Host and NAND interface have custom hardware. When the host issues a command, the hardware might validate it and queue up data to a buffer. On the NAND interface there might be a similar queue for NAND commands. You might have multiple queues for different priorities of operation. The error correct will also be in hardware. When you issues NAND reads and writes, the ECC will be checked or encoded. The rest of the FTL might all be in firmware. Perhaps a single core does everything. Or maybe its partitioned between two cores, one for the host related code and the other for the FTL related. Some companies have tried lots of cores, each with a dedicated state machine to handle some part of the operation. These can be complex to coordinate their operation and to debug. Some companies convert some of these state machines into custom hardware.
The only open SSD platform I've read about is http://openssd.io/ but I've never played with it. One of the challenges is the NAND manufacturers a lot of the critical documentation under an NDA these days. You really need that information to make a reliable SSD. When you learn how the internals of an SSD work, its a wonder that it retains data at all!
In terms of integrating SSD with the higher software level, I believe FusionIO was doing this in the past. They put the whole logical to physical mapping into the host memory.
