Personal Playgrounds

This document describes a method to experiment with an existing IP tree, switching and adding new IPs and IP versions in a way that:

  1. Does not change the existing IP tree
  2. Is traceable and shareable between users

Methodology

Usually one or more “experiments” libraries are created in order to keep these separated from normal design IPs. In an experimental Library, for each experiment a top level container type IP is created and an existing IP tree is attached to the container as a resource. It is now possible to attach override IPs directly from the top level container. These overridden IPs can be set to a different version or line than the equivalent IP in the original tree, and the tree is resolved to use the override IP using the --resolve project property. The net result is any workspaces built from the experimental tree containers will resolve the conflict in favor of the override IPs attached at the top level. The experimental tree can be evaluated with the alternative IPs, without modifying the original tree. 

Example

  • Create a Library called “experiments” and users can add individual, uniquely named IP containers to it. One example could be “experiments.user1_experiment1@HEAD.TRUNK”.

  • This container can reference one or more IP’s from various other libraries, some of which might include their own hierarchy.

  • If one of those items in the hierarchy needs to be altered, an override IPV of the desired version is added to the top container. The conflict is resolved at the top level via the --resolve option.

  • A workspace can be created from this container, and individual IPV versions can be changed via pi up ip commands.

  • Lines can be created for parents where needed if these changes need to be preserved, although these may end up needing to be hierarchical branches to the top.

  • Eventually the entire workspace could be released via pi release --hier.

  • Other users can load, or make a copy of this top IPV container, and use that for new experiments.

Benefits of the approach

  • It allows for experimentation without changing existing IP trees 

  • It maintains traceability as each IP is recorded where it’s being used and by who

  • It allows users to share these playgrounds

  • It allows promotion to a real project configuration via a copy

Considerations when using this approach

  • Sharing these playgrounds between people only works on released, managed, checked-in data. This is good for traceability.
  • There is a risk people make changes on the default line the IP was put on, and those changes ending up in the project un-intended.
  • It makes it easy to change IPs in the tree, but removing IPs from the tree is more involved.  You can:
    • Load IP@0 into the workspace, this will effectively remove the files from the workspace and leave an empty directory in the file system.
    • Create a line and removing the IP from that line.
  • People might run into permission issues where they want to make changes to either files or resources where they don’t have permissions.
  • The amount of containers under these experimental libraries could get large. 
    • One suggestion would be to create multiple libraries (per division for example).
    • Regularly asks owners if experiments can be deleted after some period of inactivity