Whether or nor write and read accesses to the sc_register are successful during reset should be configurable, at the moment there is no such check so all read and writes are successful during reset.

We get the r_last and r_valid for 2 cycles

I guess that it can be fixed, instead of

putting it in else

if(this->r_ready.read()) { ... 
} else {
            wait(this->r_ready.posedge_event() | clk_delayed); 
}

Because in any case we wait for one cycle afterwards

in process_snoop_resp of simple_initiator_b, the following check

if ( snp.trywait() <0 ) ...

blocks simualiton. Instead , snp semaphore should be checked with

if (snp.get_value ()== 0) ...

then use
snp.wait()
to take the semaphore. then simulation can continue

When using the AXI4 pin adapter: "axi::pin::axi4_target" I have to bind the "w_id" port.

"WID" port was removed in the AXI4 specification. ARM IHI 0022E ID033013 As described below.

Hi, I am interested in your project, and I am looking for a new way to record the TLM trans instead of the logfile, I think you project may be a good solution, but i am confuse with the simple README.md, and don't know how to use in my systemC project, it would be better if there are some example : )

Hi,

I think there is a bug in this part of the code

strb[i] is checked only in the lowest part of the strb signal. It can be the case that strb is active on the upper parts of the signal.

e.g.

size = 8
w_strb = 0xFF00 

Hi Eyck,

in AXI4 protocol, if there is e.g. a burst read transaction of size 2, how many cycles should it last? From the moment it puts first r_valid to true until it asserts r_last ?

From this waveform, I can see it lasting 3 cycles, but shouldn't it last 2 cycles?

We can see that axi4_target is asserting r_valid for 1 cycle, w\o considering whether there is a new data, is that 1 cycle meant to always occur and therefore the burst of size 2 should last minimum 3 cycles?

Hi,

I have run asan (but not on the original repo) and found possible memory leak in:

fsm_handle object is created by calling find_or_create, but never deleted

Chain:

Pin-level model
axi::pin::axi4_target -- PIN2TLM adapter.
axi::pe::simple_target + set_operation_cb + operation_resp(trans, 2) -- on the TestBench side.

Case:

Pin-level Model (Initiator) issues series of AXI write transactions with IDs=[1,0,3,1,0,5,4,2,7,1,0,6]

The pin-level adapter (Target) is accepting Address/Data on AW,W channels and responding with 2 cycle delay on B channel.

Completion of transactions IDs=[1,0,3,1,0,5,4] are correct.

Transaction ID=2 completion was delayed by AXI Initiator by 6 cycles.

Error:

Target changed ID without waiting for Initiator readiness and presented ID=7

Stuck:

Target never accepted any of following IDs=[1,0,6]

In some cases, it appears incorrect timing diagram of ar_ready signal (half-cycle asserted signal).

When creating multiple tlm_target instances inside one sc_module, all socket member variables will have the same name in the object hierarchy, leading to the warning:

Warning: (W505) object already exists: <some_path>.socket. Latter declaration will be renamed to <some_path>.socket_0
In file: kernel/sc_object_manager.cpp:153

It would be an easy fix to extend the existing constructor with a socket_name argument:

axi::axi4_lite_cfg does not work with bind_aw function because all signals are wired there, including aw_user.bind(o.aw_user), although the width of aw_user in axi4_lite_cfg is USERWIDTH = 0

This leads to the following error message

[E] [ 0 s ](E5) out of bounds: sc_uint[_base] initialization: length = 0 violates 1 <= length <= 64 [FILE:/scratch/stas/repos/Tests/Raven/Minres-SystemC/src/sysc/datatypes/int/sc_uint_base.cpp:345]

Hi Eyck,

I haven't seen pool_allocator destructor called. I do see e.g. tlm_mm one called at the end of simulation, and I wander when/how is pool_allocator destructor supposed to be called?

I guess that this should be the case "The storage for the object is allocated when the thread begins and deallocated when the thread ends" cpp reference. Maybe I was doing something wrong?

Would instead of

something like this be used?

    static pool_allocator<T, CHUNK_SIZE> inst;

I am trying to compile, and have some issues with conan.

