Posts Tagged ‘vhdl-ams’

16 June, 2014

I have mentioned in earlier posts that one of my responsibilities on the SystemVision team is teaching training classes. If users want formal SystemVision or VHDL-AMS training, I am usually the instructor. It is fun and occasionally gets me out of my office for a few days.

Because SystemVision is such a flexible modeling and analysis environment with a broad range of applications (think mixed-signal analog and digital + multi-technology), students in my classes often have a mix of technical expertise and design responsibilities. One class may be for an aerospace customer, another for an automotive customer, and still another for an industrial controls customer. And even though a class may be for a single customer, students invariably have a mix of engineering assignments. This makes the classes even more interesting for me since I learn about advances in many different areas. As usual, the teacher often becomes the student.

One of the reasons I like teaching classes is the Demo Factor. And what is the Demo Factor? Simply the opportunity to demonstrate capabilities students are interested in and will most certainly benefit their design flows, but capabilities usually not covered in the training material. These are usually on-the-fly demonstrations, meaning a student asks “Can SystemVision do [something]?”, and I spend part of the class time, usually while students work on lab exercises, creating a short demonstration. Building these short demos is fun and interesting, and often leads to the Wow Factor, the response I often get when a student learns SystemVision will do something useful and cool that their current design process does not support. Take, for example, a short waveform analyzer demo I did in a recent class.

One of the students wanted to know if SystemVision supports converting a waveform into a text or comma separated value (csv) file. The short answer is “yes”. Wow Factor One. But like most answers when SystemVision is the topic, the initial response is often followed with “but there is more”. I then went on to demonstrate that SystemVision’s waveform analyzer can also plot data from a text or csv file. Why does this matter? Because this little feature lets users directly compare their simulation results with lab test data. Just save lab measurements to a text or csv file, then load the measurement file into SystemVision’s analyzer and plot the data. Wow Factor Two. And then to make the demonstration even more interesting, I showed how to quickly and automatically generate a simulation model directly from a plotted waveform. Such models can be used as system driving functions during simulation. Wow Factor Three. Students immediately chatted about how this simple text-based capability might be useful in their design work.

Okay, so manipulating text-based data is not really that complicated. While it may seem a cool capability to some users, for others it is an expected feature, like cup holders in your car. And compared to the long list of SystemVision’s really cool and more advanced modeling, simulation, and analysis capabilities, it may seem worth little mention. But my recent training class Wow Factor experience reinforced an important reminder: simple can be both useful and impressive, and is almost always better. If a task is simple, keep it that way; if it is complicated, simplify it.

, , , , ,

31 May, 2014

It is official: SystemVision 5.10.3 is released and ready for download from SupportNet. The SystemVision engineering team made over 120 updates and improvements for this new release. Here are some of the highlights:

  • Relative and Absolute statistical tolerances support improved flexibility when defining device parameter tolerancing. “Relative” defines a tolerance as a percentage of the default value; “Absolute” defines a tolerance as a fixed delta from the default.
  • Asymmetric VHDL-AMS statistical distributions give you more flexibility when setting designs for a Monte Carlo (statistical) analysis. Asymmetric distributions can be applied to a model’s internal or external parameters, can be coupled with symmetric or asymmetric tolerances, and now work for SystemVision’s Sensitivity, Worst Case, and Extreme Value analyses.
  • Model Wizard is renamed as “Model and Symbol Wizard” to reflect new support for generating simulation models and schematic symbols from existing design schematics. The wizard is now SystemVision’s consolidated, central location for creating models and symbols for your simulations.
  • Experiment Manager is re-released after key improvements to help you setup, run, and manage simulation experiments for your designs.
  • New datasheet-based models add flexibility and more detail to your system analyses. Several standard datasheet models expand the Datasheet Model Builder’s capabilities. And the first additions to SystemVision’s new advanced datasheet model library support important device effects such as aging, high temperature, and low temperature.
  • 64-bit waveform analyzer and configurable analyzer memory allocation let you run longer/larger simulations (think a Monte Carlo analysis of several thousand runs for a complex system), and easily work with larger simulation databases.
  • Shared Library updates make it easier to include your custom libraries in a new or existing project, and to access your custom libraries from SystemVision’s Search/Place Symbols browser.

