SemiWiki – Page 677 – The Open Forum for Semiconductor Professionals

January 22, 2016

Qualcomm Shows Their First 5G Demo At Industry Analyst Day

Qualcomm Shows Their First 5G Demo At Industry Analyst Day
by Patrick Moorhead on 01-22-2016 at 7:00 am
Categories: 5G, Mobile

Complete 5G solutions aren’t something that you’ll be seeing in phones or networks any time soon regardless of what you may see in the headlines or companies are claiming. In fact, the first official release of the 5G standard isn’t likely to be finalized until 2018, at which point true 5G networks will very likely not roll out until 2020. However, due to the increased demand for added capacity and throughput, certain parties are getting impatient and want to push up the implementation of specific 5G technologies to as soon as 2018.

What we are more likely to see is that specific 5G technologies will get adopted sooner than others as the spectrum and technology allow. Part of the introduction of 5G includes the use of higher frequency signals that can range anywhere from 3.5 GHz to 60+ GHz, much higher than current 4G LTE networks. As a result, the companies in the wireless industry are moving up their time tables and preparing for 5G sooner due to the demand for increased capacity and faster throughput. Qualcomm recently held an industry analyst day to explain and demonstrate the company’s vision for 5G. Representing Moor Insights & Strategy were Anshel Sag who covers mobile and wireless and Mike Krell who covers Industrial IoT.

Part of Qualcomm’s 5G vision included how the company sees 5G evolving beyond “just another wireless technology” for smartphones and tablets, expanding into every facet of life. This included presentations on how 5G incorporates a more flexible network, making devices on the network more than just endpoints as well as their 5G unified air interface (UAI). Qualcomm’s 5G UAI combines a multitude of features including massive MIMO, reliable high capacity and high frequency spectrum and much more. To make 5G more real for the analysts in attendance, Qualcomm took analysts deep inside of their research and development building, also known as the Qualcomm Research Center (QRC). Deep down inside of the basement of the building analysts were given a peek at some of Qualcomm’s own 5G technologies in a working demonstration.

To deliver the multi-gigabit speeds that users should experience with 5G, the use of higher frequencies is needed, as mentioned earlier. For Qualcomm’s demonstration, they chose to use 28 GHz, which is right in the middle between Qualcomm’s currently supported 4G LTE bands (below 3GHz) and their 802.11ad Wi-Fi operating at 60 GHz. The industry has coined these multi-gigabit high frequency wireless technologies as mmWave, to represent the measurement of the wave lengths in millimeters due to their high frequency and short length.

Because of the nature of these waves, Qualcomm utilizes extremely small antennas in a broad array in conjunction with directional beamforming to deliver a robust wireless signal regardless of the objects in the way. This is important because higher frequency wireless signals tend to be easily obstructed or blocked when something dense gets between them and their target device. For example, Wi-Fi operating at 60 GHz also known as 802.11ad, is best applied for in-room applications and that’s generally used with 32 tiny little antennas. The technology is designed to constantly adapt and adjust to the best possible beam based on the current conditions, combining all of the antennas on the base station transmitting to the antennas on the client device. The purpose of this demo was not to show us how fast 5G can be, but rather how well Qualcomm’s 5G implementation can handle less-than-perfect conditions, which is what most users experience on a daily basis. Many of those issues come from the actual deployment of the technology and the challenges that 5G brings to the table like non-line-of-sight connectivity and the consequences of how users use their devices on 5G signal.

For this demo, Qualcomm had set up a base station and a client device in a hall way and had people walk between the two as well as move the client device around to show how their 5G technology adapted. To accomplish this, Qualcomm used a base station with a 128 antenna elements with 16 controllable RF arrays. Commercial base stations could have significantly more antenna elements in the real world depending on the area that they are trying to cover and the size that they need to be. The client device receiving the signal had four selectable antenna sub-arrays, each with their own 4 controllable RF channels, meaning that each had four antennas as well. Having multiple antennas in multiple arrays allows for the client device to switch between the best antenna array that delivers the best signal, dynamically, while also beamforming, to also improve signal and catch the best channel and signal.

In their tests, they were able to achieve speeds of 400 Mbps pretty consistently using one antenna out of the possible 16, which is pretty good when you consider that 4G LTE right now can do 100Mbps. The system is designed to find the right beam and deliver it to the right antenna in order to deliver the best possible service utilizing one beam at a time. The demonstration was using only 16 QAM modulation, which means that there is still room for improvement in terms of throughput when they are able to achieve higher order modulation like 64-QAM or higher. Qualcomm’s engineers stated that they have simulated tests of this technology in urban environments and had line of sight range of 350 meters and non-line of sight coverage of 150 meters in Manhattan.

Qualcomm’s 5G demo at their industry analyst day shows that the company is well into development in 5G technologies, and that they are already working on solving many of the problems that come with using wireless frequencies above 3 GHz. Qualcomm’s acquisition of Wilocity mid last year, the first creators of 60 GHz Wi-Fi technology, may have put the company in a unique position ahead of the competition as they have dealt with many of the issues with mmWave technologies and are already in their second generation of 802.11ad Wi-Fi. Expertise doesn’t come overnight, and there is still going to be a lot more work to be done in the 5G space in order for it to become a commercialized technology, standardization included.

