SemiWiki – Page 525 – The Open Forum for Semiconductor Professionals

December 13, 2017December 27, 2023

Webinar: ADAS and Real-Time Vision Processing

Webinar: ADAS and Real-Time Vision Processing
by Daniel Nenni on 12-13-2017 at 7:00 am
Categories: Ceva, Events, IP

ADAS is in many ways the epicenter of directions in the driverless car (or bus or truck). Short of actually running the car hands-free through a whole trip, ADAS has now advanced beyond mere warnings to providing some level of steering and braking control (in both cases for collision avoidance), providing more adaptive cruise control, adapting lighting (high-beam/low-beam), parking assistance, the list goes on. All of this requires a greatly enhanced idea of what is going on around the car and that takes lots of sensors (cameras, radar, lidar, …), lots of sensor fusion and a very significant level of image recognition. This starts with some very sophisticated signal processing. You might want to learn more about the camera monitoring part of this, including monitoring you, the not always reliable driver) by watching an upcoming CEVA webinar on the topic.

Now if you want to build this kind of solution into your ADAS system (CEVA is looking particularly at Tier-1 providers here), you could start by building up all that image recognition technology yourself or you could start with a solution that already incorporates detection engines for pedestrian, vehicles, lane markers and moving objects (deer for example, a major cause of injuries and car damage where I live; bears and cows are generally fatal all round). The platform also includes CEVA’s programmable vision platform, to which you can add your own differentiated image processing.

The great thing about emerging ADAS technologies is the amazing capabilities they enable. The bad thing from a provider point of view is the incredible range of technologies you have to bring together, and qualify, to make all those amazing feature possible. Why start from scratch when companies like CEVA have already done the base-level heavy lifting for you?

Summary
As the automotive market experiences accelerated growth and rapid adoption of vision applications such as Camera Monitoring Systems, Smart Rear Cameras, and Driver Monitoring Systems, there is a need for solutions that are both efficient and cost effective to address these applications in high volumes. In addition, these solutions must also allow for Tier-1s to both differentiate and meet the growing demands in performance from today’s OEMs.

NextChip’s APACHE4 is a vision-based pre-processor SoC targeting next-generation ADAS systems that uses a dedicated sub-system of image processing accelerators and optimized software. The APACHE4 incorporates dedicated detection engines that include pedestrian detection, vehicle detection, lane detection and moving object detection and have incorporated CEVA’s programmable vision platform into the APACHE4 alongside its differentiated image processing accelerators to enable advanced and affordable ADAS applications.

Join CEVA and Nextchip experts to learn about:
· Challenges of ADAS and vision based autonomous driving
· Overview of Nextchip APACHE4 ADAS SOC
· Utilization of CEVA-XM4 for differentiation and performance
· Applications use cases with APACHE4 and CEVA-XM4

Target Audience
Computer vision engineers, deep learning application designers, project managers, marketing experts and others interested in embedded vision, machine learning, and autonomous driving.

Speakers
Jeff VanWashenova
Director, Automotive Segment Marketing, CEVA

Young-Jun Yoo
Director, Strategic Marketing, Nextchip

About CEVA, Inc.
CEVA is the leading licensor of signal processing IP for a smarter, connected world. We partner with semiconductor companies and OEMs worldwide to create power-efficient, intelligent and connected devices for a range of end markets, including mobile, consumer, automotive, industrial and IoT. Our ultra-low-power IPs for vision, audio, communications and connectivity include comprehensive DSP-based platforms for LTE/LTE-A/5G baseband processing in handsets, infrastructure and machine-to-machine devices, computer vision and computational photography for any camera-enabled device, audio/voice/speech and ultra-low power always-on/sensing applications for multiple IoT markets. For connectivity, we offer the industry’s most widely adopted IPs for Bluetooth (low energy and dual mode), Wi-Fi (802.11 a/b/g/n/ac up to 4×4) and serial storage (SATA and SAS). Visit us at www.ceva-dsp.com and follow us on Twitter, YouTube and LinkedIn.

December 12, 2017July 18, 2025

Starblaze Uses Synopsys DesignWare IP to Launch SSD Controller SoC

Starblaze Uses Synopsys DesignWare IP to Launch SSD Controller SoC
by Mitch Heins on 12-12-2017 at 12:00 pm
Categories: IP, Synopsys

I recently wrote an article about Synopsys’ DesignWare Security IP for the Internet-of-Things market and was interested to see that a startup, Starblaze Technology, has now used parts of the same IP in its latest Solid-State Drive (SSD) controller. The security IP caught my eye, but the rest of the story really put things into focus. Synopsys was able to provide a one-stop shop experience for Starblaze that combined DesignWare Foundational IP (high performance cores, memories and standard cell logic), DesignWare Security IP (True Random Number Generator) and DesignWare Interface IP (DDR4 and PCI Express 3.1). The icing on the cake was the fact that they provided this IP in a flexible and configurable way that let Starblaze differentiate their product offering while getting all the advantages of using silicon proven IP and first-pass silicon success.

