Powered by Invision Power Board


Forum Rules Forum Rules (Please read before posting)
  Reply to this topicStart new topicStart Poll

> Spi Question (it Works!), But I only need 31 cycles???
Particle
Posted: January 05, 2011 04:11 am
Reply to this postQuote Post


Sr. Member
*****

Group: Trusted Members
Posts: 396
Member No.: 1,056
Joined: July 20, 2004




Hey guys. Yesterday I wrote a Verilog SPI controller, and while it appears to work, something strange is going on. I've noticed that I'm getting an "extra" bit on the end of a transfer. It's a valid bit--it's just a wrap around of whatever byte address I've specified when in byte mode or the first bit of the next byte in sequential.

What seems to be happening is that the memory shifts out a bit onto MISO after the first falling edge of CLK following the last rising edge of CLK where it's listening for data. This is something I can deal with, but it means that for 32 transactions I'm only pulsing CLK 31 times. Is that normal? The documentation for this memory IC shows 32 clock cycles for one transaction instead of 31. Is it an error in the documentation?

Ex:

MOSI: 8b Command + 16b Address + 8b Don't Care
MISO: 23b Nothing + 8b Byte + 1b First Bit of Next Byte

As a consequence, I can get my data by either only pulsing 31 times and taking the last 8 bits or taking bits 8:1 when pulsing 32 times. The second method becomes trickier when I want to do legitimate sequential access and the first bit has already been shifted in on the tail end of my input buffer that's about to be cleared.

Real-life example. The byte 1010-1010 is in address 0000-0000-0000-0000 of an SRAM IC. I go to read it and I get 1010-1010-1 out. If I instead write 0101-1010 I get 0101-1010-0. It's clearly wrap-around, not just a shifting issue or something like that on my part since the last bit is certainly valid. The IC is genuinely sending me 9 bits.

user posted image

I used my recently finished RS-232 module from last week to send samples of all the SPI lines with 100 microsecond (10 KHz) resolution and then wrote some software on my PC to capture and graph the data. I don't have a regular digital logic analyzer, so this was sort of a neat idea. I just slowed the transaction down to around 950 ms so I'd be able to clearly see what was going on with the limited resolution afforded by the relatively low RS-232 bandwidth.
PMEmail PosterUsers WebsiteICQ
Top
Gorgon
Posted: January 05, 2011 09:05 am
Reply to this postQuote Post


Forum Addict ++
*******

Group: Trusted Members
Posts: 3,009
Member No.: 3,861
Joined: December 18, 2005




If your logic histogram is correct, you read and set data on the same flanks for both the slave and the master, this is not correct. Normally the master and the slave clock and read/write data on different flanks. Since you don't set the first bit from the master to '1', I can't tell if you setup the data before the first rising flank of the clock, but I assume you don't.

As indicated the master must set it's first data bit a half cycle before the first 0->1 flank of the clock, and read the slaves data on the falling edge. The phase of the clock is depending on the slave device specs.

If you think about it, the slave needs at least half a clock period to respond on the data received.

TOK wink.gif


--------------------
Light travels faster than sound. That's why some people appear bright until they speak!
PMEmail Poster
Top
Particle
Posted: January 05, 2011 04:18 pm
Reply to this postQuote Post


Sr. Member
*****

Group: Trusted Members
Posts: 396
Member No.: 1,056
Joined: July 20, 2004




The controller I built is very careful not to step on any toes. It will ensure that MOSI is set a programmable number of host clocks before SPI_CLK goes high (when the slave reads) starting from when SPI_CLK goes low. It won't drop the clock low until the data out hold timing is satisfied, so there's no violation happening there. It also doesn't sample MISO until a programmable number of clocks after SPI_CLK goes low (when the slave writes) and won't set clock high again until that is satisfied. This (combined with its enforcement of all other timings) ensures that reads and writes are always happening at valid times. It just goes beyond the basic read/write on half cycles method so as to fully respect all waveform timing parameters for any device. Like I said, this controller does appear to work fine--reads and writes are always successful, I was just thrown by the extra bit. 32 transactions occur after 31 pulses as the slave device shifts out its reply's MSB half a cycle after it reads its last input bit instead of on the following clock like I'd expect. Since I want 8 bits out and it wanted 24 bits in, nobody really cares about the 32nd pulse. It isn't reading MOSI on the 32nd and it's already shifted the LSB onto MISO as of the negative edge of the 31st cycle.

