[Arm-netbook] Another chip to consider for a future EOMA product

[luke.leighton]

On Thu, Oct 3, 2013 at 7:06 PM, Derek <dlahouss at mtu.edu> wrote:
> In the incredibly bad form of talking to myself...
>
> Links:
> https://communities.intel.com/servlet/JiveServlet/previewBody/21822-102-2-25114/Galileo%20Schematic.pdf
> http://www.pcworld.com/article/2052000/intel-outfits-opensource-galileo-computer-with-quark-chip-targets-diy-crowd.html

 i was _really_ looking forward to this SoC... but going over the
schematics i think the people who designed it must have been smoking
crack.  i mean that in the nicest possible way. ok, let me start
again, pretend i didn't say that, because i'm intending to point intel
employees at this.

 dear intel engineers,

 please for pity's sake study the target markets, schematics and
pinouts of at least 50 separate ARM, MIPS and OpenCores.org processors
before designing *anything* else around the Quark core concept.

 if you choose to ignore this advice then please, at least out of the
*huge* budget that you're working with, and the enormous NREs that
you're putting down on mask charges, consider slipping say 0.01% of it
towards the rhombus tech project just for... just for the sheer hell
of saying "thank you" on the incredibly slim chance that you listen to
the advice here and make a *successful* low-cost low-power x86 SoC in
the future.

 let's look at the interfaces.  you have:

 * PCIe (that's a really "wow!" choice, but it's useful for certain
top-end markets... let's see what else the SoC can do first, ok?)

 * USB-Host x2 (good!  USB2.  low power.  2 USBs saves on a Hub IC in
some cases)

 * USB-OTG (good!  can make gadgets out of this)

 * 2x SPI (good! one for low-speed MicroSD, one for NOR Flash, etc.
etc.  lots of embedded uses for this)

 * SDIO (good!  can use for MicroSD and WIFI... but there's only one???)

 * I2C (good!  err... how many? one?  ONE I2C??? are you... what???
even the 48-pin STM32F has 2 I2C interfaces!)

 * 2 UARTs (good... but 3 would be better.  1 "full" one and 2 with
only TX/RX.  2 "full" and one TX/RX even better)

 * RGMII (good!!!  impressive!  actually i just spotted _two_ ethernet
ports - awesome!)

 * 16 pins GPIO (good!  whew.  looks like most of these are EINT
capable.  whew.  good!)

 * DDR RAM: 2x 8-bit (only 16-bit Data) and 16 address lines.

 * LSPI.  good.  don't know what it's for, looks connected to quite a
lot of stuff, including boot flash.  so... good.

 * JTAG.  good.

what's missing:

 * ADC.  of any kind.  no mic input, line input, no 12-bit low-res
ADC.... nothing.
 * DAC. of any kind.  nothing.  no headphones... nothing.
 * I2S (AC97)
 * CAN bus
 * PWM.
 * GPU
 * SATA
 * SP-DIF
 * Standard "Memory" Bus with Chip-Select lines (suitable for TSSOP-48
NAND ICs and DM9000 Ethernet PHYs etc.)

specific comments:

* there are absolutely no Multiplexing functions of ANY kind.  page 7
of Galileo Schematics (Doc G87171) shows the SD/MMC card only has 4
data lines used.  that's four CRITICAL lines on such a low-pincount IC
that are WASTED.  those could have been multiplexed to.... anything!
PWM, CAN-Bus, anything!

* again. p7 - the SUI0_* lines are completely wasted!  you could have
multiplexed I2S onto those!

* again.  p7 - USBH0_PWR_EN and USBH1_PWR_EN - why?? this is GPIO.
these could have been called "GPIO", or they could have been used as
multiplexed capability.

* again.  p7.  SD_LED.  LED?  another wasted pin.  we're up to 13
wasted pins so far, just on one schematic page!

* again.  p7.  MAC1.  great that you have 2 Ethernets... but if only
using 1, that's now 21 pins wasted which could have been used
multiplexed to other functions.

 * p6 looks ok...

 * p5.  ARGH.  16-bit RAM interface.  that's... so unbelievably bad
it's hard to put into words.  hey look!  with 21 pins wasted above,
there are some functions that could have been multiplexed, giving
another 16 RAM lines!

 the rest of the schematic pages are basically interfaces.

 so, let's look at the markets, and do a comparison to what's available.

 with no CAN bus, the entire industrial market is out.  completely
wiped out.  nobody in industrial markets will be the slightest bit
interested.

 with no ADC, DAC or PWM, they *certainly* won't be interested.  most
other "embedded" purposes, they will look instead at say the new
500mhz Atmel ARM Cortex A5 (which has built-in PMIC capabilities thus
reducing the BOM greatly when compared to other solutions).  or if
500mhz is too much, they'll look at one of the Freescale sub-200mhz
offerings (32-pin for under $1.50) or perhaps an STM32F which has
Ethernet, CAN, ADC, DAC, PWM - all of these SoCs do.

 so the entire industrial market - everything from washing machines to
quadricopter controllers to 10-year-lifespan precision tooling
controllers - is covered by single-chip solutions, most of which only
require to be surrounded by capacitors and do not need a separate PMIC
or any inductors (unlike the Quark which requires a TPS65210 which is
$3 in 1k volumes on its own!!! let alone the Ferrites!)

 no chance for the Quark, there, then.

 no graphics.  no video outputs of any kind!  that's an immediate
show-stopper on putting this into say the android or any other market.
 even the beaglebone has _some_ sort of video output (which has to be
converted via an external costly HDMI conversion IC) but at least it's
got... _something_.  there's not even CVBS, S-Video or VGA!

 ok, so there's PCIe... but have you _seen_ the cost of (and,
crucially, the amount of _power_ used by) these external GPUs?
there's only *one* low-power PCIe GPU available on the open market:
it's the XGI Volari Z11 and if you ask them very very nicely they'll
charge you *TWELVE* (12) U.S. dollars in 10k volumes for it.  and it's
only 2D.  but... it's *literally* the only available PCIe GPU below
1W.  the closest alternative is an 8 (EIGHT) watt very old GPU from
SiS, which needs a minimum of 256mb DDR RAM to go with it, pushing the
entire budget up to around... 12 to 15 watts.  where the CPU is under
5% of that budget.

 so let's recap.

 to put this SoC into industrial or embedded purposes, you have to use
expander ICs that cost more than the price of a single integrated CPU
which already has those functions, and you still need a PMIC to power
the Quark so the BOM is basically carrying the Quark as dead weight,
because you might as well replace the entire lot *with* a single
industrial integrated Cortex M0, M3 or M4 CPU.

 to put this SoC into a mass-volume market, you'd need... well.... you
can't _get_ ultra-low-power PCIe-based GPUs, and if you wanted to do
video playback you'd need a PCIe Bridge PHY IC in order to multiplex
out onto say one of those Broadcom MPEG decoder ICs... that's if
Broadcom will actually talk to you.  usually they're extremely
hostile.   so even if you're big enough to get their attention, the
BOM's _way_ too big.

 so that market's completely out.

 the "arduino-like" market falls into a similar category to industrial
/ embedded... except even the open community will think twice about
buying it, because there's not enough multiplexing for them to use it
for several possible scenarios.

 as an "AMD Geode LX" replacement, it's an immediate failure.  the
Geode LX has the CS5536 which is an amazing companion IC, sporting
PCI, IDE, PS2, 3 UARTs, 4 USB2s, GPIO, PWM, I2C and much more.  it's
old, but it's still going strong.

 overall, then, i'm struggling to think why this SoC would be
desirable even as a demonstrator product.  the only thing i can think
of is as a collector's item.

 even if you, intel, made a similar companion IC (which, btw, if you
did a single-lane PCIe GPU with built-in MPEG and other video decode
now _that_ would be a desirable product!), you'd have to be *very*
careful about the power consumption.  even single-lane PCIe starts to
push the power up, entirely defeating the object of the exercise.

i just... i'm really sorry but i cannot see a single market where this
SoC would be successful.  i realise that you *may* be interested in
sub-licensing the Quark core into other SoCs, but that is something
that, traditionally, you've never done before so people don't really
believe you'll let them (or you'll charge them an uncompetitive
fee.... on unproven technology!)

