IP Hierarchy

The Helix IPLM IP Hierarchy, also called Component and IP BOM (CIPB), is built out of IP objects. Each IP Versions (Releases) has a set of resource fields 'resources' (and 'private_resources' - described below). Each IPV defines its children, or resource IPVs, via entries in its resources field. There is no limit to the depth of hierarchy, as each IPV resource can have resources of its own.

IP Hierarchy overview

The Helix IPLM IP Hierarchy is a hierarchical Component and IP BOM (CIPB) that can be used to capture a release of a fixed set of IP data. Each IP in the hierarchy is captured with its required resource dependencies, and can potentially be reused in other contexts with full traceability.

Each element in the hierarchy is either at a specific version, or at a designated dynamic alias (HEAD, LATEST, a moving alias, etc). When creating a hierarchy, or modifying an existing hierarchy, Helix IPLM checks for circular dependencies - for example A has a resource B, which in turn has A as a resource. When circular dependencies are encountered, Helix IPLM will not allow that IP to be created or released.

An example IP Hierarchy (CIPB) is shown below.

IP Hierarchy (CIPB) example

tutorial.tutorial@7.TRUNK
├─ ARM.cortex@1.TRUNK
│  └─ ARM.cortex_source@1.TRUNK (p)
│     ├─ ARM.cortex_ALU@1.TRUNK
│     ├─ ARM.cortex_CPU@1.TRUNK
│     └─ ARM.cortex_I2C@1.TRUNK
├─ tutorial.CADenv@GOLD.TRUNK [@1]
├─ tutorial.analog_top@HEAD.TRUNK [@6]
│  ├─ tutorial.MS90G@1.TRUNK
│  ├─ tutorial.acells_tsmc18@1.TRUNK
│  ├─ tutorial.clkgen@HEAD.TRUNK [@1]
│  ├─ tutorial.pwr_mgmt_ana@HEAD.TRUNK [@1]
│  ├─ tutorial.stup_ana@HEAD.TRUNK [@1]
│  │  ├─ tutorial.acells_tsmc18@1.TRUNK
│  │  └─ tutorial.laysc_tsmc18@1.TRUNK
│  └─ tutorial.trc@HEAD.TRUNK [@1]
├─ tutorial.digital_top@3.TRUNK
│  ├─ tutorial.aes512@1.TRUNK
│  ├─ tutorial.clk_mux@2.TRUNK
│  │  └─ tutorial.rxtx@2.TRUNK
│  │     └─ tutorial.gen_dig@2.TRUNK
│  ├─ tutorial.cpu@LATEST.TRUNK [@3]
│  │  ├─ tutorial.bist_sram@2.TRUNK
│  │  │  └─ tutorial.gen_dig@2.TRUNK
│  │  ├─ tutorial.gen_dig@2.TRUNK
│  │  └─ tutorial.proj_tech@1.TRUNK
│  ├─ tutorial.events_if@2.TRUNK
│  │  └─ tutorial.gen_dig@2.TRUNK
│  ├─ tutorial.flash@2.TRUNK
│  │  ├─ tutorial.flash_if@2.TRUNK
│  │  │  └─ tutorial.gen_dig@2.TRUNK
│  │  ├─ tutorial.gen_dig@2.TRUNK
│  │  └─ tutorial.proj_tech@1.TRUNK
│  ├─ tutorial.gen_dig@2.TRUNK
│  ├─ tutorial.interface@4.TRUNK
│  │  └─ tutorial.gen_dig@2.TRUNK
│  ├─ tutorial.proj_tech@1.TRUNK
│  └─ tutorial.tool_cert@LATEST.TRUNK [@0]
│     └─ certification.ibm_rqm@0.RQM_6_0_5
├─ tutorial.fusa@LATEST.TRUNK [@0]
├─ tutorial.padring@1.TRUNK
│  ├─ tutorial.MS90G@1.TRUNK
│  ├─ tutorial.io5v@1.TRUNK
│  └─ tutorial.io_tsmc18@1.TRUNK
└─ tutorial.verif_config@1.TRUNK

Sub-hierarchy contexts

Each sub-hierarchy in the top level tutorial hierarchy can function as its own top level hierarchy and be directly loaded into workspaces, developed, updated, and released in its own context. This means when the tutorial.tutorial@7.TRUNK IPV is loaded into a workspace it will bring along the various resource IPVs that are a part of its release hierarchy, including tutorial.padring@1.TRUNK. We could alternatively load tutorial.padring@1.TRUNK directly. The developers working on the padring can load the padring IP and its resource tree in their context to run checks, perform characterization, and make releases back into Helix IPLM.

