Per, Good questions. Commends embedded: Per Bojsen wrote: > Hi John, > > >>As defined now the pipes are not TLM compliant. > > > Could you explain in detail why they are not compliant? Is > it just that they do not follow the TLM style or is it more > fundamental than that, e.g., that it is impossible to write > a gasket layer that interfaces pipes to TLM? I'd like to > understand this better before adding more to SCE-MI 2. johnS: The main reason is that pipes - by definition only support a blocking interface. And this was intentional to ease the creation of optimized, emulator centric implementations and retain determinism. Also to more closely match semantics of Unix streams and their ease of use. So I don't think we want to change this basic simple to understand, simple to use usage model. But with TLM you also need non-blocking support (in addition to blocking) on both ends of the channels. And, you need "peek" ability in addition to basic read/write ability. I thought about adding this somehow to pipes but I think it makes them even more complicated in terms of use model and implementation model and it would complicate our committee discussions even more - something we cannot really afford at the rate we've been going. So I think it is easier to define two separate, simpler interfaces and clearly define the semantics of each. There are similarities in the two but the semantics are different enough to keep them separate. At least this is how I see it. I'm open to ideas however. > > >>I can have a proposal ready to put on the table next >>week for the face-to-face if others are agreeable. > > > I don't mind, but please make sure to add a detailed analysis > as to why TLM support must be integral to SCE-MI 2. That is, > you must convince me that TLM support could not be implemented > as an application layer add-on to SCE-MI 2. johnS: Actually it can - and so can pipes for that matter. But, just as for example the "iostreams" is an ANSI standard library of C++ so should pipes and TLM fifos be a standard library of SCE-MI 2. This way, everyone implements and uses the library the same way. > Would it be possible > to consider TLM support a sub-standard of SCE-MI 2, sort of like > a library? johnS: Yes. In fact that's how I view pipes as well - a library over DPI. The TLM fifos would be very similar. > > Also, if you could outline why TLM support suddenly has become > such a hot issue for you. johnS: I won't say it is sudden. I'm just getting the feeling that at the rate of progress in our discussions, SCE-MI 2 may be obsolete and inadequate by the time it is out because transaction verification will be more aligned with the TLM standard. I think it behooves us to make sure that SCE-MI 2 dovetails well with other emerging standards. By incorporating it now, we extend the time window of its usefulness without having to wait for SCE-MI 3 and thus lag the industry even more. The good news is that TLM and DPI are already very well defined in other standards so we really just need to "steal" the work that has been done rather than having to invent the semantics from scratch. -- johnS <eom> > > Thanks, > Per >Received on Tue Jan 31 08:27:31 2006
This archive was generated by hypermail 2.1.8 : Tue Jan 31 2006 - 08:27:54 PST