feature article
Subscribe Now

The Counting of the Beans

Engineering Practicality

In engineering school, we are taught that our discipline is about solving problems.  We learn proven, methodical approaches to problem solving, and we work to gain the experience and expertise we need to look at a set of requirements and create a solution that most efficiently and elegantly satisfies those requirements. 

Our profession is part art and part science.

As engineers, we do not follow the scientific method, but we reap rich bounty from its application.  As a painter applies pigments of known color to canvas – creating something that transcends the materials and media in which he works, the engineer applies the elements of science to real-world problems – creating solutions that are elevated above the principles on which they are founded.  In considering the difference between art and science, Einstein is reported to have remarked “…even had Newton or Leibniz never lived, the world would have had the calculus, but that if Beethoven had not lived, we would never have had the C-Minor Symphony.”

If we look at Einstein’s observation from a different angle, we see that engineering is often closer to art than science.  Our engineering creations are not like basic principles of physics and mathematics – waiting patiently in the ether for us to come along and discover them.  They are instead unique and imperfect systems – cosmic compromises that may exist for only a moment – ready to be replaced by more efficient or more relevant machines.

In engineering school, we memorize rough sketches of solutions.  We learn and practice the gestures that will later serve us as we tackle unexplored and unsolved challenges.  Our pedagogy is like that of the martial artist – repeatedly exercising defenses and counter-attacks to anticipated enemies still unknown and unseen – with the faith that our eventual assailant will bear at least some of the traits for which we trained.

As students, our passion for engineering is driven by the desire to create new things – to tackle the universe and force it, however briefly, to submit to our designs.  We hone our powers of problem-solving in controlled isolation before being unleashed on the real world – where friction cannot be assumed to be zero.

What engineering school does not teach well is that we will do our engineering in the world of politicians, accountants, soldiers, and parents.  The technical challenges for which we have trained will often be the least of our worries.  It is a rare engineer who has the luxury of a requirement like “Get this information from point A to point B as quickly and reliably as possible.”  In the real world, even the simplest of design tasks begins with a budget, a boss, and a background.  Designing the widget is easy.  Doing it in a way that meets schedule, cost, and political constraints can be a thousand times more difficult. 

In FPGA design, for example, we constantly advise engineers to maintain a diverse suite of implementation tools.  The synthesis software that gives the best results on one design may be the one that utterly fails on the next.  We could spend weeks tuning one tool to finally get that last timing path out of negative slack, while the other tool might avoid the problem altogether.  While design tools may seem expensive to the uninitiated, they are an absolute bargain when compared against the engineering time and effort they replace.  If a $40K “backup” synthesis tool could consistently save a week or two of engineering time per year, or better yet – could allow us to build our design with a cheaper speed grade or smaller FPGA, the savings in BOM, time-to-market, and engineering expense would pay for the tool many times over.  Really, if you are doing professional FPGA design for products that will be produced in even modest volumes, you should probably own every synthesis tool on the market.

Bean counting doesn’t work that way.

The tool budget forks away from the payroll budget at a very high level.  Even though the fundamental reason for buying tools is to increase productivity, corporate accounting structures make it almost impossible to do the fundamental trade-off of tool cost versus engineering expense that would begin the act of properly balancing those factors. 

Saving engineering time is just the beginning, though.  If a better tool will let us design a more efficient solution, we might be able to use a smaller battery, a cheaper FPGA, a smaller form-factor – the list goes on and on.  If we could produce a better, cheaper product – the financial implications could be enormous.  Just a slight drop in the BOM of a high-volume device could pay for a lifetime of term licenses on a decent EDA tool.

Let’s also not forget the advantages of getting the design done sooner.  Getting our product to market even a few weeks ahead of our competitors can result in dramatic increases in revenue.  Revenue which, ironically, is what the bean counters are there to measure and control in the first place.  Bean counters don’t get this, and their influence on decision makers is considerable.

Interestingly, what bean counters cannot counter is fear.  While all the “productivity” arguments in the world cannot pry a coin from the cold, dead hand of the typical corporate controller, a “fear” argument works almost every time.  If you need a particular tool to reduce the risk of a multi-million dollar ASIC re-spin, the checkbook pops open with a decisive report that echoes throughout the accounts payable department.  As engineers, we may find this illogical, but that’s where our technical training lets us down.

Engineering is simultaneously solitary and massively collaborative.

While much of our “real” engineering work is done in quiet solitude, it is a rare project that is the work of only one person.  In today’s world, most technology is the product of complex organizations with people of many motivations, temperaments, and talents.  While we tend to anthropomorphize companies and ascribe “personalities” to them, it is important to remember that a company is really a collection of individuals – each operating with his or her own biases and goals.  At the macro scale, the sum of all those separate behaviors and motives often leads to the swarm moving in the general direction that favors the financial interests of the shareholders.  But, like any NP-complete problem, the algorithm is subject to foolery from local optima. 

