Jump to content

acc_sysC

Members
  • Posts

    49
  • Joined

  • Last visited

Reputation Activity

  1. Like
    acc_sysC reacted to David Black in The difference between run_phase and main_phase in uvm_component   
    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. Thanks
    acc_sysC reacted to karthickg in Error: (E112) get interface failed: port is not bound: port 'core_pim.decoder_addr.IN' (sc_object) In file: ../../../../src/sysc/communication/sc_port.cpp:231   
    The problem is elsewhere (during elaboration - but not specifically because you left a port unconnected). This is your `PIM` constructor:
    PIM(sc_module_name name): sc_module(name) { SC_METHOD(concat_method_sY); sensitive << sY_bit << A << B; /* Etc.. */ decoder<2*N> decoder_addr("decoder_addr"); decoder_addr.IN(FUNC_ADDR); decoder_addr.OUT(sFUNC_ADDR); register_file<1<<(2*N),N> func_regs("func_regs"); func_regs.DATA_IN(FUNC_IN); func_regs.WRITE_ADDR(sFUNC_ADDR); func_regs.WRITE_EN(LOAD); func_regs.READ_EN(RUN); func_regs.clk(clk); func_regs.reset(reset); func_regs.DATA_OUT(sFUNC); /* Etc... */ } Note that the `decoder_addr` (and `func_regs`, `AMux`, `BMux`, etc) are getting instantiated as local variables inside the constructor. These will get destroyed once the constructor execution is complete. You need to fix that.
  3. Like
    acc_sysC reacted to David Black in Dynamic Module in SystemC   
    SystemC components (sc_module, sc_channel, sc_port, sc_export, and sc_prim_channel) are considered to be like blocks of silicon. They are created before the simulator starts time during a phase called elaboration. Elaboration starts when you create (instantiate) the first component. After elaboration closes there are some intermediate phases (end_of_elaboration and start_of_simulation) at which point it is no longer legal to create new components. This differs from processes, data objects (e.g., transactions) created, modified and, passed during run-time. Processes can be created, suspended, resumed, disabled, enabled, reset and killed during runtime. Processes are where all the action occurs during simulation.
    If you created your own custom channels with internal routing and switches, you can dynamically route information between all connected components using your custom channels. You could create a pool of N modules maximally interconnected to these routing channels and then manage suspend/resume and routing at run-time. It's straight-forward SystemC for any competent SystemC coder.
     
  4. Like
    acc_sysC reacted to Eyck in Is it possible to bind the output of a sub-module to two different output ports?   
    You need to connect the output port to a signal and attach a method to the signal driving the multiple output ports. So something like this:
    template<> struct Carries<1> : ::sc_core::sc_module { sc_vector<sc_in<bool>> a, b; sc_in<bool> rIn; sc_out<bool> p, g, rOut; sc_vector<sc_out<bool>> carries; CarryPropGen pg {"PG"}; SC_CTOR(Carries) : a {"vectA", 1}, b {"vectB", 1}, rIn {"rIn"}, p {"p"}, g {"g"}, rOut {"rOut"}, carries {"vectCarries", 1} { pg.a(a[0]); pg.b(b[0]); pg.r(rIn); pg.p(p); pg.g(g); pg.rOut(rOutS); // What I would like to do. SC_METHOD(propagate); sensitive<<rOutS.value_changed(); } sc_core::sc_signal<bool> rOutS; void propagate(){ rOut.write(rOutS.read()); carries[0].write(rOutS.read(); } }; BR
×
×
  • Create New...