logic specs

e:

nsen

rkin:

or fall

op delays

ily parts

s factors that play into rise time, you clearly aren't qualified to use dig ital chips in analog circuits.

on

d in many, many posts. So would you be happy with a spec of 0.2 to 1.2 ns for a rise time spec? But then that would only apply for the specified loa d and likely for a specified Vcc and temperature. I suppose they could spe cify the rise time over process *and* Vcc *and* temperature, but who would need that info? The world should specify for digital chips parameters that the digital world doesn't need?

is at least as long as you paid for. He isn't going to send it to NIST to have it measured for you.

any changes are made to the process for these chips. Your measurement will be valid at one temperature, one Vcc and very likely only for one manufact urer of the device.

ot being done by the manufacturer. If you are going to complain that an ai r pump isn't well specified for pumping water perhaps you should take it to the Chaplain.

ing digital circuits which the part you are looking at is.

You still can't get the concept can you? You don't need a data sheet to te ll you a range of rise times because that is overly simplistic. If you rea lly need the info, you need a model, not a number.

round you and the 50 parts you might order for this project.

I have millions of parts in stock. My stock room is in Thief River Falls, Minnesota. I would be very foolish to want to build my own stock room.

Not much in a while... well a test fixture was the last thing. I think I w ill be working on my third million in profit from it later this year.

any changes are made to the process for these chips. Your measurement will be valid at one temperature, one Vcc and very likely only for one manufact urer of the device.

eed.

Which other people seem to be able to deal with. How do you tame fast edge s?

ns?

Good for you. I hope you do well with your attitude that nearly every digi tal device manufacturer does a lousy job and that designers can't design.

:)

Rick C.

We have a giant Universal dual-head pick-and-place. We buy parts by the reel, usually 3000 pieces. If we run 100 boards, there will be many (actually, all) reels partially used. Should we throw those partly filled reels away, and order a whole new set from Digikey when we want to make another run?

If we do keep partial reels, what should we call the place where we store them?

Will Digikey always deliver *all* of the parts that we need in time to do the run?

Parts keep getting faster, and are often a lot faster than one might suspect from data sheets and app notes. A 3" PC trace can become a signal integrity hazard.

I tested a 16 cent Tiny flipflop yesterday for a DC parameter, and checked at the edge speeds just for fun.

If you ever do design a digital PC board again, you should maybe worry about edge speeds. It's annoying, for example, to have an FPGA that configures some of the time.

As I've mentioned before:

You can get about 250ps from LVC.

Here is a video of a 74LVC04AD that I dead-bugged on a board, in this case the chip was an old one from Philips, now NXP. Unfortunately eevblog tested it with a lower freqency than I had intended, and so the on-board decoupling did not have enough capacitance at the lower frequency and there is quite a bit of ringing on the supply. The low-portion of the waveform looks much nicer because the positive supply ringing has less effect when the nmos fets are pulling the output down to ground. I think he also removed my ac-coupling and back termination on the output, but you can see that the edge itself has about 250ps rise time, even using whatever BNC adapters he used.

That guy is *so* annoying.

TI has the 244 in both LVC and ALVC; I'll get some and try them. Of course, there are no risetime specs. Both are 4.6 volts abs max. Or maybe 6.5. Depends on where you look. I suppose I can test that, too.

rote:

stensen

Larkin:

ise or fall

prop delays

family parts

ious factors that play into rise time, you clearly aren't qualified to use digital chips in analog circuits.

ff.

ime.

ht on

ated in many, many posts. So would you be happy with a spec of 0.2 to 1.2 ns for a rise time spec? But then that would only apply for the specified load and likely for a specified Vcc and temperature. I suppose they could specify the rise time over process *and* Vcc *and* temperature, but who wou ld need that info? The world should specify for digital chips parameters t hat the digital world doesn't need?

ing is at least as long as you paid for. He isn't going to send it to NIST to have it measured for you.

if any changes are made to the process for these chips. Your measurement w ill be valid at one temperature, one Vcc and very likely only for one manuf acturer of the device.

t not being done by the manufacturer. If you are going to complain that an air pump isn't well specified for pumping water perhaps you should take it to the Chaplain.

igning digital circuits which the part you are looking at is.

tell you a range of rise times because that is overly simplistic. If you really need the info, you need a model, not a number.

e around you and the 50 parts you might order for this project.

s, Minnesota. I would be very foolish to want to build my own stock room.

Sure, it can make sense to inventory the few long lead items you might need for a job, but inventorying everything ties up capital and costs money for the space.

le

rce

and

ce

I will be working on my third million in profit from it later this year.

Really? How many SPI ports have you seen with sub nanosecond rise times th at you would have never suspected?