Starblaze, headquartered in Beijing, China, is a relative newcomer to the market being founded in November of 2015. Only two years after being founded, the young startup has used Synopsys’ DesignWare IP portfolio to design and launch a new product, their STAR1000 enterprise storage SDD controller, which they claimed met with first-pass silicon success and for which they are already shipping in volume production. That is not a minor feat for a complex multi-core high-speed device.

Starblaze attributes much of their first-pass silicon success to their use of Synopsys DesignWare IP. Their ability to work with Synopsys allowed them to focus on their design while gaining all the advantages of using silicon-proven IP. The STAR1000 SDD controller uses the Synopsys ARC HS38 processor and integrated MetaWare Development toolkit as well as several DesignWare Foundational IP blocks such as high-speed, low-power memories and logic components.

The Starblaze implementation used multiple ARC cores to achieve the high IOPS they needed as well as the 40-bit physical address extensions required to support one Terabytes of physical memory. Starblaze took advantage of the HS core’s integrated error correction code (ECC) support to provide implicit error handling needed to ensure the extremely high data reliability required by SDDs. They also used the ARC’s flexible architecture to add custom instructions, condition codes, and core and auxiliary registers to achieve lower power consumption and to reduce I/O latencies by 50 percent over competing alternatives.

Because Starblaze is selling into the enterprise storage SDD market they also needed to meet very stringent security standards to ensure protection against malicious attacks and backdoor security issues. To do this they made use of Synopsys DesignWare Security IP to implement a True Random Number Generator (TRNG) for key generation and other cryptography data required by security protocols used in their SoC. Synopsys’ TRNG module is FIPS 140-2 certified and offered a high-quality entropy source to enable high levels of security.

In addition to the cores, memories and security IP, Starblaze made use of Synopsys silicon-proven DesignWare Interface IP for their DDR4 and PCI Express 3.1 interfaces. Especially important to Starblaze was the ability of the DDR4 interface IP to support DDR4 3D stacked (DDR4-3DS) DRAM with 16 ranks of memory. That capability expanded Starblaze’s capacity by up to 400 percent compared to the previously supported 4 rank memories.

As for their PCI Express 3.1 interface, Starblaze used DesignWare IP to support single root I/O virtualization (SR-IOV) features which allows the Starblaze controller to increase system performance when used with enterprise systems employing virtualization. SR-IOV allows for sharing of the SDD across multiple CPUs or operating systems. Synopsys’ DesignWare DDR4 and PCI Express 3.1 IP also enabled Starblaze to include reliability, availability and serviceability features into their SoC that helped to increase data protection, system availability and issue diagnosis.

All in all, this is a very nice success story for the Synopsys DesignWare IP portfolio and it highlights the breadth and complexity of what can be done with their DesignWare IP portfolio. For more information on other Synopsys and Starblaze offerings please see the links below.

December 12, 2017

Creative Noise-Reduction in Automotive AMS

Creative Noise-Reduction in Automotive AMS
by Bernard Murphy on 12-12-2017 at 7:00 am
Categories: Ansys, Inc., Automotive, EDA

Automotive applications are one of the hottest domains today in semiconductor design. We’re bombarded daily with articles on new hybrids, electric cars, ADAS and autonomous cars, trucks and busses. All of these applications are certainly amazing, but the devices that make them work still have to deal with the same old challenges, often amplified in the cabin / body / drivetrain of a vehicle. One of these is noise in all its many manifestations, particularly (in this context) the noise impact of digital electronics sitting right next to analog circuitry on the same device.

A lot of what we read about managing noise, particularly between analog and digital circuitry, seems to start from the assumption that the noise source is immutable and what we need to manage is immunity to that source, through shielding, decoupling, separated power and ground planes, and so on. All of these methods are of course important, but there is also value in challenging that assumption of immutability. If the design can be modified to reduce noise generated by the digital circuitry, that should be a big win.

A while ago, ANSYS sponsored a webinar on just this topic, centering on a presentation by Dr. Peter Blinzer of NXP Hamburg. Although this isn’t hot off the presses, I think it is arguably even more important today, as mixed analog and digital content appears throughout infotainment devices, sensor fusion and other AMS functions in advanced automotive electronics. It’s also, I think, a creative application of a tool you wouldn’t normally associate with noise management.

What generates noise in digital circuitry is switching. The other thing greatly influenced by switching is dynamic power consumption. So, unsurprising, noise and dynamic power are related. But did you ever think about RTL power optimization as a way to also reduce noise? Peter Blinzer did, and came up with some compelling results.

