Jump to content

David Black

Members
  • Content Count

    360
  • Joined

  • Last visited

  • Days Won

    79

David Black last won the day on August 20

David Black had the most liked content!

About David Black

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1,843 profile views
  1. We shall have to wait and see w.r.t. co-routines, but they do look promising.
  2. If you want multiple drivers, use sc_signal_resolved or sc_signal_rv<N>. The reason for SC_ONE_WRITER is to catch errors since the normal use case for sc_signal is single drivers. The SC_MANY_WRITERS was intended to allow one process to initialize and then hand-off to another process. Your use case likely the resolved signal situation. Verilog uses wires for the resolved case. VHDL has you to be more explicit.
  3. David Black

    find parent port?

    I see this question a lot. Perhaps an enhancement idea for a future SystemC. register_port could be augmented by adding a bit of data to channels to record the connecting parent. This would add a small structure (?vector<sc_object*>?), and add a tiny bit prior to start of simulation. Providing a "netlist" helps to confirm everything is connected correctly. Of course it won't for all the connectivity (e.g. a global clock object), but it would go a long way.
  4. David Black

    find parent port?

    Try get_parent_object() -- IEEE 1666-2011 page 128
  5. You should have a top level. If you don’t, create one and instantiate everything there. Set the global quantum in your top level module st end_of_elaboration and reset local quantum’s at start_of_simulation. Set a default and allow for override. You can obtain the override value to use at run time from any of: - command-line argument using sc_argv() - read a file or database if it exists - Enviroment variable set prior to invocation - user input prompt
  6. It is definitely possible to model using c++ threads; however, I think for most things it will actually be more difficult to use than SystemC because of the preemptive nature and requirements to use mutexes and semaphores. By contrast, SystemC provides a simplified cooperative approach multitasking approach. The techniques can also be mixed when appropriate.
  7. Create a handshake signal.
  8. Caution: SystemC Kernel is not thread-safe without taking special precautions. If you call into SystemC from outside the SystemC OS-thread, you may need to create a primitive channel utilizing async_request_update(). If on the other hand you are simply stalling SystemC from within, which is what I think is being stated, then you should be fine with simple std::mutex (not sc_core::sc_mutex which is only for use inside SystemC between SystemC internal "processes").
  9. The error looks like a 64-bit library issue with stdc++.
  10. If you are trying to inject events from received TCP/IP running in parallel OS threads or external OS processes, then you will need to create a primitive channel utilizing sc_core::async_request_update() in order to safely (see note 1) inject events into SystemC. Your only other option is to poll, which is rather inefficient. Also be mindful that the SystemC side performance does not guarantee you will only get one event per delta cycle; therefor, you need to use a queue to receive data. You will also likely need to use an OS mutex (C++11 std::mutex should work fine for this application). Note 1: SystemC is not inherently thread-safe and random injection from outside can corrupt the simulation.
  11. David Black

    tracing waveforms in tlm

    Sorry, but tracing TLM is not directly supported. Recording transactions is supported.
  12. David Black

    reading part of input port

    Sorry, but this is simply not possible in the convenient manner of Verilog. Reason: SystemC is not about RTL. If you need a few bits, then read all of them and mask off the ones you want.
  13. One way to disable the clock is to completely replace it with a model that does nothing. I presented a concept called no_clock at NASCUG a few years back demonstrating an approach. You can find the code on github: https://github.com/dcblack/no_clock with a link to the presentation. You could even replace the declaration of sc_clock directly with a conditional macro test: #ifdef USE_NO_CLOCK #include "no_clock.h" no_clock myclock{ "myclock", 10.0, SC_NS }; #else sc_core::sc_clock myclock{ "myclock", 10.0, SC_NS }; #endif
  14. David Black

    Systemc performance

    I would say it is definitely interesting.
  15. David Black

    Systemc performance

    Perhaps you would like to share your code for measurements via GitHub? Measuring performance can be tricky to say the least. How you compile (compiler, version, SystemC version) and what you measure can really change results. Probably helps to specify your computer's specifications (Processor, RAM, cache, OS version) too. Processor (vendor, version) L1 cache size L2 cache size L3 cache size RAM OS (name, version) Compiler (name, version) Compiler switches (--std, -O) SystemC version SystemC installation switches How time is measured and from what point (e.g. start_of_simulation to end_of_simulation) Memory consumption information if possible This will help to make meaningful statements about the measurements and allow others to reproduce/verify your results. It is also important to understand how these results should be interpreted (taken advantage of) and compared. As with respect to TLM, it will get a lot more challenging. For example, what style of coding: Loosely Timed, Approximately Timed. Are sc_clock's involved?
×