Re: Minor TLM enhancements/fixes

Jerome,

I'll give my opinion:

Re. adding const methods to initiator and target sockets, yes, that sounds
like a good idea. Of course, it would require a new release of the TLM-2.0
kit.

Regarding the use of the data pointer with TLM_IGNORE_COMMAND and the use
of the response status with DMI and Debug, I think your proposals would
have been a good idea at the time we created the TLM-2.0 standard.
However, given that the TLM-2.0 standard has been out there for 2 years
now and a legacy codebase is building up, I would be against making either
change now because those changes could potentially break existing code.
Base protocol targets can assume a non-zero data pointer with
TLM_IGNORE_COMMAND, and are not obliged to set the response status for DMI
or Debug.

Note that custom protocols can already use the rules you propose.

With Debug and TLM_IGNORE_COMMAND, 12.3.4 e) is explicit that the target
shall not execute a read or a write but may do something else, possibly
using extensions. With TLM_IGNORE_COMMAND the target is free to return
whatever value it likes as the value of transport_dbg. I would be happy to
spell that out more explicitly.

What do other people think?

John A

From:
Jerome CORNET <jerome.cornet@st.com>
To:
P1666 Technical WG <systemc-p1666-technical@eda.org>
Date:
18/11/2010 13:43
Subject:
Minor TLM enhancements/fixes
Sent by:
owner-systemc-p1666-technical@eda.org

All,
 
following Stan?s call to send request regarding minor issues in the
current LRM, here is a small list
for the TLM part (that dates back from the TLM-2 LRM, but that we?ve
discovered only after some
practice):
 
in the sequel I give the references in terms of clause numbers of the
current IEEE draft:
 
- 14.2 ?Initiator and target sockets?: the classes
tlm_base_initiator_socket_b and tlm_base_initiator_socket (as well as
their target counterparts) are missing const versions of the methods:
virtual sc_core::sc_port_b<FW_IF> & get_base_port();
virtual BW_IF & get_base_interface();
virtual sc_core::sc_export<BW_IF> & get_base_export();
 
This would really be beneficial to add their const version, for a derived
class to call them from a const context.
 
- 15.10 ?Generic Payload ? Data pointer attribute? Clause 15.10.e
forbids to call the transport interface with a transaction object having a
null data pointer attribute. This is indeed common sense for READ and
WRITE transactions, however this unnecessarily restricts the usability of
IGNORE transactions. There are situations where transactions containing
ignorable extensions but no particular transaction data pointer need to be
sent through the transport interface. In such cases, the IGNORE command is
perfectly suited for that purpose as the transaction can be safely ignored
by the target/interconnect.
The proposal here is slightly relax the clause to ?It is an error to call
the transport interface with a transaction object having a null data
pointer attribute except if the transaction?s command is IGNORE?.
 
- Response status handling for DMI and Debug Interface: Clauses
15.2.4.j / 12.3.4.i indicate that an interconnect component does not need
to pass the interface call in the event it detects an addressing error.
Clauses 15.2.4.k and 12.3.4.o state that aside from the command and
address an initiator/interconnect/target may ignore all other attributes,
in particular the response status attribute. This is unfortunate, as it is
therefore impossible for an initiator to detect an addressing error
occurring through the DMI or Debug Interface.
The proposal would be to include the response status in the list of
attributes accounted for in the case of DMI and Debug Interface calls.
 
- In the case of the Debug Interface, clause 12.3.4.o denies any
possibility of using standard generic payload?s attributes such as byte
enable, streaming width, etc. This is overly restrictive as debug
transactions (as we always stated) are not only useful for the particular
use case of an ISS debugger , but also for filling a code/IP memory, or
performing services transactions from a test bench.
The proposal (which also addresses the previous point) would be to relax
rules associated with the GP in the context of the debug interface to the
one of the transport interface, while keeping current restrictions of
non-blocking context and rules associated with returning the actual number
of bytes read or written.
 
- Still in the Debug Interface, clause 12.3.4.q does not specify
which value to return in the case of an IGNORE command. It would be
beneficial to cover that case explicitly.
My proposal is to always return a non-zero value, which seems consistent
with the semantics of the IGNORE command (any ideas here?)
 
Cheers,
 
Jerome
 
 
 

-- 
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.