Mike Jensen's Blog

Mike Jensen's Blog RSS

Rooster Tail Engineering

May 3rd, 2012, by | Permalink | No Comments

It is not uncommon for the extraordinary to quickly become the ordinary. Consider cell phones, tablet computers (or just computers in general), hybrid cars, heart transplants, drone aircraft, digital cameras, Amazon.com, Facebook…the list is long and varied. Most of these are considered “ordinary” by today’s standards, but each was little more than an idea in someone’s brain a decade or two ago, and all were considered extraordinary when they debuted. What was cool and unusual yesterday is commonplace today. But even something that might become commonplace can remain extraordinary if we only see it once in a while. My recent weekend excursion is a perfect example…

I live in a medium-sized city on the Eastern edge of the Pacific Northwest in the United States. My wife was born and raised here, so she is well-acquainted with the local sites, sounds, and events. I’m a transplant, but have lived in the area for almost 15 years — nearly a native resident by some standards. Three large reservoirs, one flowing into another in a canyon above our city, store drinking and irrigation water. The Army Corp of Engineers, along with other federal and local water officials, manages the reservoirs. Spring is a particularly busy time for them as they regulate reservoir levels with runoff from melting snow packs and spring rains. It’s not an exact science, but the result is, in select years, an extraordinary spectacle — the Rooster Tail.

The Rooster Tail is, in short, a method for releasing water from the lower of the three reservoirs to reduce erosion in the river bed below the dam (its main purpose) while simultaneously putting on a spectacular and extraordinary show. Released water, under natural pressure from deep in the reservoir, is gravity fed through a 6 foot diameter outlet. Rather than letting the water fall naturally into the riverbed, the outlet diverts the water into a high arc that spreads the water over a large area and resembles…you guessed it… a rooster’s tail.

As we watched the Rooster Tail from across the river, my mother in-law asked if I was, perhaps, looking at the arc of water through my “engineering filter”. She was spot-on. I was indeed watching the Rooster Tail and wondering about all of the details that made it work: size of the outlet, location of the inlet at the base of the dam, diameter of the inlet versus that of the outlet, volume of water exiting the outlet, amount of pressure pushing the water from the base of the dam, etc. Accounting for lots of variables, and making lots of engineering calculations and decisions, went into a process that at a high level is really as simple as “open the valve and let the water out”. And that is what engineers do when we practice our engineering art. Our goal is often to abstract the operation of a complex system up to the “open the valve and let the water out” level, thereby hiding the myriad details of system operation from the user. Sometimes we can make our calculations and decisions using pencil, paper, and a decent scientific calculator. But many times system questions and calculations are too complex to analyze at a pencil and paper level – that’s where multi-physics modeling and simulation shine. With a capable modeling language and robust number-crunching simulator, it’s amazing what a simulation can tell you about your system — all from the comfort of your office.

There are a bunch of engineering details about the Rooster Tail that I don’t know. But thanks to a brief information sheet handed out by the Army Corp of Engineers, I know that water leaves the outlet at a rate between 11,250 and 18,750 US gallons per second (GPS). If you’re not a hydrologist, these figures may not mean a lot to you, so think of it in another way. The Summer Olympics held in London are coming up fast on the world’s calendar. If you’re a fan of swimming competitions (and even if you’re not) take a minute to notice the size of the pool where the main swimming events are held. The typical Olympic pool holds around 660,000 US gallons of water. At 11,250 GPS, the Rooster Tail can drain an Olympic pool in just under a minute – barely enough time for the 100 meter male and female freestyle world record holders to complete the race (disregard the minimum water depth required for swimming). Crank the Rooster Tail up to its upper limit of 18,750 GPS, and the pool is drained dry in less than 36 seconds – just long enough for the 50 meter freestyle world record holders to show their stuff. The Rooster Tail moves an impressive volume of water in a very short time.

Tags: , , , , ,

Automotive IESF 2012

April 25th, 2012, by | Permalink | No Comments

Believe it or not, summer is fast approaching. My daughter is looking forward to the summer break from school. My sons, being a bit older and each completing a couple of semesters of university studies, are facing a summer busy with research or employment. When they yearn for leisure days of summers past, I usually respond with “welcome to adulthood”.

