USING SITaR:

USING SITaR: The New Sound of Design Innovation

http://www.3ds.com

© 2012 Dassault SystèmesUsing SITaR:

Contents

3 What is SITaR?

3 SITaR Implements a Simplified Work Flow

4 User Roles within SITaR

4 SITaR Design Structure

5 Working From a Qualified Baseline

6 SITaR Release Numbering

6 The SITaR Work Flow

11 Example SITaR Project Work Flow

12 Working as a Designer (SITaR)

14 Advanced Configuration of SITaR

15 Conclusion

16 Appendix 1: SITaR Demo Environment

© 2012 Dassault Systèmes Using SITaR:3

SITaR Implements a Simplified Work FlowA SITaR workflow requires sophisticated Configuration Management, as workspaces are constructed at a block level, while individual module development occurs at a file level. SITaR workflow commands in DesignSync wrap module level commands, providing a simplified command set with which to work in the context of a given design project. Environment variables are used to capture module level command argument details, eliminating the need to specify server URL’s, manipulate hierarchical references, or coordinate the use of consistent naming conventions.

What is SITaR?SITaR is a process that is used to formalize the development and integration of design blocks or modules into a design. Those blocks can be hardware, software or mixed in nature, and the actual data-types within them are not limited.

The acronym SITaR represents the following design steps:

● Submit — During module development, the module reaches a milestone state where it is ready to be validated against the rest of the design and then incorporated into a new version of that design. The Submit process is used to create a configuration of the module and make it available to the integrator(s)for possible inclusion in a new version of the design. A module configuration created by the Submit process is also known as a candidate release.

● Integrate — Integrate follows the submission of a single or multiple modules and represents the process by which those Submitted module candidate releases are Integrated into the higher-level design in the context of the integrators working environment.

● Test — Test is not itself a function of the SITaR use model, but is an active process within the overall flow. Essentially, this represents the Verification of the Integrated design which must be performed in order to qualify the current status of the design before a new Release is made. Tools that are used for this process can vary, but can include simulators, compilers and formal verification applications.

● Release — Once the Integrated design has been tested/verified, Release represents the process by which the Integrated view of the design is captured. Each design Release represents a new project Baseline Release from which continued module development can occur.

This diagram provides a simplified view of the above steps. It can be seen that multiple, parallel Development and Submit flows all channel into a single Integrate, Test and Release flow. This convergence of parallel to serial activity is managed through the definition of user roles.

This diagram provides a simplified view of the above steps. It can be seen that multiple, parallel Development and Submit flows all channel into a single Integrate, Test and Release flow. This convergence of parallel to serial activity is managed through the definition of user roles.

The Simplified SITaR Flow

integrate

develop develop develop

submit submit submit

test

release

© 2012 Dassault SystèmesUsing SITaR: 4

SITaR Design Structure

The top-level of the design is termed the “Container Module”, so called since it contains all of the other modules, rather like a Bill of Materials (BOM).

Lower-level modules that are subject to the complete SITaR flow are referred to as “Local Project Modules.” These are essentially the modules developed by the project team.

The relationship between the container module and the set of sub-modules is managed using DesignSync’s hierarchical references (hrefs). Because SITaR encapsulates a simplified workflow, manipulation of hrefs during the Integrate and Release processes is automated.

User Roles within SITaRSITaR has two well defined roles contained with its use model:

● Designer Role ● Integrator Role

Designer RoleThe designer role represents all activity related to the development of design modules. This includes both “Develop” and “Submit” from the previous diagram.

The designer role does not have any final say in the contents of the active design (controlled via Integration), although the fact that the designer is submitting candidate module releases for integration means that they do have an influence on that process. It should be noted that the designer role is typically applied to several engineers working on a single project.

Integrator Role The integrator role represents all activity related to Integrate, Test and Release from the previous diagram. The integrator makes the final decision with regard to the overall content of the active design. It should be noted that there is generally only one person assigned to the integrator role for a project.

SITaR uses a two-level hierarchical structure in order to represent the design and its contents.

Design Container Module

project module project module

container module

project module


Working From a Qualified BaselineSITaR uses the notion of a “Baseline Release” that designers populate into a workspace, against which they make their changes.

