From: Anders Nordstrom (andersn@nortelnetworks.com)
Date: Sun Oct 22 2000 - 08:15:41 PDT
> BTF Members,
Please review these and the rest of the comments before our next conference
call on Friday October 27.
Thanks,
Anders
<p><p>> JohnW-Comment #61: p. 285, Section 17.1.1.1 through Section 17.1.1.4, each
> final
> example should be made neater. Perhaps a little box with dotted lines and
> rounded
> corners should be used to represent the screen display during simulation?
CLARIFICATION: Add the text "Will display on the screen:" before the
screen output.
>
>
> JohnW-Comment #62: p. 286, Section 17.1.1.2, Format specifications, third
> paragraph
> from the bottom. There is a problem in allowing the data to be written in the
> native machine integer format, which varies with CPU hardware and compiler,
> and
> may be anywhere from 16 to 128 bits. I suggest standardizing and explicitly
> requiring a definite width, say signed 32 bits, for data. Let the user
> figure out
> whatever native format specifier should be coded; if the user has unusual
> hardware
> or compiler, he or she will know it. This will improve portability and
> reusability of
> the data.
NO CHANGE: The size of an integer is not specifed in Verilog. It is only
required to be 32 bits or more.
>
>
> JohnW-Comment #63: p. 304, Section 17.3.1, $printtimescale, the text just
> before the
> example probably should say, "The timescale information shall appear in the
> following format:". Likewise, just after the example, it probably should
> say, "The
> information about c_det shall be displayed in . . .".
FIX TYPO: Change the text before the example to: "The timescale information
shall appear in the following format:". Change the text after
the example
to: "The information about c_det shall be displayed in . . ."
This is exactly what Verilog-XL prints out but this function is
not
implemented in VCS.
>
>
> JohnW-Comment #64: p. 318 - p. 327, Section 17.9.3, Algorithm for
> probabilistic
> distribution functions, I suggest that the code be moved to an Annex.
> Perhaps it should be explicitly stated whether it is allowed to use an
> improved
> algorithm (maybe a numerical recipe in assembly language) which achieves the
> same result? Also, technically, a "distribution function" of a random
> variable is a
> cumulative distribution function, an integral of the probability density
> function from
> the low end of the domain.
CLARIFICATION: Change the sentence below table 17-17 on page 319 to:
"An implementation of these functions shall behave in
the same
way as the functions defined by the following C code."
>
>
> JohnW-Comment #65: p. 334, Section 18.1.5, Limiting the size of the dump file
> ($dumplimit), really should include an option to allow the file to become a
> FIFO on
> limit: In a long simulation, often it is the latest data that are of
> interest to the
> designer.
>
SENSIBLE: Great idea but it will require a new function or added arguments
to the existing one. It may be too late to change now.
<p>Attachment Converted: "C:\Documents and Settings\stefen\Application Data\Qualcomm\Eudora\andersn42.vcf"
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:14 PDT
and
sponsored by Boyd Technology, Inc.