Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

SPI protocol using Xilinx System Generator

Status
Not open for further replies.

cineq

Newbie level 4
Joined
Nov 5, 2010
Messages
7
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,345
Hi All!!

I want to communicate with GYRO L3G4200D **broken link removed**

I'm communicatinhg with this device using Xilinx System Generator and debuging via co-simulation hardware option.

I was able to generate waveforms which are conformable with SPI protocol for this device:

wave1.png


But as you see i am not able to receive any data. I am sending "10001111" which is "Who am I" register address, and I should receive answer: "11010011". instead of that i've got only "11111111"

I'm using "single step mode" in JTAG Co-Sim and FixedStepDiscrete for simulation in simulink.

I don't understand it because everything looks good and is conformable with L3G4200D specification - first bit(RW) of SDI starts at falling edge of SCL and has value "1"(because I want read data), bits 2 to 8 are register address....:shock: I've checked every master output line under the osciloscope and it looks fine to me, but i was able to check only one channel per time...




The fings change a little when I move SDI signal one clock period further

wave2.png

But it still is not do answer of "Who Am I" Register:roll:

- - - Updated - - -

Does anybody have experience with projects in SysGen and has experience with setting up this kind of communication?

Please help poor student ;)
 

What you could do is slow down your SCL by a factor of say 1000. Usually the hardware will allow it, and it may magically fix some assumptions you unwittingly made.

Okay, looked a bit closer at it. It looks like you are changing the SDI on precisely the wrong SCL edge. You should change your SDI value when SCLK is low. Currently you are changing it when SCL is high. So essentially you phase shift your SDI 180 degrees and things should be dandy...
 
  • Like
Reactions: cineq

    cineq

    Points: 2
    Helpful Answer Positive Rating
What you could do is slow down your SCL by a factor of say 1000. Usually the hardware will allow it, and it may magically fix some assumptions you unwittingly made.

Yes I agree, but I've also checked the simulation under "free runing option" (where FPGA is operating asynchronously to the Simulink simulation) and got the same answers...

Okay, looked a bit closer at it. It looks like you are changing the SDI on precisely the wrong SCL edge. You should change your SDI value when SCLK is low. Currently you are changing it when SCL is high. So essentially you phase shift your SDI 180 degrees and things should be dandy...

Thank You but I don't understand. In first sim I change SDI during high SCL, but in the second I change it during low SCL and the answer was still wrong. Maybe You are thought aboutt CLK system clock?

I tried to modify SCL wave and I take something like this:

wave3.png

Im not sure bo I think the answer is "11000111", but it still inst Who Am I Answer :(

- - - Updated - - -

I really don't understand differences between this two answers:

wave3.png

wave4.png


The first bit starts at falling edge of SCL after the CS is low in both examples... :/ And the answer is different
 

Yes I agree, but I've also checked the simulation under "free runing option" (where FPGA is operating asynchronously to the Simulink simulation) and got the same answers...



Thank You but I don't understand. In first sim I change SDI during high SCL, but in the second I change it during low SCL and the answer was still wrong. Maybe You are thought aboutt CLK system clock?

Nope. When I said SCL I meant SCL the SPI clock, not your system clock.

I tried to modify SCL wave and I take something like this:

View attachment 79131

Well, that is still wrong, since you are still changing the SDI data when SCL is high. You should be changing SDI when SCL is low.

Im not sure bo I think the answer is "11000111", but it still inst Who Am I Answer :(

- - - Updated - - -

I really don't understand differences between this two answers:

View attachment 79132

View attachment 79133


The first bit starts at falling edge of SCL after the CS is low in both examples... :/ And the answer is different

WTF are you doing? :p Ahem, sorry. In the last one you start too soon fiddling with SDI.

SCL high is your idle state. CS high is your idle state.

Then you FIRST have CS go low to tell the SPI slave data is coming sooooon.

Then you have SCL go low so you can set SDI to your first bit of data.

And ONLY then do you start fiddling with SDI. So only after you have set SCL low for the first time can you set SDI to your first bit of data, a '1' in this case.

If that is still unclear, post your testbench + code. Hell, just zip up the archive and post it, and I'll take a look at it if you want. Saves a lot of back and forth.

Edit: Oh yeah, almost forgot to ask. Is this in real hardware with jtag and such? Or is this purely simulation? If it is purely simulation, then what are you using for the L3G4200D spi slave? The reason I ask, if you have testbench code for the L3G4200D then that is an additional source of potential errors. :p Anyways, post code and/or project dirs.
 
  • Like
Reactions: cineq

    cineq

    Points: 2
    Helpful Answer Positive Rating
I think I understand...
I understand that my first sim:

**broken link removed**

was wrong - i start first bit when SCL goes low, but I shall start it when it is already low?

So I have to increase the SCL period 2x or 4x because I'm not able to start first bit when SCL is already low. It is bocuse SCL period is 2x CLK period at the moment, isn't it?

Edit: Oh yeah, almost forgot to ask. Is this in real hardware with jtag and such? Or is this purely simulation? If it is purely simulation, then what are you using for the L3G4200D spi slave? The reason I ask, if you have testbench code for the L3G4200D then that is an additional source of potential errors. :p Anyways, post code and/or project dirs.

It's not o simulation but Hardware In the Loop. I have L3G4200D connected to the xc3s200 spartan which communicate with simulink via JTAG.
My point is to get this GYRO run in simulink scope.

I have only a simulink schematic because I have realize this project using System Generator from Xilinx.View attachment gyro_L3G4200D.zip
 
Last edited:

I think I understand...
I understand that my first sim:

**broken link removed**

was wrong - i start first bit when SCL goes low, but I shall start it when it is already low?

So I have to increase the SCL period 2x or 4x because I'm not able to start first bit when SCL is already low. It is bocuse SCL period is 2x CLK period at the moment, isn't it?

Not really. You can do SPI just fine with a system clock that is twice the SPI clock. But doesn't matter, if you see a solution right now with your system clock being 4x the SPI clock, just do that. At this stage it's probably more important to get something that works. After you get it working you'll probably see that you can also do it at 2x.

Incidentally, the " I cannot start when SCL is already low" has an easy fix. Make sure it is NOT low when you make CS go low. It's design after all, so you can make SCL whatever you need it to be.

Just initialize CS=1, SCL=1, SDI=0 (or 1, doesn't really matter) for when your design comes out of reset. And make sure it goes back to CS=1 and SCL=1 when it is not sending data. That way you have no such "but SCL is already low" problems.

It's not o simulation but Hardware In the Loop. I have L3G4200D connected to the xc3s200 spartan which communicate with simulink via JTAG.
My point is to get this GYRO run in simulink scope.

I have only a simulink schematic because I have realize this project using System Generator from Xilinx.

Thanks for the clarification. That'll save us some assumptions. :)
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top