Resistance to Schematic and Layout Review


The team lead or line manager enters the room and calls a department meeting or a design review session. Suddenly, almost everyone on the team starts mumbling or reacting with groans.

You’ve probably all experienced this situation. As a hardware guy, you have little tolerance for interruption, especially for long and tedious meetings that impede your productivity. The idea of having to sit and listen to other people discussing a blurry projected schematic, or working through a printed PDF booklet just so that your design-challenged colleague at the other end of the room can find out what he’s doing wrong, can be really upsetting.

The concept of design review has been around for a long time. Everyone knows the value of double-, even triple-checking your work (think back to elementary school). Every discipline has worked out a formal or informal collaborative process for checking and validating work: Writers have editors, accountants have auditors, and software engineers came up with pair programming a decade ago.

Software’s got it right.

There used to be a time when the conceptual design phase for software development lasted much longer than it does today. But it eventually became widely recognized that the static, non-iterative model of development (school teachers call it the waterfall model) was not effective in producing quality products on a competitive schedule.

So software development evolved to what it is today: agile and iterative. Its rapidly-changing nature creates continuous opportunities where peer code review is valuable and necessary for quality results.

In the same light, regular peer schematic and layout reviews should be seen as a logical component in the hardware development process. Some direct benefits to incremental design review include:

  • Fewer defects and errors in final design
  • More errors caught early on when they’re cheaper to fix
  • Improved communication and knowledge about design content (bus factor)
  • Mentorship of junior members of the team

And some longer-term, indirect benefits:

  • Lower number of revisions & re-spins
  • Faster time-to-market
  • Less time spent on debugging

Egos, isolationists and crappy toolsets.

Reading those lists of benefits, it should be a no-brainer to implement design review into the development cycle of every project. And yet, many hardware companies still don’t have peer review as a regular and mandatory part of their design process. Why? There are two very straightforward answers when you dig into the basics of human psychology.

  1. Ego
  2. Outdated reviewing methods

Let’s start with ego. We’re talking about hardware engineers right now but this applies to a vast majority of people at their workplace. We naturally feel like our work is an extension of ourselves. Someone judging our work is like having them judging us.. Two different types of people/engineers emerge at this point: The first class consists of collaborators, team players, and those who see it as constructive. When confronted with a problem they can’t solve, they will naturally turn towards a peer who knows the answer. For these guys, peer review is a beneficial process.

The second class is made up of isolationists. When confronted with a problem they can’t solve, they would rather unproductively try to find a workaround for hours (even days) rather than reach out to their peers for help. These guys can’t admit that someone else may know something they don’t.

Attitude over aptitude

In 2002, it was reported that the average career in high-tech lasts around 8 years. The isolationists are doomed for a shorter one, as their body of knowledge exclusively lies in what they are able to figure out on their own.

Overinflated egos can’t be good team players because their faculty to share with and learn from others is impaired. On the other hand, collaborators showing a continuous interest in learning will increase and sharpen their skills, remaining productive (and employable) in a constantly-changing field.

Design review can be painless.

Reviewing hardware designs has not been commonly included in the standard development cycle in a majority of companies for another reason: The tools are not adapted. PDFs, projectors, meeting rooms and highlighters are completely outdated ways of reviewing design. Back-and-forth email threads and over-the-shoulder methods are also inefficient and a waste of time. The key is to introduce a technique which allow each member to contribute to a review when they’re focused and willing to do it. It also shouldn’t include an archaic, middle-step that slows down the execution of fixes.

If you’re thinking about implementing an efficient design review process within your team, let us know. We’re happy to help. There’s no longer an excuse to not review designs!

How to be a better EE #1: Design Review


At Upverter, we love talking to hardware engineers and learning about how their teams review schematics. It seems that everyone has put together their own unique method:
from buying large-format printers and printing everything out on 11″x17″ paper, to long email threads in Outlook; running WebEx conferences to making PDF bookmarks.

Despite the variations in workflow, most of them agree that 2 of the most important factors in finding errors are:

  • How thorough you are
  • How experienced you are