Qualcomm 3D mmWave Signal Visualization of 4 Antenna Array (Credit: Anshel Sag, Moor Insights & Strategy)

More from Moor Insights and Strategy

January 21, 2016

Microsoft Cloud-based Connected Car Service Insights from Patents

Microsoft Cloud-based Connected Car Service Insights from Patents
by Alex G. Lee on 01-21-2016 at 4:00 pm
Categories: Automotive
1 Comment

Microsoft patent application US20150262486 and patents US9092984 and US9218740 illustrate a cloud computing service to assist drivers with respect to improving driver safety. The cloud-based driver assistive system can warn drivers upon impending collisions.

The cloud-based driver assistive system includes many grid cloud servers. Each grid cloud server is associated with a grid of grids, in which each grid corresponds to a geographic area. For example, each grid cloud server divides space into square grids that have approximately even load. To do this efficiently, the cloud-based driver assistive system identifies geographic regions of varying sizes and quickly determines which server is responsible for any location. To this end, each cloud service uses the standard military grid reference system (MGRS).The MGRS enables the cloud-based driver assistive system uniquely identifies varying sized regions in a hierarchical manner.

Each grid cloud server receives information corresponding to trajectories of the vehicles that are known to the cloud server via the wireless communications that are sent from mobile devices associated with the vehicles. The mobile devices can be implemented in drivers’ smartphones or the devices built into vehicles (e.g., vehicle navigation or entertainment system). The cloud-based driver assistive system periodically collects from a GPS device and other sensors on the mobile device of a vehicle. The information includes data regarding location, speed, course, acceleration, and yaw. For example, in a normal-to-heavy traffic situation, the cloud-based driver assistive system uploads its location information every 100 ms; in lighter traffic situations, the cloud-based driver assistive system uploads its location information less frequently, e.g., every 200 ms.

Each grid cloud server determines from the trajectory-related information whether vehicles that are known to the server to be in or approaching its associated grid are at risk of collision. If so, the grid cloud server warns drivers by transmitting the alert to the vehicles that is at risk of collision. The risk of the collision can be whether a vehicle is within a threshold distance of another vehicle and/or whether the vehicle is in a lane departure state.

Using mobile devices and relatively inexpensive sensors and wireless connections to the cloud service, the cloud-based driver assistive system can be implemented inexpensively for enriching the driving experience without needing new roadside infrastructure for vehicle-to-infrastructure (V2I) communications and embedding the Dedicated Short-Range Communications (DSRC) device to every vehicle for inter-vehicle (V2V) communications.

How Makers are changing the world—and why I’m so excited about it

How Makers are changing the world—and why I’m so excited about it
by Sander Arts on 01-21-2016 at 12:00 pm
Categories: Foundries

I’ve spent my entire career in the tech space, being exposed to some of the world’s biggest and most innovative companies. But these days, the thing that excites me a most is how Makers are using technology to make the world a better place.

Consider this: The recent Hackaday prize challenged Makers to build something that matters in the world. All of the prize-winning projects—and in fact, 80 percent of the finalist designs—were powered by Atmel-based Arduino boards. Examples include ALS patient Patrick Joyce and his 2015 winning Hackaday team who created an eye-controlled wheelchair system that offers life-changing mobility and independence for people without the use of their hands. Then there’s the team of graduate students who expanded the open source concept to bionics, giving amputees access to affordable, customizable, 3D-printed prosthetic hands. And the vineyard owner who took on the California drought with a sensor-driven water conservation system that saved 430,000 gallons of water in its first year.

It’s clear that now anyone can change the world using technology, and that presents tremendously exciting opportunities.

We help our customers make meaningful contributions with technologies that have literally turned product design into child’s play. This is part of an industry evolution that Atmel helped drive by making investments into integrated hardware, reference applications and software libraries, and high-quality, production-ready development tools. An example that’s familiar to many Makers is Arduino, which is powered by an Atmel microcontroller and is a launchpad for many Maker projects. Just search for ‘Arduino’ on Kickstarter or Indiegogo and you’ll find hundreds of projects. Some of the most-funded campaigns—from 3D printers and drones to household humanoid robots and smart home solutions—feature Atmel technology.

But as important as easy-to-use development platforms are, we believe that silicon vendors need to do more than just help Makers prototype. At Atmel, we recognized the need not only to make design easier, but also to make the transition from prototype to production easier. The Arduino environment is intuitive and easy to use for prototyping, but it has limitations that make it unsuitable for taking a project all the way to production. To solve that, Atmel provides free software development tools that let Makers import an Arduino project directly into our Studio debugging environment, which natively supports Arduino libraries. And we offer a full suite of microcontrollers at varying cost and performance levels, as well as components for connectivity, security, and touch interfaces, to take prototypes to final products. That kind of ecosystem compatibility just isn’t available anywhere else.

