Switched-cap filters: Fallen from grace?

Hello John,

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.

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

But _better_ as ASIC's ;-)

...Jim Thompson

Hello Jim,

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.

In article , John Larkin wrote: [....]

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.

In article , krw wrote: [....]

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.

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

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

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

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

In message , dated Wed, 23 Aug 2006, Ken Smith writes

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

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

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.

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.

Come to think of it ......

Certainly. ;-)

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

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.

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

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