The SystemVision crew is preparing for a busy summer as well. One of our early summer activities is the Mentor Graphics Automotive Integrated Electrical Solutions Forum (IESF) scheduled for June 14 in Detroit, Michigan. This annual automotive industry-focused event is our kick-off for other IESF events throughout the rest of the year.  Topics and locations vary a bit depending on the specific IESF event, but all are chock-full of technical content.

The June 14 event highlights development solutions for automotive systems. Even the most basic automotive platform presents significant design challenges to optimize performance and economy while ensuring passenger safety. No doubt we will see interesting offerings this year as new models roll-out in the fall. If you enjoy cars like I do, the fall new vehicle roll-out is like an early Christmas present.

Automotive design challenges require tools that help development teams turn system concepts into real, rolling vehicles. IESF events are perfect venues for learning about the advanced tools Mentor Graphics offers to help meet real world design challenges. Here are just a few of the topics scheduled for seminars and presentations, in over 40 information-packed technical sessions, at IESF on June 14:

  • Electrical systems design
  • System modeling, simulation, and analysis
  • Network design, integration, and AUTOSAR
  • Embedded software
  • Electronic thermal design and measurement
  • PCB system design

In addition, several industry experts will join the event to share their insights and expertise on key automotive industry topics:

  • David Schutt, PhD and CEO at SAE International, will present his views on the importance of standards in managing the complexity of automotive EE design.
  • Steve Crumb, Executive Director at GENIVI Alliance, will introduce the GENIVI Alliance and explain its efforts to drive broad adoption of an In-Vehicle Infotainment (IVI) open-source development platform.
  • Paul Hansen, from The Hansen Report, will give an update on observations and trends in the automotive electrical and electronics industry.
  • Martin O’Brien, general manager of Mentor Graphics’ Integrated Electrical Systems Division (IESD), explores the philosophy behind Electrical Platform Engineering and the value design teams derive from it.
  • Michael Varnau, Technical Fellow and Technical Manager of Electrical Simulation and Magnetics Design for Power Electronics at Delphi Automotive Systems, will talk about the importance of modeling and simulation-based robust design techniques for improving performance and yield, while reducing warranty and manufacturing costs, in automotive system design.

Mark your calendar for June 14 and plan to join us at this year’s Automotive IESF. Click here for more event information, and click here for a full schedule and registration details.

Tags: , , , , , , ,

Teaching and Learning CAN Bus

April 10th, 2012, by | Permalink | No Comments

One of the great things about working with SystemVision is its ability to model and analyze a variety of systems. One day I might be working with an automotive company discussing the electro-hydraulic performance of an automobile braking system. The next day I could easily be talking with an aerospace company discussing power distribution for the latest generation of a fighter or commercial aircraft. Needless to say, it’s interesting work with a miniscule boredom factor. But SystemVision’s intriguing ability to model and analyze multi-technology systems also turns out to be a bit of a challenge – at least for mere engineering mortals like myself.  Keeping up with even the basics in so many system technologies is nigh impossible. Fortunately there are mathematical and modeling corollaries between engineering disciplines, so understanding the behavior of voltage and current in an electrical system helps in understanding how pressure and fluid flow behave in a hydraulic system, or displacement and force behave in a mechanical system. Becoming well-versed, let alone an expert, in so many types of systems is the stuff of which engineering legends are made — if you’ve met one or two of these “legends”, you know what I’m talking about. In the world of EDA tools, we frequently invest a sizeable chunk of time to learn the basics of a new system technology, and then depend on customers to fill-in our knowledge gaps with the finer and usually important details. We often learn the finer points of a particular system technology piece-by-piece. Such was the case for me a couple of weeks ago while teaching a CAN bus workshop at a customer site.

While it’s easy to view SystemVision as a general purpose system simulator – I sometimes refer to it as just a big number crunching equation solver, not really particular about the type of equations users send it – we sometimes mold that general capability to address a specific engineering need. A perfect example is SystemVision’s CAN SI (Controller Area Network Signal Integrity) Toolkit. This toolkit uses a communication link between SystemVision and Microsoft Excel to automate CAN bus physical layer design and analysis. After defining a CAN network configuration in Excel, users simply click buttons in the Excel interface to auto-generate the network schematic, setup message and simulation data, run simulations, and measure network performance metrics. My assignment in the run-up to the CAN bus workshop was to translate the specific CAN SI Toolkit features and capabilities, as well as SystemVision’s more general vehicle networking modeling and analysis capabilities, into a reasonably coherent training experience for the customer. But before developing the workshop materials, I first had to learn how to “speak” the basics of vehicle networking in general, and CAN bus in specific.

