Shabtay and Per, This is a good discussion. So what I'm kind of hearing both of you say is rather than having two separate interfaces, do what it takes for the current one to support both it's current use model and TLM. Actually I have considered that approach as well and I think there are ways to do it. However, my concern is that it makes one fairly complex interface rather than two simpler interfaces where it is fairly clear which to use for what. But, I may be wrong about this. I'm definitely open to a consolidated interface esp. if we can clearly define how you could use it for both streaming and TLM oriented applications. Let's talk about this some more tomorrow and hopefully spend some quality time discussing it at the face-to-face next week. -- johnS Shabtay Matalon wrote: > Hi John, > > >>johnS: >>It can. But I think this makes it more complicated >>that way. >> >>Here's my reasoning: >> >>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 >> >>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. > > [Shabtay] John, I think this now throws the problem at the user to > understand each interface and figure out what to use. > > >>johnS: >>Right now the TLM-API is only defined in an OSCI SystemC >>context based on classes and communication is only defined >>between SystemC and SystemC - not between SystemC and HDL. >> >>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. > > [Shabtay] You are correct about TLM being a SystemC protocol. So the > adaptor will need to be implemented in SystemC as a bridge between > SystemC TLM and the C API we defined on the SW side. Assuming DPI subset > and pipes present the C API, I don't understand why the TLM library > should not be written as SystemC adaptor/s that encapsulates the pipes > and DPI on the SW side. If pipes are not capable of being the underlying > transport layer, we should revisit the pipes semantics rather than > creating a different implementation for pipes that is TLM compatible. > > Can you mention which incompatibilities you identified in the pipes to > allow pipes to be encapsulated within SystemC TLM adaptors? What > prevents us from addressing these incompatibilities besides being rushed > to complete SCE-MI 2.0?Received on Wed Feb 1 15:57:27 2006
This archive was generated by hypermail 2.1.8 : Wed Feb 01 2006 - 15:57:47 PST