IP aliases

Helix IPLM releases are assigned sequential numbers, but not all releases are equally important. Aliases provide a way to apply a meaningful name to particular IP releases, and enable the Moving Alias flow. There are three types of aliases in Helix IPLM: Built in Aliases, Moving Aliases, and Unique Aliases. This section describes the types of Aliases and their functionality.

IP alias overview

Users with write permissions on an IP Line can alias IPVs on that line with a string. The Alias can then be used to reference the IPV instead of that IPV's version number. IP Hierarchies can be constructed that reference the alias instead of the IPV release number, and workspaces can be loaded or updated with aliased IPVs. User Aliases can be applied or removed from any particular IPV once the release has been made. User Aliases are often used as indicators in one of several ways:

• Release Quality Level - Aliases applied to IPVs can be any text string, and can be set up to indicate the quality level of the release. Examples are GOLD, SILVER, and BRONZE, though any naming scheme can be used. IPVs so designated can be understood at a glance by users viewing the release, and further can be integrated automatically into development hierarchies via the concept of Moving Aliases (described below).
• Important Releases - Aliases can be applied to a IPV and then locked. Once locked the Alias can't be added to any more releases on that line. The Alias can be used to designate which release corresponds to a particular tapeout, or other significant milestone.
• Line Selector - In design flows that use a number of different lines, it is possible to apply a Unique Alias that can only be applied to one IPV on one Line at a time. The IPV can be referenced via the Unique Alias (without including a Line specifier).

Aliases and dynamic hierarchy

Using Aliased references to IPVs allows automatic incorporation of releases by quality level or similar considerations, which is quite valuable, especially in the early and middle stages of a project. An important consideration is that hierarchy that references aliases is dynamic, when you make a release you may not have fully captured the design state in the release. If the alias referenced in the release hierarchy is added to a new IPV, the contents of the release will subsequently be different. For this reason, it is highly recommended that in the later stages of a project the IP Hierarchy be converted into a fully static tree, that is only fixed release number should be used without Aliases. 

Built in aliases

In addition to User Aliases that can be applied to any IPV, Helix IPLM automatically maintains two built in Aliases, @LATEST and @HEAD. These specific alias names can't be added, deleted, or directly modified in any way by the user.

@LATEST

The 'LATEST' alias is an automatically created alias that always resolves to the latest IPV release on an IP Line. This is a built-in alias that cannot be modified. Users can reference it in an IP Hierarchy or load or update it in a workspace like any other moving alias, but cannot add or delete it. For example, 'LIB.IP@LATEST.TRUNK' will always resolve to the latest release of that IP on line TRUNK.

@HEAD

HEAD is a special built-in alias that cannot be deleted or added. The HEAD alias denotes the resources of the Latest IPV Release on a line, but its contents are the latest (@HEAD) files checked in to its DM system, regardless of whether those files are part of a Helix IPLM release or not. Note that HEAD is an alias, so it is dynamic. Thus LIB.TOP@HEAD.TRUNK will always resolve to:

• The resources captured by the LATEST release of LIB.TOP. These resources are computed at the time of the action (workspace update, ip load, etc)
• The latest (top-of-tree) checked in design file versions under the IP's repo_path in the DM system, whether those files versions are captured in a Helix IPLM release or not. If the IP is a File System or Container IP with no DM managed files, @HEAD will be equivalent to @LATEST, and deliver the IP resources corresponding to the latest release of the IP.

Note the @HEAD alias is unique in that it crosses the line between Helix IPLM level IP releases (its resources) to the underlying DM system (its contents). Including an @HEAD IPV in an IP Hierarchy, or loading or updating an @HEAD IP in a workspace implies both the Helix IPLM resources and @HEAD DM files (which won't always be part of a release) should be delivered to the workspace. It is entirely possible (and often preferable) to load a fixed IPV release and then run DM commands, ie 'p4 sync' (in Perforce DMs) to get the same content. Loading Aliased IPs into a workspace has implications for how subsequent updates and releases will be performed, so it is important to understand the tradeoffs. This is discussed in more detail in the Workspaces section.

@LATEST and @HEAD comparison

The difference between the @LATEST and @HEAD alias is often confusing for users

Moving aliases

As long as the Alias is not locked and not Unique, multiple IPVs on a line can be aliased with the same Alias string. If the same Alias is applied to multiple IPVs on the same line, when the ALIAS is referenced, the highest version IPV on the line that has the ALIAS applied will be returned. This functionality allows for resources (and hence the overall IP Hierarchy) to be dynamic.

By applying the same ALIAS to multiple IPVs on one line, and using that ALIAS in the resource list of a top IP, users can automatically inherit the latest aliased version of a resource without making a new release of the top level IP. An alias replaces the version number in the IP identifier - for example, lib.ip@GOLD.TRUNK, where GOLD is an alias.

For example, if LIB.TOP uses LIB.IP@GOLD.TRUNK as a resource, Helix IPLM will not resolve this GOLD alias to its current value (say lib.IP@10.TRUNK) at the time of creation. Instead, it will retain the resource at LIB.IP@GOLD.TRUNK. When actual operations are performed on LIB.TOP, then Helix IPLM will resolve the ALIAS to its latest value at that time. Actual operations include loading the IP into a workspace, updating the IP etc. Specifically, when you run ‘pi ip load LIB.TOP’, Helix IPLM will bring in LIB.IP@10.TRUNK into the workspace. At a later point, LIB.IP@12.TRUNK is also aliased with GOLD. Now if a user runs ‘pi update’ in the workspace, Helix IPLM will figure out that a newer version of LIB.IP is available, and will bring in LIB.IP@12.TRUNK.

Locking aliases

In some cases the standard Moving Aliases functionality is not desired, instead what is needed is a fixed alias that can't be removed or added to any other version of an IP on a line than the one(s) it is already applied to. A typical scenario is to alias an IPV that corresponds to a particular tapeout or other specific milestone.

To support this flow aliases can be locked or unlocked from PiCLI with the alias lock/unlock commands. By default aliases can only be locked or unlocked by users that are in the admin group. This behavior can be changed if desired via a server side hook, see the Server Side hooks section for more details.

Unique aliases

Unique aliases differ from Moving Aliases in that for any particular IP, the alias can only be applied to a single IP Version on a single Line of the IP at any given time. Unique aliases are useful when development may be taking place across many different lines of the IP, and it is necessary to designate only one IPV across all those lines with a special status.

To differentiate Unique aliases from Moving Aliases, unique aliases always have a leading "+" character, so the alias "+MYALIAS" would indicate the alias is unique. Unique aliases are created with the 'pi alias add' command with the addition of the --unique flag to indicate the Alias is unique. If the alias already exists on any other IPV on any other Line of the IP, the add command will fail. The 'pi alias move' command can be used to move the alias from one IPV to another on the same or different line. The leading "+" character must be omitted when adding the alias, Helix IPLM will automatically prepend it to the alias name based on the presence of the --unique flag. If the leading "+" character is included the 'pi alias add' command will fail.