Mike Jensen's Blog

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

31 March, 2014

The 2014 session of the Integrated Electrical Solutions Forum (IESF) for the Military & Aerospace industries is coming up fast. Join us to see how Mentor Graphics tools can help you develop safer, more reliable systems. Here are the dates and locations:

  • April 22 in Dallas, Texas
  • April 24 in Everett, Washington
  • May 1 in Long Beach, California

If you are not familiar with IESF, here is a short description from mentor.com:

“The Integrated Electrical Solutions Forum is a global conference program for electrical/electronic design engineers, managers and executives. Each IESF event focuses on EE design issues in a specific industry such as Automotive; Aerospace; Off-Highway; Military or Commercial Vehicles sectors. IESF is free to attend, and is supported by Mentor Graphics, IBM and SAE International.”

Each location includes technical sessions in the following disciplines:

  • Platform-level Systems Engineering
  • Electrical & Wire Harness Design
  • Model-based Systems Design and Analysis
  • Network Verification (DO-330/DO-178C)
  • Design Lifecycle Management
  • Integrated PCB Systems Design & Manufacturing
  • Thermal Design for Reliability

Along with the technical sessions, Richard Aboulafia, Vice President – Analysis at the Teal group, will give a keynote address titled “Back in Black: Aircraft and Defense Markets Outlook and Forecast”. Sound interesting? Click here for more details, including a look at the conference agenda and access to registration information.


25 March, 2014

Awhile back I wrote about the importance and joy of design practice. In that post I suggested that everytime we design something, we are practicing and improving our design skills. And while we do learn from our successful designs, we no doubt learn more from the failures that sometimes litter the path to a project success. If you have done any design practice at all, you have no doubt had a design failure or two. I wonder sometimes why we say doctors are “practicing medicine” and lawyers are “practicing law”, but engineers are just “engineering”. Seems engineers should have the luxury of “practice” one in awhile too. But I digress…

I recently attended a presentation by Dirk Kramers. If competitive sailing is not your passion, particularly on The America’s Cup scale, Dirk may not be a household name in your home. But he has the distinction of being the chief designer for the boat that won the 2013 Amercia’s Cup race. He spent nearly an hour sharing the story of his team’s preparations leading up to the victory. While the race ended with the United States team defending their trophy, the run up to the race is a cautionary tale of boat design specifically, and engineering design in general.

It is easy to watch the America’s Cup race and be amazed at how competing boats maneuver on the water. Even if water craft do not interest you, you have to be impressed at how well the boats and their crews perform on the water. Twin-hull craft are particularly fun to watch since a good stiff wind, coupled with an aggressive angle of attack into it, often lifts one of the hulls out of the water and turns a sedate twin-hull cruise into a slalom thrill ride. In recent years, teams competing in the America’s Cup have universally adopted twin-hull designs. Why? One word: speed. A twin-hull craft is generally faster than a mono-hull design of similar size.

So Dirk’s team started with a twin-hull design and decided to innovate by combining two additional sailing technologies: a fixed sailing wing and hydrofoils. The fixed wing wraps around the mast and makes the boat more maneuverable. Once at speed, the hydrofoils lift the boat hulls until the craft is essentially riding on stilts above the water. So what do you get when you add a wing and hydrofoils to an already fast twin-hull boat? Yep. More speed. But it turns out there is an engineering design price to pay for this boost in performance: instability. Add a fixed wing and hydrofoils to a twin-hull boat and you make it harder to control. While Dirk and his design team knew and anticipated this, they soon discovered the price demanded when the design and performance envelope gets pushed too far into uncharted waters, to use a maritime metaphor.

Dirk and his team set out to create a competition crushing nautical speedster. Members on his team were experts in their individual areas, no doubt some of the best in their fields. Given this pool of talent, was there risk in their approach? Yes, but they felt the risk manageable. The team did their due diligence in design, including running simulations, before building a boat to test. And the first seven testing days went well, but on the eighth day disaster struck. As the test day wound down, the crew lost control of the craft which toppled and started sinking. The fixed wing was destroyed and the rest of the boat badly damaged. Pushing the design and performance envelope crumpled carbon fiber, endangered crew lives, and nearly scuttled the team’s chance to compete in the race, let alone win.

