Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender
  • Location
  • Interests
    System modeling and simulation, Architecture modeling, high speed modeling

nizam.ahmed's Achievements


Member (1/2)



  1. Hi champs, I have a specific use-case where i would like to drive signals into the test-bench, but they are coming from different pthreads. I see that my implementation works. My deeper question is, is this allowed by the SystemVerilog LRM? In effect, the SystemVerilog and the simulation engine runs.... As it runs, asynchronously a pthread pushes a stimulus into the test-bench. We do the set_context and so on before driving into the system. But, still we would like to hear from horse-mouth! BR/Nizam
  2. Hi Philip, With RTLD_NOW | RTLD_GLOBAL flags to dlopen, i found that i don't have to move the max_num_extensions to .so file. It works well even if i have it in the header file. BR/Nizamudheen
  3. Hi Philip, Thanks. I used RTLD_NOW | RTLD_GLOBAL and that did the trick. I get the same output as yours. BR/Nizamudheen A
  4. Hi Philip, Thanks for the response. Actually, i tried to reproduce the fix (you suggested) in a simple C++ environment. And, as i suspected, the item # 2 in my earlier mail is not covered with the fix. I have attached a simple package that demonstrates this. Can you take a look at it and correct me if i overlooked at something? If needed, i can call you and talk about this issue. Thanks a lot, in advance. BR/Nizamudheen Ahmed test.tar.gz
  5. Thanks Philip for your detailed answer I see 2 different problems here/ 1. Across .so files, the indexes assigned to each extension should be unique 2. Across .so files the indexes assigned to same extension (say a type ext_1_t is extended in different .so files) should be same. I can see that the item 1 shall be solved by moving max_num_extensions to systemc.so file. Do you see that itme2 shall also be resolved with the same fix? BR/Nizamudheen Ahmed
  6. Hi, I have a strange problem and i think i have root-caused it. I wanted to shared that in the Forum an solicit suggestions. I have a SystemC module A and B implemented in libA.so and libB.so file. I also have a test-bench.exe file that load (explicit DLL load) these components and connect them. Component A add an extension (lets name it ext_t) to the TLM that it transacts with component B. And B is suppose to consume this extension. In addition, A as well as B may add addition (non-shared) extension to the payload. (say a_specific_ext_t and b_specific_ext_t respectively) I noticed that the component B was not able to extract the extension ext_t. The solution works when i compile the A, B and the executable into a single executable. I think, the TLM extension is not guaranteed to work across DLL, for explicit DLL load ones. B/c the TLM extension uses the technique of mapping a extension type to an integer. This integer is used to index into the extension array. When the components are implemented across .so file, One need to ensure that the extension in different .so map to same index. Hence, the order or of "extending" should match. Have you guys observed this in your setup. Any suggestion to solve this issue? One thing i thought was to have a third .so file called libextension_super_set.so. This .so file will extend all the possible TLM extension that the components want to exchange. And each of these components shall implicitly link against this .so and hence the index uniqueness is guaranteed to work. I have not tried this one. BR/Nizamudheen Ahmed
  7. Hi Philipp, This file is physically missing from the PoC simulator package i have. Looks like something is wrong with the tar file i have. Let me download the latest one and check. Thanks. BR/Nizam
  8. I could not locate the file tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_req_rsp_channels/tlm_req_rsp_channels.h included from systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_req_rsp.h. I am sure i am messing this up. Can someone throw some light on this? Thanks and Regards, BR/Nizam
  9. Hi David, Thats is indeed neat. My questions is answered. BR/Nizam
  10. Hi Alan, Thanks for the response. Right. I can use array of ports. In such case, ( for a generic module -- like interconnect) i would have to fix a MAX_PORT_COUNT kind-of. sc_port multiport provides that flexibility though:) BR/Nizam
  11. Folks, In SystemC multi-ports, one could access the sc_interface methods of specific port instance using operator [] overloaded method. Was there any reason to not have had C++ method in sc_port to allow access to individual port instances? For example, Assume I have a port declaration like. sc_port<some_interface_type, 4> p; I have to ensure the bind order so that the ports are bound correctly. For example, p.bind(some_module.first_export); p.bind(some_module.second_export); p.bind(some_module.third_export); p.bind(some_module.fourth_export); Assume that we introduce a method named at(int index) in sc_port, that returns the sc_port instance for the index, then one could have performed bindings as follows (essentially, the order of binding is no more significant). p.at(2).bind(some_module.third_export); p.at(1).bind(some_module.second_export); p.at(0).bind(some_module.first_export); p.at(3).bind(some_module.fourth_export); I have some of the binds captured in meta-data format( IPXACT) and my parser would not always return the bind in the sequence that the current SystemC expects. Having a _at_ method would have helped. Any thoughts/suggestions/comments? BR/Nizam
  • Create New...