David Black

Excellent! But what about prior to C++11? (Inquisitive minds want to know.)

[By 'expert', I am referring to those of you that write SystemC code regularly and have decent proficiency. This is not a newbie question.] Can anybody give me a specific example of when SC_HAS_PROCESS is needed outside the constructor? I personally cannot think of any reason to place it outside the constructor with one exception, multiple constructors. Multiple constructors are rare in my experience (use of default constructor parameters is more common). Even with multiple constructors, I suspect placing SC_HAS_PROCESS inside each one is not a huge overhead. The reason for my question for my question is because I think a strong recommendation for best practices is to move SC_HAS_PROCESS into the constructor where it is used. This has several advantages: If the constructor is implemented separately in a .cpp file, then the SC_HAS process clutter is removed from the header. It directs the implementor's/reviewer's attention to the real use of this macro: supporting SC_THREAD, SC_METHOD, etc. I realize this is a bit of a nit. I am not looking to change the standard, but I am looking to provide good recommendations for best practices.

There's a lot more you need to learn I suspect. Hopefully, you are a strong C++ coder and good with templates. I can provide a few pointers and a general comment or two. 1. Prefer <systemc> over "systemc.h". The latter contains some questionable C++ coding practices w.r.t. header files, but remains in the standard for legacy code. 2. The installation should have pointed you to an installation directory, where you will find an include/ and lib/ directory. You should at the include/ directory's path to your compilation switches, and add the library directory (usually lib/ or lib-linux/) to your linker options. 3. Make sure you compile everything with the same compiler and C++ standard version. 4. During the install process you should find some instructions to specify where to install. Personally, I usually choose $HOME/.local/apps/systemc (creating the intermediates as needed). That way I won't need root privileges to install. Personally, I find using the cmake build approach smoother than autotools. Want to learn more? We have some free tutorials and other resources under https://doulos.com/knowhow/systemc/ (Full disclosure: I work for Doulos as an instructor.)

I agree with @andy for dealing with sc_signal or sc sc_fifo. If using TLM, you would use a tlm_generic_payload with a pointer to your data, an appropriate data length and a socket width of 256. The data for that case would be arranged in its natural order. It really depends on what the model is doing with the data. If you don’t need to do arithmetic with the 256 bits, you might be better off using sc_bv<256> instead, which still supports logic operations. sc_lv<256> would be useful if modeling a tristate bus with sc_signal_resolved.

There are several techniques. Temporal decoupling is one. DMI is another, which allows a processor to access memory much faster. You must keep in mind the use cases these intend to solve. LT models are for the creation of VM's used by software developers to focus on firmware development, and as such sacrifice timing accuracy in favor of performance. Software developers want register and functional accuracy. Generally, programmers do not care about timing precision. If performance analysis is desired, then use of AT modeling is better suited. A key trick to performance is avoiding the use a real clock (i.e., sc_clock). Clock's produce two context switches per cycle regardless of whether they are actually be used. The trick is to use strategic waits instead. For instance, a timer that is set to provide an interrupt in 10ms, with a conceptual 10ns clock, can simply schedule a notification 10ms into the future and save 1,999,999 context switches. By saving the start time of the timer, you can even allow code to interrogate the current time count by simple calculation (e.g., counter = original - ( current_time - start_time ) / 10ns ). A very important question for any model must be kept in mind: What problem am I trying to solve and what features need to be preserved in order to get the answer?

There is not a better than the other scenario. The question that must be asked is: What are you wanting to do with your model? 1. Virtual platform for early software development? Base protocol is likely sufficient. 2. Timing analysis of a chip architecture using Arm interconnect? Then you need a custom protocol for AXI or whatever bus technology is planned.

SystemC ports are designed to bind to a very specific signature. The idea that a 15-bit port could bind to a 17-bit port is considered dangerous. That was an intentional design decision of the design committee. The goal was to avoid mismatched signals in hardware that would be synthesized from SystemC. In a similar vein, some folks want to split out bits and write to single bits, but cannot that directly. It is possible to write channels that make the conversion.

Without seeing your code, this is impossible to determine. Perhaps you can share on edaplayground.com

The reset_signal_is() method stop any currently executing process when the designated signal channel becomes active (high or low depending on the arguments). Then it resets the context of the thread-style processes so that they are called from the beginning. It does not actually reset or change the values of any other channels. It does not need to do that for the method-style processes because they don't hold any state like threads do.

Have you considered reading the specification (IEEE-1666-2011) - see section 7.3 String Literals on page 199? Have you tried: `maddress->write(sc_bv<40>("0x8979E54200"));` and had problems? Are you properly trained in C++? Note: Using `operator->` is preferred over `operator.`