The advantages of using the “Baseline Release” methodology are:

● Changes are always made against a qualified (always working) release.

● Users are conveniently isolated from “Latest” changes concurrently occurring in other modules, as well as from the Integrate process itself.

Whenever the integrator completes a Release process, the baseline is automatically updated to this new, qualified release.

To work on a specific module, or modules, the current Baseline Release is populated into a workspace. At this point, the workspace contains a specific version of each

module, and it is likely that the module versions present do not correspond with the Latest versions. In order to work on a module, SITaR is used to replace the specific version with a copy of the Latest version, because edits can only occur on a copy of the Latest version. Work proceeds as edits are made, and checkins can occur at any time. Once a task is complete, all work is checked in, and SITaR is used to Submit a new candidate release for integration. The submission process does not alter the workspace, and further module development can occur, perhaps resulting in newer submissions.

When notification is received that a new project Baseline has been released, SITaR is used to re-populate the workspace. This way, further development always occurs in the context of the new design baseline keeping each designer’s changes in sync with the project as a whole.

SITaR uses a two-level hierarchical structure in order to represent the design and its contents.

Design Container Module

project module project module

container module

project module

Re-use of another SITaR Managed Design within the Current Project


Primary SITaR Work FlowBuilding a WorkspaceIn the case of both the designer and integrator roles, building a workspace is identical, and is managed through the “sitr populate” command.

The basis of building a workspace is that the appropriate configuration of the Container Module is fetched for the appropriate role.

In the case of the designer, the baseline release is fetched. This is essentially the last qualified release (from the sitr release process) and is aliased to the alias name defined by the $sitr_alias environment variable.

In the case of the integrator, the Latest (Default) configuration of the Container Module is fetched. Only the integrator ever references this configuration of the Container Module. It is from this latest configuration that baseline releases are generated, which are then utilized by the designers.

SITaR Release NumberingSITaR incorporates an Automatic Release Numbering scheme. The purpose of this is to allow consistent version numbering of releases (at both the Container Module and Local Project Module levels), as well as ensuring that no effort is wasted by either the designer or the integrator in terms of having to manually decide the next release numbers.

The release numbering encouraged by SITaR is of the form vM.m where “M” represents the major number, and “m” represents the Minor number. e.g. v2.1

SITaR commences all numbering at v1.1 and increments the minor number automatically. e.g. v1.1, v1.2, v1.3 . . . and so on.

It is possible to force both the major and/or minor numbers within the scheme to be incremented to the desired values by specifying a particular release number that the module should assume. SITaR will always continue from this point. e.g. v1.1, v1.2, v2.0, v2.1, v2.2, v3.3, v3.4 . . .

In the above example, the user influenced the release numbering to skip to both v2.0 and at a later time, v3.3. SITaR will always resume the automatic numbering from this point.

While it is not encouraged, it is allowed to name module releases with any name supported by the module tag command. Any attempt to do this will always result in a warning being generated since SITaR cannot automatically increment from release numbers generated outside of the vM.m numbering scheme.


Submitting Project ModulesOnce development of a module has reached a certain level of maturity and the changes have been checked in, the designer can request to have the changes Integrated into the Container Module. The method by which this occurs is through the Submit process.

Taking the development example from above, if the two changes required at this stage of development were simply those associated with the fix of “bug #1432”, following the check-in of those changes, the submit process would be executed.

stcl> sitr submit alu –description “Implemented fixes for bug #1432”

The result of executing “sitr submit” is two-fold: ● To automatically generate a release of the module in its current state

● To take that candidate release and add it to the queue of module releases that are ready for integration

The “sitr submit” function always makes a number of checks before it executes:

● It checks for and reports the existence of any modified files in the workspace before making the release (since if they exist then the release would not be synchronized with the workspace, as those changes are not yet checked in).

● Similarly, a check is made to ensure that there have been changes since the last release of the module. If the current release and the previous release are identical, the “sitr submit” process will indicate this and return. In order to force the submit process to complete, the “–force” switch can be employed.

By default, the “sitr submit” function will automatically generate release numbers as described in the section “SITaR Release Numbering” above. In order to increment the major and/or minor version numbers, or to specify any other arbitrary release name, then the “–release <name>” argument can be used whichwill overload the automatically generated release number.