Obviously Dirk and his team recovered and rallied to get back in the running, eventually besting Team New Zealand with a score of 9 to 8. But what design lesson can we learn from Dirk’s story? The answer is obvious: risk is an inherent part of engineering, particularly when dealing with unproven technologies, or combining proven technologies in unproven ways. And real danger often follows. Are these reasons enough to stop taking design risks? Of course not. Innovation in almost any design field requires risk, often by challenging old or traditional ways of doing things. Design risk drives innovation, and innovation often wins races, whether in sports or business. A key design objective, then, is to mitigate risk while still advancing technology – a perfect role for modeling and simulation. Design teams in many industries make their mistakes in simulation long before committing resources to prototype testing. And while failures still happen, the risk is better quantified.

, , ,

17 March, 2014

Most of the customers I work with design small systems, or smaller pieces of larger systems. Occasionally I get to see an end product: a car, an airplane, a mockup of the International Space Station to name a few. Most of these systems are built or assembled in one location, then put to work in another. In other words, the systems most of my customers work with are portable in a very general sense.

On the other end of the scale – what I call Big Engineering – are systems whose pieces may be designed and manufactured at multiple locations, but when the parent system is built, it lives and works in a fixed location throughout its serviceable life. Think large industrial sites. My sister is an engineer at just such a place – a coal fired power plant.

Power plants are some of the biggest industrial sites on our planet. Get beyond a handful of kilowatts and the space requirements are almost mind-boggling. Generating electricity, no matter the method or amount, requires a physical footprint proportional to the number of watts generated.

My sister works at the Intermountain Power Plant, which sits on roughly 4600 acres of high desert acreage in Central Utah. It runs two turbine-driven 950 megawatt generators. The footprint of the turbine + generator room is roughly the square footage of a medium-sized shopping mall. Everything else at the site is dedicated to either making or keeping the turbines and generators running and generating electricity. The plant is one of the biggest of its type in the nation.

My sister recently took me on a tour of her plant, which I thought would keep us busy for maybe an hour. But six very interesting hours later we turned in our hard hats and safety goggles, and headed home. During the tour, we drove and walked to areas not on any normal plant tour. She explained in interesting detail every phase of the generation process, from when the coal is dumped onsite from train or truck, to when the remains of spent coal are transported by conveyor belt to a remote corner of the site. While I am not fluent in power-plant speak, it was fun to talk engineer-to-engineer about electricity, our common technical language. There are definitely worthwhile perks when your sister is a lead engineer at a power plant.

Coal-fired power plants are simple in principle: coal makes fire, fire boils water to make steam, steam is collected under pressure and channeled to the generation room where it turns the turbine that turns the generator to create 3-phase electricity. The electricity is then routed to a big transformer (my sister’s baby) where it is stepped-up to a mind bogglingly large number of kilovolts before being converted to DC and shipped to Southern California. Yep. Utah residents very rarely benefit from any electricity generated at the plant. It all goes to help power California communities. As is often the case, however, what is simple in principle often gets pretty complicated when you peek under the hood. You might think a system that burns coal to boil water to make steam to spin a turbine to turn a generator is simple. Nope. Within the power plant are essentially three separate, complex systems: fire, steam, electricity.

The fire system tracks fuel from when it arrives on site to when waste from burnt coal is sent out to the ash bed. Coal is pulverized to dust, then mixed with air to create a highly combustible fuel that fires in what is essentially a big boiler. Once the fuel is spent, the remains are filtered through a multi-step process to mitigate air pollution. Some of the ash gets recycled at a local cement plant; the rest is piled on spare acreage.

The steam system is the middle process, converting heat from the coal to pressurized steam. Lots and lots of water is moved around the plant by motor-driven pumps of all sizes. It is a great example of a pretty efficient thermodynamic system at work. Water is transformed from liquid to gas then back to liquid again. And sometimes ice enters the process if temperatures dip far enough below freezing.

All of this leads up to the electrical system. Pressurized steam drives the turbines which spin the generators to create 3-phase electricity. All of that juice is routed to a big transformer and sent to a second facility not far away to get converted to DC for the trip to the West Coast. The combined turbine + generator units are massive (note the picture), as are the transformers. Despite their size, however, there is barely a vibration in the generation room. A good thing, too, since even a small vibration could lead to some pretty serious damage.


One recurring thought I had during my tour was “How did someone figure thus out?” The short answer, of course, is “engineering”. But that may be too simple an answer. The real answer is “iterative engineering” which is how some of the most elegant system solutions are found. And while some of my tour questions appeared complicated, many of the solutions were elegantly simple. Even though a process seems complex, it is often built on a series of very simple steps or sub-processes.

