Traceable workspaces
Helix IPLM Hierarchies are used to build and update workspaces. Once populated by Helix IPLM, workspaces can be modified directly using existing flows and tools, and using the appropriate DM system for each IP in the workspace. Helix IPLM tracks changes in the workspace, as well as what IPs are populated in each workspace.
Building workspaces
Helix IPLM workspaces are constructed based on a released IP Hierarchy. Any IP can be used to build a workspace, just as any IP can be included in an IP Hierarchy. This flexibility means that it is possible to work in different contexts within Helix IPLM. The owner of a subsystem can build workspaces from their section of a design hierarchy and work in their context. One or more projects can then integrate releases from the subproject as qualified releases become available.
Workspace configuration
Workspaces can be configured using Project Property settings on the top level IP in the workspace, and by customizing the piclient.conf file. Project Properties configure how Helix IPLM constructs a workspace:
|
Project Property Types |
Definition |
|---|---|
|
path |
Sets the relative location (path) of IPs in the workspace |
|
mode |
Sets whether the IP is populated in PiCache or in the local workspace |
|
resolve |
Sets Manual resolution of conflicts in the IP Hierarchy |
|
unix-group |
The unix group to apply to the IP when it is loaded disk |
File links between sections of the workspace, or to locations external to the workspace can also be configured automatically. If more involved workspace customization is required Helix IPLM also provides 'post load' and 'post update' client side hooks that can be used run scripts after workspaces are initially loaded as well as when they are updated to bring in new data.
Between these options automatic workspace configuration to support any specific flow is enabled.
Workspace construction
Central configuration of the workspace in Helix IPLM ensures consistent deployment of each user and automation workspace, and enables consistency within workflows. Since they are based on a tracked release the contents of each workspace are traceable from the central server.
The 'pi ip load <IPNAME>' command is used to build a workspace:
> pi ip load tutorial.tutorial ws1 Loading IPV 'tutorial.tutorial@10.TRUNK' into Workspace '/tmp/workspaces/ws1'. INFO:Waiting for 7 PiCache jobs ... INFO:Waiting for 3 PiCache jobs ... INFO:Waiting for 1 PiCache job ... ┌────────────────────────────┬───────────────────┬───────────┬──────────────────────────┐ │ NAME │ VERSION │ MODE │ RELATIVE PATH │ ╞════════════════════════════╪═══════════════════╪═══════════╪══════════════════════════╡ │ tutorial.tutorial │ 10.TRUNK │ Refer │ blocks/tutorial │ │ ARM.cortex │ 1.TRUNK │ Refer │ blocks/cortex │ │ certification.ibm_rqm │ 0.RQM_6_0_5 │ Refer │ blocks/ibm_rqm │ │ tutorial.CADenv │ GOLD.TRUNK [@1] │ Refer │ blocks/CADenv │ │ tutorial.MS90G │ 1.TRUNK │ Refer │ blocks/MS90G │ │ tutorial.acells_tsmc18 │ 1.TRUNK │ Refer │ blocks/acells_tsmc18 │ │ tutorial.adc │ HEAD.TRUNK [@1] │ Refer │ blocks/adc │ │ tutorial.aes512 │ 1.TRUNK │ Refer │ blocks/aes512 │ │ tutorial.analog_top │ HEAD.TRUNK [@1] │ Refer │ blocks/analog_top │ │ tutorial.bist_sram │ 2.TRUNK │ Refer │ blocks/bist_sram │ │ tutorial.clk_mux │ 2.TRUNK │ Refer │ blocks/clk_mux │ │ tutorial.clkgen │ HEAD.TRUNK [@1] │ Refer │ blocks/clkgen │ │ tutorial.cpu │ LATEST.TRUNK [@3] │ Refer │ blocks/cpu │ │ tutorial.dac │ HEAD.TRUNK [@0] │ Container │ │ │ tutorial.dbuf │ 2.TRUNK │ Refer │ blocks/dbuf │ │ tutorial.digital_top │ 3.TRUNK │ Refer │ blocks/digital_top │ │ tutorial.dma │ 1.TRUNK │ Local │ blocks/dma │ │ tutorial.events_if │ 2.TRUNK │ Refer │ blocks/events_if │ │ tutorial.flash │ 2.TRUNK │ Refer │ blocks/flash │ │ tutorial.flash_if │ 2.TRUNK │ Refer │ blocks/flash_if │ │ tutorial.fusa │ LATEST.TRUNK [@0] │ Container │ │ │ tutorial.gen_dig │ 2.TRUNK │ Refer │ blocks/gen_dig │ │ tutorial.interface │ 4.TRUNK │ Refer │ blocks/interface │ │ tutorial.intf_ana │ HEAD.TRUNK [@1] │ Refer │ blocks/intf_ana │ │ tutorial.io5v │ 1.TRUNK │ Refer │ blocks/io5v │ │ tutorial.io_tsmc18 │ 1.TRUNK │ Refer │ blocks/io_tsmc18 │ │ tutorial.laysc_tsmc18 │ 1.TRUNK │ Refer │ blocks/laysc_tsmc18 │ │ tutorial.padring │ 7.TRUNK │ Refer │ blocks/padring │ │ tutorial.proj_tech │ 1.TRUNK │ Refer │ blocks/proj_tech │ │ tutorial.pwr_mgmt_ana │ HEAD.TRUNK [@1] │ Refer │ blocks/pwr_mgmt_ana │ │ tutorial.rx_channel │ 2.TRUNK │ Refer │ blocks/rx_channel │ │ tutorial.rxtx │ 2.TRUNK │ Refer │ blocks/rxtx │ │ tutorial.stup_ana │ HEAD.TRUNK [@1] │ Refer │ blocks/stup_ana │ │ tutorial.sys_bus │ 2.TRUNK │ Refer │ blocks/sys_bus │ │ tutorial.t0 │ 2.TRUNK │ Refer │ blocks/t0 │ │ tutorial.t1 │ 4.TRUNK │ Refer │ blocks/t1 │ │ tutorial.timers │ 2.TRUNK │ Refer │ blocks/timers │ │ tutorial.tool_cert │ LATEST.TRUNK [@0] │ Container │ │ │ tutorial.trc │ HEAD.TRUNK [@1] │ Refer │ blocks/trc │ │ tutorial.tutorial_IEC61508 │ 1.TRUNK │ Refer │ blocks/tutorial_IEC61508 │ │ tutorial.tutorial_ISO26262 │ 1.TRUNK │ Refer │ blocks/tutorial_ISO26262 │ │ tutorial.verif_config │ 1.TRUNK │ Refer │ blocks/verif_config │ └────────────────────────────┴───────────────────┴───────────┴──────────────────────────┘
Helix IPLM reports the IPs loaded into the workspace, the version of the IP loaded, whether the IP was loaded in local mode or in the PiCache ( 'Refer Mode' ), and the path of the IP in the workspace. Once constructed, the Helix IPLM workspace consists of all the IP objects and their design files populated at the correct versions matching the release used to load the workspace. At this point, it is possible to move file or IP Versions to new versions as desired using the 'pi up' or dm commands (ie 'p4 sync'). Releases can be made either one IP at a time or hierarchically via 'pi release'.
As these changes are made, either locally or via updates from other users, Helix IPLM enables quick comparison of the current workspace state of each IP and its files against the server side release used to load the workspace. 'pi ws st' shows the status of each modified IP in the workspace, and 'pi ip diff' shows the specific differences down to the file level.
Once changes have been made and verified to the necessary level, a new Helix IPLM release can be generated from the workspace and published back to the Helix IPLM server for use by other users either to update their existing workspaces, or to build new workspaces from it.
Workspace Snapshots
The state of modified workspaces can be captured without making a full release with a workspace snapshot. Snapshots capture the state of any modified submitted files or resources and publish them to the Helix IPLM server, where they can be used to build new workspaces or diffed vs other snapshots and IP releases. Snapshots are a good way to publish hotfixes between IP providers and consumers, and allows for support personnel to check on other users workspaces, by capturing the state on the server and allowing these workspace states to be recreated or updated at any time.
Helix IPLM workspaces are created using native DM commands, so the populated workspace is manipulated directly through these DM systems with no interference from Helix IPLM as the platform is only called when needed. Users can continue to use their preferred flows, DM systems, and design applications.
Tracking Workspaces and their Contents
Helix IPLM tracks all the workspaces in the system, so it is possible to view a variety of information on each workspace, including the owner, last updated time, and what IPVs are currently consumed by the workspace. A simple table mode summary of workspaces in the system is shown below:
> pi ws list -a --model updated ┌─────────────────────────────┬────────────┬───────────────────────────────┬─────────────────────────────────────────────────────┐ │ TOP IPV │ UPDATED BY │ UPDATED ON │ PATH │ ╞═════════════════════════════╪════════════╪═══════════════════════════════╪═════════════════════════════════════════════════════╡ │ tutorial.analog_top@1.TRUNK │ admin │ 2020-01-27 07:22:54 -0800 PST │ /tmp/workspaces/release/tutorial/analog_top/TRUNK/1 │ │ tutorial.padring@5.TRUNK │ admin │ 2020-03-12 12:23:35 -0700 PDT │ /tmp/rb5 │ │ tutorial.timers@1.TRUNK │ admin │ 2020-02-06 09:50:41 -0800 PST │ /tmp/ws1 │ │ tutorial.tutorial@6.TRUNK │ admin │ 2020-03-10 06:17:40 -0700 PDT │ /tmp/ws_demo │ │ tutorial.tutorial@6.TRUNK │ alex │ 2020-03-18 05:47:01 -0700 PDT │ /tmp/my_ws │ │ tutorial.tutorial@6.TRUNK │ george │ 2020-01-27 07:30:49 -0800 PST │ /tmp/workspaces/release/tutorial/tutorial/TRUNK/6 │ │ tutorial.tutorial@6.TRUNK │ admin │ 2020-02-04 00:19:23 -0800 PST │ /tmp/ws1 │ │ tutorial.tutorial@6.TRUNK │ admin │ 2020-03-16 00:49:25 -0700 PDT │ /tmp/demo_ws │ │ tutorial.tutorial@6.TRUNK │ sara │ 2020-03-10 05:24:43 -0700 PDT │ /tmp/ws_1 │ │ tutorial.tutorial@6.TRUNK │ admin │ 2020-01-27 07:26:24 -0800 PST │ /var/tmp/pidemos/ipx_mmreg/ws │ │ tutorial.tutorial@5.TRUNK │ jake │ 2020-01-27 07:28:48 -0800 PST │ /tmp/workspaces/release/tutorial/tutorial/TRUNK/5 │ │ tutorial.tutorial@4.TRUNK │ admin │ 2020-01-27 07:26:47 -0800 PST │ /tmp/workspaces/release/tutorial/tutorial/TRUNK/4 │ │ tutorial.tutorial@3.TRUNK │ admin │ 2020-01-27 07:24:35 -0800 PST │ /tmp/workspaces/release/tutorial/tutorial/TRUNK/3 │ │ tutorial.tutorial@2.TRUNK │ admin │ 2020-01-27 07:22:09 -0800 PST │ /tmp/workspaces/release/tutorial/tutorial/TRUNK/2 │ │ tutorial.tutorial@1.TRUNK │ admin │ 2020-01-27 07:20:15 -0800 PST │ /tmp/workspaces/release/tutorial/tutorial/TRUNK/1 │ └─────────────────────────────┴────────────┴───────────────────────────────┴─────────────────────────────────────────────────────┘ Found 15 matching object(s).
If more details are required, the --verbose command line option can be used:
> pi ws list -v
Workspace /tmp/workspaces/release/tutorial/tutorial/TRUNK/3:
Top IPV - tutorial.tutorial@3.TRUNK
FQDN - demo2.dev.methodics-da.com
Path - /tmp/workspaces/release/tutorial/tutorial/TRUNK/3
Created On - 2020-01-27 07:24:35 -0800 PST by admin
Resources - tutorial.CADenv@GOLD.TRUNK [@1]
tutorial.MS90G@1.TRUNK
tutorial.acells_tsmc18@1.TRUNK
tutorial.adc@HEAD.TRUNK [@1]
tutorial.aes512@1.TRUNK
tutorial.analog_top@HEAD.TRUNK [@1]
tutorial.bist_sram@1.TRUNK
tutorial.clk_mux@1.TRUNK
tutorial.clkgen@HEAD.TRUNK [@1]
tutorial.cpu@LATEST.TRUNK [@2]
tutorial.dac@HEAD.TRUNK [@0]
tutorial.dbuf@1.TRUNK
tutorial.digital_top@1.TRUNK
tutorial.events_if@1.TRUNK
tutorial.flash@1.TRUNK
tutorial.flash_if@1.TRUNK
tutorial.gen_dig@LATEST.TRUNK [@2]
tutorial.interface@1.TRUNK
tutorial.intf_ana@HEAD.TRUNK [@1]
tutorial.io5v@1.TRUNK
tutorial.io_tsmc18@1.TRUNK
tutorial.laysc_tsmc18@1.TRUNK
tutorial.padring@1.TRUNK
tutorial.proj_tech@1.TRUNK
tutorial.pwr_mgmt_ana@HEAD.TRUNK [@1]
tutorial.rx_channel@1.TRUNK
tutorial.rxtx@1.TRUNK
tutorial.stup_ana@HEAD.TRUNK [@1]
tutorial.sys_bus@1.TRUNK
tutorial.t0@1.TRUNK
tutorial.t1@1.TRUNK
tutorial.timers@1.TRUNK
tutorial.trc@HEAD.TRUNK [@1]
tutorial.verif_config@1.TRUNK
Workspace ID - f0e8bdcf-babe-4fb7-acdb-91abb5c72693
Workspace Manager - PWM
P4 Client - ws:root:tutorial.tutorial:f0e8bdcf
Similar output can be listed in JSON format using the 'pi ws list --format json' option. Note that for scripting or developing applications that leverage Helix IPLM data the Helix IPLM Public API should be used rather than PiCLI --json output.
Searching Workspaces by their IP contents
It is often important to understand which IPs or IP Versions users have in their local workspaces, this information is readily discoverable using the 'pi ws list --contains' command:
> pi ws list --contains tutorial.padring ┌───────────────────────────┬────────────┬───────────────────────────────┬───────────────────────────────────────────────────┐ │ TOP IPV │ CREATED BY │ CREATED ON │ PATH │ ╞═══════════════════════════╪════════════╪═══════════════════════════════╪═══════════════════════════════════════════════════╡ │ tutorial.padring@5.TRUNK │ admin │ 2020-03-12 12:23:35 -0700 PDT │ /tmp/rb5 │ │ tutorial.tutorial@6.TRUNK │ admin │ 2020-03-18 05:47:01 -0700 PDT │ /tmp/my_ws │ │ tutorial.tutorial@6.TRUNK │ admin │ 2020-03-16 00:49:25 -0700 PDT │ /tmp/demo_ws │ │ tutorial.tutorial@6.TRUNK │ admin │ 2020-03-10 06:17:40 -0700 PDT │ /tmp/ws_demo │ │ tutorial.tutorial@6.TRUNK │ admin │ 2020-03-10 05:24:43 -0700 PDT │ /tmp/ws_1 │ │ tutorial.tutorial@6.TRUNK │ admin │ 2020-02-04 00:19:23 -0800 PST │ /tmp/ws1 │ │ tutorial.tutorial@6.TRUNK │ admin │ 2020-01-27 07:26:24 -0800 PST │ /var/tmp/pidemos/ipx_mmreg/ws │ │ tutorial.tutorial@5.TRUNK │ admin │ 2020-01-27 07:28:48 -0800 PST │ /tmp/workspaces/release/tutorial/tutorial/TRUNK/5 │ │ tutorial.tutorial@4.TRUNK │ admin │ 2020-01-27 07:26:47 -0800 PST │ /tmp/workspaces/release/tutorial/tutorial/TRUNK/4 │ │ tutorial.tutorial@3.TRUNK │ admin │ 2020-01-27 07:24:35 -0800 PST │ /tmp/workspaces/release/tutorial/tutorial/TRUNK/3 │ │ tutorial.tutorial@2.TRUNK │ admin │ 2020-01-27 07:22:09 -0800 PST │ /tmp/workspaces/release/tutorial/tutorial/TRUNK/2 │ │ tutorial.tutorial@1.TRUNK │ admin │ 2020-01-27 07:20:15 -0800 PST │ /tmp/workspaces/release/tutorial/tutorial/TRUNK/1 │ └───────────────────────────┴────────────┴───────────────────────────────┴───────────────────────────────────────────────────┘ Found 12 matching object(s).
As always if even more sophisticated workspace searching is required, the Helix IPLM query language can be used.