Several years ago I spent 8 weeks in an accelerated language training program in preparation for a two year stay in Japan. If you’ve ever tried to learn a foreign language, you know some of the challenges. You start out by learning some vocabulary as well as a bit of grammar. You then assemble these bits and pieces together, practicing your new-found language skills on anyone who will listen – usually members of your family. When you start out, your new communication skills are limited to one four word sentence like “My name is Fred”, followed by a long list of word triplets like “Japanese is difficult”, “When is dinner”, and “Where am I?”. It’s not pretty, but you get your message across. The better your mentor, the more you can talk in your new language, and the more you talk, the better you communicate. And that’s just how my recent CAN bus workshop went. I went in with CAN bus basics loaded in my brain and a deck of Microsoft PowerPoint slides on my laptop. I’m happy to say the workshop went quite well. The customer learned about some of SystemVision’s cool capabilities in vehicle network and CAN bus modeling and analysis, along with some hands-on labs, and I added to my networking and CAN bus vocabulary and grammar.

So if you have a chance to sit down with a tool vendor who wants to talk about mixed-technology system modeling and simulation, just remember there is a better than even chance that he or she only knows the basics of your particular system or design technology. The value that person brings to your meeting is tool and modeling expertise – if you can describe what to model, the vendor engineer can turn your description into a simulation model. You bring the specific system/application expertise. The vendor engineer brings the modeling and simulation expertise. In many instances, it’s these informal industry/vendor partnerships that move system and simulation technologies forward. Many thanks to the engineers I’ve worked with over the years who patiently explained the finer details of how and why their systems work.

Tags: , , , , , , ,

Analog Modeling – Part 6

March 30th, 2012, by | Permalink | No Comments

In Part 5 of this series we used the mathematical descriptions of the thermal and electrical properties of an incandescent lamp to create the architecture of a VHDL-AMS-based simulation model. Now it’s time to finish the model, and this blog series, by creating a VHDL-AMS entity for the lamp model.

As I mentioned in Part 5, the VHDL-AMS entity defines how a model connects to other elements in a system, and the properties users can adjust to characterize the model’s behavior. In VHDL-AMS, model connections are called “ports”, and user defined properties are called “generics”.

VHDL-AMS supports multiple port types. Since we’re modeling the analog behavior of the lamp, we’ll use terminal ports, which represent analog connections in VHDL-AMS. Terminals also have a defined nature relating to the technology of the model. For our lamp, we’ll attach electrical natures to the terminals.

In general, VHDL-AMS generics are simply user defined constants. Similar to assigning a nature to a terminal, a generic must be assigned a type. For analog modeling, common types for generics include “real” and “integer”. Types can also be technology specific like “temperature” or “resistance”.  With this brief introduction to the main elements in a VHDL-AMS entity, let’s see what we need to define for the lamp model.

The architecture for the lamp model contains a single branch quantity statement:

            quantity v across i through p1 to p2;

Anytime a VHDL-AMS architecture contains a branch quantity statement, there needs to be a corresponding port definition in the entity. Here the model’s voltage (v) and current (i) are defined in relation to p1 and p2. In this case, p1 and p2 represent terminals for the branch, and therefore terminals for the model. Since this is the only branch quantity in the model, p1 and p2 are the only model terminals. Using VHDL-AMS syntax, the port statement in the entity looks like this:

            port (terminal p1,  p2 : electrical);

Next, we need to review the architecture and create a list of constants to be declared and defined. To support the lamp model’s architecture, the following constants need to be defined in the entity:

            alpha, cth, ke, r_cold, rth, temp_amp, temp_cold

Using VHDL-AMS syntax, the generic statement in the entity looks like this:

            generic (

                        alpha : real  := 0.0045;

                        cth : real  := 0.25e-3;

                        ke : real := 0.85e-12;

                        r_cold : resistance := 0.2;

                        rth : real := 400.0;

                        temp_amb : temperature := 27.0;

                        temp_cold : temperature := 27.0);

