GR740-UM-DS, Nov 2017, Version 1.7
146
www.cobham.com/gaisler
GR740
3. The spill-if-not-ready feature is not enabled for the packet being routed.
The link will continue to be started until either the RTR.PCTRL.LD bit is set to 1 or until the link is
disabled through the auto-disconnect feature, as described in section 13.2.13.
The link-start-on-request feature is only available for the SpaceWire ports since the configuration port
and the AMBA ports do not have a link interface FSM and are therefore always considered to be in
run-state.
13.2.14 Auto-disconnect
The auto-disconnect feature allows to automatically disable the link interface of a SpaceWire port if
the port has been inactive for a long enough period of time. Each port can have the feature individu-
ally enabled by setting its corresponding RTR.PCTRL.AD bit to 1. The amount of time for which the
port needs to be inactive is defined by the settings of the global prescaler register (RTR.PRES-
CALER) and the port’s individual timer register (RTR.PTIMER). This time period is the same as the
timeout period used by the port’s data character timer when recovering from deadlock situations (see
section 13.2.15). If the auto-disconnect feature is enabled, a SpaceWire port will automatically disable
its link interface under the following conditions:
1. The link interface entered run-state because it was started by the link-start-on-request feature
described in section 13.2.15.
2. The packet that caused the link interface to start has finished (either sent or spilled).
3. Nothing has been transmitted or received on the port for the duration of the time period specified by
the RTR.PRESCALER register and the corresponding RTR.PTIMER register.
4. The port’s corresponding RTR.PCTRL.LS bit has not been set to 1.
The auto-disconnect feature is only available for the SpaceWire ports since the configuration port and
the AMBA ports do not have a link interface FSM and are therefore always considered to be in run-
state.
13.2.15 Port data character timers
Each port has an individual data character timer, which can be used to timeout an ongoing data trans-
fer in order to recover from a deadlock situation. There are two different timeouts defined: overrun
timeout and underrun timeout. An overrun timeout occurs when the input port has data available but
the output port(s) can not accept data fast enough. An underrun timeout occurs when the output
port(s) can accept more data but the input port can not provide data fast enough.
The timeout period for a specific port is set in its RTR.PTIMER register and the timer is enabled
through the corresponding RTR.PCTRL.TR bit. Timeouts due to overrun and underrun conditions can
also be individually enabled / disabled through the corresponding RTR.PCTRL2.OR and
RTR.PCTRL2.UR bits.
It is always the input port’s data character timer that is used for timing data transfers. When the timer
is enabled, it decrements on every tick as defined by the global prescaler (RTR.PRESCALER regis-
ter). The timer is always restarted when a data character is transmitted from the input port to the out-
put port(s). If the timer expires, the ongoing packet is spilled and an EEP is written to the transmit
FIFO of the output port(s).
The timeout period depends on the system clock frequency and is calculated as follows:
<timeout period> = (<clock period> x (RTR.PR1)) x RTR.PTIMER
Sub-sections 13.2.15.1 through 13.2.15.4 clarifies the behaviour of the timers for different scenarios
that can occur when a packet arrives.