View source for Embedded Open Modular Architecture/EOMA68/Hardware


= Interface Summary =

This section summarises the specification of EOMA68's physical interfaces.  EOMA68 is an "aggregation" of a set of other pre-existing hardware interface standards.  The number of pins on the interface is 68; the physical form-factor is the legacy PCMCIA.

Re-purposing of the PCMCIA interface and form-factor has been chosen to create portable mass-volume (100 million units and above) Embedded Computing Modules (Computer on Module) and other modules.  Mass-volume "Lowest Common Denominator" interfaces have been chosen, all of which have existed for over a decade, are all low-power, DRM-free, royalty-free, fully-documented, supported across the entire industry and are well understood.

The interfaces are:
* 18-pin RGB/TTL (for LCD Panels and DVI/VGA/HDMI or other display conversion ICs)
* I2C (freely available for use except for one address: 0x51 which is reserved)
* 1st USB port (Low Speed, Full Speed, optionally Hi Speed/480&nbsp;Mbit/s and optionally USB3.0 or USB3.1)
* 2nd USB port (Low Speed, Full Speed, optionally Hi Speed/480&nbsp;Mbit/s)
* SD/MMC 4-bit wide with multiplexing to SD/MMC and SPI on 6 pins
* 4 pins "External Interrupt" capable GPIO that are guaranteed to generate a fast hardware interrupt to the SoC
* 1 pin "PWM" which is also multiplexed to GPIO
* SD/MMC (and down-level compatibility to SPI) multiplexed with 6 of the GPIO pins.
* TTL-compatible UART (Tx and Rx only) also multiplexed to GPIO
* SPI up to 4-bit wide, multiplexed with 6 GPIO pins

These interfaces are '''NOT OPTIONAL''' for Cards.  All Cards '''MUST''' provide '''all''' interfaces (at some level of speed and capability).  Housings on the other hand are free to implement whichever interfaces are required for the device.  For example: whilst all Cards '''must''' have a 2nd USB interface, devices such as tablets or laptops into which CPU Cards are plugged are not ''required'' to use it.  The only exception is I2C (due to the EOMA68 identification EEPROM): it is mandatory for all Housings to provide an EOMA68 identification EEPROM.

Exactly like legacy PCMCIA Cards, EOMA68 Cards may have absolutely any functions, any additional connectors, peripherals and so on ''without'' limitation, except for compliance with the EOMA68 pinouts and physical size constraints.  These additional functions, which may include access ports in the casework, may extend outwards from the user-facing end of the Card to any practical extent, exactly as with legacy PCMCIA.

= Background to Interface Selection =

The interfaces have been specifically chosen because they are either essential or they are multi-purpose buses, and surprisingly they are perfectly adequate despite being Lowest Common Denominator across a wide range of CPUs for at least a decade.  The goal here is not to attain ultra-high-speed latest-and-greatest performance but to use proven, long-established interfaces that will be easy to find parts for mass-volume appliances in potentially hundreds of millions of units and above.

Also, some graceful degradation through negotiation at the ''hardware'' level is not only desirable but is an essential distinctive and unique feature of the EOMA68 standard, because it dramatically simplifies the "sales pitch" as well as the engineering design, user card selection ("just get one of these, plug it into any product, it will work") and so on whilst at the same time ensuring that the range of SoCs that can be used is significantly diverse and future-proof.