Note that all of these constants are assigned default values. While default values are not required, it’s good practice unless you want to force users to assign a value prior to simulation. With the generics and ports defined, it’s time to complete the entity:

            Library IEEE;

            Use IEEE.electrical_systems.all;

            Entity lamp is

                   generic (

                                    alpha : real  := 0.0045;

                                    cth : real  := 0.25e-3;

                                    ke : real := 0.85e-12;

                                    r_cold : resistance := 0.2;

                                    rth : real := 400.0;

                                    temp_amb : temperature := 27.0;

                                    temp_cold : temperature := 27.0);

                   port (terminal p1,  p2 : electrical);

            end entity lamp;

The first two statements simply access an IEEE standard VHDL-AMS library that tells the model what an electrical nature for the terminals means. We use the “entity lamp is” statement to mark the start of the entity, simply copy our generic and port statements into the entity, and then use the “end entity lamp” statement to finish.

And that’s it. If we combine the entity above with the architecture in Part 5, we have a complete model for an incandescent lamp. Although this is a simple analog model, the general development process outlined in Part 2 applies to analog models of any complexity. Next time you need to model an analog device, try using this process as a model development roadmap.

Tags: , , , , , ,

Analog Modeling – Part 5

March 23rd, 2012, by | Permalink | No Comments

If you’ve followed this Analog Modeling series, you know we’ve been talking about a general process for HDL-based modeling of analog behavior. If you’re new to the discussion, or simply want to review what we’ve talked about so far, check these links: Part 1, Part 2, Part 3, Part 4.

In my last post we developed a set of equations describing the relationship between the thermal and electrical properties of an incandescent lamp. Following the process outlined in Part 2, we now need to implement the equations using our modeling language of choice.

I’ve written before about VHDL-AMS, which is the language I will use to complete our incandescent lamp model. I chose VHDL-AMS for several reasons, two of the most important being capability and portability.

VHDL-AMS is very capable, having ample horsepower to model complex device and system behavior across a wide range of technologies. This isn’t to say, however, that the language is complex. In fact, its syntax and semantics are quite straight forward.

VHDL-AMS models are also very portable, a direct result of the language being an IEEE-sponsored industry standard. As long as my models adhere to the standard, I can move them between supporting simulators.

In addition to these language properties, I chose VHDL-AMS for our incandescent lamp model because it’s a major contributing factor to the power and flexibility of SystemVision.

VHDL-AMS models are divided into two sections: an entity and an architecture. The entity defines how the model connects to other elements of a system, and what properties users can adjust to characterize the model’s performance. The architecture describes the model’s function by implementing device equations using VHDL-AMS syntax. From a “which comes first” perspective, it makes the most sense to start model development with the architecture. Once the architecture is complete, the entity easily follows since its structure and content simply support the architecture. With this in mind, let’s work on the architecture.

From Analog Modeling – Par 4 we have the following device equations:

   Filament resistance = Rcold x (1.0 + Alpha x (Tfil – Tcold))

   Voltage = Current x Filament resistance

   Hflow(thermal) = Power(electrical)

   Hflow(conductive) = (Tfil – Tamb) / Rth

   Hflow(capacitive) = Cth x d(Tfil) / dt

   Hflow(radiated) = Ke x (Tfil**4 – Tamb**4)

   Hflow(total) = Hflow(conductive) + Hflow(capacitive) + Hflow(radiated)

Let’s first convert these equations to VHDL-AMS syntax (note that some of the elements are renamed to make the equations more compact):

   r_temp == r_cold*(1.0 + alpha*(temp_fil – temp_cold_K));

   v == i*r_temp;

   hflow == v*i;

   hflow == cth*temp_fil’dot + ke*SIGN(temp_fil – temp_amb_K)*(temp_fil**4

            – temp_amb_K**4) + (temp_fil – temp_amb_K)/rth;

Now let’s define constants and additional analog elements that support these equations. Since Kelvin is the default temperature scale for VHDL-AMS, let’s first define a couple of constants to convert degrees Celsius to Kelvin:

   constant temp_amb_K : real := temp_amb + 273.15;

   constant temp_cold_K : real := temp_cold + 273.15;

