Marcel Pelgrom consults on analog IC design.
When chess world champion Magnus Carlsen was asked what he had learned during his training sessions with former world champion Kasparov, the answer was simple: rapidly analyzing a complex chess position. And indeed, Carlsen is one of the fastest to find the crucial move in an unknown position. An important aspect of chess analysis is to recognize structures: specific arrangements of pawns and pieces that create a solid defense or allow specific attacking tactics. Experienced players cherish such structures, as they’re integral to their game.
Similar mechanisms can be recognized in designing and analyzing complex technical systems, both in hardware and software domains. In the era where a telephone exchange required a big hall, the only way to keep control over the design was to strictly separate functions and structures. The same is valid for a ‘simple’ system-on-chip IC, with various I/O channels, a few processing units and a diverse collection of memories. Clear function definitions and interfaces allow off-loading irrelevant sidelines when overviewing the system.
Managing complexity starts with selecting people. Brilliant engineers design simple systems. Electronics and software mavericks, on the other hand, are a real danger, as their smart and elegant ideas mess up the simplicity of structures and turn mastering complexity into a nightmare. Equally dangerous are people with hammers that treat every issue as a nail. These engineers, once successful with a trick, apply the same solution to every problem.
Engineers must be able to adapt their way of thinking to the system they design. That starts with acquiring a variety of tools and skills, which allows you to easily switch from analyzing a control loop in the time domain to its frequency domain or root-locus view. Real masters of complexity can simplify the system to its essence without getting distracted. They can change their perspective and analyze a problem from various sides. A broad technical experience allows them to use ideas and methods from other disciplines. There they outperform their run-of-the-mill colleagues. They see the red line running through the project and by experience discriminate essential operations from nice-to-haves.
Device lifecycle management for fleets of IoT devices
Microchip gives insight on device management, what exactly is it, how to implement it and how to roll over the device management during the roll out phase when the products are in the field. Read more. .
Implementing a system and choosing its technical structures is a consequence of a rigorous analysis of the required objective for the system. Forty years in IC design have taught me that there’s always only one objective that really matters – the rest is negotiable. A system built for serving multiple objectives is by definition too complex to master. Extensions, upgrades, modifications or even repairs drown in an uncontrollable workload.
The objective comes sometimes with the specifications, but mostly it’s more than that. Finding the crucial objective can be trivial. For Miele household appliances, it’s reliability. For Ferrari cars, it’s appearance. For Apple electronics, It’s ease of use. When Apple wanted to introduce the smartphone, Steve Jobs had every proposal brought into his office. He knew what his company objective was and how it should translate into a phone. Every proposed device not satisfying that was smashed into the wall.
During the implementation phase, the objective is leading and recognizable in the backbone of the system. Engineers have an unhealthy tendency to economizing their designs. As if the Excel generals in the company would be able to spot the waste in hardware or code. Every structure has its own set of supporting functions; optimization isn’t advisable in an early design phase.
Complexity requires an appropriate level of administration. In the days that a single engineer could build a chip or software application, some scribbling might suffice. Today, progress in a project is virtually impossible without adequate documentation and communication. Every engineer can easily identify a dozen more attractive tasks, yet a clear way of working is a must to master complexity. Organizing the daily workload is paramount: keeping track of experiments, sorting, labeling and storing test and simulation results, and keeping modifications separate from the golden code are elements necessary for avoiding communication pitfalls in modern system design.
Designing complex systems requires a comprehensive approach, from personnel selection to documenting the daily progress. Mastering complexity is foremost an exercise in discipline, a virtue desperately needed in today’s world.