RE: [P1800] Draft PAR for initial discussion in December 10, 2009 P1800 Meeting

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Tue Nov 24 2009 - 07:17:41 PST
Hi, some comments:

Please note that the IEEE now requires that what we do be an exact match for what we write in the scope section.
[SB] This is true,  but it is possible to request a revision of the PAR if there is a need to change the scope. It may be unavoidable, and we should not be afraid of it.

5.2 Scope: SystemVerilog 1800 is a Unified Hardware Design, Specification and Verification language; it was approved by the IEEE-SASB in November 2009. This standard creates a new revision of the SystemVerilog 1800 IEEE standard, which includes errata resolutions, clarifications, and enhancements for hardware design and verification, including testbench, checkers, assertions, and coverage.
[SB] It seems strange to say "hardware design and verification", and then make a more detailed list that only includes verification. Regardless, I would be happy with a very general, flexible, open-ended scope like this. Then the specifics can be decided internally.
SystemVerilog 1800 was developed to enable the use of a unified language for abstract and detailed specification of the design, specification of assertions, coverage, and testbench verification that is based on manual or automatic methodologies. It also offers Application Programming Interfaces (API's) for coverage and assertions, a vendor independent API to access proprietary waveform file formats, and a direct programming interface to access proprietary functionality.
[SB] We don't have this API for 'proprietary waveform file formats'.
The scope of this PAR covers portions of the scope of previous PARs submitted by IEEE CS DASC. The existing PARs are: 1076b, 1647, 1666, and 1364.
[SB] Probably need to list 1850 also.   But what is meant by "existing PARs"? If it means only PARs that are currently in force, then we need neither 1364 nor 1850.

 *   Do we need to add 1735 Design Intellectual Property (IP) Encryption and Rights Management?
[SB] Probably
 *   1801 UPF?
[SB] Not currently. But we should consider working on a way to integrate it into SV. I don't think the current situation where SV and UPF are completely separate is healthy.


Shalom
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Nov 24 07:21:40 2009

This archive was generated by hypermail 2.1.8 : Tue Nov 24 2009 - 07:21:50 PST