Hi John, > Why implement a > > library on top of a > library on top of > DPI > > when you can define it as two simpler problems kept > independent: > > library1 on top of DPI > > library2 on top of DPI The reason we might want to go with the first option is that if pipes can be built on top of your new TLM support API, then perhaps we can get rid of pipes and use the TLM support API instead since it is more powerful than pipes. My main concern is what you've called data shaping, by the way, not streaming. So I assume your TLM support API also supports data shaping, correct? Basically, can I pass in/retrieve whole messages on one side of the interface and retrieve/pass in chunks on the other side of the interface? Also, is the TLM support API constructed such that it provides the implementor opportunities to optimize the transfer of large messages as units over the equivalent chunk-wise transfer using regular DPI? > I think this contains the scope of the problem much > more nicely. It also lets a lot of common decisions > made for one library apply for the second since where > there are similarities. If you still see value to the pipes as a directly supported API, then we should consider the side-by-side definition. Unlike Shabtay I am not so worried about users having a hard time figuring out what API to use. If they serve different purposes it should be obvious which to choose, e.g., if the user wants to interface a TLM-based environment they should use the TLM support API, etc. If there is overlap between the different APIs the user will pick one of them and it will work, regardless of which one they choose. The vendors can help the users by providing examples and app notes, if they want. The above assumes the two APIs are not totally overlapping, that is mutually redundant, of course, but mostly complimentary. If they were completely redundant we should get rid of one of them. > So, by creating an ANSI C DPI function interface that > follows TLM semantics, we can easily build TLM compliant > bridges or adapters between OSCI-SystemC TLM modules and > synthesizeable, acceleratable HDL. I take this to mean that what you are proposing is a C API that allows one to implement a SystemC TLM interface to some transactor on the HDL side. The API you are proposing is not actually TLM. I think Shabtay missed this point. So your proposed API is equivalent to TLM semantically but not syntactically, which it couldn't be since TLM is C++. Is this correct? This is why I called it `the TLM support API'. We should be careful about what we call this thing . . . Per -- Per Bojsen Email: <bojsen@zaiqtech.com> Zaiq Technologies, Inc. WWW: http://www.zaiqtech.com 78 Dragon Ct. Tel: 781 721 8229 Woburn, MA 01801 Fax: 781 932 7488Received on Wed Feb 1 16:22:45 2006
This archive was generated by hypermail 2.1.8 : Wed Feb 01 2006 - 16:23:10 PST