Mike Jensen's Blog

EDA vs. Windows 8

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?

VHDL-AMS Stress Modeling – Part 1

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;

   12: begin

   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.