Subject: Response to issues list
From: Graham Helwig (ghelwig@asc.corp.mot.com)
Date: Thu Aug 09 2001 - 02:26:13 PDT
Hello,
Below I have attached the partial list of issues with their resolution.
Due to the very short notice and the large number of issues we were
unable to provide resolution to all of the issues listed.
Regards
Graham
-=-=-=-=-=-=-
Priority selection:
3 (high) features that directly impact the mixed-signal
subset of the Verilog-AMS language and thus prevents the
correct implementation of the language. Feature needs to
be fixed in 2.1 LRM version.
2 (Medium) features/issues that are important but does not
directly impact the mixed-signal definition however to may
directly impact Verilog-A and Verilog LRM definition.
Desirable for fix in 2.1 LRM version
1 Other issues that need to be address however it can wait
for a post- 2.1 LRM version before being fixed.
? Issue needs more clarification.
Here is a list of issues and their resolution from Motorola Australia
perspective. (Sri is currently on vacation, therefore he may have
comments in addition to these)
ISSUE : 1
PRIORITY : M
APPROVE : Y
COMMENTS :
-------------------------------------------------
ISSUE : 2
PRIORITY : M-H
APPROVE : Y
COMMENTS :
-------------------------------------------------
ISSUE : 3
PRIORITY : H
APPROVE : Y
COMMENTS :
-------------------------------------------------
ISSUE : 4
PRIORITY : M-L
APPROVE : ?
COMMENTS :
-------------------------------------------------
ISSUE : 5
PRIORITY : H
APPROVE : Y
COMMENTS :
-------------------------------------------------
ISSUE : 6
PRIORITY : M
APPROVE : ?
COMMENTS :
-------------------------------------------------
ISSUE : 7
PRIORITY : H-M
APPROVE : ?
COMMENTS :
-------------------------------------------------
ISSUE : 8
PRIORITY : H
APPROVE : Y
COMMENTS : See sub-issues 9 etc below
-------------------------------------------------
ISSUE : 9
PRIORITY : M
APPROVE : yes
COMMENTS : Verilog-AMS genvar need to be replaced by Verilog-2001 genvar
definition
-------------------------------------------------
ISSUE : 10
PRIORITY : M-H
APPROVE : no
COMMENTS :
Need to see the rewritten definition. Defining a discipline
discipline neutral;
enddiscipline
is by default analog domain, due to the lack of domain assignment
statement. Is it better to define uncommitted nets which has no
discipline assigned to it?
-------------------------------------------------
ISSUE : 11
PRIORITY : M
APPROVE : Yes
COMMENTS :
LRM needs to clarify ground usage wrt to digital nets.
-------------------------------------------------
ISSUE : 12
PRIORITY : L
APPROVE : no
COMMENTS :
Why is real nets required in a true mixed-signal language?
-------------------------------------------------
ISSUE : 13
PRIORITY : M-H
APPROVE : Y
COMMENTS :
-------------------------------------------------
ISSUE : 14
PRIORITY : M
APPROVE : Yes
COMMENTS :
-------------------------------------------------
ISSUE :15
PRIORITY :L
APPROVE : Yes
COMMENTS :
-------------------------------------------------
ISSUE :16
PRIORITY : H
APPROVE : yes
COMMENTS :
Definitely! Particularly wrt to "static" and its use within
@initial_step(),@final_step() and analysis() functions
-------------------------------------------------
ISSUE :17
PRIORITY : H
APPROVE : yes
COMMENTS :
The Synchronization definition needs to clarify this particularly wrt to
processing @cross events after the time step has converged ( see accept
step (figure 9.1))
Related issue: differences between handling @timer and
@cross in a mixed-signal synchronization time step. @timer is processed
during the timestep, while @cross is processed after the time step has
converged (post Step)
-------------------------------------------------
ISSUE :18
PRIORITY : H
APPROVE : Yes
COMMENTS : see item 16 above
-------------------------------------------------
ISSUE :19
PRIORITY : M
APPROVE : yes
COMMENTS :
The top-level module is the same as any other Verilog-AMS module,
therefore it can contain analog, digital or mixed signal behaviour.
-------------------------------------------------
ISSUE :20
PRIORITY : ?
APPROVE : ?
COMMENTS : Need more information!
-------------------------------------------------
ISSUE :21
PRIORITY : M
APPROVE : Yes
COMMENTS :Real port definitions need more clarity
-------------------------------------------------
ISSUE :22
PRIORITY : H
APPROVE : No
COMMENTS :
However, variable and probe behaviour can be better organised within
this section. It needs to be clarified if accessing a variable in the
opposite context influences the MS synchronisation.
-------------------------------------------------
ISSUE :23
PRIORITY : H
APPROVE : YES
COMMENTS : LRM Definitions need more clarification
-------------------------------------------------
ISSUE :24
PRIORITY : M
APPROVE : yes
COMMENTS : LRM needs to clarify 4-state logic accesses from the analog
context.
Sub issue: How to convert digital net/register access which exceed the
destination maximum size (converting a 256 bit variable to an integer,
for example ?)
-------------------------------------------------
ISSUE :25
PRIORITY : H
APPROVE : yes
COMMENTS :
Exact issue it unclear, however better definition of these sections will
be beneficial
-------------------------------------------------
ISSUE :26
PRIORITY :
APPROVE : No
COMMENTS :
Discipline resolution is a LRM issue that affects portability. A common
discipline resolution method should be defined in the LRM and agreed
upon.
Existing resolution method needs to consider digital and analog
primitives. See previous email from Motorola regarding updates to the
definition to allow this.
-------------------------------------------------
ISSUE :27
PRIORITY : M
APPROVE : YES
COMMENTS : There is need for sensor like converter modules between two
incompatible continuous disciplines
-------------------------------------------------
ISSUE :28
PRIORITY : ?
APPROVE : ?
COMMENTS :
-------------------------------------------------
ISSUE :29
PRIORITY : M-H
APPROVE : ?
COMMENTS : Need more clarification on all of sub-issues
-------------------------------------------------
ISSUE :30
PRIORITY :
APPROVE : ?
COMMENTS : Need more information to make a decision
-------------------------------------------------
ISSUE :31
PRIORITY : H
APPROVE : yes
COMMENTS :
-------------------------------------------------
ISSUE :32
PRIORITY : L
APPROVE : ?
COMMENTS :
Agree with $random, but not $table at this time.
-------------------------------------------------
ISSUE :33
PRIORITY : L
APPROVE : ?
COMMENTS :
section 11.6 defines that `resetall directive resets these compiler
directives.
-------------------------------------------------
ISSUE :34
PRIORITY : L
APPROVE : don't care
COMMENTS :
-------------------------------------------------
ISSUE :35
PRIORITY : M
APPROVE : yes
COMMENTS : This has been a need for a long time!
-------------------------------------------------
ISSUE :36
PRIORITY : M-H
APPROVE : ?
COMMENTS : Need clarification of the exact problem
-------------------------------------------------
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Graham Helwig email: A11558@email.mot.com ghelwig@asc.corp.mot.com Telephone:+61-8-81683532 Fax:+61-8-81683501 Motorola Australia Software Centre, 2 Second Avenue, Technology Park, Adelaide, SA, 5095, Australia -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This archive was generated by hypermail 2b28 : Thu Aug 09 2001 - 02:27:13 PDT