Before becoming professional engineers, most of us designed and built things as a hobby. It’s rare to find an engineer who jumped right into engineering school without at least some background of tinkering and experimenting. And, when we did those projects, we had full control. We could choose whatever part we wanted or needed. We didn’t have to deal with management, manufacturing, procurement, approved parts libraries, second sources, distributor line cards, or any of the other myriad constraints that tie the creative hands of just about every working professional engineer on the planet.
Of course, we had other constraints to deal with. Sometimes we were limited to the parts we could unsolder from salvaged boards with a blowtorch, or by our budget, or by what was in stock at our local Radio Shack, or by what was in the “kit” we were gifted. It turns out that these limitations were excellent training for life as a professional. After all, engineering is the art of problem solving within constraints. We have constraints that are applied by physics – like power, signal integrity, form factor, and the properties of silicon, copper, and FR4. And, we have constraints applied by our organization, which can be much more baffling in most instances.
Every choice we make as an engineer has implications. We choose a more expensive part and we affect the BOM. We choose one that consumes more power and it may have knock-on effects like thermal issues, battery sizing, form factor, heat sinks, power modules, and more. We choose one that’s in limited supply, and we may jam-up manufacturing (tried purchasing any MLCCs lately?). We choose one with tighter pin spacing, and we may make our board design more difficult. (In fact, sometimes smaller parts with tighter pin grids can actually end up consuming more total board real-estate by the time we break out all those traces.) It seems that any decision we make resonates and reverberates throughout our design, our design process, our manufacturing process, and ultimately in our customers’ experience with our product.
Luckily, making those types of trade-offs is exactly what we are trained to do.
What we are not trained to do is to navigate the labyrinthian complexity of corporate politics and bureaucracy. Does your engineering VP have a brother at a large component distributor, and magically only their line card is on the “approved” list? Are your EDA tools chosen at the corporate level by executives (who have never operated a tool in their lives) cutting multi-year, multi-million dollar deals on the golf course with whichever EDA major account rep has the best bar stock? Is a purchasing agent in manufacturing trying to swap your Xilinx FPGA for an Intel one, or your ARM SoC for one with a completely different instruction set because they can get 10% better pricing or more favorable delivery terms – with no regard to the fact that your entire application is designed around a particular processor instruction set, FPGA architecture, or other parameter invisible to the purchasing department?
Navigating this minefield can sometimes be a bigger challenge than the design itself.
Luckily, for many of these constraints, tool vendors are building-in fairly robust sets of real-time or about-at-the-right-time checking. Many PCB schematic and layout environments today also include or offer design rule checking (DRC), design for manufacturing (DFM) checks, signal- and power-integrity checking, thermal analysis, and, of course, functional simulations, to get around the more engineering-y issues. There are even checks to see if components are available in quantity for your manufacturing organization – before you willy-nilly drop some unobtainable component onto your PCB and build an entire system around it.
It’s also remarkable how the segmentation of budgets affects this decision making process. In several companies we talked to, there were tools available which could have a dramatic impact on engineering productivity and schedules. But the cost of those tools was never weighed against the additional cost of the engineering without those tools, or the improvement in project schedules and therefore product delivery with those tools. If a tool wasn’t within the pre-established budget, it didn’t matter that it might save the company many times the cost in the long run. That money, and the additional payroll costs for engineers, came out of completely different budgets and was never weighed against the tool cost. Further, there was often the attitude that the engineers could “just work harder” – as if there were any engineers just 9-to-5-ing it with overtime to spare. C’mon you slackers!
This procurement paradox also affects the companies who market to engineers. If you’re selling EDA tools, for example, you have to be mindful of the fact that the engineers you’re trying to impress with your fancy demos may (sadly) have little or no voice in choosing the tools their company adopts. If you’re a startup semiconductor company, that impressive datasheet you’re handing out may have no chance whatsoever of getting your chip past the scrutiny of a major company’s purchasing and procurement process with all of the availability assurances and other assorted hurdles standing between engineering’s desire to make the design better and manufacturing’s need for confidence in the production process.
No matter how many white papers, webinars, development and evaluation boards, mugs, t-shirts, pens, and logo personal organizers a company gives you, you may not have the power to get their product included in your next design. Even if you think their solution is the best fit for your application, the chains of corporate constraint may be far too strong to sway the outcome. If you think about it, it’s remarkable than any working product ever makes it to market at all.
IP Driving Automotive SoCs
Sponsored by Synopsys
What you design matters. You are designing SoCs for the most advanced driver assistance systems where safety and reliability are non-negotiable. Meeting automotive standards for functional safety, reliability, and quality matter. Achieving SoC-level certification matters. Your SoC isn’t just for the car other people drive, it is also for the car you drive. Design with Synopsys’ ASIL Ready ISO 26262 certified DesignWare IP, because it matters to you.
Click here for more information about DesignWare IP for Automotive
In an ideal world, engineers would have free reign on the key decisions that affect the design – the functionality, cost, performance, reliability, and manufacturability of the product. But the reality of today’s tech environment is far from that ideal. Until that changes, we have to weigh political and bureaucratic constraints with the same weight as physics and technology in the grand compromise of our engineering work.