Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Mingw Compile Issue

    If you want to build SystemC inside QtCreator you can use CMake project bundled with systemc 2.3.2 ( Open Project, select CMakeLists.txt) . There is no need to create a qmake project.
  3. Mingw Compile Issue

    You need to make sure to select the C++ standard (C++03, C++11, C++14) consistently. See this thread for a detailed explanation: Hope that helps, Philipp
  4. Mingw Compile Issue

    Hi @Matthias Jung, You should use cmake generator provided from MinGW package manager. In-case you are using the version from CMake official release then you would need to add the MinGW utilities to the system PATH environment variable. set MINGW_HOME=<PATH to MINGWROOT> set PATH=%PATH%:%MINGW_HOME%/bin # Check if you have make available on the cmd.exe make --version # Check if gcc/g++ is available on the cmd.exe gcc --version g++ --version # Configure CMake to use the make file generator on the configuer step in SystemC build directory. cmake -G "MinGW Makefiles" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON .. # or in-case the previous one doesn't work. cmake -G "MSYS Makefiles" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON .. Note: To find the list of supported generator from CMake you can use this command: cmake -G --help Update: Here is the official documentation on the CMake Makefile Generator: https://cmake.org/cmake/help/latest/generator/MinGW Makefiles.html#generator:MinGW Makefiles Regards, Ameya Vikram Singh
  5. Mingw Compile Issue

    When I start this, cmake uses MSVC for compiling, how can i force it to use MinGW? -DCMAKE_CXX_COMPILER -DCMAKE_CC_COMPILER Seems to be ignored
  6. Mingw Compile Issue

    Hello @Matthias Jung, It seems you are missing some of the compiler definition flags for the build: -DSC_BUILD ... etc. You can get the set of compiler flags for the SystemC library from the CMake generator(Only works with Makefile generator). # Using CMake to create compile_commands.json # SYSTEMC_SRC: SystemC source directory. cd $<SYSTEMC_SRC> # Create a build directory mkdir build cd build # Run CMake configuration for Make file generator. cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON .. Note: Also the quick thread library for user space thread support will not work on Windows since it is compatible only on Linux systems. Regards, Ameya Vikram Singh
  7. Mingw Compile Issue

    Im setting up SystemC with qmake: TARGET = systemc TEMPLATE = lib CONFIG += staticlib CONFIG -= qt QMAKE_CXXFLAGS = -Wall -O3 #-std=c++11 QMAKE_CFLAGS = -Wall -O3 INCLUDEPATH += src/ SOURCES += $$files(src/sysc/communication/*.cpp, true) SOURCES += $$files(src/sysc/datatypes/bit/*.cpp, true) SOURCES += $$files(src/sysc/datatypes/fx/*.cpp, true) SOURCES += $$files(src/sysc/datatypes/int/*.cpp, true) SOURCES += $$files(src/sysc/datatypes/misc/*.cpp, true) SOURCES += $$files(src/sysc/kernel/*.cpp, true) SOURCES += $$files(src/sysc/tracing/*.cpp, true) SOURCES += $$files(src/sysc/utils/*.cpp, true) HEADERS += $$files(src/sysc/communication/*.h, true) HEADERS += $$files(src/sysc/datatypes/bit/*.h, true) HEADERS += $$files(src/sysc/datatypes/fx/*.h, true) HEADERS += $$files(src/sysc/datatypes/int/*.h, true) HEADERS += $$files(src/sysc/datatypes/misc/*.h, true) HEADERS += $$files(src/sysc/kernel/*.h, true) HEADERS += $$files(src/sysc/packages/boost/*.hpp, true) HEADERS += $$files(src/sysc/packages/boost/bind/*.hpp, true) HEADERS += $$files(src/sysc/packages/boost/config/*.hpp, true) HEADERS += $$files(src/sysc/packages/boost/config/compiler/*.hpp, true) HEADERS += $$files(src/sysc/packages/boost/config/platform/*.hpp, true) HEADERS += $$files(src/sysc/packages/boost/config/stdlib/*.hpp, true) HEADERS += $$files(src/sysc/packages/boost/detail/*.hpp, true) HEADERS += $$files(src/sysc/packages/boost/mpl/*.hpp, true) HEADERS += $$files(src/sysc/packages/boost/mpl/aux_/*.hpp, true) HEADERS += $$files(src/sysc/packages/boost/mpl/aux_/config/*.hpp, true) HEADERS += $$files(src/sysc/packages/boost/utility/*.hpp, true) HEADERS += $$files(src/sysc/tracing/*.h, true) HEADERS += $$files(src/sysc/utils/*.h, true) HEADERS += $$files(src/sysc/qt/qt.h, true) SOURCES += $$files(src/sysc/qt/qt.c, true) !contains(QMAKE_TARGET.arch, x86_64) { message("x86 build") SOURCES += $$files(src/sysc/qt/md/i386.s, true) } else { message("x86_64 build") SOURCES += $$files(src/sysc/qt/md/iX86_64.s, true) } Under Windows I have this compilation issue when I use Mingw as compiler: ..\systemc-2.3.2-qmake\src\sysc\kernel\sc_ver.cpp:166:1: error: specialization of 'sc_core::sc_api_version_2_3_2_cxx201103L<DisableVirtualBind>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy) [with const int* DisableVirtualBind = (& sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_)]' after instantiation ) ^ Has somebody an idea whats going on here? I assume that it has something to do with the order of the building?
  8. Yesterday
  9. Hi experts, I have the following question about vertical reusability and null sequencers. I have a sequence that stimulates a sub block inside a TOP block. I have verified first the separated sub block. Therefore, i had a testbench for the sub block that has of course VC interfaces and registers. I would like to have a clear way of coding to allow vertical reusability of the sequence that test the sub block. In other words, i would like how to code the sub sequence so that i can start that sequence from a TOP module afterwards. I see the following problems 1)The TOP test bench will not have the interfaces (VCs) for the sub block. 2)The registers will be accessed through the TOP interface but not the sub interface. I can solve the 2 point by creating a new register model and connecting the predictor/adapter of the top. At the same time, i can overwrite the register model used in the sub block sequence so that it uses the new register TOP block handler correctly.---:OK However for the point one, it is more difficult. Theoretically, the sequence should ignore all the VCs of the sub block that are not used anymore. Now the sub block is driven by the TOP DUT and not by a test bench VC. How should a write the sequence so that these VC accesses are ignored in case a TOP sequence calling the old subsequence?. I though that any uvm_do macro that is performed to a VC that is not declared would be ignored but that is not the case... The only idea it comes to me is to code the sub-sequence with an if asking if the VC exists (not null). If it exists, then go ahead, but if it doesn´t assume that this access will be done by a TOP DUT and ignore it! Is this the right way to do this? How can you reuse your old sub sequence from the top sequence? Is there any methodology? Any link? Thanks in advance Jonathan
  10. Yes, of course. An example would be modeling interrupts, which is often done with an sc_signal<bool>.
  11. Hi In TLM, I am connecting two modules with the Initiator socket and target socket. My question is that "Is that possible to have also signal based connection between the modules as well as the Socket based connection " ? Can we have communication in both ways in SystemC ? Thanks
  12. UVM 1.2 report_summarize()

    Most methods in verilog Program including the uvm_report_object are delegated to an internal instance of a uvm_report_handler, which stores the reporting configuration and determines whether an issued message should be displayed based on that configuration. Then, to display a message, the report handler delegates the actual formatting and production of messages to a central UVM Report sample. A report consists of an id string, severity, verbosity level, and the textual message itself. They may optionally include the filename and line number from which the message came. If the verbosity level of a report is greater than the configured maximum verbosity level of its report object, it is ignored. If a report passes the verbosity filter in effect, the report's action is determined. If the action includes output to a file, the configured file descriptor(s) are determined. can be set for (in increasing priority) severity, id, and (severity,id) pair. They include output to the screen UVM_DISPLAY, whether the message counters should be incremented UVM_COUNT, and whether a $finish should occur UVM_EXIT. The following provides the default actions assigned to each severity. These can be overridden by any of the set_*_action methods. UVM_DISPLAY UVM_DISPLAY UVM_DISPLAY | UVM_COUNT UVM_DISPLAY | UVM_EXIT
  13. Last week
  14. Here my two cents, In my opinion, it would be good that UVM would do the backdoor access not as it currently does. It would be good that once provided the hdl_path to a field, the UVM library somehow would be able to generate an unique interface for that hdl_path and a bind that correspond to that interface. That generated interface should be published to the config data base and would be available in any part of your design through the ConfigDB. Of course, the UVM backdoor functions would still be able to do the checks they do now, for example, check that the register is not being accessed by the frontdoor/busy. The difference is that they will update the values over an interface that is published with a logic name in the configdatabase. Having the fields as interfaces in the config data base have the advantage that the user can download that interface handler in the scoreboard and performs things like waiting for an event/trigger on that signal. In other words, signal change detection which is very useful for interrupts. I understand that UVM cannot create code/an interface for you. However, UVM can define a macro for this. I think working with an interface exposer in the config data base is a lot easier and intuitive for interrupt handling on registers. Best regards, Jonathan
  15. UVM-SystemC 1.0-beta1 Released

    Any plan to fix this build error on Mac OS? libtool: link: ar cru .libs/libmacros.a ar: no archive members specified usage: ar -d [-TLsv] archive file ... ar -m [-TLsv] archive file ... ar -m [-abiTLsv] position archive file ... ar -p [-TLsv] archive [file ...] ar -q [-cTLsv] archive file ... ar -r [-cuTLsv] archive file ... ar -r [-abciuTLsv] position archive file ... ar -t [-TLsv] archive [file ...] ar -x [-ouTLsv] archive [file ...] make[4]: [libmacros.la] Error 1 (ignored)
  16. UVM-SystemC 1.0-beta1 Released

    In installed uvm-systemc.pc file, it sets Libs to "-luvm". Should it be "-luvm-systemc"?
  17. Why there is no standard interface class in SystemC

    Perhaps a savvy EDA vendor will pickup on This if there is sufficient commercial interest, which I doubt. Well, actually all HLS tools I've used have notion of modular interfaces. I.e. special kind of modules that aggregate ports together with protocol-handling threads and methods. For example in C-to-Silicon compiler you have to derive from both sc_module and sc_interface to create an interface module: struct slave : sc_module , sc_interface { sc_in<bool> data_rdy{"data_rdy"}; sc_in<int> data{"data"}; sc_out<bool> ack{"ack"}; sc_port<slave_if> slave_port{"slave_port"} ... }; The problem is that every tool has it's own way to define this concept. This seem to me like a language design issue: Why not standardize a common keyword for this concept?
  18. background: I have a image processing IP that comes with a C model. C model takes an array input representing a picture and sends out an array representing a picture. RTL has a pixel-based ready-ready interface on both input and output side. My question is: What's the best-practice approach when building UVM-based DV environment for this IP? What I'm thinking is build an agent for the pixel-based interface, and in block-level environment, have a predictor that takes a sequence of pixel-level sequence_items, call C over DPI, and send out a stream of pixel-level items for checking. Test will be responsible for starting sequence on the agent's sequencer as well as sending sequence(as one object) to predictor. Is there any downside to this? any suggestion is appreciated.
  19. Why there is no standard interface class in SystemC

    Java / C# interface is precisely what SystemC interface is. Your original question was more about port aggregation. The problem is that Verilog ports are really quite a different concept. To be sure , there are superficial similarities, SystemC is not an HDL. Mind you, it is quite easy to aggregate SystemC ports. Just define an aggregate class derived from sc_port. This would also allow you to crate aggregate methods (I.e. beyond simple bind). Just don’t expect this to be useable in synthesis. Perhaps a savvy EDA vendor will pickup on This if there is sufficient commercial interest, which I doubt.
  20. Why there is no standard interface class in SystemC

    No, this is not how interface in SystemVerilog works. Your example is more like Java or C# interface.
  21. I don't remember if the concept of interface came first in SystemC or SystemVerilog. But the interfaces are pretty much there in SystemC. Look at sc_interface. You can define your own interface class my_interface : public sc_interface { // ports and methods } then you can use this interface to define ports like this. class my_module : public sc_module { ........ sc_port<my_interface> myPort; } And the you can define your channels which you can use to connect this new type of ports. This I am just giving a rough idea. There are some examples available in the distribution.
  22. HI : I am aware in Accellera UVM1.2 uvm_report_server, report_summarize(), there is below uvm_info at end of the function. `uvm_info("UVM/REPORT/SERVER",`UVM_STRING_QUEUE_STREAMING_PACK(q),UVM_LOW) // Andrew f_display(file, `UVM_STRING_QUEUE_STREAMING_PACK(q)); I would like to know the motivation of doing so. It is not backward compatible with UVM-1.1X. 1. we have +UVM_VERBOSITY=UVM_NONE for regression run and we do want to see the summary of test. 2. we customized compose_report_message, based on UVM_1.2. it gave me a funny output : i.e UVM_INFO : 0 : [UVM/REPORT/SERVER] --- UVM Report Summary --- ** Report counts by severity UVM_INFO : 7 UVM_WARNING : 1 UVM_ERROR : 1 UVM_FATAL : 1 ** Report counts by id [RNTST] 1 [UVM/RELNOTES] 1 [mycfg] 1 [myenv] 6 [mytest] 1 : reporter Thanks
  23. Just for the record: None of them works, nor actively maintained.
  24. In SystemVerilog there is a standard interface keyword for module-like interface structures. Main purpose of interfaces is grouping of ports, protocol handling logic and assertions together. In SytemC there is no standard one in a language. Because of this each vendor has it's own way to create interfaces: some use pragmas, others special MACRO. In some tools interface is a class derived both from sc_module and sc_interface. There are two typedefs in a SystemC library: typedef sc_module sc_channel; typedef sc_module sc_behavior; Was it supposed that one of these should be used for interface classes?
  25. For what it is worth, there are several open-source tools developed by academia available, which translate SystemC RTL descriptions to Verilog and vice versa: SC2V: https://opencores.org/project,sc2v GSC: https://opencores.org/project,gsc SysC2Ver: http://sysc2ver.sourceforge.net Verilator: https://www.veripool.org/wiki/verilator Verilog2C++: http://verilog2cpp.sourceforge.net ... and probably others, which can be found through a web search. The development of most of these projects was not very active over the past years, but as they are open-source, you're free to pick them up. Otherwise, I fully agree with David's statement that it is not the task of Accellera to develop such tools and also not in the commercial interest of EDA tool vendors, as it is in an area, where they can differentiate themselves most from their competition. For academia and industry there might be some interest for open-source tools as a base for custom tooling, which has to fulfil very particular needs.
  26. Yes, I've noticed that in my company. People who contribute to SystemC are doing that in a spare time. Which is strange: software companies have full-time employees working on language standards and opensource compilers (C++ itself is an example). What I was talking about is a translator for cycle-accurate RTL models, not an HLS tool. So it would not hurt any business, but rather to promote SystemC as a design language. I did not know that Vivado HLS is included into free WebPack version. This explains why we are seeing students running SystemC in Vivado on this forum. Will try it to compare how good it is vs SystemC synthesis from EDA companies. I know, universities can buy licenses EDA licenses for very low cost. When I was a student we got commercial tools installed in university. But still you can't install them on your own laptop for learning at home. So free FPGA tools were always the best for practice.
  27. Memory Allocation In SystemC

    Using new and malloc are supported for the verification side of SystemC. In other words, when you are creating a validation simulation.
  28. SystemC is very well adopted already and has no need to provide free tools. Also, the purpose of Accellera is to develop standards for the EDA and engineering community, not free tools for academia. For this it has done quite well and continues to do an excellent job. Accellera is made up of volunteers from member companies and many of these do not get paid for their participation. In fact, there are very few that are paid staff for Accellera, and most of those are administrative only without the necessary skills to develop such tools. All contributions for Accellera are strictly volunteer and donations. More to the point, member companies develop and sell tools that do exactly what you are asking. So they have zero motivation to give away what they use to create income for themselves. So if you would like to develop such a tool on your own time and donate it, I am certain others would applaud your efforts; however, you should also not be surprized if your donation is rejected because it might hurt existing products of the member companies. If you would like to get a full time job with one of the member companies, do not be surprised to learn they expect you to have knowledge in SystemC to do some of the work you are hired for. Some companies might even send you to get trained. Finally, if you are interested in "free" tools that convert SystemC to Verilog, you might want to checkout Xilinx Corporation's VivadoHLS, which is as close to free as I think you will get for this type of very complex tool. It is restricted to developing code to be used inside Xilinx FPGA's and does a very decent job. You can also talk with other EDA companies about the possibility as a student of your university acquiring low cost versions of other commercial tools for use in graduate classes.
  1. Load more activity
×