Optimizing power is always a good thing; you work at reducing power until you hit whatever power budget you were given, then you stop, right? But if switching also affects noise, is hitting the power budget the right place to stop? Maybe not – maybe some further tweaking will pay off in noise reduction. Peter illustrated this through his analysis and optimization of a digital radio IC used in infotainment systems. He starts by showing a very detailed analysis of signal to noise in such a radio and the frequencies (including digital clock frequencies and related harmonics) and root causes where noise can dramatically reduce the quality of reception. These are what he wanted to reduce.

Peter ran PowerArtist analyses on multiple use-cases, looking for opportunities to reduce power. In one case, he found that a digital controlled oscillator (DCO) should have been gated off, but was actually still on. That’s also a pointer to unnecessary noise. By fixing clock gating, power was reduced naturally. We’ll get to overall noise impact next. In fact, similar analysis pointed to opportunities to improve gating on multiple DCOs. More power reductions, together with others adding up to a 60% power saving in the digital PLL alone.

Impact on noise, as measured in layout-based dynamic power simulations, was just as striking. This took total power from an average of ~30mA with noise of ~15mA down to ~5mA with noise of maybe ~1mA. Similar results were apparent in a frequency spectrum analysis, where most of the original noise contributors were reduced by almost 20dB, below the level where they can be a serious threat to reception quality (a few were not reduced but these were sources outside the scope of this analysis).

Peter noted several RTL changes they made to implement these improvements – replacing floating-point arithmetic with fixed-point, optimizations in clock gating and optimization of test-support logic. They were careful also to avoid over-constraining the design – naturally to avoid excess power but equally to limit noise. Not something we might normally consider.

To get more detail on this lateral-thinking approach to noise management in AMS designs, you can watch the webinar HERE.

December 11, 2017July 18, 2025

Synopsys White Paper on IoT Security – Introduces DesignWare Root-of-Trust Module

Synopsys White Paper on IoT Security – Introduces DesignWare Root-of-Trust Module
by Mitch Heins on 12-11-2017 at 12:00 pm
Categories: IoT, Security, Synopsys

As the internet of things (IoT) continues its climb to a trillion devices, there has been many articles and books written on the need for securing those devices. With all the IoT gear that I seem to be picking up as Christmas presents, I feel like I’m doing my part to help the market get there, but I have to say, I sure hope the SoC designers that created those devices have been reading and listening to the need for IoT security.

And, it does indeed seem that more companies are paying attention to the need for integrated security in their IoT devices. It all starts with something called Root-of-Trust (RoT) and now one of the bigger IP players in the industry, Synopsys, has written a white paper on RoT and is backing it up by introducing a new DesignWare module targeted at providing IoT security IP for SoC devices. The new module is called ‘tRoot H5 Hardware Secure Module’. More on that is a second, but first let’s do a quick review of what we mean by RoT.

As a quick reminder of why we need to secure our IoT devices, one only need remember back to late 2016 when researchers were able to demonstrate how hackers could possibly put people into harm’s way by remotely accessing a Tesla Model S car’s control system. The researchers were able to access and control the engine, braking system, sunroof, door locks, trunk, side-view mirrors and more. They did this by hacking into the car’s infotainment and WiFi connections which then got them access to the car’s controller area network (CAN) bus. The good news is that these were benevolent researchers who then worked with Tesla to close the security holes. But what if it had been someone more nefarious? Enough said.

One way to combat this type of hacking is to use what is known as a hardware Root-of-Trust (RoT). RoT is a set of functions that is explicitly trusted by the SoC’s operating system. These functions are used to ensure secure communications between an IoT device and the outside world using encryption and secure keyed handshaking. Additionally, RoT functions can also monitor the SoC’s memory, registers, and internal bus structures to ensure that data that does make it into the device has not been tampered with.

RoT functions can be implemented in software but most SoC designers are now turning to dedicated hardware accelerators to implement their RoT. Hardware cryptographic accelerators run very fast while taking the load off the SoC’s CPU(s), thus saving power and conserving device runtime memory. Additionally, security hardware can also be linked into the rest of the SoC architecture to monitor the SoC as it is running.

Per a recently released Synopsys white paper, RoT functions are typically made up of multiple hardware units. One function would be to ensure that a SoC’s boot up sequence is secure, usually by using a dedicated ROM that can only be accessed by the RoT module. Another unit takes care of True Random Number Generation (TRNG). TRNG ensure that ephemeral data used for secure connections is not easily predictable. The more random the better. Yet another unit may be a secure real-time clock (RTC) that is used to manage time-based security policies.

The important part about RoT is that it must offer strong protection for all operational phases of the SoC, such as power off, power up, run time operations and communications with external entities. Secure monitoring during power up is a must but as mentioned, many teams are now looking to integrate security into all phases of the SoC including runtime operation. Some applications require proper authentication of certificates during runtime. That means that hardware RoT modules are needed to handle common cryptographic functions such as generation of RSA signatures and ECDSA.

