EmbeddedRelated.com
Forums
Memfault Beyond the Launch

74LVT transition times: How low can you go?

Started by Joerg February 28, 2007

Joerg wrote:


> Cannot post a schematic from this computer but it's simple: Imagine an > RC with the R in series and a cap to ground. That creates a delay.
> Vladimir: I did not call shamans before releasing this stuff because I > am a Lutheran :-)))
I see. You want to be more holy than a Pope, Larkin and Rickman altogether, that is what this circuit for :))) VLV
Jim Granville wrote:

> Joerg wrote: > <snip> > >> Not really, unless I use a CPLD here which I don't want to. These >> board should not contain any programmables. > > > Care to elaborate why ? >
Programming is a hassle, we want to be able to just populate the boards, test and plug them in.
>> There are SPI devices and these only have one enable, not /OE plus >> /CE. BTW they use various names for that pin. Even within the same >> company (Analog Devices) it's called /SYNC on the DACs I am using and >> /CS on the ADC. >> >> On SPI the MISO line should be coming off tri-state a bit delayed to >> make sure the others have definitely let go of it. > > > In these situations (hand-over uncertainty), I've also seen simple > series resistors used. They keep the currents to safe levels, and > permit some latency tolerance, and normally the time frames are > short. >
We could do that but there'll be a whole lot of boards in the unit and thus a pretty large backplane that needs to be driven. Plus the digital designer for the other stuff really would like Thevenin. But with Schmitt inputs it'll be ok. -- Regards, Joerg http://www.analogconsultants.com
rickman wrote:

> On Mar 2, 1:23 pm, Joerg <notthisjoerg...@removethispacbell.net> > wrote: > >>Not really, unless I use a CPLD here which I don't want to. These board >>should not contain any programmables. There are SPI devices and these >>only have one enable, not /OE plus /CE. BTW they use various names for >>that pin. Even within the same company (Analog Devices) it's called >>/SYNC on the DACs I am using and /CS on the ADC. > > > Now this is beginning to make some sense. > > > >>On SPI the MISO line should be coming off tri-state a bit delayed to >>make sure the others have definitely let go of it. > > > Regardless of the name, all you need to do to prevent contention is > for the controller to delay enabling the next device for a period > after it disables the last device. Why is the controller not handing > this? That would be the "correct" digital approach to dealing with > this problem. >
Well, we opted for a bare bones bus where the adresses do that :-)
> > >>Cannot post a schematic from this computer but it's simple: Imagine an >>RC with the R in series and a cap to ground. That creates a delay. Now >>place a series combo of another R and a diode across the resistor and >>the delay becomes shorter in one direction. That's basically it. When >>you have Schmitts and fulfill the logic swing thresholds the diode is >>ok. For really low voltage logic you can use a BAT54 but at 3.3V a >>regular one is usually fine. I never shied away from combining analog >>and logic. Built switcher supplies and what not around these. > > > The reason to be careful combining digital and analog in these ways is > because of how the digital thresholds vary over temperature, voltage > and process. You can model, test and analyze, but you still need to > allow plenty of margin for things you don't easily control such as > process variation and noise. >
That's why I like Schmitts. Unless I want to use an logic inverter as a linear amp...
> Heck, I saw a circuit that simply used a FET to control the current > through an LED. But the transfer characteristics of the FET are not > well controlled. After two years of use in a design they tweeked > their process and the circuit stopped working due to the rise in > threshold voltage. Not a lot, just enough to make the LEDs too dim to > really see. >
Thou shalt not go by the typical Rdson versus Vgs graph but always by the guaranteed values. -- Regards, Joerg http://www.analogconsultants.com
John Larkin wrote:

> On Fri, 02 Mar 2007 18:23:20 GMT, Joerg > <notthisjoergsch@removethispacbell.net> wrote: > > >>rickman wrote: >> >> >>>On Mar 1, 1:08 pm, Joerg <notthisjoerg...@removethispacbell.net> >>>wrote: >>> >>> >>>>Vladimir Vassilevsky wrote: >>>> >>>> >>>> >>>>>Joerg wrote: >>>> >>>>>>In an embedded application I need to slow down the /OE of a 74LVT244 >>>>>>so it turns tri-state fast but goes onto the bus slower, to avoid a >>>>>>brief contention when addresses change. Is it ok for that family to >>>>>>slow /OE by 200nsec or so via RC? It'll be the usual two resistor, one >>>>>>diode and one cap deal. Want to avoid adding another Schmitt here. >>>> >>>>>You can make a delay using something like 1G97. >>>> >>>>I could also do it with a 74HC14 but I wanted to avoid more chips. >>>> >>>> >>>> >>>>>But the 200ns seems like an awful long time. Why would you need that? >>>> >>>>I might get away with 100nsec. There is going to be some intricate >>>>address decoding, more than just a 688 and a 154. >>> >>> >>>To the OP, if you need 100 ns of delay to make your timing come out, >>>there may be a problem with the design. I am sure you know what you >>>are doing, but typically the /OE is used on all bus devices as the >>>timing control and the /CE is used for selection. Most devices >>>generate the /OE with enough timing margin relative to the address and >>>any CPU generated /CE controls that you shouldn't need to delay /OE. >>>You say your address decoding is very complex, is this what the /OE >>>delay is needed to compensate for? Is there a way to speed up the >>>address decode? >>> >> >>Not really, unless I use a CPLD here which I don't want to. These board >>should not contain any programmables. There are SPI devices and these >>only have one enable, not /OE plus /CE. BTW they use various names for >>that pin. Even within the same company (Analog Devices) it's called >>/SYNC on the DACs I am using and /CS on the ADC. >> >>On SPI the MISO line should be coming off tri-state a bit delayed to >>make sure the others have definitely let go of it. > > > > Why bother? A little transient bus contention never hurt anybody. >
But when that lets off a wee EMI birdie the Federales might be swooping down on ya some day ;-) Seriously, this gear is used in medical settings and there everything needs to be nice, quiet and class B or better. -- Regards, Joerg http://www.analogconsultants.com
Vladimir Vassilevsky wrote:

