Subject: Re: VHDL-AMS Subset for Real-Time (VHDL-AMS-RT)
From: Joe Gwinn (gwinn@res.ray.com)
Date: Tue Nov 30 1999 - 08:44:02 PST
Comments interspersed below.
In the original, as received, there were lots of symbols that came out
strange, such as "VHDL‚AMS" below, where it appears that a not-equal symbol
is between VHDL and AMS. Likewise "non‚linear". In emails, the first
seven-bit ISO Roman alphabet is the most robust. I would assume that these
strange characters look OK in a German alphabet.
At 10:35 AM 99/11/26, Eduard Moser wrote:
>
>Dear 1076.1 Working Group member,
>
>including you find a first Draft of the White Paper on
>
> "VHDL-AMS Subset for Real-Time".
>
>The contents was presented and discussed during the WG-Meeting at
>FDL'99. This first draft should start a fruitful discussion on the
>issue.
>========================================================================
>Draft of White Paper on VHDL‚AMS Subset for REAL‚TIME
>Eduard Moser, Robert Bosch GmbH, moser@fli.sh.bosch.de
>========================================================================
[snip]
>0.1 General Approach
>
>The basic concept is Block Diagram modelling according to [1, 136ff].
>Each component can be described as a block whose behaviour can be
>expressed by the following equations:
>
>x'dot = f(x, u, t)
>y = g(x, u, t)
>
>(with input vector u, output vector y, state vector x, and time t). The
>functions f and g may be non‚linear and discontinuous.
This simplification is OK if and only if the chosen block diagram language
can be transformed without loss into an equivalent state-vector system, so
that centralized numerical integration algorithms can be used to solve the
resulting system of differential equations.
Some years ago, I advised a simulator manufacturer (not in the design
automation field but who will remain nameless) about a serious problem they
discovered in their product -- it could not solve a one-resistor,
one-capacitor circuit without gross errors in the tails, where the voltage
on the capacitor should have decayed to very small values. Basically, the
simulator was useless for any kind of analog system described as
differential equations.
Why? Because their model was a set of independent blocks connected
together, and each block integrated its inputs independently of the others,
and remembered everything. So, one could not use even Runge-Kutta
integration, because there was no way to perform the required
trial-solution steps. Nor could one use the implicit integration
algorithms required to solve stiff systems, where the final value depends
on itself, and one loops producing trial solutions until the stationary
point is found, reporting only the found point and not the steps leading up
to that point.
How was the problem solved? By reduction of the market into which that
simulator could be sold. It was too late to fix that simulator; the
blunder being too deeply embedded to be repaired. Fortunately for the
vendor, problems requiring the solution of differential equations were not
a large part of their then market (factory workflow scheduling), so the
direct economic harm wasn't great, but there was a large lost-opportunity
cost for them, as they could not enter a number of markets they should have
owned, given their other advantages.
I recall making just this point, and telling this war story, some years
ago, while the VHDL-AMS standard was first being developed.
Conclusion: Be very sure that the chosen block diagram language allows use
of the best of numerical integration algorithms before commiting to that
language, even though all such languages will be by definition a subset of
VHDL-AMS. A mistake here will simply kill VHDL-AMS-RT, so a
proof-of-principle demonstration should be required as a precondition for
consideration of a proposed block-diagram language.
>0.5 Sequential Statements (ß8)
>
[snip]
>
>The signal assignment statement does not support the delay mechanism
>[ß8.4]. The delay mechanism has to be substituted by explictly using
>wait statements (this substitution is not equivalent).
I don't recall if this is the same thing as the modelling of analog
transport delay, but if it is, it's still very much needed, and should not
be dropped.
Joe Gwinn
This archive was generated by hypermail 2b28 : Wed Jan 26 2000 - 15:58:28 PST