CMIS — gestione comune

CMIS, la Common Management Interface Specification, è il modello di gestione per ogni nuovo fattore di forma ad alta velocità: QSFP-DD, OSFP, OSFP-XD, QSFP112, SFP-DD e SFP112 (come SFP+ con CMIS), DSFP, COBO e QSFP compatibile con CMIS. È nato nell’MSA QSFP-DD (CMIS 3.0, 2018), è stato adottato dai gruppi OSFP e COBO e dalla versione 5.0 (2021) è mantenuto dall’OIF. Rispetto a SFF-8636 non è una mappa di memoria più grande, ma un modello diverso: pagine a banchi per un massimo di 32 lane, macchine a stati esplicite per il modulo e per ogni percorso dati, applicazioni al posto dei campi di bit di conformità, diagnostica versatile (VDM) e un canale di comandi (CDB) per firmware e funzioni estese. Byte di versione e cronologia: Revisioni della specifica.

Modello di memoria

Un banco indirizza 8 lane: il banco 0 le lane 1–8, il banco 1 le lane 9–16 e così via; quanti sono implementati è annunciato nella pagina 01h. I moduli con solo la pagina 00h impostano il bit di memoria piatta (byte 2 bit 7). Bus: indirizzo singolo A0h, fino a 400 kHz, ModSelL per slot — interfaccia a due fili.

Pagina inferiore — i byte con cui lavora l’host

Macchina a stati del modulo

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

• MgmtInit — il modulo avvia il proprio controller; l’identità non è ancora leggibile (fino a 2 s secondo le specifiche hardware).
• ModuleLowPwr — identità, annuncio e soglie sono leggibili; la potenza è limitata alla classe 1; qui l’host convalida il modulo.
• ModulePwrUp → ModuleReady — l’host disattiva il pin LPMode (o azzera LowPwrRequestSW) e il modulo alimenta la propria ottica; i percorsi dati possono ora essere inizializzati.
• ModulePwrDn — l’inverso, all’attivazione di LPMode.

Un modulo che non esce mai da LowPwr è il classico ticket CMIS: Problemi di CMIS, Alimentazione e termica.

Applicazioni e il percorso dati

Invece di bit di conformità, un modulo CMIS annuncia le applicazioni — coppie di interfaccia elettrica host e interfaccia media, con il numero di lane:

L’host sceglie un’applicazione per lane scrivendo AppSel (bit 7–4), un DataPathID (bit 3–1) e il bit di controllo esplicito nello Staged Control Set 0 (pagina 10h, byte 145–152), poi attiva ApplyDPInit (pagina 10h, byte 143). Il modulo risponde in ConfigStatus (pagina 11h, byte 202–205: accettato, rifiutato, AppSel non valido, combinazione di lane non valida…) e copia i valori accettati nell’Active Control Set (pagina 11h, 206–221). Ogni percorso dati percorre quindi la propria macchina a stati:

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

Gli stati sono riportati per lane nella pagina 11h, byte 128–131 (un nibble per lane), e le durate massime di ogni passaggio sono annunciate nella pagina 01h, così l’host sa quanto attendere. La disattivazione di Tx per lane si trova nella pagina 10h, byte 130. Un breakout che il modulo non elenca come applicazione semplicemente non è disponibile — Velocità e rate.

Monitoraggio: flag, monitor, VDM

• I monitor del modulo (pagina inferiore 14–25) e i monitor di lane (pagina 11h: potenza Tx 154–169, bias Tx 170–185, potenza Rx 186–201, 2 byte per lane) usano gli stessi formati a 16 bit di SFP/QSFP (unità).
• Le soglie sono sulla pagina 02h; i flag vengono mantenuti con latch e azzerati alla lettura, con una maschera per flag; IntL segnala qualsiasi flag non mascherato.
• VDM (pagine 20h–2Fh) aggiunge osservabili che le vecchie specifiche non hanno mai avuto: BER pre-FEC, frame FEC non correggibili, SNR per lane, temperatura ed età del laser, eSNR, parametri di transizione del livello PAM4 — ciascuno con il proprio descrittore, soglie e flag. È così che un modulo a 400G riporta la qualità del collegamento prima che gli errori raggiungano l’host (Monitoraggio).

CDB — blocco dati di comando

La pagina 9Fh è una mailbox: l’host scrive un ID del comando (byte 128–129), le lunghezze del payload (130–132), un checksum (133) e fino a 120 byte di payload locale (136–255), eventualmente altri nelle pagine EPL A0h–AFh; il modulo esegue e riporta nei byte di stato 37–38 e in un payload di risposta. I comandi standard includono:

CDB è il modo in cui gli strumenti del produttore aggiornano il firmware del modulo sul campo e in cui alcuni produttori implementano funzioni di configurazione e sblocco. Il supporto e le funzionalità sono annunciati nella pagina 01h.

Checksum e password

Il byte 222 della pagina 00h calcola il checksum dei byte 128–221; le pagine 01h, 02h e 04h portano un checksum di pagina nel byte 255 (Checksum). Le password (122–125) e gli schemi di sblocco del produttore sono fuori dalla specifica — Ricodifica EEPROM.

Supporto dell’host

I sistemi operativi di rete implementano CMIS 4.0 e 5.x con profondità diverse: alcuni gestiscono l’intero flusso applicazione/percorso dati, altri rilasciano LPMode e si aspettano che il modulo si avvii da solo. Questa differenza è dietro alla maggior parte dei ticket «riconosciuto ma mai pronto» — Problemi di CMIS, Cosa fa l’host.

In CodingBox

CodingBox rileva CMIS dall’identificatore e dal byte di revisione, legge la memoria inferiore, le pagine 00h, 01h, 02h e le pagine di lane a banchi, decodifica i descrittori di applicazione confrontandoli con SFF-8024, mostra gli stati del modulo e del percorso dati e i monitor per lane su DDM, e modifica l’identità con i checksum di pagina ricalcolati nell’EEPROM editor. Le operazioni sul firmware tramite CDB sono specifiche del produttore e fuori dall’ambito dell’editor.

Tabelle a livello di registro: Mappa della pagina inferiore, Mappa delle pagine superiori 00h/01h/02h, Mappa delle pagine di lane 10h/11h, VDM, CDB.