Subject: [sv-ec] Comments on remainder of Chapter 3
From: Jay Lawrence (lawrence@cadence.com)
Date: Mon Jan 06 2003 - 05:01:46 PST
3.10.3 type checking of enums
-----------------------------
Is the type checking here any stronger or weaker than the last paragraph
of 3.10 (immediately above the start of 3.10.1) beginning with "The type
is checked in assignments, arguments, ..."?
These two should be reconciled and put in only one place.
3.10.3 performance of type checking
-----------------------------------
Strong type checking for discontiguous ranges of values will be very
expensive at runtime. Some of the analysis can be done statically but
the worst-case is very bad.
Do we really want strong typing of enums?
3.10.5 Increment and Decrement on enumerated types
--------------------------------------------------
If we are going to provide these it needs to be separated from the
assignment operator.
The current proposal has the only way of getting to the next value as
being enumVar++. This means that the current variable is set to the next
value in the enumeration. What if I want to set a different variable to
the next value of the enumeration instead?
enum Colors {red, green, blue, yellow, white, black};
Colors c1, c2;
c1 = red;
c2 = ++c1; // assigns both c1 and c2
I would prefer a system task (make it a method if you must ;):
c2 = $next(c1); // only assigns c2
Or
c2 = c1.next;
3.10.5 Missing other "type introspection" operators on enums
------------------------------------------------------------
To make ++ ($next)and -- ($prev) useful (especially because of the wrap
semantics), the $first and $last operators are also needed.
How else do you loop through all values without explicitly calling out
the first and last (and thus creating a hard to maintain loop)?
for (c1 = $first(Colors); c1 <= $last(Colors); c1 = $next(c1))
begin
...
end
3.12 Classes
------------
I propose that all discussion of classes be postponed until Chapter 11
is reviewed. Discussing or approving this section without the full
debate on classes is premature.
David, you are planning on a one-shot vote for a whole bunch of chapters
does it include both chapter 3 and 11 or was the cut-off before 11. It
will make it difficult to approve the addition of classes in 3 without
11 included?
3.14 Dynamic casting
--------------------
Verilog uses have enough problems with static casting, this whole
section seems unnecessary. I've seen this sort of programming construct
in environments like GUI's where a user may have typed garbage in a
field and you are trying to dynamically idiot proof the validation of
the form, but I don't see why it is needed in Verilog.
Where are dynamic casts needed?
3.14 - use of term "scalar"
---------------------------
The term 'scalar' is used here and parenthetically defined as
(non-unpacked array). It needs a clearer definition somewhere.
Does it exist and I'm just missing it?
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
This archive was generated by hypermail 2b28 : Mon Jan 06 2003 - 05:03:24 PST