Accellera SV Committee Requests to SV-EC
Status: Received, Accepted, Delayed, Returned, Closed (solution accepted by generating committee)
ID	From	Description	Details	Extension ID	Status
TRN-1	SV-AC	Random Constraints	Provide random constraints	EXT-2	Accepted, Closed
TRN-2	SV-BC	Type use before definition	It forces type checking to be post-elaboration; causes unnecessary complication of analysis, particularly separate analysis; useful only with pointer types. It was claimed that this is required for the testbench donation / sv-ec. We had equal votes on whether to take it out or leave it alone. Therefore, I got the AR to check w/ you as to why EC needs it.	NA	Returned, Closed
			RESULT: A response was sent outlining its need for Class cross referencing and we returned the item to SV-BC.
TRN-3	SV-BC	Scheduling Interface	See Requirements on EXT-4	EXT-4	Delayed, Closed
TRN-4	SV-BC	Interface Usage	See Requirements on EXT-5	EXT-5	Delayed, Closed
TRN-5	SV-BC	Modports	See Requirements on EXT-6	EXT-6	Delayed, Closed
TRN-6	SV-BC	Pass by reference	Required for efficiency of passing structures and arrays	EXT-1	Accepted, Closed
TRN-7	SV-BC	Data layout	The request was for determining if packed arrays can accept reals (and other non-integral types – strings, events, classes, etc…). SV-EC needs to consider and respond.	NA	Accepted, Closed with no support for packed arrays of reals.
TRN-8	SV-CC	Handles	Link to requirements	EXT-18	Accepted, Closed
TRN-9	SV-CC	Strings	Requirements are:	NA	Returned, Closed
			1. to be able to pass string arguments to SV (DirectC) funtions and as the return of SV (Direct C) functions. Note: DIrectC function arguments can be input, output, or inout.
			2. across the SV<-> C boundary, SV strings are to be represented as char * pointers (plain C strings). NOTES: memory owned by SV strings cannot be modified by C; memory owned by C strings cannot be modified by SV (ie requires semantic equivalent of copy in/copy out)
			RESULT: The currently defined string class can be used for this with the exception that the specification of UTF-16 unicode support in 3.0 violates the requirement for supporting the string as char * pointers (plain C strings). This has been past to the SV-BC committee to resolve (along with other related issues) and returned to SV-CC. SV-BC and SV-CC recommend deprecation.
TRN-10	SV-CC	External functions/tasks	Link to requirements	EXT-20	Accepted, Closed
ID	To	Description	Details	Date	Status
TRN-1S	SV-BC, SV-CC	Unicode	Unicode causes problems in C Interface	12/16/2002	Closed
TRN-2S	SV-BC	Casts	Static cast vs. dynamic cast vs. strong typing	1/7/2003	Closed
TRN-3S	SV-BC	Slice usage	Use of slice with all unpacked data array types. See last example of Section 4.7.	1/13/2003	Closed Resolved in SB-BC58