SPI Bus Specification

You never really asked a question so I'm not sure whether you're interested in a reply.

In any case, I've had much the same experience. There doen't seem to be anything like a formal published specification. I've had to analyze each implementation I've done.

You are probably more likely to run into a setup or hold timing violation with the particular logic devices you are using, as opposed to an overall SPI timing specification issue. Even though you are running at 101KHz, clock rate, you could still run into timing troubles relative to the data to clock timing.

Most data sheets I've seen spec this as one would a Serial shift register. So they have Clk-Data out, on one edge, and Tsu.Th times on the other edge. eg the AT89LP2052 data sheet has all this info ?

Basically, from the time a clock edge and OP data appear, you have a nominal half-clock time MAX to get the IP data ready, or your SPI will notice your link. If you are pacing this, the other detail to watch, is to never change the relative skew delays : ie clock must appear before the DataOut, so that probably need special handling.

-jg

Most chips that have an SPI port will define its version in their data sheet.

This site is as generic as it can get.

Yes, sorry I forgot the question. I am looking for timing specs on the bus.

I know that the devices clock data out on one clock edge and in on the other. But I don't know how much time is allowed for the output to settle and setup on the input. So I don't know how much time can be budgeted to the multiplexer function. With a 10 us bit time I expect it will be no real problem if I jitter the signal edges by 1 or 2 us.

I was thinking of capturing the parallel data in a register and shifting it out to the other side and then clocking it into an output register. But this takes a lot more resources and it is not at all clear to me that this will work better. Just because of the issues of metastability even this approach can change the relative timing of any two signals by 1 us. So I think I will take the easy approach and not latch the inputs and let the outputs update sequentially on the fly rather than simultaneously.

Even if it is just for our project, there really needs to be a timing spec just to make sure we are all on the same page.

Thanks, I think the answer to the question I didn't ask is that there is no spec. It is up to the designer to allocate timing margins based on the chips they are using. I don't know the chips at the other end of this interface (actually either end), but the timing is very generous so I will just assume that I have timing margin to spare. I am also going to assume that it does not matter if I introduce +-1 us of relative jitter in the signals on the bus. Since the data is clocked out on one edge and in on the other, this will not cause any signals to cross a critical timing boundary.

I do remember seeing a timing spec on the SPI bus that showed some nominal amount of output delay and input setup. But I can't find that again for the life of me.

Since there are several SPI schemes there is not one answer. The chips have the timing diagrams. You need to data sheets for the chips you are talking to. Note that many A2Ds use the clock for the conversion. It may need to be uniform.

I recall "The Specification" being the "Synchronous Serial Peripheral Interface" section in what was known (in the '80s?) as the "Pink Book"; that is, the M68HC11 Reference Manual in which SPI was (presumably) first introduced. No longer pink, the most recent version I know of is available as:

Still, it does not have the timing information you seek.

Yep.

Setup and hold times along with maximum clock rate are the important things, I think.

The SPI is relatively easy. I've done several. Both bit-banged out and hardware dedicated on uP's . Just check your timing diagrams for both the source and destination. I've always used the CPU as master. Also, make sure to not violate any setup and hold times as well. At 100kHz it should be a breeze :) .

If you want more information you will have to provide details on what you are talking about as far as "fewer pins", SPI doesn't have that many pins.

Yepp, as you've alluded to elsewhere, there is no timing spec for the bus. This is determined entirely by the devices at either end. Some devices can only run at 100kbaud or so, while others run at faster than 80Mbaud. Asking for a generic timing spec is a bit like asking for a single timing spec for microprocessor parallel busses.

Cheers, Alf

Ay, there's the rub! I don't have info on the source or destination. I am just a middle man. But with a 100 kHz bus clock, I am pretty confident that this will work. Someone cautioned me that if the jitter swaps the edges of clock and data it could be a problem. But I think this is not true unless you cause an edge to move a half clock cycle. I don't see how it can matter if the data changes slightly before the active edge of the clock (instead of after) since the active edge for the receiver is the other edge.

I am not asking for help with the logical design. I am looking for timing information so I can determine how much slack there is in the system I am working with. Obviously there is no bus level spec on the timing. Rather it is up to each designer to assure that his use of different devices is compatible.

As you don't know what devices you are working with, then be very careful not merely of speeds and timings. A *lot* of older Mot chips (back when they still _were_ Motorola) truncated the least significant bit on the bus to valid for only the firrst 50% of the bit time.

Whether that is true for the devices you are delaing with is unknowable for both of us.

Cheers

PeteS

I am getting that. Unlike nearly all other serial buses, SPI has no real spec and, as you say, is like embedded CPU memory busses, a custom design for each device. That is a good analogy. But even CPU memory busses have become standardized to work with standard memory such as SDRAM, DDR, etc.

LOL, have they? I'll have to try connecting my brand new TMS470 ARM7 processor's external bus to an SDRAM (or a DDR for that matter). Dunno why I've been wasting money on static and pseudo-static ram.

You can have standards, but you pay for them in price, performance, or both. SPI is a very lightweight interface, silicon wise.

Cheers, Alf

No, you have to do a timing analyzis of the combination of CPU and Memory to find out how many waitstates you need. You also need to check if you violate setup and hold times.

This is exactly the same with the SPI bus. It defines four different modes, which are explained in most decent chapters in microcontrollers, but the setup and hold times are device dependent.