Subject: Re: [sv-ec] Comments on Chapter 4 - Arrays
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Mon Jan 06 2003 - 12:23:25 PST
Jay,
I'm interspersing my comments toyour original message below in blue.
Arturo
----- Original Message -----
From: "Jay Lawrence" <lawrence@cadence.com>
To: <sv-ec@eda.org>
Sent: Monday, January 06, 2003 7:27 AM
Subject: [sv-ec] Comments on Chapter 4 - Arrays
4.2 - Refence to VeraLite
-------------------------
The reference to VeraLite on top of page 22 should be removed/changed.
4.6.1 - Syntax of new[]
-----------------------
If the 'size' specification is an argument to new then () should be
used.
The new operator is also used to create and initialize objects (class instances),
and the parameters to the class constructor (i.e. new) are specified inside ().
A dynamic array is different in the sense that new ceates [n] elements, and the
optional argument to the constructor is specified inside parenthesis. This is
similar to the C++ syntax.
4.7 - "compile-time" error
--------------------------
What is meant by "compile-time" error? Parsing, elaboration, any-time
before simulation starts? We should either define this concept or just
say "error" and have tools produce it when they can.
Good point. A compile-time error is issued at the latest at post-elaboration time.
The intent here is that clearly this should not be a run-time error.
4.8 - passing dynamic arrays as arguments
-----------------------------------------
Since these dynamic arrays look like handles to a dynamic object this
section should probably state that a copy of the dynamic array is
passed. That also gets rid of the issue of having the dynamic array
deleted while the task is waiting.
OK. We should add a short sentence at the start of the 4.8 section that
specifies dynamic arrays passed by value pass a copy of the array.
4.9 - ordering on associative arrays.
-------------------------------------
At one point this section says an associate array imposes an ordering.
In another (4.9.3) it says the ordering for non-integral indices is
"arbitrary but deterministic". I think we need to provide a way to
guarantee deterministic ordering across implementations.
I would propose an interface similar to qsort() or the perl sort()
capability on hashes, that allows the user to provide a function to
specify the ordering. This would return -1, 0, 1 a la strcmp().
The problem with this approach is that an associative array only requires
that the keys (indices) be unique, not the values. Users may not have
enough information to sort the indices, but the associative array does
require that. Sorting an associative array does seem like a good addition,
but it does require more work than this (perhaps a Perl-like mechanism to
obtain two dynamic arrays keys and values and users could sort the two
arrays, just a thought).
4.9.1 - unspecified index type
------------------------------
This currently says "The array can be indexed by any integral data type,
including integers, packed arrays of arbitrary length, string literals,
and packed structures"
Was enum's left out explicitly or should they be added. I believe they
should be added.
Enums are not excluded. I have no issue with adding them (although the
sentence does say including, which is not exclusive).
4.9.1 - length of index expression is significant
-------------------------------------------------
This seems to imply that 1'b1 and 2'b01 would index different elements
in the array, is this true? If so I don't like it. What is the ordering
of these overlapping indices?
No. That is exactly exactly what it shouldn't be. If you were left with that
impression then maybe we should clarify the text with your example?
The semantics of index 1'b1 and 2'b01 is that they both map to the unique
numerical value 1 (regardless of the number of leading zeroes).
4.9.4 - why is 'x' and 'z' disallowed
-------------------------------------
If I declare an integer associative array why are 'x' and 'z' disallowed
as indices?
If I want it 2 state I should use 'int'.
The definition of an unspecified index is defined as a 2-state integral value.
The problem with allowing 4-state indices is that the cardinality of values
that contain X or Z is undefined. Is 3'b0X1 less or greater than 3'b011.
In this conetext, associative array indices are no different that array indices.
4.9.6 - use of event as array indices?
--------------------------------------
Why is 'event' included in table 4.5. The value of an event can't be
tested like this or are you assuming they can?
It is only there to specify what is the (default) value of a non-existent
element. events can be declared as "event foo = null;" so this is just
consistent with that declaration.
This archive was generated by hypermail 2b28 : Mon Jan 06 2003 - 12:22:45 PST