The next challenge for Makers is to bridge the chasm from makerspace to marketplace, and we’re there to help as well.

While Arduino simplifies design, crowdfunding sites such as Kickstarter and Indiegogo and outlets such as Hackaday and Instructables make it easier to bring those concepts directly to the investors who will fund their development and to the consumers who will pay for the finished product. But as Makerspace becomes more crowded, it’s becoming more challenging for individual Makers to get attention and differentiate their products from the slew of innovation on these sites.

That’s why we support Maker Faires around the world, and why we bring tech tours for training and supply chain assistance to local Makers. We also support Makers using our extensive social networking influence to highlight their projects in the marketplace. That kind of support is available nowhere else.

Atmel is ranked as the number one social semiconductor company by Publitek, with a social media influence that is the highest in the industry. The Atmel blog has millions of views and shares—more than all other 39 semiconductor companies combined (Publitek research, 2015)—and our Facebook, LinkedIn, Google+, and YouTube pages add millions more impressions. We have 55,000+ Twitter followers today, and that number is growing by ~25 percent per quarter. These impressive numbers make a significant difference to our customers and their ability to reach their prospective markets—as you can read in their own words here.

It’s this sort of validation that makes me so excited. The ultimate power is with the Makers who are changing the world. And really, this is what technology has always been about. While Makers see a way they can make the world a better place, we have the amazing opportunity to provide technologies, connections, and a full range of support that lets us become a champion for people who are solving world problems. We say that we are ‘enabling unlimited possibilities,’ and we truly do that. Next week, at Emtech Asia, I will speak on this topic. I am very excited to represent this company and the Makers that truly change the world.

This week, this story also hit the media. Have a look if you’re interested: http://www.newelectronics.co.uk/electronics-blogs/from-makerspace-to-marketplace-unlimited-possibilities-to-change-the-world/113289/

January 21, 2016

Japan..silent but strong players of semiconductor industry

Japan..silent but strong players of semiconductor industry
by kunalpghosh on 01-21-2016 at 7:00 am
Categories: Foundries

Japanese stood to be the world leaders during 1980-1990 regime in semiconductor manufacturing[SUP] [2][/SUP]. During my research, I found that Japanese semiconductor firms are very strong leaders in process which gave them a competitive advantage over others. Situation is bit different today, as we have fabless firms taking the leap, it’s always good to know how things started.

Let me begin with a small example (DRAM) to understand the strong base and deep roots of Japan in semiconductor industry in 1980-90 regime.

Concept:
Dynamic RAM (DRAM) is a memory architecture which comprises of a transistor and a capacitor that stores 1-bit of data. Due to its simple structure, a high density can be easily achieved which makes it cheaper and slower compared to Static RAM (that uses 6 transistors to store a bit).

Though it looks simple, but it’s highly process driven (and hence a perfect vehicle to learn about next gen process technology). The learning was also applied on other types of chips like DSP’s, microcontrollers, etc. The reason is the capacitor itself, which if leaks, tends to fade out the information. This needs periodic refresh process (and hence the name ‘Dynamic RAM’).

To protect capacitors from leaking, the transistors used for DRAM cells should be ‘extremely low leakage’ transistors which can be attained using substrate bias.

Next, the transistors threshold should be high in order to have lower leakage (at cost of lower switching time). And (again), attaining high threshold would need an increase in dopant concentration or a bulk bias as is quite evident from below threshold voltage equation:

Threshold Voltage Equation:
Vt = Vto + gamma(square_root(-2phiF + Vsb) – square_root(-2phiF))
Where
Vto = Threshold voltage at Vsb = 0, and is a function of manufacturing process
gamma = body effect coefficient, expresses the impact of changes in body bias Vsb (Unit is V[SUP]0.5[/SUP])
phiF = Fermi Potential (dependent on doping concentration)

Japanese DRAM market:
Japanese firms heavily invested in number of engineers to design their 1K and 16K DRAM (reports of 50 engineers for 1K[SUP] [1][/SUP]and 100 engineers for 16K[SUP] [1][/SUP]), which led to careful attention for fabrication process issues. For eg. sharp vertical walls created while etching, was a concern for lower node technologies as it resulted in inefficient etching of corners for material deposited in later stages. While leading Japanese engineers observed this short-coming and suggested a robust process of having sloped walls rather than sharp vertical walls.

This resulted in higher yields for Japanese producers (up to 68% by 1986[SUP][3][/SUP])

Now this shift in DRAM market very well reflected to overall semiconductor industry. It’s evident from below chart[SUP] [4][/SUP], that by 1990, 6 Japanese firms out of top 10 accounted for 38% of semiconductor market share with net of $20.7B out of total semiconductor market of $54.3B.

From above table, we can observe the no. of players moved from 6 to 1. This was the era when other top industries feared of market shift and focused on other segments (like microprocessors, mobile semiconductors, etc.) and became market leaders.

However, Japan still ranks #1 for installed fab capacity, #2 in terms of largest semiconductor material market. More than 50% of semiconductor materials supplied by Japan is being consumed globally and over 30% of semiconductor fabrication equipment are being purchased globally[SUP] [5].[/SUP]

