STP24DP05

[Jon Slaughter]

http://www.st.com/stonline/products/literature/ds/14714.pdf

I would like to cascade several of these to reduce the comm. lines. What I
don't understand is on page 8 it says

"In order to achieve high cascade data transfer, please consider tr/tf
timings carefully."

and t_f/t_r is 5us!!

Now it says max but serious, what does this mean? If the clock edge takes
5us to rise and 5us to fall then there is no one one can achieve any
significant data rate. I'm just not understanding this parameter and I guess
i'm confusing it with t_ON and t_OFF but what exactly does it mean?

 

[[email protected]]

http://www.st.com/stonline/products/literature/ds/14714.pdf

I would like to cascade several of these to reduce the comm. lines. What I
don't understand is on page 8 it says

"In order to achieve high cascade data transfer, please consider tr/tf
timings carefully."

and t_f/t_r is 5us!!

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

Now it says max but serious, what does this mean? If the clock edge takes
5us to rise and 5us to fall then there is no one one can achieve any
significant data rate. I'm just not understanding this parameter and I guess
i'm confusing it with t_ON and t_OFF but what exactly does it mean?

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?

 

[[email protected]]

http://www.st.com/stonline/products/literature/ds/14714.pdf

I would like to cascade several of these to reduce the comm. lines. What I
don't understand is on page 8 it says

"In order to achieve high cascade data transfer, please consider tr/tf
timings carefully."

and t_f/t_r is 5us!!

Now it says max but serious, what does this mean? If the clock edge takes
5us to rise and 5us to fall then there is no one one can achieve any
significant data rate. I'm just not understanding this parameter and I guess
i'm confusing it with t_ON and t_OFF but what exactly does it mean?

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.

 

[Jamie]

http://www.st.com/stonline/products/literature/ds/14714.pdf

I would like to cascade several of these to reduce the comm. lines. What I
don't understand is on page 8 it says

"In order to achieve high cascade data transfer, please consider tr/tf
timings carefully."

and t_f/t_r is 5us!!

Now it says max but serious, what does this mean? If the clock edge takes
5us to rise and 5us to fall then there is no one one can achieve any
significant data rate. I'm just not understanding this parameter and I guess
i'm confusing it with t_ON and t_OFF but what exactly does it mean?

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..

http://webpages.charter.net/jamie_5"

 

[Jon Slaughter]

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.

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

 

[Jon Slaughter]

http://www.st.com/stonline/products/literature/ds/14714.pdf

I would like to cascade several of these to reduce the comm. lines. What I
don't understand is on page 8 it says

"In order to achieve high cascade data transfer, please consider tr/tf
timings carefully."

and t_f/t_r is 5us!!

Now it says max but serious, what does this mean? If the clock edge takes
5us to rise and 5us to fall then there is no one one can achieve any
significant data rate. I'm just not understanding this parameter and I
guess i'm confusing it with t_ON and t_OFF but what exactly does it mean?

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.

 

[nospam]

You must ABSOLUTELY use a clock distribution chip with proper termination on
each clock line.

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.
--

 

[Jon Slaughter]

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.

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.

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.

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?

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.

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).

 

[Jon Slaughter]

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.

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)

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.

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).

 

[Jon Slaughter]

[snip]

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.

[snip]

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.

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).

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.

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

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).

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.

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.

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.

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).

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)

 

[nospam]

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 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.
--

 

[Jon Slaughter]

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?

I only need 5 to 8 or so.

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.

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.

 

[JosephKK]

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).

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