Jump to content

All Activity

This stream auto-updates     

  1. Last week
  2. Philipp A Hartmann

    C++ class object bringing into systemC Hierarchy

    Hi all, Both sc_get_current_process_b() and get_parent() are non-standard functions that may or may not be supported by (future) versions of your SystemC implementation. I recommend to only use standard IEEE 1666-2011 APIs instead: x sc_core::sc_get_current_process_handle().get_parent_object()->name() x sc_core::sc_get_current_process_handle().name() Greetings from Duisburg, Philipp
  3. David Black

    sc_spawn and anthoer process

    sc_spawn creates same kind of processes as sC_METHOD, SC_THREAD, etc, but is not limited to the elaboration phase. Please either read the official documentation for IEEE-1666 (available as pdf free via Accellera) or get a good book on SystemC or take a class.
  4. Roman Popov

    Graph Generation

    In some cases yes, you can do it by playing with dynamic casts. For example: #include <systemc.h> SC_MODULE(test) { sc_signal <int> xsig{"xsig"}; sc_signal <unsigned> xsig2{"xsig2"}; sc_in <int> xin{"xin"}; sc_out <unsigned> xout{"xout"}; SC_CTOR(test) { xin(xsig); xout(xsig2); } }; int sc_main(int argc, char **argv) { test t0{"t0"}; sc_start(SC_ZERO_TIME); cout << hex; for (auto * obj : t0.get_child_objects()) { cout << obj->kind() << " " << obj->name() << " @ " << obj; if(sc_port_base* port = dynamic_cast<sc_port_base*>(obj)) if (sc_prim_channel * chan = dynamic_cast<sc_prim_channel*>(port->get_interface())) std::cout << " ( binded to " << chan->name() << " @ " << chan << ")"; cout << endl; } return 0; } Possible output: sc_signal t0.xsig @ 0x111f878 sc_signal t0.xsig2 @ 0x111f938 sc_in t0.xin @ 0x111f9e8 ( binded to t0.xsig @ 0x111f878) sc_out t0.xout @ 0x111fa90 ( binded to t0.xsig2 @ 0x111f938) SystemC however does not store information about hierarchical bindings.
  5. sumit_tuwien

    Graph Generation

    Hello All, Using get_chil d_objects() I can traverse through hierarchy and can find any ports & instances But I cannot find how these ports are connected. All what I want to do is to create a database which I can use for visualization by post processing. Is there any way to do this ? Regards, Sumit
  6. Thanks ... I ran into this problem as well with clang++ Any known issues with mixing SystemC compiled in clang++ and uvm-systemc compiled in g++? Or should I recompile my SystemC install as well? Thanks, Ian
  7. Hi Aarthi, if you just need to get the currently active module when hitting a breakpoint in you C++ code you might use the following command (assuming you use gdb): x sc_core::sc_get_current_process_b()->get_parent()->name() (see also here: https://stackoverflow.com/questions/18078226/how-to-get-sc-module-name-of-the-current-running-module#18123785) What it does is it calles the SystemC kernel function sc_get_current_process_b() which returns a pointer to sc_process_b (the base class of of sc_method_process and sc_thread_process). Inheriting from sc_obejt it also has a name() method so you could also do x sc_core::sc_get_current_process_b()->name() which just returns the full hierarchical name of the process. HTH -Eyck
  8. Hello, I need a help, Its a huge implementation like having A, B, C systemC Modules and instantiated in the Top and sc_main have the Top hierarchy sc_module_name. In the systemC Module A, i have lot of pure C++ classes and instantiated so many times like some algorithm to do some computation. While debugging difficult to get the hierarchy which one is printing or tracing. I am looking for a solution, without changing the pure C++ classes to derive from sc_module, how do i make it a hierarchy to Top. Changing every where to have a constructor with sc_module_name will be little difficult as the code is huge. Is there any suggestion? Regards Aarthi
  9. A common question, and a topic of many discussions within the Accellera UVM Working Group (UVM-WG), was: What should the version of the new UVM release be? Since 1.0-ea, UVM releases have followed the conventions of Semantic Versioning, with MAJOR and MINOR version numbers, and an optional PATCH version letter and/or additional labels. For example, 1.1d-rc2 was MAJOR=1, MINOR=1, PATCH=d, LABEL=rc2. The UVM-WG wanted to maintain semantic versioning moving forward, but at the same time we wanted to indicate what year/revision of the 1800.2 standard we were implementing. The simplest answer was to set the implementation's MAJOR number to the 1800.2 revision year. The library may have MINOR and PATCH updates, but all versions with MAJOR number 2017 will be compatible with 1800.2-2017. If/when the 1800.2 standard is revised in the future, then the MAJOR number will change. That said, why start with 0.9 as opposed to 1.0? This was more of a subjective decision... The 2017 0.9 release is fully functional, but effectively undocumented beyond a basic README.md which describes how to install the kit. Releasing it as "1.0" was viewed as disingenuous, as we knew it was incomplete from a documentation perspective. Why not 0.0 then, or 1.0-ea? Again, subjective. The UVM-WG didn't want to release it under the heading of “0.0”, "beta", "early adopter", "release candidate", etc. because all of those imply a certain lack of functionality. When all was said and done, the UVM-WG settled on "0.9", as it made it clear that something was missing, while not necessarily indicating that the library was in some way "unsafe to use". The UVM-WG is hard at work on "2017 1.0", which will have the complete documentation of the APIs that the implementation supports above and beyond the 1800.2 LRM. In the meantime, we will be actively monitoring this forum, hoping to answer any questions you may have regarding the library. Thanks for your participation! Sincerely, Justin Refice (UVM-WG Chair) & Mark Strickland (UVM-WG Vice-Chair)
  10. Who can provide a summary of what is new and what has changed?
  11. Roman Popov

    sc_spawn and anthoer process

    sc_spawn allows to create process during simulation runtime. SC_* macro can be used only at elaboration time. Please read more details in IEEE SystemC standard. Here is small usage example: #define SC_INCLUDE_DYNAMIC_PROCESSES #include <systemc.h> SC_MODULE(spawn_demo) { SC_CTOR(spawn_demo) { SC_THREAD(static_thread); } void static_thread() { sc_spawn_options opts; sc_spawn([&]() { wait(1, SC_NS); cout << "spawned @ " << sc_time_stamp() << "\n"; }, "spawned_thread", &opts); wait(1, SC_NS); cout << "static @ " << sc_time_stamp() << "\n"; } }; int sc_main(int argc, char **argv) { spawn_demo demo0{"demo0"}; sc_start(); return 0; }
  12. Can you explain the difference between sc_spawn and another process (SC_METHOD, SC_THREAD, SC_CTHREAD )? How to use sc_spawn? Thanks all
  13. rainer

    Implement sc_trace for std::string

    gtkwave actually supports strings in VCD files as an extension (see, eg., https://sourceforge.net/p/gtkwave/support-requests/2/ and the sample VCD file thats attached). With hacking the kernel to support tracing strings, as Roman mentioned, this works well in SystemC (I wrote such a patch some time ago, but unfortunately don't have it available anymore). Still, this means that your model will only work with the patched kernel and the VCD will only display correctly in gtkwave. test.vcd
  14. StS

    CRAVE versus SCV

    Hi all, SCV is considered now in maintencance mode. This means we will adapt it to issues with new compilers and build flows but we will not add new features. Currently we are focussing our effort on UVM-SystemC. Best, Stephan
  15. kock

    IPXACT for Registers alone for UVM RAL

    Hello Saravan, There are two options. 1. You create a single IP-XACT component that contains a memory map describing your whole system. So the address block base address + register offset represents the absolute base address of the register in your memory map. There is no need to describe bus interfaces is this approach. However, your IP-XACT component is not re-usable; it is a dedicated description of your current system. 2. Your create an IP-XACT component for each individual IP describing the registers for that IP. These IP-XACT components also need a bus interface referencing the component memory map. In these descriptions, the address block base address + register offset represents the base address offset of the register relative to the base address of an instance of such a component. Next, you create an IP-XACT design in which you instantiate your IP-XACT components. In addition you need to create IP-XACT components for (possible dummy) CPU and bus. You encode the system memory map using address spaces and bridges in the bus. The CPU holds the global address space. You connect all bus interfaces like this: CPU instance master interface -> BUS instance slave interface BUS instance master interface 1 -> IPx instance slave interface BUS instance master interface 2 -> IPy instance slave interface BUS instance master interface 3 -> IPz instance slave interface ... Based on this design topology it is possible to compute the system memory map. This is typically supported by an IP-XACT Design Environment. All IP instance registers are mapped in the address space of the CPU using the addressing of the BUS. The result could be written out as a single IP-XACT component as described in Option 1. However, that result could also be written out as a UVM register model. The advantage of Option 2 is that your IP-XACT component register descriptions of your IPs are reusable. The only thing you need to change between your current system and your next system is the BUS component (different #number of slave interfaces and different addressing) and the IP-XACT design instantiating the relevant IPs. Please note that Option 2 is a simplistic representation of your system only for the purpose of describing the system memory map. However, you can refine this into an IP-XACT design hierarchy that represents the physical connectivity to capture the physical connectivity (wiring) as well as the logical connectivity (memory map) in a single IP-XACT design hierarchy (and hence single data model). Also note that you can apply Option 2 without creating the IP-XACT design and IP-XACT components CPU and BUS if you write the top-level UVM block manually which instantiates the generated IP UVM register models with the correct base addresses. Best regards, Erwin
  16. Hi All, I am working in verification. Where i have to generate reg_block for all the IP's using IPXACT. also top level reg_block which instantiates all the IP level register block using IPXACT. But i am not interested in Ports/Businterface/component. Please advise me what is the best method to do it. Thanks Saravanan
  17. 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.
  18. sumit_tuwien

    Non Constructible but Copyable !

    Hello Eyck, This is an amazing pointer. I see I have created a lot of confusions by vaguely putting some code and not mentioning the intent. I will never construct this object. All I am interested is accessing const uint8_t duh { 5 } ; const uint16_t notEgal { Moeglich::Egal(duh) } ; Here is what is important for me: Sometimes, I need partial template specialization of functions which is not allowed which can be enabled if I put this function inside a template class. Your link, very clearly lays down the rule. My expectation from the compiler was wrong and my use-case cannot be understood in a special way by the compiler. Meanwhile, I also asked help from stackoverflow.com in here (I generally do not do that, because they are champions in downvoting questions). You can see how many confusing and different answers from people. Please note:: Since I always explicitly mention all 6 special member functions, it was fine. This was accidentally found when in one place I missed 4 of them and started wondering. Glad that I did that mistake, which enabled me to learn something and correct some mistakes in my understanding. Thanks for the great help. Regards, Sumit
  19. I'm really new to SystemC and I've recently started developing a learning program where I need to comunicate between a module that has sub-modules created inside it. The pseudo-code looks something like this: module rec { std::vector<sender *> vc; constructor(rec) { SC_THREAD(main); } main() { do_some_stuff(); wait(sender_event); do_more_stuff(); } } module sender { [...] } What would be the best and simplest way to communicate between the two of them? Can I use events? Thanks in advance, Lucas
  20. Eyck

    Non Constructible but Copyable !

    Hi Sumit, Quoting http://en.cppreference.com: Some member functions are special: under certain circumstances they are defined by the compiler even if not defined by the user. They are: Default constructor Copy constructor Move constructor (since C++11) Copy assignment operator Move assignment operator (since C++11) Destructor So in the code you show you just delete the default constructor and the destructor. Obviously this does not make sense as you cannot construct any object since you do not have a parameterized constructor. But if you have one this declaration makes sense: the user of this class cannot create a default object, he has to provide some parameters. Deleting the destructor prohibits the creation of an object on the stack, you can only create them on the heap (and never release the memory except you use placement new on a pre-allocated area). But the the standard comittee has a special section on this in the C++ core Guidelines: C.21: If you define or =delete any default operation, define or =delete them all BTW, if you inherit from a class having a deleted destructor the destructor of the child is also deleted HTH -Eyck
  21. sumit_tuwien

    Non Constructible but Copyable !

    Hello David, Yes, but please note that I already applied final keyword at the end of the class and hence this class cannot be derived from. Regards, Sumit
  22. David Black

    Non Constructible but Copyable !

    A derived class could inherit this.
  23. sumit_tuwien

    Non Constructible but Copyable !

    Hello All, I found out this issue while I was playing with some SystemC stuffs (During meta-programming). This is a C++ question which I separated out from the SystemC implementation. I could have gone to pure C++ forum but since I use this forum, I believe if I ask here people will be benefited more. I observed that if I explicitly delete only constructor and destructor of a class then the resultant implementation deletes copy constructor & move constructor, but the compiler still makes copy assignment and move assignment operators implicitly available! Which in turn makes assignment possible! My question is what is the rational of this? What is the use case where this can be used. Following is an example code for reference: # ifndef MOEGLICH_H_ # define MOEGLICH_H_ # include <cstdint> class Moeglich final { public : explicit Moeglich() = delete ; ~Moeglich() = delete ; /* // With explicit deletion Moeglich& operator=(const Moeglich& other) = delete ; Moeglich(const Moeglich& other) = delete ; Moeglich&& operator=(Moeglich&& other) = delete ; Moeglich(Moeglich&& other) = delete ; */ static constexpr uint16_t Egal(const uint8_t& var_) noexcept { return static_cast< uint16_t > ( var_ ) ; } }; # endif # include <cstdlib> # include <iostream> # include <type_traits> int main(int argc, char* argv[]) { std::cout << std::boolalpha << "Is constructible : " << std::is_constructible<Moeglich>::value << std::endl << "Is destructible : " << std::is_destructible<Moeglich>::value << std::endl << "Is copy constructible : " << std::is_copy_constructible<Moeglich>::value << std::endl << "Is move constructible : " << std::is_move_constructible<Moeglich>::value << std::endl << "Is copy assignable : " << std::is_copy_assignable<Moeglich>::value << std::endl << "Is move assignable : " << std::is_move_assignable<Moeglich>::value << std::endl << "Is assignable : " << std::is_assignable<Moeglich, Moeglich>::value << std::endl ; /* Following were what I wanted to bar anyway : const Moeglich mom {} ; Moeglich pop {} ; Moeglich foo {} ; foo = mom ; foo = std::move(pop) ; */ return EXIT_SUCCESS ; } Regards, Sumit
  24. Roman Popov

    Implement sc_trace for std::string

    Unfortunately current implementation was not designed to be extensible by user. So you will have to hack SystemC kernel itself. Tracing part is relatively small so it's should not be very hard. Just follow the implementation for existing types. In general however it should be better to redesign tracing API so it will be extensible for user-supplied types. In addition to accepting fixed set of datatypes, it should also accept abstract interfaces that can be implemented by end user. For example: // currently does not exist struct BitVecConvertible { virtual sc_dt::sc_bv_base to_bv() = 0; } sc_trace(sc_trace_file* tf, BitVecConvertible &obj, onst std::string& name); In that case user can trace any type as a bit vector, by implementing an interface or providing a proxy-class.
  25. Hadrian2002

    Implement sc_trace for std::string

    As I said, after elaboration (or before_end_of_elaboration) the actual number of different strings and the number of bytes of the longest string is determinable, so I could try to wrap it around sc_bv. Since I know my target will be gtkwave I could use the string extension for vcd of gtkwave. I firstly will patch the current implementation for vcd_trace_enum, but my original questions were about the class hierarchy of the reference implementation.
  26. kjhyland

    VCD dump with Hierarchy systemc-2.3.2

    Just to confirm for other readers - the macros work as described. sc_trace(tracef, dpu.idu.weight_reader.m_traffic_gen._STATE_, "dpu.idu.weight_reader.m_traffic_gen._STATE_"); equivalent to TRACE_VAR(tracef,dpu.idu.weight_reader.m_traffic_gen._STATE_); thanks again Eyck and Ameya, K
  1. Load more activity
×