SemiWiki – Page 794 – The Open Forum for Semiconductor Professionals

October 28, 2014

ECDH Key Exchange is Practical Magic

ECDH Key Exchange is Practical Magic
by Bill Boldt on 10-28-2014 at 7:00 pm
Categories: Foundries

What if you and I want to exchange encrypted messages? It seems like something that will increasingly be desired given all the NSA/Snowden revelations and all the other snooping shenanigans. The joke going around is that the motto of the NSA is really “Yes We Scan,” which sort of sums it up.

Encryption is essentially scrambling a message so only the intended reader can see it after they unscramble it. By definition, scrambling and unscrambling are inverse (i.e. reversible) processes. Doing and undoing mathematical operations in a secret way that outside parties cannot understand or see is the basis of encryption/decryption.

Julius Caesar used encryption to communicate privately. The act of shifting the alphabet by a specific number of places is still called the Caesar cipher. Note that the number of places is kept secret and acts as the key. Before Caesar, the Spartans used a rod of a certain thickness that was wrapped with leather and written upon with the spaces not part of the message being filled with decoy letters so only someone with the right diameter rod could read the message. This was called a skytale. The rod thickness acts as the key.

A modern-day encryption key is a number that is used by an encryption algorithm, such as AES (Advanced Encryption Standard) and others, to encode a message so no one other than the intended reader can see it. Only the intended parties are supposed to have the secret key. The interaction between a key and the algorithm is of fundamental importance in cryptography of all types. That interaction is where the magic happens. An algorithm is simply the formula that tells the processor the exact, step-by-step mathematical functions to perform and the order of those functions. The algorithm is where the magical mathematical spells are kept, but those are not kept secret in modern practice. The key is used with the algorithm to create secrecy.

If a secret key is kept secret, the message processed with that algorithm will be secret from unintended parties. This is called Kerckhoffs’ principle and is worth remembering since it is the heart of modern cryptography. What it says is that you need both the mathematical magic and secret keys for strong cryptography.

Key Agreement

There needs to be a way to exchange the key during the session where the encrypted message is to be sent.

ECDH key agreement, is a way to send the secret key without either of the sides actually having to meet each other. EC stands for elliptic curve that have the property that given two points on the curve (P and Q) there is a third point, P+Q, on the curve that displays the properties of commutivity, associativity, identity, and inverses when applying elliptic curve point multiplication. Point-multiplication is the operation of successively adding a point along an elliptic curve to itself repeatedly. Just for fun the shape of such an elliptic curve is shown in the diagram.

The thing that makes this all work is that EC point-multiplication is doable, but the inverse operation is not doable.Cryptographers call this a one-way or trap door function. (Trap doors go only one way, see?) In regular math, with simple algebra if you know the values of A and A times B you can find the value of B very easily. With Elliptic curve point-multiply if you know A and A point-multiplied by B you cannot figure out what B is. That is the magic.

Now for some Math:

To best explain key agreement with ECDH, let’s say that everyone agrees in advance on a number called G. Now we will do some point-multiply math. Let’s call the sender’s private key PrivKeySend. (Note that each party can be a sender or receiver, but for this purpose we will name one the sender and the other the receiver just to be different from using the typical Alice and Bob nomenclature used by most crpyto books.)

Each private key has a mathematically related and unique public key that is calculated using the elliptic curve equation. Uniqueness is another reason why elliptic curves are used.

If we point-multiply the number G by PrivKeySend we get PubKeySend. Let’s do the same thing for the receiver who has a different private key called PrivKeyReceive and point-multiply that private key by the same numberG to get the receiver’s public key called PubKeyReceive. The sender and receiver can then exchange their public keys with each other on any network since the public keys do not need to be kept secret. Even an unsecured email is fine.

Now, the sender and receiver can make computations using their respective private keys (which they are securely hiding and will never share) and the public key from the other side. Here is where the commutative law of point-multiply will work its magic.

The sender point-multiplies the public key from the other side by his or her stored private key. This is equates to:

PubKeyReceive point-multiplied by PrivKeySend which = G point-multiplied by PrivKeyReceivepoint-multiplied by PrivKeySend

