STP24DP05

That's the maximum. Since clock is an input, don't supply edges slower than this.

All it's saying is that since clk is common to all chips in a chain, that's the weak point of your system.

For someone who's as smart as you claim, you sure have a hard time with EE 101 stuff, Jon.

Hey, how are the home-made 4 layer boards coming along? Video up on youtube yet? Need materials or a camera?

ess

I suspect the footnote is wrong. Look at the one on page 6, which makes more sense.

Anyway, I interpret the spec instruct the user to make the rise/fall be faster than 5uS. Often displays are on a "remote" PCB and sent over a wiring with significant capacitance.

The part has a Schmidt trigger, so it can probably handle a slow rise/ fall for one chip. However, when you cascade, the effective trip point (time when data is latched) will differ for each chip since the time depends greatly on the individual Schmidt trigger trip point for each chip.

Yep, if you want to achieve their claim of 25MHz max clock rate then the rise/fall time of your clock will obviously have to be much shorter. You supply the clock, so just make sure its tr/tf isn't longer than 5us.

Bob

I looked at the PDF, from what I gather, It's stating that if you were to daisy chain then (Cascade) via the Serial IN and Out to the next stage, your timing at some point would truncate to which, a following stage would then not respond.

So take into consideration the minimum time the input needs, X the number of stages. So, if for example, the input requires a 10 us on signal, you have lets say 3 stages, you would then plan your timing for 30 us in the serial data link. This will insure that the last stage to receive it's minimum time slice and not start colliding with following data at the first stage.

Now, if you were paralleling them (8 bit output for example), then it wouldn't matter for the first set of 8.

This is just my take on it..

But what does that have to do with cascading? (as the foot note indicates it has something to do with it)

Ok guys, the thing is, how does one caclulate the max number of devices to cascade?

I assume it is limited by the propagation delay and the min hold/setup times? i.e., when you bit bang the data in it takes so long to get through all the serial registers(24*n in this case) but it actually takes longer because of the propagation delay? or the extra trace capacitance will reduce the clock rise/fall time?

