Thought Leadership

Leave the House With a Clean Design

By Chris Giles

Several years ago, I posted a job opening for a Design Engineer. To my surprise, a few of the responses I received were from individuals in the fashion industry, looking for a fashion design position. Apparently, I didn’t write the job description well enough. Actually, on second thought, I think I did but those fashion types who applied probably assumed that I mistakenly listed the job as microprocessor design and that the job really was about designing pants. But I digress. Design is admittedly a very vague word. It means a lot of things to a lot of people. So, let me be perfectly clear – in the context of the rest of this entry, when I say design, I mean digital hardware design. Clear?

Moving on, I’d like to propose that most of us know bad design when we see it. The Tacoma Narrows Bridge comes to mind. Or the 8-track tape. Or bell-bottom pants. But I digress. So, why do we know bad design when we see it? Probably because it fails to achieve its intended purpose – sometimes spectacularly. We don’t often notice good design because it just does what it’s supposed to do. We only really notice good design if it does what it is supposed to do exceptionally well! But bad design – in the least it’s annoying and at its worst the result is magnificently expensive in one of many possible ways.

The result of a bad design
A poor design resulting in a display not meeting the intent

So, remember, in this context bad design doesn’t refer to bell-bottom pants, but digital hardware design that fails to meet its intended purpose. And make no mistake – hardware designs don’t always achieve their intended purpose. When those failures are discovered in the field, the implications are severe. Even when those failures are discovered before a product gets in the field, they can be very expensive. Late issue discovery has certainly led to more than one canceled product over the years. Just think of all the fun gadgets we have never been able to use just because there were too many late-found bad design elements to keep it from getting to market. Drones flying near my head, instantly dispensing snacks as I need them, come to mind. But I digress.

The fashionable response to this over the years has been to invest more in verification. According to Wilson Research Group studies consistently taken every two years, the number of verification engineers on a development team exceeded the number of (do not insert fashion here) designers around 2015 and has continued since. Yet unfortunately those same surveys show that despite the increasing investment and focus on verification, the percentage of rework-causing problems that are functional in nature stayed the same. What didn’t stay the same was the cost of failure. Respins per ASIC project or FPGA design issues escaping into production increased from 2012 to 2020. With mask costs for ASICs increasing, and labor costs increasing over that time, the cost of functional issue escapes has only increased. Don’t misunderstand, I’m not downplaying the importance of verification – not by any means. It’s critical to success. But the fact is that we are investing more and more and losing ground. We need verification but we also need to do something different.

The result of a bad design
Could also be a neon striped shirt – also a bad design

Unfortunately, the sordid tale of bad design doesn’t end there. There’s a whole class of issues that aren’t reliably caught in verification. Think of these as the short-sleeve neon-striped dress shirt with the pocket protector, worn with the bell-bottom pants. These issues have to do with asynchronous clock domain crossings (CDCs) or asynchronous reset domain crossings (RDCs). (I am going to assume that you understand metastable behavior in flip-flops caused by changes on input signals too close to the change of the clock – if not please reference the CDC content on Verification Academy). Just like someone telling you that something is in style that you believe doesn’t look good, (think – mixing plaids and stripes), don’t listen to those who claim that it’s possible to verify CDCs or RDCs in simulation, or that the design methodology is robust enough that CDC or RDC verification isn’t required. History shows that it’s “good enough” until it isn’t. Those same surveys mentioned earlier identified that the percentage of issues causing errors to get into production in FPGAs, that are due to clocking, have increased from 2012 to 2020. The good news here is that on the ASIC side, they’ve decreased due to increased adoption of tools such as CDC verification. However, as I noted earlier, mask costs on ASICs continue to increase, offsetting those gains.

