RE: TLM extensions - status

I've been watching this debate unfold as a "lurker", but I wanted to speak up on this point. I think Philipp is correct, this unfortunately doesn't seem to solve the problem because of the current wording which doesn't require any fields to be initialized other than those explicitly named. For all practical purposes, that renders all other fields or new additions useless with this particular API (Debug).

While I have no idea how many instances of models exist throughout the world that may be affected by this, as an end user of the API, I am most concerned by the fact that this fails *silently*, ie the "new" model has no idea that it is acting on bogus data, and the old model has no idea that it is receiving different data because of the recycled field data. To me, I would be furious if I spent hours debugging to track this to this situation.

And it's not even under my control if I use 3rd party IP - I have no idea if that initiator may or may not be sending uninitialized/recycled data.

This may not be what anyone wants to hear - but it seems the only way to both maintain backward compatibility and have a standardized new approach with tighter rules is to define a new enhanced debug API to coexist with the original. Possibly deprecate the original at some point.

Eric Roesler
                                 
Virtual Platform CoE
Intel Corporation
ph 480.554.7541
 

> -----Original Message-----
> From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-
> p1666-technical@eda.org] On Behalf Of Philipp A. Hartmann
> Sent: Wednesday, December 08, 2010 9:16 AM
> To: john.aynsley@doulos.com
> Cc: Stuart Swan; Bart Vanthournout; Jerome CORNET;
> stanleyk@cadence.com; P1666 Technical WG
> Subject: Re: TLM extensions - status
>
> John, all,
>
> I also think, that the addition of versioning the BP might be a good
> path for the future. But I'm a bit hesitant to embrace this in this
> short time frame we have left now.
>
> I fear the following issues:
>
> 1) How can the addition of an additional field (which needs to be
> properly initialised when reusing payload objects) solve the
> backwards compatibility issue?
>
> If we have a shared transaction pool for multiple initiators,
> the newly added attribute may be wrong, if not explicitly set
> by an "old" initiator. Which does not know anything about it.
> So it's even worse, since not just the "poorly coded" initiators
> are affected.
>
> 2) We break API compatibility with OSCI TLM 2.0 (not only binary
> compatibility due to a new kit). This leads to preprocessor
> clutter in many models, that intend to support both versions.
>
> 3) Do we actually catch all other caveats with the proposed
> versioning, if we define it in a quick shot now?
>
> I don't want to block any consensus here. I'm just concerned, that we
> do more harm than good, if we're not careful here. In fact, I think
> potential missed corner cases here may cause more maintenance effort
> down the road, than just fixing/documenting existing "poorly coded"
> models.
>
> Am I missing something?
>
> Greetings from Oldenburg,
> Philipp
>

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