Guest blogs
Proof-of-Concept Prototypes versus Manufacturing Design Preparations

Proof-of-Concept Prototypes versus Manufacturing Design Preparations

I have designed many early-stage proof-of-concept (POC) circuits, and observed many others do the same thing. It seems that there is often a huge disconnect between clients and engineers, though, when it comes to the goals of a POC design. In simple terms, an engineer worth his salt will overdesign an early POC circuit. This is because Murphy’s law always applies, and POCs are about overcoming unknowns. By overdesigning the circuit, one is able to prove the client’s product POC can be made to work, and quickly.

So, what types of things should be overdesigned? Here is a short list. However, the nature of the design will likely call for more (determining what is appropriate is part of why real engineers are paid higher than “sanitation engineers”):

1. Design in a microcontroller with at least twice the expected needed resources. If you think you need 64K for code, get at least a 128K device in a package that can migrate to a 64K variant as the project moves forward.

2. Choice of a microcontroller should not be based solely on the device’s datasheet. Choice factors should include the availability of evaluation kits, example software, ready development hardware, and most importantly, the ease of use and quality of the firmware development system.

3. Design switching power supplies with additional filters on the input and output. Generally, ferrite filter inductors like Murata or Laird SMT devices with high-frequency bypass capacitors should be added to both the power-supply input and output outboard the manufacturer’s recommended energy storage capacitors on input and output. Removing the ferrite beads will also enable disconnection of the power supply for testing and troubleshooting. It is often a good idea to choose ferrite beads with footprints of 0603 or larger to facilitate manual removal and replacement.

4. Provide power-supply switching and control interfaces so that the microcontroller can shutdown, or in some cases isolate, normal operation supplies. Consider a micropower low-dropout (LDO) regulator with diode ORing to minimize the sleep current for battery-operated systems. For such systems, it helps having a microcontroller that can operate over a broad range of power-supply voltages. For example, it allows for 3.3-V normal operation using a 2.5-V LDO micropower regulator with diode ORing to supply VCC. This enables immediate and default transfer to the LDO when the 3.3-V operating regulator is disabled. The diode ORing will also help when using a JTAG programming system, since the JTAG can be set up to provide 3.3-V programming power to the microcontroller, even in the absence of the switching and LDO regulator outputs. Such bare-board programming capability can be very helpful for many troubleshooting and testing situations.

5. Use lower RDS(ON) FETs (subject of course to control and switching limits of drive circuitry) to ensure heat problems will not stop the testing. They will cost more, but the most unpredictable characteristics in many designs are switching-device and switched-device losses. Such unpredictability also lobbies for the selection of shielded inductors with good saturation currents and low losses.

6. Distribute power-supply energy storage AND low-pass filtering around the circuit where any sensitivity to power-supply-coupled noise might become an issue. In one project a few years ago, for a particularly large client that was preparing a product for another particularly large client (that was also helped my company), I assisted on a design without distributed filtering on an RF system—the transmit circuit was coupling back to the receive circuit through the power supply. Adding such filtering improved the circuit’s signal-to-noise ratio by better than 20 dB. In that case, power routing was applied to try to reduce crosstalk, and good low- and high-frequency bypass capacitors were already installed.

7. Choose parts that are available overnight from distributors or manufacturers, and choose only parts of known quality. What will be done if, during testing, a part is accidentally damaged, or a quick change in a part’s value is needed to proceed with testing? How can one be certain that a failure during prototyping is due to the design and not the parts used?

A very common disconnect between client and designer occurs when the designer provides a bill of materials (BOM) for the POC unit and the client gets sticker shock and says, “This is way too expensive, I can’t get market share if my BOM is this high!” The designer should have been looking at a preferred path to cost reduction even in POC design, but this is not as important as getting a working model to the client and fast.

The next phase of design after POC needs to include this discussion and others to reduce costs, improve manufacturability, address user experience, etc. The difference between a normal design and a good design is how far ahead the designer can look toward these additional features during POC design. The better the design, the easier and quicker everything becomes in the next phase.

What is most important is to control the client’s expectations, to avoid the client stating, “Are you saying the design is not done yet?” This design-for-manufacture (DFM) phase of cost reduction, and considering the client’s preferred manufacturing environment, is almost always inevitable. In truth, DFM will almost never be started at the end of the first (and sometimes second) POC cycle for any given design specification. It will generally take even more cycles when the design specifications are not fixed, not well communicated, and/or not well documented.

One of my favorite rhymes from many years ago (first shown to me in 1986) was called “Twas the Night before Crisis.” The final few lines went: “And the customer exclaimed with a smile and a taunt, ‘It’s just what I asked for, but not what I want!’” To avoid such an interaction, there needs to be an active and good dialog with each customer, often face-to-face in order to read his body language. He must understand what to expect for each phase of a development project.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.