SemiWiki – Page 787 – The Open Forum for Semiconductor Professionals

November 23, 2014

More Apple A9 Ridiculousness!

More Apple A9 Ridiculousness!
by Daniel Nenni on 11-23-2014 at 8:30 am
Categories: Foundries, Mobile

File this one under funny things journalists are paid to say. Last week the Korea Times reported that Apple had “designated” Samsung as the primary supplier of the next Apple SoC. In response, the Chinese Commercial Times reported that TSMC is to supply the Apple A9 chip despite competition from Samsung. Since SemiWiki readers already know the score on this let me just highlight the funny parts:

“Samsung Electronics agreed with Apple to produce application processors (APs) from next year for iPhones and iPads, sources said Monday. The agreement means Samsung will become a primary supplier of APs to Apple, pushing its chief Taiwanese rival TSMC back to second place. From 2016, the company will supply 80 percent of APs used in Apple devices, and TSMC the remainder.”

The Samsung and TSMC FinFET processes are not compatible so I do not see Apple or anybody else for that matter splitting a bleeding edge mobile chip amongst foundries. It will take a serious amount of experienced design effort and with the current time-to-market SoC pressures those resources are not treated lightly.

Also Read: Who is REALLY Using TSMC 16FF+?

“TSMC replaced Samsung in 2013, becoming the main manufacturer of Apple’s A8 processor, used in the iPhone 6 and the iPhone 6 Plus. Samsung only produced 30% of A8 processors, a market insider said.”

Again, Apple did not split the manufacturing of these chips. According to tear downs the Apple A8 (iPhone) and the A8x (iPad) are both TSMC 20nm. According to Samsung they do not offer a 20nm foundry process nor have I seen a Samsung 20nm SoC. In fact, I was told a while back that Samsung would skip the 20nm planar node to accelerate their 14nm development (which is 20nm FinFET).

“A US investment banker confirmed on Nov. 19 that TSMC is to manufacture a large portion of the A9 processors in 2015, although whether the process technology will be 20-nanometer or 16-nanometer is still unclear. Samsung will supply a smaller proportion of the processors, the paper reported.”

I wonder what investments this US banker has?

“The yield rate of TSMC’s 20-nanometer process technology has reached 80%, and its 16-nanometer FinFET process technology 90%. The two processes are expected to account for 1% of revenue in the first quarter of 2015 and 10% in the fourth quarter of 2015, said market analyst Randy Abrams from Credit Suisse Taiwan.”

I know Randy, I’m pretty sure this is a misquote. I will let you know after my next Taiwan trip. Unfortunately it has been cut and pasted around the internet already by those who need to believe it is true.

And finally, according to Barron’s:

Investors who have been put off by delays in production ramps for Intel’s latest chips should focus on the broader picture. Intel has a 3½-year lead over rivals like Taiwan Semiconductor Manufacturing, IBM, and Samsung Electronics in cutting-edge chip-making techniques, says Pitzer…

If you must give them a click:

http://www.koreatimes.co.kr/www/news/tech/2014/11/133_168259.html

http://www.wantchinatimes.com/news-subclass-cnt.aspx?id=20141121000059&cid=1206

http://online.barrons.com/articles/intel-has-30-upside-1416633838

Not Mobile, Automotive to See Max Semiconductor Growth!

Not Mobile, Automotive to See Max Semiconductor Growth!
by Pawan Fangaria on 11-22-2014 at 9:00 am
Categories: Foundries, Mobile

There is no denying that mobile market is almost matured, the growth in the semiconductor industry has to pick up somewhere else. Although it’s expected that worldwide cellphone subscription will exceed the world population in 2015 (already exceeded in many parts of Europe) and continue for some time (while CAGR in unique subscription will decline to 3% by 2018, see report), the actual rise in CAGR in revenue is going to be much higher in automotive semiconductor segment.

According to IC Insights forecast report, in 2013-2018 the automotive IC segment is going to see 10.8% CAGR, much higher than other segments including communications, industrial and consumer. While cars and other vehicles will see more and more infotainment, ADAS (Advanced Driver Assistance Systems) and safety systems (National Highway Traffic Safety Administration has mandated backup cameras as a must in all new vehicles), some of the communication systems such as IoT devices and vehicle-to-vehicle communications will also go into vehicles. The growth in automotive ICs has already picked up; in 2014 it is expected to grow by ~15% to $21.7B compared to just 1% in 2013.

