Thursday, July 28, 2011

Update 10 for Altium Designer 10 available

The Altium Development team are pleased to announce a new update for Altium Designer.

This update focuses on addressing further issues that have been raised in BugCrunch, including:

  1. Feature request to reset component designators when copying and pasting in schematic
  2. Angular dimensions will now be correctly saved, no matter how the inside/outside reference points are selected
  3. Implemented “Select touching area” and “Select touching line” for object selection in schematic sheets, libraries and OpenBus documents.

Along with these issues, there are also a few issues fixed for CAMtastic. For detailed information on what is delivered with this update, read the release notes.

The delivery of this update affects the following 3 modules in the System Components category:

  1. PCB System
  2. PCB Support
  3. Schematic System

Installation of these updated modules will bring their revision up to 10.600.22648. The Platform Build number will remain at 10.589.22577 as the Altium Designer Base module is not updated.

To update your Altium Designer 10 installation, go to the Plug-in page (DXP >> Plug-ins and Updates) and select “Update All”. If you don’t see the update, use the “Refresh” link in top right hand corner of the Plugins page.

For those who installed directly from DVD, you can access the updates by changing a setting in preferences: System >> Installation Manager, change the Remote Repository Location to


Tuesday, July 26, 2011

Shanghai Vault Update - VITA CMC Mating Connectors

The Shanghai Content Center is very pleased to announce an update to the previous VITA family release. This week, more mating connectors for the existing VITA Mezzanine standard modules have been added.

These follow the same style as previous mating connector projects, that is complete with signal assignments, connector 3D models and example layouts. These design templates can be used in conjunction with our existing VITA module templates to build up carrier modules.

This release includes mating connectors for FMC, PMC and XMC, and can be found in the VITA - CMC folder of the Shanghai Vault.

FMC and XMC are both provided in single and double variants.

Those on the AltiumLive Subscriber Plan can use these templates by connecting to the Shanghai Vault directly from Altium Designer 10 using their AltiumLive credentials, or by browsing to the AltiumLive Design Content area and selecting the Altium Shanghai Vault


Monday, July 25, 2011

How to import Eagle files into Altium Designer?

There has been some discussion around importing files from Eagle and we have
collected some information which I felt was worth sharing with you. As you are
aware Altium Designer does not currently offer an Eagle importer however there
is a way to import your Eagle Schematic and PCB's into AD. CadSoft, Eagle offers ULP
script's (User Language Program) that will export to an earlier Protel format
which can then be opened in Altium Designer. These scripts use the file
extension [*.ulp].

Using the Eagle export script Tool, it is possible to export Protel ASCII data
from Eagle Schematics and/or PCBs. The resulting ASCII data can be opened with Altium Designer.  Important
this export tool is not an Altium product, and is not supported by Altium. These below scripts are popular but
there are others floating around as well.

Convert Eagle Schematics to Altium

Convert Eagle PCB's to Altium

