Scott Sullivan <scott <at> ss.org> writes:

This will likely relegate it with the other reject CPUs because there is a difficulty in finding low power discrete GPUs.

No SATA either. Blech.

Scott Sullivan <scott <at> ss.org> writes:

At 400Mhz, it was a low value proposition to begin with.

Well, let us note that those are x86 clocks, not ARMv6 clocks. Not that I claim to know how much work this Quark is doing per clock, but certainly a Core 2 running at 700 MHz would lap a RasPi.

Now, if it doesn't get that same work done, then what is Intel thinking?

On Thu, Oct 3, 2013 at 7:06 PM, Derek dlahouss@mtu.edu wrote:

In the incredibly bad form of talking to myself...

Links: https://communities.intel.com/servlet/JiveServlet/previewBody/21822-102-2-25... http://www.pcworld.com/article/2052000/intel-outfits-opensource-galileo-comp...

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.

On Fri, Oct 4, 2013 at 9:53 AM, joem joem@martindale-electric.co.uk wrote:

On Fri, 2013-10-04 at 01:11 +0100, luke.leighton wrote:

...

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.)

JM steps away from keyboard.... and runs away screeemminngg.....!!! ...aaaarrrggggHHHHhhhhhhh!!!!.....

(but then again, are we supposed to synthesise those by purchasing/adding our own IP / or perhaps even add an Allwinner A20 to get those functions on the cheap? :D )

yeah... exactly :) uhm.... wait... how would you join an A20 to a Quark X1000? USB perhaps? oh hang on, we need those USB ports for other purposes: let's put down a USB Hub IC as well, yaaaay!

l.

On Fri, Oct 4, 2013 at 10:26 AM, Stéphane Goujet stephane.goujet@wanadoo.fr wrote:

Hello,

The remarks I will make are based on the Quark X1000 datasheet, not on the Galileo documentation.

Le Fri, 4 Oct 2013 01:11:55 +0100, "luke.leighton" luke.leighton@gmail.com a écrit :

...

• 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)

There is no OTG port on the SoC, but a Device port.

ok, well spotted.

...

• RGMII (good!!! impressive! actually i just spotted _two_ ethernet

ports - awesome!)

2 ports indeed, but RMII (Fast Ethernet), not RGMII (Gigabit).

oo ouch. ok. that explains why they're 8-bits. RMII - reduced MII, wow! i'd never heard of that before. makes sense.

...

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

I have to say I really do not understand why it supports x8 chips only and not x16. I must miss a point.

because it's ultra-low-power. at 400mhz (800mhz DDR3) you'd be looking at only... what... 175mA? i think *finger-in-air* 32-bit DDR3 ICs @ 400mhz use around 350mA.

the only problem is... they just halved the memory speed! but, the whole SoC is only running at 400mhz anyway so in some ways it doesn't matter.

l.

On Fri, Oct 4, 2013 at 1:57 PM, Stéphane Goujet stephane.goujet@wanadoo.fr wrote:

Le Fri, 4 Oct 2013 12:25:58 +0100, "luke.leighton" luke.leighton@gmail.com a écrit :

...

On Fri, Oct 4, 2013 at 10:26 AM, Stéphane Goujet stephane.goujet@wanadoo.fr wrote:

...

...

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

I have to say I really do not understand why it supports x8 chips only and not x16. I must miss a point.

because it's ultra-low-power. at 400mhz (800mhz DDR3) you'd be looking at only... what... 175mA? i think *finger-in-air* 32-bit DDR3 ICs @ 400mhz use around 350mA.

What I meant was 1x16, not 2x16, sorry for the misunderstanding. They insist on saying it supports 2x 8-bit wide chips and nothing else, but I cannot see why we could not use a single 16-bit wide chip (much easier to route).

oh right. yes, i see. ahh... i think it's going to depend on how they implemented the DDR3 controller. let's think for a moment... intel have a habit of using their own "stuff", not licensing other peoples' industry-standard hard macros, and this is their first real foray into anything below 32-bit memory buses [at least for 2 decades, it is!]

so whereas everyone else would license a DDR3 hard macro that conformed to the specifications and allowed flexibility (because otherwise as a hard macro licenser they'd get no customers), there's no guarantee that intel have bothered to implement anything other than what they've said that's been implemented.

l.