Jump to content


Popular Content

Showing most liked content since 10/22/2017 in Posts

  1. 1 point

    SCV library installation

    Hi Aixeta, this is already fixed in the upcoming release of the SCV. Meanwhile you can workaround by casting directly to sc_logic: sc_dt::sc_logic_value_t(this->_get_instance()->get_bit(i))
  2. 1 point
    Hi. This seems to be related to SystemC in general and not to UVM. sc_start() - without argument - starts the simulation until there is no activity anymore. No activity means no more events in the event queue. sc_clock generates new events all the time because the value changes independent from everything else in your design. As a result, the event queue will never be empty and the simulation never stops. (For completemess: the simulation ends as well when the maximum time is reached, i.e. the maximum time value that can be represented by sc_time). Normally, there are two ways to stop simulation, either by calling sc_start with a argument or by calling sc_stop. The first has been mentioned already by AmeyaVS. It runs the simulation for the given time and stops. The second can be done for instance from a testbench thread, e.g. from a sequencer when all sequences are done. Greetings Ralph
  3. 1 point

    Transaction Data Pointer

    Hi. Normally the initiator is considered as owner of the payload, i.e. he should take care of allocating and de-allocating it. The target should decide how to use the data. If the target wants to keep it/store it, the target should make a copy of the data. In that sense, the transaction is completed when b_transport returns because the initiator transfered it to the target and the target had a chance to handle it. A benefit of this is that you do not need dynamic allocation of the buffer buf. Greetings Ralph
  4. 1 point
    Starting with SystemC 2.3.2, the MSVC project files shipped with the package use the DLL-based runtime library. Therefore it is not necessary (instead rather harmful) to select the statically linked runtime library in your application. Secondly, you should not set the SC_SIGNAL_WRITE_CHECK environment variable to DISABLE (unrelated to your current issue, but suggested in the video above). More instructions on using MSVC with SystemC can be found in the INSTALL file shipped with the proof-of-concept simulator. Hope that helps, Philipp
  5. 1 point
    Philipp A Hartmann

    Explicit parent object

    Both versions are non-portable, as the SystemC simcontext is not part of the standard either. I am even surprised that the hierarchy_push/pop functions are not restricted (as they should be). So the first solution might in fact break in future versions of SystemC as you shall not mess with the object hierarchy stack yourself. Whether or not the "hierarchy scope guard" can be extended to become a standardized solution will likely require some discussions first, especially how to avoid breaking the object hierarchy. Certainly, this internal hierarchy stack is not something to arbitrarily use from the model side, other than from the sc_module_name usage today. For the particular use case, you can now look into the new "optionally bound convenience sockets" in SystemC 2.3.2, which you can safely leave unbound when not used. An arbitrary number of sockets can be bound to the multi_passthrough_*_socket, without having to do any such magic above. For a generic pattern to request additional structural things to "appear later", you can use an sc_vector with delayed initialization (since SystemC 2.3.2). This is (currently) limited to a single call, but I could envision to extend this to support distributed emplace_back() calls during elaboration. Such an approach would at least restrict the external modification of the hierarchy to much more controllable contexts. Regarding your current use case: How does the destination module actually use these newly added ports/sockets? /Philipp
  6. 1 point
    Hi Cliff, VCS provides a -top option for this, however it is a compile-time as far as I remember. Give it a try and see if that helps. Regards Srini www.verifworks.com