Module Interface Standards¶
This group defines the conventions used to describe μForge module interfaces. Start here before committing a carrier-board connector, pin map, or compatibility claim. It contains two different kinds of documents: a naming convention that establishes common language, and a pin-level proposal that is useful for planning but must be validated for the selected module and product.
Use the Documents in the Right Order¶
| Document | Status and purpose | Use it when |
|---|---|---|
| M2 Interface Naming Rules | Naming convention for M2 interface families and profiles. | Naming a module, connector, carrier board, or interface profile in documentation and design files. |
| M2 Interface Definition | Draft pin-level definition and signal-allocation proposal. | Exploring a proposed M2 carrier interface or reviewing signal sharing before committing to a connector. |
What Is Stable and What Must Be Verified¶
The naming rules are the stable vocabulary for communicating interface intent. Apply them consistently in module descriptions, schematics, BOM notes, and product documentation.
The pin-level definition is not a promise that every μForge module or SF32 package supports every assigned signal, interface, or simultaneous-use combination. Before a design commitment, verify all of the following against the exact selected module, chip, package, and hardware design guide:
- connector mechanical drawing, keying, pin numbering, and assembly constraints;
- power rails, voltage domains, current capability, and sequencing;
- interface availability, pin multiplexing, and any mutually exclusive functions;
- signal integrity, impedance, length matching, ESD, and RF keep-out requirements;
- debug, boot, recovery, and production-test access; and
- the carrier board's display, camera, audio, storage, and wireless companion requirements.
Carrier-Board Decision Path¶
- Pick the module and read its introduction and hardware design guide.
- Use the M2 Interface Naming Rules to make the intended profile unambiguous.
- Use the M2 Interface Definition to identify candidate signals and sharing conflicts.
- Confirm every used contact in the module-specific documentation and the applicable SiFli source documentation.
- Capture confirmed exceptions and unresolved items in the schematic review before layout starts.
For a complete carrier-board review, continue with Design for Production. For module-specific implementation requirements, use the matching module design guide in the adjacent Module Design Guides group.
Auto-generated content
This page was compiled/drafted without an existing source document. Verify technical claims against SiFli's official documentation before relying on them.