The integrators working in the tutorial.tutorial@7.TRUNK IPV workspace could then update their local workspace to include a new padring release, say tutorial.padring@8.TRUNK, and make a new release of tutorial to include it. It is often advantageous to split up development contexts like this, especially when a sub hierarchy will be delivered into multiple higher level projects.

Resources and releases

Editing the resources of an IP generates a new release of that IPV. Each level of IP Hierarchy is modified one level at a time (workspace based hierarchical releases can automate this process) by editing a particular IPV's resources. Resources can only be directly added or removed from a given hierarchy via server side edits, ie pi ip edit or modification via IPLM Web or the API. Resource versions and lines can be modified either via server side edits, or through workspace updates.

Modification	Clients	Notes
Changing the Version or Line of a Resource	Server Edit, Workspace Update	Changing the version or line of an IPV that is already a resource of a parent IPV
Add/Remove of a Resource	Server Edit	Adding or removing an IPV from the resource list

Hierarchy permissions considerations (partial workspaces)

Helix IPLM can build Partial Workspaces. This means that if a particular user or group doesn’t have permissions to some IPs in the hierarchy, Helix IPLM will still build the portions of the workspace that the group does have access to. The IP Hierarchy should be constructed with this in mind, because IPs that the restricted group does have access to won't be loaded into the workspace if they are only attached as resources under IPs they do not have access to. Once built, partial workspaces are fully functional, supporting update modes, releases, and all other workspace functionality. In the case of releases, if particular IPs are not in the workspace their versions will be maintained from the previous release.

A key benefit of partial workspaces is that the same IP Hierarchy can be used for all users, no matter what permissions they may have. More information is available on the Workspaces and Permissions page.

Hierarchy and DM type

IPs are differentiated by their DM type (Container, FS, P4, P4S, SVN, git, etc) but there is no difference in the behavior of any IP regarding their inclusion in an IP Hierarchy. All IP DM types can include an IP of any other DM type as a resource. This means there is no restriction on mixing and matching any DM type IP at any level of the IP Hierarchy. Perforce IPs can include git IPs, Container IPs, Filesystem IPs, etc as resources, and the same goes for any other combination. When the IPs are built into a workspace, each will have its data loaded with the appropriate underlying DM system. At the Helix IPLM level each is abstracted into an IP object and the DM doesn't impact their interoperability as IPs.

Note: Perforce (P4) and P4Stream (P4S) type IPs are fully interoperable just like any other combination of dm_types. When built into a workspace, each P4S IPV gets its own p4 client, in line with each Stream spec managing its own client. P4 type IPVs behave the same in the workspace whether P4Stream IPVs are present or not.

Helix IPLM provides a special IP object type, Containers (CONT). Container IPs are identical to standard DM type IPs such as Perforce , P4Stream, and git with the exception that they don’t have any connection to an underlying DM system, they exist only as Helix IPLM level objects. As Helix IPLM level IPs they can have resources themselves or be included as a resource to a higher level IP. Containers are used to tie together other DM (or CONT) level IPs into single IP Hierarchies. If needed they can be converted to P4 IPs. See Creating New IPs for more information on IP types.

Private IPs

As noted at the beginning of this section, Helix IPLM provides two resource fields for inclusion of resource IPVs, 'resources' and 'private_resources'. From the 'pi ip edit' template:

# Resources are optional
# One resource per line (newlines require a leading space)
resources = 

# Private resources are only loaded when this IP is the top level of a Workspace.
# This is useful to prevent subsystem test benches from loading into bigger Workspaces.
private_resources = ARM.cortex_source@1.TRUNK

If an IPV is included as a private resource, it is only included in the workspace if its direct parent is loaded into a workspace as the top level IPV. The private resource will be omitted if its parent is included as a resource of some higher level IPV. This functionality can be leveraged to include resources that only merit inclusion when an IPV is loaded on its own, but not when it is loaded as a subsystem resource of a higher level IPV. Testbenches and source IPV Hierarchies are typical examples of this.

Note: Private IPs only show their special behavior in the workspace context. When viewed in an IPV hierarchy, they are full members of the hierarchy, and will show up in usage reporting.

Using aliases in the IP Hierarchy

IP Releases are captured as sequential numbers, but can also be assigned user defined aliases. These aliases can be used to indicate the release has achieved a particular quality level, or to capture a milestone, ie that a particular release was the taped out (released to manufacturing) version. In addition to user defined aliases there are two built-in aliases, @LATEST and @HEAD.