The receiver does the same thing using his or her private key and the public key just received. This equates to:

PubKeySend point-multiplied by PrivKeyReceive = G point-multiplied by PrivKeySend point-multiplied by PrivKeyReceive.

Because point-multiply is commutative these equations have the same value!

And, the rabbit comes out of the hat: The sender and receiver now have the exact same value, which can now be used as the new encryption key for AES, in their possession.No one besides them can get it because they would need to have one of the private keys and they cannot get them. This calculated value can now be used by the AES algorithm to encrypt and decrypt messages. Pretty cool, isn’t it?

Below is a wonderful video explaining the modular mathematics and discrete logarithm problem that creates the one-way, trapdoor function used in Diffie-Hellman key exhange. (Oh yeah, the “DH” in ECDH stands for Diffie-Hellman who were two of the inventors of this process.)

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

October 28, 2014December 27, 2023

G.fast on the copper quick road for broadband

G.fast on the copper quick road for broadband
by Don Dingee on 10-28-2014 at 3:00 pm
Categories: Ceva, IP

After a four year gestation period typical of global communications standards, G.fast has reached the point where chipset makers can implement parts against stable specifications. Formal approval of the physical layer spec, G.9701, is expected by the end of 2014. G.9700, dealing with power spectral density issues, was approved earlier this year.

What does G.fast do? Conceptually, it is the evolution of DSL, delivering broadband over copper. It clears the way for a theoretical aggregate bandwidth of as much as 1Gbps, on standard loops of telephone-grade twisted pair wire already in place to most homes and businesses.

Like its predecessors, such as the current VDSL2, G.fast begs the question of FTTx – fiber to the cabinet (FTTC), distribution point (FTTdp), premises (FTTP), node (FTTN), or other entity close enough to the subscriber to complete a short run in existing copper. This is in contrast to fiber to the home (FTTH), which requires similar points of presence but also ripping up yards, driveways, junction boxes, garage walls, and other pieces of a dwelling to provide service. For the last 200m, G.fast can be far cheaper than FTTH, and provide substantial bandwidth.

Faster signals bring with them quality and interference challenges. G.fast is relatively short range. Compared to VDSL2 which can handle several thousand meters with some degradation, G.fast handles at most 250m, and really only performs at shorter ranges. Fortunately, most lines are shorter – BT says 80% of copper lines in the UK are less than 66m. To gain performance, G.fast ups the frequency, operating in a 106 MHz profile with a future of 212 MHz, overlapping FM bands.

With concerns in both power spectral density shaping and far-end crosstalk reduction, DSP comes into play with vectoring algorithms. In the recently announced DP3000 DPU chipset and CP1000 CPE chipset, Sckipio makes heavy use of the CEVA-XC DSP core for G.fast vectoring.

VDSL2 introduced vectoring, and G.fast takes it to a new level of effectiveness. With a wider frequency range, G.fast vectoring engines require advanced algorithms and more calculations. To keep complexity realistic, G.fast limits bit loading to 12 bits per frequency carrier, compared to 15 in VDSL2. The gains in crosstalk reduction using G.fast vectoring are massive.

Among equipment providers, Alcatel-Lucent and Huawei are both pushing G.fast. As with any advanced standard, the driving factor is integrated chipsets to provide performance and reduce costs for volume rollouts. Sckipio has the lead here with G.fast vectoring built in to their solution, with Broadcom still working on multi-chip solutions.

Will G.fast be broadly adopted? The telcos are pitted against DOCSIS 3.1 and cable operators, working a hybrid fiber coax (HFC) architecture. Some say with the need to roll fiber to the last 200m, G.fast may be simply a stop-gap to FTTH. Others say that last 200m is a 20 year project to cover an entire country, and G.fast speeds without tearing up copper are worth it.

It may be longer in the US, lagging behind in broadband with large distances to cover and lack of competition in most markets. By any measure, Akamai or the UN Broadband Commission, US broadband penetration and speed generally sucks. (The UN conclusion that WiMAX would be most cost effective is rather hilarious – in the words of Dr. McCoy: “It’s dead, Jim.”)

