Re: Structure of new P1666 standard

ST's position is of course to include TLM-1 in the new standard, so we
will also push for option B to be adopted.

It would not be consistent to omit something that has been recognized as
OSCI Standard and that is used by several
official participants (as well as many standard OSCI users in the
world), and that allows to address issues now covered
by pure TLM-2 (sideband signals, interrupts, etc.).

A possible solution to confusion concerns raised here could be to add a
small section explaining the complimentary nature
of TLM-2 and TLM-1.

Jerome

On 2/17/2010 3:20 PM, 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 <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* <http://www.mailscanner.info/>, and is
> believed to be clean.

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