Developing Project ModulesOnce a designer has constructed their workspace using “sitr populate”, any project module that they wish to develop is simply managed using conventional ENOVIA Synchronicity DesignSync® populate and checkin (“ci”) commands. Since the workspace is constructed from the current “baseline” release of the Container Module, it’s likely that the version of the sub-module within the workspace will be a statically tagged version. The “sitr update” command is used to switch from the version of the sub-module in the “baseline” to an up-to-date

”Latest” version of the sub-module. (This is analogous to running “populate –rec –version Trunk:Latest” in a conventional, file based, workspace.) This command is especially important when multiple designers are collaborating on the same module, since it may be necessary to update the workspace for the module in order to see the other changes.

An example flow of commands for working on a sub-module follows:

stcl> sitr populate (build workspace) stcl> sitr update alu (bring files in sub-module within the ‘alu’ directory up-to Latest) stcl> populate –lock alu/rtl/ALU.v (a modification needs to be made to the ALU.v file) stcl> xemacs alu/rtl/ALU.v (the file is opened in a text editor, modified and saved) stcl> ci –comment “Fixed bug #1432” alu/rtl/ALU.v (commit the change to the version history) stcl> populate –lock alu/doc/module.txt stcl> xemacs alu/doc/module.txt stcl> ci –comment “Updated doc to match spec change for bug #1432” alu/doc/module.txt


The “sitr select” command would be used to select the newly submitted version of the ALU sub-module to be integrated into the ‘CPU’ container module, (which,

in this case, will cause the old version of the ALU to be selected for deletion, and the new version to be selected for addition):

Integrating Project ModulesThe integrator is responsible for taking the incoming sub-module submissions, and possibly new submodules, and integrating them into the Container Module. The integration steps can be summarized as:

● sitr lookup is run to find all sub-module candidate releases, and possibly new sub-modules, that have been submitted since the creation of the current baseline release.

● sitr select is run to select the changes to be made to the Container Module.

● sitr integrate is run to integrate in the selected changes into the Container Module.

● Tests (the ‘T’ in SITaR’) are run to verify that the selected changes function together properly. ● sitr release is run to release a new ‘baseline’ version of the Container Module.

The SITaR integration commands manipulate the DesignSync hrefs which are used to manage the design hierarchy, and control the content of the integrator’s workspace.

Continuing the above example:

The “sitr lookup” command would be used to find all tagged versions of the sub-modules of the Container that have been submitted since the creation of the most recent baseline release.

stcl> sitr lookupModule Config Owner Release Date Description------------------------------------------* ALU @v1.2 joe 2007-11-20 Implemented fixes for bug #1432‘*’ flags that the configuration was created since the latest ‘baseline’ release of CPU (2007-11-12 13:48:12)

stclc> sitr select [email protected] sync://synch:2647/Modules/[email protected] for DeletionSelecting sync://synch:2647/Modules/[email protected] for Addition

Note: Multiple “sitr select” commands can be called in succession to augment the selected changes (selecting changes to other sub-modules, or selecting the addition of new sub-modules to the container.)


The “sitr integrate” command would be used to integrate in the selected changes. This command performs href manipulation.

After updating the Container Module, the “sitr integrate” command will populate the changes into the Integrator’s workspace so that the new configuration can be tested.

stclc> sitr integrateBeginning rmhref operation …sync://synch:2647/Modules/CPU: Created new module version 1.12Finished rmhref operation.Beginning addhref operation …sync://synch:2647/Modules/CPU: Added hierarchical reference:Name: ALUObject: sync://synch:2647/Modules/ALUType: ModuleSelector: v1.2Version: 1.3Relative Path: alusync://synch:2647/Modules/CPU: Created new module version 1.13Finished addhref operation.


Creating New Project ModulesIn the case that new Project Modules need to be created and added to the local project (i.e., modules that should be subject to the entire SITaR flow and not just linked in as static HREFs) it is required to create a module, release it to v1.1 and then integrate it into the Container Module.

In order to simplify this process, a command called “sitr mkmod” is provided that allows for a module to be created in a temporary work area (“–path <path>” argument) and then submitted as a candidate release. Once created in this way it can be selected and integrated into the Container using “sitr select” and “sitr integrate”.

