Pruthvi015

I don't know how specific compilers implement bool, but the C++ standard says its size is unspecified, so I probably wouldn't rely on bool to carry the data. I would declare a an array of char, e..g
 
unsigned char data[1];
 
The other thing I don't understand is your use of len. The length is the number of characters in the data array, so in your example I would always expect trans->set_data_length(1), since a bool value will fit into 1 character. You seem to be using set_data_length() to specify a bit index. There's no support for bit addressing in the TLM payload.
 
If you want to read a particular bit, you either need to work out the address that contains that bit, retrieve a character, and then mask the value you want; or create an extension to the TLM2 payload to specify the bit you want.
 
Whatever you do, the TLM2 payload always moves an array of characters; and the address in the payload points to a particular character.
 
regards
Alan

Not related to your problems, but perhaps important as you continue to devleop...
 
Technical detail - TLM 2.0 requires that you:
1. Prior to sending specify 8 attributes in the payload. You are missing the streaming width and DMI hint.
2. Check to ensure the payload matches the attributes of your target
 
Also,
tlm::tlm_generic_payload* payload_ptr = new tlm::tlm_generic_payload; is very expensive (computation time), so I would encourage you to reuse the payload object if this code is inside a loop rather than generating a new one each time.

Hi.
 
Yes. A port does not hold a value. Whenever you access a port (read or write) you actually access the channel or signal bound to it. So, the port behaves like that signal.
(But you should not write to an input port )
 
Greetings
Ralph

Hi,
Does ports like sc_in<> follow request-update thing?
 
For example,  If I write to a port sc_In  will it be updated immediately or after delta time(like in signals)? 

@Steven: I expect it will be a matter of months to have the first (draft) material available. But again, it is the working group that decides on the schedule. Not sure if this will be LRM or proof-of-concept or both.
 
@Hans: UVM-SystemC is being developed and tested by end-user companies and system houses (of which only some are member in Accellera). Accellera supports the development of a multi-language verification standard, simply because UVM is available in different language flavors. UVM in SystemC/C++ is just one of them.