Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. sheridp@umich.edu

    multi_passthrough_target_socket requires transport registeration

    Eyck, Not to quibble, but I disagree with that interpretation. You're right I don't have hierarchical binding, and by the first sentence, I should register a transport method. However, the second sentence says that if I don't register one, a runtime error will be generated if and only if the corresponding method is called, which in my code, it isn't. I think this becomes even more problematic if I had configured the socket to be SC_ZERO_OR_MORE_BOUND, in which case it's even more likely that I might not register a transport method if I intend not to connect the socket. I can definitely understand that perhaps my interpretation relies too heavily on the second sentence, but I'd say the spec could probably be made more clear in that regard. Let me know your thoughts.
  3. Actually your code, its behavior and the spec is in sync. You do not have hierarchical binding as you bind an initiator to a target socket. Therfore you need to register at least one of the callbacks so that the interface get bound to the target socket. Best regards
  4. I ran into an issue using multi_passthrough_target_sockets: It is required that register at least one transport method (b_transport or nb_transport_fw) or you'll get the following error: This is in contrast to the spec section 16.1.4.4, section l: It's not really a big problem (why would you ever not register at least one?), but it is something I ran into during development, as I was checking my hierarchical binding structure, but had not yet created my transport methods. The error message is particularly confusing, because the target_socket is bound, and the runtime error is thrown after elaboration, an not when the corresponding method is called. The following code will reproduce the error: #include <systemc.h> #include <tlm.h> #include <tlm_utils/multi_passthrough_target_socket.h> #include <tlm_utils/multi_passthrough_initiator_socket.h> class Container : sc_module { public: tlm_utils::multi_passthrough_target_socket<Container, 1, tlm::tlm_base_protocol_types, 0, SC_ZERO_OR_MORE_BOUND> target_socket; tlm_utils::multi_passthrough_initiator_socket<Container, 1, tlm::tlm_base_protocol_types, 0, SC_ZERO_OR_MORE_BOUND> initiator_socket; Container(sc_module_name name) { initiator_socket.bind(target_socket); //If both lines are line is commented, an error is generated // target_socket.register_b_transport(this, &Container::b_transport); // target_socket.register_nb_transport_fw( this, &Container::nb_transport_fw); } void b_transport( int id, tlm::tlm_generic_payload& trans, sc_time& delay ) { } tlm::tlm_sync_enum nb_transport_fw(int id, tlm::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& delay){ } }; int sc_main(int argc, char *argv[]) { Container c("container"); sc_start(); return 0; }
  5. sheridp@umich.edu

    Build error SystemC 2.3.3 with C++17

    Hi Philipp, Thanks for your response. You are right, I think the spec is clear on that point. I think I had some confusion regarding the default flags on the compiler, but, as you pointed out, that is beyond the scope of the SystemC spec.
  6. @thorsten69 : Would it be possible to generate a small testcase illustrating this problem? We're looking into it, but it'd be much easier to traige if we had a failing testcase to execute. Thanks! -Justin
  7. Thorsten- Thanks for the question! I've opened up a mantis to track the issue: https://accellera.mantishub.io/view.php?id=6966 We'll discuss it in today's working group meeting, and update the status as is appropriate. -Justin
  8. Hello, I've noticed that with SystemC 2.3.3, when I spawn a dynamic process, there is a huge memory consumption. Here' s the code generating the problem #include "test_module.h" void test_module::my_process(int temp) { printf("thread spwned @ %.1f\n",sc_simulation_time()); wait(1000,SC_NS); } void test_module::test_thread(void) { int temp=0; while(true) { printf("current time is %.1f\n",sc_simulation_time()); if (sc_simulation_time()>=100000000) { printf("stop here\n"); wait(); sc_stop(); } else { sc_spawn_options my_thread; sc_process_handle test_proc; my_thread.set_sensitivity(&clock.pos()); test_proc = sc_spawn(sc_bind(&test_module::my_process,this,temp),NULL,&my_thread); wait(10,SC_NS); } } } Basically, when I run the program I see the memory associated to the process steadily growing up second after second. SystemC has been configured with the following switches: --enable-shared=no --disable-async-updates and compiled as static library. The host OS is ubuntu 16.04 and G++ version is 5.4.0 20160609 The same code compiled on an ubuntu 10.04 with SystemC 2.2.0 does not show any memory problem. Any idea on why this happens? Thanks
  9. I have observed a register access synchronization issue in one of my simulations and want to raise this in this forum in order to get feedback if this is a bug or a misusage in some way. In the verification environment there are two register sequences running in parallel. One sequence is doing the DUT configuration and the other one is a noise sequence which switches between the different programming agents and produces some read traffic on all the programming interfaces. The issue I have observed is that the programming sequence is doing a write to a register (AHB SEQ in the image below). During this access the noise sequence randomly selects the same register to do a read access (SPI SEQ in the image). What is happening now is that the mirror(map:SPI) is waiting in the XatomicX task (uvm_reg.svh, line 2400 [Accellera-1800.2-2017-1.0 reference implementation]) for the semaphore (m_atomic). When the field write(map:AHB) finishes after some it calls the put() function of the semaphores two times. Once in the called do_write() of the parent uvm_reg (line 1775) and once in the do_write() of the uvm_reg_field itself (line 1182). This is done in "zero" time but the first put(1) already triggers the get(1) from the other thread (SPI) and the second put(1) increments the m_atomic semaphore to 1. This allows the next writes on the AHB thread to start while the read of the slower SPI thread is still ongoing. In the image I tried to visualize the parallel sequences. The issue was causing the fourth write on the AHB interface to write wrong values to the internal register because it was based on older captured data. The timing is not accurate but chosen for better visualization (all arrows would otherwise be vertical arrows). The simulation was running with a recent version of the purple EDA vendor but the semaphore handling looks ok for me (first come, first serve). I did some local modifications to uvm_reg.svh and with these changes the simulation was passing but I don't know if there are other side effect in scenarios which are not happening in our simulations. These are the modifications I did: uvm_reg.svh Removed all XatomicX() calls from uvm_reg::do_write task (line: 1591, 1633, 1775 [Accellera-1800.2-2017-1.0 reference implementation]) Changed XatomicX task () (line 2435ff) task uvm_reg::XatomicX(bit on); process m_reg_process; m_reg_process=process::self(); if (on) begin // if (m_reg_process == m_process) // return; m_atomic.get(1); m_process = m_reg_process; end else begin // Maybe a key was put back in by a spurious call to reset() void'(m_atomic.try_get(1)); m_atomic.put(1); m_process = null; end endtask: XatomicX I hope this topic is helpful. Thanks Thorsten
  10. Hi PVR, this is probably the wrong sub-forum for that question. As your title suggests you are interested in SystemVerilog Assertions but this sub-forum is more oriented to SystemC verification. You probably will get more response about SystemVerilog Assertions in other forums such as https://verificationacademy.com/forums/systemverilog.
  11. Hi All, i am new to Assertions, can you any one help me on how to check the phase difference in two clocks. Thanks in Advance, PVR
  12. Last week
  13. tommienator

    SystemC 2.3.3 Msys2 and MinGW64 compile problem

    Thanks for the response! Adding the --prefix="location" helped indeed resolve the problem :)! Normally I use it only in a Linux environment, but now there is no other possibility then running it on windows (unfortunately).
  14. Thank You guys, I was able to solve the issue
  15. alexch-cadence

    UVM-ML Open Architecture

    Hi, If still relevant, can you please post the full content of your do.sh and the values of any UVM-ML-related environment variables, or alternatively, send it to support_uvm_ml@cadence.com? Two points instantly drew my attention in the output you have posted: - do.sh runs 64-bit while demo.sh is expected to be 32-bit by default - Compiler is set to g++ 4.8; 6.3 is expected to be the default with 18.09. Thanks in advance.
  16. maehne

    SystemC 2.3.3 Msys2 and MinGW64 compile problem

    Your calls to the configure script don't include the option --prefix to specify the destination directory for installation. This is strongly recommended as the SystemC installation layout does not match well with the standard Unix directory layout for a conflict-free installation. Personally, I prefer to install SystemC on Unix-like platforms to /opt/systemc-2.3.3 (or similar). After make install, you can make sure that the include and lib-* directory below the prefix contains the necessary files. When building against this SystemC version, you will have to pass the proper include and linker flags. I recommend that you read the INSTALL and RELEASENOTES files, which are part of the SystemC PoC implementation. You may also consider to use the experimental CMake-based build system instead of the autotools.
  17. AmeyaVS

    Error in "make check" Cygwin

    Hello @egroj97, This is a known issue on Cygwin(64-bit) with QuickThreads. You need to pass the command-line option: "--enable-pthreads" to the configure script. Kindly refer the discussion about this here: On another note running applications built from source on Cygwin(64-bit) it much slower than running then on native Linux even within a VM. If you have Windows 10 with WSL(Windows Subsystem for Linux) then you could probably try that route to build and install the SystemC library. But I have not tried that out myself, and currently I do not see it being supported/validated by the working group. Anyway it will be nice to know if the library is functional on top of WSL. Hope this helps. Regards, Ameya Vikram Singh
  18. Hi, I'm tryin to install SystemC 2.3.3. I'm executing: make check after: make In Cywin. But I get the following: egroj97@DESKTOP-N99G0TH ~/systemc-2.3.3/objdir $ make check Making check in docs make[1]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/docs' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/docs' Making check in src make[1]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/src' Making check in sysc make[2]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/src/sysc' Making check in packages/boost make[3]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/src/sysc/packages/boost' make[3]: Nothing to be done for 'check'. make[3]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/src/sysc/packages/boost' Making check in packages/qt make[3]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/src/sysc/packages/qt' make check-am make[4]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/src/sysc/packages/qt' make[4]: Nothing to be done for 'check-am'. make[4]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/src/sysc/packages/qt' make[3]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/src/sysc/packages/qt' make[3]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/src/sysc' make[3]: Nothing to be done for 'check-am'. make[3]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/src/sysc' make[2]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/src/sysc' Making check in tlm_core make[2]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/src/tlm_core' make[2]: Nothing to be done for 'check'. make[2]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/src/tlm_core' Making check in tlm_utils make[2]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/src/tlm_utils' make[2]: Nothing to be done for 'check'. make[2]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/src/tlm_utils' Making check in . make[2]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/src' make[2]: Nothing to be done for 'check-am'. make[2]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/src' make[1]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/src' Making check in examples make[1]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/examples' Making check in sysc make[2]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/examples/sysc' GEN copy-check-data make fft/fft_flpt/test.exe fft/fft_fxpt/test.exe fir/test.exe fir/test_rtl.exe pipe/test.exe pkt_switch/test.exe risc_cpu/test.exe rsa/test.exe simple_bus/test.exe simple_fifo/test.exe simple_perf/test.exe 2.1/dpipe/test.exe 2.1/forkjoin/test.exe 2.1/reset_signal_is/test.exe 2.1/sc_export/test.exe 2.1/sc_report/test.exe 2.1/scx_barrier/test.exe 2.1/scx_mutex_w_policy/test.exe 2.1/specialized_signals/test.exe 2.3/sc_rvd/test.exe 2.3/sc_ttd/test.exe 2.3/simple_async/test.exe fft/fft_flpt/test.sh fft/fft_fxpt/test.sh fir/test.sh fir/test_rtl.sh pipe/test.sh pkt_switch/test.sh risc_cpu/test.sh rsa/test.sh simple_bus/test.sh simple_fifo/test.sh simple_perf/test.sh 2.1/dpipe/test.sh 2.1/forkjoin/test.sh 2.1/reset_signal_is/test.sh 2.1/sc_export/test.sh 2.1/sc_report/test.sh 2.1/scx_barrier/test.sh 2.1/scx_mutex_w_policy/test.sh 2.1/specialized_signals/test.sh 2.3/sc_rvd/test.sh 2.3/sc_ttd/test.sh 2.3/simple_async/test.sh make[3]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/examples/sysc' CXX fft/fft_flpt/fft_fft_flpt_test-fft.o CXX fft/fft_flpt/fft_fft_flpt_test-main.o CXX fft/fft_flpt/fft_fft_flpt_test-sink.o CXX fft/fft_flpt/fft_fft_flpt_test-source.o CXXLD fft/fft_flpt/test.exe CXX fft/fft_fxpt/fft_fft_fxpt_test-fft.o CXX fft/fft_fxpt/fft_fft_fxpt_test-main.o CXX fft/fft_fxpt/fft_fft_fxpt_test-sink.o CXX fft/fft_fxpt/fft_fft_fxpt_test-source.o CXXLD fft/fft_fxpt/test.exe CXX fir/fir_test-stimulus.o CXX fir/fir_test-display.o CXX fir/fir_test-fir.o CXX fir/fir_test-main.o CXXLD fir/test.exe CXX fir/stimulus.o CXX fir/display.o CXX fir/fir_fsm.o CXX fir/fir_data.o CXX fir/main_rtl.o CXXLD fir/test_rtl.exe CXX pipe/pipe_test-display.o CXX pipe/pipe_test-main.o CXX pipe/pipe_test-numgen.o CXX pipe/pipe_test-stage1.o CXX pipe/pipe_test-stage2.o CXX pipe/pipe_test-stage3.o CXXLD pipe/test.exe CXX pkt_switch/pkt_switch_test-fifo.o CXX pkt_switch/pkt_switch_test-main.o CXX pkt_switch/pkt_switch_test-receiver.o CXX pkt_switch/pkt_switch_test-sender.o CXX pkt_switch/pkt_switch_test-switch.o CXX pkt_switch/pkt_switch_test-switch_clk.o CXXLD pkt_switch/test.exe CXX risc_cpu/risc_cpu_test-bios.o CXX risc_cpu/risc_cpu_test-dcache.o CXX risc_cpu/risc_cpu_test-decode.o CXX risc_cpu/risc_cpu_test-exec.o CXX risc_cpu/risc_cpu_test-fetch.o CXX risc_cpu/risc_cpu_test-floating.o CXX risc_cpu/risc_cpu_test-icache.o CXX risc_cpu/risc_cpu_test-main.o CXX risc_cpu/risc_cpu_test-mmxu.o CXX risc_cpu/risc_cpu_test-paging.o CXX risc_cpu/risc_cpu_test-pic.o CXXLD risc_cpu/test.exe CXX rsa/rsa_test-rsa.o CXXLD rsa/test.exe CXX simple_bus/simple_bus_test-simple_bus.o CXX simple_bus/simple_bus_test-simple_bus_arbiter.o CXX simple_bus/simple_bus_test-simple_bus_main.o CXX simple_bus/simple_bus_test-simple_bus_master_blocking.o CXX simple_bus/simple_bus_test-simple_bus_master_direct.o CXX simple_bus/simple_bus_test-simple_bus_master_non_blocking.o CXX simple_bus/simple_bus_test-simple_bus_types.o CXX simple_bus/simple_bus_test-simple_bus_tools.o CXXLD simple_bus/test.exe CXX simple_fifo/simple_fifo_test-simple_fifo.o CXXLD simple_fifo/test.exe CXX simple_perf/simple_perf_test-simple_perf.o CXXLD simple_perf/test.exe CXX 2.1/dpipe/2_1_dpipe_test-main.o CXXLD 2.1/dpipe/test.exe CXX 2.1/forkjoin/2_1_forkjoin_test-forkjoin.o CXXLD 2.1/forkjoin/test.exe CXX 2.1/reset_signal_is/2_1_reset_signal_is_test-reset_signal_is.o CXXLD 2.1/reset_signal_is/test.exe CXX 2.1/sc_export/2_1_sc_export_test-main.o CXXLD 2.1/sc_export/test.exe CXX 2.1/sc_report/2_1_sc_report_test-main.o CXXLD 2.1/sc_report/test.exe CXX 2.1/scx_barrier/2_1_scx_barrier_test-main.o CXXLD 2.1/scx_barrier/test.exe CXX 2.1/scx_mutex_w_policy/2_1_scx_mutex_w_policy_test-scx_mutex_w_policy.o CXXLD 2.1/scx_mutex_w_policy/test.exe CXX 2.1/specialized_signals/2_1_specialized_signals_test-main.o CXX 2.1/specialized_signals/2_1_specialized_signals_test-scx_signal_int.o CXX 2.1/specialized_signals/2_1_specialized_signals_test-scx_signal_uint.o CXX 2.1/specialized_signals/2_1_specialized_signals_test-scx_signal_signed.o CXX 2.1/specialized_signals/2_1_specialized_signals_test-scx_signal_unsigned.o CXXLD 2.1/specialized_signals/test.exe CXX 2.3/sc_rvd/2_3_sc_rvd_test-main.o CXXLD 2.3/sc_rvd/test.exe CXX 2.3/sc_ttd/2_3_sc_ttd_test-main.o CXXLD 2.3/sc_ttd/test.exe CXX 2.3/simple_async/2_3_simple_async_test-main.o CXXLD 2.3/simple_async/test.exe GEN fft/fft_flpt/test.sh GEN fft/fft_fxpt/test.sh GEN fir/test.sh GEN fir/test_rtl.sh GEN pipe/test.sh GEN pkt_switch/test.sh GEN risc_cpu/test.sh GEN rsa/test.sh GEN simple_bus/test.sh GEN simple_fifo/test.sh GEN simple_perf/test.sh GEN 2.1/dpipe/test.sh GEN 2.1/forkjoin/test.sh GEN 2.1/reset_signal_is/test.sh GEN 2.1/sc_export/test.sh GEN 2.1/sc_report/test.sh GEN 2.1/scx_barrier/test.sh GEN 2.1/scx_mutex_w_policy/test.sh GEN 2.1/specialized_signals/test.sh GEN 2.3/sc_rvd/test.sh GEN 2.3/sc_ttd/test.sh GEN 2.3/simple_async/test.sh make[3]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/examples/sysc' make check-TESTS make[3]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/examples/sysc' make[4]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/examples/sysc' FAIL: fft/fft_flpt/test.sh FAIL: fft/fft_fxpt/test.sh PASS: fir/test.sh PASS: fir/test_rtl.sh PASS: pipe/test.sh PASS: pkt_switch/test.sh PASS: risc_cpu/test.sh PASS: rsa/test.sh FAIL: simple_bus/test.sh FAIL: simple_fifo/test.sh PASS: simple_perf/test.sh PASS: 2.1/dpipe/test.sh FAIL: 2.1/forkjoin/test.sh FAIL: 2.1/reset_signal_is/test.sh FAIL: 2.1/sc_export/test.sh PASS: 2.1/sc_report/test.sh FAIL: 2.1/scx_barrier/test.sh FAIL: 2.1/scx_mutex_w_policy/test.sh FAIL: 2.1/specialized_signals/test.sh FAIL: 2.3/sc_rvd/test.sh FAIL: 2.3/sc_ttd/test.sh FAIL: 2.3/simple_async/test.sh make[5]: Entering directory '/home/egroj97/systemc-2.3.3/objdir/examples/sysc' GEN copy-check-data To compile and run the examples type make check make[5]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/examples/sysc' ============================================================================ Testsuite summary for SystemC 2.3.3 ============================================================================ # TOTAL: 22 # PASS: 9 # SKIP: 0 # XFAIL: 0 # FAIL: 13 # XPASS: 0 # ERROR: 0 ============================================================================ See examples/sysc/test-suite.log Please report to http://forums.accellera.org/forum/9-systemc/ ============================================================================ make[4]: *** [Makefile:3066: test-suite.log] Error 1 make[4]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/examples/sysc' make[3]: *** [Makefile:3174: check-TESTS] Error 2 make[3]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/examples/sysc' make[2]: *** [Makefile:3392: check-am] Error 2 make[2]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/examples/sysc' make[1]: *** [Makefile:494: check-recursive] Error 1 make[1]: Leaving directory '/home/egroj97/systemc-2.3.3/objdir/examples' make: *** [Makefile:507: check-recursive] Error 1 My configuration summary: --------------------------------------------------------------------- Configuration summary of SystemC 2.3.3 for x86_64-unknown-cygwin --------------------------------------------------------------------- Directory setup (based on classic layout): Installation prefix (aka SYSTEMC_HOME): /home/egroj97/systemc-2.3.3 Header files : <SYSTEMC_HOME>/include Libraries : <SYSTEMC_HOME>/lib-cygwin64 Documentation : <SYSTEMC_HOME>/docs Examples : <SYSTEMC_HOME>/examples Architecture : cygwin64 Compiler : g++ (C/C++) Build settings: Enable compiler optimizations : yes Include debugging symbols : no Coroutine package for processes: QuickThreads Enable VCD scopes by default : yes Disable async_request_update : no Phase callbacks (experimental) : no ---------------------------------------------------------------------
  19. mattia@debian:~$ ls -l /usr/local/systemc-2.3.1/lib-linux64/ totale 5416 -rwxr-xr-x 1 root staff 2009584 mar 8 18:50 libsystemc-2.3.1.so -rw-r--r-- 1 root staff 3525752 mar 8 18:50 libsystemc.a -rwxr-xr-x 1 root staff 1043 mar 8 18:50 libsystemc.la lrwxrwxrwx 1 root staff 19 mar 8 18:50 libsystemc.so -> libsystemc-2.3.1.so drwxr-sr-x 2 root staff 4096 mar 8 18:50 pkgconfig
  20. Bhargav

    Glue Logics in IPXACT

    Okay Erwin. Thanks for the info. Best Regards, Bhargav Kandru.
  21. kock

    Glue Logics in IPXACT

    Hi Bhargav, Glue logic is not covered by the IP-XACT standard. Perhaps your IP-XACT EDA vendor can offer a vendor-specific solution on top of the standard using vendor extensions or vendor-specific parameter conventions. Best regards, Erwin
  22. Bhargav

    Glue Logics in IPXACT

    Hi, I have a question in how glue logics between two or more ports get represented in IPXACT. Lets say there is an ADHOC Connection between, PORT A of instance A and PORT B of instance B, in such a way that, PORTB is connected as 32'habcd ^ PORTA Like, Instance A: output port A Instance B: input port B Now, on Top file, In SV , I have following glue logic. module Top module A instance A( .A(A) ) module B instance B( .B(32'habcd ^ A) //32'habcd XOR with A ) endmodule Now, in adHoc connection,we genrally, represent two connections with just internalportreferences. How does such glue logics get represented? Thanks in advance.
  23. Philipp A Hartmann

    Build error SystemC 2.3.3 with C++17

    The INSTALL notes currently say the following about the SC_CPLUSPLUS preprocessor switch (emphasis mine): This means, that you can explicitly opt-out of some SystemC features, that would generally be supported by your compiler's C++ language support. Selecting a newer C++ standard version than supported by your compiler (setup) will typically not work - as you have experienced. That said, adding a preprocessor flag on the compiler command-line does not affect the language mode of the compiler. How to switch your compiler to C++17 mode is outside of the scope of SystemC. Your compiler (version) seems to require the -std=c++17 switch to enable this mode. The SC_CPLUSPLUS flag is then not needed as it will be set automatically to the selected version. Hope that helps, Philipp
  24. sheridp@umich.edu

    Build error SystemC 2.3.3 with C++17

    The following Dockerfile will reproduce the problem: FROM alpine:3.9 as builder RUN apk add --no-cache build-base linux-headers WORKDIR /opt FROM builder as builder_systemc COPY systemc-2.3.3.gz /opt RUN mkdir /opt/systemc_src && \ tar -xf systemc-2.3.3.gz -C /opt/systemc_src --strip-components=1 && \ cd /opt/systemc_src && ./configure --prefix /opt/systemc-2.3.3 --enable-debug CXXFLAGS="-DSC_CPLUSPLUS=201703L" && \ make -j$(nproc) && \ make install Which results in the following error: CXX kernel/sc_simcontext.lo In file included from kernel/sc_simcontext.cpp:57: ../../src/sysc/utils/sc_string_view.h:62:29: error: 'string_view' in namespace 'std' does not name a type typedef SC_STRING_VIEW_NS_::string_view sc_string_view; ^~~~~~~~~~~ It looks like the following is related: #if SC_CPLUSPLUS >= 201402L && defined(__has_include) # if SC_CPLUSPLUS > 201402L && __has_include(<string_view>) /* since C++17 */ # define SC_STRING_VIEW_NS_ std # include <string_view> /* available in Library Fundamentals, ISO/IEC TS 19568:2015 */ # elif __has_include(<experimental/string_view>) # define SC_STRING_VIEW_NS_ std::experimental # include <experimental/string_view> # endif #else // TODO: other ways to detect availability of std::(experimental::)string_view? #endif I'm guessing that defining SC_CPLUSPLUS did not cause the -std=c++17 flag to be passed to the compiler, because <string_view> contains the following: #if __cplusplus >= 201703L Update: Modifying the ./configure command to: ./configure --prefix /opt/systemc-2.3.3 --enable-debug CXXFLAGS="-DSC_CPLUSPLUS=201703L -std=c++17" solves the problem. It might be worthwhile mentioning this in the INSTALL notes.
  25. What do you see under /usr/local/systemc2.3.1/lib-linux64? In other words, what does the following reveal: ls -l /usr/local/systemc2.3.1/lib-linux64
  26. when I launch the executable program it signals me this error: export LD_LIBRARY_PATH=/usr/local/systemc2.3.1/lib-linux64 ./run_me.x: error while loading shared libraries: libsystemc-2.3.1.so: cannot open shared object file: No such file or directory operating system: Debian 9 gcc --version gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 g++ --version g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
  27. vaibhav0901

    Functional coverage- VCS

    thanks a lot. It's working now 🙂
  1. Load more activity
×