Alternatives complicate the picture. Broadband in the US is two-thirds cable. Google Fiber is fast but very selective with build-on-demand instead of metro-wide rollouts – effectively, you have to move to the “fiberhood” to take advantage of it. VDSL2 may represent “good enough” performance with the ability to span longer distances, especially in rural contexts.

It will likely be at least another year of trials before we see if G.fast gets wide scale traction. It seems well suited for dense urban markets in Europe and Asia even if North America is slow to adopt it for other reasons. Improved speed over VDSL2 and the appeal of consumer self-installation and quicker deployment compared to FTTH should spur uptake.

October 28, 2014June 14, 2019

Imec and Coventor Partner Up

Imec and Coventor Partner Up
by Paul McLellan on 10-28-2014 at 7:00 am
Categories: Coventor, EDA

Today imec and Coventor announced a joint development project for 10nm and 7nm process development. Imec, which is in Leuven Belgium, is a partner with pretty much all the semiconductor companies that are planning work at these advanced nodes. It mostly does pre-competitive research and development. This type of research is very expensive for any one semiconductor company to carry out so it makes sense to share the investment across the entire industry. It will be interesting to see whether the GlobalFoundries acquisition of IBM’s semiconductor business changes the landscape since historically IBM has done a lot of research themselves, and those researchers now work for GF. Imec is a big operation with a staff of over 2000 people, including 670 industrial residents and guest researchers.

To adopt the 7nm node, the industry needs to select the optimal layout, as well as optimize process step performance and control methodology. Using Coventor’s SEMulator3D platform, engineers from imec and Coventor are working together to reduce silicon learning cycles and development costs by down selecting the options for development of next-generation manufacturing technologies. The SEMulator3D platform is an integrated set of modeling tools with enhanced visibility, accuracy and performance that enables engineers to interactively model and simulate a wide range of manufacturing effects in software before committing to expensive test chips.

At imec, process and integration experts have connected imec’s own optical lithography simulations with Coventor’s SEMulator3D virtual fabrication platform to explore FinFET scaling to the 7nm node and to compare the process window marginalities in several dense SRAM designs using Spacer Assisted Quadruple Patterning and either multiple immersion or EUV patterning cut/keep solutions. Moreover, a Spacer-Assisted Quad Patterning scheme for 7nm dense interconnect was devised using SEMulator3D, and process window marginalities for an immersion based multiple block patterning solution were analyzed.

Additional collaboration will focus on the predictive modeling of Directed Self-Assembly for advanced patterning. This is one of the great hopes “lithography in a bottle” for creating patterns at these very advanced nodes without requiring uneconomic numbers of process steps and assuming that EUV doesn’t come on line in time for 7nm (if it ever does).

Obviously at one level this provides imec the capability to do virtual fabrication using SEMulator3D but the tool itself is not static and needs to keep adding capabilities for 10nm and 7nm as development of these process nodes proceeds. As David Fried, Coventor’s CTO, said:Imec is the premier semiconductor research center, and this collaboration allows us to synchronize our modeling roadmap with one of the industry’s most advanced process roadmaps, as well as to speed the development of their 10nm and 7nm technology. Working together with imec on novel integration schemes, designing SEMulator3D-specific structures for imec’s testsites, and then calibrating advanced models to imec’s wafer processing is an extremely effective and valuable way for Coventor to optimize our virtual fabrication platform for emerging market requirements.

More information on SEMulator3D is here.

Xilinx UltraFast Design Methodology Guide will save you time and money

Xilinx UltraFast Design Methodology Guide will save you time and money
by Luke Miller on 10-27-2014 at 7:00 pm
Categories: FPGA, Xilinx

Well today, i’m easing my way back in from vacation. Took a camper, 6 kids, 1 wife with bun in the oven and saw the great USA. 17 States, roughly 5500 miles. It was great fun and tiring at the same time. The Grand Canyon was a blessing but I really enjoyed the ‘The Four Corners‘ where UT, CO, NM, AZ all meet. I had each kid lay down and made sure they got the chance to be in four states at the same time. Below is my pic. Now the X formation is of course a tribute to the Mother Ship Xilinx and not to the fact at I was eXhausted.

