[gem5-users] Connecting non-coherent component to coherent XBar

[Sebastian Rachuj]

Dear All,

I am using gem5 with a self-written operating system (actually bare
metal) for AArch64 and some custom SystemC modules, I connected using
the ExternalSlave/TLM port. The dot plot of the config is attached.

When only running one CPU core (that means that the other core is
spinning in an endless loop) it works fine. All my bare-metal programs
are running without any errors. However, when I also have a more complex
program running on the second core, gem5 fails with

panic: panic condition pkt->cacheResponding() occurred: Should not see
packets where cache is responding

I found out that this error occurs due to an express snoop going to the
bridge's slave port. My assumption is that I somehow have to configure
the connection from the membus (actually only a coherent XBar) to the
bridge in a way that stops snoop packets from getting forwarded to the
bridge. Unfortunately, I have no idea how this works or if this means
implementing a coherent bridge.

Additionally, I tried some other topologies of the XBars like directly
connecting the IOBus (non-coherent XBar) to the MemBus (coherent XBar).
However, then it fails with

panic: system.iobus.slave[0] was not expecting a tryTiming

Connecting the ExternalSlave directly to the MemBus does not work
neither due to the same error:

panic: system.tlm.port was not expecting a tryTiming

When changing the MemBus to a non-coherent XBar, the following assertion
fails:

design: build/ARM/mem/noncoherent_xbar.cc:110: virtual bool
NoncoherentXBar::recvTimingReq(PacketPtr, PortID): Assertion
`!pkt->isExpressSnoop()' failed.

Is my approach for connecting an ExternalSlave to the processor system
even the correct one or do I have to do it in a different way?

The gem5 commit I'm currently working on (with some changes to debug my
problem with software traps) is 0473286ab1e9992a906eff380000bf90c82eeccb.

Any help is appreciated.

Best Regards,
Sebastian Rachuj

[Nikos Nikoleris]

Hi Sebastian,

It's hard to say which MemObject received the packet where the flag cacheResponding was set. In typical Arm systems (not very different from the one you have), packets with cacheResponding set would stop at the CoherentXBar which has the point_of_coherence parameter set (configuration parameter). In your system, I would start by making sure that MemBus has point_of_coherence set.

Nikos

On 27/07/2018, 08:55, "gem5-users on behalf of Sebastian Rachuj" <gem5-users-***@gem5.org on behalf of ***@fau.de> wrote:

Dear All,

I am using gem5 with a self-written operating system (actually bare
metal) for AArch64 and some custom SystemC modules, I connected using
the ExternalSlave/TLM port. The dot plot of the config is attached.

When only running one CPU core (that means that the other core is
spinning in an endless loop) it works fine. All my bare-metal programs
are running without any errors. However, when I also have a more complex
program running on the second core, gem5 fails with

panic: panic condition pkt->cacheResponding() occurred: Should not see
packets where cache is responding

I found out that this error occurs due to an express snoop going to the
bridge's slave port. My assumption is that I somehow have to configure
the connection from the membus (actually only a coherent XBar) to the
bridge in a way that stops snoop packets from getting forwarded to the
bridge. Unfortunately, I have no idea how this works or if this means
implementing a coherent bridge.

Additionally, I tried some other topologies of the XBars like directly
connecting the IOBus (non-coherent XBar) to the MemBus (coherent XBar).
However, then it fails with

panic: system.iobus.slave[0] was not expecting a tryTiming

Connecting the ExternalSlave directly to the MemBus does not work
neither due to the same error:

panic: system.tlm.port was not expecting a tryTiming

When changing the MemBus to a non-coherent XBar, the following assertion
fails:

design: build/ARM/mem/noncoherent_xbar.cc:110: virtual bool
NoncoherentXBar::recvTimingReq(PacketPtr, PortID): Assertion
`!pkt->isExpressSnoop()' failed.

Is my approach for connecting an ExternalSlave to the processor system
even the correct one or do I have to do it in a different way?

The gem5 commit I'm currently working on (with some changes to debug my
problem with software traps) is 0473286ab1e9992a906eff380000bf90c82eeccb.

Any help is appreciated.

Best Regards,
Sebastian Rachuj


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Sebastian Rachuj]

Hi Nikos,

Post by Nikos Nikoleris
It's hard to say which MemObject received the packet where the flag cacheResponding was set. In typical Arm systems (not very different from the one you have), packets with cacheResponding set would stop at the CoherentXBar which has the point_of_coherence parameter set (configuration parameter). In your system, I would start by making sure that MemBus has point_of_coherence set.

That was simple. "point_of_coherency" was exactly the option I was
looking for. Thank you very much!

Best Regards,
Sebastian