| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 471
|
| Category | errata
|
| Synopsis | 5.6: Synchronous (Sequential) UDP Scheduling Semantics
|
| State | open
|
| Class | errata-discuss
|
| Arrival-Date | Sep 14 2003
|
| Originator | Stephen Williams <steve@icarus.com>
|
| Release | 2001b: 5.6
|
| Environment |
|
| Description |
This issue has been getting under my skin recently, as I find that there is a significant difference of opinion how the UDP output is supposed to be scheduled when the UDP is synchronous. I'm trying to decide what is right in my own implementation. I have heard now that NC-Verilog and VCS both schedule synchronous udp outputs as non-blocking assignments, but that ModelSim schedules them like blocking assignments. I've heard reasoned arguments on both sides of this, so it is abundently clear to me that this is under-specified by the standard. (Reasonable people case to different conclusions.) I propose that the *synchronous* output of user defined primitives be scheduled as non-blocking assignments. This matches the behavior of the assignment most commonly used to infer synchronous (RTL) logic in the first place, so would lead to more consistent behavior. I suggest that the *combinational* output of user defined primitives are scheduled as normal gate propagation events. Makes sense, and matches commonly expected behavior. -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." |
| Fix |
|
| Audit-Trail |
From: Steven Sharp <sharp@cadence.com> To: Shalom.Bresticker@motorola.com, steve@icarus.com Cc: sharp@cadence.com, etf-bugs@boyd.com Subject: Re: errata/471 Re: udp scheduling semantics Date: Wed, 17 Sep 2003 18:08:02 -0400 (EDT) >Category: errata >Confidential: no >Originator: Steven Sharp <sharp@cadence.com> >Release: 2001b >Submitter-Id: etf >Class: TBD >Description: >Date: Tue, 16 Sep 2003 21:04:06 -0700 >From: Stephen Williams <steve@icarus.com> > >Strictly speaking even ordinary primitive gates are left for the >implementer to guess about, although putting propagation events in >the active queue seems obvious. The *only* constructs that have their >output scheduling explicitly stated are the assignments and the >tran devices. I agree that UDPs are no more or less well specified than other primitives. I also agree that it seems obvious that gate primitive output update events should go in the active queue. However, I am not convinced that this is completely unspecified. Section 5.6 provides details of how various assignments (and constructs equivalent to assignments) are translated into processes and events. The mention of switch processing in 5.6.5 seems to be an anomoly in this section. There is no indication that this section is intended to describe the scheduling implications of all constructs in the language. There are plenty of other constructs that are not mentioned in this section. The section just tries to clarify assignments. Section 5.3 describes the stratified event queue. It also describes specific special cases that are placed in each of the queues other than the active queue. These include all of the cases described in section 5.6 as not going on the active queue, plus some that are not in section 5.6. It is reasonable to assume that anything that is not described as a special case falls into the general case of the active queue. Yes, it would be nice if this were stated clearly, but I think it can be inferred. Note that if you don't make this inference, major portions of the language are left unspecified. For example, there is nothing that explicitly says that an evaluation event for a behavioral process (continuous assignment, always block, initial block, etc.) is scheduled as an active event. Should we assume that a simulator is allowed to evaluate those on the monitor list? >So for errata/471 the solution I proposed is apparently wrong, but >the fault it tries to fix is valid. The correct (I hope) answer is >to explicitly state that the outputs of all primitives, including >user defined conbinational and sequential primitives, are propagated >through the _active_ events queue. I believe that this is the correct answer, but if it is necessary to make this clarification, then there are plenty of other constructs in the language that need clarification as well. The simplest solution would be to add a paragraph at the end of section 5.3 that states explicitly that all other events are added to the active queue. Otherwise something might get missed. It might be necessary to put in a caveat like "unless stated otherwise in their description." For example, I think PLI can schedule variables to change value on the nonblocking assignment queue. A list of the constructs will always risk being incomplete, while a blanket statement will always risk being incorrect. Steven Sharp sharp@cadence.com |
| Unformatted |
|
Hosted by Boyd Technology