And SystemVision 5.10.3 includes a sneak peek at two new productivity tools:

  • Worst Case Scenario Manager uses the advance datasheet models (mentioned above) to help you setup and run multiple worst case simulation scenarios. The result is a detailed view of your system’s worst case performance as components change due to aging and temperature effects.
  • Batch Simulation Tool lets you setup multiple simulation and analysis tasks that can run while you work on other projects, or while you are away from the office. Along with running batch simulations, you can easily compare new simulation results with those from an earlier analysis – a handy feature if you are updating simulation tools, tweaking model behavior, etc. And you can tell the tool to send you an email when a batch simulation starts and ends.

The Worst Case Scenario Manager and Batch Simulation Tool are beta features for this release. Read the release notes for more information on accessing SystemVision’s beta features.

If you are already a SystemVision user, download the new release and run the install program. Then be sure to review the release notes for more release details. And if you are new to SystemVision and want to take a closer look, contact your local Mentor Graphics sales and support team, or add a comment to this blog post and I will get back to you.

, , , ,

21 January, 2014

I wrote a month or so ago about the challenge of finding — or creating — simulation models. In that post, I suggested there are three general categories of engineers looking for a model:

  • Give me a model
  • Help me understand the model
  • Help me develop a model

For the “help me develop a model” category, I mentioned Graphical Modeling and Language-based Modeling as two popular model development options. These are useful methods when all you have is equations describing a device’s performance. But there is a modeling need that sits between having a canned simulation model and needing to create one from scratch. It’s a modeling middle-ground where you have component data from which to generate your model. For example, you may have a list of SPICE parameters, or perhaps VHDL-AMS code, that you want to turn into a simulation model for SystemVision. Or you may want to create a model from component datasheet performance parameters or curves. Enter the SystemVision Model Wizard, newly added to the  SystemVision 5.10 release.

Model Wizard accepts component data in multiple formats, including SPICE parameters, VHDL-AMS code, datasheet performance tables, and datasheet performance curves. From these data sources, the wizard generates a SPICE or VHDL-AMS model along with a schematic symbol you can immediately use in a design. The generated model’s format depends on the input data’s format. If you start with SPICE parameters, you end up with a SPICE model. If you start with VHDL-AMS code or datasheet information, the end result is a VHDL-AMS model. With device data in-hand, the wizard walks you through five easy steps:

  1. Select your model data type (SPICE, VHDL-AMS, Datasheet)
  2. Choose the base SystemVision model that matches your data
  3. Select or create your symbol
  4. Match the ports in your model to the pins on your symbol
  5. Set default values for model parameters

When these steps are complete, you simply save the model and start using it, which brings me to another new feature in SystemVision 5.10: Shared Libraries. Shared Libraries support the Model Wizard and let you create your own custom libraries of simulation models and schematic symbols. The Model Wizard’s final step is saving your model to the local project or a standalone library . If you want to use the model only in your local project, then save it with the project. But if you save your new model in a library outside of a project, you can access that library’s models and symbols from any of your SystemVision projects.

If you have SystemVision 5.10 installed, try the Model Wizard and see how easy it is to create simulation models from a variety of data formats. And if you still need to install the 5.10 release, hop over to SupportNet to download the software and begin the installation. Since feedback is always a good thing, as you use the wizard to create models, post a comment or send me an email and let me know what you think.

, , , ,

10 December, 2013

Many of my recent interactions with customers have been on a single theme: modeling. Simulation is a great tool, but only if you have models that tell the simulator what to do. Models vary in type and complexity, but they all share a common purpose: to tell you something about how a device or system works, often in a specific application or under specific operating conditions. But there is a gap, an often very wide gap, between wanting to simulate a design and having a model that tells an accurate story for your system (notice that I did not say “the accurate story” since how you model your system will depend on what you want to know about it – accuracy is a byproduct of purpose).

When it comes to modeling, I find that engineers are generally divided into three groups: give me a model, help me understand the model, and help me develop a model. Depending on project priorities and how critical the need, the same engineer may spend time in each group on a single project.

The “give me a model” group is either under a time crunch to complete the analyses and finish the design, or is not familiar with other modeling options. The advantage for this group is that models are plentiful. They are available from a variety of sources including component manufacturers, third party vendors, in-house modeling groups, and tool suppliers. SPICE models are particularly popular in this category. The disadvantage, however, is twofold: model quality may be suspect, and model functionality may be limited with no way to improve it.

