Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. vedant-cst

    reset method or thread

    Thanks, @David Black I was more interested in the second manner.
  3. Yesterday
  4. kimmysawi

    Array pseudo-methods missing

    The method which you post on that google link are not working, if there is any other to please post it up (Y) Cheers
  5. David Black

    reset method or thread

    Reset is accomplished by throwing an exception. You cannot perform cleanup *before*, but you can perform cleanup on the way out in two manners. First, automatically created objects will of course run their destructors as guaranteed by C++. Second, you can catch exceptions by strategic placement of try-catch blocks and looking for the appropriate sc_exception. It is required by SystemC that you rethrow after catching; otherwise, you will corrupt the SystemC kernel.
  6. vedant-cst

    reset method or thread

    Can you explain how the reset() function works in sc_process_handle? Basically, I want to understand if I can perform any cleanup task before the reset() function resets any thread or method.
  7. Last week
  8. jrefice

    What's New in IEEE-UVM?

    Wow, starting the questions off with a (not entirely unexpected) doozy! 🙂 Unfortunately there's no single document which states "Here's a full list of everything that changed". This is because a large number of changes were performed by the Accellera UVM WG prior to the IEEE UVM WG spinning up, so there was never a single "central" location wherein everything was tracked. Many of the changes were also "non-functional", ie. the removal of user's guide-esque material and removing the accidental documentation of implementation-specific artifacts. The best list we've got of functional changes is the bug database where we tracked the changes required to convert the UVM 1.2 reference implementation to UVM 2017 0.9, and that's not really intended for mass consumption. If I were to go through that list and pick "Justin's Top-N": Accessors- Almost all fields (e.g. printer knobs, etc) have been replaced with set_/get_<field> accessors. Besides for simply being a better coding convention, this allows for greater extensibility. Opening up the core services- The user now has the ability to insert their own code within the core services of UVM. One common use case for this would be to create a factory debugger, such that all calls to the factory get reported, or a resource pool with a more performant implementation. It's even possible to implement one's own uvm_root, however that has some additional restrictions called out by the LRM. In the past all of these would have required the user to hack inside their own version of the library. Library initialization- The library no longer mandates that initialization happen during static init. It must happen during time 0, but any time during time 0 is sufficient. This allows the user to leverage #2, but it also allows for new use cases (e.g. "parameterized classes participating in the name-based factory"). There's also new hooks in the library which allow the user to "start and stop with run_test". Removing the black magic- Anyone brave enough to expand the field macros would know that pre-2017, there was some scary and completely undocumented stuff going on there. This has all been refactored, and just as importantly, documented in 1800.2-2017, such that users can now implement their own macros and/or policies without having to worry about how it would interact with the Accellera library's implementation. Policy changes- Lots of extensibility changes here. Printer, packer, et. al now derive from a single common source (uvm_policy). They all support arbitrary extensions, similar to TLM2's Generic Payload, allowing for VIP-specific information to be communicated during their processing (e.g. masking fields from a print or compare operation...). Additionally, the printer now has a much more robust mechanism for tracking the structure being printed, making it easy to implement new printers (XML, YAML, JSON, etc.). Registers- Surprisingly few changes here. The most obvious change is that you can now unlock a model after it's been locked, which allows you to remove/replace/etc registers within the model during runtime. For SoCs which support hotplugging, or are generally re-configurable, this was a huge gap in 1.2 functionality. At DVCon 2017 & 2018, there were tutorials which covered all of the above and more, with detailed examples. Aside from #1, most of those changes are for advanced use cases, or providers of infrastructure. Day-to-day users shouldn't necessarily see a drastic change. Looking at the new Accellera implementation specifically, I'd say that the most impactful change is actually in the handling of deprecation. Pre-IEEE, the library would keep code in deprecation for as long as humanly possible so as to limit exposure to backwards incompatibility. Post-IEEE, the library is still using deprecation, but we are limiting ourselves to the previous LRM version. In other words: If something was deprecated as of 1.2, it has been flat out removed in the implementation of 2017. Additionally, the API for enabling deprecated code has been inverted... instead of defaulting to "enable deprecated APIs", the library defaults to "disable deprecated APIs". Hopefully that helps shed some light on your question, -Justin
  9. Hello Everyone, UVM provides multiple options to start a sequence from the run_phase of the uvm_test. One of these options is to call <seq>.start(<seqr>); which works perfectly fine. But, if I try to use the other option `uvm_do_on(<seq>,<seqr>) in the run_phase of the test, the simulation fails with the following compilation error with incisive simulator (at the line where `uvm_do_on is called): 'start_item': undeclared identifier [12.5(IEEE)]. Is there any restriction that we cannot use `uvm_do_on method to initiate a sequence from the run_phase of the test? If it is allowed, then why do I get this error? Please suggest. Best Regards Suraj Parkash Gupta
  10. 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
  11. 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.
  12. 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.
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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)
  18. Who can provide a summary of what is new and what has changed?
  19. 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; }
  20. Can you explain the difference between sc_spawn and another process (SC_METHOD, SC_THREAD, SC_CTHREAD )? How to use sc_spawn? Thanks all
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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.
  26. 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
  27. 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
  28. 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
  1. Load more activity
×