From what I've gathered from memory IC tech docs, this is actually starting to look normal. It's weird to me, though, and I'm just wanting to make sure this is normal before going "well OK then, this must be business as usual so I'll deal with it" and moving on. Since I'm in the learning stage, I don't want to commit to incorrect info.
PMEmail PosterUsers WebsiteICQ
Top
Particle
Posted: January 06, 2011 04:12 am
Reply to this postQuote Post


Sr. Member
*****

Group: Trusted Members
Posts: 396
Member No.: 1,056
Joined: July 20, 2004




Here's a reference from a Ramtron tech doc that demonstrates what I mean:

user posted image

You could be done with this transaction after 15 cycles if you read the LSB on the 15th cycle after CLK goes low, making sure to wait for the data setup time to elapse. It's the same thing I'm seeing on my logic analyzer, but it just seems conceptually funky unless the last pulse is just for the master's benefit if its controller is basic and simply shifts in on the positive edge of CLK.

The slave responds half a cycle after the last bit it reads off of MOSI instead of waiting for the next pulse. I wonder why they bother doing that extra bit then?
PMEmail PosterUsers WebsiteICQ
Top
Gorgon
Posted: January 06, 2011 09:04 am
Reply to this postQuote Post


Forum Addict ++
*******

Group: Trusted Members
Posts: 3,009
Member No.: 3,861
Joined: December 18, 2005




QUOTE (Particle @ January 06, 2011 05:12 am)
The slave responds half a cycle after the last bit it reads off of MOSI instead of waiting for the next pulse. I wonder why they bother doing that extra bit then?

I see that I formulated the answer wrong in my last reply. The idea is that data is set on negative flank and read at the positive flank. The master set its first databit a half cycle (imaginary negative flank) befor the first positive flank. This is because the clock always return to '0' in this case. That is also the reason you have 16 cycles(pulses) for 16 bits.

You can use the SPI interface on simple shift registers and advanced chips, and they all have to be in sync, since they all can be connected to the same bus, and clocked simultaneously. If you cheat and loose clock pulses for whatever reason, you'll end up in a mess before you know it.

You should also be aware of the fact that the clock phase and data transfer protocol may be reversed on some systems/ devices. If you make some universal interface you should also make these things configurable in the interface. I've myself used several different protocols in the same interface/bus, towards different devices.

TOK wink.gif


--------------------
Light travels faster than sound. That's why some people appear bright until they speak!
PMEmail Poster
Top
Particle
Posted: January 06, 2011 07:00 pm
Reply to this postQuote Post


Sr. Member
*****

Group: Trusted Members
Posts: 396
Member No.: 1,056
Joined: July 20, 2004




I forgot to mention that I actually do set up the first bit before the first clock. I was very careful when designing the controller. =) First I made it functional and then I went about hiding as much controller latency as possible without compromising correctness.

My real concern here now that I'm more clear on what is happening is how this is going to effect page and sequential reads in ICs that support them. If the memory IC automatically increments the address and is doing so on the tail end of the previous transaction due to that last pulse being there, what happens the next time I go to read data? My guess is that it starts at the beginning of that next address since these things don't address to the bit but rather the word (8-bits, 16-bits, whatever it happens to be).

If I do say a transfer that exceeds the controller's RX register width, things are going to get funky. The controller signals when it is full with the idea being that the host will copy the controller's RX register and tell the controller to resume. This puts me in a strange situation where I'm left with an extra, ninth bit (the first bit of the next byte) such that the host would need to buffer 33 bits instead of 32. It's doable, but again it feels weird. Is there a different way this is normally done to make it less complex / cleaner?
PMEmail PosterUsers WebsiteICQ
Top
Sch3mat1c
Posted: January 06, 2011 07:04 pm
Reply to this postQuote Post


