1. Approach

The SpeA-card provides a Single-Pair-Ethernet connection to any controller via SPI for fast cycles (32..50 µs) and the low and safe data rate of 10 Mbit/s for long distances.

This document describes hints for the controller software.

2. Cycle Synchronization approach

The approach of the Ring Cycle Synchronization is:

All Stations in the Ring should work synchronous.

It means they works with a synchronous step cycle (usual as hardware interrupt of the processor for fast cycle times), and the frame signals of this cycle can be used for determine the time and width of signals (analog signals, pulse outputs etc.).

The signals for the cycle comes for SPE-Ring-Slaves from the FPGA:

The master in the SPE-Ring-communication is responsible to the correct cycle. The master by itself can also be synchronized by a higher master in other communication relations, this is not clarified here. But this idea should be presented here, because a comprehensive system should be able to work synchronously.

The SPE-Ring-Master starts the transmission of the SPE telegram with the frame_in signal. Starting from frame_in a defined number of synchronization bits are transmitted, after them the data are following. The SFD (Start frame delimiter) is a bit sequence between the synchronization bits and the data, this SFD is important for the telegram timing.

On a SPE-Ring-Slave with the SFD the signal a frame_out is produces as output of the FPGA to use as input to the controller (low active after SFD). This signal has a minimal jitter due to the clock sync capability (measured 30 ns) and a known delay of transmission compared to the frame_in in the SPE-Ring-Master. The following Oscilloscope view (living as gif image) shows that relations:

FrameIn FrameOut2

In the Overview you see frame_in in the master on D14 and frame_out in the Slave on D10. Both have a delay from 10.95 µs, that is the length of the synchronization pattern + the transmission time. After zooming you see a jitter from only ~ 30 ns on the frame_in on slave, though the source of the signal is in the master and the full transmission via SPE is between both. That is less. See ..\SpeA-FPGA\SpeA-JavaFPGA.html##ClkSync_Mdls. There is described that the internal working clock (CE signal) is synchronized, so that the jitter is minimal.

With the frame_out as input to the controller either an interrupt to process the data can be start. Or better, an internal PWM can be controlled by a PLL (Phase Look Loop) algorithm, see next chapter.

See chapters:

The next slave stations in the Ring receives the SFD in a exact related time with less delay, because the telegram is immediately forwarded in hardware. Only an additional jitter is added again, so that the jitter in compare to the master is now ..50 ns. This may be only prevented by an synchronization of the internal clock itself. In the yet given solution only the CE signal is synchronized, hence the internal non synchronized clocks of 10 ns in any station produce this non preventable jitter. But this jitter is low (50 ns vs. 50 µs cycle in the second slave, till …​ 300 ns jitter in the 10th slave).

The accuracy of the PLL control depends on the timer resolution in the microController and produces also a jitter in this range, see PLL control of the interrupt cycle

With a common cycle also it can be done:

  • The average time for Measurements should exact follow this cycle. For Measurements always the middle value (average, integral) of the pre-period should be used as characteristic of input signals, not a accidently time for a fast measurement. This is necessary to suppress technical noise which is usual synchronous to the actuator period (from a PWM), or also, to suppress accident disturbance with a higher frequency as the measurement one.

  • A PWM (Pulse Width Modulation) often use for output of data, for example Firing pulses for power valves or also simple outputs should work exact synchronous in this cycle to refresh the current data in each cycle.

2.1. Standard time stamp approach ? Or time in synchronized cycles