But you were talking about SPI ports a few messages ago. Now you are picki ng fast parts and saying they are fast. Well, yeah, they are.

Lol, if you can't design an FPGA configuration circuit you are in bad shape .

I don't actually have that problem, my FPGAs are all flash based. :)

Rick C.

Not many lately, because we are very careful about SPI use. We had a horrible problem last year with the AD7793, which is very picky about the SPI timing and has a horribly brain-damaged internal architrcture. We spun a couple of boards to use the TI ADS1247, which works fine.

Analog Devices doesn't do the best digital sections of their mixed-signal parts. Kind of chaotic.

uP and FPGA regular i/o port pins now often have sub-ns edge speeds. Sometimes you can tune drive strength and speed, sometimes you can't. If you are running more than a few inches of trace, signal integrity analysis is mandatory nowadays; not just impedances and terminations, but crosstalk too.

If you buffer stuff like SPI cs and clock, it's prudent to understand the buffer chips too. We recheck that stuff at our PCB Design Review, post-layout, and often have to tweak.

We've had a couple of cases where FPGAs didn't configure reliably. We learned, and now we don't have that problem any more.

You sure have a lot of expert opinions about stuff that you never do.

As a rule of thumb, any line longer than 1/10 wavelength should be treated as a transmission line. For that distance that would translate to 300 MHz (considering velocity factor) and to 1 ns ris/fall time.

A microstrip is a convenient transmission line structure, i.e. a constant width track over a continuous ground plane. Just adjust the track width to get the desired transmission line impedance by considering the distance to the ground plane and the dielectric constant of the PCB material used.

ote:

hristensen

ohn Larkin:

t rise or fall

pec prop delays

me-family parts

various factors that play into rise time, you clearly aren't qualified to u se digital chips in analog circuits.

stuff.

e time.

right on

dicated in many, many posts. So would you be happy with a spec of 0.2 to 1 .2 ns for a rise time spec? But then that would only apply for the specifi ed load and likely for a specified Vcc and temperature. I suppose they cou ld specify the rise time over process *and* Vcc *and* temperature, but who would need that info? The world should specify for digital chips parameter s that the digital world doesn't need?

ing?

string is at least as long as you paid for. He isn't going to send it to N IST to have it measured for you.

ge if any changes are made to the process for these chips. Your measuremen t will be valid at one temperature, one Vcc and very likely only for one ma nufacturer of the device.

t it not being done by the manufacturer. If you are going to complain that an air pump isn't well specified for pumping water perhaps you should take it to the Chaplain.

be

designing digital circuits which the part you are looking at is.

to tell you a range of rise times because that is overly simplistic. If y ou really need the info, you need a model, not a number.

olve around you and the 50 parts you might order for this project.

alls, Minnesota. I would be very foolish to want to build my own stock roo m.

eed for a job, but inventorying everything ties up capital and costs money for the space.

tiple

uper

is

rt

source

y" and

ource

nk I will be working on my third million in profit from it later this year.

that you would have never suspected?

But you don't seem to be saying the SPI port had problems with rise time. I recall this was a logical issue where it was hard to know what state the SPI port was in at any given time. You never really tracked the problem do wn to a cause, you just got rid of the offending part. So why are you tell ing us about it in a conversation about signal rise time?

cking fast parts and saying they are fast. Well, yeah, they are.

Understanding is always better than ignorance, yes. You seem to be on both sides of that fence. Sometimes you claim you need data they don't publish . Other times you just wing it and hope it works. Oh well, to each his ow n. I guess I've never been bitten by SI issues. I've found it easy to pre dict where the SI problems are likely.

ape.

Did I say "never"? I was working for a defense contractor who used a lot o f Xilinx parts. The software people (they put FPGA design in the software section) couldn't get the FPGA to configure. They had some five people wor king on it including a manager. My manager impressed me to help them out. When I got there I had to get everyone to stop what they were doing and ex plain to me what they had done and how they were doing it. I told them the few simple things required to configure an FPGA and made sure they were do ing all of them at the same time, voila, it configured. I walked away with them all amazed. Pretty silly I know. Every time they tried it they left out one thing or another.

I have done designs with X and A and L and even ATT FPGAs. Now I don't bot her with the PITA devices. I just use parts that work. :) I seem to reca ll you had no end of trouble with some of your Xilinx parts. They make goo d parts (most of the time) but their software sucks. Given that designing with FPGAs is more software than hardware, it makes sense to pick device th at are easy to work with, not devices that make your life hard.

Rick C.

A more appropriate differentiator is "a length greater than 1/2 rise-time". 3" is on the short side for a 1ns rise time.

Microstrip is intrinsically dispersive. Buried strip-lines aren't.

