Subject: RE: $sv-ec SVTestbench questions/comments.
From: Mehdi Mohtashemi (Mehdi.Mohtashemi@synopsys.com)
Date: Thu Nov 21 2002 - 18:33:54 PST
Hi Adam,
I have included response to the questions you raised in your email
regarding SV testbench donation. Again, I hope this clarifies the
issues.
Section 1. Introduction
First, a clarification. You refer to associative array as a hash. That is
not strictly correct. Although an associative array can be used as a hash,
it also imposes an index ordering and a well defined traversal order. A
hash table imposes no index ordering.
While lists are very useful, the donation's linked lists are modeled after the
C++ Standard Template Library, also not built into the language, but on top
of c++ langugae. The linked list package would be available in source form so
users can modify the package to create new data types or traversal primitives.
This can be very useful for testbench component, hence its inclusion in the
donation.
Perhaps, you make the case for a new requirement to provide a built-in list?
Section 4.7 Associative array (hash) methods
The associative array traversal is not pointer based (and it is not like STL).
The associative array provides built-in methods to traverse the array via the
array's indices (these are not pointers or iterators). This traversal model is
more memory efficient than the perl mechanism which makes a copy of all
the array indices into a new structure, and that is the reason for choosing
this mechanism. Adding a new method that copies the indices into a new
structure might be a worthwhile enhancement.
Section 8.2 Wild equality/inequality.
These operators use casex semantics users requests. Since they have been
added, no user has requested casez semantics. For completeness sake, perhaps
we should add two other operators that implement casez semantics?
Section 8.3 Side effecting operators (pre/post inc/dec)
We are simply documenting that there is currently no clear definition as
to how these operators behave. This is certainly an issue for the basic
committee to decide, as evident by the emails that we have seen today.
If the committee decides to make these undefined then every implementation
will do something different. There is really no reaseon to sacrifice performance
for accuracy since the compiler can recognize the most common uses
(as your message implies) and apply the fastest code. For example, if a
statement includes ++ on unique variables (which is easy to check) then
the fastest code is generated for that expression.
Regards,
- Mehdi
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org]On Behalf Of Adam
Krolnik
Sent: Wednesday, November 20, 2002 8:56 AM
Cc: sv-ec@eda.org; Adam Krolnik
Subject: $sv-ec SVTestbench questions/comments.
Good afternoon;
I have a few questions about the testbench features.
Section 1. Introduction.
You introduce,
"built in types, string, associative array (hash), dynamic array."
"built in synchronization primitives , semaphore, mailbox."
And in section 16 you talk about linked lists. Why are linked lists
not a build in (first class) type like the above elements?
Surely a list is as useful or more than several of the above.
Section 4.7 Associative array (hash) methods
Why follow the STL model, which is reference/pointer based to access elements
of a hash (table?) Why not utilize a perl model which returns a list of
elements and provides foreach() for iteration through such lists.
This is a cleaner and simpler model to use in a language that does not rely
on pointers (references) as a fundamental basis.
Section 8.2 Wild equality/inequality.
Why do you choose the casex semantics for these new operators.
There are papers written about the pitfalls of using casex.
Instead they recommend usage of casez semantics which excludes
the value X as a matching value.
Section 8.3 Side effecting operators (pre/post inc/dec)
Does the value of these operators justify the exacting definitions
that are required. The efficiency of coding using these operators
is not very large given the forms that can cause confusion in the code.
Thanks.
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Thu Nov 21 2002 - 18:33:22 PST