Subject: Re: [sv-cc] DirectC C side pdf - comments & explanations
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Thu Feb 20 2003 - 11:23:42 PST
> Please find my detailed review of the C side LRM draft.
> There are two PDF documents attached. The first is a
> version of the original PDF with yellow "Post-It" notes.
> The second is a summary of all the notes.
> Doug
Doug,
Thank you very much for your diligient proofreading and your
corrections and improvements.
A few issues need explanation.
### Page 1 Sequence number 5
Why "packed arrays and System Verilog arrays"?
Because the arrays from two domains are referred here:
- C data structures for the canonical representation of packed arrays
(structures allocated by the user in her/his C code)
- all types of arrays used on SystemVerilog side (packed or unpacked,
C-compatible or Verilogish), allocated by SV compiler and passed to C.
### Page 1 Sequence number 6
I assumed that the reader of "C Layer Annex" is familiar with the concepts of
external and exported functions. But the explanation will not hurt.
### Page 2 Sequence number 1
sv_CANONICAL_SIZE or SV_CANONICAL_SIZE?
Two conflicting requirements: every name should start with sv_ (see 1.2)
and macros are preferably all-upper-case. Team?
### Page 3 Sequence number 1
I guess I got too attached to the acronym WYSIWYG :-)
I wanted to emphasize that there will be no coersion or changes whatsover
to the formal arguments of an external function.
For native SV functions, compiler optimizations may transparently change the formal arguments and the function's code because of compiler pragmas or command
line switches like +2state in VCS, or, due to optimizations like scalarization,
vectorization, etc. a single SV function may got split into different
specialized versions with changed types of formal arguments.
In the case of open array, the type of formal argument is only partly
defined by the external declaration, se we may not state that "formal argument
types are =completely= governed by extern function declaration".
As far as exported functions are concerned, I think that the emphasis
on WYSIWYG principle is even more important. And this paragraph does apply
to exported functions! (I don't dare to claim it's well written or clear!)
SV code of an exported function expects the types of arguments to be exactly
as declared. This must be guaranteed by the caller. Note, however, that
C compiler can provide coersion only for C types, but not for SV types!
So, if the user passes 10-bit array to SV, when 40-bit array is expected,
the error will not be corrected by C compiler, although if the same happened
in SV, the SV compiler would handle it correctly and provide coersion and
a temp.
### Page 4 Sequence number 3
"read or write anything" is deliberately vague and broad in meaning.
This includes i/o, environment, variables/objects from operating system
or from the program or other processes (threads, shared memory, sockets, etc.,
etc), you name it ...
Maybe we should be more descriptive/verbose?
### Page 5 Sequence number 4
I wondered whether the whole section 1.6.3 "Data representation" be better
split into two?
It's meant for two kinds of audience:
- for vendors: what are the new restrictions imposed on the implementation
and added by C Layer of DirectC; info about 'byte' or 'int' is redundant
for them
- for users: what is the representation of data. They don't care what has
been already specified by SV and what is added by C Layer of DirectC.
They are not even required to read SV LRM! For them "C Layer Annex" shall
be selfcontained and a complete source of information.
The two sets of information partly overlap. I had a similar discussion with Joe.
### Page 7 Sequence number 1
No, [31:0] is not in a normalized form for the unpacked part.
Two-dimensional example may look like:
in SV: logic [2:3][1:3][2:0] b [1:10][31:0]
normalized: logic [17:0] b [0:9][0:31]
BTW, I have no clue what is SV semantics for slices and acsending/descending
indices. Consider the following slices of unpacked array: A[2:3]=A[5:4];
A[2]<--A[5], A[3]<--A[4] or A[2]<--A[4], A[3]<--A[5] ?
### Page 8 Sequence number 1
1) Not really.
If a C function dynamically allocates the data structure for simulator
representation of a packed array, it does not need svc_src.h.
For your convenience I'm enclosing an example sent on Feb. 6
"Subject: [sv-cc] Re: Calling SV from C"
------------------
SV:
export a.b.c.myfunc;
...
function void myfunc (output logic [31:0] r); ...
...
C:
#include "svc.h"
extern void myfunc (svLogicPackedArrRef r); /* exported from SV */
/* output logic packed 32-bits */
solution 1, dynamic allocation:
...
svLogicVec32 my_r[sv_CANONICAL_SIZE(32)]; /* my array, canonical representation */
/* allocate memory for logic packed 32-bits in simulator's representation */
svLogicPackedArrRef r =
(svLogicPackedArrRef)malloc(svSizeOfLogicPackedArr(32));
myfunc(r);
/* canonical <-- actual */
svGetLogicVec32(my_r, r, 32);
/* will use only the canonical representation from now on */
free(r); /* don't need any more */
...
------------------
Should this example make into LRM?
### Page 11 Sequence number 2
"VCS" or "a System Verilog simulator"?
"a SV simulator" will be better, although I really did mean VCS.
VCS uses {c,d} fields as in svLogicVec32, instead of legacy {bval,aval}.
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Thu Feb 20 2003 - 11:24:42 PST