Jump to content

David Black

Members
  • Content count

    192
  • Joined

  • Last visited

  • Days Won

    36

David Black last won the day on September 15 2016

David Black had the most liked content!

2 Followers

About David Black

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

451 profile views
  1. All SC_METHOD() not running parallely

    I doubt the reset.neg() is the issue in this case. Furthermore, I disagree that the approach is wrong. Being sensitive to both edges can have a purpose depending on the design. For instance, assuming a positive edge going reset, you might wish to clear various things out on the leading edge and check that they remained so at the trailing edge. The real problem lies somewhere in the methods I strongly suspect. Perhaps the stimuli. We need to see the implementations.
  2. Methods registered as processes via SC_THREAD are not allowed to have arguments and must have the signature: void METHODNAME(void); Think of it this way: When you register a method to be used as a SystemC process, you are telling the simulator kernel to invoke the method for you, and you are also implicitly stating you will not be invoking it yourself. I suspect you simply need to remove the SC_THREAD registration. put(data) will be called from another thread process, and hence does not need a process locally. If your channel requires a local process, it will need to be something that is not part of the interface class.
  3. SC_ID_SC_EXPORT_HAS_NO_INTERFACE_

    Correct. sc_export's must be bound during construction.
  4. Technically, you are not supposed to call sc_stop() more than once during a given simulation. Since version 2.3, you now have the option of using sc_pause() if you wish to go back and forth. But there is a more fundamental issue that should be observed: There is no way to pause an SC_METHOD as Biplab is requesting. You simply must re-enter the method. This is a strong reason for using SC_THREAD, which allows the use of wait(). If for some strange reason you insist on using SC_METHOD, then your only alternative is to create a state machine implementation in combination with using next_trigger(). These comments also apply to using suspend()/resume(), disable()/enable(), or sc_pause()/sc_start().
  5. is it possible to use "virtual public sc_module"?

    It looks like you solved your problem; however, just a C++ note as to using of the keyword 'virtual' with classes and the infamous diamond problem. // Example demonstrating proper use virtual class inheritance to solve the dreaded diamond problem. // Only a problem when base class contains data. #include <iostream> #include <systemc> struct Base { int m_i; Base():m_i(42){} }; // Only one of the following two required to use 'virtual' keyword, but two is safer struct A : virtual Base { int m_a; A(): m_a(1){} }; struct B : virtual Base { int m_b; B(): m_b(2){} }; // The following will only have one copy of 'var' from Base struct Final: A, B { Final() { std::cout << "Constructed Final with m_i=" << m_i << std::endl; } }; int sc_main(int argc, char* argv[]) { Final f; sc_assert( f.m_i == 42 ); return 0; } // Copyright 2015 by David Black // License: Apache 2.0
  6. uvm object into uvm sequence

    What is the compilation error you are seeing?
  7. The problem is that a wire can only be driven with hld_force. The register model assumes they are modeled as regs. You did not indicate how the regs were connected to the wire, but it probably doesn't matter. SystemVerilog allows a single process to assign a reg that is connected to a wire from within a module; however, if more than a single process is involved (e.g. the register model), then wire/assign semantics follow. I suspect that is your problem. If you care to post an example of your modules and how the reg's/wire's are connected and driven, we could confirm this.
  8. Object Oriented programming using SystemC

    Instead of using the SC_MODULE macro, try using a standard declaration: struct Task : sc_core::sc_module, A { ... };
  9. You can launch processes from within a method using sc_spawn(). The SC_THREAD and SC_METHOD macros are only valid inside module constructors. By default sc_spawn() specifies SC_THREAD style behavior. If you need to specify static sensitivity, you will need to use sc_spawn_options. You could also use dynamic sensitivity and process control as an alternative.
  10. execution region of UVM TB

    Normal SV active regions. If you use clocking blocks for signal interface (and refrain from input delay of 0ns), you will not have any problems w.r.t. races.
  11. You can write assertion property that generates events when it detect how long WREADY is asserted and the specific conditions under which it occurs. By means of a simple function call you can then notify the monitor of the data (# cycles) and capture the information to be passed on to a coverage collector. Doulos demonstrate something very like this (measuring Reset pulse widths) in their UVM training.
  12. uvm-systemc

    I'm afraid that information is subject to the rules of Accellera. Only members may get early access and view the current schedule. If your company is a member, then you can get more information privately.
  13. systemC

    Ask Altera support re. Quartus. I doubt it.
  14. Convenience Socket for NoC Mesh

    This is easy. Just name your b_transport implementations: b_transport_N, b_transport_E, b_transport_S, b_transport_W, and register them for the respective sockets. Do the same for all the other methods. I would probably use multi_passthrough flavor of sockets for this. Example: #include "tlm_utils/multi_passthrough_initiator_socket.h" #include "tlm_utils/multi_passthrough_target_socket.h" struct Bus: sc_module // with two bidirectional sockets North & South { tlm_utils::multi_passthrough_target_socket<Bus> targ_socket_N; tlm_utils::multi_passthrough_initiator_socket<Bus> init_socket_N; tlm_utils::multi_passthrough_target_socket<Bus> targ_socket_S; tlm_utils::multi_passthrough_initiator_socket<Bus> init_socket_S; SC_CTOR(Bus) : targ_socket_N("targ_socket_N") , init_socket_N("init_socket_N") , targ_socket_S("targ_socket_S") , init_socket_S("init_socket_S") { targ_socket_N.register_b_transport( this, &Bus::b_transport_N ); targ_socket_S.register_b_transport( this, &Bus::b_transport_S ); ... } virtual void b_transport_N( int id, tlm::tlm_generic_payload& trans, sc_time& delay ); virtual void b_transport_S( int id, tlm::tlm_generic_payload& trans, sc_time& delay ); ... };
  15. Keep in mind that if you add any fields the driver needs to see, they must be present in the base_pkt -OR- there must be some base_pkt methods that provide access via some type of return value.
×