Workspace configuration

This section describes how to configure Helix IPLM workspaces, including the paths that IPs should be populated in the workspace, cache configuration, unix group, as well as what links and files to generate in the workspace. Workspaces are configured in Project properties and using settings in the piclient.conf file.

Workspace configuration overview

There are two main sources for settings to configure Helix IPLM workspaces:

Project properties

Project properties configure how IPs are built in the workspace. They are set server-side on the IP object, via Editing IPs either from IPLM Web, PiCLI, or the API. A summary of project property configuration options are listed in the following table:

Project property syntax (command line)

Project properties are set in the IP template from the command line. The IP template is accessed via the pi ip edit <LIB>.<IP> command. Project property settings on an IP apply to the IP itself and the resources of that IP. 

The overall syntax of a project property statement must conform to:

• A single IP identifier <ip ident> per line of the template (under the ‘project_props’ section)

• Up to one each of the project property types (path, mode, resolve, unix_group) per line

• The --resolve project property can only appear with the wildcard “*” IP identifier

project_props = 
<ip ident> [--path <path>] [--mode local|refer|both] [--resolve <IPV>] [--unix_group <group><ip ident2> [--path <path>] [--mode local|refer|both] [--resolve <IPV>] [--unix_group <group>

Project property priority and ordering

Project properties can be set on any IP in an IP Hierarchy. In any given IP Hierarchy only the Project properties on the top IP in the hierarchy and those on the leaf nodes of the hierarchy can have an effect. Project properties on IPs in middle levels of hierarchy (that have both a parent and a resource IP) will be ignored. In the event of conflict between the top level IP’s project properties, and the leaf level Project properties, the Top level Project properties are used.

When multiple <ip ident> statements apply to a single IP, if there were settings for both ‘mylib.’ (all IPs in the mylib library) and a setting for ‘mylib.myip’ whichever setting was latest in the list of Project properties would take effect. For this reason more specific Project properties should be placed later in the list of Project properties.

Wildcards in project properties

Wildcards can be used in the <ip ident> section of a project property line. Some examples using the --path setting are shown here:

Resolving Hierarchy conflicts with Project properties

Ideally, IP Hierarchies are created without conflicting lines or versions in the tree. Sometimes this isn’t possible in the short term, as when including an already manufactured design into a new hierarchy. The older design might have a dependency on an older IPV than the newer hierarchy does. 

Helix IPLM supports maintaining conflicting IP versions in the IP Hierarchy but when the IP gets loaded into a workspace, these conflicts must get resolved. Without the --resolve project property Helix IPLM will auto resolve conflicts on workspace load, choosing an aliased version if available, and if not the highest release number involved in the conflict.

*  --resolve mylib.myip@5 tutorial.anotherip@8

Note:  If necessary, the --resolve Project property can be used to override the default on a temporary basis (the end goal should always be to remove conflicts where possible) by choosing which IPVs to win any conflict. The --resolve property can only be used with the “*” value in the <ip_ident> field.

Project properties supports per IP or Library (applied to all IPs in the Library) selection of the automatic conflict resolution method to use in resolving conflicts. The syntax is:

project_props = * --auto-resolve alphanumeric|version

Details on the operation of automatic conflict resolution can be found on the IP Hierarchy page.

Setting up the workspace

Setting the IP paths in the workspace

The --path project property is used to define the IP path in the workspace. By default in the absence of a --path setting the IP directory will be placed at the root of the workspace and be named <LIBRARY>.<IP>.

The path definition can include the variables $LIB and $IP which will be resolved to the IP and Library names of the IP. Note that it is in most cases necessary to use the $IP variable when using <ip ident> specifications that can match multiple IPs, so that the IPs are placed in separate directories in the workspace. Helix IPLM won’t place a new IP into an already existing IP directory.

Setting the IP Cache Mode in the Workspace

Helix IPLM has an IP Cache which is a central disk area (usually on NFS) that has IP versions populated on disk with read only permissions. IPs can be either pre-populated in the cache or populated on demand when requested by the first workspace that needs that version. The primary benefits of the Cache are:

1. Subsequent requests for a particular IPV (after the first one) load very quickly, taking just the time needed to populate a link to the central cache

2. Because cached IPs are read-only to the user workspace there is no possibility of accidental local edits. This makes cache based tapeouts or other high stakes releases preferred to local workspace based releases.

3. Linking to the cache reduces overall disk usage

The --mode project property can be used to limit the IP to being populated either in the PiCache or in the local workspace. Without setting --mode the IP will by default be loaded from the cache, but can be switched to local if required. Unless there is a specific use model that is needed on particular IPs the --mode setting is not usually necessary.

Workspace permissions

Once populated, on disk IP data is protected by the unix level permissions set the workspace. Helix IPLM can set unix permissions with the group specified by the --unix-group project property. 

The --unix-group project property applies to both IPVs in the local workspace, and in the PiCache. Note it is also possible to set ACLs in Picache via the PiCache pre-build hook setting. For local mode IPVs the user must belong to the unix_group specified in the project property.

Workspace configuration in IPLM Web

Workspace Configuration works similarly to the CLI on the IPLM Web interface. 

1. Select Edit IP to edit the IP from the IP page.
   
   
   

2. On the Project properties tab, set the scope of the project property (identical to the <ip ident> on the CLI) and configure the project properties for that mode.

   
   

3. Once complete, click Add and the project property will be saved in the form. The project properties for that mode can be edited by clicking on the configured item, or additional entries can be configured and saved as well.

   
   

4. Once complete, click Save on the top of the form to make a new release of the IP with the new project properties settings. Then click Create.
   

Workspace configuration from piclient.conf

Helix IPLM provides a number of file level Workspace configuration options from the piclient.conf file. Full details concerning settings in the piclient.conf file are discussed in the Client Configuration section. The location of the piclient.conf file is configured using the $MDX_CONFIG_DIR environment variable.

An overview of the settings described below can be found from the output of the 'pi settings' command:

> pi settings
You are logged in as 'admin'.

MDX_CONFIG_DIR 					Env var 	/usr/share/mdx/config
MDX_MAX_LIST_RECORDS_LIMIT 		Unset
MDX_PI_ASCII 					Config 		False
MDX_PI_COMPRESS 				Default 	False
MDX_PI_SERVER 					Env var 	http://methodicsiplm:8080
MDX_PI_TIME_FORMAT 				Config 		%Y-%m-%d %H:%M:%S %z %Z
MDX_PROJECT 					Unset
MDX_WORKSPACE_MANAGER 			Config 		PWM
MDX_PWM_CDSLIB_DIR 				Unset
MDX_PWM_CLIENT_FORMAT 			Default 	ws:{user}:{lib_ip}:{wsid}
MDX_PWM_DEFINE_CDSLIB 			Config 		.:cds/*
MDX_PWM_INCLUDE_CDSLIB 			Config 		cds.lib
MDX_PWM_P4_SYNC_BATCHSIZE 		Default 	2000
MDX_PWM_POST_REFERENCE_CDSLIB 	Config 		/mdx/tools/cds/IC617/share/cdssetup/dfII/cds.lib
MDX_PWM_PRE_REFERENCE_CDSLIB 	Unset
MDX_PWM_TEMPLATE_CLIENT 		Unset
MDX_PWM_UNDEFINE_CDSLIB 		Unset
MDX_PWM_WORKSPACE_CDSLIB 		Unset
MDX_PWM_WORK_LINK 				Config 		$VSC_INSTALL_DIR/config/cadence/dot_cdsinit:cds_run/.cdsinit,$VSC_INSTALL_DIR/config/cadence/cdsLibMgr.il:cds_run/cdsLibMgr.il,cds.lib:cds_run/cds.lib
MDX_PICACHE_BIC_DIR 			Unset
MDX_PICACHE_COMPRESSION 		Unset
MDX_PICACHE_DATA_WAIT_TIME 		Default 	10
MDX_PICACHE_SERVER 				Env var 	picache:5000

PiCache Server configuration:
Root 										/picache-root
Server Version 								1.8.3
Site 										minneapolis

Perforce client configuration

If there are Perforce IPs in the workspace, Helix IPLM configures a Perforce client spec to define the mapping between the Perforce repository and the workspace.

The ”MDX_PWM_TEMPLATE_CLIENT” setting defines a template p4 client that IPLM uses to configure the Options field of the new p4 clients it creates when it builds workspaces with p4 type IPs. The template client name defined in the variable is the name of an existing p4 client defined on the Helix Core server. IPLM leverages the “-t template” flag on the p4 client command to read the Options field from the template client . See “p4 help client” for more information.

Note:  Any content in the template client’s “View” field will be discarded by IPLM.

A typical use for the MDX_PWM_TEMPLATE_CLIENT setting is to configure the p4 client to be “unlocked” rather than the IPLM default “locked” setting.

File linking configuration

Example work_link setting

work_link = $CENTRAL_CAD/project/environment.bash:setup.bash,$VSC_INSTALL_DIR/config/cadence/dot_cdsinit:cds_run/.cdsinit,$VSC_INSTALL_DIR/config/cadence/cdsLibMgr.il:cds_run/cdsLibMgr.il

Cadence cds.lib Setup

The Cadence cds.lib file maps the Cadence library location on disk for the Virtuoso Analog/Mixed Signal design application. If Helix IPLM IPs contain Cadence data the cds.lib file needed by Virtuoso can be automatically generated and kept up to date as the workspace is loaded, updated, and refreshed. If no cdslib related variables are defined, no cds.lib file will be generated. By default Helix IPLM's PWM workspace manager will use a two level approach to cds.lib management.

1. cds.lib file - the top level file is created when the workspace is first created an is not subsequently modified by Helix IPLM. The cds.lib file INCLUDEs the second level workspace_cds.liib file.
2. workspace_cds.lib file - the second level cds.lib file that gets generated/updated automatically during update commands as necessary

cds.lib setup options