One might conclude that our profession is one that benefits more from people skills than from technical prowess.  However, it is easy to demonstrate that this is not the case.  A friend of mine who owns a consulting company claims that an “excellent” engineer is worth, in his estimation, forty “average” engineers.  Yep, that’s not a typo.  “forty.”  We don’t want to believe that, of course.  It would be nice if the engineering-world value of the person in the next cubicle with two years less experience than you and one less degree was somehow linearly less than yours in a way that fit nicely into corporate salary matrices.  Human Resources has spent decades teaching us that this is the case, and the bean counters most certainly want it to be true.  But line up two engineers with similar qualifications and have them independently try to solve the same problem and you’re likely to find an enormous difference in performance.  Engineer #1 might easily design something with forty times the commercial value of engineer #2.

In the world of bean counting, we don’t want to compensate engineer #1 forty times engineer #2, however.  Our sense of social equity in professions like engineering doesn’t mirror, say, our valuation of sports heroes.  In sports, we understand the importance of the “franchise player.”  In most modern high-tech companies, engineers are valued within a much narrower band.  Sure, the founder in an engineering-oriented start-up who happens to be an engineer may garner the same kinds of multiples in compensation that one would expect based on contribution to the bottom line, but such an effect is seldom seen in engineers hired into a pre-existing, functioning company.  If you want to earn the big bucks, and you want to be an engineer and not an entrepreneur, your options are severely limited.

But, fear not, fellow engineer.  The counting of the beans is not the reason we chose the discipline of engineering from life’s menu of options.  While it is true that the lively legume of finance is the fuel that feeds our passionate pursuit of the perfect problem, mere cash is a hollow victory.  It is not the monetary rewards that truly drive us to press on in the midnight hour when the last of the Mountain Dew has left the cooler and the flutter of fluorescent sunshine over the empty sea of cubicles makes our eyelids heavy.  We are driven by a moment and a feeling.  We crave that fleeting second when the LED first blinks on, when the stepper motor initially engages, or when a fuzzy image finally emerges from the darkness.  That is the moment when we know that our idea will work.  That is the moment when we know we have – however briefly – reversed entropy and shaken our finger in the face of cosmic certainty.  That is the moment that nourishes our engineering soul.  No scientist can ever know that feeling.  No bean counter can ever measure its worth. 

Leave a Reply

featured blogs
Nov 30, 2021
We live in a world where the idea of usability is to make products easy to use, make things easily accessible, and visually appealing. It's our constant endeavor to improve the usability of our... [[ Click on the title to access the full blog on the Cadence Community si...
Nov 29, 2021
Tell me if you've heard this before, but I'm looking for a Nordic word that has a sufficiently amorphous gestalt to make it confusing to explain in Norwegian....
Nov 29, 2021
Lean how virtual electronic control units (ECUs) accelerate automotive design and enable advanced driver-assistance systems (ADAS) for connected vehicles. The post From Road to PC: Accelerating Intelligent Software Growth with Virtual ECUs appeared first on From Silicon To S...
Nov 8, 2021
Intel® FPGA Technology Day (IFTD) is a free four-day event that will be hosted virtually across the globe in North America, China, Japan, EMEA, and Asia Pacific from December 6-9, 2021. The theme of IFTD 2021 is 'Accelerating a Smart and Connected World.' This virtual event ...

featured video

Achronix VectorPath Accelerator Card Uses PCIe Gen4 x16 to Communicate with AMD Ryzen PC

Sponsored by Achronix

In this demonstration, the Achronix VectorPath™ accelerator card connects to an AMD Ryzen based PC using PCIe Gen4 x16 interface. The host PC issues commands to have the Speedster™7t FPGA on the VectorPath accelerator card write and read to external GDDR6 memory on the board. These data transactions are performed using the Speedster7t FPGA’s 2D network on chip or NoC which eliminates the need to write complex RTL code to design the host PC to GDDR6 memory interface.

Contact Achronix for a Demonstration of Speedster7t FPGA

featured paper

3D-IC Design Challenges and Requirements

Sponsored by Cadence Design Systems

3D-ICs are expected to have a broad impact on networking, graphics, AI/ML, and high-performance computing. While there’s interest in 3D-ICs, it’s still in its early phases. Standard definitions are lacking, the supply chain ecosystem is in flux, and design, analysis, verification, and test challenges need to be resolved. Read this white paper to learn about 3D integration and packaging of multiple stacked dies, design challenges, ecosystem requirements, and needed solutions.

Click here to read more

featured chalk talk

i.MX RT1170

Sponsored by Mouser Electronics and NXP Semiconductors

Dual Core microcontrollers can bring a lot of benefits to today’s modern embedded designs in order to keep all of our design requirements in balance. In this episode of Chalk Talk, Amelia Dalton chats with Patrick Kennedy from NXP about why newer design requirements for today’s connected embedded systems are making this balancing act even harder than ever before and how the i.MX RT1170 can help solve these problems with its heterogeneous dual cores, MIPI interface, multi-core low power strategy and SRAM PUF technology can make all the difference in your next embedded design.

Click here for More information about NXP Semiconductors i.MX RT1170 crossover microcontrollers