I have mentioned before that one of the more enjoyable parts of my job is getting out of the office to meet with folks who use, or have an interest in using, SystemVision in their product development process. I always learn something, and can hopefully share a bit of what I know as well. I recently enjoyed just such an experience.
Earlier this year, a long-time Mentor Graphics customer, and recent SystemVision client, called to schedule VHDL-AMS language training. As a quick reminder, VHDL-AMS is an IEEE standard language for modeling mixed-signal, multi-physics systems (click here to read one of my earlier posts on the language). After a little back-and-forth, we agreed on dates and I marked them on my calendar.
Teaching training classes is often an interesting experience, and perhaps even a little nerve wracking, since I usually have few details about how the students use, or intend to use SystemVision. It is interesting for the very same reason it is nerve wracking: student expertise and work duties can cover a broad range of applications and technologies which sometimes makes it hard to cover all use cases, and answer all of the questions, in enough detail to make the class immediately useful in their work. For this most recent class, however, I was in luck. All of the students worked together in the same group, and they all had similar applications for SystemVision. But this time the application was a little peculiar for modeling and simulation generally, and SystemVision specifically.
Most customers use SystemVision to design systems from scratch, or to jump in mid-design to investigate and solve a particularly troublesome problem. And a handful of customers use SystemVision to get an early start on test program development, using a virtual prototype of the finished design as a test development platform. But the group in my training class uses SystemVision on the opposite end of the system life cycle. The end system is already in service, and has been for many, many years. Over time, existing test procedures for these systems get a bit antiquated, or the need for additional tests arises. So my students reverse engineer these legacy systems to not only figure out how they work, but also to develop test procedures based on the new, documented understanding.
So how does modeling figure into their work flow? Turns out the answer is pretty simple in theory, but a bit more complex in practice. As is often the case when building large, complex systems (think airplanes, automobiles, etc.), many of the sub-systems are developed and acquired through third parties. And these same third parties very often do not supply detailed design data, let alone simulation models, sighting intellectual property rights and restrictions. So students in my class often need to create simulation models with little in the way of specifications, detailed documentation, or bench measurement data. Sounds fun, right?
Once they have a working design based on schematics created from a combination of custom and standard models, they run through a series of fault simulations, failing one part at a time, documenting the change in performance, then failing the next part and repeating the simulation and documentation process. When the modeling and simulation are complete and the results documented, all of this information is turned into test procedures that technicians use to keep the systems running for years to come.
So the VHDL-AMS class ended, and I learned another way to use simulation — this time in a post-design, post-deployment, reverse engineering and test development process. Who knew? What is the most peculiar way you have seen simulation used for design analysis?