SpeA card and controller Software

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:

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.

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

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.

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.

The data are immediately "on the fly" transmitted from the RAM to the SPE telegram output, and also immediately written to the RAM while receiving. This approach requires supporting a boud rate for SPI from the same as the telegram, it means 10 Mbit/s. The second one necessity is: The SPI and DMA should be prepared before a telegram comes in. It means the controller software (in interrupt) should be oriented to the telegram flow. But exactly this is desired for a strong cyclically communication.

Hint for a 100BASE-T solution: This requires either a SPI baudrate of also 100 Mbit/s which may be supported by fast controller solutions, or a parallel access to the RAM (160 ns/16 bit should be possible). For slower controllers as slave on the 100BASE-T ring only a few words should be received and transmitted temporary stored in the FPGA. The amount of forward transmitted data in the ring topology does not need a controller access.

The just in time approach enables communication and reaction in microsecond cycles with less additionl delay.

An example how does it work is explained as text in the following linked article (click the picture), needs 2 MByte to load. This article contains also a link to a video.

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.

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).

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 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:

TODO

See also SpeA-Manual#SpeRingFast

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

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:

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.

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:

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.

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:

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

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.

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).

ccc

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.