SPI means Serial Pheripheral Interface.
The Serial Peripheral Interface Bus or SPI bus is a synchronous serial data link de facto standard, named by Motorola, that operates in full duplex mode. Devices communicate in master/slave mode where the master device initiates the data frame. Multiple slave devices are allowed with individual slave select (chip select) lines. Sometimes SPI is called a four-wire serial bus, contrasting with three-, two-, and one-wire serial buses. SPI is often referred to as SSI (Synchronous Serial Interface).
Data transmission:
A typical hardware setup using two shift registers to form an inter-chip circular buffer
To begin a communication, the bus master first configures the clock, using a frequency less than or equal to the maximum frequency the slave device supports. Such frequencies are commonly in the range of 10 kHz–100 MHz.
The master then transmits the logic 0 for the desired chip over the chip select line. A logic 0 is transmitted because the chip select line is active low, meaning its off state is a logic 1; on is asserted with a logic 0. If a waiting period is required (such as for analog-to-digital conversion), then the master must wait for at least that period of time before starting to issue clock cycles.
During each SPI clock cycle, a full duplex data transmission occurs:
- the master sends a bit on the MOSI line; the slave reads it from that same line
- the slave sends a bit on the MISO line; the master reads it from that same line
Advantages:
- Full duplex communication
- Higher throughput than I²C or SMBus
- Complete protocol flexibility for the bits transferred
- Not limited to 8-bit words
- Arbitrary choice of message size, content, and purpose
- Extremely simple hardware interfacing
- Typically lower power requirements than I²C or SMBus due to less circuitry (including pull up resistors)
- No arbitration or associated failure modes
- Slaves use the master's clock, and don't need precision oscillators
- Slaves don't need a unique address — unlike I²C or GPIB or SCSI
- Transceivers are not needed
- Uses only four pins on IC packages, and wires in board layouts or connectors, much fewer than parallel interfaces
- At most one unique bus signal per device (chip select); all others are shared
- Signals are unidirectional allowing for easy Galvanic isolation
- Not limited to any maximum clock speed, enabling potentially high throughput
Disadvantages:
- Requires more pins on IC packages than I²C, even in the three-wire variant
- No in-band addressing; out-of-band chip select signals are required on shared buses
- No hardware flow control by the slave (but the master can delay the next clock edge to slow the transfer rate)
- No hardware slave acknowledgment (the master could be transmitting to nowhere and not knowing it)
- Supports only one master device
- No error-checking protocol is defined
- Generally prone to noise spikes causing faulty communication
- Without a formal standard, validating conformance is not possible
- Only handles short distances compared to RS-232, RS-485, or CAN-bus
- Many existing variations, making it difficult to find development tools like host adapters that support those variations
- SPI does not support hot plugging (dynamically adding nodes).
Applications:
The board real estate savings compared to a parallel I/O bus are significant, and have earned SPI a solid role in embedded systems. That is true for most system-on-a-chip processors, both with higher end 32-bit processors such as those using ARM, MIPS, or PowerPC and with other microcontrollers such as the AVR, PIC, and MSP430. These chips usually include SPI controllers capable of running in either master or slave mode. In-system programmable AVR controllers (including blank ones) can be programmed using an SPI interface.
Chip or FPGA based designs sometimes use SPI to communicate between internal components; on-chip real estate can be as costly as its on-board cousin.
The full-duplex capability makes SPI very simple and efficient for single master/single slave applications. Some devices use the full-duplex mode to implement an efficient, swift data stream for applications such as digital audio, digital signal processing, or telecommunications channels, but most off-the-shelf chips stick to half-duplex request/response protocols.
SPI is used to talk to a variety of peripherals, such as
- Sensors: temperature, pressure, ADC, touchscreens, video game controllers
- Control devices: audio codecs, digital potentiometers, DAC
- Camera lenses: Canon EF lens mount
- Communications: Ethernet, USB, USART, CAN, IEEE 802.15.4, IEEE 802.11, handheld video games
- Memory: flash and EEPROM
- Real-time clocks
- LCD, sometimes even for managing image data
- Any MMC or SD card (including SDIO variant)
Modes of Operation:
MODE
|
SETUP
|
SAMPLE
|
0
|
falling
|
rising
|
1
|
rising
|
falling
|
2
|
rising
|
falling
|
3
|
falling
|
rising
|
In the SPI communication, there can be 2 or more devices and 4 modes of operation depending of the clock phase & polarity. Only one master device & a number of slave exits on the bus which are controlled by Master. So simply there are two devices namely MASTER DEVICE and SLAVE DEVICE.
The Master module in mode 3 is designed using Verilog as a FSM (finite state machine), with 3 states namely IDLE, SEND & FINISH. And the Slave module is simple like shift register. These are designed and tested in Xilinx & ModelSim.
SPI MODE 3:
CHANGE DATA @ NEGEDGE
read data @posedge
The SPI Mode 3 waveform is
Let us see the MASTER MODULE here. (Slave module & joining Master-Slave in upcoming postings)
In IDLE state, it waits till the data is available and then proceeds to LOAD state where the direction, data are stored into transmit register. In SEND state, the data is shifted out & parallely sampled from DIN and after completing it goes to FINISH state putting received data into receive buffer & sets Done flag.
The block diagram of MASTER MODULE is as follows,
RSTB-active low asyn reset, CLK-clock, T_RB=0-rx 1-TX, mlb=0-LSB 1st 1-msb 1st
START=1- starts data transmission cdiv 0=clk/4 1=/8 2=/16 3=/32
The SPI MASTER module code is as follows:
STATE MACHINE:
//state transistion
always@(negedge clk or negedge rstb) begin
if(rstb==0)
cur<=finish;
else
cur<=nxt;
end
//FSM I/O
always @(start or cur or nbit) begin
nxt=cur;
clr=0;
shift=0;//ss=0;
case(cur)
idle:begin
if(start==1)
begin
case (cdiv)
2’b00: mid=2;
2’b01: mid=4;
2’b10: mid=8;
2’b11: mid=16;
endcase
shift=1;
done=1’b0;
nxt=send;
end
end //idle
send:begin
ss=0;
if(nbit!=8)
begin shift=1; end
else begin
rdata=rreg;done=1’b1;
nxt=finish;
end
end//send
finish:begin
shift=0;
ss=1;
clr=1;
nxt=idle;
end
default: nxt=finish;
endcase
end//always
CLOCK GENERATOR BLOCK:
always@(negedge clk or posedge clr) begin
if(clr==1)
begin cnt=0; sck=1; end
else begin
if(shift==1) begin
cnt=cnt+1;
if(cnt==mid) begin
sck=~sck;
cnt=0;
end //mid
end //shift
end //rst
end
Tx BLOCK:
always@(negedge sck or posedge clr) begin
if(clr==1) begin
treg=8’hFF; dout=1;
end
else begin
if(nbit==0) begin //load data into TREG
treg=tdat; dout=mlb?treg[7]:treg[0];
end //nbit_if
else begin
if(mlb==0) //LSB first, shift right
begin treg={1’b1,treg[7:1]}; dout=treg[0]; end
else//MSB first shift LEFT
begin treg={treg[6:0],1’b1}; dout=treg[7]; end
end
end //rst
end
Rx BLOCK:
always@(posedge sck or posedge clr ) begin // or negedge rstb
if(clr==1) begin
nbit=0; rreg=8’hFF; end
else begin
if(mlb==0) //LSB first, din@msb -> right shift
begin rreg={din,rreg[7:1]}; end
else //MSB first, din@lsb -> left shift
begin rreg={rreg[6:0],din}; end
nbit=nbit+1;
end //rst
end
SIMULATION OUPTUT OF MASTER:
If you enjoyed this post plz let us know your views via comments.
This helps us to do much more better.
Thankyou.
This helps us to do much more better.
Thankyou.
How you have used blocking statements inside always @ (negedge) block. This code will never get synthesized.
ReplyDeleteyes ujjwal kant is right
DeleteHI Dudes :
ReplyDeletePlease Register the Forum to download and discussion about the Project .
http://www.edtro.com/index.php?board=6.0
How to downloadload the code and is it for single slave or can we extend it
Deletewhere is the testbench
ReplyDeletegood article
ReplyDeletecan we have Testbench for the same
ReplyDelete