This post discusses the design for a FPGA I2C Slave implementation in VHDL. The final source code for this design can be found in this post here. This I2C Slave implementation provides basic read, write, and addressing functionality. The address of the slave is configurable through a generic. The implementation supports repeated START conditions, but it does not support other "advanced" features such as clock stretching and 10-bit addressing.
The final implementation has been tested on an Altera Cyclone IV FPGA, using a Raspberry Pi 2 as the I2C master.
This post requires a basic knowledge of the I2C bus. I will not be teaching about or providing a tutorial for I2C here, as there are already many great resources on the internet for learning about it.
The ultimate authority for I2C will always be the specification and user manual. However, this document might be too detailed for those who are only looking for a basic overview. Personally, I recommend any of the following three resources for learning I2C.
Sparkfun I2C Tutorial.
ESAcademy I2C Bus Overview.
Columbia Lecture Presentation.
I2C Slave VHDL Interface
The VHDL implementation will provide the following interface for usage:
--Transaction is in progress
in_progress : out std_logic;
--READ command signals
tx_done : out std_logic;
tx_byte : in std_logic_vector(7 downto 0);
--WRITE command signals
rx_byte : out std_logic_vector(7 downto 0);
rx_data_rdy : out std_logic;
clk : in std_logic);
The naming of the signals here may be a little confusing. I2C transactions take place from the master's perspective. Therefore, a READ command means that the master is reading data from the slave (i.e the slave is sending data to the master). A WRITE command means that the master is writing data to the slave (i.e the slave is receiving data from the master). In the interface defined above, however, the naming is done from the perspective of the slave. By convention, TX refers to transmitting data and RX refers to receiving data. The signals that begin with
"tx_" are used when the slave is transmitting data to the master (during a READ command). The signals that begin with
"rx_" are used when the slave is receiving data from the master (during a WRITE command).
tx_done is an indicator signal that goes high when the I2C Slave module has finished transmitting data to the master. The data to be sent to the master must be set in
rx_data_rdy is an indicator signal that goes high when data is received from the master. The received data can be found in
clk is the clock signal for the I2C Slave module itself. This should not be confused with SCL, which is the I2C-bus clock line. This will be explained more in the next section. For best performance,
clk should be significantly faster than SCL.
in_progress is an output indicator signal I decided to add, as it may be useful in some applications. It goes high whenever there is activity on the bus that is addressed to the slave.
I2C Slave FSM Design
This I2C Slave implementation uses a fast clock to oversample the SDA and SCL signals. This is more reliable than using the SCL line itself as the FPGA's clock signal. There are four particular events that need to be captured. The first two are the rising and falling edges of the SCL clock. These edges trigger transitions between states in the FSM. The next two are the START and STOP conditions. These occur when the SCL line is high, so they must be captured separately. Four strobe signals are used to capture these events. These strobe signals go high to indicate that the event has occurred.
Using these four strobe signals, it is easy to implement a state machine for the I2C Slave. The FSM uses eight states. The states and their general functions are listed below.
IDLE - No bus activity that is addressed toward the slave. The slave is waiting for a START condition in this state.
READ_ADDRESS - Reads the 7 bit address and the R/W bit from the master. Also determines whether the address is a match
SEND_ACK - Sends an ACK bit by holding SDA low through one SCL cycle.
WRITE_CMD - Reads one byte of data from master by polling SDA line.
READ_CMD - Writes one byte of data to master by setting SDA line.
WAIT_ACK_1 - Waits for ACK bit from master. This requires two states.
WAIT_STOP - A NACK was received during a READ command. Therefore, the I2C shouldn't do anything and should just wait for a STOP bit.
Below is a diagram of the FSM. Note that this FSM diagram does not show all the transitions that occur because of START and STOP conditions. When a START condition is received, the FSM immediately transitions to the READ_ADDRESS state to begin a new transaction. This allows Repeated Start Conditions to work. When a STOP condition is received, the FSM immediately goes into the IDLE state. These transitions due to START and STOP conditions can occur at any point and in any state of the FSM. They are not shown in the FSM diagram because it would be too messy.
Note that the FSM diagram contains some internal strobes and logic signals for its transitions.
scl_rising are the two strobe signals for the rising and falling edges of the SCL line, as previously discussed.
rw is a signal that holds the value of the R/W bit. It is set during the READ_ADDRESS state.
bit_count is a counter. Every transaction involves a single byte that is clocked in or out one bit at a time. The counter keeps track of the number of bits received or sent and transitions between states after a full byte.
continue_read is a signal that goes high when the I2C slave should continue reading from the master during a WRITE command. This depends on whether a ACK or a NACK was received after reading a byte.
Finally, because the I2C bus lines are open-drain, a tri-state buffer must be used to manage when the I2C slave pulls the SDA line low. An enable signal,
sda_out_en is high when the slave has control of the SDA line.
sda_out_en is high only when the slave is sending data during the SEND_ACK and READ_CMD states. The tri-state buffer is simple to implement:
--SDA and SCL outputs
sda <= sda_o when sda_out_en = '1' else 'Z';
scl <= 'Z';
For the full source code, click here.