Difference between revisions of "Spacewire"

From TASTE
Jump to: navigation, search
Line 8: Line 8:
 
In case you need to configure the router, modifications shall be made in the respective routing tables within the spwrouter_custom_config.c file. Right in the beginning of this file you’ll find a structure where it is defined which ports (or logical addresses) and respective parameters are enabled and which ones are not. Please, refer to Figure 1-3 - Structure to enable/disable ports and respective parameters. You are recommended to picture the numbers as binary numbers to fully understand the logic.  
 
In case you need to configure the router, modifications shall be made in the respective routing tables within the spwrouter_custom_config.c file. Right in the beginning of this file you’ll find a structure where it is defined which ports (or logical addresses) and respective parameters are enabled and which ones are not. Please, refer to Figure 1-3 - Structure to enable/disable ports and respective parameters. You are recommended to picture the numbers as binary numbers to fully understand the logic.  
  
 +
 +
[[File:SpW-Figure-1-3.jpg]]
 
(Figure 1-3)
 
(Figure 1-3)
  

Revision as of 14:34, 16 November 2017


The router

The Spacewire router of the LEON4-N2X board (NGMP board) interprets the address contained within a packet to be sent or received, and realizes the routing of this packet, according to the rules present in the routing table, to one of the existing physical ports. In case of the LEON4-N2X board, it contains 8 SPW ports and 4 AMBA.

In case you need to configure the router, modifications shall be made in the respective routing tables within the spwrouter_custom_config.c file. Right in the beginning of this file you’ll find a structure where it is defined which ports (or logical addresses) and respective parameters are enabled and which ones are not. Please, refer to Figure 1-3 - Structure to enable/disable ports and respective parameters. You are recommended to picture the numbers as binary numbers to fully understand the logic.


SpW-Figure-1-3.jpg (Figure 1-3)


The number 4 is represented in binary as 0100. Since the second bit from the left controls if the port (or logical address) is enabled or not, in this case it is enabled, i.e it takes the value 1, and no other options are enabled. The table show us that the ports (or logical addresses) with the values from 20 HEX (31 in decimal) to 8F HEX (143 in decimal) are enabled. Please, note that ports 0 – 31 DEC are enabled by default. The number 5 is represented in binary as 0101. Since the forth bit controls the header deletion from the messages send/received from that port (or logical address), this bit being at 1 means the header will be deleted when using the ports configured with this value. The table show us that ports (or logical addresses) with the values from 90 HEX (144 in decimal) to FF HEX (255 in decimal) are enabled and the header deletion option is enabled for these ports (or logical addresses) as well.

The following tables define the routing logic followed by the router. Please, refer to Figure 1-4 - Routing tables for ports and logical addresses. For the first 31 values, the routing matches directly a physical port, in case it exists. The following values, 32 – 255, are merely seen as logical addresses. This means that the router will route whatever comes with these addresses to one or more of the existing physical ports (8 SPW, ports 1 – 8, and 4 AMBA, ports 9 – 12, available in the case of the LEON4-N2X board).

(Figure 1-4)

Once again, you are recommended to picture the numbers as binary numbers to fully understand the logic. To make it clear let’s look at an example. The address 1 and the address 33 (21 in HEX) have both the same value (highlighted in blue in the figure), 2 HEX (0x00000002 HEX). If we look at the binary representation of this value it is 000…000010. This shall be read as the first bit counting from the right corresponding to the physical port number 0, the second bit corresponding to the port number 1, and so on. Thus, the value 2 means we are redirecting both the 1st and the 33rd addresses to the port number 1. While the 1st address makes perfect sense that is routed to the port number 1, the 33rd address is doing it because we want this as a routing rule, for packets to be sent/received at this port when the address 33 is given. Would we modify the 33rd address to 0x00000004 HEX for example (000…0100 in binary) and the routing rule would change. In this case packets would be sent/received at port number 2, instead of number 1, when the 33rd address is specified. Note that for clarity and consistency we opt to keep the first twelve addresses routed to the first 12 ports (the 8 SPW and the 4 AMBA) ordered in the most natural manner.


Spacewire Time Code

The time code concept is explained in this "link":http://spacewire.esa.int/content/Home/Time-Codes.php

All Spacewire configuration is done at _struct grspw_config dev_def_cfg_ at the *po_hi_driver_rasta_spacewire.c*

It includes the following for time code

.tc_cfg = TCOPTS_EN_TX|TCOPTS_EN_RX,/* Enable TimeCode */ .tc_isr_callback = app_tc_isr,/* TimeCode ISR */ .tc_isr_arg = NULL, /* No TimeCode ISR Argument */


Basically will only need o enable it to have it.

When a time code is received it will call the app_tc_isr callback, it is function declared further below that we can customize to further handle the time code. It has one parameter with integer time code value.

There is function to obtain current time code

   *int router_get_tc(void *p, unsigned char *tc)*


Spacewire Plug and Play

The GR740 supports the Pnp protocol as states in its manual:http://www.gaisler.com/doc/gr740/GR740-UM-DS.pdf .

The manual provide a configuration port to apparently acesss the Pnp Register to know about the plugged in spacewire devices.

In terms of software PnP seems to be completely transparent to the user, the only detect code is a flag to inform user if HW supports the PnP:

 In    *void router_print_hwinfo(struct router_hw_info *hwinfo)*

printf(" Timers available:  %s\n", hwinfo->pnp_avail ? "YES" : "NO");


SpaceWire Router in the N2X and GR740 board

h2. Header duplication

Following what we think it's presumably the spacewire convention. It specifically says in the board data sheet that the message to be received at the end of the road, meaning when it reaches the final AMBA port, must have its header, however the router should be deleting the 1st byte of the header in the physical ports. This is achieved in the gaislersamples/router_demo by setting the 1st byte in the data field to have the last header byte.

In our device driver, since we know that we are receiving an iop_wrapper_t struct, that has a single buffer pointer to a buffer, and information about the header and payload offsets, we decrement the payload offset by 1, in order the contain the last header byte and increase the size by 1.

Gaisler has been contacted about the header duplication issue, below is the transcript of their feedback


bq. I'm not sure I understand your question but I will try to answer. The N2X has a router inside which is able to route based on logical addressing and/or path addressing. When header deletion is enabled (typically when path addressing) an "extra" byte is needed to select which port to route to/from within the N2X. If you configure the routing table to route incoming packets with node address X to AMBA port Y and you configure the AMBA port Y with the node address X, then the "extra byte" is not needed. I hope this answers your question.