Key management is done inside the hardware Root of Trust module. Only indirect access to these keys is allowed and managed by the RoT application layer. Assuming the privilege levels are correct, any importing of keys must be authenticated, and any exporting of keys must be wrapped to ensure continued protection of the secret material. An example of common key management applications would be a hardware secure module (HSM) using a public key cryptography standard (PKCS)#11 interface application to manage the policies, permissions, and handling of keys.

So, what is Synopsys doing in this space? They recently released a DesignWare Module called tRoot H5 Hardware Secure Module. The module is a RoT HSM that enables connected devices to securely and uniquely identify and authenticate themselves to create secure channels for remote device management. The tRoot module is designed to protect devices when they are powered down, at boot time and at runtime. The DesignWare HSM handles secure communications management with other devices and has logic blocks for a Secure Instruction Controller and a Secure Data Controller. These latter two blocks can be used to build further security into the rest of the SoC.

A block diagram for the tRoot HSM module is shown. Being DesignWare, the module can be synthesized and mapped to any standard process technology used for IoT SoCs. The module is highly scalable and flexible as it uses software running on the HSM CPU to define the security features that are to be supported by the SoC. The tRoot module also offers Key Management which uses the PKCS#11 interface to help manage both static and ephemeral keys and can also be used to manage secure in-field firmware updates for the IoT device.

To summarize, making IoT devices secure all starts with a hardware Root-of-Trust. More companies are addressing this space with dedicated RoT IP and Synopsys is now in the mix with their new DesignWare tRoot H5 HSM with Root-of-Trust.

You can learn more about Synopsys offerings in this space by visiting their DesignWare Security IP web page, viewing their webinars and downloading their “Understanding Root-of-Trust” white paper.
See Also:
Understanding Hardware Root of Trust
DesignWare Security IP web page
Webinar: Building Security into Your SoC with Hardware Secure Modules

December 11, 2017

When Invaluable Kills Business

When Invaluable Kills Business
by Frederic Leens on 12-11-2017 at 7:00 am
Categories: EDA, FPGA
6 Comments

Productivity is notoriously hard to sell. I recently visited a company where the engineering team wanted to evaluate one of our FPGA debug and analysis products on an existing board. This board had an FPGA that we supported and had all the required connectivity – it could just be used ‘out of the box’. Our tool – Exostiv – involves the insertion of a debug IP in the FPGA. We offered to set up the tool with the engineering team and within 60 minutes, the board was instrumented and ready to use. As I did it by myself, there was no initial setup cost nor learning curve cost in this example.

Well, a good demonstration as it seemed… After 2 hours of discussion and having shown the product’s main features, I left the engineering team a unit with a license until the next day.

The next day, the engineering team told me that the tool was easy to use for those used to JTAG-based logic analyzers such as Chipscope / Xilinx logic analyzer. Basically, the flow was identical. Specific items like transceivers configuration required some additional understanding of the parameters, but overall, they said the setup and trial had run pretty smoothly.

Then, they told me that our tool had allowed them to find and correct a bug in an Ethernet IP that they were unaware of. With our tool, they had been able to cover a specific test scenario that had not been explored until then. They were about to send the board and the firmware to production and said that this new result was‘invaluable’.

As for me, I was absolutely delighted. This trial had totally exceeded my expectations. I expected to receive a purchase order the same day.

I was wrong.

Actually, they were puzzled. They somehow went to the conclusion that our tool was priced too high because our model involves subscribing for our software for a minimum of 12 month – and here they had resolved the bug so quickly… (I am still perplexed by this reasoning).

Anyway, they decided to wait until they had a new bug or alert that could *justify* buying the tool. Practically, this means waiting until ‘someone’ (a customer?) complains after the system is released.

They had discovered an issue that they were not aware of – and before it had become painful to anyone…

And what about the management? He was almost not aware of it. Practically, nothing harmful had happened at all – so nobody was even considering a purchase…

This – real – case is a little extreme, I agree – and I certainly do not know all the details of the decision process in this company.

However, we are seeing a real trend this days of engineering ‘waiting for pain’ and then look for a remedy for it.

The problem with this approach can be a severe loss of money.

Going to production with unknown bugs has a cost that generally reduces to how much market (share) you’ll loose by arriving late on the market with a working product. In this case, it seemed that the product was already reasonably stable: the engineering team was perfectly qualified and had not seen anything wrong (somehow someone had second thoughts or doubts, since they showed some interest in testing our solution). This cost can be estimated at the value of the market that is left to the competitor because you are delaying your product launch – or fixing the product.

Even if this cost is very large (loosing a few % of market share should be a lot of money – or you do not address a market that is large enough), it can have no impact on a decision to invest in a new hardware or software EDA tool to debug and analyse electronic systems in the late stages.

