Subject: Re: $sv-ec Forwarded Message from ["David Smith"
Vassilios.Gerousis@Infineon.Com wrote:
>Greetings,
>4. Process Control - Existing process control is based upon implementation in System Verilog and Vera. Suggestions for improvement have been based upon other languages but no implementation with Verilog or SystemVerilog.
>5. Data Channels - Discussion has been based on requirements and proposals taken from other languages but no implementation with Verilog or SystemVerilog.
Limiting new functionality to what EDA vendors have supplied in
>I believe we have to raise the bar on our proposals. If there is no existing implementation of the proposal relative to Verilog or SystemVerilog then I believe we cannot make any further progress on the proposal. One reason for this is that we are running out of time for the 3.1 LRM and need to make sure that we complete work on the SVT (SystemVerilog Testbench), the Random Constraints (as required by SV-AC),References (as required by SV-CC), and aliases (since we have completedvoting on it) and getting all of this in the LRM.
If we are pushed for time I would rather defer functionality completely
Considering how much stuff was donated after 3.0 it seems unlikely to me
Kev.
This archive was generated by hypermail 2b28
: Wed Nov 13 2002 - 10:27:36 PST
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Nov 13 2002 - 10:26:51 PST
>I have posted a new document up on the SV-EC website at http://www.eda.org/sv-ec/SVTestbench.pdf . This document is the current state of the effort to merge the Testbench Donation and Clarification documents into a single document, clean-up (remove extraneous material and re-organize for clarity), and incorporate some of the results of the committees work on reviewing the open issues.
>
>The current plan is to:
> 1.. map each of the sections into the 3.1 LRM
> 2.. merge the information into the 3.1 LRM
> 3.. review the sections, as available, within the committee and amend as required (this can include removal if so voted)
> 4.. update the BNF to include the new information (after all otherreview is complete)
> 5.. vote on the completed LRM to be passed to the full SV organization Stu Sutherland, Mehdi Mohtashemi, and Arturo Salz are currently working on the details of this effort but the milestones we are working to meet are:
> 1.. December 15th for complete integration into 3.1 LRM
> 2.. December 31st integration of all extensions in 3.1 LRM
> 3.. January 15th, 2003 complete review of 3.1 LRM
> 4.. (continue work on integration of other sections into the 3.1 LRM -SV-CC, SV-AC, SV-BC)
> 5.. February 24th, 2003 complete 3.1 LRM (complete at DEVCON)
> 6.. May 1, 2003 SV 3.1 sent to Accellera board
> 7.. June 1, 2003 SV 3.1 standard complete
>
>I would like to focus any detailed discussion using the LRM as it becomes available. Please take a look at the new document on the site to see if there are any significant new issues that are raised.
>
>I would also like to clarify some confusion that may exist around the state of the other extensions for 3.1. The guidelines from Vassilios for proposals are that they should be based on existing implementations. We have clearly not followed this for some of the items that we have been discussing. I think that this has caused us to spend more time than wehave in discussing ideas that have a real requirement but do not have a well-defined solution. This results in us having to go through the process of creating a solution - clearly not the spirit behind the Accellera standardization effort. Based on the original guidelines from Vassilios I would like to review the outstanding extensions:
>
>1. References - based on implementation from Vera with Verilog as described in the Testbench donation
>
>2. Random constraints - waiting for donation from Synopsys based on implemenation from Vera with Verilog
>
>3. Alias - based on creation work within committee - this is a relatively small extension that has taken some time to get complete
>
It was partly a replacement for jumpered ports in Verilog which didn't
work well with newer port syntax.
>
>
The process control proposal is there because SV 3.0 is deficient with
respect to what programmers in C/C++ expect - i.e. the
proposed functionality has already been implemented in Unix and other OS
environments.
>
An implementation for data channels currently exists in proprietary
tools used at National, and it overlaps with the Vera "mailbox"
functionality.
commercial tools doesn't seem reasonable to me. I believe ".*"
previously existed only in proprietery Intel tools. Similarly anything
already in the C,C++ and Java standards seems like fair game - a lot of
SV is just chunks of C functionality, and the Vera class implementation
appears to be based on Java.
>
>I welcome your thoughts and/or reactions to this.
>
>
>Regards
>David W. Smith
>
than provide a half-baked solution, e.g. defer "Data Channels"
and "Mailboxes" to 3.2, maybe "References" too, and concentrate on
"Process Control" and other incomplete items.
that we can incorporate it all into a clean LRM in less
than several months (at the current rate of progress), and if it isn't
clean it won't get through the IEEE process quickly.
--
National Semiconductor, Tel: (408) 721 3251
2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090