Intel Quark D1000 microcontroller [pdf] | Hacker News Reader

Intel Quark D1000 microcontroller [pdf]

intel.com

13 pointsluu14 comments

Open articleView on HN

Important characteristics of the Intel® QuarkTM microcontroller D1000 CPU are provided in the following list:

• 32-bit processor core

• IA-32 instruction encoding [1]

• 5 stage pipeline

• Harvard architecture

• 8KB of on-chip data SRAM

• 32KB of on-chip data/execution FLASH

• Deterministic 21 Cycle interrupt latency

• Minimal processor initialization for fast power-up

Above from the PDF

[1] IA-32 architecture subset, no segmentation support.

I don't think [1] should be a footnote. This is not an x86. This is a new 1970-style ISA with a textbook RISC implementation, but without the ISA that made RISC work. I predict this will fail, not because of the Quark ISA, but because Intel can't compete with the sheer diversity of microcontroller implementations that can only come from a highly competitive market. ARM currently hold sway in this market, with MIPS in niches. In future I expect to see RISC-V show up where license cost or customization matters more than software legacy.

I wouldn't bet against the oldest and biggest CPU vendor.

Atmel of Arduino fame had $1.4B in sales last year. Microchip who was the hobbyist's go to before the Arduino had $2.1B in sales. Freescale who is the corporate descendant of Motorola microcontrollers had $4.6B.

Intel had $55.9B in sales and $11.7B in profit - more then enough profit to buy every chip those other three companies made last year.

Intel missed mobile - almost no cell phones have Intel inside - they are going to catch the next wave or die trying.

But, unlike the PC market with 2-3 major manufacturers, Intel can't bully around thousands of independent shops and OEMs that buy 1K/10K/100K quantities of Atmel/NXP/Freescale/Renesas/TI parts every year.

I lead system architecture for one of them and Intel is so off my radar that I wouldn't even look twice at the Quark/Edison line. Unless they want to give them to me for free, that is. If those chips are their IoT play, I'm not seeing any advantage yet. Show me how you're going to complete with TI or Broadcom.

And how many $3 D1000s do you have to move to match the margin generated by one server-class CPU core?

(BTW, NXP bought Freescale earlier this year so it's really 4.6B + 5.6B once the merge is completed.)

What's the tooling like for this ISA, anyone know? IMHO that's what will make or break this thing. If you can't output code for it from GCC or LLVM then why even bother looking at it.

GCC can compile to both 32- and 64-bit Itanium, as can Intel's toolchain (which is what I imagine most people will be using for this).

What? This has nothing to do with Itanium.

Ugh, never mind, I confused IA-32 (x86, in this case a stripped-down x86) with IA-64 (Itanium).

There's a lot more to a micro controller than the CPU. Intel's Micro controller offerings have traditionally had weak timer and ADC peripherals.

Edit: Just glanced through the user guide [0]. The timers are pretty basic.

The general purpose one timers only count down, and don't have capture/compare logic (lame!). It does not appear that the timer end state (all 0's) can do anything other than interrupt the CPU (like triggering the ADC, toggling the state of an IO, or capturing the state of a comparator or IO).

The watchdog only seems to have a single clock source (CPU clock), with no backup like in the MSP430 series. So you can probably get stuck in a low power mode, and there's no protection if the clock source rolls over and dies. There's an interrupt-then-reset mode, which is nice, I guess.

The real-time clock is nothing that can't be implemented in lightweight software using a general purpose counter on, e.g., MSP430.

The ADC is a bright spot. The channel sequence table appears to allow channels to be sampled in arbitrary order, and a multiply-adder can apply calibration constants to the raw conversion before the data leaves the peripheral.

[0] http://www.intel.com/content/dam/www/public/us/en/documents/...

It bothers me that you can't execute out of SRAM. That doesn't bode well for bulletproof firmware update, unless there's something that I'm missing.

Firmware upgrade doesn't necessarily need internal SRAM, it just needs to be able to execute out of one bank FLASH while writing the upgraded one. Its perfectly workable and bulletproof-able with this setup.

I want to know what the advantage, if any, is of using a Quark over say a PIC32 or an Arm?

Reply on news.ycombinator.com