[sv-cc] RE: SV LRM review issues

Stu, Team,

I found one more problem in the SV #50 edits.
In the new Example 4 in subclause 10.1, the
"svBitPackedArrRef" argument in the C function foo7
should be changed to "svBitVecVal*".

Thanks,
Doug

> -----Original Message-----
> From: Warmke, Doug
> Sent: Sunday, January 23, 2005 10:23 AM
> To: sv-cc@eda.org; 'sv-bc@eda.org'
> Cc: stuart@sutherland-hdl.com
> Subject: SV LRM review issues
>
> Hello Stu, SV-BC, and SV-CC.
>
> I finished reviewing all my Mantis items.
> Almost all of them have been Closed.
>
> I assigned 3 of them back to SV-LRM, and added
> Bug Notes explaining the reasons why. The Bug Notes
> are duplicated here for your convenience.
>
> Thanks and regards,
> Doug
>
> Item #50
>
> 1. In the 3rd paragraph of E.4, it is stated that
> "This subclause fully defines the svdpi.h file".
>
> This is not strictly true, since the file is fully
> defined in Annex F (not this little subclause).
> The following would be better:
> "The svdpi.h file is fully defined in Annex F."
>
> 2. In 9.3, Example 3, the following comment:
> /* Read least significant byte of each word of b into
> aB, then process...*/
> should be indented 2 more spaces, so that it lines up
> with the line of code below it.
>
> 3. The title of Annex F should be:
> "Include File svdpi.h"
>
> (Currently it is simply named "Include File")
>
> 4. In E.7.8 (inout and output arguments), the terms
> svBitPackedArrRef and svLogicPackedArrRef should be
> replaced with svBitVecVal* and svLogicVecVal*, respectively.
>
> 5. In E.6.4, there was a collision between items #50 and #274.
> To fix this, all that needs to be done is to replace
> svBitPackedArrRef with svBitVecVal*. There are two places
> this change is needed, both in the 4th paragraph of the subclause.
>
> Item #163
>
> 6. There is a tiny editorial error in this item.
> There needs to be an "a" in front of "4-state type"
> at the end of the first sentence in the second
> paragraph of 3.3.2.
>
> Item #315
>
> 6. In the 2nd-to-last paragraph of 17.15, the following
> sentence appears:
> "Note that the latter situation will can occur if the design
> contains more than one instance of a module containing a
> bind statement."
>
> Note the "will can occur". In the original proposal, this was
> simply "will occur". I feel "will" is better than "can"
> in this case.
> This situation WILL occur with 100% reliability, not just
> sometimes,
> as the word CAN implies.
>
>
>
>
Received on Mon Jan 24 16:27:51 2005