Forum Addict ++
Group Icon

Group: Moderators
Posts: 19,502
Member No.: 73
Joined: July 24, 2002




You could add more registers so there's a FIFO on it. This is typical of most serial controllers, though I don't know if it is for SPI.

Tim


--------------------
Answering questions is a tricky subject to practice. Not due to the difficulty of formulating or locating answers, but due to the human inability of asking the right questions; a skill that, were one to possess, would put them in the "answering" category.
PMEmail PosterUsers Website
Top
Gorgon
Posted: January 06, 2011 07:31 pm
Reply to this postQuote Post


Forum Addict ++
*******

Group: Trusted Members
Posts: 3,009
Member No.: 3,861
Joined: December 18, 2005




QUOTE (Particle @ January 06, 2011 08:00 pm)
If I do say a transfer that exceeds the controller's RX register width, things are going to get funky. The controller signals when it is full with the idea being that the host will copy the controller's RX register and tell the controller to resume. This puts me in a strange situation where I'm left with an extra, ninth bit (the first bit of the next byte) such that the host would need to buffer 33 bits instead of 32. It's doable, but again it feels weird. Is there a different way this is normally done to make it less complex / cleaner?

If you are left with an extra bit in the sequence I would suppose that you don't use the clock properly to clock your data. If done correctly you should end up with the correct number of bits, in the correct order.
I saw you said something about listening for data in your first post, and I think your solved this in a iffy way. The clock is the master in this! rolleyes.gif
You shift the data IN on the positive flank and OUT on the negative(seen from the master). The last negative flank is only to return to '0', and you need to setup the first bit before the first positive flank.

As long as you are the SPI master in this, there is no problem with timing. The interface is CONTROLLED by the master.
I have only used MCU based SPI controllers, but I've never had any problems with data overflow/speed. The controller is normally working in interrupt mode, and the isr read/write data from and to the controller. Remember to read first since controllers normally start transmitting when written to.

TOK wink.gif


--------------------
Light travels faster than sound. That's why some people appear bright until they speak!
PMEmail Poster
Top
Particle
Posted: January 07, 2011 04:40 am
Reply to this postQuote Post


Sr. Member
*****

Group: Trusted Members
Posts: 396
Member No.: 1,056
Joined: July 20, 2004




Please do not get hung up on where I'm reading & writing data or skim the post--I feel like you guys are missing what I'm trying to get across. I absolutely guarantee you that I'm doing I/O at valid times! This thread is not me relating problems being able to read or write successfully. I can and do.

I *do* set the first bit on MOSI before the first clock pulse. There isn't any problem with timings. Every bit I ever read is read fine and every bit I write is taken by the IC. Never does the controller not manage to make an IC work nor do I receive bits shifted to the left or right of where I expected them. I also only ever pulse exactly 32 times in a transaction where I write 24 bits and read 8. The IC MUST receive every bit and on the correct pulses as evidenced by it replying in the expected way. If I were shifting my TX one bit forward or backward, the IC simply wouldn't talk to me at all or would perform the wrong function if it still managed to make a different (yet still valid) command. These problems don't happen, so I'm confident.

I've only referred to timings for the sake of demonstrating that I've been careful to observe them all instead of just toggling at a given clock frequency and reading on edges. And technically, the clock doesn't itself need to control anything. CLK toggling is just how to prompt the slave to transition or read. You can read MISO at any point where the data is "valid". You're getting hung up on where I'm reading the data at, but that clearly isn't an issue. I'm getting 100% valid data back at full transmission speed. ICs have a parameter for how long it takes output states to become valid following the negative edge of a clock pulse. The data remains valid until the next negative edge. I'm reading at a valid time. I'm also writing at valid times. This is not the problem.