My opinion is that it is usually too complicated for many companies to put a number on it. The value cannot be estimated accurately and its consequences are usually unpredictable and too distant. We are constantly working at gathering such numbers… But who really believes the salesman who tries to frighten the customer to get a sale…? As a professional, I am personally inclined to calling to the intelligence of my prospects, not their fear…

In my opinion, as an electronic engineer, we should all ask ourselves the following questions:

– Will there be bugs in your design?Absolutely. FPGA are such complex beasts that this cannot be avoided. No wonder why 40% of the total design time is spent on debug and verification.
– When do those bugs cost the most? When they ‘escape’ to production: the cost of having to stop the production and get back to design is gigantic.
– Who is responsible to avoid this?The engineering team.
– Why would you reserve a budget for any tool?Because it pays back.

It pays back first from the saved engineering hours. It pays MUCH MORE back if the tools help avoid bugs escaping to production, even on FPGAs.

Thank you for reading.
– Frederic

December 9, 2017

Top Cybersecurity Concerns Are WRONG

Top Cybersecurity Concerns Are WRONG
by Matthew Rosenquist on 12-09-2017 at 7:00 am
Categories: Security
1 Comment

A recent survey by Varonis of 500 security professionals from the U.S., UK, and France highlights the top three cybersecurity concern for 2018: Data Loss, Data Theft, and Ransomware. Sadly, we are overlooking the bigger problems!

Missed the Target by a Mile
I think we are scrutinizing at the small and known threats, when we should be looking forward at the significant risks coming our way. In some ways, it is like the child in the crosswalk who is looking down at their untied shoes, while oblivious to the truck speeding towards the intersection. The top survey results are not surprising, just disappointing.

The Real Threats
Here is what the world should really be concerned about, when it comes to cybersecurity:

[LIST=1]

Data Integrity Compromises. These types of attacks can cause catastrophic impacts and losses, orders of magnitude greater than data breaches and common theft. By just modifying a few transactions or data records, thieves have been able to steal tens to hundreds of millions of dollars, researchers have taken control over the operation of cars and planes, and national infrastructure systems have been physically damaged.

Escape of Nation-State Attack Techniques and Code. Highly sophisticated and funded capabilities are normally reserved by nation states for precision attacks. But once the vulnerabilities, exploits, and tactics are used in the wild or leaked, others will have the opportunity to harvest, dissect, and duplicate functions for their purposes. Threats such as cyber criminals, anarchists, and other nation states will gladly wield these super weapons for their end-goals and to the severe detriment of others.

Exploits in IoT Devices Which Pose a Risk to Life-Safety. Society is sliding over the verge where we place our lives and safety in the hands of intelligent machines. It is most relevant in the automotive, critical infrastructure, healthcare industries. Although astonishingly wonderful if used for good, it comes with risks. Autonomous vehicles, electrical grids, and medical devices all play an important role in keeping people alive and healthy. When attacks undermine functions and turn malicious, people will be put in harm’s way.

Not a Flawed Survey
Sadly, I believe the survey was accurate. This means those professionals who provided answers are only seeing the near-term problems: the very ones they fear most. These issues are annoying, but do not compare to what is just around the corner. The risks are as mismatched as much as the capabilities to prevent, detect, and respond to them. Consider that there are already mature tools and defenses for data loss, theft, and ransomware. They just must be instituted, configured, and maintained to work against most attacks. For the real threats, we are much less capable in our defenses. Granted, the participants may not have many options to choose from, but the answers given may speak volumes about those who voted for these categories. Namely, that they are likely not as prepared for these basic risks as they would like, therefore they fear what they know will come. With their focus on these, they fail to see the long-term strategic picture. That is bad for everyone, except the attackers. Without looking forward, like the child in the crosswalk, they are likely to be surprised when the truck hits.

We Must Do Better
We must think strategically if we want to be prepared and make a meaningful difference.

“Plan for what is difficult while it is easy, do what is great while it is small” – Sun Tzu

If we don’t perceive and understand the big problems ahead, we stand little chance in addressing them early.

Where do you stand? Is your attention only on the immediate and well-understood risks?

Interested in more? Follow me on your favorite social sites for insights and what is going on in cybersecurity: LinkedIn, Twitter (@Matt_Rosenquist), YouTube, Information Security Strategy blog, Medium, and Steemit

December 8, 2017July 3, 2021

Free IoT SOC Books at REUSE 2017

Free IoT SOC Books at REUSE 2017
by Daniel Nenni on 12-08-2017 at 7:00 am
Categories: Events, Open-Silicon, Semiconductor Services

The second annual REUSE conference is next week bringing the fabless semiconductor ecosystem together for a day of food, fun, and some very interesting presentations. It’s at the Santa Clara Convention Center this year which is nice and it is FREE! More importantly, there will be 30+ vendors in the exhibit hall which opens at 9am for registration and breakfast. Exhibit hall conversations are the best for networking, absolutely.

