Developing Digital Communication Interfaces with LabVIEW FPGA (Part 2)

For engineers developing test applications with integrated non-standard or custom digital communication interfaces, the LabVIEW FPGA module is a graphical development environment for easily implementing or prototyping your communication protocols on the 7831R reconfigurable I/O hardware. Unlike designing and building your own hardware such as an ASIC or writing your own VHDL code to run on an FPGA, with the LabVIEW FPGA module you develop, test and debug new functionality quickly without the need for specialized development tools. Part 2 of this document focuses on bi-phase encoded protocols, and the use of time measurements to decode protocols. It also addresses data packet construction and parsing.

Digital Communication Protocols and FPGAs

There is a wide range of communication protocols in use in test systems ranging from common interfaces such as RS-232 and GPIB to custom protocols implemented by individual vendors and application developers. While using an off-the-shelf product to meet your communication needs is usually the best solution, many communication protocols may not be supported by a ready-made implementation on all test platforms. In this case developing your own custom hardware may be required. As an alternative using FPGA-based reconfigurable hardware can provide you the same benefits as custom hardware at a fraction of the cost.

In part 2 of this document we will look at more advanced communication protocols using bi-phase encoding and how to apply the appropriate LabVIEW FPGA techniques in their implementation. Part 1 focused on the basics of digital communication protocols and how to use LabVIEW FPGA to implement NRZ-encoded protocols such as SPI and I²C.

Bi-phase Encoding

Bi-phase encoding is a common modulation scheme used in a wide range of digital communication protocols across a range of different industries. Protocols using bi-phase encoding often tend to be mission critical embedded applications requiring a high degree of reliability. A few examples of bi-phase encoded signals include ARINC-429 and MIL-STD-1553 used for communication among devices and system on commercial and military aircraft respectively. More down to earth applications of bi-phase encoding include S/PDIF used for the digital audio signals coming from CD and DVD players as well as classical 10BaseT Ethernet communication. 

In bi-phase encoding the data signal and clock signal are combined into one signal, containing both clock and data information. This allows the use of only one signal line, reducing cabling needs and costs. As with NRZ, there are a number of different bi-phase encoding schemes as shown in figure 1.

Due to the encoding of the clock signal with the data signal, there is always at least one transition in the signal in every clock cycle. In addition the data information is encoded in the transitions of the signal, rather than the level of the signal. Because signal edges are easier to detect by a receiver and much less prone to noise degradation, bi-phase encoded signals can be transferred over longer distances than NRZ encoded signals using the same cabling and drivers.

Figure 1: Bi-phase Encoding Schemes

The most common bi-phase encoding scheme is Biphase-L (Level). In Biphase-L encoding a '0' bit is represented by a rising transition in the middle of the clock cycle, while a '1' bit is represented by a falling transition. Transitions are added on the edges of the clock cycle as necessary. Biphase-L is the basis of the common Manchester encoding scheme. There are however some implementations of Manchester encoding that invert the signal levels so that a rising transition represents a '1' bit and a falling transition represents '0'. IEEE 802.3 which defines the Ethernet 10BaseT communication defines Manchester in this manner. Before implementing an encoding scheme in your application make sure that you clearly understand the encoding of the bit data to signal levels.

In Biphase-M (Mark) and Biphase-S (Space), there are always transitions on the edges of each clock cycle. Biphase-M adds a transition in the middle of a '1' bit clock cycle, while Biphase-S adds the transition in the middle of a '0' bit clock cycle.

Regardless of which of these encoding schemes is used, there is at least one transition per clock cycle and the signal line never maintains the same level for more than one clock cycle. This allows a receiver to recover the clock frequency of the sender and decode the signal synchronously.

Data Packets

