OpenROAD application components share the same name space. This means that OpenROAD identifies the component strictly by name and does not consider the context in which the name is used. These components are:

When OpenROAD encounters a name, it uses the first component it finds that matches the name. The context in which the name is specified has no effect on the name resolution. For example, when you use a procedure name in a callproc statement, OpenROAD searches for any component with that name, not just a procedure.

When you include the application name, OpenROAD searches the specified application for the component rather than using the usual search order. You can specify the current application, any included application, or the core library.

When you specify a procedure or frame name at runtime, the search order differs from the first four steps of the name order search.

When you use one of these statements to specify a frame or procedure name, OpenROAD resolves the reference at runtime instead of at compile time. OpenROAD first searches the currently executing component (a frame, global procedure, or user class method script) for a local procedure with the dynamically specified name. If the search is not successful, OpenROAD then searches for a global component (a frame or procedure).

By default, the global search order for the resolution starts with the topmost running application, that is, the application with which the user began the session.

This feature means that a frame in an included application can call a frame that belongs to the including application. For example, if Application A includes Application B, then Application B can use a dynamic name to call a frame that is part of Application A.

The following table displays dynamic and explicit name resolution. It also shows the behavior for a variety of callframe statements using the assumptions described in this section. It also illustrates the behavior differences between dynamic and explicit name resolution.