Thing is, it would be nice if I could get some idea of how many I could cascade and still be ok. (it will really suck if I cascaded them and couldn't get any decent speed which will break the app)

The chips will be several inches apart so there might be significant capacitance.

I was thinking about multiplexing the clock so all the devices would have no clock except one. It would be similar the serial but should have any problem with cascading.

But it would be easier to just cascade for my specific application.

Ahhhh, yes. You're right.

Well, the problem would be in meeting the setup/hold time for the cascaded SDI pin.

For a multi-chip system where each chip gets a copy of the system clock (aka "system synchronous"), the difference in effective clock arrival times and out-to-in trace delays must be considered.

In this case, since they allow the rise and fall time of the clock(s) to be so big, it is critical to be able to predict when SDO will become valid so that the SDI pin on the other end of the trace meets its setup time requirements. Each chip may (will) interpret the clock arrival time differently as the rise time of CLK increases.

Since the max clock-to-out for SDO is 24ns (at Vdd=5V), and the min setup time for SDI is 15ns, then this means that the minimum system clock frequency is 39ns ASSUMING that the trace propagation time from SDO to SDI is 0ns AND the rise time of CLK is 0ns. This 39ns min CLK period will be increased by the sum of the SDO-to-SDI trace propagation time and the rise time of CLK.

If you use a clock driver with tr=2ns, and the trace length between any SDI and its corresponding SDO is kept to under 1ns (6") then your min CLK period would be 39ns + 2ns + 1ns = 42ns which is 23.8MHz. If you run the chips at

Bob

You'll also have to consider the effect of a slow clock rise time on the hold time requirements of SDI.

If chip1 sees the clock much earlier than chip2 then the hold time at the SDI pin of chip2 may not be met.

Bob

You must ABSOLUTELY use a clock distribution chip with proper termination on each clock line. Each chip gets a "copy" of the clock and each copy arrives at its chip at the same time (by controlling each CLK trace length) as the others within reason, based upon setup/hold requirements.

For TTL/LVTTL signals, use a CMOS clock distribution chip and put a 33ohm resistor as close to each clock output pin as possible. The other end each clock line will connect only to ONE clock input (this is called "source termination" and it works really well).

There is no maximum number of chips that could be cascaded. At any particular clock edge, each chip registers its SDI from the previous clock edge and begins to output its SDO on the current clock edge. The internal shift registers support your

No you don't. Clock skew is only relevant between adjacent sections of the extended shift register. The data sheet is pretty lousy but it looks like worst case @ 5v the part can accommodate up to 4ns of clock skew between adjacent chips (9ns min prop delay less 5ns recommended hold time).

Much easier to use a single clock.

The maximum number of devices in the chain is limited by clock loading slowing the edges with the potential to introduce skew. No reason why clock buffers could not be inserted in the chain prodding you can insert an adequately matched delay in the data at the same place.

If you are interested in the error status coming out of the shift register you will obviously have to look at it with respect to a clock from the end of the chain.

Yeah and to cascade them. Basically if I can cascade with no major problems then I can pretty much minimize costs, routing problems, and mechanical issues. It is the best solution but I'm afraid I might run into some problems with timing/speed.

Cascading and IO sharing means I only need about 5 uP IO lines. Without running the chips in parallel means up to 25-35.

Basically I'm going to wire-and all the TF pins, tie all the OE, CLK, and LE pins, and cacade the SDI/SDO. This gives me the same number of IO lines as just using one chip.

I think though that everything should be ok as long as I don't run into major timing issues. (I can use a driver after the uP to drive all the lines if necessary.

I think as long as I treat the SDI/SDO, LE, and CLK lines as transmission lines it should be ok? the OE and TF flags don't need it since they are not time critical.

This shouldn't be a problem? If so I can just buffer the output clock from the uP which should take care of it.

Not sure how I can use the buffers to match the delay though. Guess you mean I could insert a delay after each section? This would be hard to match though?

No, I'm just worried about the thermal flag so I can shut down the devices if they overheat. I assume it is independent of the clock and such... I'm going to leave the EF floating as it's not important for my app(well, not that I couldn't use it but given the circumstances I don't need it).

The issue is signal integrity. You have to have a clock with monotonic edges and one that doesn't violate undershoot/overshoot specs.

It used to be, with slow clock edges, that you could connect a single clock source via daisy chain or star configuration. That just isn't true any more.

I inherited a design that used a single clock driver output to connect to several pins. Although the clock rate was slow (1MHz) the rise/fall time was about 1ns. This resulted in double clocking due to the placement of the reflection at one of the pins. It failed to pass error free data.

You can't use source termination for multiple if multiple clock pins are connected in a daisy chain when the receivers are LVTTL or CMOS logic levels because you won't meet their levels during the forward transmission of the edge (and then comes along the reflected wave to add insult to injury). You have a chance using source termination in a star topology but it's kinda tricky.

If you use end termination for the daisy chain and star configuration then you have to have a super low impedance clock driver to assure that it will launch a full amplitude wave into the trace(s). Otherwise, you won't meet the logic levels.

It is MUCH easier to bite the bullet and put in a clock distribution chip. They're cheap and they work and they allow you to sleep peacefully.

Bob

I will have star network for the clock(obviously) and daisy chain the data. I can have significant driving capabilities so I don't think that will be a problem with the clock. Although it will be distributed rather far apart and I might have a problem with termination. Not quite sure how to terminate but I guess it's the same as if it was just a single connection? (terminate at destination which would be at each IC in this case)

The main question here is it really needed. They might be cheap but I have another issue which has to do with the mechanical aspects. (basically I need as few components as possible because they way the circuit will be used)

It is not critical to have glitch free operation. In fact, because I have to update the IC every time any glitch won't have much of an impact as long as it is random and doesn't occur to often. This is a lighting situation and I have the IC's driving several rows which means I need to update them continuously. Any glitch will only cause the light to be slightly brighter or not.

One main problem is that my uP will be almost completely tied up transfering the data to the chips. I suppose I will have to use it as a slave and another uP to update it(which can be done slower).

Another way I was thinking was to use a larger serial-in/serial-out to update the IC's transparently and just update those chips when needed... but then it requires much more circuitry.

The point here because I am using PWM and have more than one row I have to update the circuitry repeatedly even though each row won't change much(still needs to be updated because the IC only see's one row).

Here's what you have to be aware of:

For clocks - must meet logic level reqs, meet max rise/falltime reqs, be monotonic, and not violate undershoot/overshoot reqs. For data - must meet logic level reqs, meet setup and hold time reqs, and not violate undershoot/overshoot reqs.

There should be some info on the web that discussed various termination techniques along with transmission line effects of pcb traces. I'll see if I can find a good link.

If you have access to a good simulator (like HyperLynx) then learn it, use it, and love it. They are worth their weight in gold (whatever that means).

In your case, I wouldn't worry too much about the data lines (just connect them with no termination components). The data edge rates should be slow enough that you shouldn't violate undershoot/overshoot specs and not eat into your setup/hold time reqs by too much due to edge ringing.

The clock is a different matter. Use a separate clock output for each pin (using a "low skew" clock distribution chip) and utilize the 'source termination' technique on each clock line. The clock traces should be routed as a transmission line (50ohms is typically used). Insure that each clock reaches its destination pin within, say, 0.5ns by adding trace length where required (0.160ns per inch is okay to use as the pcb trace delay value).

Bob

Right... but the problem is actually figuring out this stuff. I'm thinking though the main problem is terminatin and propagation delay. i.e., the clock won't be sync'ed with the data because of the serial vs parallel method. (would have been nice if they allowed the clock to be serialized in too?)

I guess I have to figure out the propagation type and see how much it gets out of wack compared to the clock?

That or I could multiplex the data line which would make it sync up with the clock and remove that issue(but kinda defeats the purpose).

I'm reading up on it now. Seems like Thévenin termination is the way to go.

I'll look into it.. I've not really messed with stuff like that before but I guess it's as good a time as any to learn.

It wouldn't hurt to terminate would it? Just in case? Guess I could add the footprint for the resistors and add them if there are in problems.

I can't use source termination because my ic's are distributed equally along the clock line. This means the "middle" ones won't get the full voltage except when reflected and might be double triggered.

Can you explain to me why the clock would be a problem and not the data line? It seems to me that it is the reverse. After all, both are pretty much transmission lines but the data adds in propagation delay. (BTW, I'm not familiar with a clock distribution chip)

I didn't say you can have one lousy clock, or source terminate any multidrop clock line, or hang the clock pins on stubs.

I said it was much easier to use a single clock. Maybe he needs 40 devices, how easy is it to implement a 40 way clock generator with 40 length equalised clock lines the longest of which might be a couple of feet?

You need a low impedance clock line, end terminated and carefully daisy chained along the devices. How long it can be and how many devices you can hang on it I can only guess at. The data doesn't give any clock pin loading specs.

Shame the part doesn't provide a delay matched buffer of its own clock which would avoid all this crap. Maybe sticking a tiny logic dual buffer right on the clock pin of each part buffering and delaying the clock and SDO lines for the next stage is a simpler solution which allows the chain to extend without limit.

I only need 5 to 8 or so.

Thats what I was thinking... would be hell of a lot easier. Would be nice if they gave some idea of the cascading effect.

The other major problem is that my uP will be only updating the IC's and there won't be enough time to do much else. I wonder if I can use some different method? I was thinking of having a serial-in/serial out just transfer the data to take over the job of the uP but it means I need an independent clock, multiplexer(for the rows), counter, etc for each IC. The uP is definitely easier and probably more cost effective from what I can see but means I'll need two.

What would have been nice if they had a 24xN memory so that you could easily use rows with them. That way I could clock in the data as slow as I want then have it run without much interaction(just supply a clock to have it step through the memory).

I think what I'm going to do and just pray it works is use two uP and wire up directly(cascading the data) and use termination. Hopefully that will work.

Sounds like a perfect excuse to use an I/O state machine (IOP) to do the updating. Kinda like an old CRT controller.