Deleting Modules from the Container ModuleModules can be removed from the Container Module by the Integrator using “sitr select –delete”, followed by “sitr integrate”. Once removed, execution of the “sitr release” function will generate a new release that will no longer contain the deleted items. Note that deletion in this case refers to the dereferencing of modules from the Container Module and not the permanent removal of them from the server — they can always be added back into the Container Module at a later point in time using the “sitr select” and “sitr integrate” functions.

Testing the DesignTests are conducted in the integrator’s workspace to ensure that the changes made do not break or regress the design. If the tests fail, the integrator can use “sitr lookup”, “sitr select” and “sitr integrate” to continue to make changes to the Container Module, until they are satisfied that the new configuration is acceptable for release as a new baseline.

Releasing the DesignOnce any integration task has been carried out, and the test procedures prove satisfactory, it may be desired to create a new baseline release. This new release will form the baseline for any future design modification/enhancements made by the designers to sub-modules.

In order to release the design, the command “sitr release” is run by the integrator. This will have the effect of releasing a new version of the Container Module and updating the baseline tag used to identify the baseline release ($sitr_alias). As with submitting modules, the automatic release numbering scheme is employed unless specifically overwritten with the “–release <name>” argument.


Now, Project Modules can be added to the structure as required. Further modules can be added incrementally at any point later in time:

stcl> sitr mkmod –name ALU stcl> sitr mkmod –name arbiter

The sub-modules are then added to the Container module:

stcl> sitr select [email protected]> sitr select [email protected]> sitr integrate

Finally, the first release of the design is generated, which will form the basis for designers to commence work.

stcl> sitr release

Example SITaR Project Work Flow

Generating a SITaR Project Structure from ScratchAn Integrator starts by setting the appropriate environment variables:

These variables are contained in a file which is sourced by the Integrator prior to executing “sitr” commands.

Next, the Container Module is created on the server:

stcl> sitr mkmod –top

The name of the Container Module is defined in the variable $sitr_container. The “-top” option creates a container module. In this example a Container Module called CPU is created.

Next, an Integration workspace is built:

stcl> sitr populate

The location if the workspace is defined by the $sitr_workdir variable, and the module populated is defined by the $sitr_container variable.

export sitr_container=CPUexport sitr_role=Integrateexport sitr_alias=goldenexport sitr_workdir=/home/pauln/workareas/sitr/integrationexport sitr_server=sync://localhost:8888export sitr_relpath=Peer


Making modifications can be an iterative process, in which changes are checked in, more files are checked out for edit and subsequently checked in, and so forth. The DesignSync checkin (ci) command is used to checkin changes:

stcl> ci ALU

Note that multiple designers may be working on the same sub-module. Running the “sitr update” command often will keep the workspace updated with changes which have already been checked in by others.

When the changes made have stabilized to the point that a task is considered complete, all remaining local modifications are checked in.

To submit the changes as a candidate release for integration:

stcl> sitr submit ALU

If multiple designers are contributing to the development of a sub-module, it would make sense to coordinate candidate submissions.

Working as a Designer (SITaR)A Designer also starts by setting the appropriate environment variables:

These variables are contained in a file which is sourced by the Designer prior to executing “sitr” commands.

Next, a workspace is built:

stcl> sitr populate

The workspace now contains static versions of each sub-module as released in the project baseline.

In order to make modifications to a specific module, the “sitr update” command is used to remove the static version, and replace it with a copy of the “Latest” version, from which edits can proceed.

stcl> sitr update ALU

Edits are made to files in the sub-module:

stcl> cd ALU stcl> populate –lock <files>

export sitr_container=topexport sitr_role=Designexport sitr_alias=goldenexport sitr_workdir=/home/pauln/workareas/sitr/designexport sitr_server=sync://localhost:8888export sitr_relpath=Peer


Releasing a New Design Baseline (SITaR) The integrator can release the design using the “sitr release” command, which creates a new version of the Container Module containing the new project baseline. Sub-module designers are notified that a new project baseline exists, and are encouraged to update existing workspaces to the new baseline.