> > > Joerg wrote: > > >> Cannot post a schematic from this computer but it's simple: Imagine an >> RC with the R in series and a cap to ground. That creates a delay. > > >> Vladimir: I did not call shamans before releasing this stuff because I >> am a Lutheran :-))) > > > I see. You want to be more holy than a Pope, Larkin and Rickman > altogether, that is what this circuit for :))) >
"Holier than thou" is just what our pastor keeps hammering into us not to ever think, pretend or live ;-) -- Regards, Joerg http://www.analogconsultants.com
>Regardless of the name, all you need to do to prevent contention is >for the controller to delay enabling the next device for a period >after it disables the last device. Why is the controller not handing >this? That would be the "correct" digital approach to dealing with >this problem.
I know of several clean solutions. The simplest is to leave a dead cycle between enables. That has the obbvious drawback of wasting a lot of time on the bus. Another approach is to only enable the drivers for the last 1/2 or 3/4 of each cycle. This can be free if you are using something like a '138 to select which chip drives the bus since it has an enable pin where you can connect the clock. Sometimes you can add a gate delay - that is delay the enable until the previous enable is off in such a way that it takes one level of logic. This may be easier if you are already using a PAL. Another approach is to just ignore the problem. I'm pretty sure I've seen an app-note someplace that says the turn off is faster than the turn on just for this reason. That only work if you are using the same logic family for all your bus drivers, and maybe you need same voltage/temp too. A test card and some time in the lab might be worthwhile. It's probably a lot more reasonable to ignore the contention if you are using the chips with the built in series damping resistors. They will limit any current spikes. -- These are my opinions, not necessarily my employer's. I hate spam.
Hal Murray wrote:

>>Regardless of the name, all you need to do to prevent contention is >>for the controller to delay enabling the next device for a period >>after it disables the last device. Why is the controller not handing >>this? That would be the "correct" digital approach to dealing with >>this problem. > > > I know of several clean solutions. > > The simplest is to leave a dead cycle between enables. That has > the obbvious drawback of wasting a lot of time on the bus. > > Another approach is to only enable the drivers for the last 1/2 or 3/4 > of each cycle. This can be free if you are using something like > a '138 to select which chip drives the bus since it has an enable > pin where you can connect the clock. > > Sometimes you can add a gate delay - that is delay the enable > until the previous enable is off in such a way that it takes > one level of logic. This may be easier if you are already using > a PAL. > > Another approach is to just ignore the problem. I'm pretty sure > I've seen an app-note someplace that says the turn off is faster > than the turn on just for this reason. That only work if you are > using the same logic family for all your bus drivers, and maybe > you need same voltage/temp too. A test card and some time in > the lab might be worthwhile. > > It's probably a lot more reasonable to ignore the contention if > you are using the chips with the built in series damping resistors. > They will limit any current spikes. >
Ignoring can come with penalties. I am often called out to clients after they failed at the EMC lab. Wish they'd call me before but it's like at the dentist, most of us go there after the pain has become unbearable or a molar just broke (had that happen last week). Anyhow, I have found "innocent" bus contentions to be the root cause of such failures more than once. -- Regards, Joerg http://www.analogconsultants.com
Joerg wrote:
> "Holier than thou" is just what our pastor keeps hammering into us not > to ever think, pretend or live ;-)
And yet you believe him, thus accepting he's holier than you. "Sans dieu, sans maitre". Be your own arbiter, think your own thoughts.
Clifford Heath wrote:

> Joerg wrote: > >> "Holier than thou" is just what our pastor keeps hammering into us not >> to ever think, pretend or live ;-) > > > And yet you believe him, thus accepting he's holier than you. >
No, I believe in God.
> "Sans dieu, sans maitre". Be your own arbiter, think your own thoughts.
Own thoughts, yes. Own arbiter, that don't work IMHO. -- Regards, Joerg http://www.analogconsultants.com
CBFalconer wrote:
> Jim Granville wrote: > > ... snip ... > >>The other issue that can bite, is transistion oscillation. >>Without a Schmitt, if you scoped the output at the 4mA peak, >>you will see what I mean. That can cause real problems with >>downstream devices - I've seen even unrelated pin drive have >>edge-oscillation effects that needed external remedies. > > > Actually a Schmidt trigger input can make things worse. Without > it, a single CMOS inverter using a Vcc that allows a linear input > bias can stabilize using just a large resistor from output to > input. With it, the input voltage must be some sort of sawtooth, > depending on the innate input capacitance. The half period will be > the time needed for the input to rise (or fall) the hysteresis > voltage.
You've lost me here. I'm talking about unwanted transistion oscillation, which can be in the 100's of MHz region in modern devices. There is no feedback resistor, and a Schmitt IP does not make transistion oscillation worse, it removes it. I think you are thinking of RC oscillators, or even Crystal oscillators ( using unbuffered gates, HCU04 type) which are about the only place you'd try and do linear feedback, without real care. -jg

Memfault Beyond the Launch