Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 08/22/2020 in Posts

  1. David Black

    sc_inout class

    Nothing wrong. Your output will be available after the delta cycle completes. You can view the new value in the next delta cycle. The problem for you conceptually is that you think 'S_val_out = expression' is a blocking statement. In other words, you expect the value to be transferred to the current value of S_val_out at the end of the assignment. Actually what is happening is akin to: S_val_out->write( A_val_in->read() +B_val_in->read() ); External to your sum class object, the S_val_out is bound to a channel sc_signal<T>, where the write() method is implemented. T
    1 point
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. @omaima RTFM please. It's all in the README and related files. Better yet, signup and take a class from somebody.
    1 point
  8. Than you have a typo in another place: class target : public sc_module { public: sc_export<sc_signal_in_if<bool> > in; ---- > Change to sc_export<sc_signal_inout_if<bool> > in; sc_signal<bool> sig; target(sc_module_name name){in(sig);} }; The problem is that you try to bind port and export with different interfaces
    1 point
  9. this sounds like a bug. normally the sequence and/or items do know on which sequencer they run on *or should run on". there are a few situations where that in of is/was missing. a recent issue i remember was one where when an item was sent to a low level bfm sequencer from a virtual sequence running on a null sequencer then the sequencer info was wrong leading to similar fails.. /uwe
    1 point
  10. A1: You can start your simulation with the +UVM_CONFIG_DB_TRACE plusarg to see messages for set(...)/get(...) in the log file. A2: You can have both use models. You can either tell the sequencer to start a sequence of a certain type by providing a type wrapper (like you did and the sequencer will instantiate it itself) or you can directly provide an instantiated sequence which you randomized/configured to your heart's desire (and the sequencer will start it). If you run your simulation with UVM_FULL (at least on the sequencer) you should see a message saying that it started the phase seque
    1 point
  11. Hi, declaring a class virtual means that the class itself cannot be instanced - it must be extended. So you can't make an instance of uvm_scoreboard on its own. However uvm_scoreboard is itself derived from uvm_component. uvm_component has a constructor (new function) which needs the two arguments (name and parent). If you derive from a base class and don't write your own constructor in the derived class, then the default constructor will get called. If the default constructor is called, then the standard says (1800-2012 p145) "super.new call shall be the first statement execu
    1 point
×
×
  • Create New...