Next, we need to define analog elements, called “quantities” in VHDL-AMS, to help us define items in the equations that vary with time:

   quantity v across i through p1 to p2;

   quantity r_temp : resistance;

   quantity temp_fil : temperature;

   quantity hflow : heat_flow;

The first quantity statement defines how the voltage across and current through the lamp relate to the model pins (we will define the pins in the entity). The remaining quantity statements define analog elements that not only support the model equations, but also become waveforms that we can plot after a simulation. For example, once the model is finished we can plot the filament’s resistance and temperature, as well as the total heat flow for the lamp.

These are all of the architecture elements we need to completely describe the operation of our lamp. The only thing left to do is add an architecture wrapper around them:

   architecture dyn_therm of Lamp is

      constant temp_amb_K : real := temp_amb + 273.18;

      constant temp_cold_K : real := temp_cold + 273.18;

      quantity v across i through p1 to p2;

      quantity r_temp : resistance;

      quantity temp_fil : temperature;

      quantity hflow : heat_flow;

   begin

      r_temp == r_cold*(1.0 + alpha*(temp_fil – temp_cold_K));

      v == i*r_temp;

      hflow == v*i;

      hflow == cth*temp_fil’dot + ke*SIGN(temp_fil – temp_amb_K)*(temp_fil**4

                    - temp_amb_K**4) + (temp_fil – temp_amb_K)/rth;

   end architecture dyn_therm;

And that’s it. We now have a complete VHDL-AMS architecture, called “dyn_therm”, describing the relationship between the thermal and electrical properties of an incandescent lamp. While we could have used another modeling language to implement the lamp’s behavior, VHDL-AMS is pretty hard to beat for clarity and ease of coding. In the final post of this series, Analog Modeling – Par 6, we’ll finish the model by adding the VHDL-AMS entity.

Tags: , , , , , ,

Analog Modeling – Part 4

March 2nd, 2012, by | Permalink | No Comments

It’s time to dig a little deeper into the incandescent lamp behavior I introduced in Part 3 of this blog series. My goal is to select a set of equations that best describe the elements of the lamp’s behavior that I want to quantify during simulation. Recall my comment in Part 3 that a lamp has several characteristics worth analyzing including electrical properties, thermal properties, aging properties, and photometric properties. For this post I will focus on the lamp’s relationship between electrical and thermal power. If you have attended any of our VHDL-AMS Introduction workshops or training classes, you will no doubt recognize this discussion.

Electrically, an incandescent lamp behaves like a temperature dependent resistor. The filament’s resistance increases with temperature, which in turn affects the lamp’s electrical power characteristics. From a thermal perspective, as the filament heats up, it dissipates power through thermal conductance, thermal capacitance, and radiation. So the lamp consumes electrical power, and dissipate thermal power. Since the lamp must obey conservation of energy laws, we have:

      Electrical power = Thermal power

This is a simple, high-level, mathematical relationship. Let’s add some detail by deriving equations for each power type. Deriving an equation for the electrical power starts with the standard, textbook definition:

      Electrical power = Voltage x Current

But we need to account for the change in filament resistance. We can do so by considering Ohm’s Law:

      Voltage = Current x Resistance

We know that filament resistance varies with temperature. For our discussion, let’s assume resistance is related to temperature as follows:

      Filament resistance = Rcold x (1.0 + Alpha x (Tfil – Tcold))

Where Rcold is the filament’s cold resistance, Tcold is the filament’s cold temperature, Tfil is the filament’s heated temperature which increases over time as the lamp approaches full brightness, and Alpha is the filament’s resistive temperature coefficient. Given this equation for the filament resistance, Ohm’s Law for the lamp becomes:

      Voltage = Current x Filament resistance

Now let’s discuss the thermal power which is represented as a heat flow in the lamp. As I mentioned above, we will assume there are three elements to the lamp’s thermal power: thermal conductance, thermal capacitance, and radiation. The total thermal power, or total heat flow, is the sum of heat flows from each element. Let’s consider these heat flows in order. Heat flow due to thermal conductance can be characterized as:

      Hflow(conductive) = (Tfil – Tamb) / Rth