I've never worked on a projects where this was an issue, but I have worked on projects where I couldn't make buried trace narrow enough to give me a characteristic impedance much higher than 50R. 75R was an impossible dream.

Where did you get that .3", while the OP was talking about 3" or 75 mm. Anyway, the signal propagates about 200 mm during a 1 ns rise time on typical PCB transmission lines, so half of that is 100 mm, quite close to 75 mm as the rule of thumb.

This is a discussion group, and people discuss things. You seem to not discuss things, and get mad when people do.

The AD7793 digital interface is electrically fragile; SPI messes up erratically, and even touching the clock line with a scope probe can change things. We never figured out why. Since dropping CS does *not* reset the internal bit counter, one SPI clock glitch hoses the chip thereafter.

You like to whine; I like to design.

Using ROTs are not a safe way to design. We calculate, simulate, and experiment.

I use LT Spice to sim terminated PCB traces, and that works well. I can estimate overshoot or drool and decide what looks good. If you have enough drive strength available, a source termination that makes a little overshoot is about right.

A multilayer board can have a long single-ended clock trace that threads through layers with vias, a mix of microstrip and symmetric or asymmetric stripline, "referenced to" ground planes and power pours or maybe other signal layers. Hazards are very real and rules of thumb get scary.

. I recall this was a logical issue where it was hard to know what state t he SPI port was in at any given time. You never really tracked the problem down to a cause, you just got rid of the offending part. So why are you t elling us about it in a conversation about signal rise time?

So why did you stop discussing and start complaining? I'm just asking you to talk about the topic at hand rather than continually changing the topic. You complained that YOU need rise time specs in digital chip data sheets. You justify that on the fact that clock lines like the CS in SPI designs needs to branch out which is hard to route as a clock line. I asked about real world situations where you traced a problem to the SPI port rise time making the CS line hard to route. You respond with an unrelated anecdote a bout an SPI part you couldn't figure out how to use with no indication it h ad anything to do with rise times.

No one is mad except maybe you. Do you want to have a discussion or not? If not, why do you keep replying?

You "never figured out why"... I guess that is a good basis for drawing any conclusion you wish. Nothing else in the paragraph is supported.

You seem to be the one whining now. If you don't want to discuss the issue of rise time, then please don't bother whining about all your unrelated de sign failures.

Rick C.

Electronics continually changes the topic for you, if you actually design electronics.

On a complex PC board, thousands of things can go wrong. Some can and should be anticipated, but weird chip behavior sometimes can't be. Every data sheet should have a CONFESSIONS section with a big black border. Someone with time on their hands could get a lot of web traffic with a site that collects and publishes IC bugs.

The TI part works great.

I guess I should ask you the same thing? Where did you get '.3"'? (Hint: the '.' belongs with the previous sentence and there are two spaces before the 3)

But the rise time matters, not the fundamental frequency.

I think that the Errata for some PIC microcontrollers should have been called "List of Lies in the Datasheet" when it is things like FLASH endurance that is 10x lower than the datasheet spec, and it has stayed that way over multiple all-layer silicon revisions (meaning they have no plan to fix it) and multiple revisions of the datasheet (meaning they are in no hurry to admit that they won't ever fix it).

There are lots of five or 10-year old data sheets, for still active parts, that have obvious mistakes. And chips with horrible flaws that aren't getting documented or fixed.

It's insane for hundreds of users to individually discover the same chip bug.

The replacement of actual product support with user forums is sad. It may be a consequence of a shortage of support people, who get better jobs elsewhere; I notice that the good ones move on soon. But at least the forums posts make the bugs publicly visible. (Assuming they are allowed up!)

ime. I recall this was a logical issue where it was hard to know what stat e the SPI port was in at any given time. You never really tracked the prob lem down to a cause, you just got rid of the offending part. So why are yo u telling us about it in a conversation about signal rise time?

ou to talk about the topic at hand rather than continually changing the top ic.

Actually I find designing electronics requires focus and dealing with an is sue until it is completed. You seem to want to wander all over the place, but I guess that is mostly because you just don't want to discuss a topic y ou don't really understand.

ts. You justify that on the fact that clock lines like the CS in SPI desig ns needs to branch out which is hard to route as a clock line. I asked abo ut real world situations where you traced a problem to the SPI port rise ti me making the CS line hard to route. You respond with an unrelated anecdot e about an SPI part you couldn't figure out how to use with no indication i t had anything to do with rise times.

? If not, why do you keep replying?

any conclusion you wish. Nothing else in the paragraph is supported.

sue of rise time, then please don't bother whining about all your unrelated design failures.

Yes, an inability to discuss the issue of rise time on SPI signals. I can see why your SPI designs fail to work. Total lack of focus.

Rick C.