Mastering Design Abstraction

It still happens, even today. The SystemVision team is invited to visit with a customer. After brief introductions, we sit down to discuss their specific mechatronic system design challenges. And then it happens…out comes a detailed schematic that accounts for every component in the system. Naturally, there is nothing wrong with detailed level schematics. At some point, every mechatronic system development project ends up with its nitty gritty details reduced to one or more detailed drawings of some sort. But many companies actually start and stay at the detailed level, bypassing the many benefits of a multi-level design process, an approach made possible by advanced simulators and industry standard hardware description languages.

Admittedly, I thought detailed level design was the beginning and end of a system development methodology. It’s the way I learned to design in college: start out with a system specification, whip out a notebook to make a few calculations and draw a preliminary schematic, then head to the lab for a bit of bread boarding and test. Okay…so I’m exaggerating a bit. I did draw a few block diagrams to partition my designs into somewhat independent functional blocks, but from there I dove pencil-and-paper first into detailed design. I suspect most engineers, particularly those doing electronic design, were trained in a similar methodology. But my views on design methodology abruptly changed when I took my first job in the EDA industry.

The company I worked for was proselytizing a methodology they called Top-Down Design. This term is well known and almost overused today, but at the time it was a new way to look at system design, especially within the fledgling EDA industry. According to a top-down design methodology, systems are developed and analyzed at four levels of design abstraction:

Conceptual Level Design: The first step in a top-down design methodology. Requirements are defined and specifications written. High-level models are created and used to model the overall system. The integrated system model then becomes an executable specification against which ongoing development work is verified.

Architectural Level Design: High-level models are further partitioned into more detailed blocks. Along with adding design detail, partitioning may be along technology or design domain boundaries. Each partition should be an easily implementable system building block.

Functional Level Design: Architectural blocks are implemented using behavioral models of real world devices. Models are selected and used according to the physical effects to be analyzed. A single functional level block may have multiple representations, depending on the behavior the design team wants to analyze.

Component Level Design: Detailed, low-level models replace functional-level behavioral models. When the component level design is finished, there is typically a one-to-one correspondence between a part on the schematic and a physical part that is used to build the mechatronic system. A component level design may even serve as a manufacturing schematic. If a top-down design flow is executed correctly, a component level design is mainly used to verify that system performance meets requirements and specifications.

Naturally, there are many variations on this view of a top-down design methodology. But while others may describe the methodology in a slightly different way, or use slightly different levels, the underlying principles and results are the same: top-down, multi-level design leads to improved mechatronic system performance, better system quality, and a shortened and more economical product development cycle.

For me, first learning about top-down design was an “Aha!” moment, the revelation of a natural, though seldom used, system development methodology whose principles ring true even today. In short, it just makes sense. But even though it makes sense and promises improvements in design productivity and quality, top-down design has been slow to catch on. But as mechatronic system complexity increases, more and more companies are catching the vision. Top-down design is here to stay as a sound, reliable methodology for mechatronic system development.

What design methodologies do you use? Let me know where your development projects typically start on the top-down design ladder, and what abstraction levels you use.