From: Steven Sharp (sharp@cadence.com)
Date: Thu Oct 12 2000 - 18:18:25 PDT
> AnneH-TC-1) On page 46, in the fourth example, is -4'sd12 / 3 really 4? I
> think that 4 is just an intermediate result for -4'sd12.
CLARIFICATION:
Add an additional line to the last comment:
// The result is 1.
> AnneH-TC-2) On page 48, in section 4.1.6, the text says that a reg is
> treated as unsigned, but Table 4-8 shows a signed reg treated as a signed
> 2's complement (the same as an integer)
PROPOSED CHANGE:
There are other related errors in this same paragraph that should be fixed.
Change the first paragraph in section 4.1.6 to read:
A reg shall be treated as an unsigned value unless explicitly declared
to be signed. An integer variable shall be treated as signed. Signed
values shall use a 2's complement representation. Conversions between
signed and unsigned values shall keep the same bit representation; only
the interpretation changes.
> AnneH-TC-3) On page 53, in example 2, neither start nor result is a signed
> reg. According to the text before the examples, zero filling should be
> used in this case, not sign filling.
PROPOSED CHANGE:
Change the declaration in example 2 to read:
reg signed [3:0] start, result;
> AnneH-TC-4) On page 113, it would be useful to show an example of the new
> UDP header format.
SENSIBLE:
But the consensus in discussion was not to add one at this late date.
> AnneH-TC-5) On page 114, in Table 8-1, it says that "x" is not permitted in
> the output field of a UDP. If this is true, then the example for notifier
> regs in timing checks on page 265 is wrong, and there is no way to do
> notify reg error handling in a UDP.
PROPOSED CHANGE:
In the Comments field of table 8-1 for Symbol x, remove the last sentence
that says "Not permitted in the output field."
> AnneH-TC-6) On page 131, in section 9.3.2 paragraph 1, it says that the
> left hand side of a force statement may be a bit or part select of a vector
> net. However, on page 130, in the last paragraph of section 9.3, it says
> that neither a bit select or a part select of a vector net is allowed for a
> force. Which is correct?
PROPOSED CHANGE:
Change the last sentence of the last paragraph of section 9.3 to read:
Bit-selects and part-selects of vector variables are not allowed.
> AnneH-TC-7) On page 250, in the middle of the page, in the description of
> when $setuphold reports a timing violation, timecheck appears instead of
> timestamp. The correct condition is:
> >(beginning of time window) < (timestamp time) <= (end of time window)
SEND TO ATF
> AnneH-TC-8) On page 254, in the middle of the page, in the description of
> when $recrem reports a timing violation, timecheck appears instead of
> timestamp. The correct condition is:
> >(beginning of time window) < (timestamp time) <= (end of time window)
SEND TO ATF
> AnneH-TC-9) On page 254, in the last sentence of section 15.2.6, change
> $setuphold to $recrem.
<p>SEND TO ATF
> AnneH-TC-10) On page 257, the text under case 2 should go with case 3
> instead. In case 2, the remain active flag is not set, so only one
> violation should be reported after a rising edge on CP. The text currently
> in the document for case 3 saying that all CPN edges would cause a
> violation is wrong because CPN edges after E would not cause violations,
> since the rising CP edge at F with MODE low would disable the check.
SEND TO ATF
> AnneH-TC-11) On page 284, in the second bullet item, "For each % character"
> should be "For each % character, with the exception of %m".
CHANGE PASSED
Proposed: Steven
Second: Mac
Passed
> AnneH-TC-12) On page 299, in section 17.2.4.4, there is an inconsistency.
> In the second paragraph, it says that loading starts from the LSB if there
> is no start argument. In the fifth paragraph, it says that loading starts
> at the lowest numbered location. The lowest numbered location does not
> have to be the LSB.
UNSURE:
The obvious change seems to be to change the fifth paragraph. However, it
should be noted that $readmem is implemented in all leading simulators to
load from the lowest location even though this disagrees with the standard.
This will not change (we tried and finally gave up). The standard should
be changed to match reality. And then it may make sense for $fread to match
the behavior of $readmem.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:14 PDT
and
sponsored by Boyd Technology, Inc.