Viewing workspace modifications
Helix IPLM can compare the state of a workspace against the hierarchy of any version of the top level IPV that was used to load the workspace. File modifications are made using DM level operations, and both file and resource modifications are introduced via updates brought in by Helix IPLM in preparing the workspace data for the next release. As these workspace modifications accrue it becomes more and more valuable to be able to compare the current state of the workspace to fixed server side releases, in order to fully understand all the changes that are being made.
This section shows the various ways you can view workspace modifications in the Helix IPLM platform.
Workspace status overview
There are several methods available to understand the state of a workspace, and different capabilities are available depending on whether the user has direct access to the workspace in addition to access to the Helix IPLM server.
Server-side workspace tracking
Helix IPLM keeps a record of every workspace that it creates, this record is updated when the workspace is updated, and can be used to see the up to date IPV level contents of the workspace along with detailed information on when each IPV in the workspace was updated, the owner of the workspace, etc. The 'pi ws list' command is used to list the server side workspace information. See the Listing Workspaces section for details. Workspaces also support search via the query language, see Querying Workspaces.
IPV compare (diff)
The 'pi ip diff' command can either perform a detailed comparison of the differences between an IPV in a workspace and a release of an IPV on the server, or the differences between two server side releases of a given IPV. The diff will compare IPV resource and metadata differences, as well as file version level differences between the two IPVs or between a workspace and an IPV.
Note: The file level diff reports the different versions between the two compared objects, but not the file content differences. For file content differences use the applicable DM level command.
Information on using pi ip diff to compare IPVs against each other and against workspaces is detailed in the Comparing IPs in the System section.
Workspace status
The pi workspace status command is used to check the current status of one or more IPVs in the workspace. The table output of 'pi workspace status' can be configured, (see the Client Configuration section) but by default it shows a summary of each requested IP's status in the workspace. For additional details on modified IPVs, the pi ip diff command can be used.
Note: For P4
Command line
Helix IPLM actively tracks the status of all the IPs loaded into a workspace. To quickly find out the status of each IP in a workspace, use the 'pi ws st' command:
pi ws st command
> pi ws st -v Workspace ID : d6c5ab5a-bfbe-44df-9da6-c84c48f14974 Directory : /tmp/workspaces/ws3 IP : tutorial.tutorial@6.TRUNK Default "pi up" Target : tutorial.tutorial@8.TRUNK Resources : ┌────────────────────────────┬───────────────────┬───────────────────┬───────────┬───────────────────────┬───────────┬──────────────────────────┐ │ NAME │ EXPECTED VERSION │ LOCAL VERSION │ WS STATUS │ SERVER STATUS │ MODE │ CONFLICTS │ ╞════════════════════════════╪═══════════════════╪═══════════════════╪═══════════╪═══════════════════════╪═══════════╪══════════════════════════╡ │ tutorial.tutorial │ 6.TRUNK │ 6.TRUNK │ Modified │ New version available │ Refer │ │ │ ARM.cortex │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ │ ARM.cortex2 │ │ 8.TRUNK │ OK │ OK │ Refer │ │ │ certification.ibm_rqm │ 0.RQM_6_0_5 │ 0.RQM_6_0_5 │ OK │ OK │ Refer │ │ │ tutorial.CADenv │ GOLD.TRUNK [@3] │ GOLD.TRUNK [@1] │ OK │ New @GOLD available │ Refer │ │ │ tutorial.MS90G │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ │ tutorial.acells_tsmc18 │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ │ tutorial.adc │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Refer │ │ │ tutorial.aes512 │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ │ tutorial.analog_top │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Refer │ │ │ tutorial.bist_sram │ 1.TRUNK │ 1.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.clk_mux │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ │ tutorial.clkgen │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Refer │ │ │ tutorial.cpu │ LATEST.TRUNK [@2] │ LATEST.TRUNK [@2] │ OK │ OK │ Refer │ │ │ tutorial.dac │ HEAD.TRUNK [@0] │ HEAD.TRUNK [@0] │ OK │ OK │ Container │ │ │ tutorial.dbuf │ 1.TRUNK │ 1.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.digital_top │ 2.TRUNK │ 2.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.events_if │ 1.TRUNK │ 1.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.flash │ 1.TRUNK │ 1.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.flash_if │ 1.TRUNK │ 1.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.fusa │ LATEST.TRUNK [@0] │ LATEST.TRUNK [@0] │ OK │ OK │ Container │ │ │ tutorial.gen_dig │ LATEST.TRUNK [@3] │ LATEST.TRUNK [@3] │ OK │ OK │ Refer │ tutorial.gen_dig@1.TRUNK │ │ tutorial.interface │ 1.TRUNK │ 1.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.intf_ana │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Refer │ │ │ tutorial.io5v │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ │ tutorial.io_tsmc18 │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ │ tutorial.laysc_tsmc18 │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ │ tutorial.padring │ 1.TRUNK │ 6.TRUNK │ Modified │ OK │ Local │ │ │ tutorial.proj_tech │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ │ tutorial.pwr_mgmt_ana │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Refer │ │ │ tutorial.rx_channel │ 1.TRUNK │ 1.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.rxtx │ 1.TRUNK │ 1.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.stup_ana │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Refer │ │ │ tutorial.sys_bus │ 1.TRUNK │ 1.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.t0 │ 1.TRUNK │ 1.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.t1 │ 1.TRUNK │ 1.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.timers │ 1.TRUNK │ 1.TRUNK │ Modified │ OK │ Refer │ │ │ tutorial.tool_cert │ LATEST.TRUNK [@0] │ LATEST.TRUNK [@0] │ OK │ OK │ Container │ │ │ tutorial.trc │ HEAD.TRUNK [@2] │ HEAD.TRUNK [@2] │ OK │ OK │ Refer │ │ │ tutorial.tutorial_IEC61508 │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ │ tutorial.tutorial_ISO26262 │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ │ tutorial.verif_config │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ └────────────────────────────┴───────────────────┴───────────────────┴───────────┴───────────────────────┴───────────┴──────────────────────────┘
Status summary fields
The following status summary fields are displayed at the top of every workspace status report.
| Status summary field | Description |
|---|---|
| Workspace ID | The IPLM database UUID for the workspace. This UUID can be used to uniquely identify the workspace, and it can be used as an input to the ‘pi ws delete’ command. |
| Directory | The filesystem location of the workspace. Workspaces can be moved with the ‘pi ws move’ command. |
| IP | The top level IPV currently loaded in the workspace. |
| Default “pi up” target | If no target is supplied to the “pi up” command this is the IPV that IPLM will update the top level IPV in the workspace to. |
| Resources | A summary table showing the state of the resources in the workspace. See following sections for details. |
Resources report overview
This command can list one or more of the IPs in the workspace, their current release and, in the 'WS STATUS' column, either that an IPV matches the server (Expected Version) state, displays with an 'OK' status, or that it does not match the server state, in which case it is shown with a 'Modified' status. 'OK' IPs are those that are exactly on the 'EXPECTED VERSION' release, with no file or resource modifications, 'Modified' IPs are those that have some file or resource modifications versus their release. Detailed information on each column is shown below.
EXPECTED VERSION column
The EXPECTED VERSION shows the IP Version in the pristine server side release hierarchy of the top level IPV loaded into the workspace. This column is the reference against which changes in the workspace can be evaluated. The EXPECTED_VERSION column only changes as a result of:
- Loading a top level IPV into a new workspace via 'pi ip load'
- Running a 'pi update' on the top level IP in an existing workspace
- Making a 'pi release' of the top level IP in the workspace
- An alias referenced by the top level IP Hierarchy is applied to a later version of an IP than what is currently in the workspace. See Hierarchy and Aliases.
In the example above the EXPECTED VERSION column is populated by the resource versions that were loaded (or updated) into the workspace by tutorial.tutorial@6.TRUNK. The EXPECTED VERSION column contains identical IPVs to the IP Hierarchy of tutorial.tutorial@6.TRUNK, with the exception of the case where there are IP version conflicts in the hierarchy. In this case tutorial.tutorial@6.TRUNK has both gen_dig@1 and gen_dig@3 are in different branches of its hierarchy. These conflicts are resolved when the IP Hierarchy is loaded in the workspace, see the Workspace Configuration section for details on conflict resolution.
If new versions of the top level IP (tutorial.tutorial@7.TRUNK or later in the above case) become available on the Helix IPLM server, this will NOT be indicated in the EXPECTED VERSION column, instead the SERVER STATUS column will show there is a new version available with the message 'New version available'. The EXPECTED VERSION column always reflects the IP Versions last loaded or updated in the workspace based on the top level IP's resource hierarchy.
EXPECTED VERSION and moving aliases
If the top level IP Hierarchy has IPVs that are referenced via Aliases (ie tutorial.CADenv@GOLD.TRUNK above) these are resolved at the time of workspace load or update to the latest version of the IP Line that has that alias applied.
If subsequently the same alias is applied to an even later version of an IP on the Line the latest version with that Alias will have changed, and the EXPECTED VERSION column entry for that IP will change to reflect that. In the case above the CADenv@GOLD alias resolved to CADenv@GOLD.TRUNK [@1] when the workspace was first loaded, but since the GOLD alias was later applied to CADenv@3, the EXPECTED VERSION now shows CADenv@GOLD [ @3 ]. Additionally the SERVER STATUS column indicates a new @GOLD IPV is available. A pi update on CADenv would bring in the later @GOLD version. See Updating the workspace for more details.
EXPECTED VERSION possible values
|
Value
|
Comments
|
|---|---|
| IPV | The IPV derived from the conflict resolved IP Hierarchy of the top level IPV loaded into the workspace. |
|
Blank |
The IPV was brought into the workspace as a result of directly updating a resource IPV in the workspace. The new version of the resource IP had a new resource of its own, which is not in the hierarchy of the top level IPV originally loaded into the workspace. |
LOCAL VERSION column
The LOCAL VERSION of each IPV shows the current IP Version in the workspace. The LOCAL VERSION can change either directly or indirectly (via resource relationships) as a result of a 'pi update' on a resource IP, or as a result of a 'pi update' on the top level IP.
The LOCAL VERSION column can be compared to the reference EXPECTED VERSION column to see IPs that have been moved from their expected version via a 'pi update' or to see IP@ALIAS entries that may have newer aliased versions available. See tutorial.CADenv above.
LOCAL VERSION possible values
|
Status
|
Comments
|
|---|---|
| IPV | The IPV currently in the workspace. |
| Blank | The IPV was removed from the workspace as a result of directly updating a resource IPV in the workspace. The new version of the resource IP was missing the resource in its updated hierarchy. |
WS STATUS column
The WS STATUS column gives information about the status of the given IPV in the workspace. This column reports whether the IPV has been modified (in terms of either resources or files ) versus its server side release definition, whether there is a DM error in accessing the IP, whether the IPV is Missing or Invalid on disk, or whether an update is needed to an @HEAD IP.
WS STATUS possible values
|
Status
|
Comments
|
|---|---|
| OK | No Modifications. IPV on disk matches its server side release. File list on disk matches IPV release contents (no changed versions or modified files), and Resources of the IPV are a the same versions in the workspace as in the server side IPV Hierarchy. |
| Missing | IPV's top level directory is not present in the workspace. It may have been manually deleted or moved. If the IP is in refer mode the link to the cache cannot be accessed for some reason (permissions issues in most cases) |
| Modified | One or more of the IP's files have been modified, either moved to a different version in the DM system, locally modified (edited) and/or one or more of the IPV's resources are not at the version specified in the EXPECTED VERSION column. |
| Invalid Target | In Refer mode, specifies the IPV's link is pointing to something other than the IPV in the cache. If the IP is a Filesystem type, this indicates the link is pointing to the wrong location in the file system (vs. the path in the repo_path of the IP). |
| DM Error | The Helix IPLM client can't access the IPV's DM (for instance P4 settings are wrong or P4 Server is down in the case of a P4 IP) |
| Update Needed | For IPs loaded @HEAD the Update Needed status indicates new file versions are available in the DM system. These can be populated with a 'pi up IP@HEAD' |
| Update Needed, Modified | A combination of the 'Updated Needed' and 'Modified' states. Applies only to @HEAD IPs, indicates new file versions are available, and there local files open for edit/delete or Resources of the @HEAD IP are changed from the EXPECTED VERSION |
| Removed | For all IPVs, this specifies that the IPV has been removed from the workspace using workspace edit. An IPV that is removed as a result of a workspace edit should be displayed in the workspace status message. An IPV is considered 'removed' if it was deleted from a workspace IP's resource list with workspace edit and no other workspace IPV has it as a resource. |
| Added | For all IPVs, this specifies that the IPV has been added to the workspace using workspace edit. Any IPV that is added as a result of a workspace edit should be displayed in the workspace status message. An IPV is considered 'added' if it is not a resource of an unmodified IPV in the workspace. |
SERVER STATUS column
The SERVER STATUS column reports status on the server versus what is currently in the workspace.
SERVER STATUS possible values
|
Status
|
Comments
|
|---|---|
| OK |
Default status, implies:
|
| New @ALIAS Available |
|
| New Resources Available | For the Top IPV in the workspace, indicates one or more IPVs in the tree are referenced by ALIAS, and new IPV releases are available for those ALIASes |
| New Version Available | For the Top IPV in the workspace, indicates there is a new IPV release available on the server. |
MODE column
Indicates the IP Mode relative to the IP Cache.
Tip: Container IPs have no mode. This is because they do not contain any files, so there is no concept of local/refer in this case.
MODE possible values
|
Status
|
Comments
|
|---|---|
| Local |
IP is populated locally in the workspace. If permissions permit the IP can be modified at the file level. 'pi ip refer' command can be used to move it to IPLM Cache. |
| Refer | IP is populated in refer mode, it is located in the IPLM Cache directory in read only mode. 'pi ip local' command can be used to move it |
| Container | IP is a container type, has no DM files associated with it, and isn't present on disk |
CONFLICTS column
The CONFLICTS column shows which IPVs have conflicts versus the top level server side IP Hierarchy. An IP Hierarchy can have multiple versions of the same IP on the server, however when it is loaded into the workspace these conflicts must be resolved. The CONFLICTS column indicates which IPVs were not chosen in the conflict resolution process.
Checking status on PiCLI
Details on the 'pi workspace status' command are shown below.
> pi ws st -h
Usage: pi workspace status [-h] [--wsdir WSDIR] [--format {json,skill,table}]
[--ignore-files] [--verbose] [--model MODEL]
[identifier [identifier ...]]
Description: Show the status of a Workspace.
Positional arguments:
identifier Only show information for the specified IPs.
Optional arguments:
--format {json,skill,table}, -f {json,skill,table}
Specify output format.
--ignore-files Only compare resources versions.
--model MODEL Use the specified report model (table report only)
--verbose, -v List all IP in the Workspace and their status.
--wsdir WSDIR, -ws WSDIR
The Workspace directory. If not specified, the current
directory should be a Workspace directory.
-h, --help Show this help message and exit
Detailed information on the arguments to pi workspace status:
| Command Option | Description |
|---|---|
| --format json | Provide a json string showing the workspace status |
| --format skill | Provide a SKILL (Cadence scripting language) output string showing the workspace status |
| --format table | Display the default table output format showing workspace status |
| --ignore-files | Won't check file status. This argument will speed up the command significantly for larger IPVs as it removes the need to access the filesystem. |
| --model | Show a custom --format table output display. See Client Configuration for details. |
| --verbose | Show all IPV results. By default if an IPV has an OK status it will be trimmed from the output. |
| --wsdir | Use a specific workspace path for the workspace status. Else workspace status is run versus the current workspace |
Workspace status customization options
It is possible to customize the default table output display of 'pi ws st'. Details on this are shown on the Client Configuration page. The following non-default fields are available.
| Optional Display Field | Description |
|---|---|
| last_updater | The last user to update the IPV in the workspace |
| last_update_timestamp | The timestamp of the last update to the IPV in the workspace |
| dm_type |
The Data Management type of the Resource |
| path |
The relative location of the Resource in the Workspace |
| latest |
The latest version of the resource on the Server |
| latest_message |
The release message of the latest release on the Server |
| current_message |
The release message of the current Resource in the workspace |
| dm_type |
The Data Management type of the Resource |
| path |
The relative location of the Resource in the Workspace |
| latest |
The latest version of the resource on the Server |
|
latest_message |
The release message of the latest release on the Server |
| current_message |
The release message of the current Resource in the workspace |
JSON output fields
The following additional fields are available via the 'pi ws st --format json' output display (beyond the standard table fields).
Note: For scripting it is advisable to use the Helix IPLM API rather than the --json format option from PiCLI.
| JSON output Field | Description |
|---|---|
| CurrentMsg | The release message of the IPV in the workspace |
| Last Update Timestamp | The timestamp of the last update to the IPV in the workspace |
| Last Updater | The last user to update the IPV in the workspace |
| Latest Msg | The release message of the latest release of the IP (not necessarily the version in the workspace) |
| Version->latest | The latest release of the IP (not necessarily the version in the workspace |
| Workspace ID | The UUID of the workspace (Helix IPLM tracks all objects by UUID rather than name) |