Maybe this will make it clearer what I'm saying. Imagine a memory IC of infinite capacity that has never-ending data in it of this pattern: 1010-1010-1010-etc. Lets say that it only supports reading from the beginning and will go for as many cycles as you want. The read command is 1. Let's say I want to get the first two bits. I should perform three write/read cycles, sending 1-0-0. The IC will only care about the first bit at which point it will start replying. This action represents 3 read/write cycles. The graph below shows what would happen:

user posted image

- Master sets MOSI on the falling edge of CLK or CS.
- Master reads data after the falling edge of CLK and before the rising edge of the next CLK (black dots). This action happens at least x cycles after the falling edge with x representing the IC's data setup time in host cycles. Ex: If the host frequency is 50 MHz (20 ns) and the slave IC requires 25 ns max to set up data, the controller will wait 2 cycles (40 ns) after CLK drops before reading.

- Slave sets data on the falling edge of every cycle.
- Slave reads data on the rising edge of each CLK (red dots).

The slave has sent three bits to me.

The whole deal with my question is related to how the IC responds to me three times when I'm only supposed to get two bits back. Notice it replies half a cycle following the last input bit. Notice that it also transitions after the last cycle. This is the exact same thing that happens according to this example graph Ramtron has provided:

user posted image

Replies half a cycle later after the last input bit. My experience is identical. The difference here is that this graph doesn't show the IC is sending another bit on the negative edge of the very last CLK cycle. An IC replying in an arbitrary-length sequential manner will certainly transition there. It is THAT which I am referring to since the IC is really already done sending 8 bits after 7 cycles.
PMEmail PosterUsers WebsiteICQ
Top
Gorgon
Posted: January 07, 2011 09:11 am
Reply to this postQuote Post


Forum Addict ++
*******

Group: Trusted Members
Posts: 3,009
Member No.: 3,861
Joined: December 18, 2005




Ok, I only try to help you out here. The clock is everything in the SPI system, whatever you say. The reason for that is the timing of the interface. The clock period and pulse length takes care of all the timing involved in the data transfer.
If you tell me that the clock is not very important, I'll tell you that you speak rubish.

Take some time and study this: SPI definition

ADDED: From what I can tell your question is; what happens after the last clock cycle. This is depending on the device you communicate with. If it is made to continue transmitting it will load a new byte. This will be described in the spec of the device. Normally an inactive chipselect will reset all counters/ registers in the device, and make it ready to start again.

TOK wink.gif

This post has been edited by Gorgon on January 07, 2011 01:55 pm


--------------------
Light travels faster than sound. That's why some people appear bright until they speak!
PMEmail Poster
Top
Particle
Posted: January 07, 2011 05:55 pm
Reply to this postQuote Post


Sr. Member
*****

Group: Trusted Members
Posts: 396
Member No.: 1,056
Joined: July 20, 2004




If you insist that SPI_CLK must control the master's reads, I must in turn insist that you do not fully understand SPI. The positive edge of CLK is when reads on MISO *normally* done, but that is not the only point where data is valid. Data is valid at all points between [Tv] nanoseconds after the negative edge of SCK and before the next negative edge of SCK. Absolutely any and all points. If your host clock is sufficiently faster than the SPI clock frequency (SCK), there are going to be multiple host cycles during the valid period (which in the case of SPI is also controlled by master anyway and can be arbitrarily long). This is the same basic concept surrounding all sampled I/O such as when you talk to a PS/2 device or listen to RS-232. There's no getting around that fact. It's not my opinion. You seem stuck in a mindset surrounding a more basic architecture like decimating the host clock to derive SCK and then doing logic trigged by the edges of that derived clock. That is also a valid technique, but it's not the one employed here. Both are functionally correct. However, this is all irrelevant to my actual question. I was not asking about how to do SPI. Despite weather or not you agree, I'm doing it in a way which is perfectly valid. Take note that I've spent dozens of hours researching SPI resources. Just linking me to Wikipedia is sort of demeaning.

