Re: Minor TLM enhancements/fixes

John, Jerome, All,

I'm a little late in reviewing the discussion below - here are my inputs.

About adding const versions of get_base_port() and get_base_export() to initiator socket class, I agree that it will be beneficial in the context of derived classes.

About relaxing the rule for transport functions to allow null data ptr when the command is IGNORE, I understand John's backwards compatibility concerns, but I am convinced by Jerome's counter-argument below - the only code that will possibly need rewriting is any protocol checker kind of thing that is going into each and every detail of the protocol - such code is rare and it is safe to say will not appear in typical user code. Considering the limited scope of backward-incompatibility, and the benefit of relaxing the rule, my vote would be for allowing data ptr to be NULL for IGNORE cmd.

About allowing DMI/debug to use all the generic payload attributes (like byte enable) and to obligate returning the response status, it is trickier in terms of backward compatibility. I think Jerome's use cases are legitimate. Does it work if we change the LRM wording to "may or may not" instead of mandating one rule or the other in this respect? That would allow existing models to not change their behavior but new models can choose to use the additional expressivity. However, I'm not sure if that serves the original objective - unless the LRM mandates the rules, is it useful in terms of interoperability?

About what transport_dbg should return for IGNORE cmd, I do not have any bright ideas to contribute, we could have chosen something like -1 but that won't work since the return value is unsigned.

In summary, IMO all the enhancements/fixes proposed by Jerome are minor but do serve valid, and important use cases. In balance, it will be beneficial to include these enhancements in the LRM, even if that implies some loss of backward comptability (in the worst case). This is in line with the philosophy we have been following for standardizing the SystemC language itself, where we do go ahead with changes that are deemed overachingly beneficial, but can lead to a little bit of backwards incompatibility - e.g. in case of event startvation, sc_start() will now return the time of event starvation instead of the max sim time.

My 2 cents.

-Bishnupriya

From: Jerome CORNET <jerome.cornet@st.com<mailto:jerome.cornet@st.com?Subject=RE:%20Minor%20TLM%20enhancements/fixes>>
Date: Tue Nov 23 2010 - 09:08:14 PST

John, all, some remarks below.

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Monday, November 22, 2010 5:35 PM
To: Jerome CORNET
Cc: owner-systemc-p1666-technical@eda.org; P1666 Technical WG
Subject: Re: Minor TLM enhancements/fixes

>>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.
Sure, that would require minor modifications of the existing kit. I already have got a modified version compiling and running, that I can provide.

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

This is a truly important question here. Indeed, we have to take care of backward compatibility (else we hurt the ecosystem). I am on the same page as you on the intent. However, we have to balance that we the need
for the standard to evolve to address real world situations that had not been taken care of at the time of creation of the standard. Let's remember that at that time, compromises were done to allow the standard to go out in time (as many years had already been spent on it).
 Let us examine in details the backward compatibility issue, w.r.t to the various requests:

- On the use of data pointer with TLM_IGNORE_COMMAND:

o In many cases, the IP will just do nothing upon reception of an IGNORE command because it does not support any extension. Changing the rule has not effect on backward compatibility here.

o In cases where the receiving IP supports extensions and say, user-defined commands, it will indeed have a special handling for TLM_IGNORE_COMMAND and possibly

use the data pointer, in which case it could take advantage of the non-null data pointer assumption. However, it can well receive a IGNORE transaction with an extension

that it does not understand, so before using the data pointer of the transaction or any other field, it'd better first test presence of a well-known extension. To summarize,

either the target receives a transaction with an extension it understands, and then the data pointer will anyway be non-null if it assumed so, - or - the extension is unknown

and anyway the target will not take advantage of the data pointer, which can then be left to null. No effect on backward compatibility either.

o Finally, we have the case of protocol checkers, or IPs that deeply checks compliance of transactions upon reception. In that case indeed, the IP will need modification to avoid

complaining about the a null data pointer with an ignore command. However, it is highly probable that the IP will need modification because of IEEE itself, since - as I made

the remark for TLM 2.0.1 (for which we did similar adjustments)- the clause number will again change from TLM 2.0.1 to IEEE. So, the error reporting code will have to be changed

anyway to report clause numbers refering to an up-to-date document (as we have done to align on TLM 2.0.1 in the past).

- Regarding the response status with DMI/Debug as well as the huge limitations of the debug interface w.r.t to byte enable, and other attributes:
These limitations really hinder TLM-2 usability and using custom protocols will not solve the problem as it would have done in other situations. This is because even with a custom protocol you end up with the need to plug other vendor's IPs.

o I plug a third-party subsystem on my own platform with my custom protocol. I am therefore able to use the response status in my own platform, but not when crossing the boundaries of the third

party subsystem. I send a DMI transaction to the third party subsystem, which do not complete it because of an addressing error. I end up believing the subsystem does not support DMI: time is lost in interactions with the IP provider , for nothing... whereas the field is there in the DMI transaction! We just can't use it.

o I have to generate debug transactions with byte enable and with the guarantee that no side effect will be performed upon reception. I can depart from base protocol and use them for my own platform with custom protocol, but what do I do when crossing a third-party subsystem boundary? How can I rephrase my byte enable debug transaction as a truly base-protocol transaction with only unaligned addresses and sizes that I could send on the debug interface? No way. Maybe send it through the transport interface where the rules allow to use every attribute, but then I have no guarantee about the side effects. What do I do?
Now, imagine we decide to change the rules a bit and allow use of all attributes with debug interface. What will existing IPs do upon reception of a transaction, say, with a non-null byte enable pointer? They will complain and return an error. What does need to be changed? Nothing, except possibly the wording of the error message. Any IP has the right to return error if it does not support a given combination of generic payload attributes.
To summarize, I really believe that a useful standard is one that lives and evolves. What I am proposing here are minor changes with limited backward compatibility problems. No code modification to the TLM kit is required (except for the first point of the email), only the wording needs to be adjusted.

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

Re-reading your answer I understand that we have to proceed in such a way that existing uses are not forbidden by a more explicit wording. However, I guess that a non-zero value (if the command have to return "OK" in the response status sense) will fit. What do others think?

Best regards,

Jerome

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
----------------------------------------------------------------------------------------------------------------------------------------------------
     Bishnupriya Bhattacharya   |   Software Architect - Virtual System Platform   |   Cadence
     P: +91.80.4184.1197   www.cadence.com<http://www.cadence.com/>
----------------------------------------------------------------------------------------------------------------------------------------------------
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.