Design Con 2015
Breaking News
News & Analysis

Intel Tackles SoC With Quark

10/7/2013 10:35 AM EDT
25 comments
NO RATINGS
More Related Links
View Comments: Threaded | Newest First | Oldest First
krisi
User Rank
CEO
ARM bus?
krisi   10/7/2013 1:31:40 PM
NO RATINGS
Did I did read it right, Intel is using a bus defined by ARM?

nickflaherty
User Rank
Blogger
Re: ARM bus?
nickflaherty   10/7/2013 4:11:58 PM
NO RATINGS
Yes, that's right. Intel has been an ARM licensee since StrongARM (Xscale) and acquired other ARM licenses with acquisitions such as Zarlink, so it has some expertise with the AMBA technology. And there is no risk of ARM being able to use that as a business lever - you could argue that AMBA is so pervasive in SoC it should be licensed on fair and resonable (FRAND) terms, but if you use it to get an advantage over Intel, then what's to stop that happening to TI, or Samsung, or any other licensee. To keep its business model intact ARM has to be scrupulously fair with its licensing.

krisi
User Rank
CEO
Re: ARM bus?
krisi   10/7/2013 4:17:51 PM
NO RATINGS
thank you Nick for the explanation, makes sense


BTW, I thought Intel aquired only demodulator and tuner business....didn't realize that included Amba

Wilco1
User Rank
CEO
Re: ARM bus?
Wilco1   10/7/2013 4:54:51 PM
NO RATINGS
Nick, AMBA is a free an open standard than anyone can use.

nickflaherty
User Rank
Blogger
Re: ARM bus?
nickflaherty   10/7/2013 5:12:25 PM
NO RATINGS
Indeed it is but the trademark is still owned by ARM and ARM is the dominant supplier of AMBA-based interconnect IP so it's not exactly open source.

Wilco1
User Rank
CEO
Re: ARM bus?
Wilco1   10/7/2013 5:28:40 PM
NO RATINGS
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"...

Bruzzer
User Rank
Freelancer
Re: ARM bus?
Bruzzer   10/7/2013 6:45:31 PM
NO RATINGS
Right. ARM cannot use the AMBA Open Bus standard against Intel.  But Intel can certainly taper in and use the AMBA Bus standard for development against ARM.

Mike Bruzzone, Camp Marketing

krisi
User Rank
CEO
Re: ARM bus?
krisi   10/7/2013 7:03:36 PM
NO RATINGS
But in the past Rambus conceived some IO memory schemes, patented them and then demanded high royalty rates (7% if I recall), are we sure ARM is not going to do the same?

dynamited
User Rank
Rookie
ARM graphics?
dynamited   10/7/2013 2:58:47 PM
NO RATINGS
Yeah, that is confusing, a story about Intel quark and the only picture is one of ARM architecture. I think the story misses the point, quark will never be multi-core.

nickflaherty
User Rank
Blogger
Re: ARM graphics?
nickflaherty   10/7/2013 4:08:45 PM
NO RATINGS
No confusion - that is the block diagram of the X1000 from the Intel datasheeet released on Friday - ARM devices don't use a bridge, that's an Intel architectural feature. The point is that it looks more like a chip based on the ARM core than previous devices, uses the AMBA bus and is nominally aimed at IoT...... there you go. It can't get as low cost or low power as chips based on the M0+ ore, so it will have to have a multicore version if it is to compete in that middle ground or it will die - how Intel will do that is a very interesting architectural question.

Wilco1
User Rank
CEO
Re: multi-core 486?
Wilco1   10/7/2013 5:18:23 PM
NO RATINGS
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...

dynamited
User Rank
Rookie
Re: ARM graphics?
dynamited   10/7/2013 5:49:12 PM
NO RATINGS
From your article,

http://www.electronics-eetimes.com/en/arm-targets-low-cost-8-and-16bit-designs-with-new-m0-flycatcher-core.html?cmp_id=7&news_id=222911689#

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.

Wilco1
User Rank
CEO
Re: ARM graphics?
Wilco1   10/7/2013 7:34:02 PM
NO RATINGS
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.