Bi-phase and NRZ encoding describe how individual data bits are encoded onto a signal line, but they do not define how data is packaged. To transfer data and information we need to assign meaning to the bits and define how they fit together. The simplest form of packing data is to collect bits into bytes and transfer raw bytes using the selected encoding scheme. For example, basic RS-232 communication (8 data bit, 1 start bit, 1 stop bit, no parity) transfers one byte of data at a time across the line. Each byte is identified by the start and stop bits. To transfer a string or multiple bytes of data, one byte is sent at a time, collected by the receiver and joined together to form the complete message or data item. In a similar manner SPI and I²C transfer one or more bytes of data between sender and receiver. The meaning of the data bytes is not defined by these protocol, but is determined by the device(s) used and the developer or designer of the system.

Higher level protocols typically include more definition pertaining to the meaning of the data in each data packet based on the purpose and needs of the applications for which the protocol is intended. For example, S/PDIF (Sony/Philips Digital Interface Format) is used to transfer digital audio data between audio components such as a DVD player and amplifier. Therefore the designer of the protocol could define a very specific structure and contents for the data packet which meets the needs of the devices. As we can see in the following figure the main portion of the S/PDIF data packet is occupied by the audio data sample, while some additional information and status bits can also be included. Every packet transferred using S/PDIF has the same format and every device receiving this data knows how to parse and extract the required information.

Figure 2: S/PDIF subframe (data packet) structure

When developing a digital communication protocol on the FPGA you define the level of meaning assigned to the data within the data packet, whether it represents raw data or already has some meaning associated with it.

Header

In order to properly read and decode a digital data stream the receiver must be able to synchronize itself with the data packet structure established by the sender. This requires that the receiver can identify the beginning or start of each data packet. For non-continuous protocols like RS-232 this process is normally very simple as the data signal will be idle and the receiver can wait for the first change in the signal line. 

Some protocols will define a specific state, high or low, for the data line while the bus is in the idle state, so that a receiver knows the exact condition (either rising edge or falling edge) of the start of a data packet. Some other protocols do not define the idle state of the bus and a receiver must be ready to identify the start condition (rising or falling edge) using a more advanced algorithm.

Some bi-phase encoded digital protocols send data continuously when the sending device is enabled. One such example is S/PDIF which has a continuous data stream from the audio source to its receivers. When the audio source is not playing anything it simply streams zero values for the audio signal level. In order for a receiving device to synchronize itself with such a data source and be able to identify the start of a data packet, the protocol needs to include special markers in the data stream. This type of marker is called a header. 

There are several different ways to define data headers that allow a receiver to reliably identify the start of a data packet. In the case of S/PDIF which uses the Biphase-M encoding scheme, the header contains an extra long data pulse which can not occur as part of the normal bi-phase encoded data stream. Looking at the Biphase-M example above we see that all pulses are either a half bit or full bit in length. Incidentally this is true for all bi-phase encoded data. The following diagram shows the three different header blocks used in S/PDIF. The first pulse of the S/PDIF header block is three half bits in length and can therefore be uniquely identified by the receiver, which then starts the decoding of the rest of the header and data packet. In addition, each header block contains four pulses which further helps the receiver decode the header. Because there is no idle state in S/PDIF (the data stream is continuous) and the encoding scheme allows the data packet to end on either a high or low state, the header can also start on either a high or low state. In other words, the first long pulse in the header is not always high as shown in the following diagram and the receiver must look for a either a high or low long pulse to detect the start of a data packet.

 

Figure 3: S/PDIF Header blocks

When designing and implementing your digital communication protocol on the FPGA it is important to consider the need for synchronization between sender and receiver and add the necessary code on both ends of the communication path.

Implementation in LabVIEW FPGA

FPGAs and the LabVIEW FPGA development tools are well suited to implementing digital communication protocols as it provides low level access and timing control over the digital I/O lines. Using the I/O node in LabVIEW FPGA you can enable and control the state or read the value of the digital I/O lines at the rate of the FPGA clock frequency, 40 MHz by default. In addition you can process digital data at the same rate and can respond to data communication with the proper response if necessary in real time.

