Subject: RE: VHDL-AMS Subset for Real-Time (VHDL-AMS-RT)
From: Steve.Grout@sematech.org
Date: Wed Dec 01 1999 - 08:10:57 PST
re the below "'" that appears, I believe that would be
the 'long dash' that Word and other word processors often
use instead of the ASCII 'dash' or '-'. The issue is best
stated as sticking to straight ASCII WITHIN documents and
not using the normally default long dash. You can turn off
the use and auto-insertion of the long dash under Word ->
tools -> options -> view -> optional hyphen (uncheck it).
The same issue arises when you use a WORD document that has
used 'smart quotes', with a leaning-left open quote. Again
there is a box to un-tick somewhere down the same path as
above.
Both often lead to strange characters when you go to ASCII,
the lowest common denominator.
regards,
--Steve Grout
> -----Original Message-----
> From: gwinn@res.ray.com [mailto:gwinn@res.ray.com]
> Sent: Tuesday, November 30, 1999 10:44 AM
> To: moser@fli.sh.bosch.de
> Cc: vhdl-ams@eda.org
> Subject: Re: VHDL-AMS Subset for Real-Time (VHDL-AMS-RT)
>
>
> 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:29 PST