Hardware does not forgive assumptions. Challenging common misconceptions, exposing real design mistakes, and following disciplined design practices can prevent costly PCB re-spins.
We will explore the real challenges in hardware design and what it takes to get a board working correctly the first time. A common belief in the industry is that the first PCB will never work and that a second or even third revision is inevitable. Many engineers openly admit that; even before completing their first design, they expect a re-spin. This mindset has become commonplace, and it is exactly what we need to question.
The aim is to challenge that assumption and focus on a few fundamental practices that can significantly improve the chances of getting a design right the first time. To keep this engaging, we are joined by our very own Mr PCB, who will stay with us throughout and share practical design insights on the decisions that matter most.
Role of a hardware design engineer
Let us first understand who a hardware engineer or a hardware design engineer really is. Often, we imagine a hardware engineer as someone sitting at a desk in front of a PC, surrounded by messy wires, PCBs, and a soldering station. While that image is familiar, it is not the complete picture. A hardware engineer is primarily responsible for the following:
Collecting and understanding requirements
This includes gathering requirements from multiple teams, such as the systems team, mechanical team, software team, testing team, and sourcing team. Hardware engineers work closely with many cross-functional teams and must clearly understand inputs from all of them. Under this responsibility, the hardware engineer also:
- Creates a system architecture to meet and fulfil system requirements
- Performs component selection, which is a critical task since every system depends on the right choice of components based on functionality, availability, and constraints
Performing analysis and simulations
Once requirements and components are defined, the hardware engineer performs analysis and simulations for the system or hardware being developed. Under this responsibility, the hardware engineer also:
- Creates schematics and PCB layout
- Creates required documentation throughout the hardware design lifecycle, starting from requirement collection to having a PCB in hand, and eventually taking the product to market
- Creates test plans
- Executes test plans effectively
Let’s look at examples of how improper test plans can negatively impact product time to market. All of this work happens while closely collaborating with cross-functional teams. Hardware design engineers interact with mechanical teams for PCB dimensions and connector placement, software teams for firmware readiness, sourcing teams for component availability and cost, business development teams to meet cost constraints, and testing and product validation teams. In practice, hardware engineers tend to work with more teams than most other roles.
In addition to all of this, one of the most important responsibilities of a hardware engineer is reading datasheets. This is critical and unavoidable. There are no shortcuts here. Without thoroughly understanding datasheets, nothing else can move forward.
The first time, the right approach
Hardware engineers do not have an undo button. Unlike firmware, where code can be changed and retried, hardware mistakes remain until they are physically fixed. If something is wrong, it cannot be reversed instantly. Even identifying the problem takes time. Issues are rarely obvious. Engineers must probe, debug, remove components, and solder them back. This process is slow, manual, and uncertain. Fixing one issue does not guarantee that others are not hiding. Every problem must be found and resolved before moving forward.
As a result, hardware development cycles stretch quickly. Once an issue is discovered, the design must be updated, components re-sourced, PCBs fabricated, assembled, and tested again. The cycle effectively restarts. This drives up development time, delays time to market, impacts the business, causes financial loss, and increases pressure on management.
The key requirements to avoid these challenges are:
Collect requirements from all stakeholders
Hardware engineers work with the maximum number of cross-functional teams. Requirements must be gathered from mechanical, hardware, software, testing, and validation teams. Inputs from all these teams must be incorporated into the design.
Understand requirements to the finest details
It is not enough to broadly define a system and select components. Every requirement must be deeply understood. For example, wake-up over CAN is a common requirement today. It may sound simple, but it is not achieved by just connecting a CAN IC to a microcontroller. Each microcontroller behaves differently, and wake-up functionality may only be available on specific pins. Many engineers miss this detail and later discover that the selected CAN RX pin does not support wake-up from low power mode, forcing a redesign and another PCB iteration. Similar fine details exist in power management, under-voltage lockout, and other system-level features, and these must be thoroughly studied and understood.
Sign-off requirements from all stakeholders
After analysing requirements, discussions must happen if there are challenges. Final requirements must be formally signed off by all teams. This is critical. Without a sign-off, teams may later claim that certain requirements were communicated but not implemented. Signed off requirements avoid conflicts, save time, and ensure accountability. Once signed off, there is no ambiguity.
Freeze requirements and stop accepting changes
At some point, requirement changes must stop. Accepting new requirements every day disrupts the design process. After sign-off, only critical changes should be considered, and their impact on timelines and design effort must be clearly communicated. Changes should be accepted only if all stakeholders agree to the consequences. Freezing requirements are essential to move forward and complete the design efficiently.
How to create a system architecture
Once all requirements are gathered, the next step is to create the system architecture.
Hardware design architecture
The system architecture must be detailed and must capture every functionality defined in the requirements. Using simple elements such as rectangles, lines, and text, the objective is to translate requirements into a clear and comprehensive architectural representation.
What is often mistaken for architecture is actually just a block diagram. A few blocks connected by lines do not represent a true architecture because they lack detail. A proper architecture includes fine-level details and clearly reflects all system requirements, interfaces, and interactions.
A detailed architecture diagram is extremely useful because requirements are usually scattered across multiple documents, often Excel sheets stored in different locations. In contrast, the architecture diagram can be integrated directly into the CAD tool being used, such as OrCAD or Altium, and can serve as the front page of the design documentation. This allows designers to quickly see what has been implemented and what is still pending. By carefully translating every requirement from various documents into the architecture diagram, a single visual reference is created, improving clarity and ensuring nothing is missed.
Time planning
Once the requirements are frozen, that is where the timeline begins. I break the architecture into smaller functional blocks and estimate the time required for each one. This may include the power supply section, the microcontroller section, or any other functional block. Effort is typically estimated in hours, for example, four or five hours per block.
Based on these estimates, a consolidated plan is created that defines the total project effort, say around seventy hours. Whether eight hours a day are spent working or more is secondary. What matters is having a realistic and structured timeline. Time for reading datasheets is always included and cannot be skipped. Without a proper datasheet study, there is no design, and every necessary activity must be part of the schedule.
Once the plan is defined, it must be followed. If specific tasks are committed for a given day, they must be completed. If the schedule slips, delays compound and critical details get missed. I also keep the project manager or reporting manager regularly updated. During the design phase, there may be dependencies on inputs from other teams. When that happens, it is communicated immediately along with the impact on the timeline. If a day is lost waiting for information, the plan is formally updated. A timeline is not a one-time exercise. It must be tracked and updated continuously to remain effective.
Component selection
Component selection starts early. Even before creating the architecture, some components may already be shortlisted, and in many cases, the architecture itself is built around those choices. Component selection usually continues until the design is frozen, and some changes as requirements evolve are normal.
I make it a point to explore components extensively. This means regularly visiting semiconductor vendor websites and reviewing their portfolios. There are many vendors in the ecosystem, and they continuously introduce new solutions. Limiting selection to a single product or vendor reduces design flexibility. Exploring available devices helps identify components that meet system requirements more efficiently.
In many cases, a function that appears to require multiple components can be implemented using a single integrated IC, reducing system complexity. Once a component is selected, the datasheet must be read thoroughly. This step cannot be skipped.
A real example highlights why this matters. A team had already shipped a system to an OEM, and out of four thousand units, one unit failed in the field. When the unit was returned and analysed, it was found that the selected component used an internal clock with an accuracy of plus or minus ten per cent. This clock was used to service the watchdog.
The watchdog window was defined as one thousand milliseconds, with a closed window of five hundred milliseconds and an open window of five hundred milliseconds. The watchdog was serviced at five hundred and ten milliseconds, just after the open window began. Most units worked fine, but one failed in the field. The solution was to service the watchdog at five hundred sixty milliseconds instead, after which the microcontroller stopped resetting.
The root cause was clearly documented in the datasheet. With a clock accuracy of plus or minus ten per cent, a five-hundred-millisecond window has a tolerance of fifty milliseconds on either side. This means the open window could start as early as four hundred fifty milliseconds or as late as five hundred fifty milliseconds. This detail was explicitly mentioned in the watchdog section of the datasheet, but was overlooked by both the hardware and software teams.
Because of this oversight, the team had to explain the issue to the customer, leading to unnecessary delays and blame shifting. The lesson is simple. To be a good hardware engineer, the datasheet must be read thoroughly, along with application notes and reference manuals.
When to simulate and how to analyse
Oops! This is an EFY++ article, which means it's our Premium Content. You need to be a Registered User of our website to read its complete content.
Good News: You can register to our website for FREE! REGISTER NOW
Already a registered member? If YES, then simply login to you account below. (TIP: Use 'forgot password' feature and reset and save your new password in your browser, if you forgot the last one!)
