Jump to content

David Black

  • Content Count

  • Joined

  • Last visited

  • Days Won


David Black last won the day on January 22

David Black had the most liked content!

About David Black

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2,071 profile views
  1. 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.
  2. 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 .
  3. 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.
  4. 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.
  5. 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.
  6. 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;
  7. 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.
  8. Possibly editing using a UTF-8 editor and inserted 3 weird characters.
  9. 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..]
  10. As the error message says, you are missing the required sc_main subroutine. You did not show your invocation line, which could be helpful.
  11. Doulos UVM Golden Reference Guide Kindle Edition: https://www.amazon.com/dp/B01HDQEN0Q/ref=cm_sw_em_r_mt_dp_U_4YeXDb7QW80NC
  12. No for a port; however, you could accomplish the goal with an sc_port< sc_signal<T> >
  13. 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>.
  14. 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.
  • Create New...