Notes:
1) “The Decline of the U.S. DRAM Industry: Manufacturing” accessed at https://www.princeton.edu/~ota/disk2/1990/9007/900711.PDF
2) “Semiconductor sales leaders by year” accessed at https://en.wikipedia.org/wiki/Semiconductor_sales_leaders_by_year#Ranking_for_year_1987
3) Peter D. Nunan, Sematech, personal communications, May 11, June 23, Aug. 4, and Oct. 10, 1989.]
4) “Why Did Japan’s Semiconductor Industry fall?” accessed at http://marketrealist.com/2015/09/semiconductor-industry-japan-fall/ )
5) “Seven Facts about Japan Semiconductor Manufacturing Supply Chain” accessed at http://www.semi.org/en/node/52146

January 20, 2016

IoT Markets: let’s get real about the numbers

IoT Markets: let’s get real about the numbers
by John Moor on 01-20-2016 at 4:00 pm
Categories: IoT, Security

I am not sure about you but whenever I see those big market forecasts for IoT (and I’ve seen a lot)… my brain takes a short cut to “ok, I get it, it’s big”. And I believe it will be. But is “it’s big” that helpful? Or, to put it another way, does it hurt?

Robin Duke-Woolley of Beecham Researchthinks it does and has recently been on a mission to try and bring some sanity back to the numbers. He says, “let’s get real about the numbers… $trillions of new dollars is ridiculous – it’s a habit to exaggerate the numbers to get the headlines… it is not realistic… so let’s be rational here”.

“It’s very large, but not monstrous”
Why is he saying this? Is he jockeying for position? Maybe, but perhaps more importantly he feels it distracts us from doing the things we need to do to develop the market(s). Yes he is interested in the growth and proliferation of IoT solutions; the platforms, the standards, the devices – yet he’s also worried that we’ll remain distracted and overlook those elements necessary for growth. Especially when it comes to appropriate security – he believes it will undermine the uptake in the applications.

Having spent the last 15 years or so monitoring the M2M space, Robin is concerned how some security-solution-vendors have simply replaced “M2M” with “IoT”. And IoT is a whole lot more complex than M2M when it comes to security. In the M2M world, systems tend to operate within more clearly defined silos and therefore tend to be better understood. In the IoT world, data can jump silos, traverse interfaces, move across networks of variable provenance and get mashed with other data sources coming from a completely different part of the system.

Add to the threat landscape the variations in economic model, variations in threat levels and security requirements and it’s easy to see why the new world of IoT (in spaces such as cities, healthcare, energy and transport) is tangibly different from anything we’ve encountered before. I’ll add something else here too – these systems will likely be expected to operate for a decade or more too, so we have an extra time dimension – and in environments which vary greatly too.

All these elements create a business risk profile, and with risk comes the potential that markets will slow unless the benefits are significantly greater. So Robin sees the need to develop the markets from a more realistic opportunity, he feels that security should be seen as an enabler of markets and not a cost of deployment. It appears we need to change the way security is accounted for perhaps over the lifetime of a service rather than a unit cost of a physical solution.

Robin spoke at the IoT Security Foundation conference at the Royal Society recently and made a fuller case for his conclusions than I have here. Fortunately you can see his talk on Youtube – if you’re interested in IoT markets I would recommend you prep a coffee and invest 30 minutes to hear what he has to say – especially as it goes against the herd.

January 20, 2016June 14, 2019

When Good Standards Get Lost – the UVM Register Model

When Good Standards Get Lost – the UVM Register Model
by Bernard Murphy on 01-20-2016 at 12:00 pm
Categories: EDA, Siemens EDA

Some time ago I wrote a DeepChip viewpoint on DVCON 2014 in which I praised a Mentor paper “Of Camels and Committees”. The authors argued that while the UVM standards committee had a done a great job in the early releases, the 1.2 release was overloaded with nice-to-have features with questionable value for a standard, particularly since this came at a cost of 12,000 new lines of presumably less than battle-hardened code. They argued that standards should stick to the minimum refinements required to enable users and competitors to progress efficiently, and no more. It’s difficult to argue with that position. Even if you are an open-source fan, a standards committee is the wrong place to evolve a code-base of this size. Either changes move too slowly to provide real-time fixes for live use, or move too quickly to support a stable standard.

Rich Edelman and Bhushan Safi of Mentor are pushing the case further, this time arguing for simplifications in the UVM register model; this subset of the standard consumes 22,000 lines of code and a quarter of the User Guide. A natural rebuttal would be that the code size merely reflects the importance of register verification. Software developers have to trust that the hardware can be controlled and observed as described in the register documentation. While it’s true that this area of verification is very important, it’s less obvious that its importance necessarily implies a need for such a large body of code and features in a standard.

Registers can be complex beasts. There are the simple cases – just address, read, write and reset – but all sorts of complications can be added: read-only, write once, clear-on-read, different reset values, different fields within a register which differ in these characteristics, shadow registers, and many more variants. Trying to abstract all of this in a complete but still easy-to-use way is a Herculean (maybe impossible) task. Another rebuttal might be to ask how else it could be done. An object-oriented (OO) approach is surely the natural way to abstract and hide complexity? But as I remember, standards should prescribe interfaces, not implementation, which is normally left to market innovation / competition. Something seems amiss.