While I was away, Xilinx published a very valuable document named “UltraFast Embedded Design Methodology Guide“. As you know, FPGAs have radically changed over the years and Xilinx has added ARM processors to them and FPGAs are now SoC’s, named Zynq. One very rarely can just sit down and start banging out code for any serious design. The Zynq design takes planning and process/methodologies like any other design, but with a few twists.

In the past, FPGAs were scary, and only used and programmed by hardware engineers, this has changed as well. Who is this guide for? The table below, sums it up very well, it is for anyone who is using a Zynq SoC in their design.

The guide is broken down into seven chapters,

Chapter 1: Introduction
Chapter 2: System Level Considerations
Chapter 3: Hardware Design Considerations
Chapter 4: Software Design Considerations
Chapter 5: Hardware Design Flow
Chapter 6: Software Design Flow Overview
Chapter 7: Debug

The most important chapter in my opinion is Chapter 2, System Level Considerations. This is where the trade space and bake off’s begin to decide where functions/algorithms need to live. For example, you have a million point FFT that needs to be solved. Based on the latency, power and resource usage will determine if this FFT is going to reside in the programmable logic or within the ARM processor system.

The other important factor is data movement, where is the data going? Can it get there fast enough? As these exercises start to begin many domino’s will fall. This guide provides much attention to the issue of memory and how it impacts the system and as you know, it is all important.

The bottom line is the Xilinx Zynq SoC design is a team effort, and all must be willing to overlap and work together. Want to have a great low power Xilinx Zynq design? The figure below really shows that all involved have an impact on power, whether you are an software engineer, hardware engineer or system architect.

The Xilinx Zynq Series will be the best selling FPGA of all time. Download the guide and get started with Zynq today!

October 27, 2014

Designing Hardware with C++ and its Advantages

Designing Hardware with C++ and its Advantages
by Pawan Fangaria on 10-27-2014 at 10:00 am
Categories: EDA

Very recently, I was seeing intense discussions on the need for agile hardware development just like agile software and ideas were being sought from experts as well as individuals. While in software world it has already evolved, in hardware world it’s yet to see the shift in paradigm. My point is that the end goal of agile hardware development must be to accomplish maximum of the hardware job at the highest level of abstraction at the fastest rate which should leave only essential jobs (which may be done in parallel) to be done at lower levels till physical implementation and that must improve the turnaround time by a large extent. Also, I am a believer of the future standing on the shoulders of the past and hence we must look at what has been done so far for hardware realization. These thoughts reoccurred in my mind when I came across a webinarwhich dealt with writing C++ code for High Level Synthesis (HLS) which can be much simpler to write and easier to test and debug than RTL code and obviously orders of magnitude (1000x – 10000x) faster in simulation compared to RTL; of course actual timing and cycle accuracy need to be looked at later.

Although, the webinar does not tell anything about agile, my intuition is that this methodology of hardware realization through software writing in C++ (most versatile programming language) must be looked at in the spirit of agile development for hardware; of course further exploration about actual hardware realization and how these concepts can be used to be truly agile is a matter of research. Let’s look at some details about this methodology; courtesy Calypto.

The key aspect here is to use algorithmic model of hardware without any timing which could later become reference model for hardware. The algorithmic model uses AC (Algorithmic C) data types (can be used with SystemC as well) which is bit-accurate, has unlimited length integer, fixed-point and floating-point that enables very fast simulation as well as compile and link times. Refinement of the model can be done by converting it to fixed-point model. Standard C++ debuggers and test coverage tools can be used along with assertions.

Above is an example code fragment of ALU implementation with ‘assert’ and ‘cover’ point statements to realize coverage driven verification of the implementation. This ALU function can be easily synthesized by Catapult, Calypto’s HLS tool. The algorithmic model can be wrapped with SystemC/TLM, embedded in SystemVerilog/UVM environment and dumped onto ESL platform for SoC verification.

The hardware architecture refinement such as block partitioning (through function calls), memory architecture (synthesized directly without any re-ordering from source code) and processing order depending on the data movement must be defined in the source code. Synthesis constraints such as clock period, technology, resource sharing, throughput etc. are for consideration at RTL, not for algorithmic model.

Above is an example of JPEG engine created by partitioning the algorithmic model; each box represents a function which is mapped to hierarchy during synthesis.

