Re: [sv-bc] Hierarchical references in #(...) instantiations and $bits() constant function calls (1224 and 2856)

Gord,

In http://www.eda.org/sv-bc/hm/10937.html , you write

   "SV has made things even worse by including variables and not just
parameters in the computation via type, $typename, etc."

type() on expressions and slices may be a little tricky, but I don't
see how type() on variables themselves, or on selects of them (such as
v[i].w[j].x[k]), adds any new difficulty to the language. It's just a
convenience for avoiding the naming and passing of types.

Anonymous type expressions in variable declarations can be factored
out into named types.

If a named type is used in the variable declaration, then it must have
been provided originally by someone that declared it.

If it's a struct type, they could have also typedefed and passed along
the types of all the fields, enabling the effect of type(v.u).

If it's a class type, they could have also used "localparam type" for
the types of all the class properties. (Except for unpacked array
types, which because of the lack of typedef syntax in class_item,
would require "localparam type" for the type of the elements and
"localparam" for the number). All of these could have been passed
along, but it would be more convenient to just use the class scope
operator.

type() on expressions and slices doesn't add anything structurally new
either, but only gives the users a convenient type calculator so that
they don't need to concoct an identical named version of the type. Any
expression or slice that the user could give to type() could also be
used outside of type(), so the tool would already need to know how to
calculate its type.

It could be that the LRM is not clear enough about specifying the
self-determined type of all possible expressions and slices, but, if
so, that's a problem that type() merely makes more salient.

$typename() though ...

    http://www.eda.org/svdb/view.php?id=1511

maybe we should just get rid of that one.

-- Brad

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.