You can find me at the Open Silicon booth signing free copies of our latest eBook “Custom SoCs for IoT: Simplified” – A Book Focusing on the Emergence of Custom Silicon for IoT Devices. More than 500 people are expected to attend and we only have 100 books so get there early if you can, it would be a pleasure to meet you!

In case you have not downloaded the PDF version here is the book foreword by Taher Madraswala, President and CEO of Open-Silicon. It has been a pleasure to work with Taher and the Open Silicon people over the last two years on SemiWiki.com. Not including this one, we have written 30 blogs about Open Silicon that have earned close to one million views.

FOREWORD

Enablers of the Internet of Things (IoT) are improving the growth rate of the semiconductor industry in a significant way. Technology advancements in algorithms and processing units have made human-to-machine communication a reality. We are now entering an era where incorporating this capability in smart devices has the potential to simplify, enhance and even save lives. The IoT ecosystem is a symbiotic collaboration of hardware and software developers, building block (aka IP) providers, architects and visionaries who want to translate complex human functions (such as voice, vision, and thought) into simpler, machine-decipherable functions. At the core of this effort are the custom system-on-chip (SoC) solutions that enable designers across vertical markets to meet the performance, power, price, and time-to-market constraints of the quickly evolving IoT universe.

The semiconductor ecosystem has categorized the IoT space into three distinct segments: IoT cloud, IoT gateway, and IoT edge. This segmentation allows key players to devise strategies and offerings in areas of their expertise, which benefits customers with much-needed competition in each segment. Similar segmentation in the computation world helped create the “WinTel” (Microsoft + Intel) ecosystem, which ruled humanity for decades. Segmentation also helps address new and evolving standards, markets and customers in a rapid response manner. Custom silicon solutions have been deployed on the cloud side of the IoT for many years, specifically in networking, telecommunications, storage, and computing. However, until very recently, custom solutions were out of reach for IoT edge and IoT gateway segments due to cost or lengthy development schedules.

The IoT SoC platform approach has opened up many new use-cases for edge applications. Among them are sensor hubs for industrial applications, including outdoor, factory floor and in-room environmental control. IoT gateway applications are also experiencing rapid growth from the custom IoT SoC platform approach. For example, a well-designed IoT gateway SoC platform can address multiple smart city applications, such as waste management, transport, traffic, parking, lighting, and metering.

Custom SoCs for IoT: Simplified 6 The custom IoT SoC platform approach can speed custom design, reduce risk and cost, and enable the critical differentiation that customers demand. Quality platform development requires extensive experience and knowledge. Platform creators must think like a system company as well as a startup. They need to consider end-use-cases in the vertical IoT markets while designing an easy-to-use platform. Such developers need to be responsible for the core block and its verification, which allows for the highly customized software drivers to be written and used as the core library.

The use of platforms not only opens the door to faster validation of new designs with very little risk but also allows the visionaries and architects to focus on their end goal, which is to bring product differentiation, more use-cases, more functionality and more ingenuity to the world of IoT.

“Custom SoCs for IoT: Simplified”is the first comprehensive book to explicitly define and detail the various IoT architectures. It covers the multitude of security factors, the power budgets associated with different IoT applications, and many more technical considerations that dictate the success of a custom IoT SoC platform, including but not limited to implementation methodologies, as well as hardware and software tradeoffs. This book also provides a detailed case study of a highly successful approach to custom SoC design for an IoT gateway SoC using Spec2Chip turnkey solutions.

It is important to mention that the implications of the Spec2Chip offerings outlined here extend far beyond IoT cloud, IoT edge, and IoT gateway devices. OEMs in other emerging technologies, such as deep learning, artificial intelligence, virtual reality, gaming and autonomous driving cars are benefitting from this Spec2Chip platform approach. Customers in these markets are collaborating with turnkey ASIC providers so they can scale back on, or even eliminate, the risks and loopholes of a lengthy chip design flow, and focus specifically on the core hardware differentiation IP and end application software that they bring to their innovation.

This book deliberately includes a great deal of data and references to real products. We want you to fully understand and appreciate the scope of the IoT ecosystem and the Spec2Chip platform approach that is fueling its expansion. The goal is for you to take this experience and knowledge and apply it to your personal or organizational design flow. Our sincere hope is that your ideas, combined with the proven design methodologies outlined here, will result in a technological advancement that contributes to the IoT universe and those who live within it.

You can register for the conference HERE. I hope to see you there!

Also read: 35 Semiconductor IP Companies Hold 2nd Annual Conference

December 7, 2017

High Calibre Development Keeps Mentor on Top of the Game

High Calibre Development Keeps Mentor on Top of the Game
by Tom Simon on 12-07-2017 at 12:00 pm
Categories: EDA, FinFET, Siemens EDA

