Jump to content

Leaderboard


Popular Content

Showing most liked content since 08/20/2017 in all areas

  1. 1 point
    For all of the bitwise modifiedWrite functions (oneToClear, oneToSet, oneToToggle, zeroToClear, zeroToSet, zeroToToggle) the specified bit write value changes the target bit and the opposite bit write value leaves the target bit unchanged. This provides atomic write access to modify a single bit within a field within a single write transaction. For fields with normal write behavior the write replaces the target field value with the write value. This feature was inherited and expanded from Accellera SystemRDL 1.0 standard which at least has equations for the few bitwise write behaviors it supports. The IEEE 1800.2-2017 UVM standard inherited this feature from IP-XACT and has a slightly better description. We'll make sure that the next version of the standard specifies more completely the behavior of modifiedWrite.
  2. 1 point
    Hi Michael, My understand is that oneToSet also means that writing a 0 has no effect. Best regards, Erwin
  3. 1 point
    Any eventual copy returned from read() by value will never be optimized away, as the source location continues to exist in the signal. The simplest solution is to change your signal converter as follows (untested): template <typename Treal, typename Tcasted> class signal_interface_converter : public sc_core::sc_signal<Treal> , public sc_core::sc_signal_in_if<Tcasted> // only read allowed { typedef sc_core::sc_signal<Treal> real_type; public: explicit signal_interface_converter(const char* nm) : real_type(nm), casted_val() {} const Tcasted &read() const override { return casted_val; } private: void update() override { real_type::update(); casted_val = static_cast<Tcasted>(real_type::read()); ] Tcasted casted_val; }; So the idea is basically to leverage the update phase to update the casted value. If the above doesn't work due to read() overloads based on the return type only, you may need to wrap it differently to separate the two conflicting interfaces (e.g. by using an internal signal with an overridden update() function, triggering the update of the casted value in the converter). Hope that helps, Philipp
  4. 1 point
    Philipp A Hartmann

    unresolved external

    You might want to read this "C++ Super FAQ" entry: https://isocpp.org/wiki/faq/templates#templates-defn-vs-decl Hope that helps, Philipp
  5. 1 point
    You would need to describe your actual question in a bit more detail. Is it about the logic inside the target (i.e. not performing the write)? Sure, you can check the state of the control bit in b_transport before processing the command. Is it about informing the initiator that this happened? Then you need to either use the response status or an extension. /Philipp
  6. 1 point

    Version

    3,819 downloads

    This file, when sourced via your .vimrc file, highlights the HDL (Verilog, SystemVerilog) and Methodology layer (UVM) keywords in the vim editor.
×