Don't get me wrong, I do appreciate the time you have invested in trying to assist me. It's only the second part of your very last post that has nearly addressed my actual question though. With continued research, I've managed to piece together a final conclusion. I want to thank you for your part in that search. I'm not being sarcastic here, all input has been appreciated.



--- Answer for Future Googlers ---

In case any others run across this thread in the future, coming in by way of Google or whatnot, I do want to provide a clear and specific answer so as to help the next person finding themselves in the same spot I was:

It's normal and you have to deal with it. The architecture of your controller will determine if you encounter this. Why? The slave will start to respond half a cycle after the last bit it clocks in from your command instead of on the next full cycle. Within one cycle it will clock in the last bit (posedge of SCK) and transition the first bit of its reply out (negedge of that same SCK cycle). As a consequence, in a situation where you want to write 8 bits and expect 8 bits back, you really only need 15 cycles to make all intended transitions occur. On your 16th cycle, you will get one of the following after the negative edge: nothing, the next bit of the following memory address, or the first bit of the same transaction you've already completed. Which you get will depend on the IC you're dealing with. ICs that do sequential transfers will always give you the next bit. Others may or may not wrap around whatever boundary (byte, page, word, block, etc) you might happen to hit. In contrast to the write + read scenario, if you only want to write X bits to the device (typical write command) you need to issue a full X cycles to get the job done instead of (X - 1). This peculiar situation only arises when the slave is replying to a command you're sending.

Now, one important consideration is what happens when your controller's input buffer is full. If your RX register is 8 bits wide and you're reading 8 bits following an 8 bit command that you're writing, the following will happen:
1) Clocks 0 to 7, Positive Edge: Slave clocks in all 8 bits.
2) Clock 7, Negative Edge: Slave has started sending bit 0 of its reply.
3) Short duration afterward: Data is valid.
4) You've completed 8 cycles and thus have done 8 reads, the 8th of which is bit 0 of the reply.
5) Clocks 8 to 14: Slave has shifted out bits 0 to 7 by this point. The 8th bit of course won't be valid until *after* the negative edge of the 14th clock.
6) Clock 15: MISO may transition to another bit after this clock.

Since most SPI controllers simply read MISO on the positive edge of SCK, most controllers never trigger a read after that last cycle. This is technically incorrect for a full duplex communication protocol, however it is how SPI seems to be expected to work. The read-on-SCK-rise method assumes that the first read should occur before the slave has ever clocked in a bit which is nonsense. SPI is a full duplex protocol and as such the slave always responds after the master. If you had an SPI slave whose sole purpose was to echo back to the master what the master said and you only triggered reads on the rising edge of SCK, your master would never receive more than (X - 1) bits back after having sent X bits. This isn't something normally seen since real, full duplex SPI communication is seemingly sort of rare. There are two ways to fix this problem: Either read data at some point after the falling edge of SCK as I do with my controller or read on every SCK pulse's positive edge AND also when you raise CS. Most of the time though, you aren't going to be interested in that very last bit. Everybody assumes that you won't be reading it--a situation borne out of the fact that a reply starts half a cycle after write. Since that is the expectation, that is what you should do. Treat the first cycle as a read instead of ignoring that pre-TX period on cycle 0.

It's the classic problem of implementation being different than the ideal. Since only the implementation ultimately matters, you'll just have to deal with it and play by those rules. In my specific case (in case you wound up taking my approach and have the same issue), the answer is to modify the controller to not read after the very last clock and to also trigger the buffer full signal before the RX register length - 1 cycle read of each pass.

--- Edit (TL;DR Version)

For anyone wanting an even quicker explanation who doesn't care about the other details: SPI operates on read-write cycles instead of write-read cycles. Read first, then write. It's goofy because of the first read never being a useful bit, but that's how this protocol is set up.
PMEmail PosterUsers WebsiteICQ
Top
0 User(s) are reading this topic (0 Guests and 0 Anonymous Users)
0 Members:

Topic Options Reply to this topicStart new topicStart Poll

 


:: support us ::




ElectronicsSkin by DutchDork & The-Force