Switched-cap filters: Fallen from grace?

[John Larkin]

Certain DC/DC designs lend themselves to be used with external clocks,
but the issue in not limited to switching supplies. Power supplies are
never perfect zero-ohm sources, so their will be noise on them just
from the circuit operation. Say the circuit works on band splitting
audio, as in the simpler modem designs. Then the transmit channel
circuitry will be generating noise right where the receive filter is
trying to elliminate it. If the PSSR of the receive filter in the
region of the transmit spectrum is poor, you may have a situation where
the PSSR related noise is worse than what gets past the filter.

I've seen SCF designs with gain from the power suppies if measured at
center frequency of a high Q resonator.

I did a dual-conversion superhet FSK modem full of cmos logic, a uP,
and a mess of MF10's, the original old nasty metal-gate version. The
first board worked, but s/n was awful on some channels, as the sc
filters aliased anything they could find back into my signal range. In
a double superhet, there were lots of opportunitities. With some added
rc's in the power lines, it worked fine, although the s/n still wasn't
anything to brag about.

John

 

[Joerg]

Hello John,

Imagine analog design evolving to programming chips in the analog
equivalent of VHDL.

< Gasp! >


It could happen, and in a way it already did for Jim and other chip
designers.

Not VHDL but when I was young I thought SPICE was for sissies. Until the
day when a new client popped up. They had weird field failures on a
pulser/receiver front end. Even the fastest scope I could muster would
show nothing, nada. So I plugged it into PSpice, the old fashioned way
via a text listing. And then, bingo, a wee but steep surge into one of
the T/R switch diodes popped up and that was the one that kept frying.
Corrected it and the field failures went away. The boss was quite
stunned. "You mean, you found that on a computer?"

PSoCs still have to come a long way. Every time I looked I was not
enthused about what's on the menu. Sure, it's buffet style. But no filet
mignon and caviar. So far it had always been cheaper to do it in discretes.

 

[Jim Thompson]

Hello John,


< Gasp! >


It could happen, and in a way it already did for Jim and other chip
designers.

It really hasn't been much of a threat so far.

Not VHDL but when I was young I thought SPICE was for sissies. Until the
day when a new client popped up. They had weird field failures on a
pulser/receiver front end. Even the fastest scope I could muster would
show nothing, nada. So I plugged it into PSpice, the old fashioned way
via a text listing. And then, bingo, a wee but steep surge into one of
the T/R switch diodes popped up and that was the one that kept frying.
Corrected it and the field failures went away. The boss was quite
stunned. "You mean, you found that on a computer?"

PSoCs still have to come a long way. Every time I looked I was not
enthused about what's on the menu. Sure, it's buffet style. But no filet
mignon and caviar. So far it had always been cheaper to do it in discretes.

But _better_ as ASIC's ;-)

...Jim Thompson

 

[Joerg]

Hello Jim,

But _better_ as ASIC's ;-)

Oh, often I'd love to switch a design to ASIC but the cost hurdle has
become quite prohibitive. All that needs to be not only fielded up front
but also amortized over the product life. That's why many of them have
remained discrete.

I wish us analog guys would have the resources that digital folks are
pampered with. Like those huge Virtex FPGAs (drool...). But whenever I
looked at analog programmables I couldn't resist the urge to yawn. Some
of the opamps on "mixed mode uC" made the old uA709 look like a rocket.
Hans Camenzind's arrays were a good idea but they don't look favorable
for low power designs. And most of mine are these days.

 

[Ken Smith]

Why do we still use schematics to design PC boards? When I tell people
that I use schematics to design logic, they think I'm a dinosaur.

I make it a point not to tell them and they still think I'm a dinosaur.

Schematics are sort of an analog thing. Symbolic descriptions seem to be
more digital. When you are thinking in analog mode, a schematic seems a
more natural way to express the design.

Some digital stuff is easier to think of as a schematic. Logic equations
work better in other cases.

 

[Ken Smith]

It demands on the complexity. VHDL has some quite nice properties
on large projects. Verbose, certainly. ...and by design. Ten
years ago I was a schematic hold-out. I rather like VHDL now, at
least for the guts.

I'd like VHDL a lot better if they'd left most of the sugar out of the
syntax or at least made it so that the "is" etc was optional.

I think, they would have been better off to make the "ABC -> DEF," call
syntax the only one. It is all I ever use. A "#include" would also be
handy.

 

[Keith]

I'd like VHDL a lot better if they'd left most of the sugar out of the
syntax or at least made it so that the "is" etc was optional.

True enough, though "is" is optional in some places, at least in
VHDL '93. This leads to the obvious problem, "where is "is"
optional". ;-)