An engineer in the “help me understand the model” group typically has a model but needs to better understand how it works. Requirements for understanding the model range from needing to document the model’s operation, to improving performance by updating or adding functionality. Depending on structure and format, however, understanding a model someone else developed can be a real challenge. For example, have you ever tried to decipher the internal workings of a SPICE macromodel for a PWM controller chip? Not so easy.

For the “help me develop a model” group, either an existing model is not doing the job, or a model search returned zero results. Engineers in this group can either go without, or build a model from scratch. Going without usually means doing manual calculations, and pen, paper, and calculator become the engineer’s most trusted design companions. Funny thing, but not many years ago I visited a group of engineers at a major automotive OEM who claimed this is exactly how they handled much of their design work: reams of paper shuttled between design groups. Apparently modeling and simulation were not a priority. A bit hard to believe, given the complexity of modern automotive design. But I digress. Fortunately, if you are in the “build a model” category, you have options for model format and structure. In working with customers, I find the two most popular approaches are graphical modeling and language-based modeling. I will talk about each of these in future posts.

, , , , , ,

3 July, 2013

I recently spent some time at a big-box store, an international retailer specializing in home furnishings and décor. Not the type of store where I usually spend a lot of my shopping time, but friends and family rave about it, so I decided to make a quick visit to see what all the fuss is about.

Aisles in this store are somewhat narrow and have a lot of twists and turns. They wander so much in and out of merchandise displays, that one of the first things you see when you enter the store is a map of the shopping floor so you get a rough idea of how to get from Point A to Point B as you shop. Arrows on the floor help you move in the right direction (from entrance to check-out), and there are a couple of shortcuts shown on the map to help you get to certain areas of the store faster.

So there I was wandering through the store following the arrows in the twisting, turning aisles, when I see a dad rolling his son around in a full-size shopping cart, the type of heavy duty metal-framed cart you typically find at a grocery store. Not really that unusual you might think, for a Saturday afternoon shopping trip to a big-box store, except the cart seemed a bit odd. As I watched the dad pushing the cart, it looked like he was doing the shopping cart equivalent of automotive “power slides” around aisle corners – the kind of slide you might see in an automotive drifting race, where drivers negotiate turns by steering out of, rather than into the turn, then accelerating just enough so traction for the rear wheels breaks loose and the back end of the car slides toward the outside of the turn. This combination of steering and sliding move the car smoothly through the turn. If you have never seen a power slide race, it is worth looking one up on your favorite sports channel or Internet search website. I thought this a strange move for a shopping cart, particularly since I did not hear the sound of rubber wheels doing a chattering skid across a linoleum covered floor. Then I saw it, the simple solution for maneuvering clumsy shopping carts around crooked store aisles: four wheel steering. I imagine this solution is neither unique to this retailer, nor even a very recent innovation in shopping cart design. But when I go shopping and need a cart to haul my stuff around the store in, the only option I have is a cart with front wheels that steer, and rear wheels in a fixed, straight ahead position. So seeing a cart with all four wheels that help with steering was new for me. And it made perfect sense for the quick turning, narrow store aisles.

Okay, so adding four wheel steering to a shopping cart is not a very complicated process. In fact, I doubt if there was much, if any, engineering design involved. I can imagine a slow day on the shopping cart assembly floor, with assembly technicians trying to think-up an entertaining activity to break the boredom. One says “Hey! I wonder what would happen if we added a second pair of swivel wheels to one of our carts?” And just as simple as that, the four wheel steering shopping cart was born. In fact, this is how many engineering design solutions are born as well. We keep experimenting, sometimes on paper, sometimes with real hardware in the lab, trying different solutions until we find one that fits. Figuring out “how” sometimes comes first; understanding “why” occasionally waits until the “how” works. If you are like me, this process is usually incremental. I find that letting my brain work on something for a while usually helps me find a workable solution. Sometimes solutions come to mind after only a few minutes or maybe an hour or two. Then there are solutions that take a week or two, or maybe even a couple of months, to figure out. And the end solution is usually pretty simple. My brain may start out thinking in great detail about complicated options, but I usually arrive at a solution that is much simpler than where my thought experiments started. I also find that the magnitude of a problem does not necessarily correlate to the amount of time it takes to find a solution. Sometimes big problems are solved in a flash; sometimes simple problems take a while to figure out. Regardless of the design challenge, however, solution options need to be thoroughly thought through.