If I install conan, it installs version2, so I get issues with conanfile.txt (conan2 is using different syntax)

ERROR: Error while parsing [options] in conanfile.txt
Options should be specified as 'pkg/*:option=value'

On the other hand, if I install version 1.59, as recommended in the README.md I get issues with compiler version

ERROR: Invalid setting '13' is not a valid 'settings.compiler.version' value.
Possible values are ['4.1', '4.4', '4.5', '4.6', '4.7', '4.8', '4.9', '5', '5.1', '5.2', '5.3', '5.4', '5.5', '6', '6.1', '6.2', '6.3', '6.4', '6.5', '7', '7.1', '7.2', '7.3', '7.4', '7.5', '8', '8.1', '8.2', '8.3', '8.4', '8.5', '9', '9.1', '9.2', '9.3', '9.4', '9.5', '10', '10.1', '10.2', '10.3', '10.4', '11', '11.1', '11.2', '11.3', '12', '12.1', '12.2']

How did you solve this issue?
P.s. I am using Opensuse OS

in file src/bus_interfaces/axi/pin/axi4_target.h some small refactor can be done in order to get rid of the warnings:

• line 55 and 57: declare functions override
• line 183 and 215: default case (case for TLM_IGNORE_COMMAND)

is +1 correct?

The following code inside src/common/util/range_lut.h [126:129] is not fully correct.