Standards philosophy aside, what’s really important is how this is working out in deployment. Mentor experience with a significant percentage of users is that the latest rev of the Register package has missed the easy-to-use objective by a fairly wide margin, at least among its target user-base. Rich tells me a majority of their users don’t understand the class structure or behavior; they do OK with the basic registers but with more complex cases they struggle (and generally fail) to find a way to model them correctly. The outcome is that they use the package to do the basic address and read/write tests, but write their own tests for more complex behavior, circumventing the intended use of UVM registers and field classes, which makes their testbenches run big and slow. And that makes them unhappy, especially if an emulator is idling for long periods, waiting for the testbench to catch up. On the other end of the scale, some verification teams enthusiastically adopt the OO style but lack the required skills and are spending a lot more of their verification cycles debugging the testbench than the design.

Rich and Bhushan make a case for a simpler approach (the genie may be out of the bottle now, but they can at least make their case). They argue for a simpler register model based on structs rather than (in their view) overkilling the need with classes. Sure classes are more flexible and extensible and inheritable and all that good stuff, but unless you are comfortable in OO approaches and skilled in UVM register classes (which it seems most verification engineers are not), all that capability becomes a steep learning curve rather than a simplification. The Mentor suggestion is a simpler (and less intimidating) programming model, easily extensible to handle those complex quirky registers. And it’s more time- and space-efficient since a packed struct is almost always going to be smaller than an equivalent class (especially for bitfields).

Rich admits their approach is not ideal either. It puts more of the programming burden on the verification team, but that seems to be happening anyway with workarounds in place of existing UVM Register capabilities. Perhaps the ideal approach would be C-based, perhaps it requires a move to some more standardized approach to register management. I’m sure users will know it when they see it; it’s not apparent that they see it in the UVM Register model as it currently stands. Perhaps that’s their problem – they have to adapt or or find a different job. But I’m not sure that’s what they or their managers expected from the standard. Or perhaps, in good standards as in good design, less is usually more.

The Mentor paper on “Getting Beyond UVM Registers” is HERE.

Chips on the road to deep learning

Chips on the road to deep learning
by Don Dingee on 01-20-2016 at 7:00 am
Categories: Automotive, Ceva, IP

CES has been morphing into an automotive show for several years now. Chipmakers were pitching control solutions, infotainment solutions, then connectivity solutions. Phone makers pitched device integration. Automotive electronics suppliers pitched MEMS sensors and cameras. Now, with a lot of pieces in place, the story in 2016 has turned to a system-level solution.

And it isn’t self-driving vehicles. Every time someone says autonomous, an angel gets its wings – but for regulatory and legal and cultural reasons, large-scale deployment of autonomous vehicles is still generations away. Researchers will research, and that’s good, but the real money for auto companies and chip suppliers is in ADAS: advanced driver assistance systems.

The embedded chip companies – Freescale/NXP, Renesas, TI – were out in front for a while. These firms were all deep in automotive control with safety-qualified parts, so the leap to infotainment and connectivity wasn’t huge. Intel tried to tell an infotainment story, with so-so results. NVIDIA snagged headlines with its Tegra SoCs in a Tesla console win, and made headway in luxury display segments. Mobileye combined MIPS cores with embedded vision processing for dedicated EyeQ ADAS chips, coming from nowhere to 10 million cars. Qualcomm now wants in with Snapdragon 820 Automotive and Snapdragon 602A solutions tuned for cars.

Suddenly, there is a battle royale developing around who can create the algorithms for ADAS integration, from the vehicle to the cloud.

This isn’t exactly a new idea. Several years ago in a restaurant at the Venetian during CES, I met the folks from INRIX who were using GPS, mobile apps, and cloud algorithms to create real-time traffic mapping. They took technology deployed in commercial fleets and massaged it to consumer smartphone tastes, but still face difficulty monetizing beyond commercial space.

What if that capability can be integrated in cars, and not just luxury models but more mainstream offerings? Now this gets very interesting for a lot of chipmakers. One analyst, Wunderlich, writes that high-end ADAS content per car may eventually be an order of magnitude above a typical mobile device – for example, perhaps 8 to 10 cameras per car with associated vision processing.

But for that kind of broad adoption, ADAS has to fully integrate with the automotive control systems. That mandates a move from garden-variety mobile SoCs that burp at extremely inconvenient times to more robust, automotive qualified parts.

In many ways, this surge in automotive chip interest resembles the COTS push in defense technology years ago. Defense electronics suffered as more and more semiconductor suppliers bailed out of the mil-spec business, unable to sustain product development and manufacturing costs for a miniscule market dwarfed by consumer electronics. The response was the Perry Memo, allowing more commercial grade technology in select use cases.