As it turns out, modeling and simulation are great ways to think through a design problem. Just trying to model a system is often a great way to figure out what really matters to the design and what is technical fluff. And simulation helps you confirm how your model, and therefore your system, performs. Key to this modeling-to-simulation flow is choosing the right modeling language. There are, of course, many modeling languages to choose from. Some are general purpose, while others are targeted to a specific engineering problem or analysis. Among the most flexible is the class of analog hardware description languages tuned for analyzing systems that contain a mix of engineering domains. Two of the most capable languages are VHDL-AMS, the multi-domain and mixed-signal IEEE standard language, and the proprietary but similarly capable MAST language from Synopsys®, Inc. Both languages are well suited for modeling the complex behavior of mechatronic systems. Choosing which language to use depends on what simulator you have access to. Using MAST means you choose to use the Saber® simulator from Synopsys. Using VHDL-AMS gives you access to a broader range of simulators like SystemVision® from Mentor Graphics®.

Some of our customers are working through this very choice. They have Saber and use MAST, but are looking for the modeling and environment flexibility offered by VHDL-AMS, SystemVision, and other tools in the Mentor Graphics portfolio. The challenge, of course, is migrating their existing MAST-based models and designs to VHDL-AMS.  To help with this migration process, the SystemVision Engineering team developed a MAST to VHDL-AMS converter. It does a nice job of converting MAST source code and netlist-based models into standard VHDL-AMS syntax , providing a good starting point for moving designs forward to an IEEE standard modeling language. Just as the simple addition of four-wheel steering to a shopping cart makes it easy to maneuver narrow, twisting shopping center aisles, SystemVision’s MAST to VHDL-AMS converter is a simple solution that eases the transition from a proprietary modeling and simulation environment to a more flexible environment based on proven IEEE standards.

, , , , , ,

5 June, 2013

It is official: SystemVision 5.10 is finished and available for download from SupportNet. Even though this release took a bit longer than normal to complete, I believe the wait is worth it. Key among the new features are the following:

Schematic symbol toolbar: Prior to SystemVision 5.10, placing symbols in a schematic required opening either SystemVision’s Search/Place Symbols dialog or DxDataBook to first access the symbol library. While both methods are easy to use, opening either tool is just an extra step between users and creating a schematic. Enter the new SystemVision symbol toolbar. This new toolbar displays quick access buttons for several commonly used electronic components (think passives, diodes, transistors, opamps) and signal sources. To place a symbol, just click the button for the desired part to attach the symbol to your cursor, then move the cursor into your schematic to place the part. Want quick access to parts that do not appear in the toolbar? No problem: you can customize the toolbar to access any symbol from the SystemVision library.

Model Wizard: While models are the key to any simulation, a suitable model can also be hard to find or create. To help you develop your own model from a variety of data sources, SystemVision 5.10 introduces our new Model Wizard. This wizard helps you parameterize an existing SystemVision model to meet a simulation need, or create a model using a new VHDL-AMS, SPICE, or datasheet data source. The wizard walks you through the process, from selecting your model source, to creating a schematic symbol and connecting it to the model, to saving the new model and symbol to a project or shared library. Model Wizard sets a new standard for wizard-based, multi-physics simulation model development.

Datasheet Model Builder: Most electronic components have some sort of datasheet giving detailed information about the performance of the device. It is not always easy, however, to turn the datasheet details into a working simulation model. Why? Because you have to have a device model whose parameters match those in the datasheet. Datasheet Model Builder (DMB) is a new GUI-based tool for parameterizing datasheet-specific VHDL-AMS based models already in the SystemVision model library. The DMB user interface looks similar to a datasheet for the device, so you can take parameter values directly from datasheet tables and enter them in the DMB tables. The result is a new simulation model and symbol for the device. DMB currently supports modeling for standard passive components (resistors, capacitors, inductors), diodes, opamps, MOSFETs, Linear regulators, and transmission lines. We plan to add support for more devices in future releases.

In addition to these and other new features, Engineering addressed 70+ improvement requests, delivering on our continued commitment to develop and support functionality and features requested by the SystemVision user community.

For more release details, visit the SystemVision 5.10 download page at SupportNet, our award winning customer service website, to review the latest release notes. Better yet, contact your local Mentor Graphics field team or leave a comment and I will respond.

, , , , ,

21 May, 2013

