Jonathan Bromley's notes on proposal 890-5: clocking blocks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ General notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (1) Throughout the text, ensure correct spelling of the scheduling region name Observed (some instances lack the final 'd'). (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? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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_identfier 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".] (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. 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. 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. 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 <=. 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. (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 (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? 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. 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"? (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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jonathan Bromley, 11 Feb 2007