Automotive under-hood applications are renowned for being even nastier than many mil-spec applications, with harsh environmental requirements and relatively low volumes that again sent many suppliers for the exit. Fortunately, foundries and processes caught up, so chip fabrication is not as big a barrier as it used to be. Safety-critical design is now a big hurdle.

So are the algorithms, and honestly that comes first – more on the safety-critical angle shortly.

NVIDIA has fired up their DRIVE PX 2, a massive 250W liquid cooled supercomputer in a box featuring the latest Tegra technology with 64-bit ‘Denver’ ARMv8 cores and Pascal GPU cores. NVIDIA thinks GPU computing is a fit for a deep neural net (DNN) cloud leveraging a common architecture running Cuda. Deep learning will be crucial to object recognition and motion tracking combined with mapping elements and other context from the cloud.

Mobileye says that makes for a nice demonstration, but to get to production algorithms takes a lot more doing. They are aiming for a proprietary mapping technology running on EyeQ chips called Road Experience Management (REM) which chews road information and localization at 10Kb/Km, compared to Google’s current HD technology with Gb/Km kinds of numbers. In theory, carmakers using EyeQ can flip on new vehicle software and build a “road book”.

CEVA is telling carmakers to hold their horses. Just as in mobile, where CEVA used more power-efficient DSP core IP to enable chipmakers to differentiate 4G LTE solutions, CEVA is creating IP for ADAS solutions. They have coupled their CEVA-XM4 vision engine with the open source Caffe open-source deep learning framework, creating a licensable solution for chipmakers called the CEVA Deep Neural Network.

Why is CEVA so confident to step right in the middle of this heavyweight fight? CEVA says they perform deep learning 3x faster, with 30x less power, and 15x less bandwidth compared to the NVIDIA approach. Some of the gain is efficient silicon in the XM4, but much of it is a floating-point to fixed-point conversion step that cuts bandwidth without sacrificing accuracy.

Compared to the Mobileye REM approach, CEVA says they are more open for customized algorithms in end-to-end solutions with tuned hardware and software. On top of that, the CEVA-XM4 is now certified to ISO 26262. That makes the XM4 currently the only licensable vision processor IP supporting ASIL B safety integrity level.

There is also mounting competition. We already mentioned Qualcomm. Samsung has created its own automotive division, and both Huawei and LG are also after automakers. There is the stealth-mode Apple automotive team doing who knows what. And there’s Faraday Future, a new firm with Tesla-like aspirations. This could put more chipmakers, or even automakers looking to self-design chips, in the market for licensable IP.

I’ve said several times that the secret of Qualcomm’s success has been a tight coupling between algorithm and silicon, with the examples of the Viterbi decoder and CDMA chipsets. After this initial phase of basic ADAS chips, we’re likely to see that the long-term winner in ADAS creates this same style of algorithmic coupling, adding cloud-based technology for an end-to-end solution optimized on ultra-low power silicon at the edge. (Qualcomm is also moving into deep learning with Zeroth.)

Can CEVA create an IP-based ADAS ecosystem quickly to compete with the headstart for Mobileye and NVIDIA and a new thrust from Qualcomm? Is CEVA’s bet on ISO 26262 certification well placed? For another perspective with a bit more detail on the Mobileye and NVIDIA pressers, Junko Yoshida had some excellent CES 2016 ADAS coverage in EETimes. The team behind Caffe also has a website.

Coventor ASML IMEC: The last half nanometer

Coventor ASML IMEC: The last half nanometer
by Scotten Jones on 01-19-2016 at 4:00 pm
Categories: Coventor, EDA

On Tuesday evening December 8[SUP]th[/SUP] at IEDM, Coventor held a panel discussion entitled the “The last half nanometer”. Coventor is a leading provider of simulation software used to design processes. This is my third year attending the Coventor panel discussion at IEDM and they are always excellent with very strong panels and discussion.

Continue reading “Coventor ASML IMEC: The last half nanometer”

January 19, 2016

How to Secure the Internet of Things (IoT)?

How to Secure the Internet of Things (IoT)?
by Ahmed Banafa on 01-19-2016 at 12:00 pm
Categories: IoT, Security

The Internet of Things (IoT) as a concept is fascinating and exciting, but the key to gaining real business value from it, is effective communication between all elements of the architecture so you can deploy applications faster, process and analyze data at lightning speeds, and make decisions as soon as you can.

IoT architecture can be represented by four systems:

[LIST=1]

Things: These are defined as uniquely identifiable nodes, primarily sensors that communicate without human interaction using IP connectivity.

Gateways: These act as intermediaries between things and the cloud to provide the needed Internet connectivity, security and manageability.

Network infrastructure: This is comprised of routers, aggregators, gateways, repeaters and other devices that control data flow.

Cloud infrastructure: Cloud infrastructure contains large pools of virtualized servers and storage that are networked together.

Next-generation trends namely, Social Networks, Big Data, Cloud Computing, and Mobility, have made many things possible that weren’t just a few years ago. Add to that, the convergence of global trends and events that are fueling today’s technological advances and enabling innovation including:

