About Model Version Revision Hierarchies

Importing a DesignSync Module Hierarchy to Create a Model Version Hierarchy

If you are using DesignSync, you can automatically create a model version hierarchy from existing DesignSync data. A DesignSync module hierarchy can map to a hierarchy of model version revisions in Defect Management and Collaboration that are linked through a relationship between the model versions. This structure supports the notion of hrefs and href selectors in DesignSync, allowing the relationship to link to a relative path (href) and tag (href selector) that also links to a model version revision in Defect Management and Collaboration. The relative path indicates where the data for a sub-module will be placed on disk, relative to the parent module, when the data is fetched from the DesignSync repository.

Take the following example:

An href of the form CHIP->ALU@Gold in DesignSync is implemented in Defect Management and Collaboration as two model version revisions, CHIP and ALU, which are linked. A DesignSync module hierarchy with an href to a simple tag (for example, CHIP->ALU@Gold) is represented using Tag Holder objects in Defect Management and Collaboration. The ALU revision is also connected to a Tag Holder object with a TagName (for example, Gold), and another relationship links to that connection.

A vault at some selector in DesignSync maps to a model version revision. That vault can be a module at some version, or even a file vault at some selector. In other words, if there were a version 1.42 of module CHIP in DesignSync, then there could be a model version called CHIP with a revision 1.42 in Defect Management and Collaboration. A static module hierarchy in DesignSync can be modeled as a simple model version revision hierarchy in Defect Management and Collaboration using the model version-to-model version capability. Thus, if a module hierarchy has an href from CHIP;1.42 to CPU;1.53 in DesignSync, then there could be two business objects called Model Version CHIP 1.42 and Model Version CHIP 1.53, which are linked together in Defect Management and Collaboration.

Suppose you are developing a CHIP and the CPU module used by that CHIP simultaneously, working towards release RelA. In this case, in DesignSync you would have an href from CHIP@RelA:Latest to CPU@RelA:Latest. In Defect Management and Collaboration, as well as model version revisions for the static (that is, released) versions of the module, you can also have model version revisions representing the work in progress (WIP). Thus, you could have model version revisions Model Version CHIP RelA:Latest and Model Version CPU RelA:Latest, that are linked together.

These dynamic hierarchies exist to track both the progress of the release and defects that arise during the development of the release that are to be fixed in that release.

For more information, see Importing a DesignSync Module Hierarchy as a Model Version Hierarchy.

Dynamically Managing Hierarchical Model Version Relationships with Tags

A hierarchy tag that is associated with a model version revision acts as a placeholder for that model version revision's location in a model version hierarchy. If the tag is subsequently moved to another model version revision, the new model version revision will now occupy that location in the model version hierarchy. This allows you to dynamically manage the model version hierarchy by moving tags to subsequent model version revisions as they are created, without having to create and remove hierarchical references from individual model version revisions in the model version hierarchy. For more information, see Adding a Hierarchy Tag to a Model Version Revision.

Manually Managing Hierarchical Model Version Relationships

You can create or remove hierarchical references to model version revisions to manually manage the model version hierarchy. For more information, see Creating a Hierarchical Reference.

You can also select one or more model versions from a search results list, a Model Version Hierarchy page opened in a separate browser tab or window, or a Classified Items list in the Semiconductor IP Classify and Reuse app, then drag and drop the selected model versions into the structure on the Model Version Hierarchy page to copy them into the model version hierarchy. You cannot move a model version from a Model Version Hierarchy page opened in a separate browser window or tab into a list or table opened in the main browser window or tab; you can only copy a model version in that situation (selecting Move will actually perform the Copy action in the background). The page displaying the model version to be copied must be shown in the Details display mode, but the page showing the target of the copied model version can be in either Details display mode or Graph display mode.

You can copy and move model versions within a model version hierarchy on the Model Version Hierarchy page using drag and drop. All model versions beneath the copied or moved model version are copied or moved with it in the model version hierarchy. Depending on which action you selected on the Model Version Hierarchy page's toolbar, the selected model versions are dropped into the model version hierarchy as children of the model version selected as the target location, either leaving the dragged model versions unmodified in their original locations (Copy action) or removing the connection to the dragged model versions in their original locations (Move action). If the parent model version of the copied or moved model version appears in more than one place in the model version hierarchy, the copied or moved model version will be displayed beneath the target parent model version in all of its locations in the model version hierarchy. You can use drag and drop to copy or move model versions when the Model Version Hierarchy page is in either Details display mode or Graph display mode.

For more information about using the Copy and Move actions to manually manage a model version hierarchy, see . For more information about using drag and drop to manually manage a model version hierarchy, see .