Mike Jensen's Blog
Mike Jensen's Blog RSSRooster Tail Engineering
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: engineering, physics, system modeling, System simulation, SystemVision, vhdl-ams
Teaching and Learning CAN Bus
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: automotive system design, CAN Bus, mixed-technology, system modeling, System simulation, SystemVision, Vehicle Networking, vhdl-ams
Analog Modeling – Part 6
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, HDL, modeling, system modeling, System simulation, SystemVision, vhdl-ams
Analog Modeling – Part 5
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, HDL, mixed-technology, modeling, simulation, SystemVision, vhdl-ams
Analog Modeling – Part 4
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, HDL, mixed-technology, modeling, simulation, system modeling, System simulation, vhdl-ams training
Analog Modeling – Part 3
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, HDL, mixed-technology, modeling, simulation, system modeling, System simulation
Analog Modeling – Part 2
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, HDL, modeling, simulation, system modeling, System simulation
Analog Modeling – Part 1
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: analog modeling, modeling, simulation, system modeling, System simulation, vhdl-ams
Connecting Tools and Processes
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: Hardware/software co-design, mechatronics, system modeling, System simulation, SystemVision, SystemVision SVX
About Mike Jensen's Blog
Views, insights, and commentary on mechatronic system design and analysis.
Latest Posts
- Rooster Tail Engineering
- Automotive IESF 2012
- Teaching and Learning CAN Bus
- Analog Modeling – Part 6
- Analog Modeling – Part 5
- Analog Modeling – Part 4