David Black

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.

sc_core::sc_signal<sc_dt::sc_bv<32> > register[32]; ... SC_METHOD(prc_assign_rf_reg); for(int i=0;i<32;++i) { sensitive << register[i]; } Above should work from a simulation point of view, but probably fails the synthesizable test. Tools might support it. Unfortunately, despite the existence of a Synthesizable subset standard, you are really at the mercy of each implementation vendor since they usually vary from the standard in various ways. The standard simply provides a starting point they attempt to match, but then add their own extensions and/or exceptions. RTFM. If they ever get around to doing modern C++, they could easily enough implement C++11's std::array container, which is conceptually very synthesizable. Then you could possibly even do: #if __cplusplus < 201103L #error Requires C++11 or better #endif #include<array> std::array<sc_core::sc_signal<sc_dt::sc_bv<32>>,32> register; ... SC_METHOD(prc_assign_rf_reg); for(const auto& reg: register) sensitive << reg; // or possibly with changes to synthesizability rules sensitive << register;

No. For analog, SCV has not solid application.

You specified a signed number which was converted to unsigned under rules of twos complement. Change “0x to “0xus and you will obtain desired results. See section 7.3 String literals on page 199 of IEEE-1666-2011 for more information.

Possibly editing using a UTF-8 editor and inserted 3 weird characters.

Observation: gets() is now considered forbidden in C since it is the cause of many hack attacks to create buffer overflow. get_s is recommended because it puts an upper limit on the number of acceptable characters. Although C++ std::string can handle large strings, it could still be an issue. I am not saying you should never use it, but please be aware. I realize our SystemC activities are usually confined to safe internal use only situations, but I can forsee examples on the open web that might lead to an issue. [Note: I teach C/C++ security courses in addition to my SystemC activities..]

As the error message says, you are missing the required sc_main subroutine. You did not show your invocation line, which could be helpful.

Doulos UVM Golden Reference Guide Kindle Edition: https://www.amazon.com/dp/B01HDQEN0Q/ref=cm_sw_em_r_mt_dp_U_4YeXDb7QW80NC

No for a port; however, you could accomplish the goal with an sc_port< sc_signal<T> >

Write your own channel, which is really quite simple(*). You could provide a template specialization of sc_fifo as a convenient and familiar interface. * It's just C++. We show students how to write their own FIFO channel as part of our Fundamentals of SystemC course <https://www.doulos.com/content/training/systemc_fundamental_training.php>.

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.