The synthesizable C++ models thus created can be used for design exploration with ‘what if’ analysis, SystemVerilog testbench development with SystemC wrappers, sequential logic equivalence checking, formal property checking and TLM synthesis.

What lies at the core of HLS is, mapping of abstract transaction to pin-accurate, cycle-accurate protocol and optimizing of throughput and latency in the target technology.

As shown above, by developing an executable design in C++ (or SystemC), the overall flow is condensed by a large extent compared to traditional flow for hardware design. One can simulate the functionality in the code very fast and then apply constraints to optimize the design through HLS; any architectural change again can be quickly implemented in the source code. Also any derivative design (such as cell phone to tablet) with similar function but different constraints can be quickly done. Power analysis and optimization can also be done with shorter loops between RTL and C++.

The SLEC (Sequential Logic Equivalence Checker) is a unique tool that can formally verify C++ against optimized C++, C++ against RTL and also check C++ properties, where it can formally prove if assertions always hold, something simulation may miss. Thus SLEC along with Catapult unlocks the full potential of ESL by providing optimized and verified RTL from C++ / SystemC. The RTL block can be verified in UVM environment against reference and ESL model.

A well executed methodology in this way can reduce RTL design and verification time by more than 50%, re-use HLS source code in TLM SoC model and leverage verification environment across abstractions. More detailed information can be obtained by registering and attending the webinarat Calypto’s website.

Coming back to my thought (it might appear radical) about agile hardware development – Can a pure agile system be thought of where RTL level stuff can also be done at the functional level in algorithmic model? Can the concepts used in SLEC, Catapult and may be other HLS tools applied at more micro as well as macro level to make it cycle accurate at algorithmic level? By the way, I learnt that SLEC also handles timing differences in internal computation and at interfaces. Comments welcome!

The IoT and the Forbidden Fruit

The IoT and the Forbidden Fruit
by Peter Gasperini on 10-26-2014 at 4:00 pm
Categories: IoT

A tremendous froth of press and promotion has arisen in the last year concerning the Internet of Things. Nearly every High Tech firm on the globe has begun to advertise their offerings as an integral part of it, positioning their products and services as both essential to the IoT and as a vital component of its future. As the smartphone and tablet markets saturate and roll over, everyone wants to jump on the IoT bandwagon, hoping that it will be the Next Big Thing upon which High Tech fortunes are made and new businesses are built. Yet what is often lost amidst the hyperbole is what the IoT really is and what its effect on our lives will be.

The mind is its own place, and in itself can make a heav’n of hell, a hell of heav’n. – Milton, “Paradise Lost”

Source: wikipedia

Enthusiasts envision a world where everyone can work, live and play out their lives thru the internet – sharing data & files, conducting business meetings over video, shopping, watching TV, cooking, managing the lights and the thermostat at home, driving, etc etc. This will be made possible by having every electrical appliance, instrument and object connected to the internet with its own unique address, rendered possible by IPv6.

Networking and Storage systems houses such as Juniper, Brocade, EMC and Cisco are salivating at the prospect of such a tsunami of streaming data. Every company building a widget with even the most inane wireless capability is touting their product as part of the IoT. Even companies as sober and conservative as IBM have been caught up in the media frenzy, anticipating a new Golden Age of High Tech.

Also read: Processor for Internet-of-Things (IoT)

Yet it remains impossible to name a truly successful IoT product introduced over the last five years. Samsung’s smart watch line has flopped – a shocker, since Samsung has performed so brilliantly in High Tech and, in particular, in Consumer Electronics over the last two decades. Google Glass has actually damaged the Google brand. Even the Apple Watch and Sony’s SmartEyeglass have been received by the market with a barely stifled yawn.

One thing is clear: no company has found the magic formula for inventing the successor to the smartphone. In fact, normally savvy and brilliant consumer electronics firms seem to have forgotten the lessons learned from products such as Sony’s Walkman and the Apple iPod:

[LIST=1]

The new technology should use the current infrastructure

It should be built on a unique combination of existing technologies and capabilities

The product should provoke a visceral, instinctive attraction to the target audience

It should be simple to use – even familiar