Efficiency and cost-reduction initiatives in key vertical market
Government incentives encouraging investment in these new technology
Lower manufacturing costs for smart devices
Reduced connectivity costs
More-efficient wired and wireless communications
Expanded and affordable mobile networks

Internet of Things (IoT) is one big winner in this entire ecosystem. IoT is creating new opportunities and providing a competitive advantage for businesses in current and new markets. It touches everything—not just the data, but how, when, where and why you collect it. The technologies that have created the Internet of Things aren’t changing the internet only, but rather change the things connected to the internet—the devices and gateways on the edge of the network that are now able to request a service or start an action without human intervention at many levels.

Because the generation and analysis of data is so essential to the IoT, consideration must be given to protecting data throughout its life cycle. Managing information at this level is complex because data will flow across many administrative boundaries with different policies and intents. Generally, data is processed or stored on edge devices that have highly limited capabilities and are vulnerable to sophisticated attacks.

Given the various technological and physical components that truly make up an IoT ecosystem, it is good to consider the IoT as a system-of-systems. The architecting of these systems that provide business value to organizations will often be a complex undertaking, as enterprise architects work to design integrated solutions that include edge devices, applications, transports, protocols, and analytics capabilities that make up a fully functioning IoT system. This complexity introduces challenges to keeping the IoT secure, and ensuring that a particular instance of the IoT cannot be used as a jumping off point to attack other enterprise information technology (IT) systems.

International Data Corporation (IDC) estimates that 90% of organizations that implement the IoT will suffer an IoT-based breach of back-end IT systems by the year 2017.

Challenges to Secure IoT Deployments
Regardless of the role your business has within the Internet of Things ecosystem— device manufacturer, solution provider, cloud provider, systems integrator, or service provider—you need to know how to get the greatest benefit from this new technology that offers such highly diverse and rapidly changing opportunities.

Handling the enormous volume of existing and projected data is daunting. Managing the inevitable complexities of connecting to a seemingly unlimited list of devices is complicated. And the goal of turning the deluge of data into valuable actions seems impossible because of the many challenges. The existing security technologies will play a role in mitigating IoT risks but they are not enough. The goal is to get data securely to the right place, at the right time, in the right format, it’s easier said than done for many reasons, Cloud Security Alliance (CSA) in a recent report listed some of the challenges:

Many IoT Systems are poorly designed and implemented, using diverse protocols and technologies that create complex configurations.
Lack of mature IoT technologies and business processes
Limited guidance for life cycle maintenance and management of IoT devices
The IoT introduces unique physical security concerns
IoT privacy concerns are complex and not always readily evident.
Limited best practices available for IoT developers
There is a lack of standards for authentication and authorization of IoT edge devices
There are no best practices for IoT-based incident response activities.
Audit and Logging standards are not defined for IoT components
Restricted interfaces available IoT devices to interact with security devices and applications.
No focus yet on identifying methods for achieving situational awareness of the security posture of an organization’s IoT assets.
Security standards, for platform configurations, involving virtualized IoT platforms supporting multi-tenancy is immature.
Customer demands and requirements change constantly.
New uses for devices—as well as new devices—sprout and grow at breakneck speeds.
Inventing and reintegrating must-have features and capabilities are expensive and take time and resources.
The uses for Internet of Things technology are expanding and changing—often in uncharted waters.
Developing the embedded software that provides Internet of Things value can be difficult and expensive.

Some real examples of threats and attack vectors that malicious actors could take advantage of are:

Control systems, vehicles, and even the human body can be accessed and manipulated causing injury or worse.
Health care providers can improperly diagnose and treat patients.
Intruders can gain physical access to homes or commercial businesses
Loss of vehicle control.
Safety-critical information such as warnings of a broken gas line can go unnoticed
Critical infrastructure damage.
Malicious parties can steal identities and money.
Unanticipated leakage of personal or sensitive information.
Unauthorized tracking of people’s locations, behaviors and activities..
Manipulation of financial transactions.
Vandalism, theft or destruction of IoT assets.
Ability to gain unauthorized access to IoT devices.
Ability to impersonate IoT devices.

Dealing with the challenges and threats
Gartner predicted at its security and risk management summit in Mumbai, India this year, that more than 20% of businesses will have deployed security solutions for protecting their IoT devices and services by 2017, IoT devices and services will expand the surface area for cyber-attacks on businesses, by turning physical objects that used to be offline into online assets communicating with enterprise networks. Businesses will have to respond by broadening the scope of their security strategy to include these new online devices.

Businesses will have to tailor security to each IoT deployment according to the unique capabilities of the devices involved and the risks associated with the networks connected to those devices. BI Intelligence expects spending on solutions to secure IoT devices and systems to increase five fold over the next four years.

The Optimum Platform
Developing solutions for the Internet of Things requires unprecedented collaboration, coordination, and connectivity for each piece in the system, and throughout the system as a whole. All devices must work together and be integrated with all other devices, and all devices must communicate and interact seamlessly with connected systems and infrastructures. It’s possible, but it can be expensive, time consuming, and difficult.

The optimum platform for IoT can:

