Elaborate
Resolve constant expressions, parameter values, and datatypes.
In the previous version of VL, we used to do a series of transforms
that:
(We'll refer to these three kinds of transformations collectively as
"elaboration;" commercial implementations use that term to mean something
somewhat similar.)
The problem with this series of transformations is that there may be
complicated relationships among functions, parameters, and datatypes -- a
function, parameter, or datatype definition may use functions, parameters, and
datatypes. Consider the following sequence of declarations:
function integer f1 (logic a);
f1 = a ? 3 : 5;
endfunction
parameter p1 = f1(1);
typedef logic [p1-1:0] t1;
function t1 f2 (integer b);
f2 = ~b;
endfunction
parameter t1 p2 = f2(p1);
From the example we can see that it won't suffice to use our three
transformations once each in any order. One solution might be to try the
tranformations repeatedly in a cycle. Our solution is instead to allow
parameters, functions, and types to be resolved as needed while resolving other
parameters, functions, and types. We use a lookup table to store previously
resolved items as a form of memoization.
The lookup table in which we store these values is called an elabindex.
The elaboration algorithm calls subsidiary algorithms of vl-expr-svex-translation, which use the elabindex lookup tables in a read-only
manner. Before translating an expression (or, similarly, function declaration)
to svex, the elaboration algorithm walks over the expression and collects the
information it needs to successfully resolve it to an svex expression: the
types, svex translations, and port lists of functions that the expression
calls, and types and values of parameters referenced in the expression. This
information is stored in the elabindex before translating the expression.
Subtopics
- Elabindex
- A data structure for recording elaboration results, i.e., functions,
types, and parameters.
- Vl-override-parameter
- Try to override a parameter with a new expression.
- Vl-genblob-elaborate
- Vl-modelement-elaborate
- Vl-design-elaborate-aux
- Vl-package-elaborate-aux
- Vl-taskdecl-elaborate
- Vl-clkdecl-elaborate
- Vl-defaultdisablelist-elaborate
- Vl-modport-portlist-elaborate
- Vl-modinst-elaborate-aux
- Vl-maybe-parse-temps-elaborate
- Vl-ansi-portdecllist-elaborate
- Vl-ansi-portdecl-elaborate
- Vl-parse-temps-elaborate
- Vl-dpiimportlist-elaborate
- Vl-clkassignlist-elaborate
- Vl-cassertionlist-elaborate
- Vl-assertionlist-elaborate
- Vl-taskdecllist-elaborate
- Vl-sequencelist-elaborate
- Vl-propportlist-elaborate
- Vl-propertylist-elaborate
- Vl-plainarglist-elaborate
- Vl-namedarglist-elaborate
- Vl-maybe-clkskew-elaborate
- Vl-gclkdecllist-elaborate
- Vl-gateinstlist-elaborate
- Vl-elabtasklist-elaborate
- Vl-defaultdisable-elaborate
- Vl-sequence-elaborate
- Vl-property-elaborate
- Vl-modportlist-elaborate
- Vl-modport-port-elaborate
- Vl-modinstlist-elaborate
- Vl-letdecllist-elaborate
- Vl-interfaceport-elaborate
- Vl-initiallist-elaborate
- Vl-gateinst-elaborate
- Vl-fundecllist-elaborate
- Vl-clkdecllist-elaborate
- Vl-assignlist-elaborate
- Vl-assign-elaborate-aux
- Vl-arguments-elaborate
- Vl-alwayslist-elaborate
- Vl-regularport-elaborate
- Vl-portlist-elaborate
- Vl-finallist-elaborate
- Vl-dpiimport-elaborate
- Vl-clkassign-elaborate
- Vl-bindlist-elaborate
- Vl-aliaslist-elaborate
- Vl-warn-about-negative-indices
- Vl-udplist-elaborate
- Vl-propport-elaborate
- Vl-modinst-elaborate
- Vl-udp-elaborate
- Vl-port-elaborate
- Vl-plainarg-elaborate
- Vl-namedarg-elaborate
- Vl-modport-elaborate
- Vl-gclkdecl-elaborate
- Vl-elabtask-elaborate
- Vl-clkskew-elaborate
- Vl-assign-elaborate
- Vl-always-elaborate-aux
- Vl-always-elaborate
- Vl-alias-elaborate
- Vl-initial-elaborate
- Vl-bind-elaborate
- Vl-final-elaborate
- Vl-fundecl-paramdecls-for-const-args
- Vl-fundecl-body-with-const-args
- Vl-exprlist-args-to-4vec-consts
- Sv::svex-constval
