David Black

Instructions are in the README and should be clear enough. Let me know which instruction is puzzling. OSX uses a simple bash shell by default, unless you are on Catalina. Which version of OSX are you on?

With the advent of OSX 10.14.x Mojave and OSX 10.15.x Catalina, it becomes a little more complicated because you will need to give permissions to the tools (requires admin privileges), but it is fairly straightforward. If you find the OSX installation too challenging you could try a Docker installation of Ubuntu or a Virtual Machine (VM) such as VirtualBox with Ubuntu. Personally, I am using Mojave and the Cmake install quite successfully. Being a bit old school, I use MacVim (GVim for Mac) as my text editor, and iTerm for my terminal.

I'm sorry, but I really think that if you upgrade your C++ skills, most of these errors will become obvious. Q: Have you tried putting your code onto http://www.edaplayground.com? You can then share a link to your code, which will make it infinitely easier for somebody to comment on the errors. It's free.

Yes, but you need to use a real string (not empty). Usually, the instance name matches the name of the instance itself. For example: #include "top_module.cpp" //< Real code goes in here #include <systemc> // Minimal sc_main function int sc_main(int argc, const char* argv[]) { Top_module top_instance{ "top_instance" }; sc_core::sc_start(); return 0; }

Depends on what the problem statement is. Likely as not, the test will rely on some type of SystemC ports for the inputs.

SystemC is simply a C++ library. The syntax of SystemC is C++. To meet the requirement of using SystemC you would probably just place the C++ inside a SystemC SC_THREAD method. SystemC is easy to wrap around C or C++. This is sounding more and more like you are doing homework for a class, which means you need to get educated. This forum is not a place to have us do your work for you. First, go and learn C++. I don't mean minimal C++ either. SystemC uses plenty of advanced constructs of C++ including OO concepts, generic programming concepts and coding patterns. You have very little hope of being a successful SystemC coder if you don't know C++ well. Second, take a class on SystemC or read a good book. Take time to do the examples and understand how it hangs together. Shy of the above, find another field of endeavour. In any case, please do not ask people to do your homework. We have enough on our plates as it is, and you will do your future employer no favor if you slide by with minimal SystemC skills. Where to take a course? Try https://www.doulos.com/content/training/SysC_training.php (my employer) Where to find a book? Try Amazon. I wrote a book (slightly dated: SystemC: From the Ground Up) that will get you started. Or search for others. But a SystemC course or book will not help much until you become proficient at C++.

You really should not use an empty string for the instance name.

This looks like homework and a trivial FSM. Most of the coding would be simple C++. Good luck!

For your specific problem just Google "C++ read CSV": https://thispointer.com/how-to-read-data-from-a-csv-file-in-c/ https://www.gormanalysis.com/blog/reading-and-writing-csv-files-with-cpp/ For C++ try: https://www.geeksforgeeks.org/c-plus-plus/ http://www.cplusplus.com/doc/tutorial/

This is not a SystemC issue. This is a C++ issue and you need to go to a C++ forum to improve your C++ skills. There are plenty of tutorials of various types for this. Pretty much any C++ solution will work.

The syntax wait(), which calls void sc_core::wait(void), assumes a static sensitivity list, but you have not setup a static sensitivity list that I can see. Also, you are sending and immediate notification, which I somehow doubt you really grasp the implication thereof. You need to learn about the fundamentals of the SystemC scheduler to get this working correctly.

Keep in mind that SystemC's kernel is not threadsafe. SC_THREAD and SC_METHOD processes are completely different animals than OS threads as well. You can use the async_request_update() method to interface into SystemC from the outside. From the inside you can of course stall everything in the SystemC side because it is cooperative multitasking system. In either case, you will need to use appropriately setup mutex to protect shared resources. Due to differences in the concept of time (simulated vs real), you will also likely need to use mailboxes for communication. You might also what to consider scheduling events to happen at the end of a delta cycle (ie. event.notify(SC_ZERO_TIME) or perhaps even a non-zero time in the future.

@sas73 and @tymonx - Feel free to contact Accellera itself and try to argue your case, but the Accellera is a membership based standards organization and not subject to the whims of the general public. Large electronics and EDA companies depend on their experts who are assigned to work on those standards, and many significant tools and designs are based on their work. If your employer feels strongly about this topic, perhaps they will consider joining the Accellera organization in order to contribute to the discussions. Standards discussions are often long and drawn out with many inputs. Membership at the contributor level is not free because they want serious contributors and because the organization has funding needs to promote the standards.

