High-quality hardware design, part 2: guaranteeing specifications

High-quality hardware design: how do you achieve it? We discussed the first part, the definition phase, in an earlier blog. In the second part, we focus on the next phase of hardware design in product development: guaranteeing specifications. Using our own process, we explain how you can ensure that hardware requirements arising from the system architecture are translated into a high-quality design.

High-quality hardware design: how do you achieve it? We discussed the first part, the definition phase, in an earlier blog. In the second part, we focus on the next phase of hardware design in product development: guaranteeing specifications. Using our own process, we explain how you can ensure that hardware requirements arising from the system architecture are translated into a high-quality design.

A high level hardware design

The first step is to create a high level hardware design. You use traceability from engineering requirements to design decisions. This way you ensure that the design meets all engineering requirements. The design is assessed both internally and externally. Because this is the most creative part of the hardware development process, you want to start the feedback cycle as early in the process as possible.

Draw up detailed design and schedules

Then the detailed design and schedules can be drawn up. Again, this is not a ‘big-bang’ approach. It is an iterative process with a lot of internal feedback between the engineers. It starts by discussing how a circuit works and ends with a formal review of the schematic. We use the Altium 365 ecosystem for the review process. This makes it possible to place comments and tasks directly in the schedule. For this review and every comment or task we use this flow:

To do

New comment/task created in schematic and assigned to developer.

In progress

Developer reworks design to fix issue.

Resolved

If solution is approved the issue is marked resolved.

An important part of the schematics are the components that are used in the design. Each component has the following properties:

  • A schematic symbol
  • One or more footprints (depending on the IPC class)
  • Component parameters
  • An orderable part number (or more)

To keep track of the status of our components, each component and footprint in our database adheres to the following lifecycle:

New

Initial state after creation by the developer

Prototype

After a new component is reviewed by a colleague it transitions to the state 'prototype'

Production

When the component is proven to be correct in a prototype it is moved to the state 'production'.

Obsolete

Once a part is obsolete, or not to be used for some other reason, it is moved to the state 'obsolete'.

Release process

When a design is ready to be released, we create a production package (TPD). This 'package' contains all the information the manufacturer needs to assemble the PCB. To ensure that the output is uniform, consistent and complete, all output in the TPD is generated from preset templates.

In the release process, automatic checks are also performed on the design, in which the following components are verified:

  • Does the design comply with the design rules?
  • Are there any unresolved comments?
  • What is the condition of the components?
  • Are all components available?
  • Are all design documents stored in the cloud environment?

As soon as the check has been successfully completed, the release can start. After execution, the release is tagged in the repository and can be sent to the manufacturer for production.

Lifecycle management

Because our component database is linked to the supply chain information of many manufacturers, we can monitor the availability of all components. This also applies to the manufacturer's lifecycle. We take advantage of this: we proactively scan for future supply chain problems and ensure that our designs are manufacturable. This has additional added value in the current market, where shortages of semiconductors play a role.

In short, an iterative process is also important in hardware development. In this way, it is possible to respond quickly to lessons learned from previous iterations. Changes from the customer, for example through testing with prototypes, can also be included in the end product in this way. We therefore do not see changes as an obstacle to be avoided, but as an important part of the development process. With this mindset, specifications can be guaranteed.