We know everyone is crunched for time and usually isn’t as meticulous as they’d like to be. We also know that gaining experience often comes from mistakes: making them yourself or learning from the ones your colleagues have made.

If you’re new to reviewing schematic (or have simply been neglecting it), here are some general guidelines to help you become an effective reviewer.

    1. Read the datasheet of each component! It sounds so obvious, right? You’d be surprised at how many reviewers skip this. This is one of the most valuable things you can do. Read the datasheet, understand how the part functions, how each pin should be connected, and then check the schematic. With practice you’ll become an expert at reading datasheets quickly and figuring out which parts are important for schematic review. It’s not as daunting (or time-consuming) as you might think.
    2. Collect all the supplemental documentation on the vendor’s site. Look for reference designs, evaluation boards, application notes, layout guidelines, etc. Then quickly compare your schematic against each of these documents. Any differences might signal a mistake. This is a fast way to check connectivity with confidence.
    3. Leverage the vendor’s field application engineers. FAEs are often very knowledgeable on how their vendor’s components can be used in a design. Send them your schematic and they’ll be happy to review it for you. They often have their own internal checklist for this purpose.
    4. Create a culture of asking questions. Why is this connected this way? Why did you choose this part? How do you plan on dealing with X? When someone verbally walks through something, it often triggers important things that they hadn’t considered before. You’ve probably experienced this phenomenon yourself. There’s a ton of value in not only knowing the answer, but in this associative way of thinking.
    5. Share “lessons learned” with each other. Create a communal list of errors you’ve found on previous boards. Review this list before looking at a schematic (or designing one from scratch!) to remind yourself of things to watch out for. Have your senior engineers get this list started.
    6. Review the schematic in small chunks as it’s being designed. Many engineers don’t have the time to be thorough when faced with a giant schematic. It can be a daunting and a stressful process. Instead, consider sending out a small piece of the schematic every few days during the design process. This way reviewers are only faced with one circuit or component. It’s not only more manageable, but also an enjoyable way for engineers to familiarize themselves with the overall design as it comes together. They’ll be much more prepared for the big review at the end.

While some of these guidelines might seem obvious and basic, it’s important to build on a good foundation of reviewing schematics. There are simply no shortcuts. Once you incorporate these steps into your work and process, it will be loads easier (and faster) to prevent errors from actually becoming a problem.

Stay tuned for a checklist of specific circuit errors to watch out for.

4 Reasons to do a Better Job at Design Review

On this blog, we often point out analogies between hardware and software development. Here’s one such analogy: just as it has become easier to write software thanks to technology, behavioural evolution, and better processes, new tools have appeared that make it easier for hardware engineers to design better devices.In this post, we want to talk about one of these tools: schematic and layout design review. Design review is code review for hardware. It is the stage in the design cycle when one’s work is peer-reviewed for errors.

We were curious to know how companies implemented their design review process and what tools they used to achieve it. So we ran a survey over the last few weeks and talked to 400 engineers worldwide from all over the spectrum: big firms, startups, medium-size businesses, and so on. Surprisingly, we realized that in the era of advanced technology the most commonly used tools for design review were… highlighters, red pens, printed PDFs, and meeting rooms. One of the most elaborate devices used to complete design review must have been a projector or a laser pointer. Nothing really innovative there!

Having reflected on the survey, we came to the following conclusions.

1 – You already know the value of design review

Drawing a schematic is basically an exercise in carefully reading datasheets, app notes, and reference designs to learn how to best connect up each component for your application. This is in addition to all of the work involved in developing the top-level architecture for your board and selecting components to meet the product requirements. Each of these steps is an opportunity to make a mistake.

Every seasoned hardware engineer has had the experience of spending many frustrating hours debugging something on their prototype only to discover the root cause was a careless error in the schematic or layout that should have been caught earlier. This results in wasted time, a costly board spin, or worse, being completely blocked from testing a particular part of your board. Every hardware engineer knows that after spending many weeks working on the same schematic you’re simply unable to see errors any more. You need a fresh set of eyes to take a look. This is what design review delivers.

2 – There are all sorts of reasons that people fail at design review.