Been there and done it many years ago. Requires deep knowledge of host OS mutexes (std::mutex), std::condition_variable, use of sc_core::async_request() and optionally Linux signals in a custom primitive channel. Used it when modeling a video application.

It can and should be used both ways. You can verify/validate register behavior (e.g., write via the front door and verify via the backdoor) and use it to configure IP via the backdoor. The reason for using it to configure components is that backdoor accesses are faster than frontdoor accesses, and performance is important when you consider the millions of things to be tested.

Derive from sc_signal and overload the read method to call write before returning the previous value That would be awkward because writes are not seen until the next delta cycle and there is no way to guarantee which process goes first. Processes are not differentiated on the basis of module when executed by the SystemC Kernel (and there is intentionally no mechanism to do so since it would violate the premises of event driven simulation.) I suppose you could setup a module based mapping and determine the owner during the update cycle. You could perhaps defer reads to block until the next delta cycle. Derive from sc_signal and provide a new method to signal an event. Not sure how useful this is if you cannot write a value. Same as #3 All of this requires you to have a deep understanding of the event-driven simulator kernel and be capable of writing your own primitive channels. You should thoroughly understand how sc_signal works. You might find the following useful: https://github.com/dcblack/SystemC-Engine (or sign-up for Doulos' Fundamentals of SystemC course). Notice that this is all simple behavioral modeling using C++ constructs. If you do not know C++ well, then you need to get educated. C++ is a relatively complex topic and you won't learn everything about it in a forum. Your best bet is to educate yourself: read a book, take a course and apply it.

This looks suspiciously like a professor’s homework assignment or exam. the answer is yes and there are many ways to do it.

Likely because it is a school assignment or possibly because they are using a tool that cannot synthesize threads. Hopefully, not because somebody told them that SC_METHODs are faster than SC_THREADs. That depends heavily upon the implementation of SystemC itself. I know of cases where it is the other way around (SC_THREAD is faster than SC_METHOD).

You need to call sc_trace for every individual signal or variable you wish to trace. If you have custom data types, then you need to overload sc_trace with your own type.

Remove the char** env from the sc_main() signature. It's not supported by SystemC (nor in main for that matter). If you are trying to pass the environment variables, then pass them via a global variable or (better) use the library getenv() function. What toolset (compiler and host OS) are you doing this in?

I was unaware that Verilator had a flow to allow mixed simulations, but more pointedly: main should call sc_main (not the other way around) Usually we don't write main because SystemC provides it to automatically call sc_main main only has two forms in my experience: int main( int argc, char* argv[]) // normal int main() // usually for embedded or simple situations You really should return a value from main. Either 0 (gives not much information and implies success) or a calculated value resulting in 0 (success) or 1 to 127 (failure)

From a system point of view, you should consider which resources are being shared (specific address ranges). You should detect any shared accesses (read or write), and perform explicit synchronization on any shared access.

To do this you would need a have an sc_process to observe the situation. You can of course traverse the design hierarchy and obtain a list of all processes; however, you will not be able to ascertain why they are suspended. Your question is a bit vague. Perhaps you could put a working code example on EDAplayground.com and give us a link to consider. You could record the __FILE__ and __LINE__ in every process just before suspension in a process specific variable.

Use sc_signal_resolved instead of sc_signal<sc_logic>.

We await your rewrite of the SystemC kernel. Please make sure it can pass all of the regression tests.

All, if you rewrite the core. SystemC is simply a C++ library. I routinely use C++17 with SystemC. I will suggest we don’t use C++20 for a few more years because: 1. Compilers are still too immature 2. Some of the changes are quite radical and will take time for user education (e.g., coroutines, modules, and ranges) 3. Some changes would possibly require to much refactoring (e.g., modules)

Quite the opposite. Because SystemC uses cooperative multi-tasking (which also implies single threaded in the OS world), then coding is much simpler. That is precisely why they chose to use cooperative multitasking. This is identical to the model used by Verilog, SystemVerilog and VHDL. Hardware engineers do not want to be concerned with mutexes and data sharing. Furthermore, most of the time (99.9%) we simply don't worry about delta cycles. The time when you might worry about them is when you have to write your own primitive channels. From reading your questions, it seems clear that you are not following the simulation model very well. You need to keep in mind that SystemC processes are not pre-emptive. There is no way for a process to interrupt another process. One other area, which gets some programmers into trouble is when they try to introduce OS parallelism into the picture without a clear understanding that the SystemC scheduler is NOT OS thread-safe. That requires special handling and is an advanced topic. SC_THREADs and SC_METHODs are not real OS processes. SystemC processes cooperate with one another by yielding at points when they are ready to give up control. The yielding statement is `sc_core::wait` with all its overloads

You have a race condition at 2ns, 4ns,… By chance the second process is last. I suggest you study https://github.com/dcblack/SystemC-Engine