Minor TLM enhancements/fixes

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.