Updating the Workspace to a New Project Baseline (Designer)When a new release has been generated, designers can choose to update their workspace to this new release. This is carried out simply by using the “sitr populate” command. The “sitr populate” will NOT replace any modules which are currently in edit mode. If, following the generation of a new release, a designer wishes to see how their workspace compares with the new baseline on the server, the the “sitr status” command can be used.

Integrating Submitted Modules from Designers (SITaR)As described above, an integrator may query the system for a list newly submitted modules (i.e., modules submitted since the creation of the current project baseline) by running the “sitr lookup” command. The “sitr select” command can be used to select one of more module versions for integration, and the “sitr integrate” command can be used to manipulate hrefs accordingly. The result is an integration workspace which contains the newly submitted sub-modules as chosen by the integrator.

Testing the New Configuration (SITaR)Test is not itself a function of the SITaR use model, but is an active process within the overall flow. Essentially, this represents the Verification of the Integrated design which must be performed in order to qualify the current status of the design before a new Release is made. Tools that are used for this process can vary, but can include simulators, compilers and formal verification applications.


Enabling Module Caching to Maximize Disk Space EfficiencyThe fundamental concept underlying SITaR is that when a design consists of multiple distinct modules, all module development occurs in the context of a stable set of all the modules, i.e., the project baseline. Thus, only the module (or subset of modules) on which a designer is actively making modifications must be physically present in the workspace. The remaining modules which are present as static versions need not be physically populated into a designer’s workspace. DesignSync includes a module caching mechanism by which modules versions may be pre-populated into an “mcache” directory on a LAN. When a module version is populated (in this case the Container Module), the mcache is inspected to see if it contains any static module versions which are included as hrefs. For any module version which is found in the mcache, a link is created in the workspace to the module located in the mcache, rather than physically populating the module into the workspace. This results is a very efficient use of disk space allocated for designer workspaces, because only the modules which are actively being modified are present in the workspace.

In the context of the SITaR flow, the mcache is automatically populated on demand in a fashion similar to how file “share” caching works. When “sitr populate” is run, it first gathers the list of module versions included in the baseline to be populated. If any module versions are not already present in the mcache, “sitr populate” populates them into the mcache directory. “sitr populate” then invokes “populate”, which does find the set of module versions associated with the baseline in the mcache, an thus creates links rather than populating module content physically into the workspace. Thus, as with “share” file caching, the first designer to populate a new baseline on a LAN incurs the overhead of fetching new module content into the mcache.

Advanced Configuration of SITaR

Defining the Sub-Module to Container Module Relative PathsThe following environment variables affect the way in which the SITaR structure is defined.

$sitr_relpath determines the default relative paths that are used during the integrate process, and therefore the final structure of the design.

Setting $sitr_relpath to “Cone” means that all relative paths lead to modules being placed in a workspace within the cone of the Container module (./<module>) directory. This leads to a local directory structure that will have a parent directory named as $sitr_container and all other modules will be in subdirectories within the parent. Hence “Cone” is a useful way to work when the directory structure should reflect the logical hierarchy of the design.

Setting $sitr_relpath to “Peer” means that all relative paths include “../” as their prefix. Therefore, all modules href’ed by Container Module will be placed at the same level as the Container Module in the workspace.

Hence “Peer” is a useful way to work when the directory structure should remain “flat” and should NOT reflect the logical hierarchy of the design.


DesignSync is the only DDM system which includes a simplified command set (which wraps lower level command, and renders complex details as transparent) which implements a well defined work flow. And because SITaR is implemented as a wrapper, the commands are contained in Tcl procs, and as such can be modified to suit alternate work flows as well.

With SITaR in place, design teams are able to reclaim time in the design schedule that was previously lost developing against the wrong data set, waiting on multiple teams to finish development, having integrators struggle with identifying and assembling contributions from multiple sources (especially if being fetched from different DDM systems), and having to wait as designs are locked down during integration tasks. SITaR is the new sound of design innovation.

ConclusionSITaR implements a work flow which is unique among Design Data Management (DDM) systems. While all DDM systems provide revision control and configuration management capabilities, the SITaR command set provides a simplified use model which supports a design methodology commonly found in the development of complex Integrated Circuits. SITaR is suited for any workflow in which a design is comprised of contributions from multiple contributors, and construction of the top level design is the responsibility of an integrator. The SITaR command set leverages DesignSync’s unique and powerful capabilities for managing design data hierarchies, and provides designers with a small, simple, and intuitive command set for coordinating what are otherwise complex configuration management functions.

