Embedded Open Modular Architecture/EOMA-200

= EOMA-200 =

STATUS: DRAFT


 * Target uses: Mass-volume retail products crossing over to Embedded Industrial and Mid-to-low-end Server systems. Examples: Small Desktop systems, Micro servers, Smart NAS Home Servers, Digital Signage, Industrial PCs, Education and R&D purposes.
 * Dimensions: 100mm x 65mm PCB in a 103 x 68 x 16mm case
 * Pinouts: 4 50-pin B2B connectors providing 200 mandatory pins
 * Extensibility: 30mm x 14mm front-facing panel space and 2nd 65mm x 14mm front-facing panel
 * Power provision: 5V @ 4.5A and 3.3V @ 3.0A (32.4 Watts total)

= Introduction =

'''The EOMA-200 Standard is primarily designed to target mass-volume use by end-users in the retail sector, thus providing Engineering, Research, Educational and Industrial sectors with access to low-cost modular and Open Hardware. With provision of power up to 32.4 Watts, modern interfaces and plenty of expansion capabilities both on and off the Module, swappable modules supporting high-end processors at affordable prices become a real possibility'''.

With many standards providing 200 or more pins, the differentiator making EOMA-200 worthwhile is that all other standards (such as PC-104, COM-Express, Q-Seven and others that re-use MXM or SO-DIMM form-factors) are bare PCB factory-only modules with optional sizes that then also have optional functions. These factors combine to make other standards realistically installable only by experts or technical engineers with knowledge of ESD precautions and the full details of the available technical options offered by both module and base-board, in order to ensure correct interoperability and price-effectiveness in not over-ordering a motherboard with more (or less) functionality than can be supported. In other words, these alternative standards are absolutely guaranteed to be unsatisfactory, technically. To obtain a perfect match it is often necessary to custom-create a base-board, which is clearly unsatisfactory from a pricing and NRE perspective.

For example, the Q-Seven Standard has two different mechanical sizes, two variants based on the CPU type, optional DisplayPort, optional USB3 ports, optional AC97 Audio, optional Ethernet, optional UART, optional LVDS channels and more, all of which massively complicate decision-making for an end-user. COM Express on the other hand has mandatory interfaces, making the decisions easy on the technical side, but unfortunately it has 4 different size variants. Also, as these standards are not common-place, being suited for Industrial Applications with long-term supported CPUs and chipsets, they are typically far more expensive.

The EOMA-200 modular standard is designed to be user-installable in mass-volume appliances, gaining the benefit of mass-volume pricing for the components. There are no options on the pinouts, and there are no size variants, thus making both the purchasing decisions and the installation easy for the average person. Instead, options for extensibility are offered via two front-facing panels (in exactly the same way that standard ITX and ATX motherboards provide a standard front-facing area). One is of size 30mm x 14mm, and the other is of size 65mm x 14mm. The 65mm panel is sufficient to fit up to 4 Ethernet ports, or up to 8 USB2/3 ports, an HDMI connector, eSATA, FireWire, DisplayPort, MIPIport etc. The 30mm panel is intended but not limited to having an on-board MiniPCIe slot behind it, such that WIFI SMA connectors can be put into the 30mm panel.

= Preliminary pinouts =

Total pinouts summary
These pinouts are NOT OPTIONAL. However, within the majority of the interfaces is the ability to down-level negotiate or provide less than the full set of functionality. For example: if a particular SoC or CPU does not have USB3, then the USB3 pins can be left out and USB2 only provided. Additionally, if a particular low-cost SoC or CPU does not have a full set of 5 USB ports, a Hub Controller IC MUST be deployed on the Module PCB in order to comply with the standard. Likewise for PCIe: if a particular SoC or CPU does not have full 4-lane PCI Express capability then a 2x or even a 1x lane can be provided. Likewise also for the SD/MMC which can reduce down as far as 4 pins (in SPI mode); I2S as well can reduce down to 5 pins; Ethernet can down-level negotiate to 100mb/sec or even 10mb/sec.

Summary of Interface pinouts:
 * HDMI: 12
 * USB3 1: 6
 * USB3 2: 6
 * USB3 3: 6
 * USB2 4: 2
 * USB-OTG 5: 3
 * SATA: 4
 * I2C 0: 2
 * I2C 1: 2
 * I2S: 8
 * 5V : 9
 * 3.3V : 6
 * GND: 23
 * RGB/TTL: 28
 * SDMMC 1: 11
 * SDMMC 2: 11
 * SPI: 4
 * PCIe Host (4x): 18
 * Gig Eth: 8
 * GPIO: 24 (6 of which are taken for SD/MMC and PCIe servicing)
 * UART 1: 2
 * UART 2: 4