The product should not be engineered as a fashion statement, but should be neutral and unobtrusive

It should be marketed not as a piece of technology, but as a tool that will enhance the user’s life

Though the above may seem very obvious and just basic common sense, every single one of the major IoT products released over the last several years violates at least half of those principles.

Nonetheless, research-oriented technophiles have been anticipating the expansion of the internet into every facet of life and have been looking at ways to support it thru the infrastructure. There are three peer-to-peer wireless standards of significant interest contending for mastery of this space – Wi-Fi Direct, Bluetooth 4.0 and Wireless USB. All are based on existing, widely used and very robust protocols and have years of work and decades of expertise captured in their specifications. Nevertheless, as the following table demonstrates, none of them have a combination of performance, power, bandwidth and other features that makes it a clearly superior choice over the others:

Yet just as Adam and Eve changed everything when they ate fruit from the Tree of Knowledge, the many far-reaching effects of the IoT will include their share of decidedly negative consequences. For instance: if a person has all of their home appliances connected to the internet and controlled thru their e-wallet-equipped smartphone, a third party – whether criminal or official – will be able to track everything this person buys, does and communicates on a daily basis, should they be able to hack into the personal network of that individual. And hack it they will – even purportedly secure and well protected systems for Wall Street firms, retailers and government agencies worldwide have been penetrated and their databases compromised by organized criminal enterprises. Governments the world over have also demonstrated how they can be a potential threat to their citizenry thru monitoring their communications and activities, the most recent scandal highlighting the LAPD and its disturbing pronouncement that all drivers in Los Angeles are being tracked.

I’m blogging about all this and more at http://vigilfuturi.blogspot.com. As the IoT turns into a juggernaut, we need to be prepared to deal with how it will affect our lives – embracing some parts of it while altering or resisting other aspects.

October 26, 2014

Cliff Hou at TSMC OIP

Cliff Hou at TSMC OIP
by Paul McLellan on 10-26-2014 at 7:00 am
Categories: Foundries, TSMC

I attended Cliff Hou’s keynote at TSMC OIP Forum earlier this month. OIP is a huge undertaking. It currently has over 100 ecosystem partners, 10 technology generations, 7600+ IPs, 60+ EDA tools, 7000+ tech files and 150+ PDKs.

Most of Cliff’s presentation gave details on where TSMC are with the various processes. Of course 20nm and above is all in full production, and we know it is shipping in high volume to both Apple and Qualcomm, among others, since they have said so. In fact there are 12 products that are already function proven on first silicon.

16FF completed full qualification in Q4 2013 and entered production. Over 55 products are planned for tapeout in 2014/5 in mobile, networking, CPU, GPU, FPGA and more. They achieved first silicon success on a network processor for HiSilicon Technologies. It is actually a combination of several chips using TSMC’s CoWoS (chip-on-wafer-on-silicon) 3D technology. The logic chips are built on 16FF process containing 32 Cortex-A57 cores, and the second chip is a 28nm I/O chip.

16FF+ (the “+” is important, it is a different process) is currently in qualification, which is on track. They released V1.0 in August 2014 so designs can start. 16FF+ yield is ahead of plan.

The 16FF+ IP ecosystem is already showing silicon results with various interface and memory IP already completed silicon qualification.

Cliff talked about 10nm. He said that it has industry leading density for the smallest die size. Compared to 16FF+ it has a speed improvement of 25%, a power reduction of 45%, density improvement of 2.2X for logic and 0.45X for SRAM. The key upcoming milestones are:

V0.1 available for design starts Q4 2014
V0.5 available, Q2 2015
Risk production November 2015

Going off the bleeding edge, Cliff talked about TSMC’s ultra-low-power technology, especially targeted at internet of things (IoT) applications:

0.18eLL and 90uLL in production
55ULP, 40ULP and 28ULP will have risk production in 2015
RF and embedded flash features for IoT SoC integration
The ULP processes have lower Vdd to reduce active and standby power. Tailored eHVT device enables over 70% reduction in standby power. Think battery life.

Cliff’s last slide summarized TSMC’s process introduction roadmap:

