Jump to content


  • Content Count

  • Joined

  • Last visited

  1. Well, after doing some more research on this topic, I think I can answers parts on my own: 1. Regarding the clock, I now understand, that this is not necessary. Instead, I can pre-calculate specific times and use events or other mechanisms to get notified once the particular time is reached. 2. Regarding synchronization, I used a sc_fifo now for transferring data. When it comes to signals on the ports, I simply set them wrt timing, so that CA is still maintained. I think that nails it pretty much... Cheers, Sebastian
  2. David, thank you for that thorough answer. I'd like to discuss different aspects a bit more. Could you explain me a bit more, how this is supposed to work? E.g. for this particular models, the goal was to also have cycle-accuracy, i.e. to me it seems unable to remove the clocks. This results from the following problem: usually the valid is raised only once. That is, with every new rising clock, new data is transferred. If I now remove the clock, then I won't know when there is new data. The next thing is, that these models are supposed to be connected to a complete system which would expect the clock port, because it would also transfer data synchronized to the clock. But maybe my approach is wrong. Yes, I do write unit tests, in fact the approach I'm currently using is test-driven to ensure that the models are working properly. For instance, I figured out by using a test, that my model would work when ready is true all the time but that data is lost, when it switches to false from time to time (e.g. because the internal memory is full). If I understand this correctly, then, in turn, the model might expose a different interface than for instance an implementation in Verilog or VHDL does? Also here I have had the problem, that I was unable to do synchronization between both modules. For example, I implemented them with SC_METHOD only and used next_trigger in order to maintain dynamic sensitivity on e.g. valid and ready. However, I had the requirement, that ready must be true before valid. I'm unsure how to model this correctly. So, for instance to avoid syncing to the clock again, I would use events. But to me this seems not being a good idea, since I would have to make this event visible across the modules in their interfaces. And I also think, this is what channels are for. Maybe you could give me a hint on this. To me, it seems that it is absolutely necessary and also absolutely ok to add additional signals to help with synchronization, even if they are not in the implementation afterwards. Thanks & Cheers, Sebastian
  3. Hi, I created a pair of modules in SystemC. The purpose is to model a data transfer with one side being the source and the other side being the sink. It currently uses SC_THREAD for processing, e.g. (not showing all details): class Source : sc_module { sc_in<bool> clk; sc_in<bool> ready; sc_out<bool> valid; sc_out<sc_bv<8>> data; // This is a SC_THREAD void process() { while(true) { wait(clk.posedge_event()); valid.write(data_available()); wait(SC_ZERO_TIME); if (data_available()) { auto datum = get_datum_to_transfer(); data.write(datum); if (ready.read()) { erase_transferred_datum(); } } } } } class Sink : sc_module { sc_in<bool> clk; sc_out<bool> ready; sc_in<bool> valid; sc_in<sc_bv<8>> data; // This is a SC_THREAD void process() { while(true) { wait(clk.posedge_event()); const bool is_ready = get_ready_state(); ready.write(is_ready); wait(SC_ZERO_TIME); if (is_ready && valid.read()) { store_datum(data.read()); } } } } For testing, the two modules are connected via sc_signal. Now, the problem that arose was, that it could happen, that ready and valid where assigned at the exact same simulation time respectively on the same rising edge of the clock. Then, the sink could not properly receive the data. I circumvented this by using wait(SC_ZERO_TIME); to issue delta-cycles which fully solved this particular problems. However, this particular design brings me to the following questions: Assuming, that there are many of these modules in the complete simulation, is the overhead of SC_THREAD negligible? I am aware, that internally pthreads are used and thus the OS has to deal with it (context switches). But I'm wondering, whether this approach will eventually slow the simulation. When implementing the exact same modules with SC_METHOD, is there a possibility to issue delta cycles in order to update the signals, whenever they are written? I found out, that triggering sc_start(SC_ZERO_TIME); results in the same effect. However, I don't think it is appropriate. Is this already the cleanest approach to the given problem of synchronizing two usually independent modules? Cheers, Sebastian
  4. Thank you for the reply. Dou you know, whether sc_curr_simcontext = new sc_simcontext(); also takes care about destructing the old context? That is, otherwise I would assume the simulation leaks memory with every new instantiated context. Cheers, Sebastian
  5. Hi, I'm working on a TL-Model in SystemC. Due to some internal necessarities, it is important to re-instantiate the model before a new simulation. I do not want to re-start the whole program. However, I get the following warning: This obviously comes from re-instantiation, since the instantiated module always uses the same name. However, this does not really makes sense to me, since between instantiations, the destructor is called and therefore, also sc_module_registry::remove gets called from which I'd assume, that it removes the module properly. This feels like a SystemC bug to me. Cheers, Sebastian
  • Create New...