Re: [sv-bc] Opinion on merging of P1364 and P1800

Cliff's opinions on merged documents.

At 05:40 PM 1/27/2006, Karen Pieper wrote:
>Hi, all,
>
>In the P1800 meeting last week, the Working Group asked for each of 
>the SV-* committees to provide an opinion on whether or not to merge 
>the P1364 and the P1800 LRMs into one LRM.  They are interested in 
>your opinions on:
>
>1)  How much time will it take us to merge the relevant parts of the LRM

I believe Stu's assessment is correct. I also agree that if funding 
could be put in place, Stu could make this happen ASAP. When Stu is 
editing, he does not participate as much on the subcommittee 
conference calls as much and does not make as many proposals, so Stu 
could also do much of his work in parallel with subcommittee work.

This is my assessment of the merging task

Key: SV - SystemVerilog IEEE1800
           VL - Verilog - IEEE1364

Cliff's opinion of merging difficulty is shown at the end of each line

IMO - Sections that need merging:
VL- 3. Lexical conventions (semi-easy)
SV - 3. Literal values (semi-easy)
SV & VL - 4. Data types (semi-difficult)
SV - 5. Arrays (semi-difficult)
VL - 5. Expressions (semi-difficult)
SV - 6. Data declarations (semi-difficult)
VL - 6. Assignments (semi-easy)
SV - 8. Operators and expressions (semi-difficult)
SV - 9. Scheduling semantics (semi-difficult - due to simultaneous clean-up)
VL - 11. Scheduling semantics (semi-difficult - due to simultaneous clean-up)
SV - 10. Procedural statements and control flow (semi-difficult)
SV - 11. Processes (semi-difficult)
SV - 12. Tasks and functions (semi-easy)
VL - 10. Tasks and functions (semi-easy)
SV - 19. Hierarchy (semi-easy)
VL - 12. Hierarchical structures (semi-easy)
SV - 22. System tasks and system functions (semi-easy)
VL - 17. System tasks and functions (semi-easy)
SV - 23. Compiler directives (semi-easy)
VL - 19. Compiler directives (semi-easy)
SV - 24. Value change dump (VCD) data (semi-hard??)
SV - 18. Value change dump (VCD) files (semi-hard??)
SV - 27. SystemVerilog VPI object model  (???)
SV - Index
VL- Index

Sections that are just copied over:
SV - 7. Classes
VL - 7. Gate and switch level modeling
VL - 8. User-defined primitives (UDPs)
VL - 9. Behavioral modeling
SV - 13. Random constraints
SV - 14. Interprocess synchronization and communication
SV - 15. Clocking blocks
SV - 16. Program block
SV - 17. Assertions
SV - 18. Coverage
SV - 20. Interfaces
SV - 21. Configuration libraries (copied from IEEE1364)
VL - 13. Configuring the contents of a design
VL - 14. Specify blocks
VL - 15. Timing checks
VL - 16. Backannotation using the Standard Delay Format (SDF)
SV - 25. Deprecated constructs
SV - 26. Direct programming interface (DPI)
SV - 28. SystemVerilog assertion API
SV - 29. SystemVerilog code coverage control and API
SV - 30. SystemVerilog data read API
SV - Annex A - BNF (already combined??)
VL - Annex A - Formal syntax definition (already combined??)
SV - Annex B - Keywords (already combined??)
VL- Annex B - Keywords (already combined??)
SV - Annex C - Standard Package
VL - Annex C - System tasks and functions
SV - Annex D - Linked Lists
VL - Annex D - Compiler directives
SV - Annex E - Formal semantics of concurrent assertions
SV - Annex F - DPI C layer
SV - Annex G - Include file svdpi.h
SV - Annex H - Inclusion of foreign language code
VL - Annex H - Encryption/decryption flow
SV - Annex J - Glossary
SV - Annex K - Bibliography (already combined??)
VL - Annex I - Bibliography (already combined??)

Just copy over -OR- Separate document(??)
VL - 20. PLI overview
VL - 21. PLI TF and ACC interface mechanism (deprecated)
VL - 22. Using ACC routines (deprecated)
VL - 23. ACC routine definitions (deprecated)
VL - 24. Using TF routines (deprecated)
VL - 25. TF routine definitions (deprecated)
VL - 26. Using VPI routines
VL - 27. VPI routine definitions
VL - 28. Protected envelopes
VL - Annex E - acc_user.h (deprecated)
VL - Annex F - veriuser.h (deprecated)
VL - Annex G - vpi_user.h
SV - Annex I - sv_vpi_user.h

I think this is doable right now and will save us time later because 
we will only have to consider and modify one document.

>2)  When you recommend merging the LRM (now, toward the end of the 
>current 2 year revision cycle, next LRM, never)...

I really think we actually save time and work if we do this now.

Compared to an actual design I work on some years back, we took a 
2-week hit to re-partition a design and on the back-end pulled the 
project schedule in by the two weeks we lost up front. This was 
because the re-partitioning simplified the final verification of the 
project. I see this as being very similar in nature.

A merged document saves us from double-reading to make sure the 
contents are accurate in both places.

>3)  Any other questions or comments that the committees recommend 
>the study group consider in their decision to develop the next PAR.

Separation of the PLI/VPI into a separate document.

>Committee chairs, I would appreciate it if you would develop a 
>response reflective of your committee's opinion and forward it to me 
>after your next committee meeting, preferably no later than the 15th 
>of February.
>
>Thank you,
>
>Karen Pieper

Regards - Cliff


----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training