Re: Structure of new P1666 standard

Hello,

STARC's position of the structure of new P1666 is to adopt option
C, somewhere between A and B.
For example, many people still uses TLM-1 eg. for cycle accurate
modeling but it is not in the TLM-2's scope.

Also we agree with JEITA's opinion to make it clear what TLM-1 is.

Regards,

-- 
Kaz Yoshinaga
Tel: +81-45-478-3228
email: yoshi@starc.or.jp
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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.