One might be tempted to think that technology driven gains in computer performance might be enough to keep up with the needs of design and verification tools. We know that design complexity is increasing at a rate predicted by Moore’s Law. We also know that the performance of the computers used during IC development benefit from this same level of performance improvement. When I first started in EDA I made the analogy of a dragon chasing its tail – always close, but never quite able to catch up. However, the dragon always seemed close enough to make developing the next generation of hardware possible.

Stepping back and examining the issue more closely reveals well known issues, such as exploding design rule complexity. I have written before about the rapid increase in the thickness of DRM’s. The need for increased compute power necessary for design completion hits across the board. We see it in simulation, synthesis, place and route, etc. However perhaps the most heavily impacted area is physical design verification, aka DRC.

Many of us can remember the tectonic shift in DRC when flat checking became impractical. This is when after decades there was a move from Cadence’s Dracula to Mentor’s Calibre. Calibre effectively and reliably solved the issues surrounding hierarchical DRC and paved a new path forward that was absolutely necessary for design productivity. The holy grail of most verification tools is the overnight run. If a tool can run in 8 to 14 hours, the users can start a run, go home and come back the next day to analyze and correct issues.

As process nodes advanced, the requirements for physical verification exploded. The new requirements came from several distinct categories. Mentor has published a white paper recently that discusses each of these areas and describes the work and development effort necessary to deliver a total solution that makes physical optimization practical.

Some of the solutions are good old fashioned software development work. These include the addition of parallel processing and support for larger designs. Mentor does a lot of additional work on the algorithmic side to support faster operations. Some of these focus on handling hierarchy better, especially when it relates to metal fill. Anyone involved with nodes below 28nm knows how complex metal fill requirements have become. Calibre is used now to generate metal fill. Mentor has pushed out significant enhancements in fill generation. The white paper discusses how these enhancements and methodology changes enable much higher design throughput.

Other significant runtime improvements can be achieved through less obvious methods such as carefully writing rule decks. Two seemingly similar methods of performing a check can have vastly different runtimes. If specific knowledge is used in writing rule decks, overall runtimes can be lowered. We are long past the days where users write their own rule files. Today all the major foundries provide Calibre rule decks. Mentor has developed deep relationships with the major foundries and has, in conjunction with them, devised a process to ensure that all the supported rule decks use the most efficient methods. This requires early access and intimate cooperation between the Calibre team and the foundries.

More advanced nodes also come with completely new verification requirements. One such example is multi-patterning. Early on the foundries took care of this for their customers. However, as the process advanced from double to multiple patterning, the responsibility migrated to the physical layout teams. This is another area where Calibre has added support to ensure that customer designs are quickly and correctly completed.

In the Mentor White Paper there is discussion on the effort that Mentor expends adapting Calibre at each new process node and at the same time maintaining backwards compatibility, so that designs on nodes like 130nm or 90nm still obtain the same verification results. My observation is that Mentor is highly aware that the base tool needs to be reinvigorated at the same time as new performance features need to be added. Furthermore, none of it is useful without deep foundry relationships to anticipate the requirements for nodes that may be years away. Mentor is in an enviable position as it has the ability to work with foundries and their most advanced customers to ensure that support is ready prior to production release for each new node.

The Mentor paper entitled “Achieving Optimal Performance During Physical Verification” is a fascinating view into the work that is required to stay on top of meeting and exceeding the next generation needs for physical verification. The results that Calibre attains are a clear indication of the level of effort that Mentor dedicates to the overall process of enhancing and supporting their physical verification solution. I highly recommend reading the paper to get more detailed insights and to better understand how the whole solution works together.

December 7, 2017

Optimizing Return from your IP Portfolio

Optimizing Return from your IP Portfolio
by Bernard Murphy on 12-07-2017 at 7:00 am
Categories: Automotive, Consensia, EDA

Given that SoC design today is predicated on IP reuse, you would assume that processes to deliver, maintain and communicate status on reusable IP should be highly optimized. But that’s not necessarily the case, especially when so many design companies have consolidated, each brings its own IP libraries, design flows, license agreements and inevitably fragmented tribal knowledge about what works well, what doesn’t and under what circumstances.

This isn’t a hypothetical problem, Recently, a design group in the Asia arm of a design company purchased an interface IP for $750k; shortly after, the US branch of the same company purchased the same IP, also for $750k. Were they able to sort this out? I don’t know but buyers have responsibilities as much as sellers. If too much time passed, I’m guessing the vendor would feel completely justified in pushing back against requests for a refund (try getting a refund from Amazon or Expedia after a few weeks, based on a mistake you made).

