David Black

I concur with Eyck's comments. A few more thoughts: SystemC-processes are very different from OS processes. SystemC itself runs inside a single OS-thread. SystemC uses cooperative multitasking to simulate SystemC processes, which come in three flavors: SC_THREAD, SC_METHOD, and SC_CTHREAD (for synthesis). This is common among discrete event-driven simulators (e.g., Verilog, SystemVerilog, and VHDL use the same idea) Cooperative multitasking simplifies the coding a lot to make it easier for designers using these simulators. When documenting, I fin

Your problem is in the verilog because you created a race condition. Replace the $display with $strobe to see the proper settled condition of the signals. See https://www.edaplayground.com/x/9KdZ Perhaps you have not been formally trained in the semantics of event driven simulation.

With some corrections, it works on EDA playground <https://edaplayground.com/x/q3Ei>. Note: You do really don't need those deleted copy-constructors, etc. Rule of zero works. Also SC_HAS_PROCESS works best inside the thread. Also works on under Ubuntu with GCC 10.0.

That's an odd question since: 1. SystemC is software (C++ actually). 2. SystemC is used to model software running on hardware. So, most folks would model the hardware and use the software to validate the use cases. The next step would be to implement the hardware and then run the software on the real hardware. Some of the software used in a SystemC model would possibly be transformed into hardware (e.g., using an HLS synthesis tool such as Cadence Stratus, Siemens EDA's Catapult or Xilinx Vitis_HLS) or conventionally with RTL. Where is the software you ask? It depends on yo

If you want real help, you need to show us the source code. At a minimum, we would need to see the signal declarationwithin its context, and the location of it's constructor and write method. If using a custom datatype, we need to know that definition. Also, what compiler switches are used (e.g., -Wall -Wextra -std=?)? What compilation warnings are emitted? What version of SystemC?

Be aware that SystemC kernel is not threadsafe with exception of async_request_update(). So you must code accordingly.

Suggestions: 1. use stricter compilation rules such as -pedantic -Wall -Wextra and require all compilations to have zero warnings. This methodology will catch most errors. Use Ptah as to make exceptions around specific warnings you allow but only when you are certain and only for short code segments. 2. Switch from g++ to clang++ 3. Run static analysis and lint tools on your code Consider using Jetbrains’ CLion toolset. Inexpensive for what it does.

You should also take a look at uvm_heartbeat. It might be appropriate.

Consider using a uvm_event from the uvm_event pool and possibly a uvm_event_callback. Monitor 1 sends a delayed event: task monitor1::run_phase( uvm_phase phase); My_transaction sent_txn; uvm_event sent_evt = uvm_event_pool::get_global_pool().get("my_timed_event"); uvm_event rcvd_evt = uvm_event_pool::get_global_pool().get("my_received_event"); forever begin ... collect transaction ... timeout: fork begin received_evt.wait_trigger(); disable timeout; #timeout evt.trigger( sent_txn ); join_none end endtask: monitor1 Monitor 2 sends received transact

I think you are slicing the data structure. See https://stackoverflow.com/questions/274626/what-is-object-slicing.

sc_core::wait will always move to a subsequent (i.e., different) delta cycle. // sc_time_stamp: 0 s sc_delta_count:0 wait( 1, SC_US ); // sc_time_stamp: 1 us sc_delta_count:1 wait( SC_ZERO_TIME ); // sc_time_stamp: 1 us sc_delta_count: 2 wait( 2, SC_NS ); // sc_time_stamp: 1002 ns sc_delta_count: 3

I would further suggest that the static casting sounds suspicious, but without actual code we cannot determine much about the situation. Ideally you could put a subset of your code on www.EDAplayground.com and share a link. You might also consider turning on compiler switches such as GCC’s --pedantic and -Wall to see if the are any coding violations.

