Subject: Kev's Verilog-AMS Outstanding Issues
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Dec 01 2000 - 10:41:31 PST
My outstanding issue list (for discussion):
1. Truncating vs Rounding when converting Analog to
Digital times.
I uploaded some diagrams from last year's
discussion to -
http://www.eda.org/verilog-ams/htmlpages/tc-docs/
I still haven't seen any rationale for truncating
time, in my opinion it introduces unnecessary
timing errors. I propose using rounding unless
there is a good reason for truncating.
2. Driver-receiver Segregation
Connect statements and the insertion of A/D & D/A
convertors is actually an extended form of 'signal
resolution' - both VHDL and Verilog have mechanisms
where all drivers of a signal have their values
merged and the result appears as the value for that
signal everywhere. The driver-receiver segregation
section in the Verilog-AMS LRM as it stands appears
inconsistent with this accepted approach and should
be restated.
[ In general for a net that appears in multiple
domains, the drivers in those domains need to be
converted to the domain of highest accuracy,
resolution is performed in the domain of highest
accuracy (analog) and the result converted back
to the lower accuracy domains. ]
3. A/D Convertor placement
Auto-inserted convertors should be on the child
side of ports where conversion takes place as
they are really associated with the driving
and receiving processes in the child (not the
parent), and because back-annotation may not
work correctly otherwise. Also, if A/D convertors
need to attach to a local power supply (say
'local.vdd' in Verilog) the search scope should
start in the child.
4. Driver Access
The driver-access look-ahead functions should be
reinstated, there is no other way (I know of) of
getting accurate D -> A conversion timing. The
fact that they may not function in all cases is
a user/methodology issue.
5. A/D Synchronization
The A/D synchronization algorithm is described
at a kernel level rather than at the behavioral
process level. I would prefer a description that
is more general and applicable to multi-solver
and multi-kernel simulators, e.g.:
Step 1: Processes execute and schedules future
values (and set d?/dt etc.) and a
callback event (at acceptance, if
necessary).
Step 2: Simulator steps to global next event
(analog or digital) and executes it.
Step 3: Processes activated by event execute
and reschedule future values and events.
Step 4: Goto step 2
- NB: Time is continous, 'digital time' doesn't
really exist.
Regards,
Kev.
-- mailto:Kevin.Cameron@nsc.com
This archive was generated by hypermail 2b28 : Fri Dec 01 2000 - 10:50:22 PST