Where Tfil is the filament’s temperature, Tamb is the ambient temperature, and Rth is the filament’s thermal resistance. This equation tells us that, for a given thermal resistant, conductive heat flow increases with higher filament temperatures. Heat flow due to thermal capacitance can be characterized as:

      Hflow(capacitive) = Cth x d(Tfil) / dt

Where Cth is the thermal capacitance and Tfil is the filament’s temperature. Using this relationship, we set capacitive heat flow to increase proportionally with the filament temperature’s rate of change. Finally, radiated heat flow can be characterized as:

      Hflow(radiated) = Ke x (Tfil**4 – Tamb**4)

Where Ke is the radiated energy coefficient, Tfil is the filament’s temperature, and Tamb is the ambient temperature. Recalling that thermal power is simply the sum of all heat flows in the lamp, and using these three heat flow definitions, the lamp’s total heat flow is:

      Hflow(total) = Hflow(conductive) + Hflow(capacitive) + Hflow(radiated)

Now that we have derived equations representing the incandescent lamp’s electrical and thermal power relationships, we can move on to the third step in our modeling process (outlined in Analog Modeling – Part 2), which is:

  • Implement the equations and relationships using syntactically correct statements based on your modeling language of choice

Which I will do using my modeling language of choice, VHDL-AMS, in my next blog post: Analog Modeling – Part 5.

Tags: , , , , , , ,

Analog Modeling – Part 3

February 10th, 2012, by | Permalink | No Comments

Welcome to the third installment in my Analog Modeling blog series. In Part 1 I wrote about why equations are important for simulation. In Part 2 I suggested a process flow for turning device equations into a simulation model, and introduced the basic structure of a VHDL-AMS model. Now it’s time to begin the model definition process. As I outlined in Part 2, the first step is deciding what you want your model to tell you about the device, which may not be as obvious as it sounds.

The most important thing to remember when deciding what details you need to know about device behavior is this: calculations require CPU time, and CPU time directly affects how many seconds, minutes, and maybe hours will tick away on your wristwatch before the simulation is finished. Saying “I want to know everything there is to know about this device” is okay as long as you understand that the complexity of your model is directly proportional to the number of details you want to know about the device’s operation. I’ll say it again: more complexity means more of your time watching the simulation progress meter chug along.  If you think about it, seldom do you really need to know every single detail about how a device operates. More than likely you will only be interested in 2 or 3 important performance metrics. Let’s use an incandescent lamp model as an example.

An incandescent lamp is designed to turn electricity into lumens. This transformation takes place by connecting a resistive wire, or filament (usually made of tungsten), to a source of electricity. As current passes through the filament, it heats up until it glows. The filament is enclosed in a glass bulb which is typically filled with an inert gas to reduce filament evaporation and oxidation. With this brief introduction in mind, here are some lamp properties that might be interesting to quantify in a simulation:

  • Light intensity
  • Electrical vs. thermal power
  • Efficacy (Lumens per Watt)
  • Filament temperature
  • Rate of filament evaporation
  • Rate of filament oxidation

If you create a lamp model to quantify all of these properties, your model will be quite complex, and potentially compute intensive. Following the analog modeling guidelines mentioned earlier, you need to narrow the options by deciding what you really want the model to tell you about the lamp’s performance. For our discussion, let’s focus on the relationship between the lamp’s electrical and thermal properties.

In my next blog post, Analog Modeling – Part 4, we’ll move to the next step in the analog modeling process and select equations that quantify the lamp’s interactions between electrical and thermal power.

Tags: , , , , , ,

Analog Modeling – Part 2

February 2nd, 2012, by | Permalink | No Comments

In Analog Modeling – Part 1 I reviewed the importance of equation selection in the analog modeling process. In a nutshell, the first step in getting good simulation results is choosing equations that best describe the behavior or device you want to analyze. Your analog equation set could be as simple as a single transfer function describing the relationship between the inputs and outputs of a block, or as complex as the set of mathematical relationships characterizing a detailed motor model. Regardless of the complexity, turning your set of equations into a viable simulation model may seem a bit daunting. Like most engineering tasks, however, if you establish and use a proven process, even the most complicated task is reduced to a simple set of practical steps. For analog modeling using a general hardware description language (HDL), I recommend the following process flow:

  • Decide what you want your model to tell you about the device (hint: you may want to know more than the standard equations tell you)
  • Derive the characteristic equations and relationships for internal and external variables to calculate the information you want to know
  • Implement the equations and relationships using syntactically correct statements based on your modeling language choice
  • Declare and define appropriate objects to support your model statements

