System Level HDL-topia

I remember my early days in the EDA industry. SPICE was little more than a teenager (I suppose this dates me a bit). I had recently finished a 5-year stint working for the United States Air Force and had just joined a young company as an Applications Engineer to help promote the features and benefits of system design using Hardware Description Languages (HDLs). Though HDL use for semiconductor design was already on the rise, HDL-based modeling for mechatronic system design was pretty much a new concept. At the time, using HDLs for mechatronic system development was a real “missionary sell”. Even before selling our tools, we first had to sell customers on why HDL-based design made sense. Now, a couple of decades later, HDLs are going strong.

If you pop over to Wikipedia (yeah, I’ll confess, I like Wikipedia – if nothing else, it gives me a good jumping-off point for researching stuff) and look up “HDL”, you’ll find something like this in the first paragraph:

In electronics, a hardware description language or HDL is any language from a class of computer languages and/or programming languages for formal description of electronic circuits, and more specifically, digital logic. It can describe the circuit’s operation, its design and organization, and tests to verify its operation by means of simulation.

Though a bit electronics-centric for today’s mechatronic systems, it’s not a bad definition. Adding a few tweaks for mechatronic system design, the definition might read something like this:

“In mechatronic system design, an HDL is a class of programming languages for the formal description of mechatronic systems. Design teams use HDLs to describe a system’s operation (regardless of design domain), its design and organization, and test benches to verify operation by means of simulation.”

A wide variety of HDLs are used today. Some are focused on a very narrow solution space for solving specific problems unique to a particular technology. Others have a larger scope and address a broader range of design challenges. I call this latter group “system-level HDLs”. The IEEE 1076.1 standard, also called VHDL-AMS, is in this category. What features should a system-level HDL have? Here are four of the key requirements on my list:


Depending on which one of your engineering buddies you talk to, you may get a “life is digital” or “life is analog” view of the world. Digital technology gets most of the press these days, and rightly so. It is by far the most common way we interact with the technologies that crop up in every corner of our lives. No news here. But digital interfaces largely insulate us from what is predominantly an analog world. Getting the interface right, quickly and accurately going from analog to digital and back again, often defines the success or failure of a design. During the development process, design teams need to move seamlessly between analog and digital development.


Seldom is a system a technology island, depending solely on a single design domain. Even if the blocks in a system are tied to a specific technology, chances are that several blocks either drive, or are driven by, a different technology. The ability to handle physical domains outside of the traditional EDA/electronics space is critical to effective mechatronic system design. Think hydraulics, pneumatics, mechanics, thermal, etc. Technology interfaces, in other words the boundary between physical domains, are more important than ever. Interface issues need to be an important part of design considerations from the beginning of the system development process. Being able to model multiple technologies is the key.


Complex system design rarely happens at a single level of abstraction, even if high-level design is more of a pencil-and-paper exercise than a keyboard-and-mouse operation. As I outlined in my recent Mastering Design Abstraction blog post, a complex design can easily move through four different design phases: conceptual level, architectural level, functional level, and component level. Design teams need the ability to model system behavior at any level of abstraction, from high-level building blocks to detailed device physics. Any HDL worth using must support modeling at multiple levels of abstraction, and allow mixing of design levels in a single schematic and simulation.

Simulator Independent

Many EDA companies claim to support some sort of mechatronic system simulator. No surprise, since the market has decent growth potential. Only a handful of simulators, however, have the compute power necessary to simulate complex mechatronic systems (you guessed it…SystemVision is on this very short list). Some EDA companies will argue the benefits of proprietary modeling languages over industry standard, simulator independent HDLs. Whatever other benefits may accrue from proprietary languages, one big (but unspoken) reason EDA companies push them is simple: tool sales. If you want to use a proprietary language to create simulation models, you are locked to the tool that supports the language. Having worked with both types of languages, and both types of companies, industry standard, simulator independent languages win, hands down. Standard, independent languages allow simulation models to move among design groups or companies without the sometimes onerous baggage of simulator requirements. Design teams can choose the simulator best suited for the job without being handcuffed by a proprietary modeling language.

Hardware description languages make complex system design and analysis practical. Notice that I didn’t say “possible”. It turns out that some technology companies, even a few with household-name status, still use tried-and-true “pencil-and-paper” methods to design their systems. While they may not actually shuffle reams of paper between design groups, they do use development tools that are past their prime. But even these hold-outs will eventually need to adopt an HDL or two in order to keep pace with shortened design cycles and demands for increased functionality.

How about your design methods? Do you use HDLs in your design flow? If so, which one(s)?

Post Author

Posted February 12th, 2010, by

Post Tags

, , , , , , , , , ,