I have written a time or two about my daughter’s piano recitals. As luck would have it, springtime is yet another popular recital season. This time my daughter had two – one for her own piano teacher’s studio, and the other as an invited duet accompanist to play in a friend’s recital. All-in-all, not a bad way to spend a mid-spring evening. As I listened to students play their prepared pieces, I noticed that some sat down at the keyboard with printed music in-hand, while others sat down with the notes and fingering stored in their brains. And even some of those that did bring music did not appear to give it much attention – the printed music just a crutch in case their memory froze while performing. While watching the performers, particularly those playing from memory, I realized that each relied on both muscle and auditory memory. Each had trained their hands and fingers to be in a certain position at a particular time in the piece, and listening to themselves play was how each checked for errors.

As I thought about this, I remembered my days playing basketball in high school. We spent part of each practice drilling on fundamental skills: dribbling, passing, shooting, etc. Not really very exciting work, but necessary so our muscles would know how to respond automatically in game-time situations. It turns out this focus on fundamentals is not just for collegiate and pre-collegiate players. I heard a radio interview recently of a former NBA basketball coach, who won a record 11 NBA championships during his coaching carrier, explain how he regularly led his players, the folks getting paid millions of dollars for their on-court expertise, through practice drills focused on fine-tuning fundamental skills. Just like the piano players at the recital, his teams’ success depended in part on practicing and memorizing skills, then recalling them when needed.

So what does this have to do with mechatronic system modeling and simulation? I think plenty, especially for companies that design and build complicated systems with long lifetimes. Not long ago I was listening-in on a customer conference call. We were discussing modeling and simulation as a way to archive system information – partly meant to preserve design info, and partly meant to preserve engineering expertise. In my Preserving Expertise blog post from last October, I mentioned a colleague’s proposal to use modeling and simulation as a way to pass system and engineering expertise from one generation of engineers to another. One of the customer engineers on the conference call recognized that this potential knowledge drain could present a real problem for his company. He called it the “boomer cliff” since engineers from the baby boomer generation are retiring and taking their years of system knowledge and expertise – their engineering muscle memory – with them to their favorite golf course, fishing hole, or Caribbean cruise. And he saw modeling and simulation as a possible way to preserve the expertise that would certainly leave his company in coming years.

Companies really are faced with a dilemma. While one solution is to hire back retiring engineers as highly paid consultants, this will only work for a time until the siren-song of retirement activities grows stronger than the allure of a post-retirement paycheck. The more I think about it, the more using modeling and simulation to preserve engineering knowledge really does make sense. When archived with the proper model, simulation, and data analysis information, packaging a system design for future reference is a great way to preserve engineering muscle memory for any system. Does your company need to preserve system and engineering expertise for the future? If so, how do you plan to do it?

, , , ,

25 March, 2013

I’ve been away from my blog for a couple of months helping the SystemVision Engineering team with a few details related to our upcoming release: SystemVision 5.10. We’re excited about this new release. It introduces, among other things, a new way to create simulation models from a variety of data sources. We think this new capability will make it much easier to create SystemVision simulation models. The new release should be out in the next few weeks, and I’ll write more once it is finished. Now back to my stress modeling series…

In Part 1 and Part 2 of this series I explained the foundation for adding stress calculations to a simulation model: in this case, a simple resistor defined by Ohm’s Law. Part 1 developed the basic resistor model. Part 2 showed how to include power calculations by adding just a couple of lines of model code. As is, this is a fully functional model that will tell me important details about how my resistor performs in a circuit. But VHDL-AMS gives me the power to go even further, so I can have my model notify me, while the simulation is running, if my resistor’s power exceeds a certain limit. To do this, I use a combination of two VHDL-AMS commands (ASSERT and REPORT) and two attributes (‘ABOVE and ‘IMAGE). As I did in Part 2, I will create a new architecture to add this new capability t0 my model:

   1: architecture power2 of resistor is

   2:  quantity v across i through p1 to p2;

   3:  quantity pwr : power;

   4: begin

   5:  assert pwr’above(max_pwr)

   6:    report “*** Maximum power of ” & real’image(max_pwr)

   7:           & ” watts exceeded at ” & real’image(now) & ” seconds.”

   8:           & ” Measured power is: ” & real’image(pwr) & ” watts. ***”

   9:    severity warning;

   10:    v == i*res;

   11:    pwr == v*i;

   12: end architecture power2;