Before discussing the details of these steps, it’s worthwhile to understand how a model is structured in the HDL you plan to use. For this post, I’ll describe the general structure for a model written in VHDL-AMS. Keep in mind that model structures for other languages may differ a little…or a lot.

A typical VHDL-AMS model has two parts: an Entity and an Architecture. Each has a specific purpose. A VHDL-AMS Entity defines the parameters you can adjust to tune your model’s behavior, and describes how the model connects to other elements in a system. For example, here is the Entity for a simple resistor:

   entity resistor is
     generic (
        resistance : real := 100.0);
     port (
        terminal p1, p2 : electrical);
   end entity resistor;

The Generic section establishes a parameter called “resistance” and sets it to a value of 100. The Port section names two terminals, “p1″ and “p2″, and defines them as electrical in nature, meaning simulation results will be stored using electrical units. Any performance definition for this resistor model must be related to these two terminals.

A VHDL-AMS Architecture defines how the device operates, and connects the operation definition to the information in the model Entity. Here is a sample Architecture for the resistor model:

   architecture ideal of resistor is
      quantity voltage across current through p1 to p2;
    begin
      voltage == current * resistance;
   end architecture ideal;

This simple Architecture implements the device equation (in this case Ohm’s law) in VHDL-AMS syntax, and defines how the equation relates to terminals p1 and p2 in the Entity. Notice that the equation

   voltage == current * resistance

is very similar to the textbook definition of Ohm’s Law: v = i * r. The “quantity” statement defines how the “voltage” and “current” elements in the equation are associated with terminals p1 and p2. In this case, voltage is calculated across, and current through, the terminals. Knowing how to structure a model for a particular HDL simplifies the modeling process.

With this brief introduction to VHDL-AMS model structure, we can add some detail to our modeling process discussion. In my next post I’ll give some pointers on deciding what details you need to know about a device.

Tags: , , , , ,

Analog Modeling – Part 1

January 25th, 2012, by | Permalink | No Comments

I recently spent some time rummaging around my basement. I suppose my basement is not unlike many others — it’s kind of my family’s catch-all storage place for items too big to fit in a closet. Besides housing my HVAC and water heating systems, my basement is home to a variety of holiday decorations, lots of canned, bottled, and bulk food items, a small collection of mismatched folding tables and chairs, a few carpet remnants from a recent remodeling project, and the “archive” section of my personal library. I say “archive” since the stacks of books in my basement are the overflow from the stacks in my office. Yeah, I love books, and my large and diverse collection is a virtual window into my rather broad range of interests — probably too broad for my own good. My book-buying mantra is “you can never have too much reference material”. When I add a book to my library, it has a permanent home; selling or giving away any of them is a bit like abandoning a trusted friend. I’ll be the first to admit that books are a bit of an obsession for me, but I digress…

A downside of having so many books is that I sometimes forget what titles I have. Having finished my basement rummage, I was on my way back upstairs when a long forgotten little green book caught my eye: Engineering Formulas, 7th Edition, by Kurt and Reiner Gieck. I inherited this tiny yet information packed volume a decade or so ago from my dad’s personal reference library. The book covers a broad range of engineering topics including statics, dynamics, thermodynamics, electricity, and controls, just to name a few. While it’s not meant to be a detailed mathematical tome on all things engineering, it is a pretty good primer for new topics, and a reasonable review for subjects I haven’t worked in for awhile. For me, it was a great re-discovery and will no doubt be a handy reference when I need to research analog device operation before creating a model.

Before simulation there has to be modeling, and analog modeling starts with a mathematical description of behavior. I know this isn’t rocket science, but in the crunch of a hectic design schedule, it’s easy to forget that behind every symbol in a simulatable schematic there has to be some sort of mathematical model, and inside every mathematical model there is at least one equation. It’s pretty hard to overstate the importance of equations to the modeling and simulation process. If your simulation results look good, chances are a quality set of equations helped determine the answer. If your simulation results look wacky, equations could easily be the problem. In short, quality of simulation results is directly related to the quality of device equations. Getting the equations right is an important first step toward simulation results that make sense.