template <typename T> inline void range_lut<T>::addEntry(T i, uint64_t base_addr, uint64_t size) {
    auto iter = m_lut.find(base_addr);
    if(iter != m_lut.end() && iter->second.index != null_entry)
        throw std::runtime_error("range already mapped");

The m_lut container stores entries for the start and end address of every registered object (e.g. sc_register). When adding a new entry, it only checks if the demanded base address is available in m_lut (as start or end address of a previously added entry).

Problem: If a new entry starts in-between the borders of existing entries, the overlap is not detected and no error is thrown.

This case can be reproduced with the code from ticket #24 by removing register four.

After updating the SCC lib to the latest version, ThreadSanitizer complains about data races like this one:
https://jenkins.minres.com/blue/organizations/jenkins/Raven-Tests/detail/Raven-Tests/101/pipeline

[2021-06-09T13:09:01.633Z] WARNING: ThreadSanitizer: data race (pid=7968)

[2021-06-09T13:09:01.633Z]   Write of size 4 at 0x55a30515d360 by thread T2:

[2021-06-09T13:09:01.633Z]     #0 CLIParser::CLIParser(int, char**) /var/jenkins_home/workspace/Raven-Tests@3/RAVEN-Validation/platform/src/CLIParser.cpp:103 (dual_hifive_vp_mt+0x26d1d1)

[2021-06-09T13:09:01.633Z]     #1 top(int, char**, bool) /var/jenkins_home/workspace/Raven-Tests@3/RAVEN-Validation/platform/src/dual_hifive_vp_mt.cpp:78 (dual_hifive_vp_mt+0x23de1b)

[2021-06-09T13:09:01.633Z]     #2 sc_main /var/jenkins_home/workspace/Raven-Tests@3/RAVEN-Validation/platform/src/dual_hifive_vp_mt.cpp:190 (dual_hifive_vp_mt+0x23f3ff)

[2021-06-09T13:09:01.633Z]     #3 sc_elab_and_sim /var/jenkins_home/workspace/Raven-Tests@3/Raven/Minres-SystemC/src/sysc/kernel/sc_main_main.cpp:89 (libsystemc.so.2.3+0x3c3078)

[2021-06-09T13:09:01.633Z]     #4 int std::__invoke_impl<int, int (*)(int, char**), int, char**>(std::__invoke_other, int (*&&)(int, char**), int&&, char**&&) <null> (dual_hifive_vp_mt+0x24d1be)

[2021-06-09T13:09:01.633Z]     #5 std::__invoke_result<int (*)(int, char**), int, char**>::type std::__invoke<int (*)(int, char**), int, char**>(int (*&&)(int, char**), int&&, char**&&) <null> (dual_hifive_vp_mt+0x24d016)

[2021-06-09T13:09:01.633Z]     #6 int std::thread::_Invoker<std::tuple<int (*)(int, char**), int, char**> >::_M_invoke<0ul, 1ul, 2ul>(std::_Index_tuple<0ul, 1ul, 2ul>) <null> (dual_hifive_vp_mt+0x24ce9e)

[2021-06-09T13:09:01.633Z]     #7 std::thread::_Invoker<std::tuple<int (*)(int, char**), int, char**> >::operator()() <null> (dual_hifive_vp_mt+0x24cdf1)

[2021-06-09T13:09:01.633Z]     #8 std::thread::_State_impl<std::thread::_Invoker<std::tuple<int (*)(int, char**), int, char**> > >::_M_run() <null> (dual_hifive_vp_mt+0x24cc88)

[2021-06-09T13:09:01.633Z]     #9 <null> <null> (libstdc++.so.6+0xd6d83)

[2021-06-09T13:09:01.633Z] 

[2021-06-09T13:09:01.633Z]   Previous write of size 4 at 0x55a30515d360 by thread T1:

[2021-06-09T13:09:01.633Z]     #0 CLIParser::CLIParser(int, char**) /var/jenkins_home/workspace/Raven-Tests@3/RAVEN-Validation/platform/src/CLIParser.cpp:103 (dual_hifive_vp_mt+0x26d1d1)

[2021-06-09T13:09:01.633Z]     #1 top(int, char**, bool) /var/jenkins_home/workspace/Raven-Tests@3/RAVEN-Validation/platform/src/dual_hifive_vp_mt.cpp:78 (dual_hifive_vp_mt+0x23de1b)

[2021-06-09T13:09:01.633Z]     #2 sc_main /var/jenkins_home/workspace/Raven-Tests@3/RAVEN-Validation/platform/src/dual_hifive_vp_mt.cpp:188 (dual_hifive_vp_mt+0x23f397)

[2021-06-09T13:09:01.633Z]     #3 sc_elab_and_sim /var/jenkins_home/workspace/Raven-Tests@3/Raven/Minres-SystemC/src/sysc/kernel/sc_main_main.cpp:89 (libsystemc.so.2.3+0x3c3078)

[2021-06-09T13:09:01.633Z]     #4 int std::__invoke_impl<int, int (*)(int, char**), int, char**>(std::__invoke_other, int (*&&)(int, char**), int&&, char**&&) <null> (dual_hifive_vp_mt+0x24d1be)

[2021-06-09T13:09:01.633Z]     #5 std::__invoke_result<int (*)(int, char**), int, char**>::type std::__invoke<int (*)(int, char**), int, char**>(int (*&&)(int, char**), int&&, char**&&) <null> (dual_hifive_vp_mt+0x24d016)

[2021-06-09T13:09:01.633Z]     #6 int std::thread::_Invoker<std::tuple<int (*)(int, char**), int, char**> >::_M_invoke<0ul, 1ul, 2ul>(std::_Index_tuple<0ul, 1ul, 2ul>) <null> (dual_hifive_vp_mt+0x24ce9e)

[2021-06-09T13:09:01.633Z]     #7 std::thread::_Invoker<std::tuple<int (*)(int, char**), int, char**> >::operator()() <null> (dual_hifive_vp_mt+0x24cdf1)

[2021-06-09T13:09:01.633Z]     #8 std::thread::_State_impl<std::thread::_Invoker<std::tuple<int (*)(int, char**), int, char**> > >::_M_run() <null> (dual_hifive_vp_mt+0x24cc88)

[2021-06-09T13:09:01.633Z]     #9 <null> <null> (libstdc++.so.6+0xd6d83)

[2021-06-09T13:09:01.633Z] 

[2021-06-09T13:09:01.633Z]   Location is global 'logging::Log<logging::Output2FILE<logging::DEFAULT> >::reporting_level()::reportingLevel' of size 4 at 0x55a30515d360 (dual_hifive_vp_mt+0x000000731360)

[2021-06-09T13:09:01.633Z] 

[2021-06-09T13:09:01.633Z]   Thread T2 (tid=7972, running) created by main thread at:

[2021-06-09T13:09:01.633Z]     #0 pthread_create <null> (libtsan.so.0+0x5ea99)

[2021-06-09T13:09:01.633Z]     #1 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) <null> (libstdc++.so.6+0xd7048)

[2021-06-09T13:09:01.633Z]     #2 main /var/jenkins_home/workspace/Raven-Tests@3/RAVEN-Validation/platform/src/dual_hifive_vp_mt.cpp:204 (dual_hifive_vp_mt+0x23f53c)

[2021-06-09T13:09:01.633Z] 

[2021-06-09T13:09:01.633Z]   Thread T1 (tid=7971, running) created by main thread at:

[2021-06-09T13:09:01.633Z]     #0 pthread_create <null> (libtsan.so.0+0x5ea99)

[2021-06-09T13:09:01.633Z]     #1 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) <null> (libstdc++.so.6+0xd7048)

[2021-06-09T13:09:01.633Z]     #2 main /var/jenkins_home/workspace/Raven-Tests@3/RAVEN-Validation/platform/src/dual_hifive_vp_mt.cpp:203 (dual_hifive_vp_mt+0x23f521)

[2021-06-09T13:09:01.633Z] 

[2021-06-09T13:09:01.633Z] SUMMARY: ThreadSanitizer: data race /var/jenkins_home/workspace/Raven-Tests@3/RAVEN-Validation/platform/src/CLIParser.cpp:103 in CLIParser::CLIParser(int, char**)

At the moment only transactions with gp.get_data_length() == gp.get_streaming_width() are allowed.
It would be beneficial if tlm_target would allow FIFO like accesses to resources.

This size is not always correct:

According to spec (Page. D3-187 IHI0022H_c_amba_axi_protocol_spec.pdf )

The following transactions have a single read data channel transfer:

- CleanUnique
- MakeUnique
- CleanShared
- CleanInvalid
- MakeInvalid
- Barrier
- DVM

So in this case, first ar_snoop should be read, and then set the correct size, right?

Hello,

The README specifies a c++11. I was wondering if SCC could be used with c++std>11, too, but noticed that the build fails because of a missing include in incl/scc/report.h

Here is the log of a c++17 build with GCC 10: scc_buildlog.txt

The fix is to include <cstring> in the header to make strcmp visible again. Here is the patch: 0001-insert-cstring-include-for-c-11.patch.txt
The include should not interfere with c++11.

Hi Eyck,
not sure if there is a bug in this line:

https://github.com/Minres/SystemC-Components/blob/7d8a0173b219d684c80ba268086b31027d4a7402/src/bus_interfaces/axi/pin/axi4_initiator.h#L174C13-L174C13

In case we have e.g. 32B wide bus, we want to have single 4B write, with an offset 30, strb will be all zeros.
How this write should be handled?

Currently, only byte-addressed resources can be used with scc::tlm_target. The underlying type util::range_lut throws a std::runtime_error("range already mapped") if word-addressed entries are added.

Use case: Integrated circuits (discrete components) typically communicate over serial interfaces (I2C, SPI, ...) and use word addressing for the registers. To model this properly with TLM, SCC should support this.

The issue can be reproduced with the following register container class.

class test_regs : public sc_core::sc_module, public scc::resetable
{
public:
  uint32_t reg_one;
  uint32_t reg_two;
  uint32_t reg_three;
  uint32_t reg_four;

  scc::sc_register<uint32_t> one;
  scc::sc_register<uint32_t> two;
  scc::sc_register<uint32_t> three;
  scc::sc_register<uint32_t> four;

  test_regs(sc_core::sc_module_name name) :
      sc_core::sc_module(name),
      NAMED(one, reg_one, 1111, *this),
      NAMED(two, reg_two, 2222, *this),
      NAMED(three, reg_three, 3333, *this)
      NAMED(four, reg_four, 4444, *this)
  { }

    inline void registerResources(scc::tlm_target<32> &target)
    {
      target.addResource(one, 0x01);
      target.addResource(two, 0x02);
      target.addResource(three, 0x03);
      target.addResource(four, 0x04);
    }
};

Note: Multiplying the real addresses by the byte-size of the registers is a work-around but not a decent solution.

When using the function dump_configuration(...) of the scc::configurer, parameters that have a separate originator at the top level do not get dumped.