Design Hierarchy and Elaboration

Design Elaboration

ESDL uses class composition to define hierarchy in the design being
modeled. Tightly integrated with hierarchy is the concept of
elaboration of design. System design components and subcomponents
being modeled also need hierarchical context and naming, hierarchical
perpetuation of time unit and precision and also hierarchical
contextualization of parallelization.

Additionally, design components need a way to communicate with other
components. To model the communication medium, ESDL provides the
concept of channels and ports. Ports of various components need to get
connected before the simulation can start.

Elaboration in ESDL happens in phases. A component in ESDL is called
an Entity. The diagram below shows the base class hierarchy of an
Entity. To make elaboration of a design possible, each Entity in the
design must have auxiliary code that reflects on the composition of
the component. This is done by adding the following line as part of
the Entity class declaration:

mixin Elaboration;

That is it. Normally you will not be required to add any other line of
code in the entity to facilitate its elaboration. The Elaboration
mixin would add the required code to the Entity. For example the code
added by the mixin would:

• create a build function that will construct (new) all the component entities declared in the body of the current entity
• call build function for those component entities as well.

The Build Phase

While class composition would be generally sufficient to model the
composition of a domain's architectural components, hardware
description languages like SystemVerilog and VHDL make available the
hierarchical name of a component, which can be printed to identify the
instance of the component in log messages. This feature is very useful
for putting component hierarchy in context while printing a debug
message. This is very important in hardware because a component in a
hardware design is often reused in various hierarchies of the same
design.

System level description languages like SystemC make it mandatory for
the user to give a name to each component in the design
hierarchy. Same philosophy is followed by SystemVerilog UVM, wherein
the component name as a string and the parent object handle is
required to be passed as arguments to the constructor of the component
being instantiated. As the modeled design gets constructed in a
top-down fashion in SystemC (as also in UVM) its various components
get a context in form of their parent component. This hierarchical
context is then used to derive the hierarchical name of the various
components in the design hierarchy.

ESDL does something similar. But instead of asking the user to provide
a name string and a parent (as UVM does) as an argument during
component instance constructor, ESDL uses metaprogramming and compile
time reflections (made available by dlang) to create a runtime
reflection of the component hierarchy. Using metaprogramming features
of D in this way helps reduce the boilerplate. More importantly, since
naming of the component instances is automated, the names thus given
to the components completely match with the hierarchical access to the
objects within the code.

In some cases, the user may be required to intervene in the process of
building the design. For example, a component may have been
instantiated as a base class object and the user might want to
actually instantiate a derived class object. Vlang provides the
function doBuild for that purpose. When the function is coded in a
design, it is called before the build-phase and the build-phase itself
only instantiates the components that have not been yet
instantiated. The build phase automatically provides a name even to
the components that have been manually instantiated.