TLC+SLC

[Funny-Boy-Max]

Can the black-box mode support simulated TLC+SLC mixed SSD?

[huaicheng]

Yes, FEMU can be extended to do so but its current FTL doesn't have corresponding logics.

What you need to do is to implement your data placement policies on SLC and TLC.

[huaicheng]

Partly, with a caveat worth being clear about.

nand_cell_type (1 SLC .. 4 QLC) plus cell_pages selects a cell type for the device, and the media layer then applies per-page-type read/program latencies for that type:

-device femu,...,femu_mode=1,nand_cell_type=1              # all-SLC
-device femu,...,femu_mode=1,nand_cell_type=3,cell_pages=3 # all-TLC

What is not modelled is a hybrid part — an SLC write cache in front of TLC, with data folded from one to the other. nand_cell_type is device-wide, so you cannot presently mark some blocks SLC and the rest TLC, and there is no fold/migration path between them.

If you want the timing shape of an SLC cache today, the closest thing is the bbssd write buffer (buffer_size, in pages), which absorbs writes at DRAM latency and programs them later — it models the deferral, not the SLC media.

Leaving this open as a real feature gap.

[maxDeveloper42]

Hi @huaicheng , thanks for the detailed explanation – really appreciate it.

I'm actually want to try to implement this hybrid SLC+TLC thing mostly for my own curiosity and learning, not for any formal project.

Since I'm pretty new to FEMU, I was wondering which layer you think would be the best place to achieve this feature?

Looking forward to your thoughts when you have a moment.

[Funny-Boy-Max]

你好@huaicheng谢谢你的详细解释，非常感谢。

我其实想尝试实现这种混合 SLC+TLC的方法，主要是为了满足自己的好奇心和学习兴趣，而不是为了任何正式项目。

由于我对 FEMU 还不太熟悉，我想知道您认为在哪一层实现这个功能最合适？

期待您有空时分享一下您的想法。

Hi，an SLC+TLC hybrid solution has been realized utilizing the FEMU platform. Researchers wishing to conduct performance investigations are invited to access the repository at: https://github.com/Funny-Boy-Max/Hybrid_FEMU". Relevant literature is available here: “Hook: A pattern locality guided prefetch with enhanced read performance for hybrid SSDs”

[maxDeveloper42]

@Funny-Boy-Max
Thx! I will carefully learn your code and read your paper. I would be glad to have further communication and explore possible collaboration in the future.

[Funny-Boy-Max]

@Funny-Boy-Max Thx! I will carefully learn your code and read your paper. I would be glad to have further communication and explore possible collaboration in the future.

For inquiries, please feel free to contact us via email at mailto: zhaoyumiao99@gmail.com.

[Funny-Boy-Max]

Partly, with a caveat worth being clear about.

nand_cell_type (1 SLC .. 4 QLC) plus cell_pages selects a cell type for the device, and the media layer then applies per-page-type read/program latencies for that type:

-device femu,...,femu_mode=1,nand_cell_type=1              # all-SLC
-device femu,...,femu_mode=1,nand_cell_type=3,cell_pages=3 # all-TLC

What is not modelled is a hybrid part — an SLC write cache in front of TLC, with data folded from one to the other. nand_cell_type is device-wide, so you cannot presently mark some blocks SLC and the rest TLC, and there is no fold/migration path between them.

If you want the timing shape of an SLC cache today, the closest thing is the bbssd write buffer (buffer_size, in pages), which absorbs writes at DRAM latency and programs them later — it models the deferral, not the SLC media.

Leaving this open as a real feature gap.

Thank you for your further response！

[huaicheng]

@Funny-Boy-Max thanks for sharing Hybrid_FEMU and the Hook paper — that is the most direct starting point for anyone wanting this today.

@maxDeveloper42 on where to put it, the short answer is: one line decides the timing, and the rest is allocation policy.

Timing. bb_decode_loc() in hw/femu/bbssd/ftl-media.c is the single place a cell type becomes a latency — it fills NandLoc.flash_type from the device-wide n->nand_cell_type. The media layer below it (hw/femu/nand/nand-media.c) already indexes everything by that field (rd_table_ns[flash_type][page_type], wr_table_ns, er_table_ns, from hw/femu/nand/nand.c). So if you store a cell type per block in struct nand_block (hw/femu/bbssd/ftl.h) and read it there instead of the device property, per-block SLC/TLC timing works with no changes to the timing model itself.

Allocation and folding. There is already a multi-write-pointer mechanism: ssd_write_pointer_for_class() / get_new_page_class() in hw/femu/bbssd/ftl-line-gc.c, used today for log and hot/cold. Add an SLC class and a TLC class, point host writes at SLC, and fold with the existing collection path — reclaim_line() already relocates valid pages through a write pointer, so an SLC→TLC fold is a collection whose destination is the TLC class. should_gc_high() is the shape to copy for the "SLC is filling up" trigger.

The one real trap is capacity, not timing. An SLC block holds a third of a TLC block's data, but FEMU's geometry is uniform — pgs_per_blk is global and capacity is derived from it in hw/femu/bbssd/ftl-geom.c. Modelling the true capacity asymmetry means making usable pages per block vary, which touches the geometry and capacity accounting. If you only care about the latency behaviour, keep the page counts uniform and vary just the timing; that is far less invasive and is usually enough.

Worth saying plainly: this is a design change rather than a missing knob, so it belongs as a feature PR rather than something nand_cell_type can be stretched to cover.