16FF+ is mature and ecosystem ready with multiple solutions. First product is silicon-proven with 50+ tape-outs are scheduled for 2014 and 2015
10nm offers 2.2X gate density, 25% better speed or 45% power reduction with risk production in Q4 2015. Ecosystem solutions have been developed, certified and in use on test chips
Ultra Low Power technology platform, covering from 0.18ɥm to 28ULP, can support various IoT applications. Existing ecosystem can be leveraged for fast time-to-market

October 25, 2014June 14, 2019

3 reasons to focus on hardware dependent software

3 reasons to focus on hardware dependent software
by Don Dingee on 10-25-2014 at 4:00 pm
Categories: Aldec, EDA

Why is software for modern SoCs so blasted expensive to develop? One reason is more software is being developed at the kernel layer – hardware dependent software, or HdS. Application software often assumes the underlying hardware, operating system, communication stacks, and device drivers are stable. For HdS, this flawed assumption of stability can eat a project alive. Continue reading “3 reasons to focus on hardware dependent software”

October 25, 2014December 27, 2023

Sensing, Processing and Connecting: IoT Fundamentals

Sensing, Processing and Connecting: IoT Fundamentals
by Eric Esteve on 10-25-2014 at 7:00 am
Categories: Ceva, IP

Internet of Things, or Internet of Everything, is certainly the buzzword of the year. Does IoT describe one product family? Not really as the acronym describes a family of concepts, each of these concepts could effectively be turned into a family of products, if this concept reach the market, or fulfill a market need. Nevertheless we could unify IoT definition, saying that IoT fundamentals at hardware level are: sensing, processing and connecting. These three actions will serve as an IoT product foundation, the finished product also including software encapsulation and security. An IP vendor is not selling a finished system, but some of the hardware “lego” pieces that you need to integrate to build the system. CEVA is typically one of these IP vendors you may want to talk with when defining an IoT product, as the company propose two of these fundamental pieces: Processing (thanks to the DSP IP core family) and Connecting (thanks to Riviera Waves acquisition). If you consider that CEVA has developed their DSP IP port-folio by supporting the mobile phone semiconductor industry, you realize that the company should be well positioned to address the various needs of IoT systems by offering low power solution. Low power is the mobile industry DNA, it’s also CEVA DNA because CEVA’s IP port-folio development is tightly coupled with battery powered, mobile systems.

If you search for low cost, low power sensors, you will certainly find several products filling your requirements. However, low cost/power generally means noisier sensors. That’s why DSP fit in sensing, as you need a lot of signal-cleaning (filtering, smoothing, calibrating) in order to extract meaningful data. Moreover, with the introduction of mics and image sensors, no processor does a better job than a digital signal processor: DSP have been invented to process algorithms, and voice or image processing rely on algorithms.

Thus, DSP-based sensing is not only the best (algorithm) processing option, it’s also the best approach for power saving, as we can see on the above example of MP3 decode comparison. Main CPU is clearly the worst option (it’s normal as a CPU is supposed to be general purpose processor) and the power consumption of M4 MCU/DSP is still 2x this of an optimized DSP core like CEVA-TL4.

The next question is to know if you can support multiple sensing technologies by using a single DSP (or do you have to use a specific DSP for each sensing technology). In fact the answer is in the picture below: the same DSP core can support sensor fusion (contextual awareness + motion gesture + indoor navigation), voice trigger, ultrasonic gesture, face trigger and BlueTooth Low Energy beacons. CEVA is claiming that such a DSP solution implemented on 28HPM supporting Always-on (sensor fusion + Voice Trigger + Race Trigger + BLE) consume less than 150 uW…

CEVA propose using the CEVA-TL421 as an audio analyzer, supporting mobile wearable, smart home and robot applications, all these applications requiring supporting:

Voice recognition and speaker identification
Speaker separation through beamforming
Environment sensing like in the train or cinema
Emotion detection

To support video analytics, the CEVA-MM3101 Computer Vision Engine would be suited for mobile, wearable, smart home, smart cities and security & surveillance markets. For such markets the DSP need to support:

Human & object recognition
Face recognition, gesture recognition
Tracking based on feature and pattern matching
Emotion detection
Image and video enhancement or Video stabilizing.

