VHDL-AMS Model Portability — Fact or Fiction?

Once in awhile I work with customers who want to move VHDL-AMS models between multiple simulators. The ability to do so is one of the great promises of standard modeling languages and, at face value, should be an easy task. After all, if a language is an industry standard, and multiple simulation tools claim to support it, then moving models between tools should be a plug-and-play process, right? Well, the answer is both “yes” and “no”. Sometimes it truly is plug-and-play with models working well across multiple simulators. But more often than not, moving VHDL-AMS models between simulators from different vendors isn’t as easy as you might think. The problem is not in the language itself, but in how the vendor interprets and implements language features.

Standard languages are typically supported by a standards body which, with the help of its members, defines language functionality and documents required features in a Language Reference Manual (LRM). LRMs are weighty documents, usually several hundred pages long, containing everything there is to know about a language. The latest version of the VHDL-AMS LRM  (IEEE STD 1076.1-2009) stretches on for 340+ pages. For the average reader, even someone with a background in modeling and simulation, it is not a light read.

To support a language standard, tool vendors must first interpret the LRM as accurately as possible, then implement their interpretation in a simulation program. Problems relating to model portability start with LRM research and generally take one or two forms. First, the tool vendor needs to determine which language features to support. It shouldn’t come as a surprise that developing simulation support for a new language is not an overnight task. Supporting a new language often takes several man years of development work, especially if language support first requires a new simulator. A simulator won’t be viable in the market until it first supports a core set of language features, but opinions about what constitutes a core feature set vary a bit between tool vendors. This leads to language features supported in one simulator that are not supported in another.

Once a tool vendor determines which language features to support, the next model portability stumbling block results from language feature implementation. In other words, once a tool vendor decides which features to support, the next step is determining exactly how to support each feature. Hopefully, the LRM is written well enough to limit implementation errors. But errors do creep in. Tool vendors exacerbate this problem when they are lax in strict adherence to LRM requirements. As an example, some simulators allow non-standard syntax that might cause errors in tools that more strictly interpret the LRM. Once again, this leads to models that work in the parent simulator but possibly not in others.

Language standards are not new to the simulation tool industry. Nor is the ability to move models between tools from different vendors. Users have successfully done so with standards-based digital models for years (think simulation models based on the popular VHDL and Verilog logic modeling languages). Mixed-technology language standards, however, lag logic modeling languages in model portability, but are gaining popularity. As mixed-technology languages like VHDL-AMS grow in popularity, so will their broader acceptance. And as acceptance grows, so will multi-vendor simulation support until seamless model portability is a reality.

Post Author

Posted October 12th, 2011, by

Post Tags

, , , , ,

Post Comments

1 Comment

About Mike Jensen's Blog

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

Comments

One comment on this post | ↓ Add Your Own

Commented on January 7, 2013 at 1:11 pm
By VHDL-AMS Stress Modeling – Part 1 « Mike Jensen's Blog

[…] VHDL-AMS Model Portability – Fact of Fiction? […]

Add Your Comment

Archives

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