Workspace State and Making a New Release

As work proceeds in a Helix IPLM workspace, Helix IPLM can be used to analyze the workspace and how it differs from the top level hierarchy originally loaded into the workspace. Modified files, new versions, and update resources are summarized with the 'pi workspace status' command. The 'pi ip diff' command can be used to show a detailed comparison of each IP and its changes in the workspace.

Analyzing the Workspace State

After Helix IPLM builds a workspace based on a IP Hierarchy captured by the Helix IPLM server, users will work in it using their preferred tools and flows. File level DM operations will be handled with the DM system used to manage each IP in the workspace. At any point in the development process Helix IPLM can be asked to report on the current state of the workspace versus the IP Hierarchy that was originally used to build it. This is accomplished with the 'pi ws status' command:

pi ws st Command
> pi ws st
Workspace ID : 7133a773-fd21-491f-8446-b8f6d60f7882
Directory    : /tmp/workspaces/sub2/ws1
IP           : tutorial.tutorial@6.TRUNK
Resources    :
┌──────────────────────┬───────────────────┬───────────────────┬───────────┬─────────────────────────┬───────┐
│ NAME                 │  EXPECTED VERSION │   LOCAL VERSION   │ WS STATUS │      SERVER STATUS      │  MODE │
╞══════════════════════╪═══════════════════╪═══════════════════╪═══════════╪═════════════════════════╪═══════╡
│ tutorial.tutorial    │      6.TRUNK      │      6.TRUNK      │  Modified │ New resources available │ Refer │
│ tutorial.CADenv      │  GOLD.TRUNK [@1]  │      1.TRUNK      │     OK    │   New @GOLD available   │ Refer │
│ tutorial.bist_sram   │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
│ tutorial.cpu         │ LATEST.TRUNK [@3] │ LATEST.TRUNK [@3] │  Modified │            OK           │ Refer │
│ tutorial.dbuf        │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
│ tutorial.digital_top │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
│ tutorial.events_if   │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
│ tutorial.flash       │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
│ tutorial.flash_if    │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
│ tutorial.gen_dig     │ LATEST.TRUNK [@2] │      1.TRUNK      │     OK    │  New @LATEST available  │ Refer │
│ tutorial.interface   │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
│ tutorial.padring     │      1.TRUNK      │      9.TRUNK      │  Modified │            OK           │ Local │
│ tutorial.rx_channel  │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
│ tutorial.rxtx        │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
│ tutorial.sys_bus     │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
│ tutorial.t0          │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
│ tutorial.t1          │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
│ tutorial.timers      │      2.TRUNK      │      2.TRUNK      │  Modified │            OK           │ Refer │
└──────────────────────┴───────────────────┴───────────────────┴───────────┴─────────────────────────┴───────┘

Any modified Resource IPs are listed in the first NAME column, with the first IP in the list being the top level IP used to load the workspace.

The second EXPECTED VERSION column shows the IP Version that is expected to be in the workspace based on the IP Hierarchy loaded by the top level IP (in this case tutorial.tutorial@6.TRUNK). The third column, LOCAL VERSION shows the version of the IP currently loaded in the workspace. Running 'pi update' on resource IPVs can move them to different versions in the workspace, and a comparison between the EXPECTED VERSION and LOCAL VERSION columns highlights the difference between the two versions. For example in the output above, the version of tutorial.padring has been updated from padring@1 (as defined in the tutorial.tutorial@6.TRUNK) hierarchy to padring@9 in the workspace.

The fourth column, WS STATUS, shows if the IPV is modified in the local workspace. A modified state occurs when either the contents (files) or resources (child IPs) of an IPV are changed and indicates that a particular IPV has been loaded into the workspace, but the contents or resources of the IPV have since been modified such that they no longer exactly match the release captured on the Helix IPLM server. Further details on the nature of the modifications present can be found via the 'pi ip diff' command displayed in the following section.

The SERVER STATUS column indicates whether new versions of Aliased IPVs are available on the server, which could be brought into the workspace via a 'pi update' command. 

Finally the MODE column indicates whether the given IPV is loaded in the local workspace, and is available for edit (Local mode) or whether it is loaded into the Helix IPLM IP cache 'PiCache' in read only 'Refer' mode. Loading IPVs in PiCache speeds workspace loads, and is convenient for creating tapeouts or other important releases, as there is no possibility of unintentional local edits in the workspace.

Detailed IP modification information with 'pi ip diff'

IPs displaying a modified state in the output of the 'pi ws status' command can be further examined for specific changes using the 'pi ip diff' command:

pi ip diff Command
> pi ip diff padring
tutorial.padring@9.TRUNK on the server and tutorial.padring@9.TRUNK in the Workspace differ.
┌─────────────────────────┬──────────────────────────┬───────────┐
│ FILES                   │ tutorial.padring@9.TRUNK │ Workspace │
╞═════════════════════════╪══════════════════════════╪═══════════╡
│ hw_code/test/rev33.txt  │            1             │  Modified │
│ hw_code/test/lcu.v      │                          │   Added   │
│ hw_code/test/newline.v  │                          │     3     │
│ hw_code/test/subsys.txt │                          │     1     │
│ hw_code/test/test.v     │            1             │     2     │
└─────────────────────────┴──────────────────────────┴───────────┘