If you goal is to develop an IoT platform, to serve as a demonstrator as well as to support software development, you can put all together the various CEVA DSP core (CEVA-TL410, CEVA-TL421 and CEVA-MM3101) with the CEVA Connectivity Platform supporting Zigbee, Bluetooth and WiFi. But you will probably need to integrate a low-power CPU/MCU (don’t need a powerful one, as the DSP cores are running the high performance processing), shared memory and various interfaces like I2S, I2C, LCD drivers or some of the MIPI specification like CSI or SoundWire.

Eric Esteve from IPNEST –

October 24, 2014

A Brief History of ASTC and VLAB Works

A Brief History of ASTC and VLAB Works
by Paul McLellan on 10-24-2014 at 4:00 pm
Categories: EDA

When I worked for VaST our engineering was in Sydney Australia. To my surprise there was another, entirely independent, group working on virtual platform modeling and tools in another place in Australia, in Adelaide. Is there something in the Fosters? They had originally been part of Motorola Corporate R&D and Software Group, servicing all the many segments of its semiconductor arm, SPS, but they incorporated as Australian Semiconductor Technology Company (ASTC) when SPS was spun out of Motorola as Freescale in 2005. Then in 2011 they also created the VLAB Works business outlet, essentially a complete virtual prototyping laboratory for accelerating embedded system design, hw/sw co-design, and embedded software development.

They have a mixture of EDA engineers, semiconductor designers, IP, embedded software and more. They have a lot of really innovative new internal technology, as is their premier virtual prototyping laboratory VLAB and its suite of tools and toolboxes, but typically they do business as turnkey projects to create, deploy and support complete virtual platforms to accelerate system design and embedded software development. They have close to 100 engineers and have completed over 200 projects. Everyone is an engineer, including management, with 50% of management and 25% of staff having PhDs, so it is a very deep and very experienced team, everyone with over 10 years of experience in these domains.

One area of ASTC focus, where they seem to be ahead of anyone else, is automotive grade MCU and ECU virtual platforms, very fast, accurate, integrated in the automotive flow solutions, where they support all the leading automotive microprocessors (not the usual ones used in, say, cellphones), the bus communication standards such as FlexRay and CAN, (which I thought was “car area network” for years but the C is a much more boring “controller”), LIN, SPI, Ethernet, and all others, and support of the right system simulators and analysis tools used in the industry such as Mathworks’ Matlab and Simulink, dSpace HILS/VEOS, Vector CANoe/CANalyzer.

For example, they can handle an entire closed loop ECU virtual system, including MCUs, ASICs, Interface electronics, and car motor and other plant models, running the Autosar operating system, running a mixture of tasks on multiple simulated CPUs and with a virtual console connected to control and observe, at real time speeds or much faster than real time,

Another focus area is platforms for mobile. Cell-phones have very short development cycles and if you wait until the hardware is available before you start to do the embedded software development you will be late. Reference boards used to be one solution but they are getting too slow. I once asked an engineering manager in Japan what they did while they were waiting for reference boards: “we pretend to program” he said.

Mobile requires an almost completely different set of models and interfaces from automotive (outside of automotive infotainment which is much closer to smartphone technology and does not have safety critical issues). They have undertaken complex operating system porting for mobile/multimedia and have operating system ready to run on new architectures (including new DSPs). The operating system will be ready to install immediately the silicon is available.

ASTC was born in Australia but has grown into a global company by attracting similarly experienced teams from around the world and is now a global company. For example, in 2007 they acquired the Motorola phone virtual prototyping team in Urbana-Champaign, IL, US, and later on added the key experts from the modem simulation organisation in Toulouse, France. They have offices across the world in US, Japan and Europe. And, yes, still in Australia too. The yellow stars are their offices, the red dots are their customer locations.

As a manager from a major European automotive Tier 1 business unit (outside Stuttgart I’m guessing) said:Deploying a VLAB MCU virtual prototype “enabled us to prepare our ECU software up to 6 months earlier and be ready for the winter season tests on time, rather than miss a whole year cycle of time to market!

Even by the comparatively glacial speed of automotive development, one year of time to market is huge.

VLAB Works’ website is here. Parent ASTC’s website is here.