Acquire and manage data to create a standards-based, scalable, and secure platform.
Integrate and secure data to reduce cost and complexity while protecting your investment.
Analyze data and act by extracting business value from data, and then acting on it.

Last word…
Security needs to be built in as the foundation of IoT systems, with rigorous validity checks, authentication, data verification, and all the data needs to be encrypted. At the application level, software development organizations need to be better at writing code that is stable, resilient and trustworthy, with better code development standards, training, threat analysis and testing. As systems interact with each other, it’s essential to have an agreed interoperability standard, which safe and valid. Without a solid bottom-top structure we will create more threats with every device added to the IoT. What we need is a secure and safe IoT with privacy protected, tough trade off but not impossible.

January 19, 2016

How to Build a Deadlock-Free Multi-cores SoC?

How to Build a Deadlock-Free Multi-cores SoC?
by Eric Esteve on 01-19-2016 at 7:00 am
Categories: IP, NetSpeed Systems

We will precisely explain the meaning of deadlock in a modern, complex multi-core SoC. First, let’s take a look at the crash of the Air France 296, when a brand new Airbus A320 crashed during a demo flight on June 26, 1988. This Airbus 320, the first plane being completely automated, thanks to the FADEC flight system, was running a demo flight. The pilot decided to mimic a landing just above the airport, without effectively landing. The goal was to demonstrate how brilliant the plane was. Unfortunately, such a maneuver was not recognized by the FADEC and the flight system, being blocked, decided to reset itself. The problem was that in 1988, the reset/restart took 7 seconds, and during the reset time, the pilot was trying to put the gas on and climb (as he would have done with no problem on a plane from the previous generation). The result is printed on the picture below… At that time (1988) there was no SoC but just a 68020 processor, but what has happened is the equivalent to deadlock in modern SoC: the system becomes blocked, and there is no other way to escape this state except going to reset.

Let’s jumpstart to 2016, electronic systems are now based on System-on-Chip integrating multiples –if not many- processor cores (CPU/GPU/DSP) and several dozen IP. As soon as you architect such a complex multi-cores SoC, you have to use and design an interconnect IP in order to exchange data between the multiple agents. It can be a bus-based or an internally defined interconnect IP, but the trend is to move to a commercial Network-on-Chip (NoC) IP, like NetSpeed SoC interconnect IP generated by NocStudio.

Now a simplified case study where two agents are sharing the same interconnects, as pictured below. We can intuitively understand that deadlock are occurring when one agent (agent0) need to read a data to complete a task, which data is a response generated by the other agent (agent1) expecting to read the result of the operation done by agent0. In this case the situation is creating a dependency illustrated by the red arrows. The dependency is that read requests can complete only when they can issue a read response in the other direction. A deadlock occurs if buffers in both directions are full of read requests and there is no way to send read responses. Chicken and egg is a pertinent illustration of dependency… When deadlock occurs, the system is stuck and there is no other way to escape this state but to reset/restart it, assuming that architects have envisaged this type of event and integrated adequate test structure. If you remember the beginning of this blog, resetting a system can be dramatic, even if, in most of electronic systems, the risk is to lose data, not life.

Before using NetSpeed’s NocStudio, SoC architects using home-made interconnects had to plan SoC validation campaign to detect potential deadlocks. The problem with such strategy is the awfully long lead time associated with the simulation. You have to run functional simulations and it may take weeks if not months of computer intensive validation to discover the first deadlock, even if it would take a few hours or days when the SoC is integrated into the real system. The entire process (identify deadlocks, design fix, run again simulation) could take as long as six months… which seems unacceptable in respect with the Time-To-Market (TTM) request.

NetSpeed’s NocStudio is used at the architecture definition level, when the architect specify the communication protocol inside the SoC. NetSpeed IP achieves full deadlock detection and resolution by partitioning complex protocol transactions into the simpler sub-flows from one endpoint to the next. The deadlock in Figure 2 can be avoided by having separate resources for the read and read-response packets, by adding a virtual channel to the network to create an alternative read-response path. Machine learning algorithms are used to automatically learn the correct processing order in which sub-flows are processed and mapped to virtual networks.

To detect protocol deadlocks, properties of all system components in terms of how they produce and consume network packets and these packets are inter-related to each other are required. Designers use a flexible formal language to capture the deadlock relevant properties of various system components. There are two ways dependencies can be specified in NocStudio. They can be implied within a traffic description, or they can be specified explicitly. Subsequently this information is also used to construct the network level deadlock-free NoC. That’s why NetSpeed uses the “Correct by Construction” slogan to describe the NoC generated by NocStudio.

We know since decades that state machines can lock and put a chip in trouble, forcing to reset a complete electronic system. Since architects are defining always more complexes and heterogeneous SoC, the probability to introduce dependencies dramatically increase, with the direct consequence to put the SoC in deadlock. Even if deadlock can be detected by running simulations and fixed by design, this iterative process is way too long to comply with the TTM requirements. NetSpeed propose a solution: design an interconnect IP “correct by construction”, using NocStudio to generate Orion, a deadlock-free NoC.

From Eric Esteve from IPNEST