The above 'pi ip diff' output for the padring IP shows files that have a different state in the padring@9 release (first column) versus the workspace (second 'Workspace' column). In particular it shows that the 'rev33.txt' file was DM revision 1 in the padring@9 release and is currently in a modified state, meaning it has local changes but hasn't yet been checked back into the DM (Perforce in this case). 'lcu.v' wasn't part of the padring@9 release and is currently in an 'Added' state, as it is added to the DM but it hasn't gone through its initial check yet. 'newline.v' and 'subsys.txt' are both checked in at different versions, but weren't part of the padring@9 release. The 'test.v' file was DM file version 1 in the padring@9 release but is currently at DM version 2 in the workspace.

All of these modifications were created either directly by modifying the files in this IP, or by applications the user has run that have modified the files. Helix IPLM is used in this example to report on the workspace state. Resolution of the Modified and Added state (or else ignore them) is required before making a new release of the padring IP.

Workspace State
> pi ip diff padring
tutorial.padring@9.TRUNK on the server and tutorial.padring@9.TRUNK in the Workspace differ.
┌─────────────────────────┬──────────────────────────┬───────────┐
│ FILES                   │ tutorial.padring@9.TRUNK │ Workspace │
╞═════════════════════════╪══════════════════════════╪═══════════╡
│ hw_code/test/rev33.txt  │            1             │     2     │
│ hw_code/test/lcu.v      │                          │     1     │
│ hw_code/test/newline.v  │                          │     3     │
│ hw_code/test/subsys.txt │                          │     1     │
│ hw_code/test/test.v     │            1             │     2     │
└─────────────────────────┴──────────────────────────┴───────────┘

Resource modifications can also be shown with 'pi ip diff'

pi ip diff Resource Modifications
> pi ip diff tutorial
tutorial.tutorial@6.TRUNK on the server and tutorial.tutorial@6.TRUNK in the Workspace differ.
┌──────────────────┬───────────────────────────┬───┬───────────┐
│ RESOURCES        │ tutorial.tutorial@6.TRUNK │   │ Workspace │
╞══════════════════╪═══════════════════════════╪═══╪═══════════╡
│ tutorial.CADenv  │      GOLD.TRUNK [@1]      │   │  1.TRUNK  │
│ tutorial.padring │          1.TRUNK          │ → │  9.TRUNK  │
└──────────────────┴───────────────────────────┴───┴───────────┘

In this case we see that the tutorial.tutorial (the top level IPV used to load the workspace) is in a modified state because it has two resources that have been moved from the versions expected by tutorial.tutorial@6.TRUNK. The CADenv IPV has been moved from the moving 'GOLD' alias to the fixed release 1.TRUNK. The padring IPV (whose own file level modifications we inspected above) is loaded in the workspace at version 9.TRUNK instead of the expected 1.TRUNK. Both of these modifications were accomplished by running 'pi up' the CADenv and padring respectively to update those resources to their new versions in the workspace.

Creating a new Release from a Modified Workspace

IPs in a modified workspace can be released one at a time if desired. To make a new release from a given IP it must show that it is modified in the workspace, indicating either its resources or contents have been modified from the latest release. It is also necessary to update IPVs to the latest version available in order to be sure of capturing other users changes that may be in more recent versions of the IP. Releasing IPs one at a time can be laborious if there are many changes in the workspace, so Helix IPLM provides a hierarchical release mechanism which calculates the necessary releases needed to capture all the changes in the workspace from the lowest levels in the hierarchy up to a new top version.

pi release --hier Command
> pi release --hier -m "new tutorial release"INFO:Waiting for 9 PiCache jobs ...
INFO:Waiting for 4 PiCache jobs ...
INFO:Waiting for 2 PiCache jobs ...
INFO:Waiting for 1 PiCache job ...
Successfully created 'tutorial.interface@3.TRUNK'.
Successfully created 'tutorial.rxtx@3.TRUNK'.
Successfully created 'tutorial.clk_mux@3.TRUNK'.
Successfully created 'tutorial.flash_if@3.TRUNK'.
Successfully created 'tutorial.flash@3.TRUNK'.
Successfully created 'tutorial.bist_sram@3.TRUNK'.
Successfully created 'tutorial.cpu@4.TRUNK'.
Successfully created 'tutorial.t1@3.TRUNK'.
Successfully created 'tutorial.dbuf@3.TRUNK'.
Successfully created 'tutorial.events_if@3.TRUNK'.
Successfully created 'tutorial.t0@3.TRUNK'.
Successfully created 'tutorial.padring@10.TRUNK'.
Successfully created 'tutorial.timers@3.TRUNK'.
Successfully created 'tutorial.rx_channel@3.TRUNK'.
Successfully created 'tutorial.sys_bus@3.TRUNK'.
Successfully created 'tutorial.digital_top@3.TRUNK'.
Successfully created 'tutorial.tutorial@7.TRUNK'.

After running the 'pi release --hier' command all changes in the workspace are captured and combined efficiently into a new top level release, tutorial.tutorial@7.TRUNK. A 'pi ws st' on the workspace shows no modifications:

pi ws st Command
> pi ws st
Workspace ID : 7133a773-fd21-491f-8446-b8f6d60f7882
Directory    : /tmp/workspaces/sub2/ws1
IP           : tutorial.tutorial@7.TRUNK
Workspace is up-to-date.

All of the workspace modifications have been captured by the new tutorial.tutorial@7.TRUNK release.