nickflaherty
User Rank
Blogger
Re: ARM graphics?
nickflaherty   10/7/2013 10:34:54 PM
NO RATINGS
Intel is very clear that it has several customers working on smart watch and wearable designs with Quark, but your comments are even more relevant for IoT applications

rick merritt
User Rank
Author
Quark = x86 microcontroller
rick merritt   10/8/2013 12:58:22 AM
NO RATINGS
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.

rick merritt
User Rank
Author
Re: Quark = x86 microcontroller
rick merritt   10/8/2013 1:01:04 AM
NO RATINGS
Said another way:

Intel's Quark: Too small for gateways, too big for nodes but juuuuust right as an x86 microcontroller for a bunch of embedded apps.

Wilco1
User Rank
CEO
Re: Quark = x86 microcontroller
Wilco1   10/8/2013 6:49:29 AM
NO RATINGS
Quark is not a microcontroller either. It requires DDR3 RAM. No on-chip flash. No ADC/DACs. Maximum bit toggling rate at 230Hz (Herz, not kiloHerz).

I'm sure Quark is fine for the Arduino boards for experimenting and educational use. But seriously, do you expect anyone to replace their current MCU solution with Quark?

nickflaherty
User Rank
Blogger
Re: Quark = x86 microcontroller
nickflaherty   10/8/2013 7:57:54 AM
NO RATINGS
That's the thing about this launch though - there are plenty of Intel architecture processors available for embedded boards (including multic-core devices), but this is very deliberately aimed at the microcontroller market in wearable devices and IoT - and, like you, I just can't see it. Maybe Intel thinks the 2W TDP or the 1V core voltage will be enough to get into those designs, or, as I suspect, there is a stripped down version with a much lower TDP in the pipeline - that's the only way I can marry up the public statements with the technology we saw last week. 

Wilco1
User Rank
CEO
Re: Quark = x86 microcontroller
Wilco1   10/8/2013 9:09:22 AM
NO RATINGS
Yes it is quite possible that Intel was talking about some next generation variant in the future. In that sense you'd hope this time it will be less troublesome than the process of making x86 suitable for phones (though 5.5 years after launch of Atom, x86 is still almost non-existent in phones...). As is, Quark has no future beyond given away for free for educational purposes.

KB3001
User Rank
CEO
Re: Quark = x86 microcontroller
KB3001   10/10/2013 5:57:05 PM
NO RATINGS
"As is, Quark has no future beyond given away for free for educational purposes."

 

And even there, I do not see it becoming much of a success. I mean if I can get cheaper, higher performance and less power hungry Arduino and other MCU boards from a variety of providers, why would I ever bother with Intel's Quark? The software legacy argument does not hold anymore, wake up and smell the coffee. Another gimmick from Intel if you ask me....

DMcCunney
User Rank
CEO
IoT != Linux
DMcCunney   10/12/2013 3:30:48 PM
NO RATINGS
Another issue is where this new architecture will actually compete. SoCs based on ARM's M0+ Flycatcher core will not run Linux, although they do hit the sub-50-cent price point for the IoT, including security engines and targeted peripherals.

I'm not sure whether running Linux is relevant.  The key in Internet of Things is Internet, which means the Thing must have an IP address and be able to communicate with other Things via TCP-IP.  That requires being able to implement a TCP-IP protocol stack on the Thing, but doesn't require the Thing to run Linux.  TCP-IP has been brought up on all sorts of platforms.

And depending upon the Thing and what it is intended to do, it may not need a full TCP-IP implementation - just enough to communicate on a specific port using a specific protocol.  Will a Thing need to support HTTP or FTP, for example?  Unlikely.

A lot of discussion like this seems to assume that all of the Things will be full 32 bit processors that could run Linux, but I don't see that being true for a majority of the Things the IoT will encompass.  Intel has its own RTOS - VXWorks - acquired with Wind River, and it's hardly the only alternative for OSes on embedded devices.

