Jonathan, Thanks for the detailed review. I like almost all your suggestions. Please see below for my responses. Regards, Doug ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ General notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (1) Throughout the text, ensure correct spelling of the scheduling region name Observed (some instances lack the final 'd'). DOUG: OK (2) Signedness of cycle delays: Cycle delays in a ## construct must be integral and non-negative. It's not entirely clear what happens if a negative number appears in this context. The value should probably be interpreted as unsigned, but this is likely to yield unexpected behavior because small negative integers cast to unsigned will have the effect of very large positive integers. Is it a good idea to encourage implementations to issue a warning in this case? DOUG: You seem to have taken care of this with one of your proposed edits below (requiring cycle delays to be non-negative integers). That's fine with me. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Detailed comments on the text ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 15.2 Clocking block declaration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ First para in 890-5 text: ========================= (1) Suggestion: change The signal_identfier identifies a signal in the scope enclosing the clocking block declaration and declares the name of a signal in the clocking block. Unless a hierarchical_expression is used, both the signal and the clocking_item names shall be the same. to: The signal_identifier identifies a signal (a net or variable) in the scope enclosing the clocking block declaration, and declares a _clockvar_ in the clocking block. Unless a hierarchical_expression is used, both the signal and the clockvar names shall be the same. [Motivation: Introduce the term clockvar so it can be used elsewhere with confidence; remove ambiguity associated with the word "signal".] DOUG: OK (2) The last sentence of the first paragraph is potentially ambiguous thanks to the use of "includes". In fact, the *exclusion* of the previous sentence *includes* class properties etc! Suggested re-wording of final sentence: Likewise, it shall be illegal for a clocking signal_identifier to specify either a class property or a dynamically-sized variable. DOUG: OK Second para in 890-5 text: ========================== Some of the text in this paragraph is explanatory rather than normative, and is intentionally incomplete. It may be preferable to make some of the paragraph a Note, so that statements such as input or inout signals specified in the clocking block are sampled when the corresponding clock event occurs do not conflict with later, more detailed normative text. Specifically, replace the paragraph with the following two paragraphs (I've also suggested some tiny rewordings): The clocking_event designates a particular event to act as the clock for the clocking block. The timing used to drive and sample all other signals specified in a given clocking block is governed by its clocking event. See 15.12 and 15.14 for details on the precise timing semantics of sampling and driving clocking signals. Bidirectional signals (inout) are sampled as well as driven. An output signal cannot be read, and an input signal cannot be driven. NOTE: All input or inout signals specified in the clocking block are sampled when the corresponding clock event occurs. Likewise, all output or inout signals in the clocking block are driven when the corresponding clock event occurs. DOUG: OK 15.12 Input sampling ~~~~~~~~~~~~~~~~~~~~ (1) Penultimate para in 890-5 text would be clearer if it referred to the clockvar; reference to "the signal" is highly ambiguous. Suggested rewording: change When a signal appears in an expression, it is replaced by the signal's sampled value, that is, the value that was sampled at the last sampling point. to When an input or inout clockvar appears in any expression its value is the signal's sampled value, that is, the value that the clocking block sampled at the most recent clocking event. DOUG: Is this better than "sampling point"? There may be a skew involved, which would mean that the sample doesn't occur precisely at the clocking event. 15.14 Synchronous drives ~~~~~~~~~~~~~~~~~~~~~~~~ (1) First para at the head of page 4 of 890-5: "The event_count" has no antecedent in the text, and the syntax of "event_count" is rather deeply buried in the production rules for "cycle_delay". Furthermore, part of the text of this paragraph appears to refer to the struck-out syntax [cycle_delay] clockvar_expression <= expression at the foot of the previous page. Suggested re-wording of the first two paragraphs of this page: replace The event_count refers to the expression after the ## in the cycle_delay production and is an integral expression that optionally specifies the number of default clocking events (i.e., cycles) that must pass before the statement executes. Specifying a nonzero event_count blocks the current process until the specified number of clocking events has elapsed; otherwise, the statement executes at the current time. The event_count uses syntax similar to the cycle delay operator (see 15.10); however, the synchronous drive uses the clocking block of the signal being driven and not the default clocking. The second form of the synchronous drive uses the intra- assignment syntax. An intra-assignment event_count specification also delays execution of the assignment. In this case, the process does not block, and the right-hand expression is evaluated when the statement executes. with An optional cycle delay control, of the form ##expression, may immediately follows the synchronous drive operator <=. DOUG: follows should be follow The expression in this cycle delay control shall be a positive integral expression. The syntax is similar to the syntax of nonblocking intra-assignment delay, If this optional cycle_delay is used, the clocking drive shall evaluate its right-hand-side expression immediately and shall schedule the clocking drive to occur in the future timeslot specified by the cycle delay (that is, for a cycle delay ##N, in the timeslot in which the Nth subsequent clocking event occurs). In this construct, the clocking event is that of the clocking block of the signal being driven and not the default clocking. Whether or not a cycle delay control is used, a clocking drive statement shall never block the flow of execution. NOTE: As with any other procedural statement, a clocking drive statement may have a cycle delay of the form ##N as a prefix. Such a cycle delay, used as a prefix to any procedural statement, waits for the specified number of cycles of the default clocking. DOUG: I'm not very comfortable with this suggestion. The main text treats cycle_delay as if it's only used on the rhs of the <= operator. Since that use is probably fairly rare, it seems confusing. I'd rather treat both ##n cb.v <= e; -and- cb.v <= ##n e; as equals when it comes to describing cycle_delay. (Even though your NOTE: is technically correct) (2) Towards the end of 15.14, three paragraphs before 15.14.1: Discussion of asynchronous execution of clocking drives could be misinterpreted as suggesting that the drive blocks until the clocking event. Suggested re-wording: replace It is possible for a drive statement to execute at a time that is not coincident with its clocking event. Such drive statements shall be processed as if they had executed at the time of the next clocking event. The values on the right hand side of the drive statement shall be read immediately, but the processing of the drive is delayed until the time of the next clocking event with It is possible for a drive statement to execute at a time that is not coincident with its clocking event. Such drive statements shall execute without blocking, but shall perform their drive action as if they had executed at the time of the next clocking event. The values on the right hand side of the drive statement shall be read immediately, but the processing of the drive is delayed until the time of the next clocking event DOUG: OK (3) Last paragraph of 15.4: Is it true that we want *all* output clockvars initialised to 'bZ? Surely clockvars that drive a *variable* should be initialised to 'bX? DOUG: This doesn't matter. One can't read the value of an output clockvar. And an output clockvar won't spontaneously update its associated clocking signal - a drive needs to occur first. The default value of the associated clocking signal will be something appropriate to its type, and that will be the initialized value of that signal. Maybe someone can come up with some better wording, to the effect of "Output clockvars that never updated via a synchronous drive have no effect on their associated clocking signal" 15.14.1 Drives and nonblocking assignments ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (1) Suggest replacing the last sentence: This is because reading the input always yields the last sampled value, and not the driven value. with This is because an inout clockvar is in fact an input clockvar and a distinct output clockvar of the same name. Reading an inout clockvar in effect reads the input clockvar of the same name, yielding its most recently sampled value. A clocking drive to an inout clockvar in effect drives the output clockvar of the same name the output clockvar of the same name, so the input clockvar is not immediately updated with the driven value. DOUG: I prefer the original sentence. I think it says everything that needs to be said, with less words. 15.14.2 Drive value resolution ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (1) After the second code example, paragraph beginning "Multiple clocking block outputs driving a net" - is it useful or necessary to add "e.g. through different ports"? DOUG: This could be removed without harm. (2) Same paragraph as (1) above: suggest replacing a variable inside the clocking block that is updated as a nonblocking assignment with a variable inside the clocking block that is updated in the NBA or Re-NBA region with clocking output behavior, as described in 15.14 above DOUG: OK Thanks very much, Jonathan. Those suggestions will help improve things. Just curious: Is another batch of suggestions coming on the Program block changes? Regards, Doug > -----Original Message----- > From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] > Sent: Saturday, February 10, 2007 8:31 AM > To: sv-ec@server.eda-stds.org; Warmke, Doug > Subject: Comments on 890-5.pdf > > I've started to review Doug's latest and very thorough > proposal for clocking blocks and programs (Mantis 890, > document 890-5.pdf). Herewith my comments on the proposals > relating to clause 15, clocking blocks; I'll try to do the > same for the clause 16, programs, proposal in the next > day or two. Many of the points are fairly trivial > nit-picking or suggestions for clearer wording, but there > are a couple of areas that seem to me to need a little > technical clarification. > > Seems to me that considerable thanks are due to Doug > for his major effort on this. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, > Hampshire, BH24 1AW, UK > Tel: +44 (0)1425 471223 Email: > jonathan.bromley@doulos.com > Fax: +44 (0)1425 471573 Web: > http://www.doulos.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sun Feb 11 21:47:44 2007
This archive was generated by hypermail 2.1.8 : Sun Feb 11 2007 - 21:48:18 PST