The first version of the 96Boards Consumer Edition (CE) specification is available on this website in PDF format here. Please post your comments and questions on this forum.
i’m the author of the EOMA standards, which have been developed openly and publicly over the past few years. the EOMA standards are designed as long-term consumer-friendly simple standards where the primary motivation is that the sales pitch for initial sales as well as future upgrades is “Just plug it in: it will work”.
i would therefore like to offer some insights into the 96boards “consumer” standard. i have to warn you, and i apologise deeply in advance for this, that it’s not a favourable assessment based on the intended market deployment (“consumers”). my advice here is that you should have announced this a long time ago, opened up the forum and the standards process to consultation, waited for at least one year, then announced preliminary boards on a draft standard, then waited another year to see if it was found to be successful, and then and only then finalised the standard.
so, the first point: both the web site and the standard (which took a long time and over 5 clicks to find) are completely unclear as to what the standards are for. i assume that because the word “consumer” is included in the first standard, that it is targetted at the average end-user, however i have had to infer that (logically deduce it). i assume therefore that the intent is that the average end-users to whom products are targetted will want to upgrade at a later date, keeping the casework and peripherals just like some (very advanced) PC users do at the moment. i assume that the intent was to make it easier to follow this upgrade path, although that is not entirely clear and is speculation.
so that’s the first thing: the actual purpose of this standard is completely unclear!
moving on from there: the key to a successful standard is that there should be absolutely no possibility for confusion in the eyes of the end-user. High-end Gaming PCs for example take months to plan and build. the average PC is slightly better as long as you steer clear of internal PCIe upgrades (USB2 and now USB3 peripherals, which, thanks to the USB standard, “just work”). even PCIe cards, as long as you have a full tower, you can pretty much just buy whatever and you can expect it to “just work”, again, thanks to the auto-negotiation at the hardware level.
this gives a clue as to what is really really important about developing end-user-targetted standards: there must be NO optional interfaces.
so the first indication that there’s been a design mistake is on page 5, “Optional MIPI CSI-2”. this means that anyone wishing to purchase a 96boards-compliant host device - especially if they may be expecting in the future to upgrade - must carefully review both the initially selected hardware. but, the problem is that even in that initial selection there will be fear in their minds, “what if i cannot find an upgraded board in the future which has the EXACT same options as what i am intending to buy right now?”
the second source of confusion is on the SoC Location Options. assuming that end-users will be considering upgrading (possibly on a financial budget) or just simply being socially and ecologically responsible by re-using parts that they already own, it is reasonable to expect that they will want to keep the casework when upgrading. so it’s not that there are two possible power dissipation options within the standard, it’s that catering for both has not been made mandatory that is the key source of confusion.
page 6: DRAM and eMMC being optional on the board, that’s absolutely fine. specifying minimum RAM and boot flash size requirements, that’s a great idea. microSDHC: i don;t fully get the rationale here for mandating microSD. also, it’s not been made clear as to what the minimum compliant standard is (3.0 or 4.0). this is especially important given that the 4.0 standard [stupidly] removes SPI compliance.
page 7: WIFI / bluetooth. this just drives up cost. i don’t understand the rationale for increasing cost.
page 7: Display Interface. i don’t understand the rationale for mandating the interface type. it guarantees exclusion of lower-cost SoCs (Allwinner A13, A10s, quad-core A33, and many others that provide no MIPI, DisplayPort or HDMI functionality), and also results in case-work confusion over the choice of Type A, Type D, MHL or DisplayPort connectors. it would have been far better to leave all of this up to the OEM designers, specifying a base case standard and allowing them to create matching 0.1mm stainless steel port-plates just like in ATX PCs today.
again: on the audio interface, this once again excludes certain SoCs. audio is very very tricky: there is such a massive amount of variation. this indicates that it should have been left up to the OEMs to decide how to provide audio, with the standard specifying that it must BE provided but leaving it up to them as to how it should be done (and to provide a matching port-plate).
MIPI 1-4 lane selection, with implementations being allowed to use less lanes: GOOD. this is the CORRECT thing to do.
regarding the sentence “Note that if a single DSI interface…” - i genuinely cannot make heads nor tails of it. i don’t understand it at all. but the red flag is “optional as to whether the on-board interface is useable at the same time”. this is an absolute no-no.
page 7: Camera Interfaces. whilst allowing selection of between 1-4 (or 1-2) lanes at the hardware level is perfect, the optional provision of CSI1 most definitely is not. the scenario which gives the “red flag” is the one where an end-user purchases an initial unit with 2 CSI interfaces, then later purchases an upgrade unintentionally with only one. in the strictest case they will just have entirely wasted their money because there is actually nothing wrong (under warranty) with the new unit, but in the worst case scenario there will be considerable product returns. as you know, in the consumer market, ANY returns is extremely bad, and above a certain threshold the entire product line - and the standard itself - will be killed off by every single retailer.
destroying the reputation of the standard, due to angry end-user report over time, is perhaps the absolute worst thing that could possibly happen… and unfortunately, based on the standard itself, we can pretty much guarantee that that is what is going to happen.
“GPIO signals” - this is the very first mention of GPIO in the entire document, and it’s done as an after-thought! it’s only because i have developed standards myself, and i am familiar with dozens of ARM and other SoCs, that i know what is being referred to, here (multiplexing). that it is not clearly spelled out will be a severe source of confusion to OEMs.
page 7: USB ports. “two Type A OR Type C ports (USB 2 or 3) shall be provided” - again, massive source of confusion for end-users when it comes to choosing an upgrade. casework may not be saved when upgrading.
regarding USB-OTG: i also thought about whether it would be wise to include USB-OTG in EOMA standards, and in the end only decided to include it (non-optionally) in one standard which was “dongle-like” (similar to these HDMI-USB dongles), on the basis that the power requirements of such small devices was well within the 500mA power provision of USB-OTG.
at no point did it ever occur to me to allow USB-OTG to be optional within any of the EOMA standards-compliant connectors. i did however mention that it would be fine to have USB-OTG as an optional interface via the general user-facing fascia plate, where the OEMs were permitted to place any interfaces of their choosing out through that area. there are several standards that follow this guideline, and it is good practice.
so, again, there is a source of confusion for end-users in both selection of their initial purchase as well as for future upgrades. and unfortunately the confusion multiplies with the number of permutations from all the various options.
page 8: audio. mandating audio via bluetooth, again, i do not see a description of the rationale behind this as a mandatory choice (nor why bluetooth itself is a mandatory requirement). I2S/PCM - which is it? is it I2S or is it PCM? there is no link to the I2S standard on page 15 where References are given, so it is unclear. also, I2S is quite a high-end standard, which immediately excludes certain SoCs. additionally, which variant of I2S is permitted: the 5-pin variant or the 8-pin variant? all in all - and i know this because i have had to think about it for some considerable time - the audio section of this standard leaves a lot to be desired. it would be far better to leave it up to OEMs, merely stating the minimum requirements (stereo, 16-bit, minimum of 32khz, mono mic), just like it is done with ATX PCs for at least a decade and a half, now, with the 0.1mm steel fascia plate.
page 8: DC Power. this, as i have discovered, is one of the hardest things to get right. the EOMA68 standard - quite by accident - is actually almost USB-OTG compliant (except being a maximum of 5.0 watts). it is then possible to use SoCs such as the Allwinner AXP209 and a SY6208, or for higher power provision for portable devices i have recently discovered the LTC4155 to be a perfect match as it can supply up to 15 watts, has automatic dual-supply selection between 5.0V DCIN and USB-OTG, and has boost power for USB-OTG from the on-board battery and so on. to my eye, the power provision section of page 8 and 9 looks… complicated, unclear, and expands the source of confusion for end-users into the realm of the power sources that they will have to select and then replace later when upgrading.
but the real serious problem here with this standard is in the sentence “Limitations on available power shall be clearly documented”. this is a standard. you’re supposed to tell us what is required!
page 9: power measurement. excellent idea!
page 10: power button being external or via a pin connector: great idea. implementation note: yeah, i too had the same thought for example on one board i have designed the power button is connected directly to the AXP209, whereas on another it is wired directly to the SoC’s “reset” line. the only thing not made clear is where the switch actually resides.
page 10: external fan connection. +5V or +12V - bad idea. it should be one or the other, not both.
page 11: UART: second UART, again: confusion. there should either be one, or two, but not one OR two interfaces. also you need to be much clearer as to the levels.
page 11: JTAG. making a particular JTAG interface mandatory will automatically exclude certain SoCs. this is generally inadviseable.
page 11: expansion connectors. this is only the second mention of GPIO, which should have been included right at the start in the summary (mentioned as multiplexing).
page 12: here is where we see the extent of the possible confusion for end-users as well as for OEM implementations. there are no less than FOUR mentions of the word “optional”, and we also see something that has not been specified before (I2C interfaces) but is only mentioned in passing. it is important to have a section on I2C because there are minimum speed requirements for I2C that need to be clearly spelled out.
only now, on the “expansion notes on connector” is multiplexing mentioned. GPIO needs to have its own special section because there are power requirements, speed requirements, TTL level requirements and much more. did you remember to specify the voltage levels of the GPIOs? is in and out okay? can the GPIO be tri-state? what is the minimum resistance during tri-state? none of this has been covered in prior sections but the standard has moved on to the connectors already without mention of the GPIO in its own explicit section.
general notes: the choice specifically of 1.8V for GPIO is a poor one. it guarantees that any SoC that does not provide exactly 1.8V GPIO must now include external bi-direction level shifters. and given that the GPIO ports are multiplexed, mezzanine boards are now made both more costly as well as much more complex.
it would have been far better to provide a reference voltage (VREFTTL) and to specify that when doing GPIO the VREFTTL rail must be used as the source for pulling HIGH/LOW. the VREFTTL voltage may then be put into one side of a level shifter (if it is required at all). quite often it is sufficient to choose a GPIO expander IC, and to power the GPIO expander IC from the VREFTTL rail.
so you have specified one pin to be the 1.8V “power reference” line - this pin is already allocated. it should have been simply “VREFTTL”, with the possibility of VREFTTL being between 1.8V and 3.3V.
in this way you would have allowed far more low-cost SoCs to be selected, without the mandatory addition of level-shifter ICs that will, without a shadow of doubt, increase the BOM for any SoC that is not exactly 1.8V. given that some of the SoCs on the market can be as little as $2 in 10k volumes, the addition even of a single $1 16-pin level shifter IC - or worse a level-shifter IC with two-way port selection (in order to cater for the optional interfaces) makes the deployment of such SoCs completely pointless!
overall then, it saddens me to have to conclude that this standard is simply not well thought-out, from several perspectives. the above is by no means exhaustive, but it is clear that the standard is a product of how it was developed.
if you believe that these are valid points that should be addressed, if you would like some assistance to develop future standards, i will be available to assist as long as you make it clear how i may financially benefit from doing so, both short and long-term.