I see Quark as Intel's effort at an x86 microcontroller and admission there are as many apps at the low end as at the high end of micros these days.
Wearables is more of a fashionable focus these days. Note one of the first reference designs is an industrial control board. Also note: ARM is getting the new design wins in industrial mil/aero boards.
Eh, I don't think Quark will ever fit in a watch or headphone, let alone run it for more than a few minutes before the battery runs out. Remember it has a 15x15mm package, 2.2W TDP and requires external flash, power hungry DDR3 and many external chips for IO, LCD display, ADC/DAC etc. It is not an MCU.
Note that a Cortex-M0 is actually significantly faster in every way despite its tiny size. All the x86 baggage and overheads make no sense in this market, it's not like there are a lot of washing machines or toasters still running DOS.
the flycatcher is only a 12k gate device. Of course it cannot reach the power levels of a 32bit pentium design. You should be comparing flycatcher with a 8051. Again, I don't see a multi-core quark for the applications it is targed for, e.g. watches, head phones, health monitors, etc.
Yes the trademark is owned by ARM, but that's completely unrelated to the IP. My point was that ARM cannot use AMBA to get any leverage over anyone like you suggested. Effectively AMBA is FRAND by definition as it is free and open. There are some serious legal restrictions on most "open source" (like GCC), so AMBA is actually far more open and less restrictive to use than what people call "open source"...
I don't understand why you think Quark should be multi-core. It is a 486, so why 2 of them when 1 is already awful enough? Using an old and slow 486 in Quark doesn't make any sense at all - it is so slow that even a Cortex-M0 will run rings around it on pretty much any aspect you can imagine (raw compute performance, DSP performance, interrupt latency, bit banging etc). If you compare it with higher-end Cortex cores it looks even worse...
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.