Selecting device equations is a bit of a subjective process. The equations you select or derive to describe a device’s behavior may well be different from those I would choose. A lot of this has to do with the information, technology, and modeling experience we have at hand. But selecting equations is only the beginning of the modeling process. With equations in hand, the next big hurdle is figuring out how to turn them into a viable simulation model. A bad implementation of even excellent equations can cause simulation problems. In coming blog posts I’ll suggest some general guidelines to help you turn device equations into useful VHDL-AMS simulation models.

Next in this Analog Modeling series: Analog Modeling – Part 2

Tags: , , , , ,

Connecting Tools and Processes

January 13th, 2012, by | Permalink | No Comments

Searching the Internet is like having a giant, international reference library at your fingertips. If you know what you’re looking for and have a reasonable idea of where to look, with a little patience you can usual find some pretty interesting material related to your search topic – okay, you can also find a bunch of stuff you aren’t looking for, but as I often say, “That’s a topic for a different discussion…” I occasionally search for information on mechatronic system simulation – just to see what new challenges design teams face. One of my recent searches turned-up a whitepaper on automotive electrical system simulation. And as I started reading the paper, I smiled my “there it is again” smile…

It seems most folks who write papers on mechatronic system simulation feel the need to remind readers of an obvious fact: modern systems are complicated. You usually don’t have to read too far into the opening paragraphs of a paper before being reminded “…modern systems are increasing in complexity…” I’ll be the first to admit that I’ve occasionally used similar phraseology when writing papers, datasheets, and brochures. While it’s a well-worn and very tired marketing phrase, and despite being painstakingly obvious (particularly if you are the one doing the designing), increasing system complexity is a fact of engineering life. And with compute power enabling better and more advanced system control, engineers are encouraged to work on even more complex ideas. What is complex today will be considered simple tomorrow.

In a way it’s a bit ironic that, in many cases, mechatronic system engineering gets more complex in order to simplify and improve the end-user experience. Stated another way, the degree of design difficulty goes up in order to reduce the degree of use difficulty. It’s actually kind of a neat thing if you think about it: we’re making complex technology approachable, and in some cases invisible, to folks who really aren’t interested in the technical details. They just want what they buy or use to work. But there comes a point where even the best design team needs a bit of design help, a time when interactions between system components are too complicated to manually design and track. A system development flow that used to require a single design tool now needs multiple tools. And system complexity factors drive the need for multiple tools to automatically share design data. Maybe a multi-physics hardware simulator needs to talk to a control algorithm. Perhaps a test development program needs to communicate with an electronic circuit simulator. Or a mechanical simulation might need to swap information with an electronic circuit simulation, which in turn needs to share details with a control algorithm — all under the watchful eye of a test program. The design tool combinations and interactions can easily get as complex as the systems.

I recently joined a customer conference call to talk about SystemVision linked-up with software control algorithms through SystemVision conneXion (SVX). The customer just wanted to run their hardware design with the controlling software. I wrote a blog post about this configuration several months ago. While the SVX technology is great for running software with a model of the mechatronic hardware, there is a bit more under SVX’s hood.

SystemVision conneXion is an extensible program for connecting disparate applications and processes. The SVX application server manages communication through application or process-specific clients. Want to include a C/C++ or Java algorithm in your simulation? SVX supports clients for both. How about adding a model written in SystemC, or an algorithm modeled in Simulink, or maybe even the system’s mechatronic elements modeled in SystemVision, to the simulation mix. Just use the available clients. And what if you want to use LabVIEW to get an early start on test program development? Since I mentioned it, you probably won’t be surprised to learn SVX also supports a LabVIEW client. And the technology is flexible enough to enable additional clients if needed.

The point of all this is simple: there are many good tools available for designing specific elements of a system, but most are limited to a single design domain. What design teams have long needed is a way to connect applications and processes together in a single simulation session. Enter SVX.

Want to know more about SVX? Click over to the SystemVision conneXion homepage for more details. Or post a comment or send me an email with your question.

Tags: , , , , ,

Views, insights, and commentary on mechatronic system design and analysis.

System Modeling Training Courses