Concept to PCB

Today we will talk about designing hardware in a systematic way. We will see what are the different approaches we can take and how we break down the product brief into PCB requirements. We will also check out some IRL product briefs.

As with most answers in engineering, the answer in system design approaches the answer is ‘it depends’.

There is no single right or wrong way to design a system. But I think there is a mostly wrong way and mostly right way to design a system. When you see any design, you can find flaws and say, this could be added or this is not optimum design. But you need to get into the designers shoes, and ask why these decisions were taken, it could be they were short on time or had some cost limitations.

First we will see what is the wrong way.

Mostly wrong way

In this approach, especially when you are a beginner, you would have worked with one platform and are familiar with it. So when you get a product or a project brief, your first thought is can I run it on XYZ platform. On hardware it could be, say, the Arduino platform. If the project/product fits into what you are familiar with and it works, you are happy, the client is happy. I’ve been guilty of this too. When I used to get a project with a tight timeline, I had to work with the tools I was familiar with and knew most of its gotchas. This can also be applied to software, using the same stack you know and worked with. It could interrupt based code, even if the product can work with round robin or the other way, it might need a RTOS.

This can be called a bottom top design approach. When you follow this approach, you can become a fanboy of something. I was an Atmel fanboy myself before it was acquired by Microchip. You stop seeing the limitations.

The short of this is that we try to fit in the project to our requirements and not the other way round, again nothing wrong, you could say it works, I get stuff done. But in the long run it’s not the best strategy. Because this is self limiting. You don’t do full justice to the product.

Mostly right way

From what I learned, the right way to have a top-down approach is better in my opinion. This approach usually leads to a better design and does justice to the product.

We first study the pain point and how the product is solving it. This is a great place to start because it makes sure that there is no XY problem scenario.

The most recent example I can think of was, there was a request from the driver for a motor, but the actual problem was something else. The definition of the problem was not clear.

After we have gathered the product brief, we start listing down the high level requirement as below in no particular order.

• Processing power
• Communications interfaces
  • High speed
  • Low speed
• Power constraints
• Dataflow
• Mechanical constraints
• Hardware and software compliance
• Cost
• Timeline

We don’t need to think about this list in order, we need to think about all of them in parallel.

For the processing power, you need to know how much compute is needed on the edge, do you need a floating point processor? This is where you need to know the dataflow. Here you sometimes need to learn about some protocols used in the software, just so you have a birds eye view if it has any effect on the hardware design.

Sometimes you need to use an overkill of a processor just because of the interfaces. Say you need five UARTs, but the processor that is sufficient for the application has just one, in this case you need to go for a higher end processor.

Cost here means the cost of the product, not the BoM, it includes, cost of PCB, assembly, enclosure, shipping etc. You would also need to have an idea of the power budget of the device. It will also give you an approximate handle on the thermal requirements of the pcb.

Then there is compliance, when you are developing a product, you need to think about the tests it will go through, emissions test, waterproof test. Some certifications are needed to legally sell your products in certain regions, for example, you need FCC to sell in the US. There are certain restrictions in frequency bands your product can use.

For some products especially in military, automotive, medical you also need to go through software compliance.

Architecture

Once you have all the stuff in your head, you can now start drawing block diagrams, each block will later turn into a schematic sheet. An interesting way of making block diagrams is to use LLMs. I’ve posted the details in the blog

PCB requirements

After this you can start listing down the pcb requirements. Here fist thing to ask for is the MCAD requirements. If not 100% MCAD requirements are clear, make sure you know the ballpark size and the form factor of the PCB. Make sure you have all the interfaces and power connectors placed properly. Recently there was an oversight from Nvidia where the connectors got too hot and melted.

Apart from the interfaces needed by the product, you also need to add the interface for debugging, bootloading and other things that will help you with the board bring up. Next you’d need to look at the board configuration, is it a rigid board, or you’d rigid-flex based on the mechanical constraints, or is it a multi board system.

Some microprocessors have a strict power up and power down sequence, you need to turn on/off the various power rails in a particular order, or the processor will not boot up. In this case you’d need to add a power supervisor for handling this sequencing.

Next is planning on the stackup, this depends on the complexity and the board density. We can probably do another post dedicated to the layer stackup.

In some cases if the product is a wearable, you need to take into consideration the weight and height of the components.

Component selection

It’s very important to know the final application of the product.

One time I built a product and later the client comes in and says it will be used in automotive too? It was not pleasant, as I did not select automotive compliant components, and the device would fail if used in an automotive setting.

Some applications need components with certain standards. For automotive components, you need to have components that are AEC-Q100 standard, these components have a wide temperature operating range, and they are tested for vibration too. If you need RoHS certification, you need to use those certified components.

If you are building say a device that goes in ID cards, then you need to be mindful of the height of all the components. This also goes if you have a PCB that folds over.

Passives components have a precision, it’s recommended to go for high precision components like 1% tolerance rather than 5 or 10%. Make sure to select the resistor with appropriate power dissipation.

The type of component you used also determines your cost of assembly.

Schematic Design

After you have selected the components, you can start with the schematic design, use the architecture block diagram as a reference to make the various schematic sheets. It’s good to define the net classes and differential pairs in the schematic, so later pcb rules can be applied to them.

BoM optimization

This is done as you are designing the schematic. Use the parts that are absolutely needed, if you are not sure, add it to the design but it can be marked as DNP for manufacturing. I remember a story about a smart watch manufacturer that was able to save $100,000 just by removing one 10 cent capacitor over a million units manufactured.

PCB design

Now after all is said and done we arrive at PCB design. Here too we first define the rules and rooms for different classes and blocks of the circuit. I talked about this in this blog post. How you place your components is important, as it can have some effect on the assembly time and cost. You have to select the dielectric and use it to define the rules for trace space and width for impedance controlled tracks.

Design for X

You can replace any alphabet by X and you can make an acronym. You can design for assembly, for bom, for manufacturer, you need to design for X, where X here stands for eXcellence. Do justice to the product, it’s okay not to know everything, you must ask and learn.

Prototypes

Once you have the design files ready, you do a small production run of 5-10 devices, this design should be as close to the final as possible. The boards I designed, I sent the same files, I used for prototypes and did a production run of thousands of devices. Used these to extensive testing and also make the design for QA systems for production runs. This way the manufacturer can test the device before shipping it. Also have the prototypes for mechanical also made and test the fit and function of the device within the enclosure. Here all the test points you added will come in handy.

Compliance testing

Test early and test often. It’s good to have an idea of the compliance testing your product will need, even if you don’t do it right away, do the tests in house. You can do the tests for emissions and for IP.

By the end of this exercise you should have a product in hand. May your next product be excellent!

Fin.

If you want to see the live video on this check it out here

Also if you want to keep the conversation going join us at DevHeads discord

No part of this post was generated by LLMs.