April 23rd, 2015
DO-254 Without Tears
April 23, 2015 by Dr. Pranav Ashar
This article was originally published on TechDesignForums and is reproduced here by permission.
At first glance the DO-254 aviation standard, ‘Design Assurance Guideline for Airborne Electronic Hardware’, seems daunting. It defines design and verification flows tightly with regard to both implementation and traceability.
Here’s an example of the granularity within the standard: a sizeable block addresses how you write state machines, the coding style you use and the conformity of those state machines to that style.
This kind of stylistic, lower-level semantic requirement – and there are many within DO-254 – makes design managers stop and think. So it should. The standard is focused on aviation’s safety-critical demands, assessing the hardware design’s execution and functionality in appropriate depth right up to the consequences of a catastrophic failure.
Nevertheless, one pervasive and understandable concern has been the degree to which such a tightly-drawn standard will impact on and be compatible with established flows. This particularly goes for new entrants in avionics and its related markets.
Your company has a certain way of doing things so you inevitably wonder how easily that can be adapted and extended to meet the requirements of DO-254… or will a painful and expensive rethink be necessary? Can we realistically do this?
OK, Google: A Man and His Watch
April 23, 2015 by Peggy Aycinena
I’ve got a friend who received an Android Wear (read “watch”) as a gift earlier this year. In the last several months, he’s become addicted to wearing the darn thing although its usefulness is distinctly limited: He can check the time and screen calls without digging a phone out of his pocket. Oh yeah, and when messages and/or emails come in, he knows straightaway.
Other than being a fascinating toy, however, and something to diddle with – particularly for those who like the openness of Android – Wear is really not much more than a distinctive fashion statement and not too much of that.
Nonetheless, now that Apple’s claiming more stupendous success with yet another highly over-hyped product launch (read, “the Apple Watch”), it’s time to re-consider the importance, even gravitas, of this Android Wear thing. After all, let’s not just lay down in the road and let Apple run over us yet again. Let’s cheer on these Android Wear users. Let’s celebrate anybody willing to stand up to the Apple juggernaut. Yay!
Perhaps the biggest cliche in EDA is that functional verification consumes 70% of a chip project’s resources and is growing. Variations on this statistic have been around for at least ten years, probably more. It’s quoted almost as much as Moore’s Law, which incidentally turned 50 this year. Although not as old, the observation that verification dominates SoC development is almost universally accepted. Some may argue the exact percentage, but the spirit remains the same. As a consequence of this state, verification content is turning up everywhere. In today’s post, I’d like to summarize some recent and upcoming events of interest, plus remind you of some related topics covered in previous posts.
My first updates involves DVClub, the informal gathering of verification professionals held in multiple locations around the world. Yesterday was DVClub Silicon Valley, held as usual at Dave & Buster’s mega-arcade in Milpitas. Olig Petlin presented “Formal property verification at AMD: Theory and Practice” to a good-sized crowd. The talk was a nice, comprehensive overview of formal analysis and how it is typically deployed, but I would have liked to hear more specifics about AMD uses it on their projects. Paradigm Works recently assumed management of DVClub in the USA and is doing an excellent job of reinvigorating the franchise with more events in more locations. Boston on May 13 and Austin on June 3 are next on the calendar.
If there’s something missing in your personal or professional knowledge of Moore’s Law, you should have spent 5 hours at the Computer History Museum in Mountain View on April 17, 2015, although even then you might not have learned anything new. For people in technology, seriously, what more is there to know?
The ‘law’, penned by Gordon Moore and published in an Electronics article on April 19, 1965, was based on his many years’ experience in the nascent-to-ferocious semiconductor industry, and has since been interpreted, re-interpreted, mis-interpreted, and zealously lionized – both the law and the man – over the last 50 years. Which brings us back to April 17th and the 3-part program at the CHM.
Times are good in EDA. 2014 was a record revenue year for our industry, according to an April 13 EDAC announcement. Several technology areas (IC physical design and semiconductor IP) and geographies (the Americas and Asia-Pacific) experienced double digit growth in Q4. The number of people working in EDA is on the rise, too: a total of 31,735 employees at companies EDAC tracks in Q4 2014, compared to 29,880 employees a year earlier. This rising tide is lifting all boats — including #52DAC, which I invite you to register for today if you haven’t already.
How to use VIPs In Practice
Let’s assume that we are designing a new system on chip (SoC) which contains a processor and memory controller, as well as analog and digital peripherals like Ethernet, USB, 1-Wire and JTAG controllers.
Allow me to describe a typical verification process, and explain why I recommend the use of Verification IPs within the testing process.
Figure 1. Typical verification process
Thanks to the widespread reuse of intellectual property (IP) blocks and the difficulty of distributing a system-wide clock across an entire device, today’s system-on-chip (SoC) designs use a large number of clock domains that run asynchronously to each other. A design involving hundreds of millions of transistors can easily incorporate 50 or more clock domains and hundreds of thousands of signals that cross between them.
Although the use of smaller individual clock domains helps improve verification of subsystems apart from the context of the full SoC, the checks required to ensure that the full SoC meets its timing constraints have become increasingly time consuming.
Signals involved in clock domain crossing (CDC), for example where a flip-flip driven by one clock signal feeds data to a flop driven by a different clock signal raise the potential issue of metastability and data loss. Tools based on static verification technology exist to perform CDC checks and recommend the inclusion of more robust synchronizers or other changes to remove the risk of metastability and data loss.
You are registered as: [_EMAIL_].
CafeNews is a service for EDA professionals. EDACafe.com respects your online time and Internet privacy. Edit or Change my newsletter's profile details. Unsubscribe me from this newsletter.
Copyright © 2016, Internet Business Systems, Inc. — 595 Millich Dr., Suite 216 Campbell, CA 95008 — +1 (408)-337-6870 — All rights reserved.