Total: 200

Note:
 * PCI Express pinouts:
 * SD/MMC description of 4-pin SPI mode:
 * HDMI (Type A) pinouts:
 * SD/MMC:
 * SD/MMC 1-bit, 4-bit and 8-bit modes:
 * eMMC:

Connector 1
This block contains HDMI, Ethernet, I2S, I2C, SPI, 8-bit SD/MMC and 6 GPIO. The total GND pins is 5 for this connector. It also has 2 5.0V power pins.

Summary:
 * 1-12: HDMI (down-level negotiable to DVI)
 * 13: GND
 * 14-21: Gig Eth (down-level negotiable to 10 or 100mbit/s
 * 22: GND
 * 23-33: SDMMC 0 (8-bit, down-level negotiable to 4-bit, 1-bit or SPI)
 * 34: GND
 * 35-38: SPI
 * 39-40: I2C 1
 * 41: GND
 * 42-43: 2 5V
 * 44: GND
 * 45-50: 6 GPIO

Pinouts for Connector 1
Notes:


 * HDMI is a Type A
 * HDMI 5V Power (DDC) is provided by motherboard
 * HDMI can down-level negotiate to DVI by leaving out the CEC pin
 * SDC0-DET is effectively just a plain GPIO pin. It should however be connected to a GPIO pin that supports External Interrupt (EINT)
 * Modules with 10/100 Ethernet only must not connect pins 14, 15, 20 or 21: they must be left floating (NC).

Connector 2
This connector is primarily for PCI Express. 4 of the 6 GPIOs are dedicated to PCI Express management, and the I2C lane is also intended for connection to the PCI Express bus. Also provided is SD/MMC. There are 9 GND pins in total on this connector, and four 3.3v power pins.

Summary:
 * 1-12,26-40: PCIe Host (1 4x) + 9 GND
 * 13-14: I2C 0
 * 15-25: SDMMC 1 (8-bit)
 * 41-44: 4 3.3V
 * 45-50: 6 GPIO (SDC1-DET, GPIO1, PRSNT1, WAKE, PWRGD, PRSNT2)

Pinouts for Connector 2
Notes:


 * PCI-Express optional JTAG is for debugging of PCI-e cards, not for the provision of JTAG to debug the Host CPU. If JTAG is to be provided, it is recommended that either some of the GPIO pins from the other 3 connectors be wired to the PCI Express JTAG pins (and use the GPIO for bit-level software emulation of JTAG on the Host CPU), or that an Embedded Controller (such as an STM32F) be dedicated to this (and other) purposes, or an alternative interface (such as USB or I2C) have a converter IC added which provides a JTAG interface (for example with the FT2232H ).
 * SDC1-DET, PRSNT1, WAKE, PWRG and PRSNT2 are effectively just plain GPIO pins. They should however be connected to GPIO on which EINT (External Interrupt) on the CPU is supported.

Connector 3
This connector provides 24-pin RGB/TTL, SATA, 2 UARTs and 6 GPIO pins. It also has 3 GND pins and 3 5.0V power lines. UART 1 is a 2-pin RS232, whilst UART2 provides TX, RX as well as CTS and RTS.

Summary:
 * 1-28: RGB/TTL
 * 29: GND
 * 30-33: SATA
 * 34: GND
 * 35-38: UART 2 (RX/TX and CTS/RTS)
 * 39-40: UART 1 (RX/TX)
 * 41-43: 3 5.0V
 * 44: GND
 * 45-50: 6 GPIO

Connector 4
This connector is primarily for USB, although it also provides an 8-bit I2S interface and 6 GPIO pins. There are also 7 GND pins in total, four 5V power pins and two 3.3V power pins

Summary:
 * 1-7: 1 USB3 + 1 GND
 * 8-14: 2 USB3 + 1 GND
 * 15-21: 3 USB3 + 1 GND
 * 22-24: 4 USB2 + 1 GND
 * 25-28: 5 USB-OTG (Tx, Rx, ID) + 1 GND
 * 29-36: I2S
 * 37: GND
 * 38-41: 4 5V
 * 42: GND
 * 45-50: 6 GPIO

Pinouts for Connector 4
Notes:
 * USB3 pinouts
 * Strictly speaking, the USB-OTG ID pin is an analog GPIO, and can be implemented as such if a particular SoC or CPU does not have USB-OTG.
 * If a particular SoC or CPU (or SoC with PCIe Bridge and PCIe-USB3 controller) does not have the full USB3 range, the optional pins (marked "Not used") can be left out, in this order: 17-20 if the chipset only has 2 USB3s; 17-20 and 10-13 if the chipset only has 1 USB3; 17-20, 10-13 and 3-6 if the chipset has zero USB3s. The USB2 lines however MUST NOT be left unconnected.  See section on USB requirements (below) for details.

= Interface Negotiation considerations =

EOMA standards provide "graceful degradation" should a particular CPU or SOC (plus chosen peripheral and hub ICs if needed) not have the full functionality. This section covers the down-level negotiation for the various interfaces which, by their nature, either provide auto-negotiation at the data level or can degrade gracefully by leaving out some of the pins. The interfaces in EOMA-200 which can down-level negotiate are:
 * I2S
 * both SD/MMC interfaces
 * PCI Express
 * all the USB interfaces
 * Ethernet
 * SATA
 * HDMI
 * The 24-pin RGB/TTL interface

Also, it is worth reiterating that these interfaces are MANDATORY. Provision of the interfaces can be done using controller or bridge ICs, if a particular SoC does not have the full set of interfaces. It is worth noting however that in picking a particular SoC, the total cost of providing the full set of interfaces including the converter and/or bridge ICs needs to be taken into consideration. Often, an ultra-low-cost SoC may end up being more expensive, price/performance-wise, than a more expensive SoC or CPU which has the full set of interfaces.

USB
With the exception of the USB-OTG interface, all the USB ports of the EOMA-200 specification are Host only, and MUST support all protocols right down to USB 1.1 (11mbit/sec). If a particular SoC's USB Host port supports High-speed (USB2 480mbit/sec) only, then it must be fronted by a USB2 Hub IC that can perform the necessary auto-negotiation. The reason for this is very simple: end-users may plug in devices which only support USB 1.1, such as certain 3G modems from certain manufacturers, and some other ultra-low-cost peripherals (keyboards, mice etc.). If any one of the USB ports on a SoC supports USB2 only then such peripherals will fail to operate, resulting in high product returns (in the mass-volume retail sector, even 0.1% product returns is a total disaster because margins are very tight and the volumes so large: 0.1% could easily be 500,000 units over a product lifecycle).

If a SoC or CPU does not have 3 USB3 ports, then the provision of USB3 should be prioritised in numerical order (or the USB3 ports should be provided through the deployment of a PCI Express Bridge IC - or the use of a 2nd PCI Express interface if the CPU has one - and a standard PCI Express USB3 Hub IC).

In other words, if the SoC only has one USB3 then this should be allocated to the 1st USB3 port on the module (pins 1-6), and the remaining two USB3 ports should be USB2 (pins 8,9 and 15,16). If the SoC only has two USB3s then the first and second USB3 ports on the module should be USB3 (pins 1-6 and 8-13), with the third being USB2 (pins 15,16).

Additionally, as noted in earlier sections, the provision of all five (5) USB interfaces is MANDATORY. Each interface can provide up to the full data speed, but if a particular SoC, CPU or its Controller Hub does not have the full 5 USB interfaces, then a suitable USB 4-port Hub IC (such as the FE 1.1) could be deployed, or the use of a PCI Express Bridge IC alongside a PCI Express USB3/2 Hub IC could be deployed. Regardless of the method in which it is achieved, the 5 USB interfaces MUST be provided.

If a particular SoC (or CPU and its associated Controller Hub) has more than 5 USB interfaces then designers may choose to deploy some of those extra interfaces out to one of the two EOMA-200 front panels. Additionally, designers may choose to deploy PCIe Bridge ICs and PCI Express USB Hub ICs in order to provide more USB interfaces on the front panel, or any combination thereof as long as the mandatory requirements to provide 5 USB interfaces on Connector 4 are also met.

I2S
I2S provides AC97 Audio. However, some Motherboards may deploy Audio ICs which do not support the full capabilities of 8-pin I2S. Under these circumstances, the SoC or CPU and its associated Operating System MUST gracefully degrade, auto-detecting if 5-pin I2S (2-channel output and audio in only) or only 4-pin I2S (audio output only) is deployed.

To aid in the discovery of the Audio capabilities, an I2C EEPROM at a known address (TBD) will be available on I2C-0, which will store Linux kernel "Device Tree" data advising of the Motherboard's Audio IC and its capabilities.

Ethernet
All EOMA-200 modules are required to support the full auto-negotiation capabilities of Ethernet, up to the maximum speed chosen to be provided. Specifically:


 * Providing 10 Mbit/s Ethernet is acceptable
 * Providing 100 Mbit/s Ethernet and down-negotiation to 10 Mbit/s Ethernet is acceptable
 * Providing 100 Mbit/s Ethernet only is not acceptable
 * Providing 1,000 Mbit/s Ethernet is acceptable as long as down-level negotiation to both 100 Mbit/s and 10 Mbit/s is also provided
 * Providing 1,000 Mbit/s Ethernet only is not acceptable.

I/O Boards (devices) must also support up to a maximum chosen Ethernet specification and all speeds below. This guarantees that any Module will work with any I/O Board, with any combination auto-negotiating to the maximum possible speed.

If a particular SoC does not have Ethernet capabilities, then Ethernet MUST still be provided. This can be done in any form, depending on the SoC. The Tegra 3 for example has a General-Purpose Memory Bus, to which PHY ICs such as the DM9000 or GPMB-to-RGMII converter ICs such as the AX88100 can be connected. Another alternative is to use USB-to-Ethernet ICs or PCI Express Ethernet PHY ICs. Regardless of the method chosen, the provision of Ethernet in EOMA-200 is MANDATORY.

Additionally, if a particular SoC or CPU and its associated Controller Hub have additional Ethernet ports, designers may choose to deploy them via one of the two front panels of EOMA-200. Designers may also choose to add in converter or bridge ICs which add extra interfaces anyway, however in doing so it is imperative that the MANDATORY requirements of EOMA-200 be met as well.

Note:
 * Gigabit Ethernet requires auto-negotation of cross-over or straight-through cables. As this is part of the Gigabit Ethernet specification, it is also part of the EOMA-200 specification
 * 10/100 Ethernet does not typically require auto-negotiation / detection of cross-over or straight-through cables. Therefore, it is not necessary, if the Module's Ethernet PHY IC only supports 10/100, that the Ethernet PHY support auto-detection of cross-over.  If however the Ethernet PHY supports Gigabit Ethernet and a 10/100 cable is plugged in, then as this is part of the Gigabit Ethernet specification, under these circumstances auto-detection of cross-over must be provided.

PCI Express

 * All EOMA-200 Modules MUST provide at least one lane of PCI-e, in "Host" Mode. The remaining PCI-e lanes - up to 2x and 4x - are OPTIONAL, but are recommended.
 * If a particular SoC or CPU supports higher speed PCI Express (Gen 2, Gen 3 etc.) then lower speed generations of PCI Express MUST also be supported.
 * A module may choose to internally deploy more than one PCIe interface (e.g. to an on-board Mini-PCIe card). However in doing so, compliance with EOMA-200's requirement to provide at least one lane of PCI-e via Connector 2 MUST still be met.

If a particular SoC or CPU with its associated Controller Hub does not have PCI Express, then there are a number of options available in order to comply with the EOMA-200 Standard. One is the use of the PLX Tech USB2380 IC which is a USB2 client to PCI Express (1x PCI-e Gen 1 compatible). If the SoC, CPU (or its Controller Hub) has USB3, then the PLX Tech USB3380 or the USB3382 may be deployed.

However: regardless of how the requirements are met to provide PCI Express, the deployment of these converter ICs MUST NOT be done at the expense of non-compliance with the EOMA-200 mandatory interface requirements. For example: if a USB interface is used to perform USB-to-PCIe conversion, but there are not enough USB interfaces left on the SoC to comply with the mandatory EOMA-200 USB requirements, then an additional USB Hub IC MUST be deployed on the module in order to meet both the PCI Express and the USB EOMA-200 interface requirements.

Use of USB-to-PCIe Bridge ICs
Special note to Module designers: if choosing to implement a system using USB-to-PCIe Bridge ICs, not only may the performance be severely degraded (especially if the resultant Module is plugged into an I/O Board that is rich in PCI Express technology) thus adversely affecting the user experience, but also the cost of adding the Bridge IC may turn out to have a lower price-performance metric than using a SoC or chipset which already has PCIe on-board.

'' Bottom line: in considering the use of USB-to-PCIe Bridge ICs, think twice! Is the price-performance metric really worth it? The answer could potentially be yes, but it is unlikely to be so. Although end-users may choose to plug a budget low-cost EOMA-200 Module into a high-performance Chassis with high-end Graphics and plenty of PCI Express, SATA RAID, Ethernet and other peripherals, it is not up to Designers of either Modules nor I/O Boards to pre-judge or prejudice an end-users' choices, and the design of both Modules and I/O Boards should take into consideration the possibility of such extremes, either way.''

Considerations for I/O Board (chassis) Designers
I/O Board chassis designers are free to use the PCIe interface for any purpose they desire (including ignoring it entirely). Example uses include:


 * Ignoring the PCIe interface (suitable for ultra-compact systems)
 * Connecting 1 lane directly to a MiniPCIe socket (suitable for 300mbit/sec 802.11n WIFI cards) and ignoring all 3 other lanes
 * Connecting the 4x lanes to a PCI Bridge IC and providing PCIe risers (and optionally a MiniPCIe socket). This would be a suitable option for Mini ITX and full Desktop Tower systems, in particular to take standard off-the-shelf 3D Graphics Cards etc.
 * Connecting the PCIe interface (or some of the bridged PCIe connections) to additional on-board peripheral ICs, to provide Gigabit Ethernet, SATA, USB3, 3D GPUs etc. This would be a suitable option for Embedded and Industrial PCs where PCIe risers are problematic (vibration, space considerations etc.)

It's worthwhile bearing in mind therefore that PCI Express is the general-purpose way to extend Modules far beyond the space and capacity that could normally be expected of such a small module, easily turning EOMA-200 modules into a full-fledged Desktop or Server products that compete with existing high-end systems available today.

SATA
All EOMA-200 Modules are required to support the full backwards-compatible auto-negotiation capabilities of SATA, up to the maximum speed and capabilities chosen to be provided. Specificially:


 * Provision of SATA-II is acceptable, but provision of SATA-II with only support for 3 Gbit/s SATA-II i.e. no support for all lower speeds is not acceptable.
 * Provision of SATA-III is acceptable, provided that backwards-compatibility with all prior versions of SATA are also provided.

If a particular SoC or CPU and its associated Hub Controller IC do not provide SATA, then bridge and/or converter ICs MUST be deployed in order to comply with the EOMA-200 standard. For example, the JM20329 is a highly cost-effective USB2-to-SATA-II solution, and the TI USB3 to SATA bridge IC is also effective; there exist other options including PCI Express Bridge ICs and USB3-to-SATA-III converter ICs.

Additionally, if a particular SoC or CPU and associated Hub Controller IC has more than one SATA interface, designers may choose to deploy spare SATA interfaces in the form of an on-board mSATA module, or to provide one or more eSATA connectors via the front panel slots of the EOMA-200 standard. Regardless of the design offered, the provision of SATA is MANDATORY, and any provision of such additional functionality MUST NOT be at the detriment of compliance with the EOMA-200 mandatory pinouts.

24-pin RGB/TTL
The RGB/TTL output is the one point where close attention has to be paid on the part of EOMA-200 designers, because of the variance between devices in which the Modules will be plugged. This will need careful monitoring and may warrant a "Certification Programme" to ensure that Modules are compliant with a wide range of devices.


 * RGB/TTL is a parallel data bus, potentially running at up to 125 or even 150mhz. Both Modules and I/O Boards must ensure that the length of the tracks leading to and from Connector 3's RGB/TTL pins are all of equal length.  It is recommended that both the source (e.g the CPU) and the sink (e.g an LVDS IC) are placed as close to Connector 3 as possible.
 * Modules must provide software-programmable support for anywhere between 180x120 RGB-TTL resolutions all the way up to the maximum that they are capable of, with the maximum resolution being clearly marked on both the Module, as well as the retail packaging in which it is sold.
 * Modules should support up to at least 1920x1080 at at least 50fps. However, some ultra-low-cost SoCs, especially those designed for mobile devices, only support up to XGA or WXGA resolutions.  The use of such SoCs is not entirely recommended.
 * EOMA-200's RGB/TTL interface is 24-bit-wide. If a particular SoC only has e.g. 18-bit or 15-bit RGB/TTL then the LSB (lower) bits must be set to logic output level 0 when the LCD interface is enabled: they must NOT be left floating or tri-state.  This ensures that devices which are expecting the full 24-bits do not receive noise on the lower bits of each of the R,G and B 8-bit inputs.

Considerations for Multi-screen systems
The RGB/TTL interface is primarily made available for Digital Signage products, All-in-one PCs and for connection to small displays on Desktop systems with a built-in touchscreen for menu selection and as a Mouse Pad, etc. Although there is no reason why individual devices should not have more than one LCD screen, allowing them to be selected, the burden of complexity for screen selection is placed onto the CPU Card software, so any company planning such a multi-screen device over the 24-pin RGB/TTL interface should contact the authors of the EOMA-200 specification (lkcl@qimod.com).

Realistically, however, high-end multi-screen devices should consider using USB-based screen driver technology such as that from DisplayLink, or add extra HDMI, DVI, DisplayPort or MIPIport interfaces directly on the Module PCB via one of the two EOMA-200 front panels.

An even better and much simpler option would be to use the PCI Express lanes of EOMA-200, and to provide room for a standard off-the-shelf PCI Express Graphics Card, or to provide the option to plug in MXM Graphics Cards into the I/O Board.

HDMI
The HDMI Interface is of Type A (4 Differential LVDS pairs) rather than Type B (7 differential pairs). HDMI is however merely an extension of DVI-D, with the addition of CEC. If therefore a particular low-cost SoC does not have an HDMI output, then one possibility is to convert its RGB/TTL output (if available) into DVI, using for example a TI TFP410 converter IC. A better possibility however is for the Module to deploy a PCI Express Bridge IC (or to use a 2nd PCIe interface if it has one) and to deploy a suitable low-power GPU (Graphics IC) which has an HDMI output.

Either way, although the provision of HDMI is MANDATORY in EOMA-200, the provision of DVI-D only (by leaving out the CEC interface) is both reasonable and acceptable for low-cost Modules.

SD/MMC
The SD/MMC standard has been extended numerous times, and is backwards-compatible all the way to 4-pin SPI. EOMA-200 modules may therefore provide any version of the SD/MMC standard, but in doing so they must support ALL down-level compatible versions of SD/MMC (including 4-pin SPI interoperability). This requirement is to ensure that smaller low-cost motherboards which only connect some of the pins can still interoperate, as well as support user peripherals that only have the lower levels and data rates.

On any given Chassis (I/O Board) design, the uses to which any of the two SD/MMC interface can therefore be put includes, but is not limited to:


 * SD/MMC card slots (1-pin, 4-pin and 8-pin data lines)
 * eMMC NAND Flash chips
 * SD/MMC WIFI modules (removable as well as SIP embedded modules)
 * SD/MMC 3G modules and other peripherals

All and any of these peripherals could potentially be on the main I/O Board into which the EOMA-200 Modules can be plugged.

If in the instance that a particular SoC or CPU (with its associated Controller Hub IC) does not have two SD/MMC interfaces, then they MUST still be provided: the interfaces of EOMA-200 are MANDATORY. One method by which a particular SoC may provide SD/MMC is to use a USB-to-SDMMC converter IC (e.g. SMSC's USB224x or USB225x ) or a PCI Express Bridge IC and a PCI Express SD/MMC Controller IC (such as the JMB387 ).

If a particular SoC or CPU has more SD/MMC interfaces than the EOMA-200 standard requires, then designers may choose to deploy an SD/MMC card slot via one of the two EOMA-200 front panel holes, or may choose to add on-board eMMC or other SD/MMC peripherals, soldered to the Module's PCB. Alternatively, designers may choose to deploy USB or PCIe or other converter / bridge ICs to add extra functionality. Regardless of whether these or any other options are explored by the designers, the designers are free to add whatever they choose as long as the EOMA-200 requirements that two SD/MMC interfaces are provided, as EOMA-200's interfaces are MANDATORY.

Notes:
 * Guidelines for debugging of SD/MMC, kindly written by Texas Instruments:
 * SDCard simplified specifications, explaining that yes, peripheral negotiation is available in the SD Specification

= Design Considerations and suitable CPUs =

As the power provision is for up to 30 Watts, and the PCB size is 100 x 65mm, this standard is suitable for some low-power Intel CPUs, AMD's Fusion chipsets, VIA Nano CPUs and even RDC's IAD100PE offering, as well as the more modern ARM and MIPS SoCs such as the Tegra 3 and the Freescale iMX6. Designers should note however that provision of PCI Express is MANDATORY, ruling out many of the lower-cost SoCs and those that are targetted at tablets or phones.

Freescale iMX6
Freescale's iMX6 is near-perfectly-suited to a low-cost EOMA-200 module, having on-board SATA, Gigabit RGMII, a 1x PCI-Express interface, HDMI, 2 USB-2 ports and 1 USB-OTG port. The only exception is therefore that the iMX6 does not have USB3, nor does it have the total 5 USB ports. A 4-port USB Hub would therefore need to be deployed. However the total system cost (BOM) if the Dual iMX6 was used would be somewhere around $USD 40 to $45, given that the pricing of the iMX6 Dual is only $USD 22 at the time of writing. Use of the Quad-Core iMX6 would increase the BOM only by a further $USD 10. The other advantage of using Freescale SoCs is their committment to long-term availability.

Notes for estimated BOM:
 * iMX6 Dual SoC: $22 ($32 for the Quad iMX6)
 * PMICs: $5 appx
 * Gigabit Ethernet PHY: $3.50 appx
 * 6-layer 1.5mm PCB: $1.50 appx
 * Connectors: $5 appx
 * FE1.1s USB Hub IC: $1.50 appx
 * Additional discretes: $1.50 appx
 * Casework: $3 appx

Total: appx $USD 43 ($53 appx for a Quad-core system)

Tegra 3
The NVidia Tegra 3 is ideally suited to this form-factor, as it has PCI-Express (up to 4x with an additional 2 reconfigurable lanes), SATA-III, USB-3, USB-2 and USB-OTG. Although the Tegra 3 does not have Gigabit Ethernet it has a General-purpose memory controller that can take either a DM9000 which provides a 10/100 PHY in a single chip or an AX88180 in combination with an RGMII PHY. The other option for the Tegra 3 is to use standard PCI Express Gigabit Ethernet ICs: this is possible (and convenient) because there are two PCI-express lanes spare that can be used for this purpose.

AMD Fusion CPUs
AMD's Fusion CPUs are also ideally suited, such as the Embedded R-Series including the R-452L, R-260H alongside the A70M or A75 controller hubs. The older G-Series would also be suitable all the way up to the T56N, in combination with the A50M or A55E controller hub if the lack of USB3 and down-level negotiation to USB2 would be acceptable to end-users, or if a PCI-Express Bridge IC and a standard PCI Express USB3 IC is deployed on the Module's PCB.

Heat Sinks
30 Watts is a lot of heat to get rid of when the top surface area is only 60 sq.cm. Research is underway as to how to dissipate the heat, and the following links are proving useful:


 * http://sound.westhost.com/heatsinks.htm
 * http://www.ti.com/lit/an/slva462/slva462.pdf

From the above, we find two equations. One is "Henry's Rule Of Thumb" which is that the Thermal Resistance (in Centigrade / Watt) of a heat sink can be calculated roughly from Surface area by the formula "50 / sqrt (sq.cm)", and the second is that of calculating the temperature that can be dissipated by a heat sink based on the target power: Temp Diff (C) / Power (Watts) - the same units.

An additional calculation gives us the total surface area of the heat sink, based on a "fins" design. If the width is 10 cm, and there are fins of width 1mm spaced out 1mm apart, then 50 such fins can fit into a 10cm width. If the height is 1cm then there are two faces every 2mm, giving a total of 100 faces of height 1cm in a 10cm width. Multiplying by the depth (of 6.5cm) we get a total surface area of 650 sq.cm.

From "Henry's Rule Of Thumb" for passive-cooled aluminium heat sinks in free air, we therefore calculate a rough Thermal Resistance factor: 50 / Sqrt(650) = 1.96 Degrees C per Watt (call it 2). Therefore, if we assume that a Temperature Differential of 20 C is acceptable (e.g. the ambient air is 25 C and the temperature of the heat sink is 45C) then our 650 sq.cm heat sink, of height 1cm with 50 fins covering the top of the unit, can dissipate 10 Watts.

So, for something like the Freescale iMX6 (which has a maximum flat-out power consumption of 4.5 watts if running everything at 100%) a 10 Watt passive-cooled aluminium heat sink would do absolutely fine. For anything over that however it will be necessary to add a fan.

Therefore, the addition of a fan as a standard component has to become part of the EOMA-200 specification, along with the mechanical considerations associated with that.

= On-board I2C EEPROM =

Not all of the EOMA-200 interfaces are self-describing or auto-negotiating at the hardware level. For example: the AC97 Audio does not have auto-negotiation, and neither does the RS232, nor do the GPIO pins or the RGB/TTL interface. This matters because it is possible that EOMA-200 modules could be plugged into I/O Boards with completely different characteristics. In the case of PCI-Express, SATA, Ethernet and USB this is not a problem because those interfaces have auto-detection.

To cater for this specific problem, there MUST be an on-board I2C EEPROM at an address TBD on the 1st I2C Bus, which will contain identification information in Linux Device-Tree format, that uniquely identifies the hardware on the I/O Board which cannot otherwise describe itself or its purpose. For example:


 * The AC97 Audio is over an 8-pin I2S interface. However, it is possible that I/O Board Designers may choose to only provide outputs (no audio input).  As I2S does not have a means to inform the hardware of how it is being used, it is necessary to put this information into the I2C EEPROM.
 * Additionally, some I/O Board Designers may choose to only connect 1 of the 4 I2S output lines, choosing to implement only for example Stereo Audio instead of 5.1 Channel. This information must be encoded and stored in the I2C EEPROM.
 * Additionally, although I2S is a standard, the CODECs that can be connected to I2S are not standard. The choice of which AC97 CODEC to use cannot be dictated by the EOMA-200 Standard, because the CODECs are improving all the time.  Therefore, the choice of CODEC IC that is used, and how it may be enabled, must be encoded as Device-Tree information that must go into the I2C EEPROM.
 * The purposes to which each and every single one of the 24 GPIO pins can be completely different on a per-I/O-Board basis. Pin 15 may be used as "USB Hub Power-up" on one device, yet used as "Mini PCIe WAKE#" on another.  This information - for each and every GPIO pin used - must be encoded as Linux Device Tree information and stored in the I2C EEPROM.
 * LCD Panels do not have an accurate reliable method of querying their capability. Even the EDID data which comes off of some LCD Panels (but not all) is known to be completely wrong in many cases!  Therefore, the refresh rate, size, number of bits per pixel and the pixel configuration information - all this information MUST be stored as Linux Device Tree information in the I2C EEPROM.

Observations and considerations
The following observations should be read CAREFULLY:


 * The current thinking is for GPIO pins to be named as a device by purpose (such as "Reset Button" or "Power for USB Hub"), not as devices by GPIO number (of which there would have been 24, one for each GPIO pin). For example, there may be a Linux Kernel "Reset Button Driver" happening to have one (1) GPIO pin.  The Linux Device Tree data associated with this Linux Kernel Driver would therefore specify exactly which GPIO pin that was.
 * non-Linux-based Operating Systems will be required to decode Linux Device Tree data and to provide infrastructure for downloading 3rd party drivers for all peripherals listed in a particular I/O Board's EEPROM. Encoding the exact same information in two different formats, burdening the I/O Board Manufacturers with the additional cost of storage of duplicate data, is not acceptable in the mass-volume arena.  The means by which the 3rd party drivers are developed, obtained and stored is beyond the scope of the EOMA-200 Specification.  3rd party OS Vendors should discuss directly with I/O Board Manufacturers exactly how they are to support 3rd party drivers - most likely by pre-populating / pre-loading the drivers required for the full range of potential modules directly onto the storage media of the product, and arranging network connectivity for those for which it is not possible to pre-install.
 * The provision of the I2C EEPROM is MANDATORY for I/O Boards, and it is MANDATORY that Modules read and utilise the information contained in them. Failure to do so would result in Modules becoming incompatible with the I/O Boards into which they are plugged, or worse, specific customisation of Modules to suit specific I/O Boards only would occur, resulting in the EOMA-200 standard becoming fragmented and of no value.
 * It may be necessary in some cases - particularly for x86 hardware - that the BIOS be made aware of the I2C EEPROM's format and of EOMA-200's requirements. ARM-based systems do not have a BIOS, so typically use u-boot (which will also require to be modified to be made aware of EOMA-200).  In such cases, it is recommended that Module Designers consider using Coreboot because the full source code is available and it will be easier to collaborate with other EOMA-200 Designers to all parties' advantage than to pay proprietary BIOS Software Houses to custom-develop a BIOS for each and every single product.  (Note: The Coreboot BIOS is mature software, supporting over 230 motherboards at the time of writing and is shipped in major mass-volume products such as Samsung's ChromeBox and ChromeBook products).

= Example EOMA-200 PC =

The example below shows how a small Desktop PC can be created. This example has:


 * HDMI output
 * 1 USB3
 * 4 USB2
 * 2 Gigabit Ethernet
 * 1 eSATA
 * SD/MMC
 * Micro-SD
 * Micro-USB
 * Mini PCIe with a combined Bluetooth 4 and 802.11N 300mb/sec WIFI card
 * Standard Audio connectors
 * DC Power input jack



= References =