Defining High Speed Signal Paths with xSignals in Altium NEXUS

The Challenge

With ever-increasing device switching speeds comes the challenge of maintaining the integrity of the signal, and meeting the signal's timing requirements. The signal integrity can be managed through controlled impedance routing, which is achieved through the careful design of both the PCB stackup and the routing widths to be used on each layer.

The timing requirements are met by matching the routed lengths of the signal paths. For a set of 2-pin signal paths, each running from an output pin to a single input pin, calculating and comparing the lengths is a straightforward process. This is not the case for many typical design solutions though where there may be a series termination component in the signal path, or there are more than two pins in the signal, which could then be routed using a Balanced T or a Fly-By routing topology, as shown in the image below.

Four DDR2 RAM chips routed using a Balanced T topology. ##

The Solution

The designer's job is to translate their design requirements, such as the maximum route length allowed to meet the timing budget, into a set of design rules, such as a Length rule to ensure that the timing is met, and a Matched Length rule to detect potential timing mismatches.

Now the designer sees the signals in terms of their function (eg, 'This address signal must be routed from this connector to each memory device. To achieve that I'll route using a fly-by topology with a termination resistor at the end. I might also require a series terminator at the source'). Even though address A0 passes through a termination resistor, to the designer, that signal is still A0 on the other side of that resistor.

But the PCB editor sees each signal simply as a set of connected pins (commonly referred to as a net) — Net A0 goes from this connector pin to this memory component pin, then to this memory component pin, and so on. As soon as a series termination resistor is added, that address line becomes two discrete nets. This makes it difficult for the designer to specify key design requirements, such as Length and Matched Length design rules.

This can be managed by a feature called xSignals. This feature enables the correct treatment of a high-speed signal path as just that - a path for a signal to travel between a source and destination, through termination components as well as branches.

Creating a New xSignal

An xSignal is a designer-defined signal path between two nodes; they can be two nodes within the same net or they can be two nodes in different nets.

xSignals are defined using the following methods:

1. Use the xSignals Multi-Chip Wizard. This will be the most common approach to creating xSignals and is covered in detail on the xSignals Multi-Chip Wizard page.

Alternatively, the following methods are used by selecting objects of interest first, then choosing the appropriate command:

2. Create a single xSignal based on selected pads. Select the required start pad and end pad (these pads can be in different nets if there is a series termination component). Pads can be directly selected in the design space, or the PCB panel can be used in Nets mode to locate and select the pads (as shown in the image below). Once the pads are selected, either right-click on a selected pad in the design space then run the xSignals » Create xSignal from Selected Pins command, or right-click on one of the selected pads in the PCB panel and run the Create xSignal command. The new xSignal will be listed in the xSignals mode of the PCB panel.

   When you are defining an xSignal based on selected pins (footprint pads), select only the start pad and the end pad before running the Create command.

   The name of the new xSignal will be a combination of the two net names, separated by a hyphen. The xSignal name can be edited in the xSignals mode of the PCB panel.

   The new xSignal can be added to an xSignal class, right-click in the xSignal Classes region of the panel to create a new class and add members to it.

3. Select the source component, then right-click on the selected component and choose the xSignal » Create xSignals between Components command from the context menu. The Create xSignals Between Components dialog will open, with the chosen source component selected. The dialog is described below.
4. Select one or more series components in the design space then right-click on one of the selected components and choose the xSignal » Create xSignals from Connected Nets command from the context menu. The Create xSignals From Connected Nets dialog will open. The chosen source component, and the nets connected to that component, will be selected. The dialog is described below.
5. There may also be situations where you wish to create an xSignal within an existing xSignal, in this situation the xSignal mode of the PCB panel can be used. Ensure that the Select option is enabled at the top of the panel, locate the current xSignal, select the required pads in the xSignal Primitives section of the panel, then right-click on one of the selected pads in the design space and use the method described in step 2 of this list to complete the process.

Select the two pads in the Nets mode of the panel, right-click on one of the selected pads then choose Create xSignal. Note that the pads are in different nets.

Create xSignals Between Components Dialog

If you have a large number of xSignals to define, it is more efficient to use the Create xSignals Between Components dialog. Accessed via the Design » xSignals » Create xSignals command, the dialog presents Source Components and their Source Component Nets and Destination Components and allows you to create one or many xSignals in a single operation. The approach is to:

1. Select the Source Component.
2. Select the Destination Component(s).
3. Select the Source Net(s) of interest.
4. Click the Analyze button. The software will identify all possible xSignals between the chosen components that include the chosen nets and list them in the xSignals region. Note that the analysis algorithm follows the current topology of the chosen nets and this will influence the proposed xSignals (more on this below).
5. After analysis has been performed, potential xSignals will be listed in the lower region of the dialog, and all will be enabled for creation. Carefully check through the list of proposed xSignals, and enable only those that are required. 
6. Select the required class at the bottom of the dialog, or type in a name to create a new class. If no class is chosen, the xSignals are still created and you can add them to any xSignal class in the Object Class Explorer dialog (Design » Classes).
7. Click OK to create the xSignals.

The dialog will close and you will be returned to the design space. The new xSignals will be listed in the xSignals mode of the PCB panel.

Use the dialog to quickly identify and create multiple xSignals and add them to the required xSignal class.

Create xSignals From Connected Nets Dialog

If you are creating xSignals that include series termination components, a good approach is to use the Create xSignals from connected nets command. The command is available whenever a component is selected either via Design » xSignals sub-menu from the main menus or the right-click xSignals sub-menu.

This command is designed to build xSignals outward from a selected series termination component, such as a resistor or capacitor. It supports both one or more discrete components, and one or more multi-instance pack-style components, such as resistor networks. After running this command, the Create xSignals From Connected Nets dialog will open.

Use the dialog to create xSignals that span across a selected series component. In this example, two possible xSignals were proposed, only one is going to be created.

The Role of the Net Topology

When you define an xSignal, it is between two nodes or pads. However, when you select that xSignal in the xSignals mode of the PCB panel, it will actually follow the path of the connection lines that runs between those two pads, indicating that this is the path that the software assumes the xSignal will be routed. The reason it does this is because it is obeying the topology defined for that net. Net topology is defined by the applicable Routing Topology design rule; the default topology is Shortest.

The simple animation shows a CPU connected to four DDR3 memory chips, which is going to be routed using a fly-by routing strategy. The DRAM_A2 xSignal class contains four xSignals. First, the class is selected, then each xSignal is selected in turn. You can see how the xSignal path follows the topology of the net, which is currently set to the default - Shortest.

Because the net topology is currently set to Shortest, the xSignals are not following the required path from the processor to the memory chips.

xSignal Creation Commands

Apart from the Design » xSignals » Create xSignals command, there are other xSignal creation commands in the xSignals sub-menu when certain conditions are met.

Below is a summary of the commands and when they are available:

Defining the Branch Point in a Balanced T Pattern

One of the challenges of a Balanced T routing strategy is how to equalize the length of the trunks and the branches beyond the T points. The available nodes in the net are only at the pads, so it is not possible to define separate xSignals for the trunk, and from the branch point to the end of each branch. The branch points are indicated by the red dots in the image below.

One way to solve this problem is to add a single pin component to the net. Create a component with a single pad that is the size of the vias being used in the design. If the branch point component pad is single-layer, then it can also be used in combination with a blind or buried via, by placing it on the via's start or end layer, giving complete flexibility as to how the routing is created. If you only want to include the branch point component on the PCB, set the branch point component's Type to Mechanical to exclude it from the BOM, and prevent any synchronization issues with the schematic. If you plan on including the branch point component on the schematic, the component Type can be set to Standard (no BOM).

Balanced T routing can require matched lengths between intermediate branch points.

Because the branch point is a node in the net, you can now define xSignals for just the trunk, for each major branch, and for each minor branch, if needed. These can then be used to scope matched length design rules, giving the designer complete control over how finely the length matching is to be performed. 

Managing xSignals using the PCB - xSignal Panel

In the PCB panel’s xSignals mode, its three main regions change to reflect the xSignal hierarchy of the current PCB design (in order from the top):

• xSignal Classes
• Individual xSignals within a class
• Individual xSignal Primitives that constitute an xSignal (pads, tracks and vias)

xSignal Classes Region

The xSignal Classes region lists any xSignal class collections that have been defined or all available classes (<All xSignals>).

Select a class to see its xSignals list in the middle region (xSignals) and to display them in the PCB design space.

To create a new xSignal class from the existing xSignal collection, right-click in the region then select Add Class from the context menu to open the Edit xSignal Class dialog. The dialog lists the available xSignals that can be added or removed as members to the new class using the management buttons. Use the Name field to define a suitable name for the new xSignal class.

Create or add to an xSignal class by adding/removing xSignal members using the Edit xSignal Class dialog.

The panel region’s right-click context menu also offers the ability to remove (Delete) or change its visual representation in the PCB design space (for example, Change xSignal Color).

xSignals Region

The middle region of the panel displays xSignals from the xSignal Class(es) selected in the region above.

The following information is listed with each xSignal by default:

• – this feature has two functions:
  • color background – the color assigned to the xSignal (the thin line that represents the xSignal in the design space). Right-click to Change xSignal Color for all currently selected xSignals.
  • visibility checkbox – use this to always display the xSignal regardless of whether it is currently selected or not.
• Name – name of the xSignal.
• Node Count – the total number of pads in this xSignal.
• Routed Length – the sum of the lengths of the placed track and arc segments that form the routing plus the vertical distance traversed through vias (see note below). The routed length calculator does not attempt to resolve overlapping track segments or routing wiggles inside pads.
• Signal Length – accurate calculation of the total node-to-node distance. The following notes apply to Signal Length calculations:
  • Resolves overlaps and wiggles inside pads.
  • Handles routing paths created with objects other than tracks and arcs (e.g., a region or a fill).
  • Includes vertical distances through vias (see note below).
  • Includes the Total Pin/Package Length for this xSignal.
  • Includes the Un-Routed (Manhattan) Length for this xSignal.

  • Failure to comply with applicable Length/Matched Length design rules is flagged by the signal length being displayed on a colored background: signal lengths that are too short in yellow, signal lengths that are too long in red.

    See Length Tuning to learn more about how the Length and Matched Length design rules are applied.
• Total Pin/Package Length – the sum of all the Pin Package Length values in all pads in that xSignal. This value is defined as a property of the PCB pad and can also be specified in the schematic pin.
• Unrouted (Manhattan) Length – the vertical plus horizontal (X+Y) distance of all unrouted sections.
• Margin – the difference between actual signal length and the target signal length defined by applicable Length/Matched Length design rules.

Right-click in the region then use the Columns sub-menu to add the following column:

• Delay – the time it takes for a signal to propagate along that route.

xSignal Primitives Region

The PCB panel’s third region, xSignal Primitives, lists all the constituent elements (primitives) of the currently selected xSignal.

Select the region’s Show nodes only checkbox to restrict the primitives listing to pads that are the xSignal start/end point nodes. In this mode, the selected xSignal will be shown in the PCB design space as node pads joined by a thin trace (rather than tracks) that represents the xSignal path.

The lower xSignal Primitives region lists all elements of the selected xSignal, such as pads, vias, and tracks and their corresponding delay.

Displaying xSignals in the Design Space

xSignals are displayed in the design space as a thin line. The line indicates the path that the xSignal follows. The overall length of the line is the X / Y contribution to the signal length of that xSignal. The Z, or vertical contribution to the overall signal length, is described above.

In the image below, the xSignals for a differential pair are shown. The xSignal for the unselected member of the pair remains visible because the checkbox for that xSignal is enabled in the panel.

xSignals are represented in the design space by a thin line. Both xSignals in this differential pair remain visible even though only one is selected in the panel because the visibility checkbox is enabled.

Deleting an xSignal

Select the xSignal in the panel then click the Delete button below the list of xSignals. Alternatively, right-click and select Delete from the context menu, or press Delete on the keyboard.

xSignal Query Keywords

The PCB editor includes a powerful and sophisticated filtering engine. This engine is used to identify objects when searching for objects in the design space, applying rules during interactive and automatic design tasks, and for checking rule compliance. The designer tells the filtering engine which objects they are interested in by writing a query, using query keywords recognized by the filtering engine.

The following xSignal type query keywords have been added for use in design rules and design space filters:

Membership Check Type Keywords

• InxSignal - Is the object in the specified xSignal, e.g., InxSignal('DRAM_A0_PP1')
• InxSignalClass - Is the object in the specified xSignal class, e.g., InxSignalClass('PCIE')
• IsxSignal - Is the object an xSignal with the specified name, e.g., IsxSignal('DRAM_A0_PP1')

Attribute Check Type Keywords

• InAnyxSignal - Is the object in any xSignal, e.g., InAnyxSignal

Design Rule Support for xSignals

Design rules are how you translate your requirements into a set of instructions that the PCB editor can understand and obey. Rules can be checked during object placement, referred to as Online DRC, or as a post-process, referred to as Batch DRC. xSignals can be used to define the objects to which a design rule must be applied.

► Learn more about Design Rules

► Learn more about Length Tuning

Matched Length Rule

The Matched Length design rule is used to ensure that the length of the specified nets is within the specified range. This rule is essential in a high-speed design, where the challenge is not just about how long it takes the signals to arrive (which is determined by their overall length), but how important it is that the specified signals arrive at the same. Depending on the signal switching speeds, the function of the signal, and the materials used in the board, the allowed difference could be as much as 500mils, or as little as 1mil.

The image below shows an example of the Matched Length design rule configured to target the xSignals in the xSignal class PCIE, and test for a difference in lengths within each differential pair in that xSignals class. Each pair in the class must have routed lengths that result in a Delay Tolerance of no more than 2ps delay between the two nets in that pair.

Note that the Matched Length design rule Constraints requires you to select between matching the length of all targeted nets (Group Matched Lengths), or matching the two nets within each diff pair in the targeted nets.

The image below shows the PCIE_TX xSignal class selected in the panel, and those xSignals selected in the design space.

As well as the PCIE class, there are also classes defined for the TX and RX pairs. Note that one of the TX xSignals fails the applicable matched length rule. ##

If you plan to length tune xSignals which include single nets and differential pairs, create the following rules:

• A matched length rule that defines the length matching requirements between nets and differential pairs in xSignals. To configure the rule to test the length of one net/pair against the length of another net/pair, enable the Group Matched Lengths option.
• A second, higher-priority matched length rule that defines the within-pair length matching requirements. To configure the rule to test the length of one pair-member against the other pair-member, enable the Within Differential Pair Length option.

A good approach to tune the lengths of such xSignals is to:

1. Route the nets and differential pairs of the xSignal.
2. Length tune the single nets using the Interactive Length Tuning command.
3. Length tune between the pairs using the Interactive Differential Pair Length Tuning command. Length tuning uses the longest signal length in the longest pair as the Target Length, and tunes the longest net in the pair to this length.
4. Length tune the shorter net within each pair against the other net in the pair using the Interactive Length Tuning command.
5. Now you can use the PCB Rules and Violations panel to check the within-pair Matched Net Length rule(s). To do this, select Matched Net Lengths in the Rule Classes section of the panel, then right-click on the required Matched Length rule and select the Run DRC Rule <RuleName> command from the context menu. Adjust the single-net tuning accordions if required.
6. Then use the PCB Rules and Violations panel to check the between-pair Matched Net Length rule(s), using the process just described. Adjust the differential pair tuning accordions if required.

Length Rule

The Length design rule is used to ensure that the overall routed length is within the specified range. This rule is typically used to ensure that the target nets are no longer than the specified length, for example, to ensure that the circuit timing requirements will be met. The length rule respects the xSignal type queries listed above.

Return Path Rule

The Return Path design rule checks for a continuous signal return path on the designated reference layer above or below the signals targeted by the rule. The return path can be created from fills, regions and polygon pours placed on a signal layer, or it can be a plane layer.

The return path layers are the reference layers defined in the selected Impedance Profile. Add a new Return Path design rule in the High Speed rule category.

The image below shows a Return Path rule violation, where the xSignal return path polygon has a hole for a via to pass through.

Using the PCB Rules and Violations panel to locate a Return Path rule violation. ##

Accurate Length Calculations

A key requirement of defining high-speed design rules is an accurate calculation of the route lengths. The traditional approach to calculating signal length is to add up the centerline length of all segments used in a route, as well as the vertical distance due to the height of the vias, which was originally determined by the board thickness.

This approach is not adequate for a high-speed design for a number of reasons, including:

• Stacked and overlapping objects - an algorithm that simply adds the centerline length of all objects in a net does not cater for stacked or overlapped objects.
• Wandering route path within an object - there are often routing objects completely within a pad or via, which can falsely add to the length, as shown in the first image below. The second image shows the correct way to calculate the length when a fill object is part of the routing.
• Via length - blind and buried vias do not traverse all layers of the board, so the board thickness is not sufficiently accurate to determine the vertical length. The actual via height must be used, taking into consideration the copper and insulation thicknesses that the via passes through.

The PCB editor's length calculator returns the most accurate route length possible.

The length calculation is accurately calculated along the centerline of the shortest path, as shown in these two images.

Accurate lengths, based on the layers traversed and the stackup dimensions, are calculated for vias. Image from the PCB panel in Nets mode.

Pin Package Delay

In every high-speed design over 500 MHz, the connection medium, or bond wire to the die, introduces a delay to the signal. This in-device delay is referred to as the pin-package delay. Even if two devices are fully pin-compatible from a design and PCB standpoint, package flight times will be different across different devices, so they will need to be accounted for. Flight time information can be found within the IBIS 6 document for the device. The Package Pins information should be considered during the I/O planning stage, or after synthesis for an FPGA. All device manufacturers should be able to supply the package delays, which will be specified either as a picosecond delay or as a length.

The delay can be included in your design either as a Pin Package Length or as a Propagation Delay, using the respective fields for the pin in the schematic editor or the pad/via in the PCB editor. The values entered are handled as follows:

Pin Package Length - all pin package lengths within each net are added in the PCB editor to give the Total Pin/Package Length, which is included in the overall Signal Length for that net. Refer to the Nets mode of the PCB panel to learn more about the Signal Length.

Propagation Delay - all user-defined delay values defined for pins/pads and vias in each net are added to the routing delay for that net in the PCB editor. The routing delay is automatically calculated by the Simbeor® field solver built into the Layer Stack Manager. Pad and via delays are not calculated automatically but can be user-defined.

Including the Delay in the Schematic

Pin package lengths can be defined as an attribute of the schematic component pin in the Properties panel in Pin mode. The software will default to use the Units of the underlying document, enter the units with the value, if required.

Enter the pin-package length with the required units.

Defining the Delay in the PCB Editor

The Pin Package Length and Propagation Delay values are transferred to PCB layout as seen in the Pad mode of the Properties panel.

The Pin Package Length and Propagation Delay values are transferred from the schematic to the PCB, or they can also be defined directly in the PCB.

Examining the Pin/Package Length and the Propagation Delay in the PCB Panel

The Pin/Pkg Length is automatically included in the Signal Length calculations, which are displayed in various modes of the PCB panel. Set the panel to Nets mode to examine (or edit) the value of the Pin/Pkg Length for the pins in the chosen net. Note how the Routed Length column reflects the length of the routing, and the Signal Length column reflects the length of the routing plus any Pin/Pkg Lengths in that net.

The Pin/Pkg Length and its impact on the Signal Length is shown in the Nets mode of the PCB panel.

In the image below the propagation Delay column shows that there are two pairs of xSignals that are failing a Matched Length design rule. Because the highlighting is in the Delay column, it indicates that the rule is configured to use Delay Units rather than Length Units.

The Delay column shows that there are two pairs of xSignals that are failing a Matched Length design rule. 

How the Length is Included in xSignals

The Pin/Pkg Length is automatically included in the overall xSignal length when:

• That signal is part of an xSignal definition
• That pad is not connected in a fly-by routing pattern (there is only one trace connected to that pad)

Net-related Terminology

In the PCB editor, the following terminology is used:

• Net – a collection of components pins (nodes) that are connected to each other. The arrangement of how those nodes connect to each other is referred to as the topology; the default topology is shortest.
• From-To – conceptually, a From-To runs between two nodes in a net. The From-Tos can be created to follow the topology or arrangement of nodes in that net. For example, the net topology could be from R1-1 to U1-5 to U3-2 to R5-2. This net could have three From-Tos: R1-1 to U1-5; U1-5 to U3-2; and U3-2 to R5-2. If the topology is changed so will the possible From-Tos. From-Tos are created in the From-To mode of the PCB panel by either clicking the Generate button to create them based on a topology, or by selecting two pads in a net then clicking the Add From To button.
• xSignal – a user-defined set of nodes, typically a sub-set of a net (from this node to that node), or a combination of two nets that include a series component, such as a termination resistor.