For Ethernet with >= 100Mbit/s there is a NTP "Network Time Protocol" (https://en.wikipedia.org/wiki/Network_Time_Protocol) or better PTP (Precision Time Protocol) (https://en.wikipedia.org/wiki/Precision_Time_Protocol) can be used, accordingly to the TSN (Time Sensitive Network) rules (https://en.wikipedia.org/wiki/Time-Sensitive_Networking).

But this technologies works only for the connections >= 100 Mbit/s, because they are not regarded in the original Ethernet 10 Mbit/s topology. The problem of the originaly 10 Mbit/s Ethernet was: The time of transfer of a telegram depends on the status of the line. For the line a Bus Topology is used. It means all station attacks the line. It is deterministic for transmission in a time range in milliseconds, regarding displacement mechanisms, but not for exact time stamps. Due to the presence of the star topology with its continue data stream, which can work with TSN and PTP, a proper time synchronisation for the 10 Mbit/s where never developed.

Now with SPE also the Bus Topology is in focus, with the so named "Multidrop Technology", and that does not support the time synchronization yet and per default.

But, the Ring Topology offers another approach for Time Synchronization:

  • Prior, not the time stamp should be offered to all stations as accurate as possible, but:

  • All stations should work synchronous.

It means the stations in the ring have the same time, but they don’t know (need not know) the exact absolute time. They work together, out of a global time.

It is possible to insert this stations in a global time (UTC, master clock etc.), but this is task only of the master in the Ring Topology. The master can do so by using one of the possible approaches: Standard Ethernet with TSN and PTP or NTP, or specific variants of SPE (with higher bit rates and Star Topology), which also supports TSN, NTP, PTP. Then the master can forwarding this absolute time in the Ring to all other stations with the Ring Cycle Synchronization, described following.

2.2. PLL control of the interrupt cycle

The solution of PLL control is individual for different controller. The principle is:

  • Measurement or capture of the time where the frame_in is occurring, as relative time related to the currently counting interrupt timer.

  • Comparison of this time information with the expected time. This is very simple if the interrupt is forced by the same timer.

  • Adjusting of the timer for the interrupt due to the measured difference. Whereby not the exact measured difference should be used for the new value. This is a simple P-part-controller. It is better to have a real PI controller (Proportional and Integral Part) which is changed by the time difference as input. The output can be used as reload value for the timer, which generates the interrupt.

It means while PLL controlling the interrupt cycle is a little bit lesser or greater, not constant with the same reload value. A constant cycle has usual not the same time as in the master cycle because of quartz frequency tolerances. It would run away by accumulation of time. Hence the time should be adjusted sometimes a little bit.

                   !                       moment of the frame_in
..0..........987654321.................... timer count value
                  +                        expected moment of the frame_in

In the shown situation the next cycle should be 1 time longer so that the expected moment and the occuring moment of the frame_in should be better matching. But the following cycles may be the same again, but in the mid value a little bit longer to prevent furthermore abbreviations.

If for example the frame_in comes with a cycle of 50 µs with the quartz of the SPE-Ring-Master, with 5000 steps of a 10 ns internal clock, but a slave has an abbreviation of the quarts frequency from +0.001% (10 ppm), then is should have ~5000.05 steps. It means, 19 times 5000 steps and 1 time between 5001 steps for the interrupt counter reload value. It results on a jitter of ~ 10 ns, but an exact synchronization. Because the measurement has also a resolution of this 10 ns, the value is not exact, it results last not least in a little bit greater jitter of maybe 30 ns (as experience). If the clock frequency or the frequency of the appropriate counter and capture units are lesser, for example 20 MHz resolution (50 ns steps), the resulting jitter is in range of ~150 ns.

This counters may determine also sample and integration times in hardware or Pulse Width Modulation (PWM) times. In comparison to the 50 µs cycle this is a inaccuracy in range of < 1% jitter, but a higher accuracy over more cycles (related to middle values), hence acceptable.

Todo idea that the capture and control is part of the FPGA!

Old text:

The different length of an interrupt cycle is a jitter between the Ring cycle (telegram cycle) and the internal timer and interrupt. The range of this jitter depends on the resolution of the timer. If the timer both for interrupt and capture runs with 10 MHz only (100 ns), then the jitter is of course > 100 ns. Because of some small inaccuracies the jitter may be in range of 300 ns. This is added to the telegram jitter (from 30 ns in the first station to 300 ns in the 10th station). A sum of 600 ns jitter for a 50 µs interrupt cycle is not too far. But for analog measurement and also for the PWM output this can be on a limit.

Another possibility for synchronization of the controller with the Ring cycle is: Using a Clock output signal from the FPGA caused by the internal central CE clock as clock input for the processor. Processors sometimes have a PLL for the internal clock to generate a higher clock frequency from a Quartz with lower frequency. Measurement the time of frame_in should than be used only for the first synchronization and also for checks.

For this solution it should be known that the 10 MHz or 5 MHz clock output can have abbreviations from the constant frequency because of the clock synchronization, see link:../SpeA-FPGA/SpeA-JavaFPGA.html#RxClkSync>> in the FPGA itself. The CE period switches between 9..10 internal clock periods (90..100 ns) or between 10..11 (100 .. 110 ns). This unrest should be processed by the controller’s PLL.

Hence the best solution is: The FPGA clock itself does not come from the Quartz, it does come from a PLL in the FPGA. Then each FPGA can be synchronous to the master’s quartz frequency. And also, the controller in the master is forced by the FPGA quartz or vice versa (maybe better). Hence only one quartz frequency exists in the whole ring. All is synchronous in one ring. Another related ring can be used also the same controller quartz if it is mastered by the same controller. This is the best solution of exact cycle synchronization.

Because of the cycle synchronization so far as possible all stations have the same time, independent whether they use (and knows) the time stamp itself or not.

3. Data exchange between the application in the controller and the FPGA via SPI

For the data exchange between an Ethernet adapter (its PHY chip) and the controller usual SPI is used ("Serial Peripheral Interface"). SPI is familiar for all controller. This is also the solution for the SpeA-card.

In opposite to common known solutions for Ethernet adaption to controller, this SpeA-card (its PHY) does not store data internally. Storing data means, first the data are written via SPI with any baudrate in the PHY chip of the Ethernet-Adapter. Only after writing the whole telegram content, the telegram is transmitted. Receiving data are handled adequate, first the received data are store inside the PHY, then the controller reads it out.

The decoupling of SPI transfer and Ethernet telegram transfer is an advantage for the controller software, it is independent. For example the controller may be slow (< 10 MBit/s for SPI transfer) but the Ethernet is fast (100 Mbit/ 1 Gbit). But with this approach only transfers in Millisecond range can be done. In opposite, the SpeA-card supports for Microsecond cycles. The data are immediately "on the fly" transmitted from the RAM to the SPE telegram output, and also immediately written on RAM while receiving. This is possible also because the transfer on SPE is done with the adequate baud rate is usual for SPI transfer, 10 Mbit/s The application can decide whether accessing the data so fast as possible, or also sensible after the CRC check.

For that the solution for SPI is: The SpeA-card acts as master for the SPI communication, the controller is the slave. The controller prepares the access, whereby DMA should be used, but the SpeA-card determines the timing of the SPI access.

Additionally, especially for configuration data, or for a simple controller in an SPE-Ring with less data communication, the controller can access the SpeA-card also as SPI-Master, the SpeA-card is then the SpiSlave. This can be used also for data communication if the controller is slow (does not support 10 Mbit/s SPI or has DMA possibilities) and the station is Slave in the SPE-Ring topology. Then most of the data are transferred from the Rx to Tx in the ring, independent of the controller. Only a few data which are stored internally in the FPGA are exchanged with the controller.

3.1. Reset State of the SpeA card

The SpeA card is not automatically reseted if the control is reseted and vice versa.

If the controller comes out from reset, it should be firstly program the SpeA card with SPI master access. This should determine completely the internal state of the card independent of the state before. In that time the signal frame_in should held passive low.

If the SpeA card was reseted, but the controller works furthermore, the SpiMaster access from the SpeA card is not done. This situation should be detected in the controller’s cycle, by testing the SPI register states. The controller should then start a new initialization phase of the SpeA with low inactive frame_in signal.

If the SpeA card was reseted and the controller accesses the SpeA card by itself as SPI master, it reads out the bit bSet as 0. See Mode bits in configuration. Then a new initialization should be started in the controller.

A SpeA-card which is not connected to the controller, or the controller is in reset or crashed after reset, the SpeA-card works proper as SPE-Ring Slave. See the default mode bit states in Mode bits in configuration This is important because the communication in the Ring should not depend on the proper work the software in any station in the ring. On faults the ring should primary work.

Only the dedicated master in the ring can be determined by hardware to prevent this SPE-Ring Slave forward transmission. This is necessary because otherwise a life of its own can occur: A telegram can be generated and circle continuously in the ring. The master functionality breaks this forward transportation, and the ring is silent if the master is silent.

The hardware determination for master is a jumper (connection) between J3.9 (FPGA pin A16) and J3.10 (GND).

3.2. Set the configuration with SPI master access from controller, especially after reset

Without using the frame_in signal, held it inactive low, the SPEa-card can be accessed for all configuration and data register via SPI, whereby the controller is master of SPI, the SpeA-card is slave.

A complete overview over all mode bits in the configuration is given in SpeA-ControllerSw.html#SpeA_FPGA_ModeBits

  • The card can be switched as master or as slave for SPE transmission independent of the hardware determination on jumper J3.9-10. It means a predicated master can programmed as slave and vice versa. This is necessary for tests of connection. Mode bit txMaster (9)

  • The SpiMaster access from the SpeA card should be enabled if necessary. Mode bit enSpiMaster (8)

  • The mode of transmission can be set, with or without gap. Mode bits 11,10: txNoTristateInGap and ringNoGapMin. The first one is active for a master telegram transmission (with mode bit 'txMaster'). It assures the after the telegram immediately (after a short break) the sync pattern is transmitted, the line does not go in high impedance state. This mode is possible for the ring communication, it saves time and allows more data words in the telegram (max. 41 for a 50 µs cycle or 29 in a 31 µs cycle).

    For a SPE-Ring-Slave set of ringNoGapMin is sufficient because then, the sync pattern from the station before forces immediately transmitting also the sync pattern. If the bit txNoTristateInGap is additionally set, this station transmits always without gap, also if a gap is received.

    The default mode (for SPE-Ring-Slave) is ringNoGapMin but not txNoTristateInGap. Hence the station follows the received telegram.

  • At last the bSet (15) should be set. This bit is cleared on hardware reset, so the hardware reset situation can be detected.

3.3. Behavior on transmission collision

The transmission level on the output pins is anytime read back and compared with the transmission level (with a small disable range on the edges). If the read back level is faulty, then an internal flipflop is cleared which forbids further output. It means this station switches off its transmission activity. If other stations do the same, then the line is fast in high impedance state after a collision.

The flipflop can be read out with the bit txCollision (14) in the mode config word. What to do depends from the software. In Ring topology this can occur if two stations transmit, using the opposite plug. Then one of the station, or both, are faulty configured.

In bus (multidrop) or star topology this can be occurred as normal situation if the participation on the bus is not clarified. Then usual the transmission should be repeated after a randomize time.

An adequate situation is given if the card is configured for transmission, or it is in state of configuration, but the transmission has not yet started. Then no collision occurs, receiving data, a carrier signal, comes. Then the same bit is set.

To detect such situations, the following flow is used:

  • On start of SPI access either for transmission or for receive preparation the bit activated (13) in the mode config word should be set. After detection this bit in the FPGA the collision detection for transmit and the carrier detection for receive is enabled.

  • If the mode for txMaster (9) is set, then a received carrier on the selected transmission channel (bit txSlot2, 12) is a collision though the transmission has not started yet, the bit txCollision is set and the transmission is not started.

  • But the received telegram is written via SPI in the RAM, so it can be evaluated.

TODO

3.4. Timing and Programming SPE Ring Master

Before this procedure starts, the SpeA card should program in its mode bits as:

enSpiMaster = 1;
txMaster = 1;
txNoTristateInGap = 1;  //recommended

The controller should organize a cyclically frame_in signal for the SpeA-card usual from a timer or a PWM (pulse width modulation) output, see Chapter Provide the frame_in signal to the SpeA-card, process the frame_out. Such modules are often existing on controllers. The frame_in should have a long high period, so long as the telegram runs, and a short low period. For example 45 µs high and 5 µs low.

The FPGA is the master for the SPI communication. In the low period of frame_in the controller should prepare the SPI interface as slave. Using DMA is strongly recommended, this DMA should be prepared with the expected number of words to read and write.

Immediately after the falling edge of the frame_in Pin the FPGA starts reading and writing 3 x 16 bit from the controller. This first three words are a command word, a config word and the first data word.

Then more data words (á 16 bit) are read in the timing of transmitting and receiving data bits from SPE just in time. See chapter ../SpeA-Manual/SpeA-ControllerSw.html#DataExchange. This forces a small gap between the first three words and the following. The SPICLK is determined by the internal clock of the FPGA.

The following fast image should show the timing of interrupt, SPE telegram and SPI access:

PWM:  ++|__________|++++++++++++++++++++++++++++++++++++++++++++++++ The PWM output for frame_in
Intr: --ccciiiiiiccccccWWWccccccccccccccccccccRRRccccccccccccccccc-- one cycle interrupt
SPI:  ________________ccff11 ddRRRdddWWWdddddrrrddddddddddddddddssss
SPE:  yyyyyyyyyyyyyyyyyyyyyy11ddRRRdddWWWddddddddddddddddddddddCRC_yy
  • |___| should present the hardware signal for frame_in, be carefully with the moment of edge.

  • The ccc should present any statements of the cyclically interrupt

  • iii are the initializing statements for SPI, programming FIFO and/or DMA.

  • WWW are data which are calculated on the fly for transmitting, possible

  • RRR are data which are used on the fly from the SPE communication

  • ccff11 are the first three words, command, config, first data word

  • ddd other data.

  • yyy Synchronization pattern of SPE

As you see in the simple schema, the interrupt starts with the falling (trailing) edge of frame_in. Firstly the SPI should be prepared, before the leading rising edge of frame_in comes.

After the leading frame_in first the command, config and the first data word are gotten from the controller via SPI. Then the SPE telegram starts with data, transmits first the first data word.

During transmission, the interrupt can prepare yet still data, which are transmit in the immediately following time. For that the calculation times in the interrupt should be well known. But often this is possible. This is the 'data on the fly' approach. The even yet processed data are a small time afterwards transmitted.

The adequate same is with receive data. Data which are already received and written in the controllers RAM, can be processed immediately after. If such received data comes on the start of the telegram, whereas the new data to transmit on end, there is enough time.

With this approach the dead time for a closed controlling loop can be reduced.

The opposite variant is: Using a alternate buffer for transmitting and receiving. Then the data in the second buffer can be full prepared or evaluated while the other buffer is currently used for SPI. This forces one step time more as dead time in a closed loop solution. But the preparation and communication is independent.

3.5. Timing and Programming SPE Ring Slave - interrupt for SPE—​Ring-Slave

If the SpeA-card works as SPE-slave in Ring Topology, then the first three words should be initialized as necessary. A receiving telegram can be expected due to the whole communication timing, but it is forced from the transmitting station before. A received telegram is immediately forwarded in the Ring as transmission.

If the interrupt in SPE-Ring-Slave controller is forced by the frame_in signal comming with the SFD, then the SPI communication should be already initialized. Also the first two words should be read from the controller RAM. It means, this should be done on the end of the interrupt before.

In the moment of starting the interrupt, the first data are written via SPI to the controller RAM already. This should be done usual with a DMA related to the SPI. It means, new data are written now.

If the interrupt has some preparations which needs a dedicated small time, and the information to use are on start of the telegram, the interrupt can access the just now written information immediately after writing in the same interrupt. If the relevant informations are a little bit later in the telegram, some other things may be done firstly. It is only a quest of 0.8 µs per byte.

It means there is no additional dead time in controlling loop. The new received information can be used in the same cycle.

But there is the following problem: The check via CRC is not done till now. It means either you wait till the end of telegram to get the result of CRC check, or you can calculate new values with the non checked information first, but discard this information on the end of the controller algorithm if the CRC is faulty. It depends on the controller algorithm. Usual it is not recommended to stop all functionality on one faulty telegram. It is better to replace information with estimate values, because the accident of an error is less. If one step produces non exact outputs, and the next step in a controller algorithm is exact again, it is only a small disturbance. On a fast cycle time this disturbance is not so problematically. The important one: You should not switch a state because one unexpected signal. If you switch a state, you should leave this state again if the next step is proper, as expected.

Look on the following schema:

 ssssSdddddddd.....dd_crc________________ssssSddd     The telegram
     !ppppppp_ccccccccc_pppp_ooooiiii        !pppppp  The interrupt

In telegram: * ssssS the synchroniation bits, and the Start Frame Delimiter * dddddd receive data and write to RAM immediately * crc Receive the CRC check sum after data

In interrupt: * ! start of interrupt * p do any other unrelated to telegram data (preparation, any what) * c calculation of the controller algorithm with the yet immediately received data * o Output results, after CRC check * i Intitialize SPI communication for the next cycle, write first two words.

As you see, the intitialization of the SPI should be done if the telegram has finished. But this means that the interrupt should be run longer than the telegram. This may be proper if the controller has its main task execute the interrupt, and the calculation time is ~70—​90 % of the cycle time.

3.6. Timing and Programming SPE One shot Master

This procedure is proper for either an answer in Bus- or Star communication after receive, or for test situations.

Usual, with SpiMaster mode of the SpeA-card, first the leading rising edge of frame_in is output. Because of the txMaster bit was set = 0 before, this does not start the active output yet. But the SpiMaster access starts and reads the following mode bits:

enSpiMaster = 1;
txMaster = 1;
txNoTristateInGap = 0;   // use the gap in bus mode
ringNoGapMin = 0;
activated = 1;
bSet = 1;

Because of now the txMaster is set, the transmission starts immediately with the programmed number of sync bytes. Following, the data are read and transmit. Because of the sync phase there is a little bit greater gap between the SPI accesses.

After transmission the activated is set to 0. The txMaster remains 1, but without new initialization nothing will be transmitted.

The next

3.7. Timing of SPI data transfer with frame_in - PLL interrupt synchronization for SPE—​Ring-Slave,

On the slave the timing should be similar. But not the step_in is the trigger, the data comes with receiving a telegram. Exactly therfore SPE-master and SPE-slave should be synchronized in the cycle time, see chapter Cycle Synchronization approach. Then the receive telegram does not come unexpecting, it comes in the expected time range.

Before the receiving is expected, also (as in SPE-master) the SPI interface of the controller should be initialized. All other is adequate.

3.8. Data on the fly

As shown in the graphic it is possible to write data for DMA transfer a little bit shortly before they are read from SPI to transmit. The same is with receiving: Using immediately after receive.

But this requires that the timing both from machine code execution in interrupt and the position of data in the SPE telegram are known, stable and tuned. For some simple controlling applications this can be done (need constant calculation time, less jitter). Hence the dead time in the controlling cycle can be reduced. But this is a possibility which can be used in response to the application. You should also regard, that FIFO data should be written (and hence known) before the telegram starts, only DMA data can use this possibility.

In all cases it is not possible to handle the SPI data in software. For that the data rate is too fast (10 Mbit/s, 1.6 µs for 16 bit).

For receiving it is similar. Using a FIFO the first data are written in the FIFO, but some times the FIFO size is too small, and the FIFO is entlees via DMA to the RAM. Then this just in time data can be used. For just in time performance either no FIFO capability should be used or with less size. The DMA should be prior and fast enough for 1.6 µs per access (16 bit SPI access, 10 Mbit/s).

3.9. Meaning of the data words, Headerfile

ccc

3.9.1. Overview all configuration words

//SpeA_Common/SpeA_FPGA.h:
Unresolved directive in SpeA-ControllerSw.adoc - include::../../../../src-Ctrl/main/cpp/SpeA_Common/SpeA_FPGA.h[tag=CfgData]

3.9.2. Cmd bits in configuration

//SpeA_Common/SpeA_FPGA.h:
Unresolved directive in SpeA-ControllerSw.adoc - include::../../../../src-Ctrl/main/cpp/SpeA_Common/SpeA_FPGA.h[tag=CmdBits]

3.9.3. Mode bits in configuration

//SpeA_Common/SpeA_FPGA.h:
Unresolved directive in SpeA-ControllerSw.adoc - include::../../../../src-Ctrl/main/cpp/SpeA_Common/SpeA_FPGA.h[tag=ModeBits]

The first data word (16 bit) is used as command as described in …​TODO. The second data word is the sender address. All other data words are user specific, payload in the telegram.

The user should have a data struct (C-language, also in C++), which contains the whole data for SPI beginning with the command and sender word as int16, following by the user data.

3.10. Received data, meaning

The received data are written via DMA to the RAM. The first two words contains the own command and sender, then received data with the sender address follows. Between both they may be fill words with content 0000 on the SPE-master if the response time in the ring is a little bit greater.

4. Provide the frame_in signal to the SpeA-card, process the frame_out

TODO

5. Endian approaches: Ethernet Big endian LSB first, SPI: word access, MSB first

But the output on SPE is defined adequate to the Ethernet standard with first output the LSB, but from the high byte of the 16 bit access (big endian approach).

The big endian approach should be correct understand: If a memory word (16 bit) is accessed, the processor reads the memory word correct. There is no endian approach for reading whole words from memory, endian approach is only existing for serializing of a word. It means the 16 bit access for a 16 bit word is always correct independent of endian thinking.

But for a 32 bit word, which is accessed by two 16 bit reading from SPI, first the bits 31..16 should be accessed from memory to transmit exactly first bit 24..31 and then bit 16..23 via Ethernet SPE. Following with access bits 15..0 via SPI to transmit bits 8..15 and then 0..7 via SPE. To do so, it is necessary to reverse the content in the memory. This is similar the known hton and ntoh operations "host to net" and "net to host".

But, for approaches of fast data transfer often only 16 bit are used. The order of word remains independent of big or little endian accesses. And, if both partner accepts a 32-bit or longer word without word swapping, it is also okay. The swapping is only necessary if the information are evaluated in an unknown or common way, then the big endian approach is valid and should be recommended. This is an effort in software, not in the PHY layer of this FPGA.

Examples to explain the big endian approach:

 //data example:
 int16 data = 0xabcd;
 int16 datb = 0x1234;
 int32 dat32 = 0xfe0a5678;

Memory content:

  cd ab 34 12 78 56 0a fe      content in memory as byte width for little endian approach
  abcd  1234  5678  fe0a       content in memory 16 bit width for little endian approach
  abcd  1234  fe0a  5678       changed content to transmit for big endian approach
  ab cd 12 34 12 fe 0a 56 78   Transmit order, transmits LSB of each byte first.

6. Example application for measurement data

TODO ==