Subject: Re: [sv-ec] final block proposal to SV-EC.
From: Dave Rich (David.Rich@synopsys.com)
Date: Tue Jan 28 2003 - 07:50:31 PST
Steven,
I agree with you on just one point, but not the others.
Think of the final block as group of function calls at the end of
simulation.
initial begin // pseudo example
wait(END_OF_SIMULATION)
final_block_in_module1();
final_block_in_module2();
final_block_in_module3();
...
$really_finish;
end
Having them execute as a single thread (as if they were in a single
begin/end block shown above) means that you don't need to special case
anything. You can optimize all you want, but you have to preserve the
sequential execution of each statement within the thread. I do agree
with you that this should not preclude executing on the fanout a variable.
Since final blocks can only have function_statements in them, they
cannot create threads with fork/join. And since they cannot have
event_controls in them, they must finish within a single delta cycle
(infinite looping statements excepted).
I probably should have explained a little more the reasoning behind
"deterministic, but arbitrary" execution of final blocks. I lifted this
wording from the section on indexing through an associative array.
Guaranteeing the ordering of final blocks helps golden logfile compares,
since final blocks are most often used for reporting statistics. The LRM
does not need to define the ordering, but the implementation should
define rules that will preserve the ordering between runs. Order of
compilation is one example, order in the hierarchy tree is another.
Dave
Steven Sharp wrote:
>I have an issue with the statement
>
>"Since final blocks cannot have any delay, they execute as a single thread."
>
>I assume that this is an attempt to say that the final block will not suspend
>during execution. However, the final block can write to variables, which
>may have fanout. A simulator may execute fanout of a variable immediately
>as part of updating its value. Preventing this requires either not doing
>such optimizations anywhere, or treating writes to variables in final blocks
>differently from other writes to variables. The first impacts performance,
>and the second requires writing special case code, which is an implementation
>and maintenance burden.
>
>The statement is false anyway, since the final block can contain a fork-join
>as long as the subprocesses contain no delays. This would require running
>multiple threads, and might require suspending the final block thread until
>the child processes complete.
>
>
>
>I also have an issue with the statement
>
>"The ordering of execution of multiple final blocks is deterministic, but
>arbitrary."
>
>What is the intended meaning of this statement? As written, it is simply
>true, since all software is deterministic (even if we don't always understand
>the conditions that led to its behavior). It doesn't even mean that the
>order will be repeatable from run to run, since it could be deterministic
>but based on the current system clock time or how many runs have been done.
>How could you distinguish this from the order being nondeterministic?
>
>Steven Sharp
>sharp@cadence.com
>
>
>
>
-- -- Dave Rich Principal Engineer, CAE, VTG Tel: 650-584-4026 Cell: 510-589-2625 DaveR@Synopsys.com
This archive was generated by hypermail 2b28 : Tue Jan 28 2003 - 07:51:16 PST