rahuljn Posted June 4, 2014 Report Posted June 4, 2014 Hi TLM experts, I have few question. I have a target with 2 target ports - do I need to implement b_transport for each target port or - just need to provide one implementation of b_transport In later case how can I know on which port the b_transport is called ? I also have two independent register bank, one for each target port. i.e. first register bank is accessible from first port and second one with second port. - How I can ensure the first register bank is only accessible from first port,not from other ports ? - If there is only one b_transport then how can I decide that on which port the b_transport is actually called and whcih register bank I need to access Thanks in advance - RahulJn Quote
apfitch Posted June 4, 2014 Report Posted June 4, 2014 Have a look at the section on convenience sockets in the LRM. There are some sockets that are described as tagged (see table 59). If you use one of the tagged target sockets, then you can arrange that a socket ID is associated with each initiator, so you can tell them apart. See the example at the bottom of page 531 for instance. If you have two independent register banks accessible from independent ports, why not write one target and make two instances of it? If you do want a single class with two target ports, then it's up to you to decide what to do by checking the address when you receive the generic payload. Remember that TLM2 was intended for memory-mapped busses, so your two register banks would be (I assume) at different memory map locations. regards Alan David Black and Philipp A Hartmann 2 Quote
rahuljn Posted June 5, 2014 Author Report Posted June 5, 2014 Hi Alain Thanks for your answers. What about my first question I have a target with 2 target ports - do I need to implement b_transport for each target port or - just need to provide one implementation of b_transport Thanks Quote
Philipp A Hartmann Posted June 5, 2014 Report Posted June 5, 2014 What about my first question Sounds like you didn't look up the suggested parts in the standard. /Philipp Quote
apfitch Posted June 5, 2014 Report Posted June 5, 2014 You just need one b_transport, but you have access to the tag so you know which initiator called you. Have a look at simple_target_socket_tagged and the example on page 531, regards Alan Quote
rahuljn Posted June 5, 2014 Author Report Posted June 5, 2014 Hi Philipp Yes it is clear from the LRM but I am looking for some mechanism to use similar things in my model which is based on tlm_initiator_socket/tlm_traget_socket. I need to know at run time on whcih port the b_transport is called. Is it possible ? Thanks Quote
Philipp A Hartmann Posted June 5, 2014 Report Posted June 5, 2014 Yes it is clear from the LRM but I am looking for some mechanism to use similar things in my model which is based on tlm_initiator_socket/tlm_traget_socket. I need to know at run time on whcih port the b_transport is called. Is it possible ? If you bind the same interface object (a "single" b_transport) to both target sockets, there is no predefined way to determine the port through which the interface has been called. If you insist on using a plain tlm_target_socket instead of the tagged convenience sockets, you can build the tagging mechanism on your own by implementing a small helper that provides the forward interface (most notably b_transport), stores an ID internally and forwards the call including the ID to the module itself. Not sure, why you would need to reinvent that, though. /Philipp Quote
David Black Posted June 8, 2014 Report Posted June 8, 2014 Another idea might be to observe that if the calls come from different initiators, then they likely come from different processes. Processes have unique process ids. Quote
rahuljn Posted December 9, 2014 Author Report Posted December 9, 2014 If you bind the same interface object (a "single" b_transport) to both target sockets, there is no predefined way to determine the port through which the interface has been called. If you insist on using a plain tlm_target_socket insteahid of the tagged convenience sockets, you can build the tagging mechanism on your own by implementing a small helper that provides the forward interface (most notably b_transport), stores an ID internally and forwards the call including the ID to the module itself. Not sure, why you would need to reinvent that, though. /Philipp Hi Philipp I want to build my own tagging mechanism in existing models. A pseudo code will be of great help here Thanks RahulJn Thanks RahulJn Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.