{"id":16521,"date":"2021-09-14T23:12:56","date_gmt":"2021-09-15T03:12:56","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/?p=16521"},"modified":"2026-03-27T08:47:20","modified_gmt":"2026-03-27T12:47:20","slug":"leave-the-house-with-a-clean-design","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/2021\/09\/14\/leave-the-house-with-a-clean-design\/","title":{"rendered":"Leave the House With a Clean Design"},"content":{"rendered":"\n
\n
\"\"
Fashion<\/figcaption><\/figure><\/div>\n\n\n\n

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\u2019t 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<\/em> 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 \u2013 in the context of the rest of this entry, when I say design, I mean digital hardware design. Clear?<\/p>\n<\/div><\/div>\n\n\n\n

\n

Moving on, I\u2019d 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 \u2013 sometimes spectacularly. We don\u2019t 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 \u2013 in the least it\u2019s annoying and at its worst the result is magnificently expensive in one of many possible ways.<\/p>\n<\/div><\/div>\n\n\n\n

\"The
A poor design resulting in a display not meeting the intent<\/figcaption><\/figure><\/div>\n\n\n\n
\n

So, remember, in this context bad design doesn\u2019t refer to bell-bottom pants, but digital hardware design that fails to meet its intended purpose. And make no mistake \u2013 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.<\/p>\n<\/div><\/div>\n\n\n\n

\n

The fashionable response to this over the years has been to invest more in verification. According to Wilson Research Group studies<\/a> 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\u2019t 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\u2019t misunderstand, I\u2019m not downplaying the importance of verification \u2013 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.<\/p>\n<\/div><\/div>\n\n\n\n

\"The
Could also be a neon striped shirt – also a bad design<\/figcaption><\/figure><\/div>\n\n\n\n

Unfortunately, the sordid tale of bad design doesn\u2019t end there. There\u2019s a whole class of issues that aren\u2019t reliably caught in verification. Think of these as the short-sleeve neon-striped dress shirt with the pocket protector, worn with<\/em> 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 \u2013 if not please reference the CDC content on Verification Academy<\/a>). Just like someone telling you that something is in style that you believe doesn\u2019t look good, (think \u2013 mixing plaids and stripes), don\u2019t listen to those who claim that it\u2019s possible to verify CDCs or RDCs in simulation, or that the design methodology is robust enough that CDC or RDC verification isn\u2019t required. History shows that it\u2019s \u201cgood enough\u201d until it isn\u2019t. Those same surveys<\/a> 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\u2019ve 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.<\/p>\n\n\n\n

Now let\u2019s 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\u2019t 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\u2019t 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\u2019s 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. <\/p>\n\n\n\n

Enter Questa Design Solutions<\/a>. With the introduction of Questa Lint<\/a>, brought together with Questa AutoCheck<\/a>, X-Check<\/a>, CDC<\/a>, RDC <\/a>and Signoff CDC<\/a>, Questa Design Solutions<\/a> 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<\/a>, but in the meantime let me elaborate.” Let\u2019s 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.<\/p>\n\n\n\n

\"Unclear\"
Can you please clarify? <\/figcaption><\/figure><\/div>\n\n\n\n

In the future, we\u2019ll 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<\/em>. 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<\/a> and Questa Lint<\/a>. By leveraging machine learning algorithms, as well as our deep understanding of the most common and challenging design issues, Questa Design Solutions<\/a>: <\/p>\n\n\n\n

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

    That\u2019s what we mean by actionable intent-focused insight<\/em>. 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.<\/p>\n\n\n\n

    \n
    \n
    \"Stop\"<\/figure><\/div>\n<\/div><\/div>\n<\/div><\/div>\n\n\n\n

    At this time, I\u2019d 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\u2019t it be great if there was something out there that wouldn\u2019t let you walk out the door \u201cdressed like that\u201d or would shop with you as you needed clothes for an important event? But I digress. I mean they wouldn\u2019t let you send bad designs downstream? Well, it\u2019s 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<\/a> 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. <\/p>\n\n\n\n

    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<\/a> and the tools within via the copious links that I’ve placed throughout this piece. Also, learn more about using Questa Design Solutions<\/a> and improving your RTL quality by watching our Improving Initial RTL Quality<\/a> webinar. Or contact your Siemens EDA account team for more details and an evaluation. <\/p>\n\n\n\n

    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.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Wouldn’t it be great if there were something that would stop you from leaving the house wearing mismatched clothes – I mean without a clean design? <\/p>\n","protected":false},"author":71585,"featured_media":16537,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[376,377,966,435,457,493,499,506,880,659,660,667,669,690,718,732,736,751,785,819,820],"industry":[53],"product":[205],"coauthors":[965],"class_list":["post-16521","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news","tag-cdc-analysis","tag-cdc-verification","tag-continuous-integration","tag-do-254","tag-emulation","tag-formal-verification","tag-fpga-prototyping","tag-functional-verification","tag-iso26262","tag-questa-cdc","tag-questa-cdc-fx","tag-questa-reset-check","tag-questa-signoff-cdc","tag-rtl","tag-simulation","tag-standards","tag-static-method","tag-systemverilog","tag-upf","tag-verification","tag-verification-academy","industry-electronics-semiconductors","product-questa"],"featured_image_url":"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2021\/09\/Stop300x600_original.jpeg","_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/16521","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/users\/71585"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/comments?post=16521"}],"version-history":[{"count":5,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/16521\/revisions"}],"predecessor-version":[{"id":16555,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/16521\/revisions\/16555"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/media\/16537"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/media?parent=16521"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/categories?post=16521"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/tags?post=16521"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/industry?post=16521"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/product?post=16521"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/coauthors?post=16521"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}