Cases like that are eye-catching but I suspect the bigger losses are in more mundane areas. An important part of the value in an M&A is anticipated efficiencies and new markets opened thanks to sharing a larger pool of high-value IP. And yet I don’t think I’m alone in noticing that years after some completed mergers, more than a few design organizations are still struggling to broadly realize these supposed benefits. They certainly gained market share; efficiencies around IP are sometimes less clear. When sharing between organizations proves ineffective or inefficient, teams reinvent the wheel constantly, or spend more time adapting IP they thought would be drop-in, or they simply fail to exploit opportunities that should have delivered significant market advantage.

Some of the problem starts with the way we view IP, as an essentially static end-product of IP development. Of course you hope the functionality changes less frequently than circuitry unique to the current design, but there can be a lot more information about an IP, changing more frequently than the functionality – bugs filed and status, schedule for bug fixes, silicon experiences and measurements and who else is using and has used this IP and in what configurations. All of this is very dynamic information, critically important to any current user. And it all evolves as new releases appear and new information flows in. Another design went into a respin because of a problem on that same IP? I might want to know that. Or I’m depending on a critical fix, but that need wasn’t passed down to the IP developers or status wasn’t rolled back up to those who might need it. I might want to know that too.

A Consensia-sponsored survey of design teams’ problems with IP highlights these issues: #1 they spend too long looking for the exact IP they need (incomplete databases, inadequate documentation, …), #2 they don’t know if they are allowed to use the IP on their design (license issues, ITAR issues, discontinued support, …), #3 they didn’t know the IP they wanted was already available (so they built their own) and #4 they didn’t have a good measure of the quality of the IP (yeah it exists, but nobody has used it, or it has a history of working well in certain applications but not in your application).

None of this will be a surprise to any experienced design organization. Each has typically built up home-brewed flows to address at least some of these needs, based on different DDM, bug/defect tracking, release/testing frameworks and possibly some kind of lifecycle tracking. Which is great, but there’s no easy way to bring different flows together in a merger (which may be why many are still struggling years after the M&A). Brute-force consolidation is frequently impractical. This problem becomes even more challenging when you are working collaboratively on a design with a customer.

Consensia offers the DelphIP platform to address all these problems, at the enterprise level where it can benefit all business lines in an organization. This provides a common and centralized way to track status, history, restrictions, maturity/quality along with other characteristics that aren’t commonly represented in EDA/DDM/defect tracking views. It also sits on top of and communicates with existing DDM platforms, bridging between existing local flows and enterprise-level IP communication and management.

DelphIP also supports collaborative workspaces so you work effectively with a customer in support of their value-adds, without having to expose all the gory (and proprietary) details that go into producing a modern design. Which is something you may be required to consider if you are working in the automotive space, to name just one example. You can watch the Consensia webinar on DelpIP HERE.

December 6, 2017

Safety qualification for leading edge IP elements – presentation at REUSE 2017 in Santa Clara

Safety qualification for leading edge IP elements – presentation at REUSE 2017 in Santa Clara
by Tom Simon on 12-06-2017 at 12:00 pm
Categories: Automotive, Events, IP, Silicon Creations

To ensure the reliability of automotive electronics, standards like AEC-Q100 and ISO 26262 have helped tremendously. They have created rational and explicit steps for developing and testing the electronic systems that go into our cars. These are not some abstract future requirement for fully autonomous cars, rather they are needed for critical systems in almost all cars today. Modern cars use significant electronics for engine systems, as well as braking and numerous safety systems such as impact sensors and airbags.

It can be easy to understand how an airbag system might be documented and tested before use in a car design. However, it is important to realize that a sensor or actuator is really part of a larger network of devices, where the reliability of the entire system is critical. Within each of the elements we can find components that enable communication, such as a SERDES. With designs moving to 7nm, the complexity of designing a SERDES is becoming even more complicated. This is further compounded by the overlaying of safety requirements. Yet, no matter how difficult, these added requirements are essential.

As you have read in my writing before, a standard like ISO 26262 does not allow the certification of the pieces of a system. Instead the final completed system can be qualified once it is built and its application is fully defined. The smaller components are what are known as a safety element out of context. They can be built with the final system level qualification in mind, but they themselves can never be certified.

The question remains, how should a component such as a SERDES be designed and evaluated to ensure that it is suitable for inclusion in a system that will be qualified. Silicon Creations, a leader in analog IP development, will be speaking on this topic at the upcoming REUSE 2017 conference on December 14[SUP]th[/SUP] in Santa Clara. Andrew Cole, Vice President of Business Development at Silicon Creations will present a talk called “Developing 7nm IP for Safety Critical Automotive Applications”. In addition to talking about steps necessary for ISO 26262 qualification, he will talk about AEC-Q100 pre-qualification through testing of completed parts.

His talk will be held at 11:15 AM on December 14[SUP]th[/SUP]. If you would like to register for this event please go to the event website for more information on the full agenda and registration. During the event, there will be talks given by Samsung, Intel Arm and many other key players in the IP arena. The event looks like it will provide an informative day for those interested in developing systems that employ IP.