Subject: Re: Truncation vs Rounding
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Tue Apr 16 2002 - 10:02:59 PDT
Srikanth Chandrasekaran wrote:
> Hi all,
>
> In the current LRM we use truncation instead of rounding when converting
> analog to digital times.
>
> There was some discussions in today's call as to the rational behind
> truncating instead of rounding, and whether rounding the digital times would
> be the appropriate mechanism for this conversion.
>
> Would like to hear various view points on this one.
>
> cheers,
> Sri
There various diagrams on the web linked here:
Issue 1: Truncating vs Rounding when converting Analog to Digital times.
The difference between Verilog and VHDL is that Verilog has a variable time-step.
Verilog simulation kernels use that to perform more efficient scheduling (using a time
wheel), i.e. if the time-step is set by the user at 1pS then nothing is scheduled with
finer granularity. The average error in a converted time is always negative if you use
truncation, for VHDL it is 0 to 1fs, and for Verilog 0 to whatever the time-step is.
If the user specifies a resolution of 1pS, I take that as a statement that the
time precision is +/- 0.5pS per delay, e.g. an inverter:
always @(in) out #5 = !in;
- will in reality have a 5.0 +/- 0.5pS delay, and I would expect the analog
equivalent (when dropped in) to have the same delay. I f truncation is used on
the A2D boundary the spread will be 4.0 to 5.0pS (4.5 +/- 0.5pS) instead
- the all analog version would be centered on 5.0pS.
This rounding error also makes the mixed simulation "optimistic" in timing, and the
errors accumulate if multiple A/D boundaries are crossed. Reducing the time-step
reduces the error, but it will still be optimistic and the digital simlation will be
slower due to the extra arithmetic in calculating delays and less efficient scheduling.
Unnecessary mismatch between the all-digital, all-analog and mixed simulations
will lead to lower user acceptance of AMS results.
Kev.
This archive was generated by hypermail 2b28 : Tue Apr 16 2002 - 10:05:39 PDT