The information below is mostly for things to be cautious of after a PCB is
converted, others may have more insight as to what to look for after converting
a schematic using the mentioned ulp. The original
scripts can be found at (, Or (

Note: The script can fail if there is a % character (see issue 8).

These ULP's can be helpful however some clean up should be expected. To date
the following issues have become known regarding the PCB export ULP.

1. There is no Board Header Record
2. The Layer designators in the inner layers are not correctly shown. It is possible to search for these incorrectly shown Layer designators with a text editor (e.g., Notepad) and to replace/rename these discrepancies. (e.g.
Routex –> Midx) Midx is the designator recognized by Altium Designer
3. After the PCB Import, design rules must be made and checked.
4. Plane layers may be omitted. These are however easy to create in Altium Designer as long as there no Split Planes were present.
5. There are cases where Overlay-Objects from components end up on the wrong layers. You can unlock and select the component
primitives, and then change layers for any discrepancies.
6. All pads come in a Pad Designator 1. This will have to be corrected if this is ever to map to schematic symbols. However, all primitives for a
component are at least grouped into a component.
7. All the tracks came in but were not assigned to any nets. They were all No Net.
8. The script chokes if a percent sign (%) is included in any text (such as a Comment with "1000uF 5%"). This is because the
script sends this to Printf() as a format string, which interprets it as the
start of a new field for which there is no corresponding parameter passed.

Steps in Eagle
1. Open Eagle
2. Go to File / Open / "Browse to Eagle PCB" or Eagle "Schematic"
3. Go to File / Run / "Browse to the ULP you want to run. (ie: schematic or pcb export ulp

Hope this information is helpful...

Power nets management - take 2

My recent blog post about Power nets management attracted a large number of very interesting and very informative comments. It has been heart warming, for me, to see so many people getting involved in the discussion. All these contributions have helped me appreciate how vast and intricate the domain of power management can be. It is also obviously an area of great importance to all of you, regardless of the types of design you do.

Many of these comments offer great suggestions and ideas. I would like to try and pull all this together in a coherent and organized way, that will hopefully indicate a visible and useful way forward.

I’d like to approach this by first better defining, and classifying the problems that have to be addressed in order to make power management less ‘energy consuming’ (pardon the pun) for you. Then for each problem, or class of problems, I will try to propose some possible approaches for solutions, while trying to estimate the development effort involved to implement these.

The first types of problems are elementary.

Each power network (the set of nets involved in providing power to components) should ultimately be connected to some external source of power.  Any external source of power should also deliver power somewhere. On a given power network, basic budgetary constraints should be respected (the power produced should be greater than or equal to the power consumed, the operating voltage ranges of devices connecting to a common net should match). Also, where power networks interact with signals (I refer to pull-ups and pull-downs), no spurious errors should be generated, obscuring the real errors.

Then come problems of a more complex nature.

Each power network budget should be precisely managed so as to ensure that what is supplied gets appropriately distributed (for the various parts to function properly) and ultimately collected, under all possible operating circumstances. Of concern is the amount of current provided under which voltage (for the supply side), and how it is collected and returned.

Finally, there are the more advanced issues.

Ultimately the PCB needs to be designed in a way that physically satisfies the power requirements of the parts used. To avoid repetitive work and errors, these design constraints should be automatically calculated from the schematic information. Then to verify that the result is adequate, the final PCB design should be simulated. These concern areas like power and split plane design, route management, heat management, part stress, and so on.

Simple power connection checking

For the first group of elementary problems, I think that given the means of defining a power network, its nodes and their basic characteristics, it should be relatively easy to perform elementary checks and focus the designer’s attention on potential issues.

The elementary checks that I am thinking about are:

  1. There is at least one producer of power on the network.
  2. The power produced on the network is greater or equal to the power consumed.
  3. The voltage ranges of devices connected to the network should at least intersect.

The important question is: what would be a practical way of implementing this?

First, lets consider the way to ‘build’ a power network. A power network is merely a set of nets involved in providing power to the parts that need it.

I find part see-throughs to be a good mechanism to achieve the purpose of defining this.

I understand that the graphical representation proposed in the previous post is not adequate, and I totally see the points made - as previously depicted, they can be confusing, misleading and clutter the design space unnecessarily.

Their key purpose is to communicate that for a certain intent (here, power network definition) two nets should be considered joined. In the case of power management, they act merely as wires, and therefore should be placed on parts that do not affect the voltage in a big way.

This should be reflected by their behaviour and their graphical representation. On screen, they should be visible only in an explicit way - when the mouse hovers over an involved pin for instance, and/or according to some preference or setting. Exactly how they would look though (when and if visible at all), I have not yet determined. It certainly should be possible to exclude them from printouts and outputs. Also they will allow one-to-many relationships. It will be possible to place them either in a library or in a design context.

Then lets look at what would be required to define basic electrical characteristics on a power network. I understand that replacing the ‘Power’ pin type with two ‘Power Supply’ and ‘Power Sink’ types, while embedding electrical characteristics in pin parameters is a popular idea. However, it makes me feel uncomfortable for a number of reasons.

Firstly, it raises the issue of data updating, both in a library and design context. Given an ‘old’ Power pin, a judicious choice would have to be made when coming in the new software (was it meant to be a supply or a sink?). Given today’s real situation, it sounds like there are no easy answer. The same problem exists for backward compatibility, and data that goes back and forth between various versions of the software.

Secondly, opinions seem to diverge regarding the naming and the concepts underlying these types (Power supply/sink, Current supply/sink, Positive / Negative reference...). Some confusion might also be introduced in regards to negative power supplies.

There is also the issue of parts characteristics that vary depending on the way they are used in various designs. This goes from adjustable regulators to power delivered by generic connectors. Modifying the part pins themselves in the design is always a possibility, but this is an approach fraught with danger when it comes to rigorous data management (for instance while using Update from Libraries, or the Design Item Manager).

I think that what is required here to move forward is a more flexible system which allows the connecting pins characteristics to be declared in a simple way.

In this perspective I like the idea of ‘Tagging’ put forward by Ian. A ‘Power Tag’ is simply a connection description. It is defined by a type (Producer or Consumer), a power rating, a voltage range and a free text description. When it is placed on a pin it declares the pin electrical characteristics. It can be placed either in a library context, or in a design context.

Then, given a power network, the basic checks can easily be performed:

  1. The connection types allow to check for the absence of producer or consumer.
  2. All producers power [produced] can be added, and all consumer power [consumed] can be added. These two values can then be compared to check for imbalance of the power network.
  3. Finally the voltage ranges of each connected pin power tag can be compared to check for a valid match.

The following images illustrate the overall approach described above. In this example, two power networks are defined: 5V0 and 3V3.

A power jack delivers 5V0 to the whole network. Directly in the schematic (since this situation is design specific)  a Power Tag describes the power characteristics of the power jack pin that is connected to the 5V0 rail.

A switch allows to turn power on an off. Since the nets +B and 5V0 are part of the same power network, and in effect at the same voltage, two see-throughs are added to link pins 1 and 3, and pins 3 and 2. A switch is always ‘transparent’, so these see-thoughs could have been added to the sch symbol itself, in a schematic library.

Then a regulator brings down the 5V0 rail to 3V3.

5V0 is delivered to an audio power amplifier. Power Tags placed on pins describe their characteristics. The power consumed value describes the worst case scenario. This can either be done in a schematic library environment, or in the schematic itself.

3V3 is delivered to a touch screen controller, which pins characteristics are described by appropriate Power Tags.

Then simple power checks can be performed on 5V0:

Producers on 5V0


Power produced (W)





Consumers on 5V0


Power Consumed (W)











Also on this network, all voltage ranges match (J19-1 provides 5V0, while U1-1 needs 2V7~6V0, and U26-2, 10 and 15 need 4V5~5V0).

On 3V3, the same verifications can be performed:

Producers on 3V3


Power produced (W)


480 x 10-3


480 x 10-3

Consumers on 3V3


Power consumed (W)


80 x 10-6


750 x 10-6


10 x 10-9


830.01 x 10-6

Also on the 3V3 net, operating voltages ranges match (3.2V~3.4V, 1.2V~ 3.4V, 2.7V~3.6V, 2.7V~3.6V)

Based on this revised approach I start seeing a clear path forward to the implementation of an effective solution that addresses these elementary issues, within a few months.

It should also be possible to highlight entire power nets on demand, with some indication of their correctness.

Equally, a simple mechanism of grouping producers together, using a group index in the Power Tag, will allow us to indicate which producers will be active at the same time (and so should be summed), for redundant power systems for example. The system can take this into consideration while running the checks.

Advanced power management and analysis

I also would like to address the more complex problem of assisted power budget management.

I understand that a very useful tool would be one that, given the full electrical characteristics of involved components and the way they are connected together, could do all the maths and report whether all declared constraints are satisfied, at all time. I agree with this view.

In order to implement that in any satisfying way, the Spice simulation engine would have to be brought in, which is obviously possible.


In addition to the weight of adding the adequate simulation models to libraries and designs, I am not yet sure whether all possible cases can be reliably covered. Many devices’ power consumption depend on the way they actually operate in the field. To accommodate that, the Spice simulation engine would have to be equipped with means to take into account the way devices are programmed, and the way these programmed devices interact with their environment.

This sounds like a very exciting project, but one that fits in a longer term perspective. It feels to me like something worth further pondering, investigating and talking about - possibly in a future blog post!

Finally, the advanced topics of automatic rules generation and final design simulation appear equally useful if they could be effectively addressed. However, the road to their final implementation seems even more unclear.

In terms of automatic rule generation, a number of architectural problems would have to be solved in the software, like the ability to define binary rule at the schematic level for instance. Then the guidelines for the automatic rules generation would have to be clearly investigated and defined, with possibly, new rules introduced at the PCB level.


Also, in the world of simulation of the final result, some brand new technology would have to be either developed or acquired. A number of strategic steps would have to be taken first in order to address these aspects effectively.

This has been a rather long post, but I think the interest expressed in this subject demanded a careful analysis, and an equally detailed and honest answer. My aim to is to clearly outline a path to a useful solution that can be effectively deployed in a matter of a couple of months.


Thursday, July 21, 2011

Hobart Content Update - Würth Elektronik’s SMD High Current Chokes and THT Power Chokes

The Hobart Content Team is very pleased to announce the release of Würth Elektronik's SMD High Current Chokes and THT Power Chokes.  This now brings the Würth collection to some 700 components across 6 families and includes some highly detailed 3D models.

SMD High Current Choke

This group provides a range of SMD High Current Chokes across four series, WE-HCI, WE-HCC, WE-HCF and WE-HCM.

The WE-HCx series offers robust, smoothing chokes with a high modulation range - especially suited to use in high current regulators and multi-phase (or poly-phase) converters. Also used in applications for high current radio-interference suppression chokes.

These high current chokes also have low losses in the core and very high saturation currents. The flat wire coils used in the HCI, HCF and HCM series also reduce the skin effect and copper losses.

THT Power Choke

The THT Power Chokes are separated in magnetically shielded and unshielded inductors. The barrel inductor WE-TI is available in both variations and is available with shrink tubes as well. This serves as a winding protection against external mechanical influences.

These inductors, and their core and coil parameters, are optimized for use in switching regulators and DC-DC converters. The WE-TI components deliver stable inductance values over a large bandwidth and are particularly suitable for use in switching regulator applications up to 10 MHz as they offer a high current capacity and low DC resistance in a very small package.

All components are available from Würth Elektronik ex stock. Samples are available free of charge. More info at

AltiumLive Subscribers can use these components by connecting to the Hobart Vault directly from Altium Designer 10 using their AltiumLive credentials, or by browsing to the AltiumLive Design Content area and selecting the Altium Hobart Vault.


Tuesday, July 12, 2011

Update 9 for Altium Designer 10


Update 9 for Altium Designer 10


Altium Designer, AltiumLive, BugCrunch, updates, loop removal, polygon pour

I am pleased to announce a new update for Altium Designer.

This update focuses on addressing issues that have been raised in BugCrunch and includes:

  1. Polygon pour improvements, including the issue when joining copper pour to the thermal reliefs.
  2. Improvements to the interactive router loop removal tool
  3. Resolved the issue where the conflict resolution mode was not remembered after subsequent drag operations
  4. "Restore (n) Shelved Polygons" command now asks the user if the un-shelved polygons need to be re-poured straight away or not
  5. The files now open within the library project for SVNDblib.

Thank you to those who logged these issues in BugCrunch, nominated them, and voted for them!

Along with these issues, there are a variety of other issues that we have included in this release. For detailed information on what is delivered with this update, read the release notes.

The delivery of this update affects the following 7 modules:

  1. System Components category:
    Altium Designer Base, PCB System, PCB Support, Schematic System, Soft Design Support
  2. FPGA Components category:
    FPGA Configurable - Wishbone Memory Controller
  3. Output Generators:
    Printer - PCB

Installation of these updated modules will bring their revision up to 10.589.22577. The Platform Build number will also update to 10.589.22577 as the Altium Designer Base module is updated.

To update your Altium Designer 10 installation, go to the Plug-in page (DXP >> Plug-ins and Updates) and select “Update All”.  

(If you don’t see the update, use the “Refresh” link in top right hand corner of the Plugins page.)

For those who installed directly from DVD, you can access the updates by changing a setting in preferences: System >> Installation Manager, change the Remote Repository Location to

If you are wanting to install a new build containing this update, please download the latest Installer/Uninstaller to support this build


Tuesday, July 5, 2011

Power nets management

A recent BugCrunch item (Power input vs output) raised the long standing issue of power management in Altium Designer. To ensure we are all on the same page, I have some opinions I think are worth sharing before work gets started. As always, I will be very interested in your thoughts and comments. My aim is to make sure that what we do with regards to this is ultimately useful in real life.

First, let me describe the problem as I see it and how I think it should be addressed.

In Altium Designer today, power pins are generally used to indicate a user of power. Power pins can be treated differently from other pins at ERC time.

However, it is not possible to easily identify and manage complete power distribution systems.

Consequently, a greater level of care is required to avoid fatal errors like power starved components or shorts (which I am sure keep many up at night).

At the board design level, the set of nets that distribute power constitutes a ‘power network’. Similarly, the set of nets that collect current to ground constitutes another ‘power network’.

Within each of these power networks, a unique point connects to external power resources (either a power source that provides power, or a connection to ground). The net that is connected to this point is truly a power net.

Also within each of these power networks, a number of parts (current limiting resistors, net-ties, fuses, etc.) are ‘see-through’ components that, from the point of view of the whole network, are only a connection (though a connection that bears certain required characteristics) joining one net to another .

The following is an abstract representation of such power-network at the board level.

In the drawing above, the nets drawn in red, and the nets within the red box constitute a whole power network. Within this network, a power net directive identifies the net ‘Main PWR’ as the unique net through which power is actually delivered.

The nets drawn in blue, and the nets  within the blue box would constitute another whole power network. Within this network, a power net directive identifies the net ‘Main GND’ as the unique net that is actually connected to the ground.

In each power network, only one net can be identified as a power net. Also, each net containing power related objects should be part of a power network.

In the schematics of PCB projects, a new directive will be available, called ‘Power net directive’. When placed on a given net, it will identify it as the unique net (within a power network) that connects to external power resources.

This new directive can look like this to be easily identified.

Also, a new schematic object will be introduced, called “Part See-Through”.

It will be placed by choosing two pins (from the same part) hotspots, and it will link them.

Its graphical representation will be something similar to this (this was drawn using the line and elliptical arc objects)

Part see-through’s color, thickness, line style (full or dotted line) and style (arc or line) will be controllable and determine their graphical aspect. Upon placement, part see-thoughs will be automatically ‘unionized’ with the part they target, so they can be easily moved together.

In effect, the role of a part see-through is to join two nets in a ‘group of two nets’. Consequently, a group of part see-throughs, used in combination with a power net directive will  define a whole power network.

Note that net ties components will be entirely see through by default

All standard editing and management system ( Dialog, Inspector, List, Queries, parametrization for scripts) should support these new objects and fields.

Based on these elements, some intelligence about a design power network can be gathered by the system, and reported in a useful way.

New compilation errors can indicate incoherent situations which could lead to errors in the manufactured board

  1. Missing power net directive on power network.
  2. Power net directive conflict on power network.
  3. Missing power pin on power net.
  4. Starved local power net.

Also, power to input pin errors and input pins without a driver errors can be more intelligently handled in the case of pull-ups or pull-downs: if the nets involved are part of a properly declared power network, these errors can be suppressed.

Also net classes can be generated based on declared power networks.

Finally power networks can be precisely described in reports formatted for this purpose.

A power networks report will contain information about:

  1. The list of nets involved in a given power network
  2. The list of components and their see-through pin pairs involved in the power network
  3. The details of the power net of a given power network.
  4. The list of the whole network ‘boundary pins’.

In the future, this intelligence can also be put to good use first to improve the schematic representation (through automatic wire coloring based on power networks), but also most importantly at the PCB level, to easily identify and manage power networks. Part see-throughs could also be used for other purposes, like managing the length of signal nets that contain dampening resistors