| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 599
|
| Notify-List |
|
| Category | errata
|
| Synopsis | intermediate variables with @*
|
| State | open
|
| Class | errata-discuss
|
| Arrival-Date | Jul 19 2004
|
| Originator | Eric Mahurin
|
| Release |
|
| Environment |
|
| Description |
In 9.7.5, @* triggers on all variables which are read by the statement. But, why have intermediate variables as triggers. As in the example: always @* begin // equivalent to @(a or b or c or d or tmp1 or tmp2) tmp1 = a & b; tmp2 = c & d; y = tmp1 | tmp2; end Having tmp1 and tmp2 as event triggers seems to serve no purpose other than to have the simulator evaluate this block twice instead of once when a, b, c, or d changes. Also, if intermediate variables (i.e. loop counters) are shared between always blocks, it can cause the simulator to hang in an event loop. If a variable is always assigned (blocking) before it is read within the statement, I don't see why @* needs to imply it. Maybe this could be an optional feature. |
| Fix |
|
| Audit-Trail |
From: Shalom.Bresticker@freescale.com To: eric_mahurin@yahoo.com Cc: etf-bugs@boyd.com Subject: Re: errata/599: intermediate variables with @* Date: Wed, 21 Jul 2004 14:19:11 +0300 (IDT) The block will not evaluate twice, because tmp1 and tmp2 do not change during the waiting period of the @. I think that answers your comment about loop counters also. Regardless, your question has been previously discussed. See the thread beginning at http://boydtechinc.com/etf/archive/etf_2002/0068.html You can find an archive of the full discussion about @* at http://boydtechinc.com/etf/archive/etf_2004/2687.html Shalom > In 9.7.5, @* triggers on all variables which are read by the statement. But, why have intermediate variables as triggers. As in the example: > > always @* begin // equivalent to @(a or b or c or d or tmp1 or tmp2) > tmp1 = a & b; > tmp2 = c & d; > y = tmp1 | tmp2; > end > > Having tmp1 and tmp2 as event triggers seems to serve no purpose other than to have the simulator evaluate this block twice instead of once when a, b, c, or d changes. Also, if intermediate variables (i.e. loop counters) are shared between always blocks, it can cause the simulator to hang in an event loop. > > If a variable is always assigned (blocking) before it is read within the statement, I don't see why @* needs to imply it. > > Maybe this could be an optional feature. -- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Reuse Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 |
| Unformatted |
|
Hosted by Boyd Technology