Now let’s talk about how teams build designs. In many cases, teams draw up the architecture, and then the microarchitecture, and then the block-level architectures and microarchitectures, and so on. At some point when the specs and high-level models are written, if there are separate teams, the verification team starts writing a testbench and the designers start designing. If there aren’t separate teams, the engineers design first, then verify later. Either way, design is happening in the dark without a way to test anything. So, designers either end up writing rudimentary testbenches to wiggle wires and check for a heartbeat (which is generally throw-away work) or they don’t test it at all, letting the code sit on a shelf waiting for that testbench. In modern times we sometimes also throw in the complexity of hardware/firmware co-design (meaning there’s a third team that is using the documentation and doing development in parallel), as well as additional emulation and prototyping work. Everyone needs the design to be as solid as possible as early as possible to get their part of the hard stuff underway. No one wants to see all this later-program work impacted unpredictably by bugs that could have been found during design creation. But the problem is the designer needs some sort of verification capability to meet that need. 

Enter Questa Design Solutions. With the introduction of Questa Lint, brought together with Questa AutoCheck, X-Check, CDC, RDC and Signoff CDC, Questa Design Solutions provide verification automation for designers, delivering integrated and actionable intent-focused insight from design creation through completion. I know what you’re thinking – “Gosh Chris that was a lot of words, that appear to be syntactically, semantically and structurally correct but what do they mean?” To which I say “Thank you for the excellent segue to Questa Lint, but in the meantime let me elaborate.” Let’s start with this: a designer can check that their designs are free of an entire class of common bugs that slow down or entirely restart development processes, without a testbench. More importantly, it means that this can be done in the most efficient way possible, in an environment that provides commonality across any analysis from simple static linting and design verification through formal analyses, formal verification and beyond to simulation-based verification. Consistent directives, constraint methodologies, issue disposition status flows, user interfaces and more allow the designer to find and fix issues quickly in an environment proven by over 20 years of successful customer design releases.

Can you please clarify?

In the future, we’ll get into more of the details behind the elements that make up this solution, but for now, let me expand on what we mean by actionable intent-focused insight. In my career in the (hardware) design industry, I once asked my team to use a linting solution on a design. While I believed in the value of linting, the results were so noisy that I felt a faster path to being done was finding and fixing issues through compilers and testbench bringup and debug. Regrettable, certainly, but there was far too much noise. That issue colored (not neon or striped, mind you) my view of that type of tool for years. Fortunately, this is not the issue with Questa Design Solutions and Questa Lint. By leveraging machine learning algorithms, as well as our deep understanding of the most common and challenging design issues, Questa Design Solutions:

  1. reports only the issues that need to be fixed in order of those that matter most
  2. analyzes against every issue known to provide results different than what we infer the designer’s intent to be,
  3. provides a broad range of visualization, metrics, and recommendations for every issue. 

That’s what we mean by actionable intent-focused insight. If the previous version of me had seen those kinds of results, I would have let lint do all the hard work and gone outside to play pickleball. But I digress.


At this time, I’d like to pause and thank the people in my life who taught me just enough about bad fashion to be able to write this piece. Wouldn’t it be great if there was something out there that wouldn’t let you walk out the door “dressed like that” or would shop with you as you needed clothes for an important event? But I digress. I mean they wouldn’t let you send bad designs downstream? Well, it’s an increasing trend in design to do just that. Particularly as hardware/firmware co-design increases where an expectation exists that hardware be developed under the same agile never-broken mechanism as firmware, or where industry standards or process improvement mechanisms require teams to ensure designs are clean before committed. Questa Design Solutions supports these continuous integration mechanisms, with tool integration, configurable design goals and methodologies that can either increase rigor as needed or hold them in place over time to monitor compliance and improvement. 

There’s a lot to cover here and I won’t ask you to read much further. I encourage you to learn more about Questa Design Solutions and the tools within via the copious links that I’ve placed throughout this piece. Also, learn more about using Questa Design Solutions and improving your RTL quality by watching our Improving Initial RTL Quality webinar. Or contact your Siemens EDA account team for more details and an evaluation.

On a final note, while writing this, I have come to realize that in the end those fashion designer types who applied for my position might have taught me something. While digital hardware design is, I would propose, technically much harder and the stakes much greater, there is something similar between the two. Neither industry really wants us to leave the house wearing bell-bottom pants and neon-striped short-sleeve dress shirts with a pocket protector. And your clothes look much better if you’ve used a good linting tool.

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at