"The problem is that hardware companies are much harder to build and scale than software companies."
— Marc Andreessen, 2013That quote has floated around Silicon Valley and the technology industry ever since it was uttered. Since its publishing you can find article after article discussing the challenges companies face when attempting to create physical products. As a hardware designer with a 10+ year career across industrial, defense, aerospace, and commercial applications I've found that the real challenge is that hardware projects rarely follow a predictable design pattern.
Aside from a select few early ones, every design project in my career has followed a predictable pattern regardless of the application. What is hard about hardware is maintaining the discipline to adhere to that pattern, and also the fact that hardware simply needs to work. You can't send a software patch to fix a missing pull-up resistor on a board in orbit.
I've developed boards that range in complexity from 4 layers to 32 layers. I've used Altium Designer and Mentor Graphics. I've even laid out a board in MS Visio. Over all of my experiences I've noticed a distinct pattern that the design flow follows that leads to high-quality designs made right the first time. Projects that I've worked on that have strayed from this pattern, or taken steps out of order, have almost universally operated with greater risk and gone over budget and over schedule.
The full details of each of these steps are application- and team-specific. But the general outline always holds true. Here's what it looks like in practice.
Start by getting a clear picture of the high-level system. Break it into smaller, manageable chunks. Define the performance requirements desired of those chunks, and establish how you'll verify that each one meets those requirements.
This process is the same for any project that produces a deliverable, and it's second nature to software teams working in agile environments. In hardware projects, this phase defines parameters such as BOM budget, trace length skew budget, bit error rate of high-speed interfaces, power budgets, and environmental requirements. It also defines how the customer expects the team to prove that the developed product meets these parameters using methods of verification (MOVs).
MOVs are critical for defining expectations and dedicating resources to each effort in the product development. They also help cross-collaboration by defining the scope of smaller chunks. Working on hardware without defining MOVs for performance capabilities is effectively like flying blind.
Choose components and board materials based on the performance parameters defined by the requirement specification. For example, if the board needs to have SERDES communications over 10G, an FR-4 dielectric may have too high of a dielectric constant (and cause too much loss) for the required bit error rate.
Switching bandwidth, power rails, logic compatibility, signal buffers, level shifters, external connectors, and the like are all derived from the requirements and can be selected at this stage. Parts selection also creates a feedback loop with material selection. The packages of the parts help a designer choose whether flex boards can be used, how thick the board can be, what types of vias will be allowed, and what size the board may be.
Most important to design success, make first contact with one or more PCB fabricators. Fab houses can help select the specific variation of materials to use and the manufacturing process of the bare board to ensure the design meets cost and performance criteria. Initiating work with a fab house later in the design only increases risk of costly rework.
Testing isn't something that only happens once the board is in the lab. Hardware designs, particularly ones that will go through multiple design iterations, must have their tests under consideration from the start.
Derive pre-layout simulations from part selection and performance requirements. Pre-layout simulations are commonly performed in HyperLynx LineSim, Ansys Nexxim, and LTSpice. You use pre-layout simulations to determine whether the requirements and system design are too restrictive or underdeveloped to meet performance and cost standards, before beginning design.
Pre-layout simulations define layout constraints. Post-layout simulations verify the pre-layout assumptions and simulation setups. Bench-top tests validate post-layout simulations. The pipeline of test from the system level to the bench top verifies not just the performance of the design itself but the process with which the design is validated.
This one is simple, but is often the most misunderstood. I have had program managers assume schematic capture is the process of developing a printed circuit board (PCB), and push to skip the previous steps in order to inform their customers that design has entered schematic capture.
In fact, the inverse of this understanding is true. If the design effort has followed this pattern in order and the previous steps have been defined to an adequate depth and the simulations and analyses thus far have been completed, schematic capture should be no more than an exercise of connecting the parts selected in step 2 and validated in step 3.
Constraint development is a two-step, iterative process that complements the simulation and verification in step 6.
Pull performance requirements from step one and performance data from pre-layout simulations to determine values that will be entered into your ECAD tool's constraint manager. Part placement, component requirements, and system requirements also play a factor here. For example, the physical body of a connector best defines the minimum clearance necessary for a trace from the connector — the mechanical process of installing the connector could damage a trace if routed beneath the component body.
This effort narrows the scope of pre-layout simulations by using the system design in a top-down approach. The constraints developed in this step ensure that your design is compatible with other portions of the system and set bounds on your simulation. Without setting these bounds you're effectively designing in a vacuum, and your pre-layout simulation results won't look anything like real-world performance when your design is integrated into the system.
Pre-layout simulations involve running parameter sweeps over much of the physical portions of the board. It's in this phase that you dial in your trace widths and spacings. Field solvers can be used to simulate potential sources of crosstalk. Vias can be modeled and the effect of too many vias or impedance discontinuities on the quality of the signal can be quantified. These pre-layout simulations will define much of the bounds of your layout constraints.
The system constraints determined in step 5 act as a starting point for these simulations. Iterated simulations will narrow the constraints even further by taking physical parameters, IBIS models, and S-parameters into account. This process gives you margin for performance and manufacturing. No two boards are manufactured exactly the same and the margin helps ensure your board remains in the desired operating window despite these variations in manufacturing that are out of your control.
Similar to step 4, if the constraints are well defined and physical properties are sufficiently simulated, layout is mostly an exercise in connecting the dots and passing the design rule checker (DRC) inspection.
My preference, when possible, is to perform at least two layout passes. The first pass is laying out the board as quickly as possible, without getting stuck in analysis paralysis. Then I typically erase the entire layout, whether I like what I've done or not. On the second pass, I use what I've learned from the first to produce what is typically a much better result.
This step involves reviewing the entire development pipeline to this point. It's often where teams will include a phase gate that requires other engineers to review your work. Before handing a layout off for review, perform a thorough visual inspection of your board. Assume that you have under-constrained your design and that there may still be issues like acute angles in trace routing, clearances that are too small when viewed in 3D, or not enough clearance between parts for test tools like oscilloscope probes.
This is the first time during design where you have a full picture of the design and can consider it as a tangible asset that you may get to work with on the bench. Consider manufacturing and tooling processes. Try to refine your design to make it easy to make and test. Failing to make these considerations at this stage may make some tests impossible when the board finally makes it to the bench.
Beyond this, the DRC will validate the layout.
The test plan defines what post-layout tests are critical to meeting design requirements. For the most part, this is an exercise in running post-layout simulations that mimic the pre-layout simulations and prove out that the defined constraints provide the expected performance observed in pre-layout simulation.
When you get the board back from the fab house, a comprehensive test plan should validate the performance observed in pre- and post-layout simulations. This validates the development pipeline and the tool configurations.
This step also includes functional validation. At this point you can be confident that the board is of high quality and can begin exploring the limits of performance and developing errata for the next design iteration.
Following this pattern will ensure a predictable design flow that will make organizing design information, drawings, and test results much simpler. As an added benefit, it provides program managers digestible design phases they can translate to stakeholders, which they will greatly appreciate.
By following this process I was able to effectively perform the layout of a 32-layer board in Microsoft Visio. I literally routed connectors between hand-placed connection points on shapes that represented connector pins. When I handed off my design package to the layout engineer, I already knew my spacings were achievable, that my critical communication channels would be balanced in their trace lengths, and that the design was achievable within the designed stack-up.