Subject: [sv-cc] Meeting minutes 4/2/03
From: Francoise Martinolle (fm@cadence.com)
Date: Thu Apr 03 2003 - 09:41:18 PST
Last meeting minutes:
Joao proposed, Doug seconds, Passed
Attendees:
Swapnajit
Joao
Andzej
john Stickley
John Amouroux
Kevin
Michael
Ghassan
Bassam
Doug
Francoise
Swapnajit gave an update pn the lrm status:
Submitted sv-cc sections for draft 4 on Friday last week
Draft 4 delayed for a few days due to SV-ac work;
Then review lasts 2 weeks
Andrezj:
some clarifications on the data types supported by DPI
more serious issue: dramatic change in wordings (all types are supported) to
all supported types are:
Francoise: these are just clarifications
Andrzej: no other changes; not any SV function can be replaced or called
from DPI
Andrzej: send out a new update containing the exact subset of the supported
types.
Swapnajit: Joao to make the edit changes and be the editor person
Main agenda:
John Stickley and Andrzej : John not happy about the output arguments:
main reason
use the interface akwardly input vectors canonically by value=> much simpler
HW modules may be the older RTL coding style (bit vectors), they are
not using structs, int, longint etc...
for these users, we need the best way to exchange bit vectors in any size.
John's example is not using new SV, for old users, we still need to have
efficient support
Joao: interface between 2 types domain, choice where the type conversion is
done
hard work can be on the C side or on the SV side.
All the boundery stuff is done in Verilog
John:
Output bitvectors should be supported in the easiest way: most efficient.
That is not the
way we have it now. Let's not support output bit_vectors.
Andrzej:
They should use the new data types for output arguments on the Verilog
side:an int,
byte.
only for small input and output arguments: pass the canonical format
Michael : why not return an int?
Another issue: We need a solution for 64 bit vectors
John: Symmetry of input and output is important
John: bit_vectors, the most efficient is canonical format.
Andrzej: C native types are the easiest
What the pointer points to is a canonical representation
Vectors are always pass by reference only small vectors are not.
packed array always passed by reference regardless of direction
Andrzej: wants to preserve the internal representation for output
arguments, which is the
reason for passing a ref to packed representaiton
Michael: what is the rule for finding what is a small vector (bit_vector< 32)
Andrzej: inout arguments may be important to have symmetry
Joao: verilog users don't have bit_vectors, this issue is very unlilkely to
occur
Andrezj: directC has bit_vectors, though
Joao: small bit_vector as an output vector is very unlikely
John: in the rare way you use it, do it the most efficient and the easiest
Andrzej: inout argument: pointers to sim representation
compiler will have to create a temporary in canonical
representation
and perform a conversion to sim representation -> less performant
john: I gave up. lets just leave it the way it is
joao: yes, that is not important enough
Swap:
michael brought up the question about 64 bits
Are we supporting 64 bits vector as return values
Andrzej yes but as types longint (64 bits)
cannot convert a canonical value to a longint.
Andrzej: This may be inconsistently stated in the LRM: I may have modified
in one layer but not in the other one.
Swapnajit: any other modifications to the LRM?
Joao: syntax changes in SV AC, minor names changes in the assertion
Andrezj: minor issue with open arrays and dynamic arrays
Joao: Whether [] means an open or a dynamic array depends on the context
Joao: technically what is the difference?
they are the same!
Doug: yes, this is not an issue, open in the context of DPI, dynamic in the
other context.
Joao: review the dynamic versus open arrays in functions while reviewing
draft 3
Open arrays in import declarations, named function proto have been extended
to open arrays
Andrzej: technical issue with passing a dynamic array (of not known size)
Joao: look at section 4.8 Arrays as arguments, it says that associative and
dynamic arrays
are transformed to normal arrays when passed as an actual argument
Francoise: we can support all types of arrays, then in DPI
Joao; section 10.6 doe snot have any restriction on the types of formal
arguments to functions
Joao: let 's review the draft 4 and decide if we have an issue with open
and dynamic arrays
okay
Meeting ajourned.
This archive was generated by hypermail 2b28 : Thu Apr 03 2003 - 09:41:54 PST