It’s well-known that design review isn’t done effectively right now. 75% of the engineers we spoke with told us they are well aware that they needed to do a better job at design review. Similarly, 71% of our beloved guinea-pigs described their process as ‘inefficient’, 23% found it truly ‘painful’, and only 6% were happy with their current tools and processes. The interesting question is why this is the case.

Our survey has revealed that: In order to really add value via design review you have to understand the product requirements, carefully read all of the datasheets/app notes/reference designs, understand what the designer is trying to accomplish, and then look for errors. If you don’t read the datasheets and get into the mind of the designer, you don’t add much value because then you’re only able to find the really obvious mistakes (like a power pin being unconnected), which are much less likely to be present. Design review requires you to spend a certain minimum amount of time which can easily be a few days for complex designs.

To that end a colleague is often asked to look at the design at the very end of the process, making the design appear large and daunting. As a result, the colleague, who is very busy him or herself, feels rushed and simply skims over the design and datasheets. They may not thoroughly focus on each section. Often the team culture doesn’t accept, nor encourage, an engineer to dedicate a few consecutive days to design review.

Another familiar scenario is a designer completing a schematic, sending it out to the team for review, scheduling a meeting with everyone a few days later, and everyone showing up to the meeting without having looked at the schematic! Everyone expected to talk about the design as a team. This approach is not as valuable. With layout it’s even worse. A completed layout, especially one with 8+ layers, can be so complicated that’s it’s too daunting and difficult to review all at once at the end. Finally, a lack of tools to streamline the process is the most prominent reason that companies skip design review or is the most likely reason for why they fail at design review (think back to those red pens and meeting rooms).

3- Design review shouldn’t be a separate task in the design cycle.

The best way to do design review, in our humble opinion, is to set up an incremental design review process. A short review should be done after each component (or small group of components) is placed on the schematic or layout and is mostly connected. This task is much more manageable for busy engineers. It may only take 1 hour or less to go over the datasheet and check for mistakes. It lets engineers ask questions early about design decisions. And best of all, when the design is finished and ready for final review, all team members are already familiar with every part of the design and will be much more effective at reviewing. In other words, we suggest distributing the review time throughout the design process instead of doing it all at the end. To dig into the analogy with software development, can you imagine writing an entire application and reviewing the whole code base at the end? This wouldn’t make much sense. And the claim that incremental design review works is not just a hypothesis: 97% of companies that implemented an incremental design review process in their standard design cycle found more defects on average than teams that did not. Even better, 72% had one less board revision.

Incremental design review needs to be instilled in the team culture. Managers need to foster an environment where mistakes are okay. Engineers shouldn’t feel uncomfortable putting their work up for incremental review. There needs to be a very supportive team culture where it’s understood that the primary goal is to create the best product possible and become better designers along the way. Mistakes should be celebrated (as long as they’re only made once) because you learn something really important with each mistake.

4 – Current design review tools may as well be from the Middle Age

Ok, this one may be a bit extreme but… red pens, and (non 3D) printed PDFs are probably the most inefficient tools to achieve a proper design review. Why? Because if you annotate and comment on printed PDFs then it’s likely that one poor dude will have to go back and fix all the defects. And he’s probably going to get several copies of the design with different issues pointed on each of them. Then he’s supposed to summarize all of it and adjust the design with as little delay as possible. With this approach, how do you understand design decisions? How do you keep track of what remains to be fixed? How does someone other than the overwhelmed designated-victim assess the project status and define an ETA?

But don’t panic, it is definitely not your fault. Nor your manager’s. There are currently no good tools for design review especially if you want to do incremental design review. Actually, that’s not true: there is now one tool to do this. Its called Upverter. But this is not the right time or place to talk about this 🙂

Design Review is Live

design review

Here at Upverter we have had enough of printing out designs and using highlighters to do design review. So we built design review into our tools!

You can take a look at Public Designs Reviews to see best practices that are being suggested with other people’s designs. If you would like get a design reviewed or would like to flex your expert electronics knowledge, take a look the Community Review List.

I added two of my designs up for public review, and it would be great if I got some feedback on them. So go over and give the review tool a try and drop some knowledge on me at the same time!

Have suggestions or feedback on design review (or the tool in general)? Let us know at