How to Read This Lesson

This lesson is an LRM bridge. We translate standard language into the questions you actually ask while debugging and reviewing models.

LRM Expert Reading Method

The IEEE 1666 Language Reference Manual (LRM) is an intimidating PDF of over 600 pages. It is written in strict legalistic language, defining precisely what is allowed (Normative) versus what is just explanatory (Informative).

To become an expert SystemC architect, you must know how to parse this document and map it directly to the Accellera C++ source code.

Source and LRM Trail

This chapter is the LRM bridge. The primary reference is Docs/LRMs/SystemC_LRM_1666-2023.pdf; the secondary reference is .codex-src/systemc. Read the LRM first for the rule, then read the source to understand why the rule produces the behavior you see in a debugger.

1. "Shall" vs "Should" and SC_REPORT_FATAL

In IEEE standards, words have absolute technical meanings:

• SHALL: A strict requirement. If your code violates a "shall," your model is illegal and its behavior is undefined.
  • Under the Hood: In the Accellera kernel, many "shall" clauses are explicitly mapped to runtime checks using sc_assert() or SC_REPORT_FATAL(). For example, the rule "Time resolution shall only be set before simulation starts" is enforced in sc_simcontext::set_time_resolution which checks if(m_simulation_status != SC_ELABORATION) SC_REPORT_ERROR(SC_ID_SET_TIME_RESOLUTION_, "");.
• SHOULD: A strong recommendation. You can ignore it, but you better have an exceptional architectural reason.
• MAY: An optional feature.

However, for performance reasons, not every "shall" is protected by an assertion! For example, many TLM memory management "shalls" have no runtime assertions. If you violate them, the C++ code simply segfaults.

2. Navigating the Clauses and Source Files

Do not read the LRM front-to-back. Treat it as a technical dictionary mapping to the Accellera GitHub repository:

• Clause 4 (Elaboration and Simulation): Maps directly to src/sysc/kernel/sc_simcontext.cpp. Read this to understand why your sc_start() is hanging. It mathematically defines the Delta Cycle (crunch() loop).
• Clause 5 (Core Language): Maps to src/sysc/kernel/sc_module.cpp and sc_process.cpp. Read this to understand exactly what sc_module and SC_THREAD are doing under the hood.
• Clause 11-16 (TLM 2.0): Maps to src/tlm_core/tlm_2/. Read this to understand the precise rules of generic payloads, memory managers, and socket binding.

Practical Example: Reading the TLM Rules

If you read Clause 14 on the tlm_generic_payload, you will see a rule: "The target shall set the response status attribute to a value other than TLM_INCOMPLETE_RESPONSE before passing the transaction object back to the initiator."

This is why, in all our TLM examples, you see this exact code pattern:

#include <systemc>
#include <tlm>
#include <tlm_utils/simple_target_socket.h>
 
SC_MODULE(CompliantTarget) {
    tlm_utils::simple_target_socket<CompliantTarget> socket;
 
    SC_CTOR(CompliantTarget) : socket("socket") {
        socket.register_b_transport(this, &CompliantTarget::b_transport);
    }
 
    void b_transport(tlm::tlm_generic_payload& trans, sc_core::sc_time& delay) {
        // ... process data ...
        
        // Fulfilling the "shall" requirement from the LRM
        // Without this, the initiator's check trans.is_response_error() might behave unpredictably.
        trans.set_response_status(tlm::TLM_OK_RESPONSE); 
    }
};
 
int sc_main(int argc, char* argv[]) {
    // Boilerplate main
    return 0;
}

By reading the LRM closely and cross-referencing with the accellera-official/systemc repository, you stop guessing why things crash and start architecting deterministic hardware models.