Subject: 1364.1 comments
From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Wed Aug 28 2002 - 06:23:56 PDT
Since I have expressed some reservations about the 1364.1,
it behooves me to detail at least some of my objections.
I will try here to present some of the more important problems
I see in the current draft.
I know I am not a voting member of the working group,
and I know the document has already been voted on.
I have also found a large number of smaller editorial problems
which I assume I can present later on.
Maybe directly in a phone call to Jayaram Bhasker.
I only managed to seriously review pp. 1-19.
This is what I found in those pages.
Sincerely,
Shalom Bresticker
1. The term "to model" in all its various forms is used unclearly and
inconsistently throughout the document.
As a result, it took me days to figure out the intended meaning. It is
not defined anywhere, either.
2. Section 3(r): "timeout clause" - what is the connection between the
definition and a timeout ?
3. Section 4, para. 2: Sentence 2 talks about an "unambiguous defintion
of equivalence for values on ... ports".
But what about don't-care cases, such as full_case? The sentence seems
to rule out such cases. At best, it is not clear.
4. Sec. 4, para. 2, sentence 3: "ports cannot be added or deleted during
synthesis". What about synthesizing a group of modules together and
dissolving the boundaries between them? What about test_port?
5. Sec. 4, para. 3, items (d), (e): These cover edge-sensitive and
level-sensitive designs separately. What about a mixed FF/latch design?
Same comment applies to Sec 4.2.
6. Sec. 5.1: Paragraphs 2 and 4 should be merged. In particular, last
sentence in para. 2 and second sentence in para. 4 are confusing when
put together.
7. Example 4: Won't this be synthesized to a latch?
8. Example 5: "2" should be "IN2".
9. Sec 5.2.1.2: It says negedge represents a "negative clock edge
expression". It is not necessarily a clock.
10. Sec 5.2.2: Sentence 1 says a FF has "exactly one edge event in the
event list". What about an asynchronous reset? (This is one of the
places where the verb "modeled" is confusing.)
11. Sec 5.2.2, para. 4: "Multiple event lists in an always statement
shall not be supported". Unclear what is "multiple event lists".
12. Sec. 5.3: It says a latch "may be modeled ... when all the following
apply". Only "may be"?
13. Sec 5.6: Para. 2 says, "logic_block" means no ROM. This is
confusing. First you say it's a ROM, then you say it's not a ROM. And if
it is not a ROM, then why is initial statement supported? (5.6.2). I
think you have to distinguish being ROM/RAM functionality and type of
implementation. The terms are used in different meanings.
14. Sec. 5.6, NOTE 2: not clear.
15. Sec 5.6, NOTE 3: says there may be a mismatch at time 0. At least in
case of style in 5.6.1, the mismatch may continue farther, until first
time that address gets a value. always@* may not be triggered at time 0.
16. Sec. 6.1: Para. 1 says, "If a synthesis tool supports pragmas ...",
implying it is optional. Para. 5 says, "The following ... synthesis
attributes that shall be supported..." implies a requirement. ??
17. Sec 6.1.1(a): says, "The optional value shall be ignored.." Why?
Should be "may be ignored", as in 6.1.2?
18. Sec. 6.1.1(a) Note 2 says, correctly, that a full_case may not
prevent a latch.
Sec. 6.1.1(c) Note (which should also be in 6.1.1(a)) says that "the
risk is that the user could be wrong about the fullness of the case".
This is a different reason. The first one is a better reason. The second
confuses the issue.
19. Example 31: This is a latch, so assignments should be nonblocking.
20. Sec. 6.1.4(e) keep: Text defines effect on instance, module, and
net, but not on reg.
21. Annex A labeled "D2.1", not "D2.2". Deliberate?
22. Main text should reference Annex B as appropriate, each section in
the appropriate place.
-- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478"The devil is in the details."
This archive was generated by hypermail 2b28 : Wed Aug 28 2002 - 06:45:25 PDT