osci_issues_for_scv.txt from GreenSocs at Krugle
Show osci_issues_for_scv.txt syntax highlighted
Time-stamp: <2002-12-05 15:47:01 mxg>
VWG issue list
Issue 1: Smart Pointer for Private/protected data type
Status: this is a documentation issue that will be fixed for the
production release of the code.
11/20/02: We must fix this for beta 1. Dean will fix the SCV spec,
and Ted will add an example for this to the notebook.
Associated PCR: 489032
12/02/02: Fixed in beta 1 release.
Issue 2: Transaction recording: Begin and end attribute names not
recorded
Status: this bug has been confirmed and is a priority 0 pcr. It will
be fixed for the production release.
11/20/02: We must fix this for beta 1. Bill P will fix the code.
Associated PCR: 489049
12/02/02: Fixed in beta 1 release
As part of the fix, these methods were added to scv_tr.h:
// Get the names of the begin and end attributes, as given in the
// scv_tr_generator_base ctor:
//
const char* scv_tr_generator_base::get_begin_attribute_name() const;
const char* scv_tr_generator_base::get_end_attribute_name() const;
Issue 3: Begin Transaction does not seem to record relation names
Status: this bug has been confirmed. Since the add_relation() method
works properly as a work around, this is set as a priority 1
pcr. However, our intention is to fix it for the production release
of code.
11/20/02: We must fix this for beta 2.
Associated PCR: 489052
12/02/02: Fixed in beta 1 release. As part of this fix, it's
possible to define a relation handle that can be used to specify a
relation between two transaction. This can be more efficient than
having to specifying the relation as a character string
name. (However, the original API in which the realtion name is
specified is retained.)
This typedef defines a relation handle:
typedef long scv_tr_relation_handle_t;
---
In class scv_tr_db, 2 methods were added:
// Create a new relation that can be defined between two
// transactions. If a relation with relation_name had
// previously been created, then return the handle to that
// relation.
//
scv_tr_relation_handle_t create_relation(
const char* relation_name) const;
// Get the name of a relation handle. NULL is returned if the
// relation_handle does not refer to a valid relation.
//
const char* get_relation_name(
scv_tr_relation_handle_t relation_handle) const;
---
In class scv_tr_handle, an argument in the relation callback
function was changed from:
typedef void callback_relation_function(
const scv_tr_handle& transaction_1,
const scv_tr_handle& transaction_2,
void* user_data_p,
const char* relation_name);
To:
typedef void callback_relation_function(
const scv_tr_handle& transaction_1,
const scv_tr_handle& transaction_2,
void* user_data_p,
scv_tr_relation_handle_t relation_handle);
---
In class scv_tr_handle, this method was added:
bool add_relation(
scv_tr_relation_handle_t relation_handle,
const scv_tr_handle& other_transaction_handle);
---
In class scv_tr_handle, this method was removed:
const scv_tr_handle get_related_transaction(const char* relation_name) const;
and replaced it with:
// If a related transaction is specified at the beginning of a
// new transaction, then return the other related transaction
// and the relation_handle.
//
const scv_tr_handle* get_immediate_related_transaction(
scv_tr_relation_handle_t* relation_handle_p);
---
In class scv_tr_generator, these methods were added:
scv_tr_handle begin_transaction(
scv_tr_relation_handle_t relation_handle,
const scv_tr_handle& other_transaction_handle)
scv_tr_handle begin_transaction(
const T_begin& begin_attribute_values,
scv_tr_relation_handle_t relation_handle,
const scv_tr_handle& other_transaction_handle)
scv_tr_handle begin_transaction(
const sc_time& begin_sc_time,
scv_tr_relation_handle_t relation_handle,
const scv_tr_handle& other_transaction_handle)
scv_tr_handle begin_transaction(
const T_begin& begin_attribute_values,
const sc_time& begin_sc_time,
scv_tr_relation_handle_t relation_handle,
const scv_tr_handle& other_transaction_handle)
Issue 4: Multiple calls to record_attribute (page 51)
Status: the documentation is incorrect on this point. The
documentation will be clarified in the production release. The
behavior of multiple record_attribute() calls is intended to be
implementation specific (like a zero time glitch on a signal). The
reference implementation will record all values. It is mandatory
that an implementation at least record the last value.
11/20/02: We must fix this for beta 1. Dean will fix the SCV spec.
Associated PCR: 489055
12/02/02: Document updated for beta 1 release.
Issue 5: Arbitrary data types not handled properly by record_attribute
Status: the bug as reported (compiler error on record_attribute of a
user type) could not be duplicated. However, a bug was found when
trying to duplicate the compiler error. record_attribute currently
does not record user defined attributes (it indicates they are an
undefined type). This is a priority 1 pcr. Our intention will be to
fix this by the production code release. For the compiler error, a
test case is required for us to understand the nature of the problem
being reported.
11/20/02: We must fix this for beta 1. Bill P will fix the code.
Associated PCR: 489077
12/02/02: Fixed for beta 1 release.
This is fixed for all user-defined data types except for pointers,
which are not currently implemented by the scv_extensions.
Also, this method was added to class scv_tr_handle, so that if the
attribute_value object has scv_extensions that include the name of
the object, then you don't need to use the form of
record_attribute that requires the name.
template <class T> void record_attribute(
const T& attribute_value) {
scv_extensions<T> ext = scv_get_const_extensions(attribute_value);
this->_record_attribute(0, &ext);
}
Issue 6: Installation file
Status: we will move installation information from the README to the
INSTALL file. This has been completed for the beta release.
11/20/02: done. Awaiting confirmation from Logie.
Issue 7: README references to Vendor specific tools
Status: all references to specific vendor tools will be removed from
the README file. This has been completed for the beta release.
11/20/20: done
Issue 8: make install documentation lacking
Status: make install will be documented in the INSTALL file. The
semantics of make install are to use the prefix path by default. If
it doesn't exist, then make install put the installation in the
current directory. This is done for the beta release.
11/20/02: done
12/05/02: same issue as #28
Issue 9: documentation for patching systemc with dynamic threading
Status: the systemc version reference should be 2.0.1. The prefix
for the patches is tb_ because these are not scv_ classes. The
dynamic threading patches should be removed completely from the scv
kit. We will provide those separately for users that want them
(until the equivalent functionality is available in the core
systemc). Reference to the tb_ classes has been removed for the beta
release.
11/20/02: done
Issue 10: Configure checks for vendor installation information
Status: all configure checks associated with eda vendor specific
tools will be removed. We are working on this, and intend to have a
simplified configure file for the next release that is more in line
with the systemc version of configure. This has been done for the
beta release.
11/20/02: done
Issue 11: No make debug support
Status: this request makes sense. We should be able to add this for the production release,
time permitting.
11/20/02: We must fix this for beta 2.
Associated PCR: 489112
12/02/02: not done, planned for beta 2 release.
02/11/03: fixed in beta 2.
Issue 12: Multiple platform support to a single install prefix
Status: this will be fixed along with the general cleanup of
configure in issue 10 to make the configuration compatible with the
standard systemc configuration. This will be planned for the
production code release.
11/20/02: We must fix this for beta 2. This means using
lib-<modifier> instead of lib as the library subdirectory name.
02/11/03: fixed in beta 2.
Issue 13: Source files with tb_ extensions
Status: this is related to issue 9. Our plan is to move these files
out of the scv installation, and make them available independently
and not part of the standardization effort. This is done for the
beta release.
11/20/02: done
Issue 14: Class names starting with _
Status: this is done for classes that are implementation specific so
it does not seem to be a critical issue. Is there an OSCI convention
for cases classes that are internal? It is inappropriate to use scv
in such cases, so _scv was the choice made. If there is an OSCI
coding guideline for this type of thing we can look at making the
appropriate modifications.
In a previous issue a postfix _ was mentioned. This issue was
specifically for the tb_ classes which will be removed. However, the
_<class> convention was used in the introspection code quite
extensively.
11/20/02: We will take no action on this pending a LWG decision on
naming conventions.
Issue 15: Unknown symbol __builtin_expect() on Linux
Status: this happened because of a bug in jrand() on 7.1 and earlier
versions. The fixed code for jrand() was taken from a gcc2.96
implementation on rh7.2. This is where the __builtin_expect() comes
from. We are investigating what it will take to remove the
dependency on this symbol but still have a working jrand() for
generating uniform random numbers. A possible fix has been added to
the beta kit. However, we currently do not have a Linux machine with
gcc 2.95.3 to test the fix.
11/20/02: We have confirmed that this has been fixed for 2.95.3, but
cannot guarantee that there are no other issues associated with that
compiler. VWG consensus was that this is not a critical issue
provided we work with 2.96. SystemC 2.1's primary GNU target will
be 3.2.
Associated PCR: 489116
We test with RedHat 7.1 base CD plus the following set of RPMs:
Mesa-3.4.2-10.i386.rpm
Mesa-devel-3.4.2-10.i386.rpm
XFree86-100dpi-fonts-4.1.0-25.i386.rpm
XFree86-4.1.0-25.i386.rpm
XFree86-75dpi-fonts-4.1.0-25.i386.rpm
XFree86-devel-4.1.0-25.i386.rpm
XFree86-libs-4.1.0-25.i386.rpm
XFree86-tools-4.1.0-25.i386.rpm
XFree86-twm-4.1.0-25.i386.rpm
XFree86-xdm-4.1.0-25.i386.rpm
XFree86-xfs-4.1.0-25.i386.rpm
e2fsprogs-1.26-1.71.i386.rpm
e2fsprogs-devel-1.26-1.71.i386.rpm
filesystem-2.1.0-2.1.noarch.rpm
gdb-5.1-0.71.i386.rpm
glibc-2.2.4-24.i686.rpm
glibc-common-2.2.4-24.i386.rpm
glibc-devel-2.2.4-24.i386.rpm
kernel-2.4.9-31.i686.rpm
kernel-headers-2.4.9-31.i386.rpm
kernel-smp-2.4.9-31.i686.rpm
kernel-source-2.4.9-31.i386.rpm
mkinitrd-3.2.6-1.i386.rpm
modutils-2.4.13-0.7.1.i386.rpm
ncurses4-5.0-2.i386.rpm
nscd-2.2.4-24.i386.rpm
tar-1.13.25-1.i386.rpm
util-linux-2.11f-17.i386.rpm
xinitrc-3.20-1.noarch.rpm
ypbind-1.7-8.i386.rpm
pdksh-5.2.14-13.i386.rpm
cpp-2.96-85.i386.rpm
gcc-2.96-85.i386.rpm
gcc-c++-2.96-85.i386.rpm
gcc-g77-2.96-85.i386.rpm
gcc-objc-2.96-85.i386.rpm
libstdc++-2.96-85.i386.rpm
libstdc++-devel-2.96-85.i386.rpm
motif-1.2.4-3glibc.i386.rpm
motif-devel-1.2.4-3glibc.i386.rpm
motif20-mwm-2.0.1-3glibc.i386.rpm
motif21-libs-2.1.10-3glibc.i386.rpm
motif21-sdevel-2.1.10-3glibc.i386.rpm
On RedHat 7.2 we add the following RPMs to the base CD:
Mesa-3.4.2-10.i386.rpm
Mesa-devel-3.4.2-10.i386.rpm
XFree86-100dpi-fonts-4.1.0-25.i386.rpm
XFree86-4.1.0-25.i386.rpm
XFree86-75dpi-fonts-4.1.0-25.i386.rpm
XFree86-ISO8859-15-100dpi-fonts-4.1.0-25.i386.rpm
XFree86-ISO8859-15-75dpi-fonts-4.1.0-25.i386.rpm
XFree86-devel-4.1.0-25.i386.rpm
XFree86-libs-4.1.0-25.i386.rpm
XFree86-tools-4.1.0-25.i386.rpm
XFree86-twm-4.1.0-25.i386.rpm
XFree86-xdm-4.1.0-25.i386.rpm
XFree86-xfs-4.1.0-25.i386.rpm
e2fsprogs-1.26-1.72.i386.rpm
e2fsprogs-devel-1.26-1.72.i386.rpm
gdb-5.1-1.i386.rpm
glibc-2.2.4-24.i686.rpm
glibc-common-2.2.4-24.i386.rpm
glibc-devel-2.2.4-24.i386.rpm
kernel-2.4.9-34.i686.rpm
kernel-headers-2.4.9-34.i386.rpm
kernel-smp-2.4.9-34.i686.rpm -- optional, only needed for multi-processor machines
kernel-source-2.4.9-34.i386.rpm
modutils-2.4.13-0.7.1.i386.rpm
nscd-2.2.4-24.i386.rpm
tar-1.13.25-1.i386.rpm
util-linux-2.11f-17.i386.rpm
pdksh-5.2.14-13.i386.rpm -- needed only for developers' convenience/productivity
Please see Section 5.5 of this document for an explanation of the Motif RPMs.
The following RPMs come with the RedHat 7.2 CD set and must be installed to build the LDV software:
cpp-2.96-98
gcc-2.96-98
gcc-c++-2.96-98
gcc-g77-2.96-98
gcc-objc-2.96-98
libstdc++-2.96-98
libstdc++-devel-2.96-98
ncurses4-5.0-4
libelf-0.7.0-1
Issue 16: Use of STL
Status: this may indeed be a portability issue. For Linux, HP, and
Solaris our use of stl has been okay. However, when we port to VC++
this may be a more significant issue since VC++ has not had good stl
support. We need to investigate this issue more.
11/20/02: The LWG is considering shifting to use STL in SystemC 2.1;
pending their decision, this is not an issue.
12/05/02: closed. The VWG decided that STL is necessary for SCV and
will make a statement to that effect to the LWG.
Issue 17: Naming for the scv kit
Status: the scv kit name for 1.0beta is systemc-2.0-SCV1.0B.
11/20/02: Our configure/install process must be as glitch-free as
SystemC's, and we should install seamlessly into an existing SystemC
installation tree. We should take out example from the master/slave
library. Required for beta 2.
12/02/02: planned for beta 2 release.
Issue 18: CUDD Library
Status: the CUDD library is a standard BDD package. The TestBuilder
team was given the rights to redistribute it as part of an open
source package. The copy righting should be fine for the reference
implementation. Use of the CUDD library is exactly analogous to use
of the quicktrheads library. If bugs are found, they can, and should
be fixed by osci, and contributed back.
11/20/02: Mark G will contact Stan and Kevin so OSCI lawyers can
sniff this.
Issue 19: Naming conventions in introspection code
Status: The request to make all class names lower case and all
macros start with SCV is fine. This was intended early on. I think
these instances were missed. The effected macros and classes are all
internal, so this is a low priority issue, but is simple enough that
it will likely be fixed for the production release.
11/20/02: There are no requirements from the VWG on this pending a
LWG decision on naming conventions.
Associated PCR: 489172
Issue 20: scv namespace
Status: We need to investigate what the ramifications of such a
change would be. The main effect will be in the introspection code,
but it may cause side effects, so we can't do something like this
immediately. The request for using an scv namespace is
reasonable. Is this something that other systemc extensions are
doing? At this point we will commit to investigating, but not commit
to making the change.
11/20/02: The VWG's main concern is that we work with gcc 3.2, which
may have namespace implications.
Associated PCR:489252
Issue 21: SCV Library does not compile on HP due to include of
hash_map.h
Status: This should be fixed now. The hash_map.h file is only
included for gcc 2.95. If the compiler is aCC, then the
_USE_HASH_MAP macro should not be defined in scv_config.h.
12/02/02: fixed in beta 1 release.
Issue 22: Configure script not set up properly for Solaris and HP
Status: What does this mean? There are other issues that address
specific configuration and installation issues which we can
address. Please clarify the issue.
12/02/02: Clarification requested.
Issue 23: configure script uses the wrong C compiler on HP
Status: scv uses the AC_PROG_CC to find the C compiler. This is what
it should do. SystemC manually sets the C compiler to be the C++
compiler. This is not the right thing to do. If the user wants to
use the C++ compiler as the C compiler, then they can set the
environment variable CC to be their C++ compiler. But, in that case,
then need to make sure that flags are set for compiling C programs
with the C++ compiler (different compilers have different behavior
in this regard).
12/02/02: What behavior are you seeing that leads you to believe
that this is a problem? Please clarify.
Issue 24: configure script does not work with relative pathnames
Status: This issue should be fixed. We will look into it, but it may
not be available for the beta release.
Associated PCR: 493377
12/02/02: planned for beta 2 release.
12/08/02: --prefix now handles relative pathnames.
02/23/03: Fixed for beta 2.
Issue 25: Cudd infinite loop warning on HP
Status: We will look into this to see if there is a real issue here or not.
Associated PCR: 493380
12/02/02: This warning has consistently appeared when compiling CUDD
on HP using acc. All of our regressions pass and it does not appear
to affect behavior of the system. We will investigate further to
see if this warning can be eliminated.
Issue 26: "SystemC Verification Extensions" should be renamed to
"SystemC Verification Library"
Status: This makes sense to be consistent with other SystemC library
extensions. This may be a rather extensive document change. It
should be done by the beta 2 release.
Associated PCR: 493382
02/12/03: Fixed in beta 2.
Issue 27: Specify support for gcc 2.95.3 on Linux, not gcc 2.96
Status: Currently, our regression machines are all 2.96. Until our
infrastructure is changed so that regressions are run on 2.95.3, it
would not be valid for us to list this as the tested compiler. It
should work now, but full testing has not been done.
12/02/02: see issue #15.
12/05/02: Even though we have not fully tested SCV with gcc-2.95.3,
our preliminary tests run successfully with the beta 1 kit. For
this reason we will announce preliminary support for gcc-2.95.3 on
Linux.
02/12/03: We now run gcc-2.95.3 as part of our nightly regressions.
There are a few failures, but they all involve software which is not
part of SCV.
Issue 28: Installation location for libraries, docs, etc and uninstall
Status: We need to fix this to be consistent with the core
library. This has been a lower priority because it is not a show
stopper. This is related to issue 10, but is more inclusive.
Associated PCR: 493392
12/02/02: planned for beta 2 release.
02/23/03: Installation locations fixed in beta 2. Uninstall not fixed.
03/06/03: Remaining installation, uninstallation, and make target
issues fixed.
Issue 29: configure.in and Makefile.am still contain variables with tb
Status: We removed most references to tb_ stuff. Internal variables
still have tb* names. We will fix this for the beta 2 release. The
reference to testbuilder is a directory on a server in our
environment where pdf files are stored. We will look at changing the
name of this directory.
Associated PCR: 493398
12/02/02: planned for beta 2 release
02/12/03: fixed in beta 2.
Issue 30: error in documented examples, . used instead of ->
Status: We will go through the document and verify that all examples
compile.
Associated PCR: 493399
12/02/02: Doc error fixed. We have also proofread the spec to
remove any similar errors. The result is only as good as our
proofreading skills -- undetected errors may remain. We will go
through the examples again prior to the beta 2 release to ensure
that all examples work as written.
Issue 31: _LINUX_SOURCE macro is defined in scv_config.h
Status: We will look at changing this for the beta 2 release. Only a
couple of files are affected.
Associated PCR: 493401
12/05/02: planned for beta 2 release.
02/12/03: fixed in beta 2.
Issue 32: Add scv_extensions specialization for sc non-templated base
types
Status: This is definitely something that should be done. It may,
however, not be done until early next year.
Associated PCR: 493406
12/02/02: A desireable enhancement. It's been added to our
enhancement queue, but as yet unscheduled.
12/05/02: Required for production release. This enhancement is
potentially non-trivial. This requirement may delay the production
release.
02/23/03: Fixed in beta 2.
Issue 33: Files missing in installed examples
Status: An oversight that can be easily fixed.
Associated PCR: 493407
12/02/02: Fixed in beta 1 release
Issue 34: Constrained random generation on arrays
Status: This is actually a general introspection issue that needs to
be investigated. It is likely a documentation issue. For what the
user is attempting to do in the example, he should be using:
scv_smart_ptr<int> arr[2];
The example in the spec is incorrect in this usage, and has been
changed to reflect the correct way to get the desired behavior.
It may be possible to have scv_smart_ptr handle array types. We need
to look into that. If it is not possible, then we will document this
limitation.
Associated PCR: 493506
12/02/02: This feature is not supported and the release notes will
reflect this fact. The VWG needs to take up the issue to decide
whether this feature should be part of the standard or not. We will
investigate to determine if adding support for smart pointers to
arrays is feasible.
12/05/02: A workaround exists. You can wrap a class around the
array to get the desired behavior. Workaround to be documented in
release notes.
Issue 35: Constrained random generation with unsatisfiable constraint
Status: The current behavior is correct. The semantics of the
scv_constraint_base class is that SCV_CONSTRAINTs have a conjunction
behavior. That means, if any one constraint cannot be satisfied, all
constraints cannot be satisfied. The user has many choices here:
1. they can use a soft constraint
2. they can use hierarchical constraints
3. they can make individual constraints since the constraints are
not dependent on each other.
12/02/02: Section 5.3, page 38 of the SCV spec says:
The expressions in the series of SCV_CONSTRAINT macros within the
constructor are merged into a single expression using the
conjunction operator, &&, and stored in a static variable
corresponding to the class. Using the traditional semantic for a
conjunction, the resulting behavior is independent of the order
from which the series of SCV_CONSTRAINT macros are
declared. Because the constraint information is stored in a static
variable for this class, it is processed only once. The
expressions in the macros must use operator()() on the member
smart pointers of the constraint class to relate the constraints
to the underlying data objects referred by the member smart
pointers. It is an error to assign a different data object to the
smart pointer member variable of the constraint class. If a random
value is needed for an existing smart pointer, you should call
next() on the constraint and then copy the resulting value to the
existing smart pointer.
12/05/02: Hierarchical constraints (workaround #2) will not solve
the problem. We recommend that the user split apart constraints
into seperate classe to avoid unncessary interactions. We will
update the spec in the beta 1 release to clarify the behavior when
constraints cannot be satisfied.
12/08/01: Section 5.3 of the SCV spec now includes this text:
The constraints specified by the macro SCV_CONSTRAINT are hard
constraints; if the constraint solver cannot find a legal value that
satisfies these hard constraints, an error is reported. Soft
constraints can also be specified using the macro SCV_SOFT_CONSTRAINT.
If the constraint solver cannot find a legal value that satisfies both
soft and hard constraints, a warning is reported, and the solver will
generate a value with respect to the hard constraints only, while
ignoring the soft constraints. If the constraint solver still cannot
find a legal value (ignoring the soft constraints), an error is
reported, and the solver will generate a value while ignoring all
constraints.
Because all constraints in a constraint class are ignored if a single
(hard) constraint cannot be satisfied, it may be advisable to keep
unrelated constraints in separate classes. Smaller constraint classes
may make it easier to determine why a set of constraints cannot be
satisfied.
Issue 36: Float type not supported in constrained randomization
Status: this limitation will be documented in the RELEASENOTES with
an appropriate work around.
12/02/02: The API as documented allows for constraints to be applied
to floating point numbers. The reference implementation does not
support this feature. We can add it to our enhancement queue if the
VWG so requires.
12/05/02: The VWG discussed three options:
1. leave spec as is; allow alternate implementations to support
this feature.
2. Change the spec to reflect that constraints on floating point
variables is not supported.
3. Propose a modified API for supporting constraints on floating
point variables.
The final agreement is to document that floating point numbers are
not supported (option 2). In the future, should a proposal be
written by someone for a modification of the API to support
constraints on floating point variables we will seriously consider
it.
12/08/02: Section 5.3 of the VWG spec now includes this statement:
The standard does not require support of constraints on floats or
doubles.
Issue 37: Multiply operation on constraint hangs the process forever
Status: it is well documented that some types of constraints will
cause the constraint solver to take a long time. Specifically, doing
multiplication over a certain number of bits is slow. Since a
timeout was not specified as part of the SCV standard, it is
possible to effectively hang a process using these types of
constraints. As this is already documented, there is not much else
that can be done. It is possible to add a timeout mechanism if the
SCV committee chooses to do so.
12/02/02: The release notes for the beta 1 release are updated to
reflect practical limitation in the size of numbers that can be used
in a multiply constraint.
Issue 38: scv_smart_prt<T> does not compile with fixed-point data
types
Status: fixed-point types do not currently have an scv_extensions<>
implementation which is why scv_smart_ptr<> can not use them. This
limitation should be documented. We will check the documentation to
ensure this.
Associated PCR: 493510
12/02/02: in enhancement queue, as yet unscheduled
12/05/02: required for production release. See also issue 40.
04/30/03: We would like to defer this until after the production
release.
Issue 39: Compile error due to SC_INCLUDE_FX
Status: defining SC_INCLUDE_FX causes the compile error (it occurs
on all platforms). We will investigate the cause of this. The
majority of our regressions to not turn on the fixed point support
which is why this issue would not be caught in our current
regressions.
Associated PCR: 493425
12/02/02: under investigation
12/05/02: planned for beta 2 release.
02/12/03: fixed for beta 2.
Issue 40: full integration of fixed point data type.
Status: As we looked closely at the resolution for issue 38 we
realized that inclusion in scv_expressions and randomization will be
required. We've split this out as a separate issue to distinguish
from wrapping the fixed point class with scv_extensions. This work
represents a substantial effort and we should determine (separately
from issue 38) whether or not this should be in the production
release.
Issue 41: inheritance among scv_extensions_base<> classes.
Status: We do not currently support deriving one
scv_extensions_base<> class from another scv_extensions_base<>
class. An extended class must contain all of the objects in the
class hierarchy for the type that is being extended. Planned for
beta 2 release.
Associated PCR: 493829
02/12/03: I don't think I can fix this for beta 2.
02/23/03: Fixed for beta 2.
Issue 42: compile fails on some Solaris boxes
Status: We've added a note in INSTALL suggesting trying
--disable-opt on the configure line. For beta 2, we'll
detect Solaris boxes and change the optimization level
accordingly.
02/12/03: done
Issue 43: bug in data_structures/scv_sparse_array example
Status: We've added a note in INSTALL suggesting a quick
and dirty fix for the example. We'll fix the source code
for the example for beta 2.
02/12/03: Example fixed, note removed from INSTALL, in
beta 2.
Issue 44: unapproved changes in SCV specification
Status: during preparations for SCV beta 2 we made
several changes to the SCV specification, as a result
of consultation with the VWG and with implementors of
SystemC 2.1. Our released implementation is based on
this updated spec, which has not yet been approved by
the VWG. I sent it to the updated version (vwg_1_0c)
as doc and pdf to systemc-verif-wg@server2.systemc.org.
Perhaps the list server wasn't working.
Issue 45: discrepancy between scv_report specification and implementation
Status: Until recently, Cadence's extensions to SCV had relied
on an undocumented callback hook in our implementation of SCV.
I have removed this dependency, but will not remove the
callback hook in our upcoming release (to allow users time to
switch to the new version of our extensions). I will remove
the callback hook from SCV in the following release.
Issue 46: SCV does not produce a log file
Status: The scv_report facility in SCV beta 2 does not create
a log file, even if the user supplies a name for one. This is
fixed in our current codebase. Note: There is no default log
file name: SCV will create a log file only if the user specifies
a log file name.
See more files for this project here