Subject: RE: [sv-cc] DirectC C side pdf - comments & explanations
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Feb 20 2003 - 22:46:25 PST
Hi Andrzej,
Thanks for the feedback.
Some further discussion is embedded.
Looks like Joe will have himself some fun :)
Regards,
Doug
>
> ### 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.
DOUG: Sounds reasonable. I think we should clarify the text
to state your meaning here. The way it reads right now it's
like saying "apples and fruits" instead of "apples and oranges".
(Since a packed array ISA SystemVerilog array) Joe can you please
make the text more verbose to indicate Andrzej's explicit meaning
above?
>
>
> ### 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.
DOUG: Yes this should be clearly stated. But, there are coercions
made by the compiler to adapt mismatched actual argument types to
the declared formal argument types. It might be helpful to
envision external function arguments in 3 layers:
SV actuals on top of
SV formals on top of
C formals
In a certain way, SV external function declarations really are
prototypes that stand in for C functions. I will be interested
to see if we can start using SV-EC's prototype syntax for our
external function declarations. I think that might be a more
appropriate choice in the language design.
>
> 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.
DOUG: Absolutely agree with all of the above.
Can you and Joe work these points into the text?
Some of them already are in the text, but scattered
around a little bit.
>
>
>
> ### 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?
DOUG: Yes.
>
>
> ### 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.
DOUG: No strong opinion on this.
I felt like things were structured pretty well as it was,
with only minor clarifications needed. If you guys want
to restructure, I would be happy to read it over and see
how it turned out.
>
>
> ### 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] ?
DOUG: I don't know anyone on SV-BC to ask.
Could you or Joao check into this?
>
>
>
> ### 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?
DOUG: I think it should. But the intent of the example (special case
way to avoid dependency on svc_src.h) should be made clear so that
people understand why the example is in the 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
>
Regards,
Doug
This archive was generated by hypermail 2b28 : Thu Feb 20 2003 - 22:47:01 PST