David Black

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.

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.