Adding data to new IPs

When first created, IPs are at the @0 release, and do not contain any file data in their contents. This section describes adding file data to a newly created IP.

New IP overview

When first created, DM type IPs have an associated repo_path, which is a location where DM data is stored (Perforce depot path, git repository, etc). DM managed data may or may not already exist in the location specified by the repo_path field, but no data has yet been captured in a Helix IPLM release. The initial release of the newly created IP is numbered @0. The @0 release is created without a file list (or equivalent contents from another DM). Even if Perforce data exists in the IP's repo path, when the IP@0 is loaded into a workspace, the files will not be synced into the workspace. In this case a 'p4 sync' on the IP will populate the files from the DM system and a 'pi release' can be used to capture the file list in an @1 release. Once captured, subsequent 'pi ip load's and 'pi update's will populate the files in the workspace. Note that it is possible to make additional releases without a file list by editing metadata associated with the @0 release. No IP releases will have a file list until the IP is release from the populated workspace, or it is released via one of the Special Release Mechanisms.

Populate the new IP with data

If the DM path isn't yet populated with file data we will need to build a workspace with the IP and add the data from the workspace (or alternatively use one of the Special Release Mechanisms). Once the workspace is built, the IP@0 will be loaded as an empty IP directory.

Files can be copied to the IP and added/submitted via the active DM tool and finally a release can be made of the IP that captures the new IP contents. Let's use an example 'hsio.PCIE' IP:

First we runpi ip load hsio.PCIE :

> pi ip load hsio.PCIE ws1
Loading IPV 'hsio.PCIE@0.TRUNK' into Workspace '/tmp/workspaces/ws1'.
┌───────────┬─────────┬───────┬───────────────┐
│ NAME      │ VERSION │  MODE │ RELATIVE PATH │
╞═══════════╪═════════╪═══════╪═══════════════╡
│ hsio.PCIE │ 0.TRUNK │ Refer │ hsio.PCIE     │
└───────────┴─────────┴───────┴───────────────┘

Next, we cd to the workspace directory and make the IP local (switch it into our workspace from the IP Cache) using 'pi ip local'.

> cd ws1
> pi ip local PCIE
Switching 'hsio.PCIE@0.TRUNK' to local mode.
Successfully switched 'hsio.PCIE@0.TRUNK' to local mode.

The IP directory is at the top level of the workspace (we could change this with the --path configurable using Project Properties):

> ls
cds.lib  cds_run  hsio.PCIE  workspace_cds.lib

Because there is no file list associated with the @0 release of an IP no data would be populated when loading an @0 IP into the workspace. If there were data available a subsequent 'p4 sync' (or equivalent) could be used to populate the IP directory. In this case there is no data in Perforce. Lets add some data to the IP. This is done with a filesystem copy into the IP directory:

> cp -R /the/source/of/some/data/* ./hsio.PCIE/

Followed by a 'p4 reconcile' and 'p4 submit':

> p4 reconcile ...
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/cds/padring/AOP_AMP_CORE/constraint/hierDesign.oa#1 - opened for add
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/cds/padring/AOP_AMP_CORE/constraint/master.tag#1 - opened for add
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/cds/padring/AOP_AMP_CORE/constraint/prop.cfg#1 - opened for add
...
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/doc/hw_design/blg_checklist.xlsx#1 - opened for add
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/doc/hw_verify/blg_bug.xlsx#1 - opened for add
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/hw_code/code/mt48lc32m16a2.v#1 - opened for add
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/hw_code/code/test.v#1 - opened for add
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/hw_code/filelist/blg.f#1 - opened for add
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/hw_code/report/blg.rpt#1 - opened for add
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/hw_code/report/statlinecount#1 - opened for add
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/hw_code/test/test.v#1 - opened for add
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/sw_code/driver/blg_driver.7z#1 - opened for add
//mdx_test/projects/analog/hsio/PCIE3/TRUNK/sw_code/test/blg_driver_test.7z#1 - opened for add

> p4 submit -d "initial add of files for hsio.PCIE3 IP" 
Submitting change 235.
Locking 175 files ...
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/cds/padring/AOP_AMP_CORE/constraint/hierDesign.oa#1
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/cds/padring/AOP_AMP_CORE/constraint/master.tag#1
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/cds/padring/AOP_AMP_CORE/constraint/prop.cfg#1

...
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/doc/hw_design/blg_checklist.xlsx#1 
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/doc/hw_verify/blg_bug.xlsx#1 
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/hw_code/code/mt48lc32m16a2.v#1 
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/hw_code/code/test.v#1 
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/hw_code/filelist/blg.f#1 
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/hw_code/report/blg.rpt#1 
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/hw_code/report/statlinecount#1 
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/hw_code/test/test.v#1 
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/sw_code/driver/blg_driver.7z#1 
add //mdx_test/projects/analog/hsio/PCIE3/TRUNK/sw_code/test/blg_driver_test.7z#1 
Change 235 submitted. >

Now our files are submitted in Perforce, but not yet released in Helix IPLM. If we were using a different DM system, we'd use the appropriate commands for that system (for example, git or svn) when managing the files of the IP at the DM level.

To make a release in Helix IPLM that publishes our exact IP design configuration for later retrieval and use by anyone with permission to it, run 'pi release':

> pi release -m "new hsio.PCIE3 release - files are populated"Successfully created 'hsio.PCIE@1.TRUNK'.

Now we have release @1 of the hsio.PCIE IP. Anyone with access to this IP in Helix IPLM can use it in another Helix IPLM IP Hierarchy used in their project, and we can use this configuration as a basis for future development of our IP block. We can build workspaces and run sims and verification with full confidence that we are using the same set of files that were part of the initial release.