* '''I2C''' - I2C is only two wires, is a global bus that can address multiple devices, and is a long-established proven Industry Standard with thousands of devices available.
* '''USB''' - USB2 is only two wires; USB3.0 is six, USB3.1 is ten.  USB, like I2C, is a global bus that can address multiple devices and is a long-established proven Industry Standard.
* '''RGB/TTL''' - 24-pin RGB/TTL was chosen over LVDS or MIPI so as to keep the cost down, and also to keep the signal speed down.  Whilst LVDS seems initially to be a good candidate, Single-Channel LVDS is unsuitable for driving 1,920×1,080p60 LCD Panels: most 1,920×1,080 LCD panels require between 2 and 3 LVDS drivers.  MIPI also requires multiple parallel channels to achieve higher data rates.  Any low-cost CPU chosen which did not have LVDS or MIPI would be forced to add a converter chip, potentially on ''both'' sides of the interface (CPU card as well as motherboard).  So it makes sense to choose the proven, lower-speed, reliable 24-pin interface, thus making the EOMA68 Standard suitable for use even with ultra-low-cost 320×240 RGB/TTL LCD Panels, right the way up to HDTV screen sizes.
* '''SD/MMC''' - SD/MMC has a 4-pin, 2-pin, 1-pin and SPI mode.  Transfer speed negotiation is possible at the hardware level.  SPI can even be implemented as [http://lxr.free-electrons.com/source/drivers/spi/spi-bitbang.c "bitbanging"]

= Pinouts (version 1.0) =

These pinouts make no attempt to be electrically or electronically compatible with the legacy PCMCIA standard.  1 PWM GPIO, 4 explicitly EINT-capable GPIO pins, 4 dedicated GPIO pins, additional GPIO multiplexing pins on other functions, 18-pin RGB/TTL, USB2, USB3.1, I2C, SPI, SD/MMC, UART are included in the Version 1.0 specification.

Four 5.0&nbsp;V power inputs must be provided: all pins are rated at 0.5&nbsp;A, so the maximum power dissipation is limited to 10 watts.  ''Design consideration: please note that to ensure that thermal dissipation in an enclosed fanless situation is not exceeded, a maximum of 3.5 watts should be respected, or the card must contain its own fan (not recommended).  Most systems will '''not''' have active cooling.''

All High-speed signals (USB2, USB3) are balanced lines that are still separated using GND or Power pins.  All other pins are low frequency, with the exception of the LCD Pixel Clock and Pixel Data pins, which could go as high as 125&nbsp;MHz for 1,920×1,080 @ 60fps (not recommended).  The GPIO pins are available, for general-purpose bi-directional use of digital data only.

The output from the 24-pin LCD RGB/TTL pins must be electrically compatible with a Texas Instruments SN75LVDS83B, where VREFTTL is supplied to IOVCC.

All GPIO should be initialised at start-up as tri-state isolated, or as high-impedance (48kOhm) inputs so as not to interfere with carrier boards.  Voltage levels for all GPIO are relative to VREFTTL, and follow CMOS level rules: above 0.7 times VREFTTL for a digital "1", and below 0.3 times VREFTTL for a digital "0".  Digital input voltage levels *MUST NOT* exceed VREFTTL, at any time.  When the CPU Card is powered off (i.e. when VREFTTL happens to drop to 0V), all Digital IO *MUST* also be powered off.

The option for a CPU Card to provide USB3.0 or USB 3.1 is also available, if a given system has it.  If, however, a particular system does not have USB3, the pins '''must not''' be used for other purposes, and '''must''' be left unconnected (floating).  Additionally, Housings '''must not''' use the unused pins for any other purpose and must leave them unconnected (floating).  This is to ensure that automatic down-negotiation of USB2 occurs correctly and that damage does not occur to USB3-capable CPU Cards when plugged into Housings with only USB2 capability.

Pin 43 is used for Card-specific / implementation-specific boot, power-up or reset purposes.  It is to be connected to an external switch that pulls directly down to ground to indicate "boot / power-up / reset", and otherwise is floating.  The length of time or the number of times that the switch is pressed is entirely implementation-specific for any given Card, and is entirely unlimited and unrestricted in scope by this specification.  Potential examples which are not the full scope of possibilities include "brief press" for "bring up an on-screen shutdown dialog" or "press and hold" for "emergency power-off" and "press and hold to power on" and "press to bring out of sleep mode".

Note also: for factory-install purposes, cards are of course permitted to use all and any pins, ports or methods required to carry out factory-installs and testing, as long as after factory-install the 68 pins are entirely EOMA68 compliant.  Examples of such uses would include a test-bench with an SD/MMC interface for first firmware boot, a JTAG interface and other diagnostics.

== Table of EOMA68 pinouts ==

{| class="wikitable" border="1" width="100%"
! style="width:50%" | Row 1
! style="width:50%" | Row 2
|-
|* 1 GPIO (12) / SPI_MISO(SPI_IO1)
|* 35 GPIO (13) / SPI_MOSI(SPI_IO0)
|-
|* 2 LCD Pixel Data bit 18 (Blue2)
|* 36 LCD Pixel Data bit 19 (Blue3)
|-
|* 3 LCD Pixel Data bit 20 (Blue4)
|* 37 LCD Pixel Data bit 21 (Blue5)
|-
|* 4 LCD Pixel Data bit 22 (Blue6)
|* 38 LCD Pixel Data bit 23 (Blue7)
|-
|* 5 GPIO (14) / SPI_SCK
|* 39 GPIO (15) / SPI_CS
|-
|* 6 LCD Pixel Data bit 10 (Green2)
|* 40 LCD Pixel Data bit 11 (Green3)
|-
|* 7 LCD Pixel Data bit 12 (Green4)
|* 41 LCD Pixel Data bit 13 (Green5)
|-
|* 8 LCD Pixel Data bit 14 (Green6)
|* 42 LCD Pixel Data bit 15 (Green7)
|-
|* 9 GPIO (16) / EINT1
|* 43 POWER#
|-
|* 10 LCD Pixel Data bit 2 (Red2)
|* 44 LCD Pixel Data bit 3 (Red3)
|-
|* 11 LCD Pixel Data bit 4 (Red4)
|* 45 LCD Pixel Data bit 5 (Red5)
|-
|* 12 LCD Pixel Data bit 6 (Red6)
|* 46 LCD Pixel Data bit 7 (Red7)
|-
|* 13 LCD Pixel Clock
|* 47 LCD Vertical Synchronization
|-
|* 14 LCD Horizontal Synchronization
|* 48 LCD Pixel data enable (TFT) output
|-
|* 15 I2C Clock (SCL)
|* 49 I2C Data (SDA)
|-
|* 16 GPIO (0) / SDMMC-D3
|* 50 GPIO (1) / SDMMC-D2
|-
|* 17 GPIO (2) / SPI_IO2
|* 51 GPIO (3) / SPI_IO3
|-
|* 18 GPIO (4) / SDMMC-CMD
|* 52 GPIO (5) / SDMMC-CLK
|-
|* 19 GPIO (6) / SDMMC-D0
|* 53 GPIO (7) / SDMMC-D1
|-
|* 20 GPIO (18) / EINT3
|* 54 GPIO (19)
|-
|* 21 GPIO (20) 
|* 55 GPIO (21) 
|-
|* 22 GPIO (10) / PWM
|* 56 GPIO (17) / EINT2 
|-
|* 23 GPIO (8) / UART_TX
|* 57 GPIO (9) / UART_RX
|-
|* 24 PWR (5.0&nbsp;V)
|* 58 PWR (5.0&nbsp;V)
|-
|* 25 ---- not used ---- / USB3&nbsp;StdA_SSRX-
|* 59 ---- not used ---- / USB3&nbsp;StdA_SSRX+
|-
|* 26 ---- not used ---- / USB3&nbsp;StdA_SSTX-
|* 60 ---- not used ---- / USB3&nbsp;StdA_SSTX+
|-
|* 27 ---- not used ---- / USB3&nbsp;StdB_SSRX-
|* 61 ---- not used ---- / USB3&nbsp;StdB_SSRX+
|-
|* 28 ---- not used ---- / USB3&nbsp;StdB_SSTX-
|* 62 ---- not used ---- / USB3&nbsp;StdB_SSTX+
|-
|* 29 PWR (5.0&nbsp;V)
|* 63 PWR (5.0&nbsp;V)
|-
|* 30 1st USB2 (Data+)
|* 64 1st USB2 (Data−)
|-
|* 31 GROUND
|* 65 GROUND
|-
|* 32 GPIO (11) / EINT0
|* 66 VREF-TTL (GPIO TTL Voltage Reference)
|-
|* 33 GROUND
|* 67 GROUND
|-
|* 34 2nd USB2 (Data+)
|* 68 2nd USB2 (Data−)
|}

= Special requirements for specific interfaces =

The following individual subsections go into detail about each of the interfaces so that it is clear what level of support (particularly at a hardware / firmware level) must be provided.

== Requirements for USB ==

All Cards are required to support the full backwards-compatible auto-negotiation USB device capabilities and speeds of all former versions of the USB Interface, up to the maximum speed and capabilities chosen to be provided.  Specifically:

* Providing USB Low Speed (version 1.0 - 1.5 Mbit/s) is acceptable.
* Providing USB Full Speed (version 1.1 - 12 Mbit/s) is acceptable if Low Speed is also provided.
* Providing USB Hi Speed (version 2.0 - 480 Mbit/s) is acceptable if Full Speed and Low Speed are also provided.
* Over the 1st USB port, providing USB Super Speed (version 3.0 - 5 Gbit/s) is acceptable if all lower speeds are also provided.
* Over the 1st USB port, providing USB Super Speed (version 3.1 - 10 Gbit/s) is acceptable if all lower speeds are also provided.
* Providing a higher version '''only''' and supporting no lower speeds is '''not''' acceptable.

To emphasise: providing no USB 3.0 or USB 3.1 over the 1st USB port is acceptable as long as USB2.0, USB1.1 or USB1.0 (and downwards-compatibility) is provided.

Housings must support up to a maximum chosen USB specification and all speeds below. This guarantees that any Card will work with any device, with any combination auto-negotiating to the maximum possible speed.

As a counter-example of a SoC that is '''NOT''' acceptable, the OMAP 3500 series provides USB 2.0 Hi-speed (480mbit/s) '''ONLY'''.  Use of this SoC is '''NOT''' acceptable.

== Requirements for RGB/TTL ==

The RGB/TTL output is the one point where close attention has to be paid on the part of the CPU Card designers, because of the variance between devices in which the CPU Cards will be plugged.  This will need careful monitoring and warrants a "Certification Programme" to ensure that CPU Cards are compliant with a wide range of devices.

* RGB/TTL is a parallel data bus, potentially running at up to 125 or even 150mhz.  To ensure that the parallel signals are not skewed, ''both'' CPU Cards ''and'' Housings '''MUST''' ensure that the length of the RGB/TTL tracks (data, HSYNC, VSYNC, CLK and DE) leading to the 68-pin connector - on either side of the 68-pin connector - 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 the 68-pin connector as possible.
* CPU Cards '''must''' provide software-programmable support for anywhere between 190x120 RGB-TTL resolutions all the way up to the maximum type (1366x768 for 5mm cards, 1920x1080 for 3.3mm cards)
* CPU Cards '''must''' be able to provide a minimum screen refresh rate of 60hz, and '''must''' be capable of driving screens at only 30hz.
* Resource-limited CPUs '''may''' reduce the number of bits used to store colour (even to the extent of using monochrome only) as long as the actual RGB/TTL output can achieve the maximum resolution.
* EOMA68's RGB/TTL interface is 18-bit-wide.  If a particular SoC only has e.g. 16-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 18-bits do not receive noise on the lower bits of each of the R,G and B 8-bit inputs.

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 should contact the authors of the EOMA68 specification (lkcl@rhombus-tech.net).  Realistically, multi-screen devices ''should'' consider instead using USB-based screen driver technology such as that from DisplayLink, or place any number of additional Display outputs onto the user-facing end of the CPU Card ''(most CPU Cards will at least have a Micro-HDMI output)''.

Resource-limited CPUs include for example ultra-low-power embedded SoCs which would struggle with the internal memory bandwidth needed to cover a 1366x768 24bpp refresh rate at 60hz.  Under such circumstances using only 8bpp (2 bits red, 2 bits green, 3 bits blue, or 255-entry lookup tables such as were used on VGA monitors 30 years ago) or even 1bpp (monochrome) is perfectly acceptable in order to bring down the internal memory bandwitdh.  '''HOWEVER''' if such tricks are used the actual RGB/TTL output '''MUST''' still be at 1366x768 resolution, at up to 60hz.

== Requirements for I2C ==

These are the requirements for provision of I2C on an EOMA68 interface.  The summary is that the I2C bus must not be shared with any peripherals on the CPU Card, and the CPU Card must be able to read an on-board EEPROM (at address 0x51).

* The I2C bus that is connected to the EOMA68 interface will expect to have access to an EEPROM that is addressable (readable) at I2C address 0x51.
* Additionally, there '''MUST NOT''' be ''any'' devices on the I2C bus on the CPU Card side.  The reason is that all other addresses (other than 0x51) '''must''' be available for peripherals on the Housing.
* If a CPU Card needs to connect internally to any I2C peripherals on the PCB inside the CPU Card, the CPU Card '''MUST''' use a completely separate I2C bus (internally), '''NOT''' the one that is connected to the EOMA68 Interface.  i.e. the I2C bus that is connected to the EOMA68 interface '''MUST''' remain completely dedicated to EOMA68, and '''MUST NOT''' be shared with any peripherals on the CPU Card itself.
* The EEPROM '''MUST NOT''' be used for the storage of user data: it is reserved exclusively for EOMA68.
* The EEPROM '''MUST''' be capable of operating at anywhere from 1.8v to 5.5v, or, alternatively, bi-directional auto-detecting level-shifting '''MUST''' be performed on the I2C signals.  Generally it is easier to supply the EEPROM with the variable-level voltage VREFTTL.

Please note that there is considerable confusion over the definition of addresses in I2C.
The [[Talk:Embedded_Open_Modular_Architecture/EOMA68|discussion]] page has some clarification over what consititutes an address (7-bit) and what goes into the first 8 bits (7-bit address plus 1 bit indicating read or write).  Adding to the confusion it is extremely common to find datasheets even from respectable companies that directly contradict the I2C specification.

Below is an example circuit showing an AT24C64 with the address set appropriately to 0x51.  '''PLEASE NOTE''' that the AT24C64 datasheet '''INCORRECTLY''' misleads people to believe that the addresses are 0xA2 (for read) and 0xA3 (for write).  The address for both read and write is 0x51 (in the top 7 MSBs) with bit 0 (LSB) indicating read (0) or write (1).

[[File:EOMA68-I2C-EEPROM.png]]

== Requirements for UART ==

Strange as it may seem to have requirements for UART this section covers practical issues regarding protection of CPU Cards.  When designing Housings it is important to take into consideration that many embedded SoCs do not have proper UART buffering.  Typically if the SoC is powered down but the Housing continues to be powered up such that it continues to provide a positive voltage to the UART "RX" line this can potentially result in power leakage through the SoC and on to other areas of the PCB.  It is therefore critical that Housings ensure that this does not happen.

As this problem is to be taken care of on the Housing it is worth observing that CPU Cards do not need to perform UART buffering (as this would interfere with their potential use as GPIO lines).  Due to UARTs having fixed voltages, the UART signals may however require level shifting ('''on the Housing'''): the signal levels are, like all other Digital I/O in EOMA68, expected to be relative to VREFTTL.

Below is an example circuit which can be used to protect the UART-RX line, using MOSFETs.  This is entirely on the Housing PCB (not the Card).  Housing is on the '''left''', Card is on the '''right'''.

[[File:EOMA68-UART-RX-PROTECT.gif]]

Here is another example that uses schottky diodes.  D1 is to reduce the voltage slightly so that it will be below the 3.3v level that is internally supplied to the CPU Card.  The same effect could reasonably be achieved using a resistor-divider bridge.  Again this is entirely on the Housing PCB (not the Card).  Housing is on the '''left''', Card is on the '''right'''.

[[File:EOMA68-UART-RX-DIODE-PROTECT.png]]

There are also other options such as the use of a MAX2322 RS232 buffer IC.  Other options can be found [http://www.hobbytronics.co.uk/schottky-logic-level-conversion here].

== Requirements for SD/MMC and SPI ==

SD/MMC is a little strange in that it has hardware backwards-compatibility down to SPI in most controllers.  However, recently the SD/MMC standard (version 4) has excluded support for SPI.  The decision is therefore to "go with the flow" of the SD/MMC standard, but with the stipulation that there is to be *NO* expectation of explicit hardware-accelerated SPI support from the SD/MMC pins.  To be absolutely clear: base boards *MUST NOT* expect there to be hardware SPI support from the SD/MMC pins (but that "if pushed", there is a way in software to provide SPI support even if the hardware controller does not provide it).

For where SPI is explicitly needed, there are two available options:

* An additional and separate SPI interface is provided, on different EOMA68 pins.  Use of these pins as precedence is recommended.
* Even if a hardware SD/MMC controller does not support SPI it is still possible to emulate SPI using [http://lxr.free-electrons.com/source/drivers/spi/spi-bitbang.c "bitbanging"].  As bit-banging is quite CPU-intensive, and the transfer speed of SPI is 25mhz, designers of CPU Cards as well as designers of Housings need to take this into consideration.

In essence, the SD/MMC committee have caused a bit of trouble, here, but it may be best to trust their experience in that SD/MMC Cards have probably not, for some considerable time, been actually using SPI mode, but have been offering the 2, 4 (and now 8) lane capability for a long, long time.  Relative (at the time of writing) to the 80 mega-BYTES per second of the latest SD/MMC 4.0 Ultra-speed cards, 25 mega-BITS per second backwards-compatibility - some 25 times slower - would seem ridiculous to continue to maintain.

On this basis, the SD/MMC interface is therefore offered as primarily being to access SD/MMC devices (cards and peripherals), *NOT* for the explicit primary purpose of accessing SPI devices.  However, if SPI hardware interoperability happens to be available, it *MAY* be used, and for all other instances bit-banging *MUST* be provided in software.  Board designers *SHOULD* take into account that any SPI interoperability is *LIKELY* to be implemented as bit-banging, and should, as a result, avoid using it except as an absolute last resort, prioritising the dedicated SPI interface available on EOMA68, instead.

CPU Card designers must also take into account that both the SD/MMC and the SPI interfaces are also multiplexed onto bi-directional GPIO.  As most SoCs provide exactly this kind of multiplexing by default, the requirement to offer both bi-directional GPIO as well as the other functions is not technically burdensome.

= Start-up procedure =

It is required that all pins be disabled (floating tri-state) with the exception of the I2C Bus, the 5.0v Power and the Ground Pins.  I2C Bus Master is then enabled, to search for an I2C EEPROM at address 0x51.  This EEPROM contains Linux Kernel "Device Tree" data, which specifies the devices available on the motherboard, as well as the actual pin-outs.  The exact format of the EEPROM data is yet to be decided.

One important aspect of reading the I2C EEPROM is that the Card can then correctly access and initialise Housing peripherals devices.  It also defines the purpose and use of the GPIO pins (if any are required).  Also, the format of the LCD data is Housing-specific.  For example, the pinout diagram on this page assumes 18-pin RGB TTL, but some motherboards may have LCD panels which only have a 15-pin RGB/TTL interface.  Some Housings' LCD output will have EDID data (conversion to DVI, HDMI or VGA for example), whilst others will not (a fixed-resolution LCD panel where the on-board EDID data is hopelessly out-of-date is very common in mass-produced panels).  The data in the I2C EEPROM therefore provides clear specifications on all the Housing's "non-self-descriptive" peripherals.

Discussion of the startup procedure is here on [http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-January/001787.html arm-netbooks]

= Future Versions =

All LCD and GPIO pins must be tri-state floating in order that future versions of this standard can provide faster (or merely alternative) interfaces.  At the time of writing (2011), the interfaces in the 1.0 Specification are "Lowest Common Denominator" yet are still present across the majority of 2011's powerful embedded SoCs (OMAP4440, Enyxos4210, Tegra 3, iMX53, iMX6, Allwinner A10, A20 etc.)  However, in the future, the "Lowest Common Denominator" could well comprise MIPI instead of RGB/TTL, 2 lane PCI-express (or its successor), and USB-3 instead of USB-2 (perhaps even a faster version of ULPI).

As of 2011 however, the total number of Embedded CPUs supporting all these newer interfaces and still keeping to a 1.5 watt budget is precisely zero.  Support for these high-speed interfaces will therefore be re-evaluated in 2 to 3 years time, and a future version of this standard created when a large proportion of available embedded CPUs have these or other high-speed interfaces that are available at the time.

= Deliberate Mechanical Non-interoperability =

The re-use of the PCMCIA standard pinouts with no electrical or electronic compatibility requires mechanical means to ensure that newer cards cannot be inserted into legacy sockets.  The proposed solution is therefore to deploy a fascia plate on the EOMA68 card that is both larger in width than the standard 55&nbsp;mm as well as recessed by some 8&nbsp;mm, along the length of one of the 85&nbsp;mm edges.  The exact dimensions are yet to be determined, as specific PCMCIA housings need to be examined to ensure that one side can take the recessed "edge stop".  The following part, [http://www.te.com/catalog/pn/en/1717121-1 PCMCIA Ejector Assembly] from Tyco Electronics, is ideally suited: slimline and nothing at the left side.

= Physical Dimensions =

There are three sets of acceptable dimensions: as with the legacy PCMCIA interface, these must be backwards-compatible.  As with legacy PCMCIA, Cards should typically have all user-facing connectors "flush" with the standard PCMCIA size.  This will ensure that when a Card is inserted into a device, the connectors of the Card appear to be part of the actual device.  However: devices should cater for the possibility that an EOMA68 Card may have connectors sticking out of the end, to any practical height (just as it used to be the case with legacy PCMCIA).

As the EOMA68 pinouts have been designed to avoid matching the power lines of PCMCIA, there is no need for mechanical blocking.

== Type I ==

The physical dimensions are a maximum of 3.3mm just as with legacy PCMCIA Type I.  Power consumption is a maximum of 5.0 watts.  The maximum RGB/TTL resolution permitted is 1920x1080.  There is no (unreasonable) minimum resolution.

== Type II ==

The physical dimensions are a maximum of 5.0mm just as with legacy PCMCIA Type II.  Just as with Type I EOMA68 Cards, power consumption must not exceed 5.0 watts.  The maximum RGB/TTL resolution permitted is 1366 x 768.

== Type III ==

Type III Cards have a maximum height of 10.5mm.  Power consumption is a maximum of 10.0 watts.  This is typically reserved for x86-based CPUs which require up to 10 watts to operate.  The maximum RGB/TTL resolution permitted is 1366 x 768, as it is the ''Housing'' that (by way of being 10.5mm in height) can also accept Type II (5mm) Cards, which are also restricted to a maximum of 1366 x 768.

TBC: Type III Cards should not assume that there will be fans available in the devices in which the cards are inserted, and should make arrangements for the removal of heat (including heat-sink and built-in fan, within the 10.5mm height limit).

== Interoperability Restrictions imposed by height limits ==

Restrictions on interoperability with other types are protected by height.  Those restrictions summarise as:

* Housings that take the Type I Cards '''must only''' accept Type I cards.
* Housings that take the Type II cards '''must''' also accept the Type I lower-power cards (and operate correctly and fully).
* Housings that take the Type III cards '''must''' also accept the Type II '''and''' Type I lower-power cards (and operate correctly and fully).
* Type II 5.0mm cards and Type III 8.0mm cards must be '''actively prevented''' from slotting into Type I (3.3mm) Housings by ensuring that there is a physical slot in the casework that is no more than 3.5mm in height.
* Type III 8.0mm cards must be '''actively prevented''' from slotting into Type I (5.0mm) Housings by ensuring that there is a physical slot in the casework that is no more than 5.5mm in height.

In this way, Cards which have lower resolutions will not be plugged into Housings which require higher LCD resolutions than the Card can provide, nor will they drain more power than the Housing can provide.

= Thermal Considerations =

In order to reduce the cost of Housings and system design, Type II Cards should not exceed an average of 3.5 watts power consumption for prolonged periods of time, despite there being provision for up to 10 watts on the EOMA68 connector.

Cards and Housings that support the Type III 10.5mm-high cards '''must''' be designed with a Thermal Dissipation capability that takes the 10 watt TDP into consideration, as well as taking into consideration the power consumption and heat generation of the devices used on the Motherboard as well.  Whilst fan-based solutions are acceptable, the use of thermally-conductive copolymer plastics (some of which have thermal dissipation capabilities exceeding that of Aluminium) are recommended.

= Header Connectors =

Within the physical dimensions, there is absolutely no restriction on the number of connectors, interfaces, headers, expansion headers or antenna protruding from the end of the device.  For example: a Computer-based Card may typically have, for best useability, a Micro-HDMI, a USB-OTG, a 5-pin Audio Jack and a Micro-SD Card Slot.  These four interfaces fit neatly within the 54&nbsp;mm × 5.5&nbsp;mm fascia plate size limit, as long as mid-mount connectors are used.

Also, on an actual EOMA68 Card's PCB itself, there is no restriction on the number of internal expansion headers (populated or unpopulated) - the only consideration being that the Card clearly cannot have expansion headers protruding up from the PCB (for use by Engineers and Embedded Device Designers), and also have a metal shield installed around the Card at the same time.  However, there is no reason why the expansion headers should be unpopulated, supplied without a metal shield to Embedded Engineers, yet the exact same device shipped in mass-volume with a metal shield installed, for the average end-user.

The only issue to note is that there is a maximum power budget of about 10 watts (although there are four 5.0V 0.5A pins) but also that there is a practical maximum power dissipation of EOMA68 Cards of about 4 to 5 watts.  There is no provision in the standard for air-cooling (fans) in the cases: most devices will be a passive-cooled layout.

If however the EOMA68 Card is designed to operate "stand-alone", for example by being provided with a Power Connector on its user-facing edge or by making use of USB-OTG, then of course the designers are free to disregard these constraints.  If however the Card is also expected to operate inside a conformant device, then it must adjust accordingly and stick within the 4-5 watt heat dissipation budget.