The simplest from or lowest level if implementing digital communication is some time referred to as 'bit banging' as we turn a digital line on and off in accordance with the definition of the communication protocol. The following example provide several references for implementing bi-phase encoded protocols in LabVIEW FPGA. These are meant to be used as references and as a starting point for implementing your own digital communication protocol and will most likely not solve the needs of your application without some modifications.

All of these examples can be downloaded from this Example Document on Developer Zone.

Simple Biphase Encoding

The Simple Biphase Generator shows how easy it is to take a few data bytes and encode them using a number of different LRZ and biphase encoding schemes.

[+] Enlarge Image

Figure 4: Simple Biphase Generator Diagram

This example takes a number of bytes from the front panel array and sends them out on a digital I/O line using one of the provided encoding schemes. Each encoding scheme is implemented in its own case of the Case structure. The current state of the signal line is maintained in a shift register as it is needed for some of the encoding schemes. Timing of the data bits is controlled by the Loop Timer and specified on the front panel in terms of FPGA clock cycles (ticks).

This example is purposely kept simple and does not use some of the advanced LVFPGA features such as the Single Cycle Timing Loop (SCTL) in order to show all operations necessary for signal generation in one view. Based on the timing limitations of the For loop this example can generate a data signal at a maximum bit rate of 10 ticks or 4 MHz. To generate faster digital protocols you must use the SCTL which is shown in the following examples.

Manchester Encoding

The Manchester Encoding example is separated into two main components. On the main VI diagram the Data Generation loop is used to fill a FIFO (Manch TX Data) with PRBS (Pseudo Random Bit Sequence) data to be generated in the Manchester Encoding subVI. A separate FIFO (Start) is used to send a Start command from the main VI to the encoding subVI.

Figure 5: FPGA Manchester Encoding Main VI Diagram

Manchester Encoding Process SubVI

For the purpose of this example we have defined a customer header which is added before the sequence of data bits. This header can be used by the receiver to synchronize to the data stream and to easily determine the bit rate used by the sender. The idle state of the signal is High and the packet header is a three half-bit low pulse (Start) followed by a one half-bit high pulse (Ready). Immediately following the Ready bit the data bit sequence starts.

Figure 6: Manchester encoding with custom header used in the example

The Manchester Encoding process is implemented using a state machine in a Single Cycle Timed Loop (SCTL). This design, while more complex in implementation, allows for higher performance and faster updates of the digital outputs. Using this technique digital outputs that support this operation can be updated in every cycle of the SCTL and the maximum bit rate is half of the SCTL rate , e.g. a SCTL running at 40 MHz can generate a Manchester signal at a 20 Mb/s rate.

The Encoder State Machine contains the following states:

• Idle - wait for Send Data command from main VI
• Start Condition - set Start condition on the signal output
• Ready Bit - Set Ready condition on the signal output
• Data Halfbit Update - read data from FIFO, determine new states for the output signal and update output
• Delay - extra state inserted between updates to the output signal to control the encoder bit rate

Following is the state diagram of the Manchester Encoder state machine.

Figure 7: State diagram for the Manchester Encoder

Idle State

The Idle state waits for the Send Data command from the main VI. The Send Data command is sent as a True Boolean value in the Start FIFO. When the Send Data command is received the state machine proceeds to the Start Condition state. See the Data Halfbit Update state below for a diagram of the complete loop structure around the Case structure including the DIO node.

[+] Enlarge Image

Figure 8: Idle state of the Manchester Encoding state machine

Start Condition State

The Start (Condition) state sets the output signal low for the Start condition. It also calculates the length of the Start condition in terms of FPGA SCTL clock cycles based on the Half Bit Rate specified. The length of the Start condition is three half bits. The next state is the Delay state which controls the length of the Start condition specified by the delay time.

[+] Enlarge Image

Figure 9: Start Condition state

Delay State

The Delay state inserts "empty" cycles into the SCTL in order to control the actual length of pulses generated by the Manchester encoder. The Delay state follows the Start, Ready, and Data states in order to set the length of those pulses. The Delay state decrements the delay counter and proceeds to the next state when the counter reaches 0.

