Jump to content

David Black

  • Content Count

  • Joined

  • Last visited

  • Days Won


David Black last won the day on November 30

David Black had the most liked content!


About David Black

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1,401 profile views
  1. David Black

    Array when declare port for model

    SC_NAMED is not part of IEEE 1666:2011, but rather a newly introduced (SystemC PoC 2.3.2) convenience macro looking for feedback and possible inclusion in the next version of the standard.
  2. David Black

    Array when declare port for model

    The proper SystemC notion of a port is very different from VHDL or Verilog. Ports are really a very fancy type of pointer used to direct method calls to channels. Note that channels are not signals or wires. Channels are classes that provide public methods to communicate safely between SystemC processes. The sc_core::sc_int<T> port is actually a partial template specialization for the proper SystemC port, sc_core::sc_port<T>. Ports are always bound to SystemC interfaces. A slightly more complete way of expressing this would be: using namespace sc_core; sc_port< sc_signal_in_if <bool> inA; // Port for connecting to a signal channel capable of communicating a single boolean value. Please note that you don't really initialize ports in the sense of assigning an initial value, because ports do not carry values. You do initialize ports in the sense of C++ construction and subsequent binding of ports to channels. SystemC ports have up to three template parameters (although the interface is normally the only one needed) and normally a single optional constructor argument (the sc_object instance name). If very much of the wording I've chosen above is foreign to you, then you probably don't have enough C++ programming background yet. Before tackling SystemC you need to be proficient at C++ (not C). None of your three attempted examples appear correct, but I infer that you may be interested in a port for communicating five bits over an sc_signal channel. This would be done in SystemC as follows: sc_in<sc_int<5>> inB1; or sc_port< sc_signal_in_if<sc_int<5>>> inB2; Note that the following would not work: sc_in<bool> inC[5]; // Attempt to create an array of 5 ports for 5 different sc_signal<bool> connections This is due to the unfortunate manner that array elements are constructed, and SystemC's requirement that component objects must be constructed with unique instance names. I don't have time to go deeper, andI suggest you either get a good book on SystemC or take a formal class. If you don't have a solid grasp of C++, please be certain to get educated on that as well.
  3. You would need to write a wrapper class with debug aids builtin. A sketch might be: struct debug_mutex : sc_core::sc_mutex { void lock( void ) override { auto requester = sc_core::sc_get_current_process_handle(); INFO( DEBUG, "Attempting lock of mutex " << uint_ptr_t(this) << " from " << requester.name() " at " << sc_time_stamp() ); this->sc_mutex::lock(); locked = true; locker = requester.name(); time = sc_time_stamp(); changed.notify(); } void unlock( void ) override { auto requester = sc_core::sc_get_current_process_handle(); this->sc_mutex::unlock(); time = sc_time_stamp(); locked = false; locker = ""; changed.notify(); } // Attributes bool locked{ false }; sc_event changed; sc_time time; string locker; }; I have not tested above. NOTE: I have a macro INFO that issues an appropriate SC_REPORT_INFO_VERB with the above indicated syntax. Replace with your own. Never use std::cout or std::cerr if coding SystemC.
  4. David Black

    SystemC 2.3.3 fail "make check" in MacOS

    I installed on High Sierra myself and now on Mojave without incident. At the risk of a lot of data, perhaps we need to see examples/sysc/test-suite.log?
  5. David Black

    SystemC 2.3.3 fail "make check" in MacOS

    You need to provide more information: - OS name and version (e.g. Ubuntu 18.04) - Compiler name and version (e.g. GCC 7.1)
  6. David Black

    libsystemc-2.3.3.so cannot open shared object file

    Please show results of: ls -l $SYSTEMC_HOME/lib-linux64/
  7. David Black


    This appears to be homework for school. I suggest you try reframing your request.
  8. David Black

    Benchmarking RTL simulation with SystemC

    Is it really the size of the primitive, or the size of the data in play that's the issue? Also, if you could relocate the data to in close proximity to one another, then the caching would be potentially more efficient since it is the cache line size and utilization that has a large impact on performance. Perhaps a redesign of primitives would change this for RTL; although, it might take some serious rethink to make it work. If construction of sc_signal<bool> invoked some pooling and data aggregation. I would bet a saavy C++ programmer could improve this. For what it's worth, I have had some ideas that might make gate-level sims possible in SystemC too.
  9. David Black

    Temporal Decoupling

    One trick to making temporal decoupling work is that if you have shared resources (i.e. shared memory between two initiators), you will need to do synchronization on demand for reads to the shared areas. To be clear, just because a target is accessible from two initiators does not mean it is shared. For example, in many SMP systems there might be a 32MB memory visible to two processors; however, the design of the software may only intercommunicate using a designated "shared" region of 2MB by agreement. Each processor might have its own "private" 15M region that is off-limits to the other processor by design intent. Suppose we call the processors A and B. If they stick to their private regions of memory, no problems happen; however, if processor A attempts to read a section of the shared memory to obtain information provided by processor B, then synchronization of local time is necessary. This is because processor A might be temporally ahead of the time for processor B, which ends up writing to the area A is interested just prior to A's reading it. Unless they synchronize, processor A won't see the new value from processor B. For some software systems this might not be a problem, but there are times when synchronization is demanded to ensure correct operation. So success in using temporal decoupling requires full system hardware and software knowledge.
  10. David Black

    Seeking Feedback on Datatypes

    Actually, it adds a lot of value. std::array can be passed by reference in a function call and the function can then determine the proper size of the array. This is much better than passing pointers, the C standard. You can also copy an array, which should be synthesizable, which reduces coding and greatly improves readability. It should be possible to implement some #include <algorithm>s on std::array too. Also, you can have bounds checking for additional safety; although, that aspect is probably not synthesizable. Additionally, constexpr should be quite helpful for the synthesis aspect.
  11. David Black

    Seeking Feedback on Datatypes

    How are the AC types licensed? Are there any copyrights or patents to be concerned with?
  12. David Black

    Method sensitive with sc_inout port

    Your SC_THREAD has no static sensitivity, but you call the signature `wait( void )`, which requires static sensitivity. Did you mean `wait(in1_InOut->changed_event())`? You call SC_SIGNAL_MANY_WRITERS, which strongly suggests to mean that you don't understand sc_signal channel. Probably, you should be using sc_signal_resolved.
  13. SC_UNCHECKED_WRITERS also means allowing nasty race conditions.
  14. I think this all boils down to use cases: Programmer wants the fastest possible implementation of a virtual platform to develop their software on that is register accurate and functionally correct. Solution is to use Loosely Timed (LT) modeling style. Must maintain functional/register accuracy, but try to reduce anything that slows down simulation speed. Things that slow down simulation speed include I/O (logging messages), context switching, copying data unnecessarily, arbitration and using the bus in general. Architect wants to know if a particular configuration will work when taking into account all data traffic, which requires relatively accurate timing information on bus accesses. Solution is to use Approximately Timed (AT) modeling style. Speed of simulation is secondary, but speed of model creation is still high. RTL might provide the information, but has too much detail and takes too long to create. Skipping the bus (i.e. using DMI) is inappropriate as we need to see all bus traffic. Arbitration aspects are necessary. We can still minimize I/O somewhat, but some context switching is required to provide valid timing information. Notice that I did not mention blocking (B) vs non-blocking (NB), because that is not the issue. Blocking style is actually easier to code and avoids context switching required by AT, so it is used for LT style. Interestingly, we try to avoid actual blocking (using wait) when coding b_transport in order to improve performance. Temporal decoupling and DMI are simulation speedup techniques for LT and completely inappropriate for AT. If your bus supports it, we can reduce the number of NB calls to one, but many buses need to be modeled with more than one call. It is all very protocol dependent. It is also potentially tricky to get all of this correctly coded. Some buses like Arm's AXI require additional phases to properly represent all of the timing information needed.
  15. David Black


    Sorry, but I'm bit too busy for that. As I indicated, choice 1 is the best option. It is both easier and safer. Coding mistakes with the other options are highly likely and as a non-standard approach, you likely won't get any support or help when it breaks. Something you might not have considered: You can easily pass configuration information to your SystemC designs in many different ways: Access command-line options (i.e. like Linux) using sc_argc() and sc_argv() -- See https://github.com/dcblack/sc-command-line Test and get values via environment variables. Read a configuration file. Prompt the user at the command line.