Re: Structure of new P1666 standard

JEITA's position is as follows:

1. Before starting discussion, we’d like to make clear what TLM-1 is.
   - Section 10 in the LRM?
   - The following libraries in TLM-2.0.1:
     tlm_1_interfaces, tlm_adapters, tlm_ports, and so on.

2. We adopt option C.
   We’d like to discuss what should be included and what should not be
   included.
   Included: core interfaces, tlm_fifo, tlm_fifo_if.
   Not included: tlm_transport_if, analysis port.
   What TLM-2 can cover should not be included.

Other comment:
  In LRM, the definition of TLM-2 and TLM-1 should be clear.

Hiroshi Imai, Chair of JEITA SystemC WG

On Wed, 17 Feb 2010 14:20:40 +0000
john.aynsley@doulos.com wrote:

> Hello Everybody,
>
> You will find below what the contents of the revised P1666 standard would
> look like if we put the existing SystemC and TLM-2.0 LRMs back-to-back.
>
> There will need to be some changes to the TLM-2.0 sections to meet IEEE
> guidelines and for consistency with the old 1666 std. The only major issue
> I see is that the TLM-1 / analysis port content will not be adequate as
> they stand. In my opinion, it either needs to be expanded and refined, or
> removed entirely. Perhaps this is where we should start the technical
> discussions, since it is one of the more substantive issues.
>
> So, first question: Do we want to
>
> A. Remove all mention of TLM-1 and analysis ports?
>
> B. Include a full, detailed description of all aspects of TLM-1 and
> analysis ports as they was originally released in the TLM 1.0 standard?
>
> C. Something in between? In that case, I would propose we include only
> the TLM-1 core interfaces, including analysis ports, together with some
> definition of their minimal semantics (i.e. what blocking and non-blocking
> mean, whether you are allowed to modify the method arguments, transaction
> object lifetimes, and so forth). This would require some technical work to
> pin down what the "minimal semantics" actually are.
>
> Opinions, anyone?
>
>
> OVERVIEW
>
> REFERENCES
>
> Terminology and conventions used in this standard
>
> SystemC (from existing 1666-2005)
> Elaboration and simulation semantics
> Core language class definitions
> Predefined channel class definitions
> Data types
> Utility class definitions
>
> TLM-2.0 (from existing OSCI LRM)
> INTRODUCTION
> TLM-2.0 CORE INTERFACES
> GLOBAL QUANTUM
> COMBINED INTERFACES AND SOCKETS
> GENERIC PAYLOAD
> BASE PROTOCOL AND PHASES
> UTILITIES
> TLM-1 AND ANALYSIS PORTS
> TLM-1 core interfaces
> TLM-1 fifo interfaces
> tlm_fifo
> Analysis interface and analysis ports
>
> Annex A (informative) Introduction to SystemC
> Annex B (informative) Glossary
> Annex C (informative) Deprecated features
> Annex D (informative) Changes between the different SystemC versions
> Annex E (informative) Other stuff ....
>
> INDEX
>
>
>
> I will include my full email signature once for the record ;-)
>
> --
> John Aynsley
> CTO
>
> Doulos - Developing Design Know-how
> VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
> Services
>
> Doulos. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
> Tel: + 44 (0)1425 471223 (Ext 247) Email: john.aynsley@doulos.com
> Cell: +44 (0)7798 837065
> Fax: +44 (0)1425 471573 http://www.doulos.com
>
> --------------------------------------------------------------------------------
> Doulos Ltd is registered in England and Wales with company no. 3723454
> Its registered office is 4 Brackley Close, Bournemouth International
> Airport,
> Christchurch, BH23 6SE, UK.
>
> This message (and associated files) may contain information that is
> confidential,
> proprietary, privileged, or subject to copyright. It is intended solely
> for the use
> of the individual to whom it is addressed and others authorised to receive
> it. If
> you have received this email in error, please notify the sender and delete
> all
> copies. This message may contain personal views which are not the views of
> Doulos, unless specifically stated.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.