SPI bus Protocol in VHDL

[VishwanathAmbli]

I am implementing SPI bus protocol in vhdl, the data should be transmitted during +ve rising edge of clock
i have written this code but i am unable to get the desired result, am i implementing the right way or no???? any help is appreciated:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity spi1 is
port(sclk:in std_logic; ssbar : in std_logic;
     mbuff,sbuff: in std_logic_vector(7 downto 0);
     mosi,miso: inout std_logic_vector(7 downto 0));
	  --sdo,sdi:out std_logic_vector(7 downto 0));
end spi1;

architecture Behavioral of spi1 is
signal i: integer range 0 to 255;
--signal temp1,temp2: std_logic_vector(7 downto 0):="00000000";
begin
mosi<=mbuff;
miso<=sbuff;
process(sclk)
begin
  --temp1<= mosi && miso;
  --i<=0;
  if(ssbar='1') then
     mosi<="ZZZZZZZZ";
	  miso<="ZZZZZZZZ";
  end if;	
  --if(sclk'event and sclk ='1') then
  --end if;
  if(sclk'event and sclk='1') then		
   --for i in 0 to 15 loop
	  mosi(1)<=mosi(0);
	  mosi(2)<=mosi(1);
	  mosi(3)<=mosi(2);
	  mosi(4)<=mosi(3);
	  mosi(5)<=mosi(4);
	  mosi(6)<=mosi(5);
	  mosi(7)<=mosi(6);
	  miso(0)<=mosi(7);
	  miso(1)<=miso(0);
	  miso(2)<=miso(1);
	  miso(3)<=miso(2);
	  miso(4)<=miso(3);
	  miso(5)<=miso(4);
	  miso(6)<=miso(5);
	  miso(7)<=miso(6);
	  --mosi(0)<=miso(7);
	  
	  --temp2(0)<=temp1(7);
	  --temp1(i+1)<=temp1(i);
	  --temp2(i+1)<=temp2(i);
     --i<=i+1;
     --if(i=7) then
       --i<=0;
     --end loop;		 
  end if;	
  

--sdo<=;
end process;  
        	
end Behavioral;

 

[FvM]

ssbar (nSS) suggests a SPI slave. You would have a the SCLK and nSS input, single MOSI input line and a MISO output, possibly tristatable for the bus interface. And a number of data in- or outputs, depending on the intended device function.

A shift register would be implemented as signal inside your design. I'm unable to relate the shown code to this basic structure.

 

[VishwanathAmbli]

hello FvM,

in SPI for every rising edge of sclk one bit of data is sent or 8bits????? and if u can help me frame exact entity structure and give the procedure for further proceedings i ll continue with the architecture:
thank you...

if not entity atleast FSM....

 

[shaiko]

in SPI for every rising edge of sclk one bit of data is sent or 8bits?????

SPI output will usually propogate the shift register at the falling edge and sample the input on the rising edge.
It's a serial bus so it can only sent one bit per SCLK clock cycle not more.

 

[VishwanathAmbli]

input will be sampled on the rising edge of sclk means??? it will be read that time or wat...

i mean wat variables do we need to implement this in VHDL???
should i have master buffer and slave buffer to store data, n to which variable should i shift to during falling edge... if you can explain me some more, it would help me...

 

[shaiko]

I strongly suggest that you read this:
**broken link removed**

All answers are inside

 

[FvM]

As an additional point, it should be mentioned that you have different alternatives to operate the SPI slave interface, and it's your job to decide about it.

Firstly, one of the four possible SPI modes (see the Mototorola document linked by Shaiko) has be selected. At least the active clock edge is significant, for the clock idle level both can be accepted with a respective slave design. But the master will use a specific setting.

Secondly, the SPI slave can either use a system clock or be completely clocked from SPI SCLK. The options depend on the intended SPI speed and available system clock.

A fully synchronous design, only clocked by the system clock is preferable in terms of clear timing, but requires a certain oversampling ratio of system clock to SPI clock, e.g. 3 - 4.

Using SPI SCLK as (only) clock requires asynchronous data latches.

A dual clock design which edge sensitive registers for SCLK and the system clock must be well considered to avoid timing violations in domain crossings.