Jump to content

Zack63

Members
  • Content Count

    5
  • Joined

  • Last visited

About Zack63

  • Rank
    Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

254 profile views
  1. Hello All, I have some confusion on the usage of the generic payload on the backwards path (e.g. AT nb_transport usage). At first glance, I would expect the target to re-use the generic_payload that it receives on the forward path. However, I'm working with a model that creates a new generic_payload on the backwards path. This makes things a bit strange, as I must keep the forward path generic_payload until the end of the transaction. I've looked in the LRM to determine if creation of a new GP by the target is allowed, acceptable, encouraged, etc, but I'm not finding anything obvious. Thanks in advance for comments! In case there is confusion, here is some pseudo code: // initiator sc_module. (Not using simple socket) My_sc_thread() { tlm_generic_payload gp; … cout <<" FW pointers: gp= "<<hex<<showbase<< (unsigned long long)(&gp) <<endl; out->nb_transport_fw(gp,ph,delay); } virtual tlm_sync_enum nb_transport_bw(tlm_generic_payload &gp, tlm_phase &ph, sc_time &t) { cout <<" BW pointers: gp= "<<hex<<showbase<< (unsigned long long)(&gp) <<endl; … } Output (simply showing the generic_payload pointer returned is not the one sent): FW WRITE pointers: gp= 0x7fb4423e5e90 gp.get_data_ptr()= 0x7fb4423e5f40 BW WRITE pointers: gp= 0x774ee0 gp.get_data_ptr()= 0x761f40
  2. Yes, naming the socket was the answer. In my actual code, I had an sc_export declared (from older code version), that I neglected to name and neglected to use. Thanks for the help -Mike
  3. Hello Forum, I get the error: WARN SystemC - 0.0/000: Error: (E124) sc_export instance not bound to interface at end of construction: export 'top.cpu.PV.export_0' (sc_export) WARN SystemC - 0.0/000: In file: /space/sw/vista/vista_4.1.0/generic/include/../CPP/systemc230/sysc/impl/communication/sc_export.cpp:141 But, I have no clue as to which socket/port/etc. is the problem. "top.cpu.PV" is the instance, but there is no object inside named "export_0" or even "export". I assume the "export" names are generated by TLM/SystemC. How can I find which TLM or other port is causing the issue? It seems quite puzzling. Thanks, -Mike
  4. Hello, I would like to determine port connectivity after elaboration. For example, I want to put code inside an SC_MODULE that would find the names of other ports that are connect to this module. Or, maybe there is a way to walk the hierarchy tree, and extract connectivity? The name() function gives my current instance hierarchy, but I cannot find any information on port connections. Any ideas? Thanks, -Mike
×