GRSPW datasheet(5/48 Pages) ACTEL

5 / 48 page

GRSPW / GRSPW-FT

December 2008, Version 1.0.2

GAISLER

The RMAP target is an optional part of the core which can be enabled with a VHDL generic. The

RMAP target handles incoming packets which are determined to be RMAP commands instead of the

receiver DMA engine. The RMAP command is decoded and if it is valid, the operation is performed

on the AHB bus. If a reply was requested it is automatically transmitted back to the source by the

RMAP transmitter.

The core is controlled by writing to a set of user registers through the APB interface and three signals:

tick-in, rmapen and clkdiv10. The controlled parts are clock-generation, DMA engines, RMAP target

and the link interface.

The link interface, DMA engines, RMAP target and AMBA interface are described in section 2.3, 2.4,

2.6 and 2.7 respectively.

2.2.2

Protocol support

The core only accepts packets with a destination address corresponding to the one set in the node

address register. Packets with address mismatch will be silently discarded (except in promiscuous

mode which is covered in section 2.4.10). The node address register is initialized to the default

address 254 during reset. It can then be changed to some other value by writing to the register.

The core also requires that the byte following the destination address is a protocol identifier as speci-

fied in part 2 of the SpaceWire standard. It is used to determine to which DMA-channel a packet is

destined. Currently only one channel is available to which all packets (except RMAP commands) are

stored but the core is prepared to be easily expandable with more DMA channels. Figure 5 shows the

packet type expected by the core.

RMAP (Protocol ID = 0x01) commands are handled separately from other packets if the hardware

RMAP target is enabled. When enabled, all RMAP commands are processed, executed and replied in

hardware. All RMAP replies received are still stored to the DMA channel. If the RMAP target is dis-

abled, all packets are stored to the DMA channel. More information on the RMAP protocol support is

found in section 2.6.

All packets arriving with the extended protocol ID (0x00) are stored to the 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 5 shows a packet with a normal protocol identifier. The core also allows reception and trans-

mission with extended protocol identifiers but without support for RMAP CRC calculations and the

RMAP target.

2.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 4.

Figure 5. The SpaceWire packet with protocol ID that is expected by the GRSPW.

Addr ProtID

Dn-2

Dn-1 EOP

GRSPW Datasheet(PDF) 5 Page - Actel Corporation

GRSPW Datasheet(HTML) 5 Page - Actel Corporation

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

Datasheet Download

Link URL