[+] Enlarge Image

Figure 10: Delay state of the Manchester encoder

Ready Bit State

The Ready (Bit) state sets the Ready bit (Signal High) which is part of the custom header defined for this example. If the Halfbit rate is greater than 1 cycle the next state is the Delay state, otherwise the state machine proceeds directly to the Data state.

[+] Enlarge Image

Figure 11: Ready Bit state of the Manchester encoder

Data Halfbit Update State

The Data (Halfbit Update) state is the most complex state of the Manchester encoder and is responsible for moving the data from the FIFO and passing it to the digital output signal. The diagram below shows the Data Halfbit Update state as well as the surrounding single cycle timed loop.

[+] Enlarge Image

Figure 12: Data Halfbit Update state of the Manchester encoder

Data is passed from the main VI to this state using U32 integers in the Manch Tx Data FIFO. Due to the bi-phase encoding method which transmits each bit as two separate half bits, it takes 64 half-bit updates to output a single U32 integer value. The Half Bit Counter shift register keeps track of these 64 cycles for each U32 value before the state reads the next value from the FIFO in the Case structure on the left side of this state. The current value read from the FIFO and being generated is stored in the Data Value shift register.

The central portion of this state calculate the current value of the clock and the current bit value.

• • The clock value is toggled for each halfbit and is determined by masking the lowest bit (AND '1') of the halfbit counter. If the lowest bit is low (EQUAL 0) then then the clock value is high. 
  • The current bit of the data value is extracted by converting the data value to a Boolean array and indexing the array based on the value of the Halfbit counter. The Halfbit counter is shifted by -1 bit to remove the lowest buit which is used for the current clock value. This means each data bit is read in two consecutive calls to this state, once for each value of the clock.

The current bit value and the clock value are passed to the Manchester Encoder subVI which returns the actual value of the Manchester encoded signal. This value as well as the clock value are passed to the digital I/O node of the FPGA.

The top portion of this state determines the next state. The Delay state is called if the Halfbit rate is greater than one. The state machine returns to the Idle state if there is no more data in the Manch Tx Data FIFO.

S/PDIF Input

The S/PDIF Input example described in this section shows one method for decoding a biphase encoded data stream. The article earlier describes the structure of the S/PDIF protocol which is helpful information for understanding the decoding algorithm. As a summary S/PDIF is a continuous signal stream with 28 data bits per packet encoded using Bi-Phase M. The beginning of each data packet is identified by a header which is comprised of four variable length pulses, corresponding to 4 clock cycles (bits) in the remaining data stream. Therefore each packet is comprised of 32 clock cycles of the continuous signal stream. There are three different headers, described earlier, which identify the contents of the data packet.

[+] Enlarge Image

Figure 13: LabVIEW FPGA diagram of the SPDIF Input example

The SPDIF decoder algorithm is designed by stepping through the data packets and uses the following pseudocode. The complete code is implemented in a FPGA Single Cycle Timed Loop running at 40 MHz. The main code in the loop acquires the current state of the digital signal, detecting any change in state (pulses) and then processes the pulses according to the S/PDIF definition.

Pulse Detection 

The VI acquires the state of the S/PDIF input signal and comparing the current state to the previous state is looking for any changes in signal. A change in signal indicates the end of one pulse and the beginning of the next pulse.

Pulse Length

When the end of one pulse is detected the pulse length is calculated by subtracting the time of the last signal change from the current time. 

In the S/PDIF signal there will be short (1/2 bit), medium (1 bit) and long pulses (3/2 bit). Short and medium pulses represent the data in the bi-phase M encoded signal and are also present in the header. Long pulses are only used in the header to clearly identify the beginning of each data packet( subframe). For a 48 kHz S/PDIF signal these pulses will be 163 ns, 326 ns and 488 ns in length, corresponding to ~6 ticks, 13 ticks and 19 ticks of the 40 MHz FPGA base clock.

Identify the beginning of a subframe

