Specification revisions & version bytes

Specifications are living documents. A module declares which revision its memory map follows, and a host parses the map according to the revision it knows. Most of the time the two agree well enough; when they do not, a byte gets read as something it is not. This page lists the version bytes, how to decode them, and — roughly — what each generation added, so that you can tell whether a field you are looking at even exists for the module in front of you.

Where the version is declared

SFF-8472 — byte 94

Rule of thumb: a module claiming 08h or 09h must have byte 36 meaningful (or zero) and the ×250 Mb/s rate in byte 66 when byte 12 = FFh; a module claiming 03h or below has no byte 36 semantics at all — hosts ignore it.

SFF-8636 — byte 1

Hosts that predate rev 2.0 will not look at byte 192 — a 100G module in a 40G-era switch is "unknown" for that reason alone, whatever the vendor block says.

CMIS — byte 1

A CMIS 5.x module in a host that implements 4.0 usually works for the basic flow (state machine, application select) but the host will not read newer VDM pages; a 3.0-only host may fail to bring up a 5.x module at all — CMIS issues. MIS versions track CMIS: MIS.

Compatibility rules

• Newer module, older host — unknown codes decode as unknown; a higher byte 94 / byte 1 value is normally tolerated. Problems start when the host needs a field that only exists in the new revision (byte 192, applications).
• Older module, newer host — fine; hosts keep backward parsing.
• Claimed revision inconsistent with content — the real trap. Declaring 12.x with an empty byte 66 while byte 12 = FFh gives a host "0 Gb/s"; declaring rev 2.0+ with garbage in byte 192 gives unknown type. When coding, set the revision byte to match the fields you actually use.
• SFF-8024 has no version byte in the module; the host's table revision decides which codes it can name.

Other documents and their cadence

Document numbers and titles: MSA specification catalog.

In CodingBox

CodingBox reads the revision byte first and applies the matching field definitions, so fields that do not exist for the declared revision are shown as reserved rather than mis-labelled. The EEPROM editor lets you set the revision byte together with the fields it governs.