Probably because LeakSanitizer was designed with a proper understanding of pthreads; whereas, the non-pthreads implementation uses Q(uick)Threads (or some variant), which implements some assembly language to play with the processor stack to perform context switching. This confuses most if not all memory analysis programs. Pthreads is more universal but slightly slower than QThreads.

uvm_config_db is simply a facade pattern on top of the uvm_resource_db. As mentioned above, most recommend avoiding direct use of the resource db because the config db adds more consistency to its use.

The simple answer is that SystemC does not know how to trace std::string, and much less and array of std::string. First, std::string is a dynamically variable array of characters, which will perplex waveform viewing because you need a fixed number of signals to display. Changing to a fixed std::array<char,10> would help. You would still need to write an overload something like: template<int depth> void sc_trace( sc_trace_file* tf, const std::array<char,depth>& A, const std::string& name ) { // Code to trace individual char's for(int i=0; i<depth;

You’re only allowed to call sc_trace one time for each variable and after that tracing is automatic. So you need to move the sc_trace calls out into the constructor or into end_of_elaboration or somewhere else before simulation starts. You also need to move your local variables in to the class as members.

Compile checks are to ensure that you are using the same version of GCC and SystemC and flags to build the code as was used to compile the library. Everything needs to use the same tool/library set. This includes the version of the C++ standard you are using (suggest C++14 or better).

Yes, but it will depend on whether you have a simulator that is licensed for coast simulation. Simply be sure to follow the instructions provided by the simulation vendor (E.G, Synopsys or Cadence, etc.).

Code itself looks fine. I ran the above on EDAplayground without problem. I also ran on MacOS 10.15.7 (Catalina) with Apple clang++ 12.0 (LLVM ) Here is a link to where I ran it: https://edaplayground.com/x/V25h SystemC 2.3.3-Accellera --- Sep 21 2020 10:55:34g++ 7.5Using C++ standard 201402Ubuntu 18.04 You might consider upgrading g++ (4.8 is pretty old). I use g++ 9.3 normally.

SystemC is a discrete event driven simulator using an approach similar to Verilog, SystemVerilog and VHDL.The coding approach assumes cooperative multitasking. This is very time efficient and more importantly simplifies the modeling aspect if you really understand it, and makes it easier to interoperate with other simulators. Immediate notification is a unique feature of SystemC that works for some models, but not all. The reasoning behind it is simple efficiency. Delayed notification (i.e., SC_ZERO_TIME) is the safest approach if you are not certain that other processes are designed to w

@plafrattTLM2 is built to allow any protocols you like. The "base protocol" was deemed sufficient for most needs; however, TLM2 was designed specifically to allow alternatives. Furthermore, the standard provides mechanisms to keep the cost of adapters/bridges between protocols simulation efficient. [Plug - ignore if you like] The Doulos course on TLM 2.0 <https://www.doulos.com/training/systemc-tlm-20/systemc-modeling-using-tlm-20-online/> investigates the base protocol and then builds up to a module describing custom protocols.

There are several ways to approach this. A custom channel would be another approach, where the channel determined connectivity internally. I would also say that these approaches would not be considered "hacky". SystemC is intentionally built on C++ [see note] to allow you more freedom in modeling. Synthesis tools are a bit more picky, but for modeling there are many approaches. Usually, it helps to provide block diagrams describing what you are modeling and where the connectivity needs to be dynamic. From that we can make a number of suggestions. A hack approach would involve modifyi

sc_port's and their derivatives are not designed to be changed after elaboration. You could use multiports and simply change which index you are using. If needed you could create a wrapper to encapsulate the issue.

No. sc_clock models a fixed period clock with an optional start delay. If you want to model a clock that can be changed, it is simple enough to model yourself. You can use sc_signal_if<T> as the basic interface and add to it from there. For example, I have modeled a no_clock as you can see https://github.com/dcblack/no_clock.

Analysis ports are non-blocking by definition. Subscribers are required by the standard to: Not do any blocking activities (e.g. wait()) Not to modify any aspects of delivered reference. Copy the payload if you want to extend the lifetime of the payload