jaybus0
User Rank
CEO
Re: IoT != Linux
jaybus0   10/13/2013 11:53:09 AM
NO RATINGS
No, it will not be FTP or HTTP. It will be MQTT, XMPP, etc. For ultra low power devices it will possibly be CoAP (Constrained Application Protocol), seeing that ARM has purchased Sensinode for just that purpose. However, they all work more or less like stripped down HTTP, meaning they are all using text-based messaging over TCP.

Yes, there are TCP/IP stacks for many devices. There are even stripped down IP stacks like NanoIP. Keep in mind that some of these can only work on local networks. But IoT implies Internet. Many of these devices will need IPv6 support, multicast support, encryption, etc. 

Also, if we are to connect Everything, then many Things will be operating on line power. I don't trust TCP/IP stacks that have not seen much use as an Internet-facing device, certainly not to save less than 2 W. There is a lot of room in IoT for Linux devices.

DMcCunney
User Rank
CEO
Re: IoT != Linux
DMcCunney   10/13/2013 12:58:03 PM
NO RATINGS
@Jaybus0: Yes, there are TCP/IP stacks for many devices. There are even stripped down IP stacks like NanoIP. Keep in mind that some of these can only work on local networks. But IoT implies Internet. Many of these devices will need IPv6 support, multicast support, encryption, etc.

Yes, some can only work on local networks.  So what?  I believe most Things in the IoT will be on local networks.

Looking around at the desk I'm sitting at, there is the netbook I'm posting from at the moment, a desktop multi-booting Windows and Linux, a notebook multi-booting Windows and Linux, two decommissioned rack mount servers, one running Windows and other running Solaris, and a PowerMac running OS/X.  They are all on my local network,  but my public face is my wireless router, connecting to the cable modem from my ISP. 

All of my devices have IP addresses supplied by my router and the router uses NAT to see things get to and from the correct local devices. There are half a dozen machines that might be active and communicating on my LAN via TCP-IP, but only one public IP address seen by the rest of the Internet.

There will certainly be IoT Things that will run Linux and require what you mention, but they will be the equivalent of my router: the interface between their LAN and the greater Internet.  The vast majority of Things will not be publicly visible, and I don't see a reason they would need to be.



jaybus0
User Rank
CEO
Re: IoT != Linux
jaybus0   10/14/2013 9:14:58 AM
NO RATINGS
DMcCunney... What you describe looking around your desk is a traditional topology. But people will expect to use wearables, automotive systems, etc. as they would a cell phone, anywhere and everywhere. So not just routers, but many Things will be operated outside of the more controlled local network, or at least that is the idea. Of course there will also be many Things that will and should be constrained to a local network as well, networked sensors, household appliances, industrial test and measurement equipment, etc. The point is, there will be a need for both, and I believe that there will be many, many devices assigned public IP addresses, not just routers. And so a Linux capable device makes sense because of the maturity of the network software.

DMcCunney
User Rank
CEO
Re: IoT != Linux
DMcCunney   10/14/2013 10:00:17 AM
NO RATINGS
@jaybus0: I think we're talking past each other.  I never suggested many Things on the IoT didn't have have a reason to be powerful enough to run Linux and be visible to the outside world.  Many will.

My simple contention is that most won't.  Being on the IoT just means they are assigned an IP address and can communicate by TCP-IP with other Things.  You don't have to be a 32 bit processor running Linux to do that.

Indeed, most Things on the IoT arguably shouldn't be visible outside of their local network.  A team at the University of Michigan has created an open source, Linux based scanner called Zmap, capable of scanning the entire IPv4 address space.  See https://zmap.io/ for details and downloads.  It's intended to be a security tool, and discover things which are visible and should not be.

Sure, your car's Infotainment center is a candidate for being on the public Internet.  The processor that controls your car's ignition timing isn't, and neither is most of the rest of what the car might contain.  The same holds true for for most other Things.

Radio
NEXT UPCOMING BROADCAST
EE Times Senior Technical Editor Martin Rowe will interview EMC engineer Kenneth Wyatt.
Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Flash Poll