IPs can be attached as resources to a parent IP using an alias rather than a fixed release version. Doing this in some cases will change the IP Hierarchy from consisting of entirely fixed releases (static tree) to a Hierarchy that has releases that may change as new aliases are applied to its resources (dynamic tree). At the time of final tapeout it is almost always required that the IP Hierarchy be fully static, but at earlier stages of development aliased IP versions can facilitate automatic updates, a concept called ‘Moving Aliases’. Using the @HEAD or @LATEST aliases in the hierarchy can be useful when the project is in its very early stages and no qualified releases yet exist. It is possible to lock user defined aliases so they will no longer change, and to apply unique aliases that can only be applied to one IP version across all lines of the IP.

The following table lists all available aliases and user options within the Helix IPLM framework

Alias	Definition
@LATEST	Updated every time a new release is made in Helix IPLM pointing to the latest Helix IPLM release. If a new release is made and pi up run in the @LATEST workspace IP the new release is then brought into the workspace. In the early stages of a project, before qualified releases are available, IP resources can be included @LATEST. This keeps workspaces updated with the latest release available, without consideration of the quality of the release. Note This alias is built into Helix IPLM and can’t be modified by the user.
@HEAD	Pulls in all the latest files in the underlying DM system, regardless of whether they have been captured as a part of a Helix IPLM release. If a new DM file version is checked in and a ‘pi update’ subsequently run, the new file will be pulled into the IP@HEAD workspace with no intervening Helix IPLM release. The resources of the @HEAD IP will be the same as those of the @LATEST version, equivalent to the latest release in Helix IPLM. In the very early stages of a project, before meaningful releases have yet been captured, IP resources can be included @HEAD. This will pass through any file checked into the DM system, without relying on a Helix IPLM release for the file contents of the IP. This results in a very dynamic development environment, it is generally advisable to move to slower changing Helix IPLM releases as they are available. Note This alias is built into Helix IPLM and can’t be modified by the user.
User Defined (Moving) Aliases	User defined aliases can be applied to IP Versions and are generally used to denote either that the IP release has achieved a certain quality level, or to denote an IP milestone like a tapeout. If multiple IPVs on a line have the same alias applied, Helix IPLM will return the latest version with the alias. As new qualified versions are available a ‘pi up’ of a workspace IP@<ALIAS> will update to the latest version that has the alias. Note New releases without the alias won’t be pulled in to update the workspace.

Locking aliases

In the case of a user defined alias that should only be applied once to an IP Line (ie a tapeout) the alias can be locked. When locked, no additional IP releases on that line (beyond those already set at the time of lock) can have that alias applied. This results in the latest IPV with the alias being returned when the IP@<ALIAS> is requested.

Unique aliases

Unique aliases are aliases that can only be set once per IP across all lines on the IP. This is useful to denote special releases, and in flows that leverage data across multiple IP Lines. Unique aliases make it easy to specify one release on one line of the IP as the release of interest.

IP Hierarchy on IPLM Web

The IP Hierarchy can be viewed on IPLM Web from the Hierarchy sub-tab on the Hierarchy and contents selector on the IP page. Select Tree view or Flat view in the view selector:

In Tree view, the hierarchical resource relationships between each level of the tree are displayed, which allows easy viewing of parent/child relationships at each level of the hierarchy.

In Flat view a uniquified list of all the IPVs in the Tree view are presented in a flat list. Each IP version that appears in the tree will be listed just once in the Flat view.

Both Tree and Flat views can be filtered and can show the configurable list of properties and built in fields associated with each IPV in the tree.

Use the search to find an IP in the Hierarchy. In Tree view the parent IPVs in the hierarchy are shown above matching filtered IPVs. In Flat view, only the actual filtered IPVs will be shown, so it may be easier to parse the results of the search.

If any conflicts are present, they will be displayed as colored flags on the conflicted IPVs. A fixed IPV of a particular version and an aliased version of the same IPV will appear as separate entries in the flat list. This makes it easier to see a summary of conflicts than would be possible in Tree view, where conflicted versions may occur in very different portions of the tree.

As an example if LIB.IP@ALIAS [@24] and LIB.IP@24 both appear in the hierarchy, in Flat list view, each will appear on its own row in the flat list, even though both resolve to the same underlying fixed version.

See Editing IPs for more information on conflicts.

Setting IP permissions for an IP Hierarchy

Select the Set permissions icon.

Select the permissions, then select Apply to tree to assign the permissions to the IP Hierarchy.