Pretty much every FPGA design has to interface to the real world through sensors or external interfaces. Some systems require large volumes of data to be moved around very quickly, in which case high-speed communications interfaces like PCI-X, Ethernet, USB, Fire/SpaceWire, and CAN, or those featuring multi-gigabit transceivers may be employed. However, these interfaces have a considerable overhead in terms of system design and complexity, and they would be overkill for many applications.
Systems with simple control and monitor interfaces -- systems that do not have large volumes of data to transfer -- can employ one or more of the simpler communications protocols. The four simplest, and therefore most commonly used, protocols are as follows.
UART (Universal Asynchronous Receiver Transmitter): This comprises a number of standards defined by the Electronic Industry Association (EIA), the most popular being the RS-232, RS-422, and RS-485 interfaces. These standards are often used for inter-module communication (that is, the transfer of data and supervisory control between different modules forming the system) as opposed to between the FPGA and peripherals on the same board, although I am sure there are plenty of applications that do this also. These standards defined are a mixture of point-to-point and multi-drop buses.
SPI (Serial Peripheral Interface): This is a full-duplex, serial, four-wire interface that was originally developed by Motorola, but which has developed into a de facto standard. This standard is commonly used for intra-module communication (that is, transferring data between peripherals and the FPGA within the same system module). Often used for memory devices, analog-to-digital converters (ADCs), CODECs, and MultiMediaCard (MMC) and Secure Digital (SD) memory cards, the system architecture of this interface consists of a single master device and multiple slave devices.
I2C (Inter-Integrated Circuit): This is a multi-master, two-wire serial bus that was developed by Phillips in the early 1980s with a similar purpose as SPI. Due to the two-wire nature of this interface, communications are only possible in half-duplex mode.
Parallel: Perhaps the simplest method of transferring data between an FPGA and an on-board peripheral, this supports half-duplex communications between the master and the slave. Depending upon the width of data to be transferred, coupled with the addressable range, a parallel interface may be small and simple or large and complex.
Over the next few weeks, I will be exploring each of these protocols in depth, explaining their histories, pros and cons, and typical uses. Also, I will be discussing how to implement these protocols inside an FPGA (there may even be some code floating about as well).
But before we examine these protocols in depth, it's well worth our while to spend a little time recapping some of the terminology we use when describing protocols and their behavior, as follows.
Point-to-point: The simplest of communication protocols that involves just two devices exchanging data (a common example is RS-232).
Multi-drop: A more complicated structure that consists of a single master and a number of slaves, thereby facilitating more complicated data transfers and control architectures. Some protocols, such as I2C, can have multiple masters.
Simplex: This refers to data communication that is unidirectional. A typical implementation of a simplex data link could be a sensor broadcasting data to an FPGA or a microcontroller.
Duplex: This term is used when discussing point-to-point links. The ability of a protocol to support communication in one direction at a time is referred to as "half duplex." If the protocol can support communication in both directions simultaneously it is referred to as "full duplex."
As we discuss the different protocols in future columns, we will also be referring to the Open Systems Interconnection (OSI) seven-layer model. This is an abstract model used to describe how protocols function.
Layer One: Physical Layer. Describes the physical interconnection.
Layer Two: Data Link Layer. Describes the means for actually transferring data over the physical layer (Physical Addressing).
Layer Three: Network Layer. Describes the means to transfer data between different networks (Logical Addressing).
Layer Four: Transport Layer. Provides transfer of data between end users.
Layer Five: Session Layer. Controls the connections between end users.
Layer Six: Presentation Layer. Transforms data presentation between higher-level and low-level layers.
Layer Seven: Application Layer. Interfaces to the final application where the data transferred to is used or data is gathered for transfer.
It is worth noting at this point that not all layers of the OSI model are required to be present within a particular protocol. We will see examples where only a subset of the layers is employed.
As an aside, while I was writing this, I thought about some of the more obscure EIA protocols out there, such as RS-423, RS-449, and EIA-530. Have any of our All Programmable Planet members used any of these protocols or seen them used?
Yes the output would be through VGA only in bit file format and the data rate of the camera is 30fps with resolution of 640*480. I am thinking of proceeding like this. The camera module through SPI will store a 16bit word(2 pixels) in the FPGA and from here the data will be sent to the DDRAM. Now the VGA can access the data or the pixels drom the DDRAM trrough the FPGA. I hope I am in the right direction.
Adam Taylor 2/24/2013 12:06:02 PM User Rank Blogger
Re: I2C or SPI
You will need to use the FX2 connector to connect to your camera and create the I2C or SPI interface in the FPGA connected to these pins.
You will also need to consider data rates of the camera output, how long it will take to store it in the DDR and how you will want to output it I presume via the VGA output.
What is the resolution of the camera and the format of the output?
I am interfacing a camera module on my Spartan 3AN board. I need to store the images or pixel frames to the DDR2 SDRAM memory. Can I interface the camera with the board using SPI or I2C is the only option. In this particular spartan kit I2C is user for voltage regulation so how can I use it as an interface? Please guide
@Duane: instead of "reinventing the wheel" to explain it, I searched online for some AppNotes that I have referenced in the past. I am including a Maxim AppNote link and the pertinent text. It seems to be the most concise. (We don't want these comments to become a blog :-)
Please note that not ALL SPI devices (slaves) include daisy-chain capability - so, you will need to check the datasheets.
Maxim reference, Daisy-Chaining SPI Devices, then scroll down to "How Daisy-Chaining Is Accomplished" to see the reference figures, etc. Here's the relevant information:
In a daisy-chained system, SLAVE 1 receives data directly from the microcontroller. This data is clocked into SLAVE 1's internal shift register. As long as active-low CS remains low, this data propagates through to SLAVE 1's DOUT output. DOUT of SLAVE 1 goes into DIN of SLAVE 2, so the data is clocked into SLAVE 2's internal shift register as the data appears on SLAVE 1's DOUT output. Just as SLAVE 2 receives its data from SLAVE 1, the microcontroller can simultaneously send another command to SLAVE 1. This new command overwrites the previous data in SLAVE 1's shift register. As long as active-low CS remains low, the data propagates through the entire daisy-chain until each of the slave devices has received its appropriate command. The command loaded into each slave's shift register executes on the rising edge of active-low CS.
Here we discover how to use the XADC (Xilinx Analog-to-Digital Convertor) in the Zynq All Programmable SoC to read the chip's internal temperature and voltage parameters and output them over an RS-232 link.
The Zynq All Programmable SoC comes equipped with programmable analog capabilities that can be used in a wide variety of applications, including defense, industrial, and automotive systems.
In the case of a real-world use model, we want to store our software program and configuration bitstream in nonvolatile memory and configure the device after the power comes on.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
