David Black

It should also be noted that sc_event::notify (all variants) are not blocking methods. You would have to yield your process to see the effects. Yielding is accomplished in SC_THREAD using the sc_core::wait (all variants) methods.

UVM-SystemC is a library. It is not a tool. You are expected to be very knowledgeable in both C++ and SystemC before using it. Knowledge of SystemVerilog UVM is useful. To use on the command-line you would have to decide your build methodology (probably make) and create appropriate files for that. RTFM please.

Logging in with a social accounts gives you access to all non-commercial simulators and some commercial simulators. If you want to use all the commercial simulators, you need a commercial/work e-mail address. For SystemC you don't need the commercial simulators.

This is both well known and well defined in the specification: sc_event only queues a single event for future notification notify immediate cancels the outstanding queued event and "happens" immediately. This is why it is called "immediate". If you attempt to queue non-zero notifications, only notifications nearer to the current time replace old ones. SC_ZERO_TIME can only be superceded by immediate notification. If you need to queue multiple notifications use the sc_event_queue.

It is unclear where your std::cout is located. The earliest I would expect is inside start_of_simulation() or as the first thing inside an SC_THREAD. But your code has another issue. You are declaring two independent variables. One in the struct, and the other as a stack located version with an initial value of 4 ms. Perhaps you meant to do something like: https://www.edaplayground.com/x/2c9j

Port not bound means that you forgot to connect a port. SystemC does not allow unconnected ports (at least not without some extra work). If you didn't name your port instances explicitly, SystemC arranges to have them named "port_0", "port_1", "port_2", ... etc. So you apparently have five ports on some module and you've only connected four of them.

wait(SC_ZERO_TIME); But perhaps there is more to your question. You probably need to provide some code to get a more comprehensive answer. For example, the above assumes an SC_THREAD process. If you have an SC_METHOD, then you would use: next_trigger(SC_ZERO_TIME); combined with some FSM mechanism.

Is the concern related to power domains being on or off? I would think it might be more productive if your underlying implementations looked for a hierarchical attribute related to power and you organized modules around power domains. Or perhaps you could have a global lookup unordered map of instance names to power domains. In any event, I would not redefine the API of standard channels. Keep in mind that generally sc_signal is a low level primitive and should be somewhat rare in most modeling situations. I would more likely expect this issue to appear in a TLM socket connection.

We assume you are using SystemC models for the Arm cores.

When you say "verifying hardware targets", may we assume you mean physical (not modeled)?

We shall have to wait and see w.r.t. co-routines, but they do look promising.

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.

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.

Try get_parent_object() -- IEEE 1666-2011 page 128

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

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.

Create a handshake signal.

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").

The error looks like a 64-bit library issue with stdc++.

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.

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

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.

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

I would say it is definitely interesting.

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?