In late March, Brian Bailey of Semiconductor Engineering published an article on standards: “Design by Architect or Committee?” This made me think of my own experience with the Accellera Unified Coverage Interoperability Standard (UCIS), something of which I am both proud and embarrassed. Proud, because when I was at Mentor Graphics I was the architect of the winning donation, and that’s a rare thing in any career — to contribute the design and architecture for an industry standard. However, I am embarrassed because I know I could have done better in a re-design. Any software engineer will tell you this: the second design is always better, because you’ve learned from the first. We did some re-design as part of the standardization effort, but not to the degree I wanted. (more…)
Archive for April, 2015
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? (more…)
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.
In a recent blog, Does Your Synthesis Code Play Well With Others?, I explored some of the requirements for verifying the quality of the RTL code generated by high-level synthesis (HLS) tools. At a minimum, a state-of-the-art lint tool should be used to ensure that there are no issues with the generated code. Results can be achieved in minutes, if not seconds for generated blocks.
What else can be done to ensure the quality of the generated RTL code? For functional verification, an autoformal tools, like Real Intent’s Ascent IIV product can be used to ensure that basic operation is correct. The IIV tools will automatically generate sequences and detect whether incorrect or undesirable behavior can occur. Here is a quick list of what IIV can catch in the generated code:
- FSM deadlocks and unreachable states
- Bus contention and floating busses
- Full- and Parallel-case pragma violations
- Array bounds
- Constant RTL expressions, nets & state vector bits
- Dead code
Designers are are also concerned about the resettability of their designs and if they power-up into a known good state. (more…)
The story of “David and Goliath” from the book of Samuel, has taken on a secular meaning of describing any underdog situation, a contest where a smaller, weaker opponent faces a much bigger, stronger adversary. Not just in EDA, but all companies in different technology industries deal with this struggle.
Organizations have moved from “build once, last forever” to “build fast and improve faster” approach to meet the dynamic requirements of their customers. In order to scale, evolve and respond, companies are choosing between two business philosophies. One which focuses on building larger, process driven yet efficient organizations and the other on smaller more efficient teams.
The panel discussion “The paradox of leadership: Incremental approach to Big Ideas ” at the recent Confluence 2015 conference addressed this question. It explored the pros and cons of each of these philosophies and tried to gauge if there is a preferred way to creating success as part of the conference theme: “Building the Technology Organizations of Tomorrow.” In my previous blog, Billion Dollar Unicorns, I discussed which companies were leading innovators, but the question remains: how do companies get there? (more…)