I think, they would have been better off to make the "ABC -> DEF," call
syntax the only one.

Not sure what you mean. Ordered list or enumerated list? I never
use ordered.

It is all I ever use. A "#include" would also be handy.

It's there, but invisible. Stick it in a library. BTW, I find
them awkward too. It's hard to track down where something is.

VHDL has lots of power (GENERATE is awesome) and some real
strangeness (text handling). I'd also like a bit more flexibility
in the CASE/WHEN construct (more on the order of PL/I's
SELECT/WHEN).

 

[Joel Kolstad]

True enough, though "is" is optional in some places, at least in
VHDL '93. This leads to the obvious problem, "where is "is"
optional". ;-)

That depends on what the meaning of term "is" is, no?

 

[John Woodgate]

I make it a point not to tell them and they still think I'm a dinosaur.

Could it be the three-toed claws and the spiked tail? (;-)

 

[Ken Smith]

says... [...]

I think, they would have been better off to make the "ABC -> DEF," call
syntax the only one.

Not sure what you mean. Ordered list or enumerated list? I never
use ordered.

I think the typo didn't help. Like this:

foo: BarConnect port map (clk => SysClk, -- comment bla bal
Data => DataIn, -- yack yack
Result => DataOut); -- mumble mumble

It's there, but invisible. Stick it in a library. BTW, I find
them awkward too. It's hard to track down where something is.

Yes, that is how I do it but adding a library adds a step. You have to
compile the library and then the project that uses it. Although a "make"
automates this, sometimes it would just be easier if all the stuff was in
one file.

[....]

VHDL has lots of power (GENERATE is awesome)

I ended up writing a Pascal program that generated part of the VHDL in a
project. Perhaps I could have done it in "generate" form but I couldn't
figure out how to least squares fit etc in the genrates.

and some real
strangeness (text handling). I'd also like a bit more flexibility
in the CASE/WHEN construct (more on the order of PL/I's
SELECT/WHEN).

One that was a little more tuned to doing state machines would be nice.
As it is I've usually ended up with two hunks for statemachines. One part
controls the changing of the state and the other generates the outputs
based on the state. Since I'm doing CPLDs, I don't use a "one hot"
statemachine.

 

[Ken Smith]

Could it be the three-toed claws and the spiked tail? (;-)

Come to think of it ......

 

[Keith]

That depends on what the meaning of term "is" is, no?

Certainly. ;-)

 

[Keith]

says... [...]

I think, they would have been better off to make the "ABC -> DEF," call
syntax the only one.

Not sure what you mean. Ordered list or enumerated list? I never
use ordered.

I think the typo didn't help. Like this:

foo: BarConnect port map (clk => SysClk, -- comment bla bal
Data => DataIn, -- yack yack
Result => DataOut); -- mumble mumble

Yes, that's what I thought you meant. Though the ordered list is
useful for small blocks, like gates:

Foo: NAND2 port map (A, B, Out);

Yes, that is how I do it but adding a library adds a step. You have to
compile the library and then the project that uses it. Although a "make"
automates this, sometimes it would just be easier if all the stuff was in
one file.

Make is a wonderful tool. Though I only use libraries for small
widgets that are called many times and my "toolboxes". They don't
get recompiled very often. It gets too hard to find complex logic
squirreled away in libraries.

[....]

VHDL has lots of power (GENERATE is awesome)

I ended up writing a Pascal program that generated part of the VHDL in a
project. Perhaps I could have done it in "generate" form but I couldn't
figure out how to least squares fit etc in the genrates.

Hmm, I wouldn't have thought of doing a least-squares hardware.
Can you give the context?

One that was a little more tuned to doing state machines would be nice.
As it is I've usually ended up with two hunks for statemachines. One part
controls the changing of the state and the other generates the outputs
based on the state. Since I'm doing CPLDs, I don't use a "one hot"
statemachine.

I do state machines in one procedure. Each WHEN Is a state an in
the when clause is the logic to go to the next state. The state
variable is an enumerated type and an attribute is used to instruct
the synthesizer how to build the state machine (one-hot, binary,
gray...). My procedures tend to look all alike too, with only a
clock and reset (synchronous or asynchronous) in the sensitivity
list. FPGAs are latch rich, so everything tends to end up
synchronous.

The reason I like the PL/I style SELECT/WHEN is that I don't need
to specify a single variable to do the selection. PL/I allows
something like (forget the syntax):

SELECT
WHEN A = 1
yadda
WHEN A = 2
yadda
WHEN B = C
...
OTHERWISE
END SELECT

In addition to (forget the syntax here too):

SELECT A
WHEN 1
yadda
WHEN 2
yadda
WHEN 3
...
END SELECT