I have often wondered whether power plant design could benefit from simulation-based, multi-physics modeling and analysis. After seeing a power plant in action, I believe the answer is yes, without a doubt. It is hard to appreciate what goes in to making the lights turn on in your house until you see all of the power plant pieces working together. But it is a well-balanced, finely-tuned, closely-monitored process that can easily go haywire if, as my sister said, just one screw is out of place.

Engineering at any level is interesting. From millions of transistors crowded inside an integrated circuit, to the turbine and generator deck of a coal-fired power plant, amazing things happen. The cool thing about Big Engineering is it is easier to see the system parts and pieces working together. Not so easy to look inside of an integrated circuit, let alone to figure out even the basics of what it does (unless, of course, you either designed the chip or have a datasheet). But how industrial-sized systems work is easier to decipher, with the added advantage of being able to reach out and touch the toys.

, , , ,

21 January, 2014

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

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

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

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

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

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

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

, , , ,

16 December, 2013

SystemVision 5.10.2 is finished and available for immediate download from Mentor Graphics’ SupportNet website. What will you find in this new release? Here are some of the new/updated features and capabilities:

  • Asymmetric parameter tolerances
  • Custom, user defined statistical distributions
  • Global Parameter support for Monte Carlo analysis details
  • Worst Case and Extreme Value analysis support for asymmetric parameter tolerances when using SPICE-based Uniform and Normal built-in distributions
  • Shared Library Manager for creating, editing, and managing user-defined model libraries
  • Menu option for switch between SystemVision and Corporate central libraries
  • Automatic symbol editing for new generic box symbols
  • Use reference designators to map schematic symbols to simulation models
  • User-defined parameters for schematic-based models
  • Define design parameters with a schematic scope
  • Save a simulation end-point file to continue the analysis in a different SystemVision session

 All-in-all, the SystemVision Engineering team addressed 90+ enhancements and improvements since the 5.10.1 release in mid-summer. Want more information about SystemVision 5.10.2? Would you like to see a demonstration of any of the new features or capabilities? Post a comment to this blog entry, or contact your local Mentor Graphics representative, to ask questions or arrange a discussion.

, ,

10 December, 2013

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

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

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

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

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

, , , , , ,

16 October, 2013

It happens every year in the fall: my birthday rolls around and I turn another year older. For good or bad, I am well into the time of my life where I have fewer years ahead of me than I do behind. I am not trying to be morose, just stating a fact. The numbers do not lie. And I suppose I am not unusual in occasionally looking back on my life wondering what my legacy will be. What will I be remembered for, at least among the folks who know me, when I am pushing up daisies?

I recently attended a retirement party for my father-in-law. His third such party in the years I have been blessed to be part of his and my mother-in-law’s family. The man for some reason just cannot stay retired, though I think this one might stick. It is time for a well-deserved rest, and for him to spend more time with his sweetheart at their lakeside cabin. My wife and I arrived at the party just as the retirement speeches started. My father-in-law worked in the legal profession all of his career and is well respected in the legal community of my city and state. Having said this, however, I have really never seen him in a professional setting – except, of course, at retirement parties. If you listen to the speeches at such parties, you can learn a lot about a person and how he or she is regarded amongst peers. My father-in-law was and is well-regarded not only for his legal expertise, but also for the type of man he is. While I knew he was respected professionally, I am much more familiar with his personal life: family man (husband, father, grandfather), gardener, fisherman, a bit of a technophobe. He is also a man of unparalleled wisdom – his most sage and repeated advice to me for maintaining harmony at home being “life goes a lot better when you do what you are told”. This advice has served me well during the 27+ years I have been married to one of his daughters.

What struck me most about the retirement speeches, however, was the professional legacy he is leaving behind. His skill and expertise have touched many lives. He has been a leader to some, a mentor to many, and a colleague and friend to still many more. So this got me to thinking about my own professional legacy. I still have several years before I plan to logout, turn my monitor off, and stow my keyboard for the last time. But during my father-in-law’s retirement party I wondered how I will be remembered. Will I be remembered for contributions to my profession, or for helping those coming behind me, or just for being competent at what I do? I am not sure I as yet know the answer, but any of these would be a respectable legacy. Perhaps the more important point, however, is that we really do not know how, or even if, people will remember us when we retire, so the best approach is to just do the best job we can, the job we are paid to do, and let our legacy take care of itself. Having said this, for the most part we all hope our professional contributions are remembered in a positive light, so it makes sense to pay attention to how we treat our profession and the people we meet along the way.