Post Comments

No Comments

About Mike Jensen's Blog

Views, insights, and commentary on mechatronic system design and analysis. Mike Jensen's Blog


Add Your Comment


April 2015
  • Simulation for Test
  • December 2014
  • Motor Down
  • October 2014
  • Reliability vs Robustness
  • June 2014
  • Wow Factor
  • May 2014
  • SystemVision 5.10.3
  • March 2014
  • IESF 2014: Military & Aerospace
  • Engineering Oops!
  • Big Engineering
  • January 2014
  • SystemVision Model Wizard
  • December 2013
  • SystemVision 5.10.2
  • Modeling: An Engineer’s Dilemma
  • October 2013
  • What is Your Legacy?
  • September 2013
  • Automotive IESF 2013
  • July 2013
  • Simple Design Solutions
  • June 2013
  • SystemVision 5.10
  • May 2013
  • Engineering Muscle Memory
  • EDA vs. Windows 8
  • March 2013
  • VHDL-AMS Stress Modeling – Part 3
  • January 2013
  • VHDL-AMS Stress Modeling – Part 2
  • VHDL-AMS Stress Modeling – Part 1
  • December 2012
  • Practice! Practice!
  • November 2012
  • Sharing Tool Expertise
  • October 2012
  • Preserving Expertise
  • Virtual Prototyping — Really?
  • Innovations in Motion Control Design
  • September 2012
  • Game Changers
  • Do We Overdesign?
  • August 2012
  • Tsunami Remnants
  • July 2012
  • A New Look at Device Modeling
  • SystemVision 5.9
  • June 2012
  • Veyron Physics
  • May 2012
  • Rooster Tail Engineering
  • April 2012
  • Automotive IESF 2012
  • Teaching and Learning CAN Bus
  • March 2012
  • Analog Modeling – Part 6
  • Analog Modeling – Part 5
  • Analog Modeling – Part 4
  • February 2012
  • Analog Modeling – Part 3
  • Analog Modeling – Part 2
  • January 2012
  • Analog Modeling – Part 1
  • Connecting Tools and Processes
  • December 2011
  • Turning-Off and Tuning-In
  • Use vs. Experience
  • Analyzing the Big Picture
  • November 2011
  • Simulating for Reliability
  • October 2011
  • SystemVision 5.8
  • VHDL-AMS Model Portability — Fact or Fiction?
  • September 2011
  • IESF 2011 Moves to Frankfurt
  • Simulation Troubleshooting
  • August 2011
  • Qualities of VHDL-AMS Quantities
  • Military & Aerospace IESF 2011
  • Touring Johnson Space Center
  • July 2011
  • Engineering versus Science
  • June 2011
  • System Reengineering
  • May 2011
  • Integrating Hardware and Software Design
  • Engine Remote Start
  • Integrated System Design
  • Simulation Experiments (Part 3)
  • April 2011
  • Automotive IESF 2011
  • Pushbutton Cars
  • System Simulation with FEA-Base Motor Models
  • March 2011
  • Simulation Experiments (Part 2)
  • Simulation Experiments (Part 1)
  • Japan: Patience and Grace Amid Disaster
  • Top Gear = Driving Fun
  • February 2011
  • Buoyancy
  • Ideas in Motion
  • January 2011
  • The Mechanical Half of Mechatronics
  • Detroit Auto Show
  • Signal-flow vs Conserved System Modeling
  • SystemVision 5.7…Ready, Set, Go!
  • December 2010
  • SystemVision and Windows 7
  • Friction Vacation
  • Simulation Beyond Volts and Amps (Part 4)
  • November 2010
  • Simulation Beyond Volts and Amps (Part 3)
  • Simulation Beyond Volts and Amps (Part 2)
  • Simulation Beyond Volts and Amps (Part 1)
  • October 2010
  • SAE Convergence Recap (and an Unexpected Surprise)
  • VHDL-AMS Black Belt
  • Converging on SAE Convergence
  • System Design vs System Repair
  • September 2010
  • What’s the “AMS” in VHDL-AMS?
  • How Sensitive is Your System?
  • Do You Trust Your Simulator?
  • August 2010
  • What’s in a SPICE Model?
  • Cycling + Gravity = Pain
  • NI Week: Fun for Engineers
  • June 2010
  • Are You a Flexible Thinker?
  • VHDL-AMS and Switch Hysteresis
  • May 2010
  • VHDL-AMS Revisited
  • Segway to U3-X
  • Atomic Glue
  • March 2010
  • IESF Recap
  • February 2010
  • IESF is Coming…
  • System Level HDL-topia
  • January 2010
  • Mastering Design Abstraction
  • The Joy of Disassembly