If you compare this power2 architecture with the power1 architecture in Part 2, you will notice that Lines 1-4 and Lines 10-12 are the same, except for the architecture name change. The added functionality in the power2 architecture, in Lines 5-9, defines how the resistor’s power (defined by the pwr quantity) is monitored and reported when an overpower, or stress condition, is detected. It starts with the ASSERT command and ‘ABOVE attributes in Line 5. The ‘ABOVE attribute monitors a VHDL-AMS quantity, in this case the resistor’s power, to see if it exceeds a level defined by the max_pwr limit. This limit is added as a generic to the model entity as follows:

   A:  generic (

   B:    res : resistance;

   C:    max_pwr : power := 0.25);

The original entity contained just Lines A-B. Line C adds the power limit used in Line 5. When the resistor power exceeds the max_pwr limit, the ASSERT command forces something to happen, in this case to report that the power was exceeded and what the calculated power is. This information is displayed in the simulation log using the REPORT command and the ‘IMAGE attribute in Lines 6-8. While this covers three lines in the model, the simulator sees this as one continuous line due to the ampersand (&) line continuation character. The REPORT command instructs the simulation to send text strings to the simulation log, so anything in quotes is reported as-is. The ‘IMAGE attribute also lets me include values for quantities as part of the reported message. In this case, the “real’image(max_pwr)” syntax reports the power limit setting as defined by the user. So if the value of max_pwr is left at its default in Line C, the Line 6 portion of the REPORT command sends the following information to the simulation log when the limit is exceeded:

*** Maximum power of 0.25

The “real’image(now)” syntax in Line 7 allows me to extract the simulation time at which the power limit is exceeded, and the “real’image(pwr)” syntax in Line 8 sends the detected value of the resistor’s power, contained in the pwr quantity, to the simulation log. To complete the example, assume that max_pwr is left at its default, that this limit is exceeded at 1.4 seconds, and that the actual power is 0.45 watts. The message sent to the log, as reported with the REPORT command above, looks something like this:

 *** Maximum power of 0.25 watts exceeded at 1.4 seconds. Measured power is: 0.45 watts. ***

Finally, Line 9 sets the severity of the ASSERT command. For my resistor model, the severity is set to “warning” to inform the user that the resistor model may produce unexpected results. Other severity options are “note” which is used to report general information from the simulation, “error” which indicates something is wrong with the model, and “failure” which can be used to indicate a condition that should normally never occur. What a simulator does with a severity level depends on the simulator’s definition. SystemVision simply logs details when the severity is set to note or warning, but halts the simulation when the severity is set to error or failure.

And there you have it: a resistor model that not only calculates its own power dissipation, but also reports when the power exceeds a user defined limit. If you have a copy of SystemVision, or another simulator that supports VHDL-AMS, try combining the model entity and architectures from Part 1, Part 2, and Part 3 into a single model file and experiment with a simulation. Make sure to setup your circuit so the resistor’s power exceeds the limit you set. Then look at the simulation log window to see how the REPORT command records its message. You might also try playing with the severity level to see how your simulator handles each setting. I have one more architecture that helps with viewing resistor power states in a waveform viewer, but explaining the model would make even a new blog entry a bit long. If you’re interested in seeing this architecture, of if you want a fully assembled version of the entire model, send me an email and I will send it to you.

, , , , , ,

28 January, 2013

In Part 1 of this series I started work on a simple resistor model as a way to illustrate some of the flexibility the VHDL-AMS language offers when creating simulation models. Recall that one of the advantages of VHDL-AMS is adding detail to models – a benefit not available with all modeling languages or methods. With VHDL-AMS, it’s possible to get your model and simulator to report performance details not available with other tools. To illustrate this flexibility, my resistor model will include a power dissipation calculation, and a comparison of the result with a user defined power limit to determine stress conditions.

Before jumping into the next model piece, however, I’ll tie up a loose end I left dangling in my earlier post. I mentioned the use of “==” when formulating device equations in a VHDL-AMS model. And at that time I said to simply interpret the syntax as “equal to”. But that definition doesn’t quite cover what’s going on inside the simulator. The “==” is more accurately interpreted as “balance both sides of the equation”. Once the simulator generates a matrix of equations that represent the system, the unknowns are adjusted during simulation, through a series of iterations, until all equations are solved within a user defined accuracy.

Now back to my resistor model. I’m going to jump right into the next architecture, so if you need a review (or a preview) of the model so far, take a quick look at Part 1. Up to this point it’s a basic Ohm’s Law-based resistor: voltage across the resistor is directly proportional to the product of the current and resistance. Now it’s time to add commands to calculate the power.

