Electronic Circuits Have To Be Designed – Not Assembled

Now-a-days, designers tend to use off-the-shelf designs and software available on the Internet or from the vendors to design products requisitioned by their clients. While this may be unavoidable in certain circumstances, their rampant use without understanding the factors involved can land them In problem. Here are some important suggestions from a person who has seen it all for such designers.

In the last decade experienced designers have become a rarity and the next generation of engineers does not seem to have the ability or desire to design electronics circuits bottoms up. Most of the designers tend to take an existing circuits or reference (canned) designs that are provided by the chip vendors to develop their products. Or, worst, they source from the Internet. This practice later leads to trouble when the product (circuit) is being tested. Unknown problems crop up and engineers struggle to identify them. Under these circumstances projects get delayed and miss the market window. Assuming the designers make the circuit work, they have either a cost issue or manufacturing issue. Implementing a circuit through such ‘assembled’ approach can produce pretty nasty and unpredictable results.

- Advertisement -

 
Let us see why designers tend to take this route.

1. IC product lifecycles are shortening. The devices now have only 7-8 year life, necessitating continuous learning of new devices, which the current day designers are not able to cope up with.
2. Increase in operating speed with reduced silicon geometry. This calls for strong high-speed design skills and good basics, which are a rarity with the current crop of engineers.
3. Almost a similar situation exists in the embedded software. In fact, the situation in the embedded software is even worse as most embedded software developers are only integrating the software components. Programming in C and Assembly language has become a rare skill, causing a big problem. A proper software architecture should be the right solution.

We have seen product development cycles extending and fewer companies/startups succeeding. Above all, interest in electronic product based startups has started vaning due to the perceived issues.

- Advertisement -

Why this is critical

Every electronic product needs detailed specifications to perform better and work in the environment for which it has been designed. When products are in critical domains like medical devices, avionics, and automotive, they need documentation and a strict process adherence. In fact, most of these domains demand submission of documentation to the regulatory authorities, and these documents are typically design history files (DHFs).

When you pick a canned design and use it in your product, the documentation is not available. In addition, most of these vendors put a disclaimer that the circuit provided is for demonstration purpose and they are indemnified when the designers use it in their product design.

If the product to be designed has lots of communication functions, reference (canned) designs do not scale up. This is true for both hardware and software. Today this issue plagues the IoT designs as most IoT ‘Things’ and ‘Gateways’ are communication-intensive and properly designed hardware and software is a must for proper working.

Some examples

Here are a couple of examples of how the designs that used the canned designs and associated software have performed. One of the IoT designs of a startup used a reference based hardware and code that was supplied with the reference board. But as the testing progressed the team faced following Issues:

1. Response time of the system was slower than the requirement and team ended up revisiting the code and the hardware. What transpired was that the interrupt section was not handled correctly in the hardware and software leading to the slow response.
2. In the same product the target bill of material (BoM) and the actual BoM were completely off target. Primary reason was that the reference design used almost all the parts (digital and analogue) from the same vendor, while other than microcontroller the team got lower-cost parts with better performance from other vendors. This happens especially with analogue parts and certain standard digital devices.
3. One key aspect in designs where off-the-shelf (canned) code is used is the care that is needed in the design stage. For example, embedded software for actual system can be broadly classified into following types:

• Bare metal coding. This is typically applicable to systems that use very few I/Os and are designed based on 8-bit processors. Bare metal code is specific to the hardware and offers less flexibility. But it is preferred for simpler systems that need to be produced in large volumes as such coding results in less memory consumption and tuned response time to meet the application needs.
• OS based application. This type of coding needs a basic operating system (like Free RTOS or Linux) and the application is written over the OS. This type of coding Is good for high processor performance and multitasking application needs. This type of system typically uses 32-bit processors and Is fairly complex. (The irony is that most designers use the canned design based on OS and walk into trouble.) The designers need to understand that OS will always be canned in both open source and vendor supplied software. But the section of the code that pertains to the hardware is the critical item in the overall design.

Typical simplified software architecture of an OS based system is shown in Fig. 1.

When designers choose a product architecture that uses an OS, they have to ensure that the OS is ported to the processor selected/used and the processor vendor gives the HAL/BSP for the OS. Most common mistake seen is that designers choose the processor, OS, and the BSP, but their design also has additional devices outside the controller for which the BSP or OS will not have support. Designers tend to forget this step and later struggle to make the board work.

Even messier problem noticed is the network stack (portion of the code which manages the networking functions in an OS). Other than a few versions of Linux, most OS and RTOS normally do not come with network stack, leading to huge issues. If a native networking stack is missing, porting a stack is going to be a challenge and can lead to performance, interoperability, and memory shortage issues. So, if a canned software is being planned, ensure the network stack is reliable and already proven in the processor selected.

What needs to be factored

When choosing the architecture (both hardware and software), designers need to be conscious of three critical aspects:

1. Cost of the product
2. Volume of the product to be produced
3. Types of users and the working environment of the product.

Let us briefly see each of them for better understanding.

Cost

It is the primary criteria for the success of a product. Typically, the cost of a product equals Bill of Material + Manufacturing Charges + Warranty & Product Support cost. Please note, this cost is not the final price, which would include other expenses like packaging and marketing and profit margin. When an off-the-shelf design is used, it is this cost that gets impacted. Typically, 70% will be BoM, 20% will be manufacturing, and 10% will be other cost. From this you can see how a proper design can save the cost as well as ensure the success of the product.

Sales volume of the product

With higher product volumes, the manufacturing process has to be automated, and the design has to be robust enough for fast and reliable manufacturing. Most contract manufacturers use processes like Design for X (where X stands for assembly, manufacturing, testing, compliance, and environment). An off-the-shelf design makes these processes difficult as reference design based products make the DFT and DFC difficult.

User and working environment

Third important aspect is the users who use the product and the product’s working environment. About 50 to 60% features of a product depend on these two parameters. When a predesigned (reference) circuit is used, customisation for the user to make the product work becomes difficult in environment-prescribed scenario. A harsh environment needs special parts (industrial or military grade) and a robust thermal design mechanism, not to mention radiated emission (like EMC/EMI) issues that are dependent on the components and the circuit design.

It does not mean you should not use off-the-shelf designs at all; there will be situations where it may become unavoidable. In case of PC motherboards, for example, the designs are typically provided by the chip vendors like Intel. If a customer wants to customise the design, these vendors offer circuit review and PCB layout review covering power integrity and signal integrity. So, if it unavoidable to use a canned design, make sure you know the in and out of the design before proceeding with the product implementation.

Points to keep in mind

While the list of points that need to be looked into is big, here are a few key aspects that need attention when the canned design is used:

1. Capture the product requirements completely and map to the canned design you have to ensure there are no gaps. If there are gaps, have a plan to fill them.
2. Spend time to understand the provided reference design so that implementation changes are well understood.
3. Compute the bill of material cost of the reference (canned) design and benchmark it against the budgeted cost. Identify the parts that are expensive and find lower-cost replacement without impacting the performance.
4. If you have to re-lay the PCB to suit your product, understand the thermal and electrical safety and compliance needs and implement. Most reference designs do not need to meet these, so aspects like filtering, heat-sinks, etc have to be properly looked into.
5. If your product is for medical, avionics, or automotive use, remember to generate regulatory documentation for the design and manufacturing for product’s approval.
6. Finally, verify and validate the product exhaustively to ensure it has no performance issues.

S.A. Srinivasa Moorthy is Director Engineering Design, D4X Technologies Pvt Ltd