MathGroup Archive 2013

[Date Index] [Thread Index] [Author Index]

Search the Archive

Applying Mathematica to practical problems

  • To: mathgroup at
  • Subject: [mg130969] Applying Mathematica to practical problems
  • From: John Doty <noqsiaerospace at>
  • Date: Thu, 30 May 2013 06:15:25 -0400 (EDT)
  • Delivered-to:
  • Delivered-to:
  • Delivered-to:
  • Delivered-to:
  • References: <kmngb2$3rv$> <>

Changing the topic here.

On Tuesday, May 28, 2013 1:49:00 AM UTC-6, Richard Fateman wrote:

> Learning Mathematica (only) exposes a student to a singularly erroneous
> model of computation,

A personal, subjective judgement. However, I would agree that exposing the student to *any* single model of computation, to the exclusion of others, is destructive.

> Nice that you concede it is eccentric.

Concede? I praise its eccentricity! It takes me places other tools cannot easily go.

> Productive perhaps if you do not
> encounter a quirk.

There is no nontrivial quirk-free software.

> Especially a hidden quirk that gives the wrong
> answer but no warning.

Mathematica applied to real problems is pretty good here.

> And if you are not in a hurry for numerical
> results.

OK, let's consider how I use Mathematica in mixed-signal chip design. For my video chain chips, I start with two different approches in Mathematica. I have a nonlinear simulation environment that breaks the chip down into blocks, represented by functions, and composes a function representing the effect of a single clock step on the chip state from these functions. I iterate that function to "simulate". Some of the blocks are initially represented as Z transforms, so Mathematica's algebraic capabilities come in handy. The ease of partial evaluation helps with optimization: by evaluating as much of the function as possible before iterating it, special cases like consta nt inputs become very simple and fast.

I also have a Mathematica model that starts as symbolic Z and Fourier transforms, and models the chip as linear operators. For numerical results, these operators turn into matrices.

Once I've established the design parameters, I reduce the functional blocks to circuits and simulate with that fine Berkeley product, SPICE, the liguafranca of circuit simulation. You think Mathematica has problems? You've never used SPICE.

Linguistically, SPICE is an absolute mess. "Grammar" is utterly ad-hoc, and variable with dialect. "1N914B" is a perfectly good model name for a diode, but "2N2222A"  cannot be used to name a transistor model in some dialects. There are a couple of dozen different dialects around, most containing incompatible proprietary extensions.

For quirky unpredictability, SPICE is much, much worse than Mathematica. SPICE users get used to seeing spurious "trap oscillations", large amounts of energy appearing out of nowhere, and ridiculous time steps. Tuning the numerics to get sane results is an arcane art. As a programming language, SPICE is about as sophisticated as BASIC, but much less regular. Nevertheless, SPICE is very widely used and very productive. In the end, people find that it gets the job done (although many get rather exasperated in the process!.

But the big problem with SPICE isn't that it's quirky and error-prone, but that it buries the problem in (mostly irrelevant) detail. I'm simulating thousands of transistors, each with ~100 model parameters, with state changing on picosecond time scales. My SPICE chip simulations tend to run at a billion times slower than real time. Data output is voluminous and difficult to analyze (sometimes I read it into Mathematica for reduction). These problems limit the range of questions I can practically ask of SPICE.

On the other hand, the iterated function approach in Mathematica is 10,000-100,000 times faster than the SPICE approach, so it's a lot better for probing high-level behavior. The linear algebra approach in Mathematica   is even faster: bang a few matrices together and it tells me approximately what I'd get from averaging an unlimited number of simulation runs.

Because SPICE is so slow and detailed it's very difficult to use as a design tool, where the question is "I want this behavior, how do I get it?" It'sbetter for design verification: "I have this circuit, how will it behave?". The linear approach in Mathematica is the quickest for design optimization,  but of course it can't probe nonlinear phenomena in "large signal" cases. The iterated function approach in Mathematica is a good compromise to bridge the gap.

So, when I have two Mathematica models and a SPICE model that agree that the design will meet requirements, and agree with each other where their capabilities overlap, I release the design to the layout contractor. One result is another SPICE model, extracted from the silicon geometry, for verification. This model is extremely complex, with tens of thousands of "parasitic" resistors and capacitors, but I'll run a few test cases through it before releasing the design to the mask aggregator. So, before any silicon is patterned, I get four fairly independent looks at the design from different viewpoints through two radically different tools.

There are still many things that can go wrong before I have an actual chip powered up and processing video. Some of them involve other software, but they have nothing to do with Mathematica, so I won't go into them here.

The real world simply doesn't work the way you imagine in this case. The design process involves cross checks between multiple tools and models, so few design errors escape detection.  Furthermore, I haven't seen any errors attributable to the "quirks" of Mathematica in this process. I, of course, make and (hopefully) correct errors at a rapid pace. SPICE is rather treacherous. But correct and accurate calculation in Mathematica just isn't a problem in this engineering flow.

  • Prev by Date: Re: tossing a coin
  • Next by Date: Re: Help needed on how plot a stereographic projection
  • Previous by thread: Re: Warsaw Univ. course, was Re: Work on Basic Mathematica Stephen!
  • Next by thread: Re: Applying Mathematica to practical problems