Re: TLM extensions - status

Mac,

For better or worse, I think the historical reason for not clearing all fields was an overriding concern for speed. The TLM-WG identified speed and interoperability as top priorities and worked obsessively to those ends.

Whatever, I don't see how imposing that rule now would solve the immediate issue of compatibility with legacy models?

John A

-----"Michael (Mac) McNamara" <mcnamara@cadence.com> wrote: -----
To: "'john.aynsley@doulos.com'" <john.aynsley@doulos.com>, "'jerome.cornet@st.com'" <jerome.cornet@st.com>
From: "Michael (Mac) McNamara" <mcnamara@cadence.com>
Date: 12/09/2010 04:01PM
Cc: "'bartv@synopsys.com'" <bartv@synopsys.com>, "'philipp.hartmann@offis.de'" <philipp.hartmann@offis.de>, Stan Krolikoski <stanleyk@cadence.com>, Stuart Swan <stuart@cadence.com>, "'systemc-p1666-technical@eda.org'" <systemc-p1666-technical@eda.org>
Subject: Re: TLM extensions - status

I have been confused all along as to why we don't require pool allocators to clear all fields when they recycle a tlm packet.

It is simply the right way to write a pool allocator.

It gives you security (other packet requesters can't detect data not for them)

It gives you stability (you know allocated packets will always have a known value, even if not set by the user)

It gives you ease of understanding (data fields that should be ignored, don't have arbitrary data in them that will be displayed, confusing the gentle reader when the data has no meaning)

It is simple - we just mandate that every pool allocator must clear all fields.

Mac
------Original Message------
From: john.aynsley@doulos.com
To: Jerome CORNET
Cc: Bart Vanthournout
Cc: john.aynsley@doulos.com
Cc: Philipp A Hartmann
Cc: Stanley J Krolikoski
Cc: Stuart Swan
Cc: P1666 Technical WG
Subject: RE: TLM extensions - status
Sent: Dec 9, 2010 7:30 AM

Jerome, WHOOPS! That point is central to the backward compatibility argument, so perhaps we have been talking at cross-purposes all along. A new initiator will reset the flag, but an old initiator will not reset the flag because it does not know it exists. Why does the the old initiator not get a new transaction with the flag at its default value of 0 anyway? Because it may be getting the transaction from a pool, where the transaction attributes will have values left over from a previous life. Hence the recent proposals for mechanisms to automatically reset the flag (and why auto extensions would have been an out-of-the-box solution if only a memory manager were mandated, which it is not). John A -----Jerome CORNET <jerome.cornet@st.com> wrote: ----- To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "Philipp A. Hartmann" <philipp.hartmann@offis.de> From: Jerome CORNET <jerome.cornet@st.com> Date: 12/09/2010 11:39AM Cc: Stuart Swan <stuart@cadence.com>, Bart Vanthournout <bartv@synopsys.com>, "stanleyk@cadence.com" <stanleyk@cadence.com>, P1666 Technical WG <systemc-p1666-technical@eda.org> Subject: RE: TLM extensions - status  
From:john.aynsley@doulos.com [mailto:john.aynsley@doulos.com] Sent: Wednesday, December 08, 2010 10:01 PM To: Philipp A. Hartmann Cc: john.aynsley@doulos.com; Stuart Swan; Bart Vanthournout; Jerome CORNET; stanleyk@cadence.com; P1666 Technical WG Subject: Re: TLM extensions - status
 
>>Good point. The new init would be obliged to reset the flag, which

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