jakubcabal / spi-fpga

SPI master and SPI slave for FPGA written in VHDL

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

spi slave miso test

imuguruza opened this issue · comments

Hi again!
I am triying to write from the slave 4x data transfer of 16bit spi data field. This is executed every 5ms.
I am facing an "issue" with the reset state.

In order to handle the spi slave, I am using a state machine that checks the value of din_vld to set the value of din.
So the state machine waits to see an edge of din_vld to set a different value each time.

something like:

p_rising_edge_detector : process(i_clk, i_reset)
  begin
    if(i_reset='1') then
      r0  <= '0';
      r1  <= '0';
    elsif(rising_edge(i_clk)) then
      r0  <= i_din_rdy;
      r1  <= r0;
    end if;
  end process p_rising_edge_detector;
  ---------------------------------------
  edge <= not r1 and r0;
  ---------------------------------------

--------------------------------------------------------------------------------
state_machine_p: process (i_clk, i_reset)
-- Logic to advance to the next state
begin
  if i_reset = '1' then
    state <= s0;
  elsif (rising_edge(i_clk)) then
    case state is
      when s0=>
        if edge = '1' then --wait for slave not busy
          state <= s1;
        else
          state <= s0;
       end if;
      when s1=>
        if edge = '1' then --send first
          state <= s2;
        else
          state <= s1;
       end if;
      when s2=>
      ...
  end if;
end process;

What I see is that the slave is sending a 0x0000 first, and after the data I am sending back to the master.
I am unsure gow to force the slave to not to send this 0x0000 and start with my first 16bit data.

To put it more clear:

image

The first message I want to send is 0xCAFE, but it is not registered after the reset.
I am not sure how to handle this, as I see that in the first execution I am seeing 5 rising edges of din_rdy and after 4, as expected:

image

image

How should I handle it?
Thanks!

Hi,
right after the reset you probably have bad data on signal DIN, even though signal DIN_VLD is set to '1'. You must have the DIN_VLD signal active only when you have the correct data on the DIN signal. Data from the DIN signal is accepted only in the clock cycle when DIN_VLD and DIN_RDY are active at the same time.