GR740-UM-DS, Nov 2017, Version 1.7
408
www.cobham.com/gaisler
GR740
formed on the AHB bus. If a reply was requested it is automatically transmitted back to the source by
the RMAP transmitter.
35.2.2 Protocol support
The core only accepts packets with a valid destination address in the first received byte. Packets with
address mismatch will be silently discarded (except in promiscuous mode which is covered in section
35.5.10).
The second byte is sometimes interpreted as a protocol ID and described hereafter. The RMAP proto-
col (ID=0x1) is the only protocol handled separately in hardware while other packets are stored to a
DMA channel. If the RMAP target is present and enabled all RMAP commands will be processed,
executed and replied automatically in hardware. Otherwise RMAP commands are stored to a DMA
channel in the same way as other packets. RMAP replies are always stored to a DMA channel. More
information on the RMAP protocol support is found in section 35.7. When the RMAP target is not
present or disabled, there is no need to include a protocol ID in the packets and the data can start
immediately after the address.
All packets arriving with the extended protocol ID (0x00) are stored to a DMA channel. This means
that the hardware RMAP target will not work if the incoming RMAP packets use the extended proto-
col ID. Note also that packets with the reserved extended protocol identifier (ID = 0x000000) are not
ignored by the core. It is up to the client receiving the packets to ignore them.
When transmitting packets, the address and protocol-ID fields must be included in the buffers from
where data is fetched. They are
not
automatically added by the core.
Figure 47 shows the packet types accepted by the core. The core also allows reception and transmis-
sion with extended protocol identifiers but without support for RMAP CRC calculations and the
RMAP target.
35.3
Link interface
The link interface handles the communication on the SpaceWire network and consists of a transmitter,
receiver, a FSM and FIFO interfaces. An overview of the architecture is found in figure 46.
35.3.1 Link interface FSM
The FSM controls the link interface (a more detailed description is found in the SpaceWire standard).
The low-level protocol handling (the signal and character level of the SpaceWire standard) is handled
by the transmitter and receiver while the FSM handles the exchange level.
The link interface FSM is controlled through the control register. The link can be disabled through the
link disable bit, which depending on the current state, either prevents the link interface from reaching
the started state or forces it to the error-reset state. When the link is not disabled, the link interface
FSM is allowed to enter the started state when either the link start bit is set or when a NULL character
has been received and the autostart bit is set.
The current state of the link interface determines which type of characters are allowed to be transmit-
ted which together with the requests made from the host interfaces determine what character will be
sent.
Figure 47.
The SpaceWire packet types supported by the core.
Addr ProtID
Dn-2
..
D3
D2
D1
D0
Dn-1
EOP
Addr
D0
Dm-2
..
D4
D3
D2
D1
Dm-1
EOP