In order to detect the start of the next subframe (data packet) the VI is looking for a long pulse. These pulses will be longer then 16 ticks in length. Because some headers will include a second long pulse, the VI also checks that the bit counter is greater than 5 which indicates that a long pulse is the first in the header. The bit counter is reset at the beginning of each subframe and incremented by one for each pulse in the header or each data bit in the subframe. At the beginning of each subframe the data value array is also reset. This Boolean array stores the bit values of the current subframe as they are acquired. The data value array stores the length of the header pulses in the first four bits of the array to allow for proper decoding of the data based on the subframe type (header value) later on.

[+] Enlarge Image

Figure 14: FPGA diagram processing the start of the subframe header

If the current pulse is not the first pulse of a subframe then it will be processed according to the following algorithm.

Processing the rest of the header

The VI determines if the current pulse belongs to the rest of the header by checking the bit counter. Bits 1, 2, and 3 belong to the header and are processed accordingly. For the header the bit counter is a pulse counter; each header is comprised of four pulses and occupies four bits of time in the signal stream. For each pulse in the header the length of the pulse is stored in the data value array, a long pulse is stored as '1' and a medium or short pulse is stored as '0'. 

Based on this assignment, the following headers will be stored in the data value array.

Left Channel: 1 1 0 0
Left Channel/Block Start: 1 0 0 1
Right Channel: 1 0 0 0

[+] Enlarge Image

Figure 15: FPGA diagram processing the remainder of the subframe header

Processing the data bits in a subframe

Beyond the first four pulses in the subframe the remaining pulses are processed as data bits. Each medium pulse (one bit, pulse length >10 ticks) represents a ‘0’ bit, while two short pulses (half bit) represent a ‘1’ bit. 

For each medium pulse a '0' is written to the data value array and the bit counter is incremented.

[+] Enlarge Image

Figure 16: FPGA diagram processing a medium data pulse

Each set of short pulses is processed by setting a flag on the first short pulse and updating the data value array and bit counter on the second short pulse. The flag is reset on the second short pulse.

[+] Enlarge Image

Figure 17: Figure 16: FPGA diagram processing a short data pulse and processing the end of a subframe

Process end of subframe

The end of a data packet (subframe) is detected using the bit counter. Each subframe contains four header pulses and 28 data bits which will increment the bit counter to 32. When the bit counter reaches 32, the data value array is processed.

The Boolean array is converted to a U32 integer containing the raw data packet value including the header value. The raw data is passed to the host application using a DMA FIFO. 

In addition the audio data is extracted from the raw data and passed to the front panel of the FPGA VI. Typically the audio sample is stored as a 20-bit integer value in bits 8 -27 of the subframe (see figure 2). To extract only the top 16-bits of the audio data, the raw data is shift 12 bits to the left and the resulting value is masked and converted to a I16 integer. This audio sample can either be the left or right channel. In order to determine which channel the current subframe represents, the header must be decoded as well. The lowest four bits of the data value array are extracted and converted to an integer value. 

The decimal value of the right channel header is 1 while the decimal value of the left channel header is either 3 or 9, if it is the first subframe of a new block (Block Start).

S/PDIF Input Host VI

The host example VI uses a number of simple API subVIs that have been defined to interact with the FPGA VI. The raw data is read from the DMA FIFO and then processed in the host before being presented on the VI front panel.

Three sets of information are extracted from each raw data value. The audio data sample is extracted using a bit shift and mask function. The header is extracted by masking the lowest four bits of the raw data sample. The four status bits in each subframe are extracted by shifting and masking the top four bits in the raw data value.

[+] Enlarge Image

Figure 18: S/PDIF Input example host VI diagram

Note: Extracting and viewing the audio data in this example only works with S/PDIF data streams that contain raw uncompressed audio data, which is typically for stereo (2 channel) audio streams. The S/PDIF transport format can also contain compressed audio data (for example DTS) which will pack additional channels into the data bits of each subframe. This example can not uncompress and display such audio data.

Reader Comments | Submit a comment »