English
Using FPGAs to interface with digital communication protocols
By Vineet Aggarwal, National Instruments
June 06, 2007 -- pldesignline.com
Custom or proprietary digital protocols are commonly used in today's world for device or sub-system communication in everything from Aerospace to Consumer Electronics. Many of these applications also use popular standards like SPI, I2C, I2S and S/PDIF. FPGAs can be easily configured to interface with a wide variety of protocols, and – using high-level programming tools – engineers are able to design, prototype, and test faster than ever before.
Over time, digital protocol specifications can change and evolve, and ASIC-based interfaces face challenges with regard to maintenance and forward compatibility. FPGA chips, however, are reconfigurable to keep up with future modifications that might be necessary. This how-to article discusses the implementation a custom digital communication protocol using FPGAs.
When implementing a digital communication protocol with FPGAs, it's important to understand the bigger picture. A typical specifications document for a digital protocol will include everything from individual byte translation all the way to the type of connector to use. There are several layers of abstraction that eventually work their way down to the physical electrical characteristics associated with each I/O pin. For example, digital logic levels could be simple 5V or 3.3V TTL lines (transistor-transistor logic) with single-ended signaling that references a common ground. Ground referenced signals are used to reduce the number of required pins per data line; however, while this might reduce the cost of cabling or line drivers, they are more susceptible to noise and therefore can't be used for long distances. Digital standards like RS-485 use differential signaling between -7 and 12 volts, for communication up to 4000 feet. Depending on the protocol being used, it might be necessary to implement additional circuitry for signal conditioning, and to amplify or attenuate electrical signals when interfacing to an FPGA chip.
Once digital logic levels adhere to the protocol specifications, an FPGA application can be written to control I/O lines and group individual data bits into bytes. The transfer of digital data from one device to another could be synchronous (ie: referencing the same clock) or asynchronous (ie: using independent clocks or handshaking). Digital protocols commonly describe a group of bytes as a frame, and each frame of a communication sequence could contain bytes for error correction, device identification, or addressing information. Not every communication protocol has these complexities, but it's important to understand the various layers of abstraction and decide how much should be implemented on the FPGA and how much should be handled by some other system component like a microprocessor (of course the microprocessor could also be implemented on the FPGA). Since FPGAs operate at the physical hardware level, controlling individual digital I/O lines, this article will primarily focus on clocking data lines and interpreting byte commands.
June 06, 2007 -- pldesignline.com
Custom or proprietary digital protocols are commonly used in today's world for device or sub-system communication in everything from Aerospace to Consumer Electronics. Many of these applications also use popular standards like SPI, I2C, I2S and S/PDIF. FPGAs can be easily configured to interface with a wide variety of protocols, and – using high-level programming tools – engineers are able to design, prototype, and test faster than ever before.
Over time, digital protocol specifications can change and evolve, and ASIC-based interfaces face challenges with regard to maintenance and forward compatibility. FPGA chips, however, are reconfigurable to keep up with future modifications that might be necessary. This how-to article discusses the implementation a custom digital communication protocol using FPGAs.
When implementing a digital communication protocol with FPGAs, it's important to understand the bigger picture. A typical specifications document for a digital protocol will include everything from individual byte translation all the way to the type of connector to use. There are several layers of abstraction that eventually work their way down to the physical electrical characteristics associated with each I/O pin. For example, digital logic levels could be simple 5V or 3.3V TTL lines (transistor-transistor logic) with single-ended signaling that references a common ground. Ground referenced signals are used to reduce the number of required pins per data line; however, while this might reduce the cost of cabling or line drivers, they are more susceptible to noise and therefore can't be used for long distances. Digital standards like RS-485 use differential signaling between -7 and 12 volts, for communication up to 4000 feet. Depending on the protocol being used, it might be necessary to implement additional circuitry for signal conditioning, and to amplify or attenuate electrical signals when interfacing to an FPGA chip.
Once digital logic levels adhere to the protocol specifications, an FPGA application can be written to control I/O lines and group individual data bits into bytes. The transfer of digital data from one device to another could be synchronous (ie: referencing the same clock) or asynchronous (ie: using independent clocks or handshaking). Digital protocols commonly describe a group of bytes as a frame, and each frame of a communication sequence could contain bytes for error correction, device identification, or addressing information. Not every communication protocol has these complexities, but it's important to understand the various layers of abstraction and decide how much should be implemented on the FPGA and how much should be handled by some other system component like a microprocessor (of course the microprocessor could also be implemented on the FPGA). Since FPGAs operate at the physical hardware level, controlling individual digital I/O lines, this article will primarily focus on clocking data lines and interpreting byte commands.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
Related Articles
- Serial Peripheral Interface. SPI, these three letters denote everything you asked for
- Securing UART communication interface in embedded IoT devices
- How to power FPGAs with Digital Power Modules
- Method to minimize switching activity in digital data transfer protocols
- A novel approach to ensure complete coverage for validation of communication protocols by inducing jitter and glitches in clock and data
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)