Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 10/27/2019 in all areas

  1. The Accellera SystemC AMS Working Group released the 2020 edition of the SystemC AMS User's Guide. You will find the user's guide on this page: https://www.accellera.org/downloads/standards/systemc This version of the user's guide is fully compatible with the SystemC AMS standard released as IEEE Std. 1666.1-2016. It describes all the features introduced in the SystemC AMS language standard during the last decade. For example, the user’s guide now explains the use of the dynamic timed data flow capabilities, to make AMS system simulations even more efficient and running even faster.
    3 points
  2. Eyck

    TLM CPU modeling

    There is no such thing as CPU TLM modeling. Usually you write a C/C++ processor model with the needed accuracy (instruction accurate, cycle approximate, cycle accurate) and wrap it in a way that you translate memory accesses into TLM socket accesses. Along with that you need to manage to syncronization of the time of your model and the SystemC time (to run e.g. in loosly timed mode). Another task is to take the returned execution time of the bus accesses into account for the execution of the CPU model. This involves also the selection and implementation of the accesses (DMI & blocking or n
    3 points
  3. Hello @berry_runner, Regarding a dedicated training look here: https://www.doulos.com/training/ But as a starter in this, I would recommend getting to know following in no particular order: C++11/14/17: Useful for writing concise and clean code. SystemC from Ground Up 2nd Edition by @David Black. https://github.com/dcblack/SCFTGU_BOOK/ Look into the examples directory in SystemC sources. https://github.com/accellera-official/systemc/tree/master/examples Look into publicly released projects on Github: https://github.com/topics/systemc
    2 points
  4. Just to add 2 cents to @David Black proposal: If the instantiation is exepensive you could fork() (https://en.wikipedia.org/wiki/Fork_(system_call)) your programm after instantiating the design. Basically you create a new OS process as copy of the current one and here you can continue the simulation. But in essence it is the same approach as David described.
    2 points
  5. The primary reason is that the SystemC Proof-of-Concept (PoC) implementation uses some global data structures, which get constructed during elaboration, which are not fully cleaned up when sc_stop() is called. These data structures are only freed by the OS when the application quits. There have been some efforts improve the PoC implementation in this area, but these are currently stalled. Unfortunately, partially due to bad code examples, bad habits, and laziness, many SystemC models also not cleanly deallocate their dynamically allocated resources, as they still use manual resource allocation
    2 points
  6. You cannot bind an output port to an input port. Ultimately each port must bind to a signal either hierarchically (this is where port to port binding can is used) or directly. So you need to define signal for each of the test_module output ports and bind the sc_out and sc_inout ports to it. 2 remarks: you should use sc_in instead of sc_inout to indicate the purpose clearly sc_out is just a child of sc_inout to reduce the number of output ports (and hence signal) you might want to group signals logically belonging together into structs. Those can be used as data typs of si
    2 points
  7. Eyck

    sc_clock Doubt

    sc_clock triggers itself based on the period and the (in your case default) constructor settings. The period is the default_time_unit.
    2 points
  8. You are initailaizing fl_ptr during consturction, not during execution. In generator.hpp you have: float* fl_ptr = reinterpret_cast<float*>(dmi_mem); //ovo sam ja pisao This never updates fl_ptr to the actual value of dmi_ptr. Actually your access should look like: if (dmi_valid) { dmi_mem = dmi.get_dmi_ptr(); //dmi_mem is pointer to ram[] array in memory.h float* fl_ptr = reinterpret_cast<float*>(dmi_mem); for (int i = 0; i != 20; ++i) fl_ptr[i] = 12.7; }
    2 points
  9. Your sc_trace function is a member function of the TraceList class and cannot be called like the sc_trace functions coming with the SystemC reference implementation. Those are free functions in the sc_core namespace. Moreover your sc_trace implementation is non-static so it cannot be used without a TraceList object. You need to move the function out of the class scope. Basically this is a valid approach to setup complex types. But under performance considerations I would suggest to use a different container. Best choices are std::vector or std::dqueue. And if you are using C++ 11 I w
    2 points
  10. The SystemC standard says: 5.10.8 Multiple event notifications A given event shall have no more than one pending notification. If function notify is called for an event that already has a notification pending, only the notification scheduled to occur at the earliest time shall survive. The notification scheduled to occur at the later time shall be cancelled (or never be scheduled in the first place). An immediate notification is taken to occur earlier than a delta notification, and a delta notification earlier than a timed notification. This is irrespective of the order in whi
    1 point
  11. Actually this is a Virtualizer specific question so you are better up contacting SNPS directly or try their SolvNet. But if you have missing symbols during link you miss to specify a library. How to solve this is a question to SNPS.
    1 point
  12. This is not really a memory leak, but a very bad „model“ for the current implementation. I wonder if you saw any such scenario in a real model? „Canceled“ notifications like in your case will still be kept in the kernel‘s internal data structures until the notification time is reached (1ms in your case). You would pile up 999,999,999 of these canceled notifications until they are „deallocated“, each of them taking entries in the event queue and 16 bytes for the notification itself. Which is a lot of memory. I wrote „deallocated“ in quotes, because sc_event_timed uses a very simple m
    1 point
  13. sc_fifo<T> is a channel representing hardware FIFO behavior. sc_fifo_in<T> is a specialized port used to access an sc_fifo channel. Almost identical to sc_port<sc_fifo_in_if<T>> Suggestion: Read the freely available SystemC standards document (IEEE-1666-2011) or obtain a book on SystemC. It's all very clear there.
    1 point
  14. Let me start by observing that you probably don't want to initialize an input port. After all, inputs observe information from outside the module. So I will assume you mean an output port. If need be, you could change to use an sc_inout<T> port, but you might create a nasty race condition. The cleanest and most general approach is to write to the port during the start_of_simulation phase. How? Just create a override method, void sc_start_of_simulation(void), in your module. SC_MODULE( Example ) { sc_out<bool> oport{"oport"}; sc_signal<int> local_sig{"local_sig
    1 point
  15. I'm not aware of any example so I will no be able to answer your question. But I do not see your problem. You would do it as it is done in hardware. Each stage is providing a ready signal indicating to the stage before that it can take inputs. And now the preceeding stage updates its outputs only if the ready signal of the next stage is active.
    1 point
  16. Three thoughts might be helpful for you to consider: You could of course use next_trigger() in SC_METHOD: SC_MODULE(HARD_WAY) { sc_in<bool> clock, clock_enabled; SC_CTOR(HARD_WAY) { SC_METHOD(gated_method); sensitive << clock; ... } ... void gated_method(void) { if ( clock_enabled and clock.posedge() ) { // Normal operations } else { // Wait until clock is re-enabled next_trigger( not clock_enabled ); } } The better way is to use sc_process_handle::disable() and enable() #define SC_INCLUDE_DYNAMIC_PROCESSES #incl
    1 point
  17. You can use group_of_animals_c::pre_randomize to create the array to the maximum possible size (12, given your constraint) and construct each element of the array. The array may shrink during randomization to satisfy other constraints. Something like this: function void pre_randomize(); animal_da = new[12]; foreach(animal_da) begin if(animal_da == null) animal_da=new(); end endfunction Using array reduction is the right idea to constraint the sum of animal weights. You can use a "with" clause to sum the individual animal weights.
    1 point
  18. maehne

    PSL in SystemC

    I am not aware of a widely used free PSL implementation for SystemC. However, you can find some research papers discussing using PSL together with SystemC, e.g.: Ali Habibi, et al.: Assertion Based Verification of PSL for SystemC Designs, IEEE, 2004. Wolfgang Ecker, et al.: Implementation of a SystemC Assertion Library, Design & Reuse.
    1 point
  19. SCV does not contain an the respective overloads for scv_introspection and _scv_distribution. Therefore there is afaik no way to simply randomize a vector. As a workaround you might use the randomization for plain C-style arrays.
    1 point
  20. Yes, I have actually created a post on the MinGW forum that can be found there: https://sourceforge.net/p/mingw-w64/discussion/723798/thread/7b5436a4d9/. I though got nothing. Your suggestion about overhauling this part of SystemC sounds really good. The only concern for me is that C++20 is pretty new and it might require users to upgrade their compilers to provide C++20 support.
    1 point
  21. @maehne, First of all, I would like to thank you a lot for the kind words and the info you provided. So, since my post I have been digging deep into the issue and reached the following: The issue stems from the use of exceptions from within a Quickthread I managed to create a minimal testcase that only includes Quickthreads code and a part of an example that they provided in meas.c. You can find that attached. I came across a couple of good reads and found that: In case of SEH exceptions to be able to unwind a function unwind info must exist in the .pdata/.xd
    1 point
  22. @Eyck is correct. It would be a major rewrite of SystemC to allow this. If you are trying to launch multiple simulations (sequentially) perhaps with different parameters, you need to do that from a script. If you are super insistent you have to do it under C++, you could try the following: // Compile your main SystemC as run.exe and place it in the same directory as this program int main(void) { int errors = 0; errors |= system("./run.exe -option 1"); errors |= system("./run.exe -option 2"); return errors; } Or just use your favorite script language (bash, perl, zsh, csh, pytho
    1 point
  23. My point was more of a generic nature and more related to modeling guidelines. If your initiator/test_producer has many signals some of them might belong 'logically' together as they are written at the same time. E.g in AHB you have HADDR, HTRANS, HBURST, HWRITE, etc. Instead of declaring them as sc_out<sc_dt::sc_logic> xxx or alike: sc_out<sc_dt::sc_lv<32>> HADDR; sc_out<sc_dt::sc_lv<4>> HTRANS; sc_out<sc_dt::sc_logic> HWRITE; . . . it would make sense to do it this way: struct ahb_req { sc_dt::sc_lv<32> HADDR; sc_dt::sc_lv<4&
    1 point
  24. Silly me, I was quite mistaken in my simple solution (and it only took me a few minutes after posting to realize it); however, this exercise reminded me of a 2011 feature: reset. This works for SC_METHOD processes, but is inconvenient for SC_THREADs. I enjoyed working the puzzle. You can see a full working example here: https://www.edaplayground.com/x/39QM Outline: When registering your SC_METHOD process capture the process handle and specify dont_initialize(). At the start of your method implementation, check for the trigger state of reset_event and return immediately if
    1 point
  25. Sure. Just add a method reading all bool sc_in and write to the output. You need to make it sensitive to all inputs Something like: SC_MODULE(conv){ sc_vector<sc_in<bool> > input{"input"}; sc_out<bool> ouput{"ouput"}; SC_CTOR(conv){ SC_HAS_PROCESS(conv); SC_METHOD(method); for(auto& in: input){ sensitive<<in; } } void method(){ unsigned res = input[1]?2:0+input[0]?1:0; output=res; } };
    1 point
  26. Hi, I just downloaded the UVM library but I couldn't find any tests verifying its functionality. Are such tests available? Also, is the git repository from which the library was released open? Thanks
    1 point
  27. You are writing to ports in the constructor of server. At this point they are not bound. Since you initialize them in the beginning of your thread this is not needed anyways. Aside of that you also do not need the sensitivity list for the monitor thread as you never use the default sensitivity (by using wait() ). And if you use C++11 or newer you should use In-class member initializers which eases the naming of signals (and you should name them to make debugging easier): sc_in<bool> begin1{"begin1"}, begin2{"begin2"}, begin3{"begin3"}; sc_in<bool> end1{"end1"}, end2{"end2"
    1 point
  28. I found an example on the Doulos webpage. The code is in the EDAPlayground: https://www.edaplayground.com/x/4vf Hope this helps.
    1 point
  29. Accellera released the SystemC AMS user's guide application examples, which are available for download via this link. These examples can be executed using your preferred EDA tools, as long as they support the SystemC and SystemC AMS language standard. Alternatively, you can use the open source SystemC and SystemC AMS reference implementations. Instructions for installation and execution can be found in the INSTALL or README files as part of these packages. We welcome your feedback!
    1 point
  30. David Black

    System c help

    For your specific problem just Google "C++ read CSV": https://thispointer.com/how-to-read-data-from-a-csv-file-in-c/ https://www.gormanalysis.com/blog/reading-and-writing-csv-files-with-cpp/ For C++ try: https://www.geeksforgeeks.org/c-plus-plus/ http://www.cplusplus.com/doc/tutorial/
    1 point
  31. Esp. as educational project you should implement it in 2 threads which communicate with each other. Since they run in the same process space you can access data safely once the simulation is in paused state. But you cannot restart the simulation without restarting the process it self. SystemC uses static global variables storing the simulation state and those get only initialized at program start.
    1 point
  32. There is no guarantee which method or thread is activated first There is no means to give priority. Why would you like to do this? In my experience you have a thought problem if you believe you need to do this. thread activation is more expensive (in terms of computing power) than method as the thread context needs to be restored and saved. But threads keep an internal state so they are good to describe state machines.
    1 point
  33. You can check the commit history of the file in the public GitHub repository. The chain of relevant changes are: b276fd3b ff4581f1 41ae779d Here are related discussions from the forum: Hope that helps, Philipp
    1 point
  34. You create 5 signals carrying a TraceVector. Doing so the default constructor is used which does reserve space for elements but has a size of 0... I can't tell where the assertion comes from. For those cases a debugger is pretty helpfull B-)
    1 point
  35. Sc_signals are not data types. Sc_signals are channels, which represent hardware being modeled and are used as mechanisms to transport data between processes. As such, channels are only allowed to be created during the “elaboration phase” that occurs prior to simulation starting up. Also, strictly speaking, sc_port’s are not normal pointers; although, an underlying mechanism uses pointers for efficiencies sake. The operator->() is overloaded on sc_port<IF_TYPE>. You could of course create an sc_vector< sc_signal<T> >, N >, where N was a maximum of the n
    1 point
  36. David Black

    SYNTHESIZABLE SystemC

    sc_core::sc_signal<sc_dt::sc_bv<32> > register[32]; ... SC_METHOD(prc_assign_rf_reg); for(int i=0;i<32;++i) { sensitive << register[i]; } Above should work from a simulation point of view, but probably fails the synthesizable test. Tools might support it. Unfortunately, despite the existence of a Synthesizable subset standard, you are really at the mercy of each implementation vendor since they usually vary from the standard in various ways. The standard simply provides a starting point they attempt to match, but then add their own extensions and/or exception
    1 point
  37. The basic idea: calculate hash for the string call sc_trace for the hash value update a translation file which maps hash values and the string contents. Exemplar github project which utilizes this approach: https://github.com/timurkelin/simschd In this project the translation file is written before the simulation starts raw 64-bit hash values: simvision mmap translation applied: simvision mmap is generated automatically and translates string hash (%x=) into string value (-label {}). mmap new -reuse -nam
    1 point
  38. Since you are talking about timing I would stick to a more AT like modeling style using the non-blocking transport functions. In this case you should use a memory manager (see section 14.5 of the IEEE standard). For this you need to implement the tlm::tlm_mm_interface (there a few implementations out there, you may google them). The mechanism works similar to a C++ shared pointer. The initiator always pulls a new transaction from the memeory manager and sends via its socket. Each component dealing with the transaction calls acquire() on the payload and release() once it is finished with it. Up
    1 point
  39. No. For analog, SCV has not solid application.
    1 point
  40. It would be good if you could provide a description of the problem you see (or better error messages or alike) when building the unit. I see 2 things in your code: the statement labeled with '// sensitivity list' tm << START << TIMEOUT << CLOCK; is wrong. You did this already in the constructor (SC_CTOR(timer)) of your module. The sensitivity list of your timer is wrong. The thread should only wait for the positive edge of clock, start is a data signal which is sampled/read upon the rising edge of the clock I suggest to change the implementation from
    1 point
  41. You cannot have a delay in end_of_elaboration() or start_of_simulation() since those are callback functions outside of the (timed) simulation cycle. One thing you could do is to start the gdb within a SC_THREAD where you have a wait(SC_ZERO_TIME) to let the updates settle: void start_gdb_thread(){ wait(SC_ZERO_TIME); start_my_gdb(); } BR
    1 point
  42. Fix published in 5a94360d in the public repository. Hope that helps, Philipp
    1 point
  43. SC_MODULE(DF_Fork){ sc_fifo_in<int> input; sc_fifo_out<int> output1,output2; void process(){ while(1){ int value = input.read(); output1.write(value); //output1.write(value); output2.write(value); } } SC_CTOR(DF_Fork) {SC_THREAD(process);} }; You never write on output2. Your printer then remains at value = input.read(); since it waits till data is available. Thus the simulation has nothing to do and stops itself. You can read about sc_fifo methods here: http://www.asic-world.com/systemc/channels4.html
    1 point
  44. The Accellera UVM Working Group has released the UVM 2017 0.9 reference implementation. This implementation is available as a SystemVerilog class library and is fully compatible with the IEEE 1800.2-2017 standard as defined in the Language Reference Manual. The library can be downloaded for free here. The IEEE 1800.2-2017 standard is available free of charge from the IEEE Get program, courtesy of Accellera. We encourage you to use this forum to provide feedback, ask questions, and engage in discussions.
    1 point
  45. 2 days! That's fast response Exactly! If you're not open in the design/pre-release phase you're likely to miss use cases and if the members have committed themselves to solutions and switched their focus to other tasks I imagine that there will be an unwillingness to go back and redo things even if new important insights have been revealed. I think most users would like a code base they can build upon, not one that needs adaptations to make it work. Being fully transparent about the code in the making will reduce the risk for such adaptations What I'm suggesting
    1 point
  46. Unfortunately I'm not with a member company. I was hoping that I'd have read permissions regardless of my current affiliation. As a user I'd like to see the connection between discussions in the official forum, the issues reported to the issue management system, and the code being developed in response to that. The ability to immediately test that code and possibly give feedback as code comments or a pull request. More like Github, Gitlab and other platforms. Seems to me that this would be a more efficient way to give and get user feedback.
    1 point
  47. Are there any plans on continuing using the GitHub repository for such releases or has it been discontinued?
    1 point
  48. The github repositories are the actively developed code for Accellera’s reference implementation (sourceforge was made read-only when github was spun up). That being said, github stores the active development for the reference implementation, not for the standard itself. The class reference (ie. The “Standard”), as well as the Accellera Reference Implementation are officially published on accellera.org: The UVM 1.2 Standard: http://accellera.org/images/downloads/standards/uvm/UVM_Class_Reference_Manual_1.2.pdf The UVM 1.2 Reference Implementation: http://accellera.org/images/downloads/stan
    1 point
  49. Hi Ameya, you're right: The SystemC 2.3.2 release selects a particular C++ standard to build upon and enforces consistency of this selection between the model and the library at link-time. Users can override the detection by setting the SC_CPLUSPLUS macro at build time to a (usually earlier) C++ version, as documented in the RELEASENOTES and INSTALL files of the SystemC 2.3.2 public review release. RELEASENOTES: 5) Initial support for C++11/14 =============================== This package includes an initial implementation of the C++11/14 proposal, presented at DVCon Europe
    1 point
  50. @daveW you can tryout the SystemC 2.3.2 draft release which fixes most of the issues while building under C++11/C++14 compilers. Have a look here: Regards, Ameya Vikram Singh
    1 point
×
×
  • Create New...