SPI Master/Slave Interface

Nayan Patel wrote:
> but I get the following error message:
You cannot synthesize a testbench on hardware. You can use a testbench 
only for simulation!

Some hints:
1.

1

use ieee.numeric_std.all;

2

use ieee.std_logic_unsigned.all;

Using both of them together is not a good idea, because then you get 
some type definitions doubled...

2.

1

integer range SPI_2X_CLK_DIV-1 downto 0;

A integer usually is defined with a ascending range...

3.

1

        if spi_ssel_i = '1' then                                -- async clr

NEVER EVER use an async input directly in a FSM. Let me repeat it once 
more: NEVER!!! If you don't sync in the external signel this will happen 
sooner or later, now or then:
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
(its German, try Google translator)

Lothar Miller wrote:
> Nayan Patel wrote:
>> but I get the following error message:
> You cannot synthesize a testbench on hardware. You can use a testbench
> only for simulation!
>
> Some hints:
> 1.

1

> use ieee.numeric_std.all;

2

> use ieee.std_logic_unsigned.all;

3

>

> Using both of them together is not a good idea, because then you get
> some type definitions doubled...
>
> 2.

1

> integer range SPI_2X_CLK_DIV-1 downto 0;

2

>

> A integer usually is defined with a ascending range...
>
> 3.

1

>         if spi_ssel_i = '1' then                                -- async 

2

> clr

3

>

> NEVER EVER use an async input directly in a FSM. Let me repeat it once
> more: NEVER!!! If you don't sync in the external signel this will happen
> sooner or later, now or then:
> 
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
> (its German, try Google translator)

I just figured out that the "spi_loopback.vhd" file is meant to be set 
as the "Top-Level Entity".

I simulated the "spi_loopback.vhd" file but I get the following errors 
as shown in the file attached. I am not sure why I am getting these 
errors.

Nay

Nayan Patel wrote:
> I get the following errors as shown in the file attached.
I can see no error there. Just some red and green lines.

And I see a time scale up to some 1200ps. But your test bench does its 
first action 3800ps later. Then its time for the first rising edge of 
the clock. And the reset will be set and released decades later...

Lothar Miller wrote:
> Nayan Patel wrote:
>> I get the following errors as shown in the file attached.
> I can see no error there. Just some red and green lines.
>
> And I see a time scale up to some 1200ps. But your test bench does its
> first action 3800ps later. Then its time for the first rising edge of
> the clock. And the reset will be set and released decades later...

Do you think I should change the time scale to see the inputs and 
outputs changing logics?

Its just some clicking around in the waveform window you should do. 
Use the tool you have. Engineering is not just clicking on the "Start" 
button...

Lothar Miller wrote:
> Its just some clicking around in the waveform window you should do.
> Use the tool you have. Engineering is not just clicking on the "Start"
> button...

Thanks.

I am trying to create a test program which shows that the correct data 
is being received on the SPI link by lighting a few LEDs, any ideas on 
how I can do this?

Nay

Did you simulate the design successfully? Does it do what you expect?

Then its time to go on real hardware. Just connect a SPI master and a 
SPI slave together and send data from a DIP switch continuously from the 
master to the slave. At the slave you connect your LED to the output. 
When you get the same LED on and off like you switch the DIP switches, 
then you have proven the MOSI direction.
For the MISO direction you can figure out easily a very similar test 
strategy...

Lothar Miller wrote:
> Did you simulate the design successfully? Does it do what you expect?
>
> Then its time to go on real hardware. Just connect a SPI master and a
> SPI slave together and send data from a DIP switch continuously from the
> master to the slave. At the slave you connect your LED to the output.
> When you get the same LED on and off like you switch the DIP switches,
> then you have proven the MOSI direction.
> For the MISO direction you can figure out easily a very similar test
> strategy...

Yes, I have finally created a test bench that uses the main cores only 
and it works, please find the file attached.

I understand what you are trying to say but I have to prove the MOSI 
direction by creating a state machine code and I do not know how to 
start.

Nay

Hi,

even i am trying the same testbench,master and slave codes but i can run 
them without any changes in the code but after i run in the simulation 
diagram,i can see no clk at all.it is 0.what could be the possible issue 
and solution for it?