Jump to content

David Black

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by David Black

  1. David Black

    libsystemc-2.3.3.so cannot open shared object file

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


    This appears to be homework for school. I suggest you try reframing your request.
  3. 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.
  4. 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.
  5. 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.
  6. David Black

    Seeking Feedback on Datatypes

    How are the AC types licensed? Are there any copyrights or patents to be concerned with?
  7. 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.
  8. SC_UNCHECKED_WRITERS also means allowing nasty race conditions.
  9. 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.
  10. 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.
  11. David Black


    You cannot. SystemC cannot be restarted without exiting and restarting the entire program. That said, you have three choices: Call your executable repeatedly from a script, saving the data in uniquely named log files. Same as 1 except you could use Linux 'exec' call to chain simulations together; however, be very careful with this. Probably #1 above is simpler and better for that reason. If you are able to deal with only having a single elaboration, then you could do the following: Create a global start_time_offset variable that you update between calls. Make sure you report/act-on time as if it is sc_time_stamp() - start_time_offset. Observation: #1 is still simpler and there are really no real advantages to this approach.
  12. Use a multi_pass_thru_socket and a simple loop (incomplete - extend as needed): #include <systemc> #include <tlm> #include <tlm_utils/simple_initiator_socket.h> #include <tlm_utils/multi_passthrough_initiator_socket.h> struct Broadcast : sc_core::sc_module tlm_utils::simple_target_socket target_socket<>; tlm_utils::multi_pass_through_initiator_socket initiator_socket<Broadcast>; SC_CTOR(Broadcast) : target_socket("target_socket") , initiator_socket("initiator_socket") { target_socket.register_b_transport( this, &Broadcast::b_transport ); } void b_transport(tlm::tlm_generic_payload& payload, sc_time& delay); }; void Broadcast::b_transport(tlm::tlm_generic_payload& payload, sc_time& delay) { for (size_t i=0; i<initiator_socket.size(); ++i) { initiator_socket[i]->b_transport(payload, delay); } } Of course you need to be careful with this because technically you probably need to copy the payload (i.e. create an individual transaction per target). If it is a an IGNORE_COMMAND and you use appropriately designed extensions, then it might work.
  13. David Black

    learning systemc

    Step 1: Become a proficient C++ coder. You should be very comfortable with C++ before tackling SystemC. Casual or novice knowledge is not good enough. For a list of topics, see alternate discussion on the topic of learning SystemC. Step 2. Review step 1 and make sure you can write code for each topic without hesitancy. Step 3. Read SystemC: From the Ground Up [Note: I am an author and therefore biased, but certainly not because it brings me any income worth noting]
  14. David Black

    learning systemc

    Step 1: Become a proficient C++ coder. You should be very comfortable with C++ before tackling SystemC. Casual or novice knowledge is not good enough.
  15. Looks to me like you are declaring sc_clock objects inside the constructor on the stack, which will then be immediately destroyed at the end of construction. They should be class members. Also, you appear to have the intent of using PHREADs; however, SystemC is not thread-safe unless you take special precautions. I would also suggest you consider using std::unique_ptr<> instead managing pointers yourself. Safety first.
  16. TLM2 is completely different from RTL type of connection. Interface won't work. Nor is there timing you can count on since it could be either AT or LT without timing. You also need to specify if you are interfacing between SV and SC or is this native SV UVM to UVM TLM2.
  17. David Black

    A void value confusion

    Based on what I see, the * shouldn't even be there at all since the -> takes care of it. Either use: mNeuron->dendrit[index].write(value); or (*mNeuron).dendrit[index].write(value); However, I'm more concerned that you're not using ports to access members of a module (assuming Dendrit_Set is not part of module Neuron). That violates a rather fundamental principle of SystemC. It's legal C++, but questionable SystemC.
  18. David Black

    SystemC linking problem in Ubuntu

    On the surface I would say you have a problem with your own code, but I cannot say much more because you did not share the code with us. At a minimum I would need to see main.cpp, but if you have other source files (e.g. state.cpp, which I would expect since any self-respecting C++ coder would put each class into its own CLASSNAME.cpp and CLASSNAME.h (or .hpp) file). Note: This has nothing to do with Ubuntu and likely little to do with the SystemC version.
  19. David Black

    Passing event to SC_CTHREAD macro

    The only use I see for SC_CTHREAD is synthesis tools, and this is really just a legacy issue and a vendor tools issue. The same SC_THREAD could have been used for posedge_event. This would change the coding of wait in your code though: wait(5); // 5 clock delay becomes for(int i=5; i--;) wait();// prior to C++17 which could easily be addressed with: void nWait(size_t n) { while(n--) wait(); } and allows nWait(5);
  20. I went and looked at the website where this stuff was supposed to be and found problems. I then dug around and found an archived copy, did a quick sanity check, and I've now published it on GitHub under github.com/dcblack/SCFTGU_BOOK As noted, I am working on a modern version, but time is limited.
  21. David Black

    Implement sc_trace for std::string

    Perhaps you would be willing to share your work as an Apache 2.0 licensed github project with the minimal code needed and a screen snapshot of the results.
  22. David Black

    reset method or thread

    Reset is accomplished by throwing an exception. You cannot perform cleanup *before*, but you can perform cleanup on the way out in two manners. First, automatically created objects will of course run their destructors as guaranteed by C++. Second, you can catch exceptions by strategic placement of try-catch blocks and looking for the appropriate sc_exception. It is required by SystemC that you rethrow after catching; otherwise, you will corrupt the SystemC kernel.
  23. David Black

    sc_spawn and anthoer process

    sc_spawn creates same kind of processes as sC_METHOD, SC_THREAD, etc, but is not limited to the elaboration phase. Please either read the official documentation for IEEE-1666 (available as pdf free via Accellera) or get a good book on SystemC or take a class.
  24. David Black

    Non Constructible but Copyable !

    A derived class could inherit this.
  25. David Black

    make check return fail

    I am able to reproduce the problem and will attempt a fix. Unless you are using async_request_update() in your code, you can safely ignore this problem for now. CORRECTION: While there is a bug with the following deprecated feature issue, this does not solve the problem. Stay tuned for a real fix. There is a bug in the implementation of SystemC due to Apple removing support for POSIX sem_init, which is a non-required API by the POSIX standard. See <https://stackoverflow.com/questions/1413785/sem-init-on-os-x/24617282> for details. [Pure speculation: I suspect the reason for removing support was that Apple has recently moved to an all 64-bit coding model. Potentially because they are positioning themselves to be able to port quickly to Arm v8A lacking Aarch32 on certain hardware.] When building on OSX using Cmake I noticed a clue: I use the adage, "A warning is usually a potential bug leading to a real error." Never ignore warnings from compilations. Yes, I know there is a lot of code out there with superfluous warnings. Shame on them for leaving them in. So if you see a warning, track it down. If it is truly a don't care (rarely), then it can be overridden with a #pragma. Almost all warnings can be fixed with proper coding. I am going to attempt a fix to sc_host_semaphore.h, but if you're in a hurry go to Linux.