Subject: Re: feedback on Kevins Section 9 proposal
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Aug 30 2002 - 17:25:28 PDT
> From owner-verilog-ams@server.eda.org Mon Aug 26 16:32:33 2002
>
> Here is my feedback on last weeks proposal.
> Note: C0 are issues of major concern
..
> C0: re last paragraph of 9.2.2.2
> not having implicit sensitivity to digital signals will
> mean that the behavior of the mixed signal analog blocks
> will be at the mercy of the analog time-step selection
> mechanism unless the user additionally puts a event sensitive
> statement for every digital signal referenced in the
> analog block.
>
> Based on the discussion with the committee at the last meeting
> I suggest the following;
>
> Change;
> "As with digital processes, analog processes are insensitive to changes
> in variables, i.e. a change in a variable does not force re-evaluation
> of the process, neither are they implicitly sensitive to digital signals
> used in procedural code, only changes in signals in event expressions
> will trigger re-evaluation prior to scheduled wake-up."
>
> to
> "Analog processes are implicitly sensitive to all digital value changes
> changes which affect the solution of an analog value but
> which are not 'guarded' by an event control block or a conditional block.
> This is consistent with analog value calculations being sensitive to
> changes in other analog values."
>
> Will forward email exchange with Ian on this issue shortly. !!!
I would suggest making the extra sensitivity a compile/runtime option. The
kind of errors less sensitivity will give are analogous to regular Verilog-D
programming errors - which SystemVerilog has fixed by adding "@(*)", nobody
asked for implicit sensitivity. If it turns out to be a bad idea you can
switch to implicit sensitivity in a later rev and models should be backward
compatible. If we add implicit sensitivity now and it turns out to be a
perfomance problem then it is difficult to change to explicit sensitivity
without breaking models that are built in the interim.
We could add that the compiler/parser should issue warnings for variables
used in a process which isn't sensitive to them.
> example:
>
> C0: 9.2.2.3
> Issue with "trunctation" Vs "rounding" as this is
> inconsistent with the VHDL-AMS simulation cycle and
> make it Verilog-AMS/VHDL-AMS co-simulation very
> challenging.
I still don't get this. With VHDL you simulate to a time-step
of a fs, so are you truncating to the nearest fs, the nearest
fs multiple of the Verilog time-step or what?
Regards,
Kev.
This archive was generated by hypermail 2b28 : Fri Aug 30 2002 - 17:27:51 PDT