CMIS — common management

CMIS, the Common Management Interface Specification, is the management model for every new high-speed form factor: QSFP-DD, OSFP, OSFP-XD, QSFP112, SFP-DD and SFP112 (as SFP+ with CMIS), DSFP, COBO and CMIS-capable QSFP. It began in the QSFP-DD MSA (CMIS 3.0, 2018), was adopted by the OSFP and COBO groups, and since version 5.0 (2021) is maintained at the OIF. Compared with SFF-8636 it is not a bigger memory map but a different model: banked pages for up to 32 lanes, explicit state machines for the module and each data path, applications instead of compliance bit fields, versatile diagnostics (VDM) and a command channel (CDB) for firmware and extended functions. Version byte and history: Specification revisions.

Memory model

A bank addresses 8 lanes: bank 0 lanes 1–8, bank 1 lanes 9–16 and so on; how many are implemented is advertised in page 01h. Modules with only page 00h set the flat memory bit (byte 2 bit 7). Bus: single address A0h, up to 400 kHz, ModSelL per slot — two-wire interface.

Lower page — the bytes a host lives on

Module state machine

Reset ──► MgmtInit ──► ModuleLowPwr ──► ModulePwrUp ──► ModuleReady
                            ▲                              │
                            └──────── ModulePwrDn ◄────────┘
                       (ModuleFault from any state on a fatal error)

• MgmtInit — the module boots its controller; identity is not yet readable (up to 2 s per the hardware specs).
• ModuleLowPwr — identity, advertising and thresholds readable; power limited to class 1; the host validates the module here.
• ModulePwrUp → ModuleReady — the host deasserts the LPMode pin (or clears LowPwrRequestSW) and the module powers its optics; data paths can now be initialised.
• ModulePwrDn — the reverse on an LPMode assertion.

A module that never leaves LowPwr is the classic CMIS ticket: CMIS issues, Power & thermal.

Applications and the data path

Instead of compliance bits, a CMIS module advertises applications — pairs of host electrical interface and media interface, with lane counts:

The host picks an application per lane by writing AppSel (bits 7–4), a DataPathID (bits 3–1) and the explicit-control bit into the Staged Control Set 0 (page 10h bytes 145–152), then asserts ApplyDPInit (page 10h byte 143). The module answers in ConfigStatus (page 11h bytes 202–205: accepted, rejected, invalid AppSel, invalid lane combination…) and copies the accepted values into the Active Control Set (page 11h 206–221). Each data path then walks its own state machine:

DPDeactivated ──► DPInit ──► DPInitialized ──► DPTxTurnOn ──► DPActivated
       ▲                                                          │
       └────────── DPDeinit ◄───────── DPTxTurnOff ◄──────────────┘

States are reported per lane in page 11h bytes 128–131 (one nibble per lane), and the maximum durations of each step are advertised in page 01h so the host knows how long to wait. Tx disable per lane lives in page 10h byte 130. Breakout that the module does not list as an application is simply not available — Speed & rate.

Monitoring: flags, monitors, VDM

• Module monitors (lower page 14–25) and lane monitors (page 11h: Tx power 154–169, Tx bias 170–185, Rx power 186–201, 2 bytes per lane) use the same 16-bit formats as SFP/QSFP (units).
• Thresholds are on page 02h; flags are latched and cleared on read, with masks per flag; IntL signals any unmasked flag.
• VDM (pages 20h–2Fh) adds observables the old specs never had: pre-FEC BER, uncorrectable FEC frames, SNR per lane, laser temperature and age, eSNR, PAM4 level transition parameters — each with its own descriptor, thresholds and flags. This is how a 400G module reports link quality before errors reach the host (Monitoring).

CDB — Command Data Block

Page 9Fh is a mailbox: the host writes a command ID (bytes 128–129), payload lengths (130–132), a checksum (133) and up to 120 bytes of local payload (136–255), optionally more in the EPL pages A0h–AFh; the module executes and reports in status bytes 37–38 and a reply payload. Standard commands include:

CDB is how vendor tools update module firmware in the field and how some vendors implement configuration and unlock functions. Support and features are advertised in page 01h.

Checksums and passwords

Page 00h byte 222 checksums bytes 128–221; pages 01h, 02h and 04h carry a page checksum in byte 255 (Checksums). Passwords (122–125) and vendor unlock schemes are outside the specification — EEPROM recoding.

Host support

Network operating systems implement CMIS 4.0 and 5.x to varying depth: some drive the full application/data-path flow, others release LPMode and expect the module to bring itself up. The difference is behind most "recognised but never ready" tickets — CMIS issues, What the host does.

In CodingBox

CodingBox detects CMIS by identifier and revision byte, reads lower memory, pages 00h, 01h, 02h and the banked lane pages, decodes application descriptors against SFF-8024, shows module and data-path states and per-lane monitors on DDM, and edits identity with page checksums recalculated in the EEPROM editor. Firmware operations over CDB are vendor-specific and outside the editor's scope.

Register-level tables: Lower page map, Upper pages map 00h/01h/02h, Lane pages map 10h/11h, VDM, CDB.