| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 57
|
| Category | errata
|
| Synopsis | 5: scheduling
|
| State | open
|
| Class | errata-discuss
|
| Arrival-Date | Oct 24 2001
|
| Originator | Shalom.Bresticker@motorola.com
|
| Release | 2001b: 5
|
| Environment |
|
| Description |
Section 5 has major problems. Many agree to this. Unfortunately, we did not succeed to solve them for 1364-2001. In the meantime, vendors are creating facts in their implementations. Detailed descriptions of the problems later. |
| Fix |
|
| Audit-Trail |
From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/57: Section 5 - scheduling Date: Sun, 6 Oct 2002 10:10:10 +0300 (IDT) >Category: errata >Confidential: no >Originator: Shalom.Bresticker@motorola.com >Class: TBD >Description: I promised more details on this. Without going into a lot of detail right now, and without doing a lot of research, I remember the following issues: A. The requirement that nonblocking assignments be executed in the order in which they appear contradicts the scheduling algorithm. There were some emergency last-minutes attempts to find a solution to this, but they did not work out. B. PLI scheduling - I saw an HDLCON 2002 paper by Charles Dawson that seems to discuss this. I think the URL is www.hdlcon.org/1stpl.pdf C. Function execution: is assumed to be atomic. But the algorithm allows interleaving of function calls. That is, if you have fork a = f(0); b = f(1); join then it would be legal to start to execute f(0), stop in the middle, continue with f(1), then return to f(0). The f(1) execution will of course overwrite the values of the internal variables in the f(0) execution, corrupting it. D. On this last one, I seem to be in a minority of one as seeing it as a problem. I see the need for allowing atomic execution of time-less begin-end blocks under certain conditions to guarantee that intermediate variables will not be corrupted. Example: initial begin temp = f(0) ; a = temp ; end initial begin temp = f(1) ; b = temp ; end This is of course for something like non-design code, where the two uses of temp have nothing to do with each other and do not represent signals. I do not want to start a debate on this now, just to mention the issues. Shalom |
| Unformatted |
|
Hosted by Boyd Technology