Please show your code and describe where you are simulating. The error messages are interesting, but do not completely tell the story as error messages often show up pointing to the wrong code.

There is no default_time_unit in SystemC; however, the sc_clock default constructor does supply a default value of 1 ns. Be careful you don't set the time resolution larger than 1 ns, if you are going to use the default time. You could of course be more explict: sc_time clock{ "clock", 1, SC_NS }; //< assumes C++11 or better and using namespace sc_core

What attributes are you modeling? Seems to me you would measure throughput and latency, but it might be meaningless if you are not modeling time. What assumptions are you making about the implementation technology? If somebody asked you to measure performance, ask them.

First observation: sc_main is not a module. I would suggest you put them in a real top module; however, that is likely not the real problem. Second observation: you need to show us more code. WHat you have showns is insufficient to analyze. For example, we have no idea what the port connectivity is nor how it is connected. If you have TLM, then you need to show those aspect. We would need to see at least the contents of pe and cpu for the information you have shown.

This is like an OO or C++ question. If you draw out the class diagram including the classes you are interested in and their relationships, that should answer your question. I would suggest using doxygen on your code base to see what it observes.

Create an sc_vector<sc_signal<bool>, 4>, but then you have to assign and deal with four separate signals.

Synthesizability rules are ultimately up to the HLS synthesis vendor, and they are definitely different between vendors. The synthesizable subset standard is simply a guideline of commonly agreed upon constructs that either clearly able to be synthesized (e.g. sc_signal) or not (e.g. new and delete). Every synthesis tool will have some variance. Please refer to your sythesis vendor's reference manual to learn their rules. If that fails, contact their support. Simulation does not guarantee synthesizability.

Sc_signals are not data types. Sc_signals are channels, which represent hardware being modeled and are used as mechanisms to transport data between processes. As such, channels are only allowed to be created during the “elaboration phase” that occurs prior to simulation starting up. Also, strictly speaking, sc_port’s are not normal pointers; although, an underlying mechanism uses pointers for efficiencies sake. The operator->() is overloaded on sc_port<IF_TYPE>. You could of course create an sc_vector< sc_signal<T> >, N >, where N was a maximum of the number of signals required and then allocate specific index to each spawned process.

I believe the original intent was to be able attach "attributes" in the general sense to modules, channels, ports, processes and other "objects", which could be used for unforeseen or unaddressed needs in the future. For instance, if you wanted to add power information to certain modules (e.g. static leakage), and then add some type of processing to analyze power consumption either dynamically or later. This has been used internally at a few companies and I hope the feature will stick around. Although, the CCI (Control, Configuration & Inspection) WG (Working Group) of Accellera may argue their "configuration" solution may better address these ideas. [Personally, I have not seen the current CCI solution to work on all platforms yet (implementation needs more work) and the documentation needs more work. I think there are some issues with the version of SystemC and C++ compiler features.] You download/install/test CCI from https://accellera.org/downloads/standards/systemc .

The behavior of SystemC matches what I expect, but is not what you are wanting to do. My suggestion of how to write the output holds; however, that will not fix the error. My suggestion does make it likely that you might wonder what the write() method does and not fall prey to the assumption that assignment is simply assignment. If you want to move the process to the end of the current delta-cycle, you can insert: wait(SC_ZERO_TIME); just prior to where you display the value after writing it. If you want to avoid two calls to the SC_METHOD process, add: dont_initialize(); after the SC_METHOD declaration. Do not apply this into the SC_THREAD though or that piece of code will never run. Suggestion: Get a book on SystemC such as SystemC: From the Ground Up (I might be biased 😉) and read its description of the simulator.

By default all processes are called once at time zero. Outputs on sc_signal are updated after the end of the delta cycle, which consumes no simulated time, but causes your method to be scheduled to run at the same time. What appear to be blocking assignments to the programmer's eyes are in fact non-blocking assignments that schedule updates to happen at the end of the current delta cycle. Assuming your bus_o is an sc_in<int>, which is a specialized sc_port< sc_signal_inout_if<int> >, then bus_o = VALUE; turns out to be equivalent to bus_o->write(VALUE); You need to learn how a co-operative multitasking event driven simulator works, and then you will fully understand.

You are missing at minimum a single wait() in the infinite loop. SystemC is an event driven simulator and as such concurrency is modeled using co-operative multi-tasking. An infinite loop is an infinite loop. No pre-emption.