Updating a workspace
The top level IPV in the workspace IP Hierarchy can be updated to new versions, as can individual resource IPVs in the workspace. Helix IPLM makes it easy to find and update new versions into existing workspaces. Workspace changes versus the loaded IPV hierarchy can be displayed when needed.
Workspace updates
As other users make releases into Helix IPLM it becomes necessary to bring those new releases into existing workspaces. Helix IPLM can update a workspace either at the level of the top level IPV loaded in the workspace, or at a lower level IPV in the overall hierarchy. Updated IPVs may bring in new resources of their own, which will reconfigure the existing workspace beyond the updated IPV itself. Helix IPLM implements 'update modes' which can be used to manage how local changes are retained when updates are initiated.
Finding available updates
Newly updated IPVs that may be of interest based on the current contents of an IP Hierarchy can be discovered via the 'pi ip tree --list-new' command. The command shows any updates available beyond the versions called for in the specified IP Hierarchy. To be shown in the output an IPV must have an alias applied (the newest release will automatically have the @LATEST alias applied by the system). The current version in the IPV hierarchy is displayed, along with any aliased versions that are available for update. The output below shows (in part):
- The current version of ARM.cortex used in the hierarchy is @1, however there is a @5 [GOLD] version and a the [LATEST] @6 version that could be used instead.
- The tutorial.CADenv IP is included @GOLD in the hierarchy, but there is a @3 [LATEST] version that could be used instead.
- The tutorial.padring@7 included in the hierarchy is the latest version available. Normally this version would be pruned from the tree for the --list-new output, but the padring has a couple of resources that have newer versions as well, so it is displayed in this case
pi ip tree --list command
> pi ip tree --list-new tutorial.tutorial@10.TRUNK tutorial.tutorial@10.TRUNK ├─ ARM.cortex@1.TRUNK → @5 [GOLD], @6 [LATEST] ├─ tutorial.CADenv@GOLD.TRUNK [@1] → @3 [LATEST] ├─ tutorial.dma@1.TRUNK → @2 [LATEST] ├─ tutorial.padring@7.TRUNK │ ├─ tutorial.io5v@1.TRUNK → @3 [LATEST] │ └─ tutorial.io_tsmc18@1.TRUNK → @3 [LATEST] └─ tutorial.verif_config@1.TRUNK → @3 [LATEST]
Updating a resource IP
Resource IPVs in the workspace can be updated to new versions and lines within an existing workspace. Note the current state of the workspace can (and often will) be different than the server side IP release hierarchy originally used to load the workspace. If we determine we want to update the ARM.cortex to the latest version we can run 'pi up ARM.cortex@6' or if we don't know what the latest version is just run 'pi up ARM.cortex' leaving off the version number. Helix IPLM interprets this as asking for the latest release, which is what we want in this case. Note that a user could just as easily update to an older version of the same IPV, 'pi up ARM.cortex@3' for instance.
Updating a workspace resource
> pi up ARM.cortex Updating Workspace. For large IP this could take a while. INFO:Waiting for 1 PiCache job ... ┌────────────┬─────────────┬─────────────┬───────┬───────────────┐ │ NAME │ OLD VERSION │ NEW VERSION │ MODE │ PATH │ ╞════════════╪═════════════╪═════════════╪═══════╪═══════════════╡ │ ARM.cortex │ 1.TRUNK │ 6.TRUNK │ Refer │ blocks/cortex │ └────────────┴─────────────┴─────────────┴───────┴───────────────┘
Helix IPLM reports the changes made to the workspace based on the update request, we have moved the ARM.cortex IP from version @1 to version @6. All files (and if it had any) resources of that IPV are now updated to the new version in the workspace. We can use 'pi ws st' and 'pi ip diff' to show the current state of the workspace.
Current workspace state
> pi ws st Workspace ID : f4bdf443-9438-43d0-8f45-87bc7138d675 Directory : /tmp/workspaces/ws1 IP : tutorial.tutorial@10.TRUNK Resources : ┌───────────────────┬──────────────────┬───────────────┬───────────┬───────────────┬───────┐ │ NAME │ EXPECTED VERSION │ LOCAL VERSION │ WS STATUS │ SERVER STATUS │ MODE │ ╞═══════════════════╪══════════════════╪═══════════════╪═══════════╪═══════════════╪═══════╡ │ tutorial.tutorial │ 10.TRUNK │ 10.TRUNK │ Modified │ OK │ Refer │ │ ARM.cortex │ 1.TRUNK │ 6.TRUNK │ OK │ OK │ Refer │ └───────────────────┴──────────────────┴───────────────┴───────────┴───────────────┴───────┘ > pi ip diff tutorial.tutorial tutorial.tutorial@10.TRUNK on the server and tutorial.tutorial@10.TRUNK in the Workspace differ. ┌────────────┬────────────────────────────┬───┬───────────┐ │ RESOURCES │ tutorial.tutorial@10.TRUNK │ │ Workspace │ ╞════════════╪════════════════════════════╪═══╪═══════════╡ │ ARM.cortex │ 1.TRUNK │ → │ 6.TRUNK │ └────────────┴────────────────────────────┴───┴───────────┘
We can see from 'pi ws st' that the ARM.cortex is loaded @6 (local version column) rather than the expected @1 (expected version column) as specified by the tutorial.tutorial@10.TRUNK release. The tutorial.tutorial IP shows as 'Modified' and a 'pi ip diff' on the tutorial confirms that this is because the ARM.cortex is not at the expected version.
The resources and files of a workspace can be moved around as needed via 'pi up' and dm level commands, to try out new configurations, run simulations or verification, or do any other design activity. Once the workspace is in a desired state, a new release can be created from the modified workspace.
Updating the top level IPV
The top level IPV in the workspace serves a special purpose, it is the reference for the expected workspace configuration, supplying the values visible in the 'EXPECTED VERSION' column of the 'pi ws st' output. If we update the top level IPV we are, in addition to any other updates that may bring to the workspace, changing the reference for 'pi ws st'. If we are at tutorial.tutorial@8 for instance, 'pi ws st' might show this:
pi ws st command
> pi ws st Workspace ID : f4bdf443-9438-43d0-8f45-87bc7138d675 Directory : /tmp/workspaces/ws1 IP : tutorial.tutorial@8.TRUNK Resources : ┌───────────────────┬──────────────────┬───────────────┬───────────┬───────────────────────┬───────┐ │ NAME │ EXPECTED VERSION │ LOCAL VERSION │ WS STATUS │ SERVER STATUS │ MODE │ ╞═══════════════════╪══════════════════╪═══════════════╪═══════════╪═══════════════════════╪═══════╡ │ tutorial.tutorial │ 8.TRUNK │ 8.TRUNK │ OK │ New version available │ Local │ └───────────────────┴──────────────────┴───────────────┴───────────┴───────────────────────┴───────┘
We aren't on the latest version of tutorial, so the pi ws st tells us that, but all resources in the workspace are at their expected versions for version tutorial@8, so they aren't displayed by default. If we use the -v option (for verbose) we see the entire workspace contents:
pi ws st -v option
> pi ws st -v Workspace ID : f4bdf443-9438-43d0-8f45-87bc7138d675 Directory : /tmp/workspaces/ws1 IP : tutorial.tutorial@8.TRUNK Resources : ┌────────────────────────────┬───────────────────┬───────────────────┬───────────┬───────────────────────┬───────────┐ │ NAME │ EXPECTED VERSION │ LOCAL VERSION │ WS STATUS │ SERVER STATUS │ MODE │ ╞════════════════════════════╪═══════════════════╪═══════════════════╪═══════════╪═══════════════════════╪═══════════╡ │ tutorial.tutorial │ 8.TRUNK │ 8.TRUNK │ OK │ New version available │ Local │ │ ARM.cortex │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Refer │ │ certification.ibm_rqm │ 0.RQM_6_0_5 │ 0.RQM_6_0_5 │ OK │ OK │ Refer │ │ tutorial.CADenv │ GOLD.TRUNK [@1] │ GOLD.TRUNK [@1] │ OK │ OK │ Local │ │ tutorial.MS90G │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Local │ │ tutorial.acells_tsmc18 │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Local │ │ tutorial.adc │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Local │ │ tutorial.aes512 │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Local │ │ tutorial.analog_top │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Local │ │ tutorial.bist_sram │ 2.TRUNK │ 2.TRUNK │ OK │ OK │ Local │ │ tutorial.clk_mux │ 2.TRUNK │ 2.TRUNK │ OK │ OK │ Local │ │ tutorial.clkgen │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Local │ │ tutorial.cpu │ LATEST.TRUNK [@3] │ LATEST.TRUNK [@3] │ OK │ OK │ Local │ │ tutorial.dac │ HEAD.TRUNK [@0] │ HEAD.TRUNK [@0] │ OK │ OK │ Container │ │ tutorial.dbuf │ 2.TRUNK │ 2.TRUNK │ OK │ OK │ Local │ │ tutorial.digital_top │ 3.TRUNK │ 3.TRUNK │ OK │ OK │ Local │ │ tutorial.dma │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Local │ │ tutorial.events_if │ 2.TRUNK │ 2.TRUNK │ OK │ OK │ Local │ │ tutorial.flash │ 2.TRUNK │ 2.TRUNK │ OK │ OK │ Local │ │ tutorial.flash_if │ 2.TRUNK │ 2.TRUNK │ OK │ OK │ Local │ │ tutorial.fusa │ LATEST.TRUNK [@0] │ LATEST.TRUNK [@0] │ OK │ OK │ Container │ │ tutorial.gen_dig │ 2.TRUNK │ 2.TRUNK │ OK │ OK │ Local │ │ tutorial.interface │ 4.TRUNK │ 4.TRUNK │ OK │ OK │ Local │ │ tutorial.intf_ana │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Local │ │ tutorial.io5v │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Local │ │ tutorial.io_tsmc18 │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Local │ │ tutorial.laysc_tsmc18 │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Local │ │ tutorial.padring │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Local │ │ tutorial.proj_tech │ 1.TRUNK │ 1.TRUNK │ OK │ OK │ Local │ │ tutorial.pwr_mgmt_ana │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Local │ │ tutorial.rx_channel │ 2.TRUNK │ 2.TRUNK │ OK │ OK │ Local │ │ tutorial.rxtx │ 2.TRUNK │ 2.TRUNK │ OK │ OK │ Local │ │ tutorial.stup_ana │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Local │ │ tutorial.sys_bus │ 2.TRUNK │ 2.TRUNK │ OK │ OK │ Local │ │ tutorial.t0 │ 2.TRUNK │ 2.TRUNK │ OK │ OK │ Local │ │ tutorial.t1 │ 4.TRUNK │ 4.TRUNK │ OK │ OK │ Local │ │ tutorial.timers │ 2.TRUNK │ 2.TRUNK │ OK │ OK │ Local │ │ tutorial.tool_cert │ LATEST.TRUNK [@0] │ LATEST.TRUNK [@0] │ OK │ OK │ Container │ │ tutorial.trc │ HEAD.TRUNK [@1] │ HEAD.TRUNK [@1] │ OK │ OK │ Local │ │ 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 │ Local │ └────────────────────────────┴───────────────────┴───────────────────┴───────────┴───────────────────────┴───────────┘
If we then update our top level IPV to the newest release and run 'pi ws st' again:
Running pi ws st after updating
> pi up tutorial Updating Workspace. For large IP this could take a while. ┌───────────────────┬─────────────┬─────────────┬───────┬─────────────────┐ │ NAME │ OLD VERSION │ NEW VERSION │ MODE │ PATH │ ╞═══════════════════╪═════════════╪═════════════╪═══════╪═════════════════╡ │ tutorial.padring │ 1.TRUNK │ 7.TRUNK │ Local │ blocks/padring │ │ tutorial.tutorial │ 8.TRUNK │ 10.TRUNK │ Local │ blocks/tutorial │ └───────────────────┴─────────────┴─────────────┴───────┴─────────────────┘ > pi ws st Workspace ID : f4bdf443-9438-43d0-8f45-87bc7138d675 Directory : /tmp/workspaces/ws1 IP : tutorial.tutorial@10.TRUNK Workspace is up-to-date.
We see that the version of the padring is updated from @1 to @7 via the update to tutorial@10. The 'pi ws st' shows everything is up to date, while we brought in a new resource version we also updated our reference to tutorial.tutorial@10, and the data in the workspace now matches that release.
