Jump to content


Popular Content

Showing content with the highest reputation since 08/20/2019 in all areas

  1. 2 points
    Actually, you can start a sequence in any phase. It is more important to understand the domain/scheduling relationships between the task based (i.e. runtime) phases. UVM undergoes a number of pre-simulation phases (build, connect, end_of_elaboration, start_of_simulation) that are all implemented with functions. Once those are completed, the task based phases begin. The standard includes two schedules. One is simply the run_phase, which starts executing at time zero and continues until all components have dropped their objections within the run_phase. The other schedule contains twelve phases that execute parallel to the run phase. They are: pre_reset, reset, post_reset, pre_config, config, post_config, pre_main, main, post_main, pre_shutdown, shutdown, and post_shutdown. They execute in sequence. Every component has the opportunity to define or not define tasks to execute these phases. A phase starts only when all components in the previous phase have dropped their objections. A phase continues to execute until all components have dropped their objections in the current phase. Many companies use the run_phase for everything because there are some interesting issues to consider when crossing phase boundaries. In some respects it may be easier to use uvm_barriers for synchronization. Drivers and monitors (things that touch the hardware) are usally run exclusively in the run_phase, but there is nothing to prevent them also having reset_phase, main_phase, etc...
  2. 1 point

    Bus width of socket

    Again, in your case you model a burst read which means in reality data gets transfered in several beats (32 in your case). Since your model does not deal with timing you wont notice that, all you see is that your data gets transfered. Look, TLM2.0 implements a generic bus protocol. Most of the real-world protocols have a so called burst transfer (e.g. checkout the AMBA specs). So the way to model this in an abstract way is to have a bust with and the amount of bytes being transfered in on bus transaction not in one beat. This way it is also possible to describe byte and half-word transfers. HTH
  3. 1 point
    According to log, you are using C compiler driver (/usr/bin/gcc). SystemC is C++, you should write your application in C++ and use C++ compiler driver (g++). Maybe your IDE automatically uses C compiler because you named your source file main.c
  4. 1 point

    Generic pointer to sc_out<T>

    boost::variant would be an option or you use a union. In the latter case you loose the type safety...
  5. 1 point

    Generic pointer to sc_out<T>

    Well, this topic is not easy to solve. In C++ each template instantiation (like sc_in<bool>) is a separate class in the class hierachy. The common base class is sc_port_base and this is in this context more or less useless. Actually there I see 2 options: You store a sc_port_base pointer in your map and upon each write you check for the typeid of the specific template instance and down-cast it using dynamic_cast. This is inflexible and needs additional coding if you want to use new type. You store a writer function in your map which knows how to translate a generic value (like int or double) to the particular value. This might by a lambda which captures the port reference and therefore 'knows' hwo to write to this port. But in this case you would loose type safety as you have to store a generic function unless you can use std::variant. So your map would have to be declared as typedef std::map<std::string, std::function<void(unsigned)> Map0 or (C++17): typedef std::map<std::string, std::function<void(std::variant<bool, sc_dt::sc_uint<2>>> Map0 I personally would go for option 2 as it is simpler and more flexible... HTH
  6. 1 point
    +1 I found https://accellera.mantishub.io/my_view_page.php, but that doesn't seem to list any UVM bug reports?
  7. 1 point
    While traversing, you should have realised already, that all ports (and the other SystemC objects) are derived from sc_object. But even more specifically, you can use a pointer to sc_port_base, the non-templated base class of all ports. That said, the port_wrapper you've shown won't work as is. You'd need to do proper type erasure. But even with that, you still need to instantiate the correctly templated ports/channels within your testbench. The step from a configuration file, i.e. some runtime data, to a (statically typed) C++ object then requires some kind of factory. hth, Philipp
  8. 1 point

    user defined data type signal assignment

    Hi Zarie, that's what I meant by "you must wait a delta". If no time passes, a primitive channel does not update. Kocha's solution will work (adding a call to sc_start - in fact even sc_start(SC_ZERO_TIME) should work. regards Alan
  9. 1 point

    user defined data type signal assignment

    How do you know the assignment is not working? When are you printing out the assigned value? Remember that you must wait at least a delta for a primitive channel to update. There's more about user defined types and sc_signal here http://www.doulos.com/knowhow/systemc/faq/#q1 regards Alan
  10. 1 point
    First of all, you should refer to the standardized API in the IEEE Std. 1666-2011, instead of looking at the source code of the proof-of-concept implementation. This way you make sure that your solution works in other standards-compliant implementations as well. I assume there are specific reasons, why you can't use a proper sc_port (e.g. sc_fifo_in/out), connected to the particular sc_fifo instance of interest? Looping through the design hierarchy to manipulate the model structure is a rather special case in SystemC. No. As you have seen in your tests, the add_static function is private and non-standard. It is an implementation artefact. Instead, you should spawn a process, which is then sensitive to the events. Processes are the natural way to specify event-triggered functionality in SystemC. If you need to keep a handle to an event, you can use a C++ reference (or pointer), instead of creating a new event instance. Events have "identity" and can not be copied or assigned. This is the case for many structural elements in SystemC. sc_event const & ev_ref = sc_fifo_obj->data_written_event(); In the easiest case, you can just create a plain SC_METHOD process, being sensitive to your event. Of course, this requires to wrap the "callback" in a module instance. To make sure your FIFO has been created already, you should create this process in the end_of_elaboration callback of the module: SC_MODULE( fifo_callback_handler ) { // ... void callback_process(); void end_of_elaboration() { // ... find fifo object SC_METHOD(callback_process); sensitive << sc_fifo_obj->data_written_event(); dont_initialize(); // do not run at start of simulation } }; You can also use dynamic processes (sc_spawn, sc_bind) to create processes dynamically during the simulation. See 1666-2011, Section 5.5. Greetings from Oldenburg, Philipp
  • Create New...