Mike Jensen's BlogMike Jensen's Blog RSS
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?
I have read a lot in recent months about Windows 8, Microsoft’s latest incarnation of its flagship Windows operating system. While there are many new features over and above its Windows 7 predecessor, one thing that makes me quite curious about Windows 8 is its optimization for touchscreen technology.
Note that I have yet to use Windows 8, but I have used several other touchscreen devices on the market (think tablets, phones, MP3 players, etc.). In general, I like the touchscreen interface for what these devices are fundamentally designed to do: consume information or data. Touchscreens are great for reading, playing games, listening to music, and browsing the Internet. But I think they are significantly less useful for generating information or data beyond writing a document, using a spreadsheet, or taking photographs. Microsoft’s Windows 8, however, has me thinking a bit more about the usability of touchscreen environments for one simple reason: the simulation and analysis tools I work with everyday only run on a Windows platform (currently WinXP or Win7).
My keyboard and mouse are indispensable for creating schematics, running simulations, and analyzing simulation data. Like most folks, I am pretty adept at using these mechanical devices to tell my computer what to do. But if operating system suppliers continue their focus on touchscreen technology (and I expect they will), it is only a matter of time before Electric Design Automation (EDA) vendors will have to revamp their tools for a touchscreen environment. What will that future look like from an EDA tool user’s perspective? Admittedly, my crystal ball is a bit cloudy on this topic. I can visualize touchscreen use for simple circuits, but as designs get more complex, I see touchscreen technology being more of a road block than a useful utility. Creating detailed system schematics, or routing compact PC boards, often requires precise onscreen graphics control – something my mouse gives me, but my extra-large hands and fingers are much less adept at without a significant touchscreen zoom factor. But maybe I am trying to view the future of EDA user interfaces through my limited ”what I know now” lens. Perhaps it’s time to throw away what I know about user interface design and start with a fresh set of ideas.
Hollywood’s depiction of user interfaces (think of the Ironman or Batman movie franchises, for example) show futuristic screens that appear in front of users and are manipulated not by a mouse and keyboard, but by hand movements and gestures (okay, even my Wii and Xbox can already do some of this, though I don’t expect to use either for system design any time soon). This Hollywood vision is, by definition, even more optimistic than current touchscreen implementations. But maybe someday our interactions with technology will imitate the movies. I for one am very interested to see how EDA tools will adapt to user interface advances. What do you think the future of EDA tool interfaces looks like?
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;
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.
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;
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.
One of the great values of modeling with a hardware description language is simply this: you can tell a model to calculate and report all sorts of information about what’s happening inside it. Consider a generic electrical model, for example. Simulators will report voltages across and currents through the device. But what if you want to know how much power is dissipated in the device? Or if the power exceeds a preset limit? Or maybe if the part is overstressed and possibly fails? And what if you want the device behavior to change on failure? With the right hardware description language and simulator combination, you can model and analyze all of these device characteristics and more.
VHDL-AMS is among the most flexible and powerful hardware description languages available for modeling device behavior, and it’s an IEEE standard so it’s supported by more than one tool vendor. I’ve talked about various aspects of VHDL-AMS in earlier blog posts:
- VHDL-AMS Model Portability – Fact of Fiction?
- Qualities of VHDL-AMS Quantities
- VHDL-AMS Black Belt
- What’s the “AMS” in VHDL-AMS?
- VHDL-AMS and Switch Hysteresis
- VHDL-AMS Revisited
Among its many strengths is the ability mentioned above – you can tell your models to calculate operation details that normally might not be available with other modeling languages and methods. I’ll use a simple resistor model to illustrate what I’m talking about. Before jumping into the modeling discussion, however, let’s quickly review a few VHDL-AMS fundamentals:
- VHDL-AMS is a superset of the VHDL digital modeling language. If you can model a device’s behavior in standard VHDL, you can model the same behavior in VHDL-AMS. VHDL-AMS simply adds analog and mixed-signal extensions to VHDL.
- VHDL-AMS models are constructed in two parts: the ENTITY and the ARCHITECTURE. The entity defines how the model will connect to other models in a circuit or system. The architecture defines the device behavior. A device model can have multiple architectures, but only one entity. The entity and one or more architectures work together to determine how the model behaves during a simulation.
- VHDL-AMS is a strongly typed language, meaning most elements in a model must be associated with a physical type. For example, the pins of my resistor model example will be defined as electrical type. Typing is important since VHDL-AMS is a multi-physics modeling language, meaning it’s suitable for modeling electrical and non-electrical behavior. Simulators use this typing information to check for correct connections (e.g. to prevent you from connecting an electrical pin to a hydraulic pin) and to determine what physical units to use when plotting waveforms (e.g. so voltage across and current through my resistor are plotted in units of volts and amps respectively).
- A VHDL-AMS “quantity” is an analog element in a model that is calculated by the simulator. For example, the voltage across and current through my resistor will be defined as quantities for my model. I can also define other quantities such as power and self-heating temperature. VHDL-AMS quantities are assigned a type, either by association (e.g. by port declarations) or explicitly in the quantity declaration (e.g. power or temperature).
With this short review in mind, let’s take a look at my resistor model. Recall from basic physics (or your first electrical circuits class), that the electrical characteristics of a resistor are defined by Ohm’s Law:
voltage = current x resistance
In other words, the voltage across a resistor is equal to the current through the resistor multiplied by the resistance. So with a constant resistance, an increase in current produces an increase in voltage proportional to the resistance. I’ll use this simple equation as the foundation for my resistor model.
Deciding how to start building a model is partly determined by personal preference, and partly by model complexity. For device behavior defined by complex mathematics, it is often easier to define the architecture first, then build the entity to support the architecture. But since my model is based on a simple equation, I’m going to start by defining the entity. Just like a real resistor, my model will have two ports (e.g. p1 and p2) and a resistance value (e.g. res). Here is what my entity looks like (note that I’ve added line numbers for ease of reference):
1: library ieee;
2: use ieee.electrical_systems.all;
3: entity resistor is
4: generic (
5: res: resistance := 0.0);
6: port (
7: terminal p1 : electrical;
8: terminal p2 : electrical);
9: end entity resistor;
Line 1 connects the standard IEEE VHDL-AMS library to the model. This library contains pre-defined type definitions. Line 2 instructs the model to use type definitions in the electrical_systems package within the IEEE library. Line 3 starts the formal entity definition. Lines 4 and 5 declare a property called res, typed as a resistance, with a default value of 0.0. I can use this property to assign my model a specific resistance value in a circuit. Lines 6 through 8 define the two ports for my model. Both are defined as terminals, which are analog ports in VHDL-AMS, and assigned electrical types. Line 9 closes the entity definition. Now let’s take a look at the architecture.
I will develop functionality for my resistor model using multiple architectures. My first architecture models basic resistor behavior using Ohm’s Law as defined above. Additional architectures will calculate the power dissipated in the resistor, and then determine if the power exceeds a user-defined limit. Here is the first architecture:
10: architecture basic of resistor is
11: quantity vres across ires through p1 to p2;
13: vres == ires*res;
14: end architecture basic;
Line 10 opens the architecture definition, gives it a name (basic), and links the architecture with my entity (resistor). Again, my resistor model is allowed only one entity, but I can define as many architectures as suites me. I simply need to give each architecture a different name. Line 11 begins the declaration section of the architecture, defines my analog quantities vres and ires, and associates each with the p1 and p2 ports defined in the entity. The simulator calculates these quantities, with vres calculated as the voltage across ports p1 and p2, and ires calculated as the current flowing through the ports from p1 to p2. Note that defining the port direction as “p1 to p2” is significant: in this case p1 is defined as having a higher potential than p2. Line 12 ends the declaration section and starts the model definition. Line 13 implements Ohm’s Law using VHDL-AMS syntax. The only difference between the Ohm’s Law equation and the VHDL-AMS implementation is the “==” syntax, which has significance for how the simulator handles the relationship between vres and the product of ires and res; I’ll save the detailed explanation for another blog post. For this discussion just consider “==” to mean “equal to”. Finally, Line 14 closes the basic architecture and completes this first version of my resistor model.
And that’s it for a basic Ohm’s Law-based resistor, which will work in any simulator that supports the full VHDL-AMS language standard. In my next blog post I’ll add another architecture that calculates the power dissipated in the resistor.
I recently attended a piano recital for a young man in my neighborhood who studies music at a local university. He has natural musical aptitude and is an awesome piano talent. During his recital he played compositions from popular yet long since deceased composers: Beethoven, Liszt, Debussy, Prokofiev. If you’re not familiar with any of these names, not to worry. I only know them because my wife’s family is super musical. Kind of funny how most recitals I attend feature music from dead musicians, as if to suggest there are no modern day composers whose music is worth performing. Certainly not the case, but yet another topic best left for a future discussion. Getting back to the recital…
As I watched the young man perform, I was amazed at his dexterity and agility at the piano. Though the expression may be a bit trite, his hands literally danced up and down the keyboard. While I’ve only had a couple of years of piano lessons in my life (hasn’t everybody?), I appreciated not only his talent, but also the hours and hours of practice required to perform at his level – and mind you, this was his Junior year recital. Should he have a Senior year recital, I hope to get an invitation to that performance as well. I’m sure his performance will be no less amazing.
Thinking about his hours of practice set me thinking about engineering design. His musical expertise comes by way of practice, and in order for his practice to be effective he has to spend hours upon hours at the keyboard rehearsing until each note and nuance becomes automatic. While his passion showed in his performance, passion alone for any worthwhile endeavor isn’t enough. It’s the practice that turns passion into skill.
Developing engineering expertise is, in many ways, much like building musical expertise. While engineering school is the typical path for building a solid technical foundation for our careers, it’s how we build on that foundation that really matters. Our level of passion, and our commitment to continual practice (yes, I mean engineering design practice), in many ways determines our career success. Engineering’s corollary to a musical score is a design specification. And just as the musical score tells a musician what to play, but not how to play it, the design specification guides our engineering efforts, but we are free to decide how we turn the written details into a working system. The path from specification to working system may be filled with false starts and mistakes, but willingness to make mistakes is key to perfecting a design – as long as the mistakes happen in simulation or the lab, not in the final product.
I have another neighbor who, at 80 years old, is still going strong as a practicing engineer. I refer to him as “an engineer’s engineer”, complete with a shirt pocket full of pencils and pens and a scientific calculator. I’m pretty sure he hasn’t used many simulation tools during his career – though I must admit I wouldn’t be surprised if he has. But I can imagine him practicing the old-fashioned way, hovered over a green engineering notepad with mechanical pencil moving briskly across the page, and calculator keys near-meltdown as he works on his latest project. The point is that it’s not so much how we practice, but that we do. As engineers, our “performances” are judged on the quality of the systems we design. In a very real sense, each system design we work on is practice for the next. And if your days and weeks are sometimes consumed by writing reports and doing project paper work, try working on a personal project or two. But if you develop projects for you and your family’s use, take the advice from David Penrose, an Aerospace industry engineer, who was interviewed for the November 2012 issue of Circuit Cellar magazine. David’s advice was simple: “Never automate something your spouse will have to fix when you are away”. Wise counsel indeed.
In my last post I talked about using modeling and simulation to preserve design and technical expertise within a company. This seems a valuable methodology for preventing technical ‘brain drain’ within a corporation. Recently, however, I ran into another simulation dilemma related to sharing simulation knowledge: how to share simulation expertise between companies.
Often when I talk with potential customers, they want to know how other companies use SystemVision specifically, and multi-physics, mixed-signal modeling and simulation generally, to improve development processes and reduce product development and lifecycle costs. Always good questions. Unfortunately, the answers usually aren’t easy to come by. It’s not that the SystemVision crew doesn’t know how design teams use our family of tools — we do, but we don’t share such details without permission. Our challenge is that companies benefitting from the power and flexibility of SystemVision are typically reluctant to share expertise and methodologies. Why? Key among several reasons is technology leaders often consider their design methods an important part of their competitive advantage. Yeah. I get that.
As an Electronic Design Automation (EDA) tool vendor, Mentor Graphics markets the value of our modeling and simulation tools as an important addition to an effective and efficient system design flow. But the perceived value of design tools, particularly those in SystemVision’s class, is a bit industry dependent. For example, the value of modeling and simulation is well understood in the electronics design market, particularly for complex SoC development. It’s often called ‘virtual prototyping’ — a term originally coined and liberally used in the EDA industry. Virtual prototyping in the mixed-signal, multi-physics systems market is less popular. Such systems are often designed as independent sub-systems, then integrated on a lab testbench using hardware prototypes. When we talk to potential customers, it is precisely these types of system modeling and analysis examples they want to see before investing heavily in design tools – an investment they may not be 100% sure will pay off. Despite the many cool and detailed examples we’ve developed in the SystemVision group, customers are often more interested in what others in their industry are doing. There is comfort in knowing your company is not the first to adopt what may be a new tool or methodology. Yeah. I get that too.
So back to my dilemma: customers requesting design methodology details that I either can’t share or don’t have. Even though design methodologies can be a competitive advantage, I think there is value in companies sharing at least general details on how they use design tools. In my case, such sharing would inevitably result in “Wow! I didn’t know SystemVision could do that!” comments. I’m not advocating divulging trade secrets, but I think sharing tool use experiences and expertise could be mutually beneficial. For me, even more companies and engineers would undoubtedly benefit from using SystemVision. And existing users would find more ways to get value from their tool investement. A win-win deal.
What do you think about sharing information on design tools and techniques? Do you look to other companies for pre-adoption validation of new methodologies and tools? If so, how do you get the information you need? And if your company tends to set standards in adopting methodologies and tools, do you share your expertise with other companies? If not, do you think you should?
Like many youth since time began and there were pianos to play, my daughter takes piano lessons. In musical ways, she is much like her mom. Both play piano and sing beautifully. And like her mom, my daughter’s talent is several notches above average, at the level that leaves you wanting to hear more when each piece is over.
I recently attended a recital to listen to my daughter and her fellow students perform their latest practice numbers. As events go, these recitals are rather relaxed affairs. Audience and performers filter in and out as their personal schedules allow. Students perform in roughly beginner-to-advanced order. Musical numbers range from Twinkle Twinkle Little Star-class tunes to much more complicated pieces by the likes of Chopin and Mozart. With many years of lessons to her credit, my daughter is nearer the “more seasoned, so let’s play harder pieces” end of the skill spectrum. From beginning to end, the recital was a nice affair and a great way to spend an early fall evening. As the event drew to a close, however, we were in for an unexpected surprise.
When all students finished playing their prepared pieces, the piano teacher stood to conclude the recital and announce refreshments. Before turning us loose on the pot-luck treat table, however, she requested a few minutes more of our time to share a Chopin number she’s working on. Even though we were already 90 minutes into our evening, no one dissented. She is the teacher, after all, carefully nurturing the musical talents of our children. What followed was the true treat of the evening.
I estimate the teacher is near sixty years old, plus or minus a few years. I say this to suggest but two things: she has played the piano for a very long time, and that despite her well-earned expertise, advancing years have a way of softening even the sharpest of talents. But when she laid fingers to keyboard, she performed as every bit the expert she is. Her fingers, though bent with a bit of early stage arthritis, literally danced up-and-down the keyboard. She showed why she is the teacher, the master, in her studio. She played with so much feeling that even those (like myself) who generally avoid classical music and stare at their watches or smart phones impatiently awaiting the final note, put down their electronic distractions and listened with eyes closed, savoring every note. A real treat indeed. Such performances are rarely preserved in recording, but I’ve since realized that the piano teacher is, quite literally, preserving her skill in each of her students. While all may not reach her skill level, some no doubt will go on to play the same piece, at the same rhythm and speed, inspiring their own listeners to set aside life’s distractions and listen to the simple beauty of music well played.
The piano teacher’s performance reminded me of a recent presentation I attended from one of my colleagues, an engineer as expert in simulation and modeling as the piano teacher is in matters musical. It turns out that many companies are concerned about a sort of ‘technical brain drain’ in their staff — a particularly troubling issue for companies that develop and support big things like automobiles, airplanes, and space stations to name a few. Systems in these categories last for years, often decades, so it’s not unusual for members of original design teams to move on to other projects or companies, or perhaps even retire, leaving behind little more than printed specifications, schematics, and perhaps lab notebooks. During his presentation, my colleague proposed that modeling and simulation is a way to preserve engineering expertise for any system. Along with specifications and schematics, development teams could archive models and simulation results. Future design teams would then have the benefit of a fully functional virtual model to illustrate how a system works. If you think about it, his proposal makes perfect sense. What better way to pass along system knowledge than with a functioning system model and a complete simulation database. It’s the engineering equivalent of piano lessons.
Just as my daughter’s piano teacher passes a bit of her expertise along to each student through piano lessons, design teams can pass along their system expertise through models and simulation. Both are effective methods for knowledge transfer. Whether we have musical aptitude or not, we can all learn a little from a piano teacher’s example.
It certainly isn’t news that I think Mechatronics is a pretty cool field of study. Whether you design and build mechatronic systems for your profession or your hobby (or maybe both), you have to admit it’s a fascinating subject. As I write this, I’m waiting anxiously for FedEx (or perhaps UPS) to deliver my latest toy – a 2006 Mini Cooper S remote control (RC) car kit. I’ve owned several RC cars over the years, but never one that came in a kit that I had to assemble from a box full of parts. I’ve wanted to dive deep into remote control car technology since I drove my first RC truck several years ago, but haven’t had enough time to devote to a new interest. I probably wouldn’t be taking the time now, but on a recent whim I requested the Mini Cooper kit for my birthday. Now I have to get started, or my wife will tease (translated: nag) me about wanting a present then not using it – but there isn’t much danger of that happening. I’m already planning upgrades: motor, battery pack, tires, electronic speed control. This is going to be fun.
On a Mechatronics design related note, I recently listened-in on a web seminar given by John Vargas, one of my Mentor Graphics colleagues. John has over two decades of experience in electrical, software, and systems engineering, and he currently works as a product specialist and systems architect, helping customers understand and use our SystemVision family of tools.
John’s seminar is titled “Latest Innovations in Virtual Prototyping for Complex Motion Control Systems”, which was recorded and is available on our website. He gives a brief introduction to SystemVision and where it fits in a complex system design and verification flow, then jumps right into developing a motor control system from scratch. During the demonstration, John shows and explains the benefits of starting with a high level, generic description of a system just to get the basics running, then adding progressively more detail to fine-tune system performance. Along the way he talks about creating virtual prototypes, modeling, simulation, waveform analysis, integrating hardware and software development in a single environment, and accelerating test program development using virtual prototypes as a test development platform. Click here to get a more detailed description of John’s seminar, including a link to the recorded video. It takes just over an hour to watch the entire seminar, so maybe grab your lunch and a soda and sit back for some very interesting lunchtime entertainment. Or watch it in several smaller segments, maybe while you’re taking a break or waiting for your computer to do the number crunching on your latest design. I think you’ll find John’s seminar to be well worth your while. And stay tuned for pictures of my new Mini Cooper – I can hardly wait!
About Mike Jensen's Blog
Views, insights, and commentary on mechatronic system design and analysis.
- Engineering Muscle Memory
- EDA vs. Windows 8
- VHDL-AMS Stress Modeling – Part 3
- VHDL-AMS Stress Modeling – Part 2
- VHDL-AMS Stress Modeling – Part 1
- Practice! Practice!
- May 2013 (2)
- March 2013 (1)
- January 2013 (2)
- December 2012 (1)
- November 2012 (1)
- October 2012 (3)
- September 2012 (2)
- August 2012 (1)
- July 2012 (2)
- June 2012 (1)
- May 2012 (1)
- April 2012 (2)
- March 2012 (3)
- February 2012 (2)
- January 2012 (2)
- December 2011 (3)
- November 2011 (1)
- October 2011 (2)
- September 2011 (2)
- August 2011 (3)
- July 2011 (1)
- June 2011 (1)
- May 2011 (4)
- April 2011 (3)
- March 2011 (4)
- February 2011 (2)
- January 2011 (4)
- December 2010 (3)
- November 2010 (3)
- October 2010 (4)
- September 2010 (3)
- August 2010 (3)
- June 2010 (2)
- May 2010 (3)
- March 2010 (1)
- February 2010 (2)
- January 2010 (2)