Subject: Re: Final Assertion Spec -- problem noted.
From: Adam Krolnik (krolnik@lsil.com)
Date: Mon Apr 08 2002 - 11:27:22 PDT
Hi Bassam;
I will admit that I do not understand the implications when I use
the word 'consume' in the context of these discussions.
My concern is only about how the threads of a single assertion
interact. The example you provide about two different assertions
interacting due to one 'consuming' events is outside of the issue
I have. I do not think an adequate review of the interaction of
two threads have been done.
You ask, how do the assertion threads interact with one another:
>(For example say our 2 spawned assertions created at the first req
> and at the 2nd req communicating somehow) .... does it consume
>based on:
> req (req ...done) ? or is it -req- .... req .... -done- ?
assert (req triggers ([1:10];done));
I am suggesting that the assertions should be inorder. The first
req would consume the first done, the second req would consume the
second done. I would identify this as priority based on age (
starting time, etc.)
You write that this can be solved by merging/composition of sequences.
I would be interested in seeing what this would entail. With the
model above, threads of an assertion that overlap in time have
the possibility of being useful. In the proposed model, overlapping
threads have no use because they can sync to the same sequence.
Consider this - if one wants to find one done regardless of how
many threads were started, the Verilog code (and SystemVerilog code)
is much simpler to write than the code to have each thread find
a unique done.
Thanks for the discussion.
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Mon Apr 08 2002 - 11:29:11 PDT