Jump to content

plafratt

Members
  • Content Count

    18
  • Joined

  • Last visited

About plafratt

  • Rank
    Member

Recent Profile Visitors

346 profile views
  1. Thank you for the thoughts. I am using acquire() and release() to ensure that the memory is safe while I am using the transaction in the target. The specific problem I am facing is that the initiator might call, for example, set_address() on the transaction after it receives the response, while the target is still using it. The target needs access to the original address.
  2. In systems where a target can send an early response, such as a posted write, and the initiator can change the transaction after it receives the response, how do most developers handle the transaction in the target while avoiding seeing the initiator's changes to that transaction? An obvious solution is for the target to do a deep copy of the transaction, but in a complex system with many modules, having each module potentially create its own copy of each transaction can make debug and performance analysis difficult. Another option is for the target to save the relevant information from the transaction in an extension when the target receives that transaction, but this has the problem that the developers of the target must always remember to use the accessors in the extension, rather than the standard ones for the transaction.
  3. Thank you for the responses. Sorry for the delay in my response. I'd gotten busy, and I am just now getting around to signing back in. We don't seem to be having this issue anymore. I am not sure if it because of code updates or because of a compiler upgrade. We recently switched from g++ 4.9.2 to 6.2.1, so that may have resolved the issue. The path in question is sc_fifo::read() -> sc_fifo::read(T& val_) -> sc_fifo<T>::buf_read( T& val_ ). On line 410, buf_read() returns false without setting val. None of the functions in the call chain set val, so when the original call to sc_fifo::read() returns, it is returning its locally-declared tmp variable, which was passed to sc_fifo::read(T& val), which never sets val. As I mentioned, though, this doesn't seem to be causing a problem for us at the moment. It may have been a compiler issue that got resolved when we upgraded. Thank You and Regards, Patrick
  4. I get the warning when building my code that uses sc_fifo.h, not when building systemc. I assume this is because the function is declared inline.
  5. For sc_fifo::read(), some versions of g++ give me a warning that the variable tmp is unset. I see there is a path through read() that leaves tmp unset, but I don't think it is possible that this path ever gets executed. Is there a way around this warning that doesn't require disabling the warning in g++ or changing sc_fifo.h?
  6. That is it. Thank you very much. Regards, Patrick
  7. I looked at the implementation of sc_fifo, as I'd guessed that in the read() function, it would just notify data_read_event, but the logic surrounding the notify looks a little more complex than that.
  8. I'm actually using read(), rather than nb_read(). Given the specification you posted, it seems like something unexpected is happening. I can see the fifo is getting read (I put a log statement in after the read() call), but I don't see the thread that is waiting on data_read_event getting woken up (I put a log statement there, too). The thread that is waiting on data_read_event does eventually get woken up when the last item is read off the fifo.
  9. I had been using the sc_fifo with the assumption that data_read_event would get notified whenever the receiver read from the fifo. However, I am seeing cases where the receiver reads from the fifo, but the data_read_event doesn't get notified. Is this the intended behavior?
  10. Is there a preferred way of adding an event to the static sensitivity list for a single wait? I think it would be possible by ORing the static sensitivity list with another event, and sending the result to a wait. The problem is that I don't see an accessor function for a thread's sensitivity list. I guess one approach is to hard-code an sc_event_or_list that includes the static sensitivity list, but that seems a little clunky. sc_event_or_list or_list; for (int i=0; i< 100; i++) or_list |= my_array_of_100_events; or_list |= new_event; wait( or_list ); Is there a better way to add an event to the sensitivity list for a single wait? Thanks, Patrick
  11. Philipp, Thanks for the response. This is very helpful. This makes sense now. I had noticed the use of the dereference operator, and it had caught my attention since the initiator_socket hadn't been declared as a pointer. But it didn't occur to me to look into that further. I think perhaps I was too distracted with my search through the inheritance hierarchy. Thanks again, Patrick
  12. I am a bit confused by the usage of the b_transport function in the file examples/tlm/common/src/lt_initiator.cpp. The lt_initiator class has a simple_socket_initiator member that is calling the b_transport function, and I’m trying to figure out how the simple_socket_initiator class is getting access to this function. The only connection in the inheritance hierarchy I’ve been able to find between simple_socket_initiator and the b_transport function is a distant link through a friend declaration in the tlm_base_target_initiator class. I’ve drawn a diagram showing this connection. This diagram is attached. I could be wrong, but I don’t think that this connection would allow the simple_socket_initiator to access b_transport. I am lead to the conclusion that I think there is some other connection between simple_socket_initiator and b_transport that I am not seeing. At runtime, simple_socket_initiator’s b_transport function call is getting resolved to simple_target_socket’s implementation. I’m just not sure how this resolution is happening. Any help anyone can offer is appreciated.
  13. I just found this discussion on this topic, which was very helpful. However, any additional thoughts that anyone might have on the topic are appreciated.
  14. Hello, In my previous modelling efforts with SystemC, I have, in general, used SystemC FIFOs for communication in abstract models. I have learned the basics of TLM and gone through a couple of examples, but it isn't clear to me what the advantages are of TLM over FIFOs. Someone has explained to me that there are performance advantages of TLM. However, for my purposes, I am not so concerned with performance. Does anyone have a reference that presents the advantages of TLM over more conventional communication mechanisms in SystemC? Any help is appreciated. Thanks, Patrick
  15. Jens, Sumit- I haven't tried what Jens has proposed with OpenMP, so I can't speak from experience. However, my understanding is that Jens is perhaps not trying to parallelize a single call to sc_main, but rather trying something akin to creating multiple processes, each from its own sc_main. If each sc_main is isolated from the others, perhaps each could have its own elaboration. This seems to me like something that might be feasible. However, I would not think that SystemC's internal processes (i.e. sc_methods, sc_threads, etc.) could be synchronized across processes in such an environment. Regards, Patrick
×
×
  • Create New...