Recall once again from your first physics or electric circuits class that the power dissipated in a resistor is dependent on any two of its three operating parameters: voltage, current, resistance. There are a few different combinations of these parameters that calculate power, but I’ll use the following:

   power = voltage x current

Based on this equation, here is the next section in my model:

   1: architecture power1 of resistor is

   2:   quantity vres across ires through p1 to p2;

   3:   quantity pwr : power;

   4: begin

   5:   vres == ires*res;

   6:   pwr == v*i;

   7: end architecture power1;

Here I’ve created a new architecture named “power1” for the resistor model. This architecture is the same as the “basic” architecture in my earlier post, except that its name is changed and Lines 3 and 6 are added to setup the power calculation. Line 3 defines a new quantity named “pwr” (remember that a quantity is an analog element in a model) with an assigned VHDL-AMS type of “power”. Note that pwr is not directly associated with the p1 and p2 ports of the model. Therefore the type assignment simply determines what units will be used (in this case “watts”) to plot the pwr quantity. Line 6 calculates pwr as the product of the voltage across the resistor and the current through it, as define in the standard power equation above. This architecture can be added to the model in Part 1 to create a resistor model with one entity and two architectures (recall that a VHDL-AMS model can only have one entity, but multiple architectures). When I use the resistor model in a SystemVision schematic, I can select which architecture to use for that resistor instance. If I choose the power1 architecture, the resistor’s power is calculated at each time or frequency step during the simulation, and becomes a waveform I can plot when the simulation is finished.

Now that my basic resistor is complete, I can add details that will determine if the power exceeds a user defined power rating. In Part 3 of this series I’ll create another new architecture that detects when the resistor’s power exceeds a user defined limit, and notifies me when there is a problem.

, , , , , ,

24 July, 2012

Lately I’ve been working with customers interested in using SystemVision to simulate either a real production design, or some sort of evaluation test circuit. To a customer, however, each ran into the “don’t have a simulation model” challenge for one or more devices in their system. Despite SystemVision’s large VHDL-AMS and SPICE model libraries, we didn’t have a suitable model match. And Internet searches didn’t turn up anything useful. So what is an engineer to do? The answer might be easier than you think.

SystemVision is a powerful and flexible modeling and simulation platform. Part of this power and flexibility is centered in the IEEE standard VHDL-AMS modeling language. Using VHDL-AMS, engineers can create device models of almost any type and complexity. A pretty good deal if you already know VHDL-AMS, but a pretty tough row to hoe if you first need to learn the language before creating any models. Fortunately, there is an easier way — Graphical Component Modeling.

Graphical Component Modeling (GCM) is a technique for building device models from simple, low-level building blocks. It’s kind of like having a modeling Erector Set: you have a box full of modeling pieces from which you can build an almost limitless variety of useful simulation models. With a little creative imagination and a bit of engineering inspiration, you can use GCM techniques to develop some pretty amazing models without writing a single line of VHDL-AMS code. In a way, GCM is like creating SPICE macromodels or Simulink control algorithm models, but with a couple of key differences.

First, GCM isn’t stuck modeling in a single discipline (think about the electrical-only limitations of SPICE). With SystemVision’s building-block library, it’s easy to create models in a variety of technologies, including models where the input technology is different from the output technology. Consider a pressure sensor, for example, where the input is a pressure, and the output might be a voltage or current. GCM simplifies device modeling, giving engineers a simulation toolbox full of building blocks for single and mixed-technology device modeling. Pretty cool stuff.

Second, GCM simplifies conserved system modeling using simple real number processing based on a library of math function building blocks. This is similar to control system-level signal-flow modeling for which Simulink is famous, but GCM also accounts for energy conservation in the device – not a common feature in signal-flow type models. How does this work? The answer is in SystemVision’s ability to efficiently and effectively model both conserved and signal-flow systems, which GCM uses to model physical behavior. The technique is simple: use signal-flow building blocks to model device functions, then wrap the signal-flow model in conserved building blocks to ensure energy conservation and accurate modeling of physical behavior.

Graphical Component Modeling truly is a powerful technique for developing sophisticated device models without the overhead of knowing (or learning) a new modeling language. In future posts I’ll introduce a few GCM-based model examples to illustrate GCM’s power and flexibility. Stay tuned…

In the mean time, post a comment and let me know what analog/mixed-signal/mixed-technology modeling challenges you see in your design work. GCM just might be a viable solution.

, , , , ,