so.... you're going to have to do better.  _much_ better.  it's good
that you've finally got the power down, but this is *not* an area
you've ever had a successful product in... and it shows in the choice
of interfaces.  painfully.  zero multiplexing!  what were you
thinking???

so please.  go get the schematics for the following ICs.  study *ALL*
of them.  find more like them.  they're all publicly available.  ONLY
then should you consider designing another SoC.  please also look me
up in the database (intel's internal one) because i am in touch with
the people in poland: there is some more advice and also an example
SoC pinout available for you to follow, as well.  only 304 pins, and
that's *including* 100 taken up on 32-bit DDR3 RAM (75 signal lines,
25 DDR power/GND lines).

here's the list: A10, A10S, A20, A13, OMAP3530, STM32F103 (48, 64, 100
and 144 pin variants), Freescale's equivalents of the STM32F, Atmel's
M0/M3/M4 and A5 range, Freescale's iMX6, Samsung Exynos 4412 and 5xxx
series (you can get schematics for the origenboard etc. if you look
hard enough).  Also i recommend you track down at least one of the
latest Rockchip SoCs (the dual-core 40nm one).  Even Ingenic's jz47xx
series, although it's only the latest ones that are really really
good, but the jz4720 sold _millions_ of units back in 2006 to 2008
even though it's a 176-pin QFP 350mhz MIPS, its level of integration
was just stunning.

multiplexing is the key.  you need to sit down and think for - not
kidding - MONTHS, designing from *MARKET ANALYSIS* how to fit
particular applications.  if you decide "Smart TV is one of my
markets", you go "ok, we need 2 transport streams, we need SPDIF, we
don't need CAN bus so we can multiplex CAN with SPDIF.  we don't need
a CSI (camera) as well as Transport stream, for a Smart TV product, so
we can multiplex TS with CSI".  then think of more markets, add more
interfaces, check them.  then more, then more, then more, check again
and again and again.  the example SoC pinout i sent your colleagues, i
spent *two months* on that, and one year later i *still* spotted some
errors that need correcting... or more pins added.

anyway.  i look forward to hearing whether you'd be interested in
collaborating to make a *successful* SoC based around the Quark.  i'm
happy to advise, because i want to put that successful SoC into
products!

l.