IP Hierarchy conflicts

Version conflicts in the hierarchy are allowed, since users may not have control over the hierarchy of the resources they are trying to use, as when an older version of a subsystem is reused in a newer IP Hierarchy. Helix IPLM maintains the different versions or lines on the server, and tracks them as 'conflicts'. For example, a user may wish to add a Cache IP and a Logic IP to their CPU, and these two IPs might have the same 'Standard Cell' IP as a resource, but at different versions.  

When an IP Hierarchy is loaded into a workspace, there can only be one version or line of a given IPV in the workspace at any given time. It is of course possible to update a given IP to a new version or line in the workspace after it is initially loaded. When a workspace is built the conflicts are resolved. The conflict can be resolved automatically by Helix IPLM using the rules below, or it can be resolved explicitly by applying the '–resolve' project property on the IPV.

Automatic conflict resolution

Conflicts between fixed IP versions can be resolved automatically by Helix IPLM:

Conflict Automatic Resolution Example
Two fixed versions on the same Line Choose the latest release IP@5 conflicts with IP@12, resolve to IP@12
Two fixed versions on different Lines

If TRUNK is in conflict choose TRUNK, otherwise

Choose the alphanumerically latest line name between the conflicting lines

IP@2.TRUNK conflicts with IP@10.VARIANT1, resolve to IP@2.TRUNK

IP@2.ALINE conflicts with IP@10.VARIANT1, resolve to IP@10.VARIANT1

Conflicts between aliased IP versions are resolved automatically according to the precedence:

Alias conflict resolution 
choose @HEAD before @LATEST before @<MOVING_ALIAS> before @<Fixed Release>

Conflicts between two or more different Moving Aliases are by default resolved by the reverse alphanumeric ordering between the two alias names. It is also possible to configure automatic alias resolution between two moving aliases by their underlying IPV versions, via the 'pi-admin settings' command. 

When using the reverse alphanumeric sorting order the aliases will be sorted via a "smart" algorithm that takes alphabetical and numerical values into account. For example, if we have the moving aliases "V1", "V5", "V10", then the alphabetical sorting order will also be "V1", "V5", "V10" instead of "V1", "V10", "V5", which would happen with an alphabetical sort. One frequently used approach is to use a "R_X_Y_Z" (<release><major>_<minor>_<hotfix>) naming scheme. When using the following alias R_1_0_0, R_1_10_0 and R_10_0_0. The alphanumeric sorting order will return the expected order R_1_0_0, R_1_10_0 and R_10_0_0.

When using the highest underlying release mode, the algorithm will look at all the conflicting aliases, and pick the largest fixed version among them. This means that it will resolve to the latest release among the conflicting aliases.

Conflict Resolution Method Automatic Resolution Example
IPVs included at moving aliases alphanumeric (default) choose between ALIAS names in reverse alphanumeric order IP@REVIEW [@2] conflicts with IP@PASSED [@5], resolve to IP@REVIEW [@2]
version choose between ALIASes according to latest underlying IPV IP@REVIEW [@2] conflicts with IP@PASSED [@5], resolve to IP@PASSED [@5]

Automatic conflict resolution configuration

There are two options to define the automatic conflict resolver that should be used:

  • Global settings via "pi-admin".
  • Per IP via project properties.

The global setting can be configured via the "pi-admin settings edit" command. This will bring up an editor where the variable "IP.IPV.project_props.auto_resolve" can be configured to be either "alphanumeric" or "version".

  • alphanumeric: Use alphanumeric alias resolution (default).
  • version: Use Highest Underlying Version resolution.

Per IP settings can be configured via "pi ip edit lib.ip", and adding a “project_props = * --auto-resolve alphanumeric|version” 

  • Users can indicate for a particular Library or IP how the conflicts should be automatically resolved.
  • The mode is restricted to ‘*’ as the resolution conflict should apply to the entire tree.

Explicit conflict resolution

Specifying multiple resolutions

Multiple resolutions can be specified by adding the IP Fully Qualified Names (FQNs) in a space separated list in the project properties definition in the IP template. Be sure to specify the line of the IPs you wish to resolve.

project_props = * --resolve LIB.IP1@5.LINE LIB.IP2@12.LINE LIB.IP3@LATEST.LINE

Resolve property as a temporary fix

The intent of the --resolve property is to be a temporary fix, the best approach is usually to configure the IP Hierarchy in a way that avoids conflicts as much as possible.

Origin of conflicts

Conflicts can be introduced directly, through editing the resources of an IPV (making a new release) or indirectly as when an IPV is included at an alias in the hierarchy. If the resource versions associated with that aliased IPV change, it may introduce new conflicts between the aliased IPV's sub-hierarchy and other parts of the tree. 

Conflicts introduced during IP edits:

Assume an IP has two resources A and B. Each resource calls the same sub-resource - P - but at different versions.

Conflicts in IP edits 
IP->A->P@2
   ->B->P@3

When the IP is created, Helix IPLM will warn that "IP" has a conflict (resource P is required at both version 2 and 3 which is supported in the server side release hierarchy but which is not possible/allowed in the workspace).

The first approach should always be to resolve conflicts in the IP release hierarchy directly, by making the necessary releases to remove the conflicts. In some cases this is not possible because the IP consumer doesn't have permission to modify some part of the conflicting IPV hierarchy. To resolve this conflict explicitly, a --resolve project property can be set on the top level IPV in their hierarchy. 

--resolve project property 
project property: * --resolve P@2

In this case, the user has specified that P@2 should be selected, even though B is expecting to find P@3 in the workspace. See the Workspace Configuration page for details on using project properties.

Conflicts introduced by dynamic IPs:

Assume we have this IP Hierarchy:
IP Hierarchy example 
IP
+- A@HEAD
|  +- P@5
+- B@HEAD
|  +- P@5

If A is edited such that:

'A' edit 
A->P@6

then a conflict is created in IP's hierarchy, even though we did not edit IP directly. This conflict too can be explicitly resolved without modifying the IPV hierarchy, by specifying a resolution using a '--resolve' project property for IP. 

--resolve example 
project property: * --resolve P@5