SITaR commands are aligned with how a designer thinks: I would like to fetch a project baseline. I would like to modify a specific module in context of the baseline. When I have completed my changes, I would like to submit them as a candidate release for integration into a new project baseline.

SITaR commands are equally aligned with how an Integrator thinks: I would like to assemble, test, and release a project baseline. I would like to know which modules candidate releases have been submitted for integration since I last released a project baseline. I would like to test various configurations of sub-module releases in a workspace isolated from ongoing module development. Having tested a configuration of submodules, I would like to generate a new project baseline release.


These variables are contained in a file which is sourced by the Integrator prior to executing “sitr” commands.

In order to generate a SITaR demo environment the command “sitr_demo_install” can be executed. It is recommended that the server specified by $sitr_server is a non production server, and specially designated server. It is also recommended that this command is run in a temporary staging area that can be deleted after everything is complete.

In order to clean-up a SITaR demo environment, the command “sitr_demo_uninstall” can be used. Note that this command will DELETE ALL MODULES ON THE SERVER SPECIFED BY ”$sitr_server”.

For this to be successful, the user executing this command will need the appropriate access rights. These include the following example AccessControl lines:

Appendix 1: SITaR Demo EnvironmentProvided with SITaR is an automatic means to construct a demonstration environment.

An Integrator starts by setting the appropriate environment variables.

export sitr_container=topexport sitr_role=Integrateexport sitr_alias=goldenexport sitr_workdir=/home/pauln/workareas/sitr/integrationexport sitr_server=sync://localhost:8888export sitr_relpath=Peer

access allow Delete only users $admin when Type VAULTaccess allow DeleteNote only users $adminaccess allow Rmmod only users $admin

Note that the “sitr_demo_uninstall” routine will only clean data on the server specified by $sitr_server, and will not clean-up remote modules that may have been created during the operation of “sitr_demo_install”.

© D

assa

ult S

ystè

mes

201

2, a

ll ri

ghts

rese

rved

. CA

TIA

, Sol

idW

orks

EN

OVI

A, S

IMU

LIA

, DEL

MIA

, 3D

VIA

, 3D

SwY

m, E

XALE

AD

, and

Net

vibe

s ar

e re

gist

ered

trad

emar

ks o

f Das

saul

t Sys

tèm

es o

r its

sub

sidi

arie

s in

the

US

and/

or o

ther

cou

ntri

es.

Dassault Systèmes, the 3D Experience Company, provides business and people with virtual universes to imagine sustainable innovations. Its world-leading solutions transform the way products are designed, produced, and supported. Dassault Systèmes’ collaborative solutions foster social innovation, expanding possibilities for the virtual world to improve the real world. The group brings value to over 150,000 customers of all sizes in all industries in more than 80 countries. For more information, visit www.3ds.com.

Visit us at3DS.COM

Delivering Best-in-Class Products

Europe/Middle East/Africa Dassault Systèmes 10, rue Marcel Dassault CS 40501 78946 Vélizy-Villacoublay Cedex France

Americas Dassault Systèmes 175 Wyman Street Waltham, Massachusetts 02451-1223 USA

Asia-Pacific Dassault Systèmes Pier City Shibaura Bldg 10F 3-18-1 Kaigan, Minato-Ku Tokyo 108-002 Japan

Virtual Product Design

3D for Professionals

Realistic Simulation

Global Collaborative Lifecycle Management

Information Intelligence

Social Innovation

Online 3D Lifelike ExperiencesVirtual Production

WI-SITaR 1205

http://www.3ds.com/products

http://www.3ds.com

http://www.3ds.com/company/about-dassault-systemes/dassault-systemes-in-the-world/

http://3ds.com/catia

http://3ds.com/solidworks

http://3ds.com/simulia

http://3ds.com/enovia

http://3ds.com/exalead

http://3ds.com/3dswym

http://3ds.com/3dvia

http://3ds.com/delmia

Documents

USING SITaR: