Jump to content

David Black

Members
  • Content Count

    466
  • Joined

  • Last visited

  • Days Won

    103

David Black last won the day on November 5

David Black had the most liked content!

About David Black

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2,530 profile views
  1. You should call sc_stop exactly once. Then you won’t get any errors.
  2. I believe the original User Guide was removed; however, there are plenty of resources: There are many proper examples with documentation (PowerPoint or Markdown or README.txt) inside the Proof of Concept download package (obtain from https://accellera.org/images/downloads/standards/systemc/systemc-2.3.3.tar.gz) Books such as SystemC: From the Ground Up 2nd Edition (myself et al), SystemC Methodologies and Applications (Muller et al) The standard itself is fairly readable (obtain free from https://ieeexplore.ieee.org/document/6134619) Somewhat more important for many is C+
  3. Yes, interleaving is possible in such cases the delays can be modeled but you will likely want to add some type of protocol extension (e.g., to track the transaction id when breaking up a response) and likely need to create a custom protocol as defined by the standard. The four timing points of TLM 2.0 are meant to define a basic starting point for protocols. You can also update timing in the interconnect and even deal with arbitration issues by splitting up transactions, but this is not typically done. Of course if you have a custom protocol, there are implications to interoperability and you
  4. What version of SystemC do you have? Did you compile SystemC with the same versions?
  5. I think it is simpler than you think. Just set the data length to reflect the size of the burst. In the target you can set the latency to reflect the burst size based on socket width and byte enables if used. Sure you wont see the timing of the burst internals but unless your bus protocol allows intra-burst interlehaving, this should not be a problem. Remember that TLM is only cycle approximate. This provides faster simulations that are reasonably accurate. Example: socket width 16 bits, transfer length of 32 bits. Obviously takes two clocks.
  6. The syntax of SystemC is C++. C++ supports float, double, and long double. The basic idea of SystemC is to raise abstraction above (away-from) RTL to obtain faster running simulations. So modeling a pipelined multiplier can be quite trivial using three SystemC processes: Grab inputs and schedule to be placed into pipeline on the next clock using sc_event. Schedule an sc_event_queue for stages*clock_period and place calculation into queue. When event queue triggers, pop the queue and output the value. If you need to deal with floating point status, that can be placed in th
  7. SystemC FIFO's represent hardware and as such may only be created during construction of a model. After elaboration closes, you are not allowed to add more fifos. None of your code examples above are complete, so it is fairly hard to give you a complete answer. Perhaps you could put your design on https://edaplayground.com and share a link with us. For details on phases of SystemC (e.g. elaboration) see IEEE-1666-2011.pdf, which you can obtain through Accellera.org.
  8. Usually, we compile the client code to run on a simulated processor, usually known as an ISS (Instruction Set Simulator). This will give you the correct behavior. The ISS will call wait periodically and thus do what you desire. One other possibility that I hesitate to suggest is to run your system code in a separate OS thread (not a SystemC thread) and then interact with it via proper thread-safe semantics (probably using a custom primitive channel utilizing asyc_request_update). I can reasonably expect this will not provide satisfactory results because it will not provide the proper timi
  9. In a cooperative multitasking environment (e.g. SystemC), it is impossible to have an infinite loop without yielding. The only yielding method available in SystemC threads is the wait() method; therefore, you have self-defined an impossible problem. SystemC processes (SC_THREAD and SC_METHOD) are NOT the same concept as OS processes or threads. They are constructs of the discrete event driven simulator known as SystemC. Now it is possible in some cases to trick the code, which I have used for some cases. For example, if your FW_main code where to attempt some I/O with a common method
  10. Be very careful with terminology here. If you are asking about host simulator OS threads, the answer is pretty much no. SystemC is a discrete event driven simulator using cooperative multitasking (which greatly simplifies coding) and is not thread safe. You might want to look at what is contributing to the slowdown. You should probably use a software profiler. There are two issues that commonly cause problems in SystemC: I/O. More specifically output to the log file. If your simulation has lots of SC_REPORT_INFO or std::cout producing large logs at run-time, then you will defin
  11. I don't know where you got that specification, but it looks suspiciously like a university project. Also, whoever is using the word 'static' is not using the word correctly. Nor would or should that approach ever work. The diagram implies a hierarchy of SystemC modules with a cluster module containing several DME-array modules, which in turn contain DME, DMA and MemType2 modules. These could of course be modeled without the illustrated boundaries, but it would add unnecessary complication. The outermost module (Cluster module) would have one each of an initiator and target TLM-2.0 socket (NOT
  12. Nothing wrong. Your output will be available after the delta cycle completes. You can view the new value in the next delta cycle. The problem for you conceptually is that you think 'S_val_out = expression' is a blocking statement. In other words, you expect the value to be transferred to the current value of S_val_out at the end of the assignment. Actually what is happening is akin to: S_val_out->write( A_val_in->read() +B_val_in->read() ); External to your sum class object, the S_val_out is bound to a channel sc_signal<T>, where the write() method is implemented. T
  13. No problem. Glad you got what you needed. For what it's worth, the return value from system calls is generally 0, 1 or 256. Believe I read somewhere that values above 256 are reserved for OS. 0 means success, and all others mean failure. I generally return 1 to indicate "errors detected while running".
  14. Yes and no. SystemC ports (e.g., sc_port<T>) sit on the boundary of a SystemC module to allow communication with external channels. They point outward from a module towards the channel. SystemC exports point inward towards a channel within the module or within submodules via additional export. sc_in<T> is a partial template specialization of sc_port using an sc_signal_in_if<T>. So the answer to your question depends on where the ports are located vs. the module and channel. A picture would help. What books on SystemC have your read?
×
×
  • Create New...