So what will your professional legacy be? Has yours been largely written through many years of work? Or are you just getting started in your career and so your legacy has yet to be written?  I expect most of you are like me – somewhere in between. For whatever you might be remembered, will your contributions be considered a net-positive by those who know you? No matter where you are on your career path, it is worth thinking about.

30 September, 2013

Another IESF is in the Mentor Graphics history books. Record crowds gathered at the Ford Convention & Event Center in Dearborn, Michigan to learn about automotive system design using the latest Mentor Graphics tools.

Along with hearing from keynote and industry speakers representing a broad spectrum of experience in automotive development, attendees chose from a long and varied list of technical sessions on topics ranging from wire harness design to mechatronic system simulation to infotainment design to design data management. Many of the presentations in these sessions were recorded and will soon be posted on mentor.com.

For my part I presented in two technical sessions. In the first session I talked about the challenges of mechatronic system design, including how SystemVision and SystemVision conneXion can help integrate different, and often disparate, system elements (think analog and digital electronics, sensors, actuators, a mechanical plant of some sort, and software) into a single design and analysis environment. To illustrate SystemVision’s capabilities, I used our Electronic Throttle Controller example, which shows SystemVision working in its sweet spot of mechatronic system design. And while the entire system can be thoroughly analyzed using just SystemVision, the analysis gets even more interesting and powerful when SystemVision is linked with other tools and processes, such as Simulink from The Mathworks, LabVIEW from National Instruments, or C++ code, using SystemVision conneXion.

In my second presentation I used our Automotive Electrical System example to illustrate why simulation is an important and effective tool for analyzing a vehicle electrical distribution system. For this session I showed how SystemVision can be used to detect hidden system faults, and therefore help design teams understand how a realistic sequence of events can easily cause system problems. In this case, a week connector caused an electrical system failure. The solution? Simply raise the connector’s voltage rating. An easy fix, but a problem not easily detected without simulation. The point of my presentation was showing how simulation is an effective tool for determining wire component sizing specifically, and deriving electrical system design rules in general.

In addition to the technical sessions, an Aston Martin graced the conference center lobby floor, and Oliver Kuttner, Founder and CEO of Edison2, brought his X-Prize winning car to show and tell. The contrast between the two cars was of course striking: the Aston Martin on one end of the scale representing some of the best high-end sports car engineering in the world, and Oliver’s car on the other end of the scale looking a little quirky, but sporting some of the best fuel economy numbers in the industry. Oliver’s X-Prize winning car has inspired the development of Edison2′s Very Light Car concept vehicle, which Oliver claims gets 115 miles per gallon on the highway with no electrical assist. Pretty impressive. And he has some interesting ideas about the future of the automobile. I will let you know if we get to post the video of his presentation. In the meantime, visit his website at www.edison2.com for a quick overview of his ideas and the engineering behind the Very Light Car.

So what really is the automobile’s future? Will it trend towards the Aston Martins, or the Very Light Cars? Since not everyone can afford the Aston, logic dictates the trend will be toward Very Light Cars – improved fuel efficiency for internal combustion drives, longer range for electric drives, all the while being safer to drive and more connected. I for one am looking forward to what will certainly be very interesting industry developments.

Of course, advances in automotive technology require advances in design methodologies. And better methodologies depend on capable design tools, which is where IESF comes in. It is a perfect forum for learning about Mentor Graphics tools for meeting the technology demands of more advanced automobiles. IESF was, as always, an interesting, fun, and informative event. Attendees learned about Mentor Graphics tools, and Mentor Graphics folks learned how design teams user our tools, or where they could use our tools, to improve design processes. As always, my conversations with attendees uncovered more application possibilities for SystemVision. If you are new to mechatronic system analysis using simulation, visit the SystemVision and SystemVision conneXion websites to learn how the SystemVision tool family can help you design better performing systems, automotive or otherwise, in less time, and at lower cost.

, , , , , ,

3 July, 2013

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

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

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

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

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

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

, , , , , ,

5 June, 2013

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

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

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

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

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

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

, , , , ,