What do we infer from here? If I look at the top3 automotive IC players in 2012 and 2013, they have remained in the same order – Renesas, Infineonand ST Micro. Interestingly, they are in 2014 top20 semiconductor revenue list as well, but there ST is above (at #10) Renesas (at #11 although with very minor difference in revenue compared to ST) and Infineon (at #13, improved from #14 in 2013). Let’s look at some other interesting stuff.

The top drivers in automotive segment are Analog ICs and MCUs other than growing presence of sensors and power management ICs. I see other automotive players such as Texas Instrumentsand NXPin top20 list putting higher emphasis in these automotive semiconductor areas. TI had largest 21% increase in automotive revenue in 2013. In 2014 top20 list, TI has improved its rank to #7. Also, looking at the fact that APAC region is forecast to be the largest market for automotive ICs (at ~20% CAGR), UMC is stepping up its manufacturing of automotive chips; already have plans to supply these chips for Japan’s automotive industry.

Does that mean we are going to see some changing equations over next couple of years? Among automotive players in 2014 top20 semiconductor companies (Renesas, Infineon, ST, TI, NXP), they have either improved their rank or maintained where they were in 2013. And among top3 automotive IC companies, they are retaining their order since 2012. This signifies the fact that due a longer life cycle of automotive products, they are bound to be there and further improve with accelerated growth in that sector.

By the way, wireless and consumer sector players such as Qualcomm, Inteland NVidia will also get benefited from car electronics and infotainment systems. Automotive memory IC market is also expected to double ($2B to $4.2B) by 2018.

Although the automotive segment will grow from a low base revenue compared to other segments, its high growth rate can add to already established semiconductor players in the top20 to renew their fortunes. Are we going to see any major change in rankings?

Intel 2014 Investor Meeting and 14nm Status

Intel 2014 Investor Meeting and 14nm Status
by Scotten Jones on 11-21-2014 at 6:30 pm
Categories: Foundries, Intel Foundry, TSMC

Intel’s investor meeting was held yesterday and for me the presentation that is most interesting is Bill Holt’s. The presentations are available on the Intel website: Intel Corporation – Presentations Material 2014. Here is the 2013 version of this presentation: Intel Corporation – Presentations Materials 2013. First off I want to vent a little, what is up with the European paper size? Does Intel have a secret plan to get everyone in the US to buy new printers?

On slides 3, 4 and 5, the 14nm yields are shown versus 22nm. The good news for Intel is the yields are finally looking pretty good; the bad news is it has taken a long time to get there. I find it interesting that TSMC is reportedly already getting good yields on their 16nm process suggesting their 16nm/14nm development has proceeded more smoothly than Intel’s. From what I have heard Samsung and Global Foundries continue to struggle with 14nm yields.

On slide 7, 14nm pitches of 42nm for STI, 70nm for gate (GP) and 52nm for M1 (M1P) are presented. This is in contrast to TSMC’s pitches of 48nm for STI, 90nm for GP and 64nm for M1P as reported at IEDM 2013. This gives a GP x M1P of 3,640nm[SUP]2[/SUP] for Intel and 5,760nm[SUP]2[/SUP] for TSMC. I have two observations on this:

[LIST=1]

This is comparing Intel’s 14nm to TSMC 16FF. At the 2014 IEDM on December 15, 2014 TSMC is scheduled to present what looks to be 16FF+. It will be interesting to see what if any pitch improvements they report for 16FF+ versus 16FF and how that compares to Intel. The TSMC 16FF GP and M1P are the same as 20SOC, at the 2014 TSMC technology symposium 16FF+ was reported to offer a 15% improvement over 20SOC so perhaps GP x M1P is something like 4,896. I should note here that I have had someone who should know what they are talking about tells me the 16FF+ does not improve density versus 16FF.

The BEOL pitches for Intel’s 14nm process have started to come out. My understanding is there are 8 layers of 52nm pitch metal produced with Self Aligned Double Patterning (SADP) followed by 80nm and 160nm pitch layers with air gaps and finally 3 layers of presumably large pitch metal. The use of SADP for the first 8 metal layers means they are 1D metal layers and the design rules are very restrictive. It seems unlikely to me that a foundry could get away with such restrictive rules and this is a key part of why Intel can produce smaller metal pitches than anyone else (more on the metal layers later).

Slide 8 shows a 0.54x scaling in SRAM size, an impressive achievement!

Slides 9 through 14 present fin scaling and show scaling to a smaller pitch while simultaneously increasing the fin height. This is another impressive achievement.

Slide 15 presents Intel’s leadership in introducing new process technologies to the industry. Once again these achievements are impressive and it illustrates how much Intel has helped to drive the industry forward over the last decade. The key question this slide doesn’t address is what is next and will Intel maintain a lead. TSMC, Samsung and Global Foundries are all ramping up their FinFET processes and have essentially “caught up” on that innovation. In my opinion the next innovation will be Germanium or Indium Gallium Arsenide fins and it will be interesting to see who get there first.

Slides 18 and 19 present the 14nm Interconnect. I have to say I am very surprised by the 13 layers of interconnect at 14nm (the number of metal layers isn’t listed here and is from other sources). Intel had 6 metal layers for 180nm and 130nm while transitioning from aluminum to copper metallization; at 90nm they had 7 metal layers, 8 metal layers at 65nm and then 9 metal layers at 45nm, 32nm and 22nm. My expectation at 14nm was 10 metal layers. What I think happened was the use of SADP to produce the 52nm critical metal pitches forced 1D metal and a lot of metal layers to accomplish the required interconnect. My “guess’ is:

M1 through M8 are alternating x and y direction metal layers all serving for short signal runs.
M9 and M10 reportedly have air gaps and presumably these are longer signal runs where the air gaps are need to lower the RC delay.
M11, M12 and M13 are presumably large pitch metal runs for power and ground.

Slide 20 is a new version of the “infamous” slide showing Intel’s density lead. In the past the x-axis has been node but has now been switched to time. Now instead of Intel lagging and then pulling ahead they consistently lead. The following is my own version of this slide comparing Intel and TSMC actual processes and then forecasting TSMC 16FF+ with a 15% shrink and 10nm with a 2.2 density improvement based on the TSMC technology symposium early guidance (these are updated projection since my “Who will lead at 10nm post”). For Intel I used my own trend projected 10nm numbers.

Intel Versus TSMC GP x M1P by year of technology introduction.

As can be seen from this plot, Intel consistently leads for density; the problem to me with this analysis is until recently Intel was exclusively using their processes for microprocessors (MPU) which have a much narrower set of performance requirements than processes for foundry use. Intel only had to focus on fast transistors while TSMC has to provide processes that meet a wide variety of different requirements. At 22nm Intel’s MPU and foundry processes have the same pitches for GP and M1P but will that hold at 14nm and if so how many customers will accept the restrictive design rules required for SADP metal layers?

Slides 22 and 23 show Moore’s law is alive and well at least at Intel. The cost per wafer goes up with each generation but the die shrinks more than make up for it. As we have entered the multi-patterning era wafer costs are rising faster than we have historically seen but at least at Intel the die shrinks are overcoming this.

Some observers believe that at the foundries the increase in wafer cost at 20nm due to multi-patterning has overwhelmed the die shrink and die costs have risen. I do not believe this but rather think the die cost reductions have slowed. At the 16nm/14nm node at foundries the wafer costs will again increase (although the use of 20nm backend pitches mitigates this to some extent) and the shrinks are minimal. At 16nm/14nm die cost reductions will be minimal at best. At 10nm I expect foundries to deliver competitive cost per die reductions as we get back to full shrinks, in fact TSMC has guided a 2.2x increase in density. Wafer costs from 16nm to 10nm at TSMC are not going to go up anywhere near 2.2x!

All in all Intel continues to deliver impressive technological progress and do it economically. Comparing Intel with TSMC (or any foundry) for device area is really not a valid comparison until Intel is a substantial foundry player and the processes being compared are both being used in the foundry space.

I am still going through all of the presentations but I also wanted to comment on Stacy Smith’s presentation slide 51 which shows Intel’s fab capacity and demand coming back into balance, which is a really big deal after the low levels of loading seen in 2012 and 2013.

November 21, 2014

ARMmbed? IoT dedicated ARM OS!

ARMmbed? IoT dedicated ARM OS!
by Eric Esteve on 11-21-2014 at 12:10 pm
Categories: Arm, IP

The IP vendor #1, leading the pack with revenues more than twice the closest competitor revenues, has to position on the new IoT market, especially because ARM’s main product line is processor IP family, and MCU or CPU is certainly at the earth of the SmarCoT: the “Smart” part. In fact, ARM’s customers have the freedom to develop any chip (as soon as they pay the license and royalties) addressing the Internet of Things. But ARM marketers have made a serious home work to define how they see the IoT market and define solutions around ARM Cortex M family to address this market.

It’s all about ecosystem, and ARM knows pretty well about the concept, we even can say that they have introduced it within the semiconductor industry! You need partners to build an ecosystem and ARM has defined three partner classes: Cloud (providing services), Partners (for development tools) and Silicon Partners who bring the technology. These three groups form the mbed Partner Ecosystem (mbed is in fact the Operating System developed by ARM to support IoT).

Interesting in the above scheme is the fact that you don’t see any IC or any CPU or MPU IP, even if you can easily guess that you will find it into the IoT devices on the right side… but not only. If you dig in the new web site fully dedicated to ARMmbed, you quickly identify the Silicon, for example in the Smart Home solution:

The multiple home appliances and control developed around ARM Cortex M running mbed OS are the smart things (SmarCoT) connected to Internet via a single gateway (integrating Cortex A CPU running Linux). In fact mbed[SUP]™[/SUP] OS enables low-power wireless devices with IPv4 or IPv6, integrates with home/mobile gateways and electric meters to provide Internet routing. One of the new standards for home automation is Thread – its IPv6 based standard that brings IP to the edge, it consumes minimal power and allows mesh networking among home appliances. It runs over low power radio (802.15.4) MAC and PHY.

If you are interested by Smart City, the same mbed OS would be used to support large scale and secure IoT street:

Analogous to a Web Server that accepts connections from mobile phones or web browsers, a Device Server handles the connections from Internet of Things (IoT) devices (or “Little Data”). This Device Server is a key enabler for cloud service providers, operators and enterprises to access the IoT growth market with production deployments, bringing end node devices in to the world of web services. The Device Server can be used to connect the Little Data world of IoT to the Big Data applications.

ARM has already built a specific policy for mbed OS partners who :

contribute technically to the platform,
use it within their own solutions for developers,
work with ARM on marketing,

and finally benefit from being part of the ecosystem.

Technical benefits include early access rights to platform source that enable porting code and integrating solutions before it goes public, and support from the team creating the platform itself. Partners can also get development licenses for the latest versions of Device Server. Marketing benefits include being featured on the mbed Developer Website, social media channels, involvement with press releases, guest blogs and videos, and participation at ARM® mbed events.

ARM is claiming a developer community being already over 70,000 strong, and if you look at the partner’s logos, you can see that almost all the big names of the MPU space, the Atmel, Freescale, NXP, Renesas, ST are mbed OS partners. Complemented with Big Data service providers like Alcatel-Lucent, IBM or Ericsson to name a few, this initiative could support the creation of a new industry, required to develop IoT. ARM is very good at building an ecosystem and such ecosystem is helping facilitate the building of deeper relationships between new and non-traditional customers and partners.

If you are interested in discussing becoming a partner, please contact partnership@mbed.org

Eric Esteve from IPNEST –

November 21, 2014August 22, 2024

Global Foundries and IBM, More Details

Global Foundries and IBM, More Details
by Paul McLellan on 11-21-2014 at 7:00 am
Categories: Foundries, GlobalFoundries

Now that the dust has started to settle on the GlobalFoundries acquisition of IBM’s semiconductor business it is possible to look into another level of detail about what GlobalFoundries will be acquiring in the way of technology and IP. Of course, the deal hasn’t formally closed yet so this won’t all happen instantly. Estimates are that the deal may take as long as a year to close, and the rules are quite strict on how closely people can work together on an unclosed deal so it is going to be a challenge to manage the transition.

Firstly, there is additional capability in the specialized foundry business, meaning anything other than regular digital SoC type manufacturing. GlobalFoundries already has a good capability in this area, primarily running in the old Chartered fabs in Singapore, some of which have been upgraded to 300mm. But with IBM the gain:

PA/FEM (power amplifiers, front-end modules) and transceivers
High performance RF and AMS with SiGe
High voltage and power management
A specialty foundry business to address growth opportunities in mobile RF, which is expected to grow fast (see graph above)

This all runs in the old IBM 200mm fab in Essex Junction, Vermont, which is about 3 hours drive north of GlobalFoundries’ fab8 in Malta NY. The capacity is around 40K wafer starts per month.

They are also taking over IBM’s commercial ASIC business which is focused on network and computing infrastructure, in particular wired communications, wireless communications infrastructure (base stations) and storage. This runs in the IBM 300mm fab in East Fishkill, New York (a couple of hours south of fab8). The ASIC business is expected to grow with a CAGR of 6.5% (see graph above). East Fishkill has a capacity of around 14K wafer starts per month.

Fab8 has a capacity of 60,000 300mm wafers per month (or roughly 120,000 200mm equivalents).

There is major investment in technology in the north east with the college of nanoscale science and engineering (CSNE) in the area too (in Albany) too. But clearly GlobalFoundries now has a world class technology development team.

So the bottom line is that the acquisition:

Reinforces GlobalFoundries’ long-term commitment to manufacturing and technology leadership
Provides R&D expertise to give a path to 10nm and beyond
Expands segment growth in RF and ASIC
Becomes IBM’s sole source foundry partner
Gives them strategic relationships with top OEM industry suppliers

GlobalFoundries have a presentation deck covering the acquisition here.

HLS Tools Coming into Limelight!

HLS Tools Coming into Limelight!
by Pawan Fangaria on 11-20-2014 at 10:00 pm
Categories: EDA

For about a decade I am looking forward to seeing more of system level design and verification including high level synthesis (HLS), virtual prototyping, and system modeling etc. to come in the main stream of SoC design. Although the progress has been slow, I see it accelerating as more and more tools address the typical pain points in designing and verifying at the system level. Naturally, if you can’t confidently verify a design done in certain way, you wouldn’t design it in that way. So, the message is clear – close the gap between what a designer wants to do and what the tools provide; closer the gap, faster the adoption.

I was particularly happy seeing the sixth annual HLS survey reportconducted by Calyptoamong SoC, IC and FPGA design engineers and managers. I couldn’t imagine only 4% of engineers among 750 who responded to the survey do not use HLS. That means majority of the respondents were active users of HLS and they knew about the actual problems they face while using HLS. What if these problems are solved to delight them? Let’s see what these pain points are –

It’s clear, proving C and RTL equivalence is a major challenge; RTL structure depends on the constraints put in the synthesis tool and hence can significantly vary in its sequential behavior depending upon those constraints. So, the C-to-RTL formal verification tools must take into account the design intent. The other major challenge in tracking the mismatches between C and RTL models and lack of test coverage for the generated RTL signifies that there is acute need to generate equivalent RTL testbench also along with the RTL model.

Which C source code errors were hardest to identify during HLS? As usual, detection and removal of dead code in any software is a major pain point. The point important to HLS is the fact that such errors (e.g. uninitialized memory read, ABR etc.) in C source code can show their effect differently in different contexts, thus affecting consistency in results and re-usability of code. These errors must be removed early in the design process to keep the code quality high and re-usable which can be synthesized consistently.

The question on power reduction was interesting; we are already seeing major power reduction at RTL through various RTL level tools in the market. The power reduction at system level and then at C++/SystemC/HLS is a step well perceived for best way to start the design at system level. HLS tools can optimize micro-architecture to minimize power and also utilize RTL power optimization tools to produce power optimized RTL in one go.

What are the hardware types being designed using HLS? Clearly major concentration is towards wireless, video, imaging, graphics etc. However it is interesting to see the other 25%, that means the advantages of using HLS in more designs is being recognized by the design community.

Look at the HLS reportat Calypto website to find more details. I like this process of Calypto; gathering inputs from design community and then incorporating those into their tools, that’s a great way to accelerate closing the gaps between design and tool-to-design. So what’s Calypto doing to address the key points in their HLS tool Catapultand Sequential Logical Equivalence Checking (SLEC) tool? We need to watch out on that. Stay tuned to hear more on specific HLS improvements from Calypto to provide a superior experience to designers.

Using HAPS-DX for system-level deep trace debug

Using HAPS-DX for system-level deep trace debug
by Don Dingee on 11-20-2014 at 4:00 pm
Categories: EDA, Synopsys

Debugging an ASIC design in an FPGA-based prototyping system can be a lot like disciplining a puppy. If you happen to be there at the exact moment the transgression occurs and understand what led up to that moment, administering an effective correction might be possible.

Catching RTL in the act requires the right tools. Faults in a complex design are rarely obvious, more likely rooted in a sequence of events sourced from multiple IP blocks partitioned across FPGAs and clock domains. For example, debugging a USB protocol fault calls for capturing a deep trace buffer on the port itself, correlated with streams from other test points in IP blocks and interconnects.

Most FPGA-based prototyping systems are not equipped for deep trace debug operations. FPGAs do not contain enough internal memory to capture very long traces. The Hawthorne effect enters the equation; configuring FPGA resources for debug operations consumes FPGA resources and can affect the outcome of the observation or other operations in unpredictable ways.

Of course, test points never seem to be in the right places at the right time, especially as the root cause of a problem traces farther back into multiple blocks. Having to rebuild an entire RTL design partitioned across several FPGAs just to change the test point configuration for debugging a problem is time consuming and risky.

Most design philosophies use a cascade-up approach: debug the details at the IP block level, then abstract functional blocks as black boxes at system integration. This not only greatly reduces the test point loading, but also reduces system test time and fosters IP reuse – if it all goes as planned.

When Synopsys designed the HAPS-70 Series of FPGA-based prototyping systems, they hit system-level partitioning and interconnect head on, and addressed much of the system-level debugging capability. It became clear that IP block testing needed a similar approach, and to scale down and enable more teams, Synopsys introduced the HAPS-DX. Developers then could design and prototype IP blocks on a smaller, more cost effective platform, and pass artifacts directly up to the HAPS-70 platform for SoC integration.

A big feature of the HAPS-DX is the detailed, deep trace debug capability. HAPS-DX has an 8GB DDR3 SDRAM SODIMM and a suite of logic analysis tools. It can grab 128 signals at 140 MHz, for a full five seconds of data. Synopsys Verdi and Siloti visualization tools can be used to view the results.

A new, short video from Troy Scott and Peter Zhang of Synopsys shows how the HAPS-70 can be used with the debug features of the HAPS-DX and ProtoCompiler non-invasively. Effectively, the HAPS-DX serves as storage and control for debug operations, connected to watchpoints on the HAPS-70 via high-speed serial links.

This approach leaves the HapsTrak 3 connectors wide open for daughter cards and FPGA interconnect – the partitioning on the HAPS-70 is unaffected. The HAPS-DX captures data, and shares it with a host workstation for display over the high bandwidth UMRBus.

With the capture mechanism in place, ProtoCompiler is used to set triggers. Its RTL Instrumentor allows navigating the RTL design hierarchy visually. A few clicks can set watchpoints or triggers by signal name. A run-time utility then takes over sampling, and can export data in an FSDB format for display and analysis. Results are fully correlated and can be annotated back to RTL source.

This video, “Synopsys ProtoCompiler for RTL Debug with HAPS Systems”, appears with other helpful FPGA-based prototyping videos from the Synopsys marketing and engineering teams.

November 20, 2014

Don’t be an “ID-IoT”

Don’t be an “ID-IoT”
by Bill Boldt on 11-20-2014 at 8:00 am
Categories: Foundries

Let’s just come out and say it: Not using the most robust security to protect your digital ID, passwords, secret keys and other important items is a really, really bad idea. That is particularly true with the coming explosion of the Internet of Things (IoT).

The identity (i.e. “ID”) of an IoT node must be authenticated and trusted if the IoT is ever to become widely adopted. Simply stated, the IoT without authenticated ID is just not smart. This is what we mean when we say don’t be an ID-IoT.

It seems that every day new and increasingly dangerous viruses are infecting digital systems. Viruses — such as Heartbleed, Shellshock, Poodle, and Bad USB — have put innocent people at risk in 2014 and beyond.

Because the digital protection mechanisms themselves have become targets, and with the IoT multiplying the number of targets the targets must be hardened.

It is not hard to see that trust in the data communicated via an ubiquitous (and imvasive) IoT will be necessary for it to be widely adopted. Without trust, the IoT will fail to launch. It’s as simple as that. In fact, the recognized inventor of the Internet, Vint Cerf, completely agrees saying that the Internet of Things requires strong authentication. In other words, no security? No IoT for you!

A bracing reason that data security is so important is that money now is simply electronic data, so everyone and every company are at risk of financial losses stemming directly from data breaches. Data banks are where the money is now kept,so data is what criminals attack. While breaches are, in fact, being publicized, there has not been much open talk about their leading to significant corporate financial liability. That liability, however, is real and growing. CEOs should not be the least bit surprised when they start to be challenged by significant shareholder and class action lawsuits stemming from security breaches.

Although inadvertent, companies are exposing identities and sensitive financial information of millions of customers, and unfortunately, may not be taking all the necessary measures to ensure the security and safety of their products, data, and systems. Both exposure of personal data and risk of product cloning can translate to financial damages. Damages translate to legal action.

The logic of tort and securities lawyers is that if proven methods to secure against hacking and cloning already exist, then it is the fiduciary duty of the leaders of corporations (i.e. the C-suite occupants) to embrace such protection mechanisms (like hardware-based key storage), and more importantly, not doing so could possibly be argued as being negligent. Agree or not, that line of argumentation is viable, logical, and likely.

A few CEOs have already started to equip their systems and products with strong hardware-based security devices… but they are doing it quietly and not telling their competitors.

Software, Hardware, and Hackers
Why is it that hackers are able to penetrate systems and steal passwords, digital IDs, intellectual property, financial data, and other secrets? It’s because until now, only software has been used to protect software from hackers. Hackers love software. It is where they live.

The problem is that rogue software can see into system memory, so it is not a great place to store important things such as passwords, digital IDs, security keys, and other valuable things. The bottom line is that all software is vulnerable because software has bugs despite the best efforts of developers to eliminate them. So, what about storing important things in hardware?

Hardware is better, but standard integrated circuits can be physically probed to read what is on the circuit. Also, power analysis can quickly extract secrets from hardware. Fortunately, there is something that can be done.

Several generations of hardware key storage devices have already been deployed to protect keys with physical barriers and cryptographic countermeasures that ward off even the most aggressive attacks. Once keys are securely locked away in protected hardware, attackers cannot see them and they cannot attack what they cannot see. Secure hardware key storage devices employ both cryptographic algorithms and a tamper-hardened hardware boundary to keep attackers from getting at the cryptographic keys and other sensitive data.

The basic idea behind such protection is that cryptographic security depends on how securely the cryptographic keys are stored. But, of course it is of no use if the keys are simply locked away. There needs to be a mechanism to use the keys without exposing them — that is the other part of the CryptoAuthentication equation, namely crypto engines that run cryptographic processes and algorithms. A simple way to access the secret key without exposing it is by using challenges (usually random numbers), secret keys, and cryptographic algorithms to create unique and irreversible signatures that provide security without anyone being able to see the protected secret key.

Crypto engines make running complex mathematical functions easy while at the same time keeping secret keys secret inside robust, protected hardware. The hardware key storage + crypto engine combination is the formula to keeping secrets, while being easy-to-use, available, ultra-secure, tiny, and inexpensive.

http://www.youtube.com/watch?v=zZsOjyo26tg

Bill Boldt, Sr. Marketing Manager, Crypto Products Atmel Corporation

November 20, 2014July 18, 2025

Is Your Washing Machine a Connected Thing?

Is Your Washing Machine a Connected Thing?
by Eric Esteve on 11-20-2014 at 4:00 am
Categories: IP, Synopsys

In fact the question could be about your watch, thermostat or other smart appliance, as soon as the “thing” relies on one or more sensors to function. In this case, we are close to call this thing an IoT (or SmarCoT), we just need to add WiFi, BTLE, ZigBee connectivity. Sensors are ubiquitous, integrated into smartphone, automotive, thermostat, home appliances and many more. If you want to define IoT, you should start to list the many things that use sensors. When a “thing” uses sensor(s), a CPU or DSP or combination of both is not far away, to process the sensor raw data. It becomes a “smart thing”. Connecting a smart thing look like a good idea? Just do it and you will have built a SmarCoT (Smart Connected Thing) or IoT!

The next question is which processor to select, especially when the thing will be battery powered, and the electronic system has to be smart in term of power consumption. We are not talking about a device you need to charge every day or even week, rather several weeks. We know for quite a long time that integration is always a good path for low power: moving from external I/Os to internal connections greatly help to save power. Thus, using a CPU IP subsystem that could be integrated into a larger chip sounds good.

Synopsys DesignWare Sensor and Control IP Subsystem is optimized to process the extensive amount of data in sensor fusion applications. The subsystem includes a rich library of off-the-shelf DSP functions supporting filtering, correlation, matrix/vector, decimation/interpolation and complex math operations. Designers can implement these sensor-specific DSP functions in hardware using a combination of native DSP instructions within the EM5D or EM7D processor and tightly coupled hardware accelerators to boost performance efficiency and reduce power consumption by up to 85 percent compared to discrete solutions.

Synopsys has built a real subsystem as you can see on the above picture, integrating ARC CPU (EM4, EM5D, EM6 or EM7D) tailored to the computation needs. A computation hungry application may require using Instruction and Data memory cache, but you can decide to integrate only the right quantity of embedded SRAM. In both cases, the solution will exhibit minimized power consumption, as there is no power hungry internal bus like AMBA AHB or the like. This architecture sounds like a main differentiator when compared with the competition, even when dealing with low performance CPU like ARM Cortex M, for example.

But low power architecture doesn’t mean low capability: this IP subsystem is expected to interface with sensors, thus it offers a full set of tightly coupled peripheral interfaces (see above), including both digital and analog interfaces, as well as a Pulse Width Modulator (PWM) interface. The lower cost is a sensor, the higher DSP manipulations will be needed, and Synopsys proposes various DSP accelerators, either hard wired (EM4 or EM6), either with native instructions for the EM5D and EM7D versions. Even a Floating Point Unit can be added as a licensable option if needed.

Claiming that your solution is low power is one thing, demonstrating this claim in a real case is better!

Synopsys has benchmarked ARC sensor IP subsystem supporting the same 9-D sensor fusion application, in term of cycle counts as well as energy consumption with two competitor solutions. Synopsys IP subsystem is integrated into an ASIC built on 40LP when the X and Y solution are based on standard parts (from well-known microcontroller manufacturers). The cycle count reduction, by a factor of 5 (with competitor X) or 4 with Y, is impressive. Such a 80% reduction in cycle counts, plus the smarter bus free architecture explains why Synopsys solution exhibits more than 85% savings in energy consumption!

In fact, this ARC IP subsystem is like sensors, it’s ubiquitous. It’s not possible to describe in a short paper all the potential configurations ranging from pure RISC CPU, to 25% RISC/75%DSP, passing through any possible implementation. You will get a very good overview, and also some in-depth information by listening this webinar:

Webinar: Simplify Sensor and Actuator Functionality for your IoT Solution

From Eric Esteve from IPNEST

November 19, 2014

Qualcomm Enters Server CPU Market

Qualcomm Enters Server CPU Market
by Paul McLellan on 11-19-2014 at 6:00 pm
Categories: Foundries

Fresh from the leaked memo that Intel is merging its mobile business into its PC client group, Qualcomm is going the other way and has confirmed that it is entering the ARM server CPU market, an announcement made at its analyst day earlier today.

This is a major trend that less than a month ago I reported from the Linley microprocessor conference. You can go and read the whole thing but the money quote is:ARM has a tiny share. But as I reported last year, that is all set to change. The 64-bit ARM v8 instruction set has opened up new markets and almost all embedded vendors are moving their future investment to ARM. However, the time to design-in, ship and ramp equipment in a conservative market means that the crossover will take 5-10 years, but:

AppliedMicro shipping X-Gene and sampling X-Gene2
Cavium plans to sample Thunder in Q4 (their current products are MIPS based)
Feescale sampling LS1 and plans to sample LS2 this quarter
LSI/Avago/Intel shipping ARM version of Axxia (although presumably this will be short lived now Intel owns that business)
AMD sampling Hierofalcon for embedded market
Broadcom shippping StrataGX and developing Vulcan CPU

Now we can add Qualcomm to this list. Since Qualcomm is pretty much doing the most advanced SoCs on TSMC’s most advanced processes, and given that it has its own ARM processor already, this should put it in a good position. As Qualcomm’s CEO Steve Mollenkopf argued, their ability to quickly adopt next-gen manufacturing processes will give it an edge.

It still remains to be seen if “ARM servers” are really a market. It is supposedly driven by demand from internet giants but until Facebook or Google announce that they are building datacenters at scale using ARM-based CPUs the jury is still out. It is also clear that the companies building ARM-based server CPUs cannot all be successful. I would expect only one or two of these companies to achieve true scale. But there is clearly a value proposition. For some tasks, maximum single thread performance is the most important thing and Intel is untouchable there. But for many tasks, such as servicing hundreds of thousands of simultaneous users on the web, raw performance of a thread is probably less important than aggregate performance of the datacenter against the important metrics of power, cost and physical size. Good performance at 10% of the cost, 10% of the power and 10% of the physical volume sounds pretty compelling. The total cost of ownership of a datacenter includes a high electricity bill to deliver power to the servers and another high electricity bill to power the air-conditioning to get the heat out. Reducing that may be even more important than the cost of the server chips.

But Facebook is at least talking the talk. Jay Parikh, Facebook’s vice president of infrastructure engineering said:Qualcomm-based ARM servers gives us the ability to rethink the way that we have built certain parts of our infrastructure.

So Intel is trying to get into Qualcomm’s primary business and now Qualcomm is trying to get into Intel’s.

Wall Street Journal article is here