Workspaces

Helix IPLM workspaces are built from released IP Hierarchies (CIPBs) captured in the Helix IPLM Server. All the data in the IP Hierarchy can (if permissions have been granted, see Workspaces and permissions for more details)  be populated into the workspace at the precise versions captured in the release. This section gives an overview of how Workspaces are constructed, updated, and released within the Helix IPLM platform.

Workspace overview

Helix IPLM workspaces are built from Released IP Hierarchies, and when first loaded they exactly match the Hierarchy's release. As development proceeds Helix IPLM can check the current state of the workspace against the release that was initially loaded, providing a view of the changes that have been made to that point. Once design gets to a point where the state of the workspace is ready for a new release, Helix IPLM can capture the workspace state and share it to the server as a new release. The new release then becomes the basis for the next round of development, and can be used for verification and documentation of the captured design state. Workspace snapshots, which capture and transfer the workspace status without making a full release can be made at any time and used to make hot fixes and share issues between IP providers and consumers. Workspace management in Helix IPLM additionally provides a number of opportunities for workflow automation. The traceable Helix IPLM workspace provides the foundation for a number of development capabilities:

CapabilityDetails
Incremental DesignIncremental changes can be applied on top of a known state and verified in a controlled manner.
Reference ComparisonThe workspace state can be compared against any Helix IPLM release
Stable Verification PlatformStatic releases freeze the state of the design. While development work continues, earlier states of the design can be easily replicated and verified.
Continuous IntegrationThrough automation via hooks and/or events automated build processes can use Helix IPLM releases to build their workspaces
Design IntegrationSub-hierarchies of the Helix IPLM workspace can be updated to incorporate new sub-system releases. Staged updates facilitate efficient integration.
Immutable RecordHelix IPLM releases can be used to recreate the state of any release (tapeouts etc) months, years, or even decades later

Workspace Build - Develop - Update - Release flow

Once built the DM managed data in Helix IPLM workspaces supports any native development flow, Helix IPLM stays out of the way until needed. Standard DM commands for the IP in question ( eg Perforce, Subversion, git ) can be run from the command line, clients with DM capabilities can work on the data, Cadence, Synopsys, or ADS data can be managed through VersIC. As the design progresses Helix IPLM can be used to compare the current state of the design to the releases captured in the server. If new versions of some IPs become available Helix IPLM can bring those updates into the workspace using Update Modes. When the data set has reached a state in which it is ready for release, Helix IPLM can be used to capture the new release.

The below diagram shows IP@52 being loaded into the workspace, a combination of DM (in this case Perforce) and Helix IPLM commands being run on the workspace to make changes, and finally a new release being created and published back to the Helix IPLM server (IP@53).

Centralized Workspace tracking

Because Helix IPLM workspaces are built from and can be updated to IP Versions (Releases), they are fully traceable in the system. Workspaces and their contents can be queried centrally, this allows for IPVs that have issues associated with them, or that have particular licensing requirements to be fully searchable across all workspaces. 

Workspace Development Automation

Workspace Load, Update, and Release events provide opportunities to automate design flows through Hooks. Automation can be initiated for instance at the time a new release is captured. That new release can be characterized via continuous integration flows via Jenkins, with simulation, verification, and metadata capture being performed automatically. The results of the checks and data gathering can then be applied back automatically onto the new IPV created by the release. In this way consistent sets of metadata and characterization information can be generated for each release, without the need for user intervention. 

Command Line

Workspaces are managed via the 'pi workspace' command on PiCLI:

pi workspace Command
> pi ws -h
Usage: pi workspace [-h] SUBCOMMAND ...

Description: Commands related to Workspaces. These subcommands are used to
delete, list information about, and move Workspaces.

Optional arguments:
  -h, --help            Show this help message and exit

Available sub-commands:
  SUBCOMMAND
    delete (del, remove, rm)
                        Delete a Workspace.
    list (ls)           List all matching Workspaces.
    move (mv)           Move a Workspace to a new location.
    refresh (ref)       Refresh a Workspace.
    status (st)         Show the status of a Workspace.