[sv-bc] RE: Doug's 1364 issues

My comments:

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Warmke, Doug
> Sent: Wednesday, December 21, 2005 2:59 AM
> To: sv-bc@eda.org
> Subject: RE: [sv-bc] Agenda: Dec 5, 2005 SV-BC CC
> 
> Hi All,
> 
> I've finally got my 20 issues transferred from BTF into Mantis.
> Here are the results.  Some are easy and have proposals
> uploaded.
> 
> Notes on my issues:
> 
> 621 -> 1246  - Comments within `define arguments
>                Medium one, possibly controversial. Proposal is
> uploaded.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001246

[Shalom] Controversial indeed.


> 624 -> Close - This is simply requesting closure on existing
> issues
>                BTF-463(Mantis-1004) and BTF-506(Mantis-1072).

[Shalom] True, but the discussion on 624 should be preserved in one or
both of those Mantis issues. (What is the plural of Mantis? Is it Manta?
Manti?) Note that the issue also requests closure of ETF-106, but that
was indeed subsequently closed.


> 626 -> 1247  - Request for stronger definition of 'time step'
>                Propose close, since 'time step' doesn't appear
> ambiguous
>                in the remaining places it is used)
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001247

[Shalom] Why not clarify it? "time step" is also used 19 times in 1800.
As an example of possible confusion, the term "time unit" in the LRMs is
used to specify the amount of time described by #1, which is dependent
on the timescale used. However:

	- In 1364, 10.1 says, "A function shall execute in one
simulation time unit", which seems to be incorrect and should have been
"one simulation time step". 
	- 18.1.3 says, "Executing the $dumpvars task causes the value
change dumping to start at the end of the current simulation time unit."

	- 18.3.1 says, "When $dumpports executes, the associated value
change dumping shall start at the end of the current simulation time
unit."
	- In 1800, 17.7.3 says, "The clocking event is used to obtain
the sampled value of the argument expression at a clock tick prior to
the current simulation time unit. Here, the current simulation time unit
refers to the simulation time unit in which the function is evaluated.
This sampled value is compared against the value of the expression
determined at the prepone time of the current simulation time unit."


> 631 -> Close - Use of genvar inside generate scope.
>                This has already been clarified with the 1364-
> 2005
> generate rewrite.

[Shalom] Agree.


> 642 -> 1248  - $swrite should completely overwrite its target
> string.
>                There is already unambiguous language in the LRM
> governing
>                the action of $swrite, but Shalom wants it more
> explicit.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001248
> 644 -> 1249  - Attributes on system function calls.
>                LRM makes this illegal, but Shalom would like
> the
> feature.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001249

[Shalom] What I meant is that it seems to be useful.


> 649 -> 1250  - Use of "unknown" should be more precise
> throughout LRM.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001250
> 650 -> 1251  - Better specification of 'wait' conditions being
> 'x' or
> 'z'
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001251
> 652 -> 1252  - Problem with path condition example #2 in
> 14.2.4.3.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001252

[Shalom] Note that is a real error, not an ambiguity.


> 654 -> 1253  - Missing [ polarity_operator ] for edge-sensitive
> specify
> paths.
>                Easy one.  Proposal is uploaded.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001253

[Shalom] The proposal changes the BNF to allow an optional
polarity_operator in the specified places, but does not add the needed
text describing what is its meaning (non-meaning in this case?)


> 655 -> 1254  - Clarifications on terminal connections for array
> of
> instances.
>                Fairly easy one.  Proposal is uploaded.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001254

[Shalom] Agree.


> 656 -> 1255  - "port" vs. "terminal" terminology issue.
>                Probably needs brief committee discussion for
> direction,
>                then it will be easy to bang out a proposal
> based on
> results.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001255
> 657 -> 1257  - Error in multi-driver wired logic drawing for
> module path
> outputs.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001257

[Shalom] This is also a real error.


> 660 -> 1258  - LRM doesn't clearly specify behavior of
> primitives with 1
> input.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001258
> 661 -> 1259  - Minor edits in 5.1.10 and 5.1.11.
>                Easy one.  Proposal is uploaded.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001259

[Shalom] Agree.


> 662 -> 1260  - Incorrect rule for extension of unsized
> constants.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001260

[Shalom] This is also a real error.


> 663 -> 1261  - Incorrect width extension rule in 4.1.10.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001261

[Shalom] Ditto.


> 664 -> 1262  - Missing rule for reduction operators in 5.5.1.
>                Easy one.  Proposal is uploaded.
> 
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0001262

[Shalom] Agree.


> 
> Happy Holidays to all SV-BC fans!
> Doug