Feature: Timeout events handling

[dpretet]

Timeout detection and management can be enabled and configured by interface.
This avoids any deadlock if a slave doesn't respond to a request, or if a
master doesn't accept a completion.

The timeout management is done on slave interface (connected to a master agent)
and on master interface (connected on a slave agent). The timeout circuits run in
the clock domain of the switching logic, not on the master pr slave agent clock. So the
timeout counters never require any CDC stages.

The timers could be implemented in different manners:

• With a shared counter implement millisecond or microsecond time reference,
  configurable based on the platform clock speed, spreading all the master and slave interface.
  Then all the master / slave interfaces would also implement a (small) local counter to measure
  timeout. This solution allows a compact implementation but is not very precise.
• With a (wide) local counter in each master/slave interface. This solution will be very precise but require
  more area.

Time out events may occur on slave interface (connected to a master agent)
and on master interface (connected on a slave agent). Timeout events can occur
only inside the core (on switching logic) and/or with slave agents. The interconnect
will always accept new request if internal buffer are not full.

Timeout events can occur:

• between slave interface and master interface for address/data channels (internal)
• between master interface and slave interface for write completion channel (internal)
• between master interface and slave interface for read data channel (internal)
• between master interface interface and a slave agent for address/data channels (external)
• between slave agent and a master interface for write completion channel (external)
• between slave agent and a master interface for read data channel (external)

A timeout event must:

• be marked with SLVERR in completion channel
• drives a request / completion interface to free it

The core's behavior ensures the agents can continue to operate, but can't ensure
the whole system will still be operational. The user needs to correctly manage
these situations by communicating with a defecting slave or master and reboot it.

It would be suitable the axe-interconnect core implements a debug interface to stream
such event and inform the SOC's root master. In critical issue, the root master may reboot
the system.