Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 09/26/2021 in all areas

  1. A better solution is to compile for C++11 (or later) instead, where sem_* APIs are not required.
    2 points
  2. Hi there, thanks for the post! I'm not sure where that image is from, but there's no plans to remove the runtime phases from UVM.
    1 point
  3. Managed to run SystemC on new Apple M1 silicon, following are the steps 1. modify configure file, add the following code highlighted in red # check CPU architecture case ${target_cpu} in #( x86_64|amd64) : TARGET_ARCH="${TARGET_ARCH}64" CPU_ARCH="x86_64" QT_ARCH="x86_64" ;; #( x*86|i*86) : CPU_ARCH="i386" QT_ARCH="iX86" ;; #( powerpc64) : TARGET_ARCH="${TARGET_ARCH}ppc64" CPU_ARCH="ppc64" QT_ARCH="pthreads" ;; #( powerpc) : TARGET_ARCH="${TARGET_ARCH}ppc" CPU_ARCH="ppc" QT_ARCH="powerpc-apple-macosx" ;; #( arm) : TARGET_ARCH="${TARGET_ARCH}arm" CPU_ARCH="arm64" QT_ARCH="pthreads" ;; #( *) : as_fn_error $? "\"sorry...architecture not supported\"" "$LINENO" 5 ;; 2. install g++ using homebrew brew install gcc 3. setting CXX and point to the homebrew g++-11 in step 2, run configure export CXX=g++-11 ./configure 4. make all 5. make check I would like to encourage others to share their experience of porting systemC to this new mac silicon.
    1 point
  4. Create a custom protocol and don't use address field if you don't have an address. If you do have an address but it has different requirements, then add a mandatory extension to the payload for your protocol.
    1 point
  5. This is a known issue, covered by the currently open mantis: https://accellera.mantishub.io/view.php?id=6913 In a nutshell: RAL doesn't currently provide any API for indicating that a register is "temporarily volatile"... basically something has happened which causes the model to lose track of the expected state of the register, but it's a potentially recoverable event. We're currently working on how such an API could/should work. Thanks for the information!
    1 point
  6. Hi all, I am running into a very weird exception when I try to build SystemC applications that contain `SC_THREAD` under Visual Studio 2019. I managed to prepare a small reproduction example (see attached file) which looks like: #include <systemc> SC_MODULE(Test) { SC_HAS_PROCESS(Test); explicit Test(sc_core::sc_module_name name) : sc_module(name) { SC_THREAD(busy); } void busy(void) { for(int i = 0; i < 10; i++) { sc_core::wait(1, sc_core::SC_NS); printf("busy\n"); } sc_core::sc_stop(); } }; int sc_main(int, char *[]) { Test ttt("ttt"); sc_core::sc_start(); return EXIT_SUCCESS; } The program is compiled using the attached CMakeLists.txt file. Upon execution, it runs into an exception and when I look in the debugger, the exception comes from: The same program runs without any issues when compiled using GCC 9.2 on CentOS 7. On Windows, I am using Windows 10 with VS 2019 Enterprise. Did anyone else run into similar issues when trying SystemC 2.3.3 with VS 2019? Edit 1: Issue has been resolved. It turns out that you need to pass `/GR` and `/vmg` in the compile flags. Best Regards, Mohamed CMakeLists.txt ctor.cc
    1 point
  7. I deduct from this that somewhere in your design, timing is involved, most probably in the part that triggers/feeds the input threads. If not, your simulation would finish in zero time + x delta cycles, which "at this time stamp" seems to contradict. So, you have to define what "at this time stamp" means. Is it exactly the simulation time at which the first FIFO notifies the arbiter? In that case, David's solution applies. Do you have clocks (e.g. wait statements with time indication) in your design? Maybe your arbiter can only be sure at the end of a clock cycle? Maybe another part of your design must tell the arbiter that "at this time stamp" has finished, and the arbiter can assume that no new transactions will come in?
    1 point
  8. Due to the design of sc_event there will only be one event for a given delta cycle.
    1 point
  9. Create: sc_event arbiter_event; All arriving processes push to their respective fifo and immediately post: queue.push(data); arbiter_event.notify(SC_ZERO_TIME); Arbiter waits for the event and processes all fifo’s upon receipt.
    1 point
  10. I could finally make it using TLM docmentation (the IEEE 1666 standard might be useful). I had to implement a TLM transaction extension to fit the particular needs of some transactions between the pipeline and the file register. Useful examples for TLM transaction extensions are provided in a document from the university of Munich. Finally, the Doulos examples are also interesting (but less interesting than the last one). Hope this helped! J-B
    1 point
×
×
  • Create New...