Subject: Re: questions about CBV
From: Adam Krolnik (krolnik@lsil.com)
Date: Tue Apr 16 2002 - 08:24:44 PDT
Hi John;
Thanks for getting back to me..
You wrote:
>From the perspective of CBV, the user has created two threads, both
>of which are looking for the same thing. Since protocol >correspondences
>rapidly become too complicated to predict with pre-defined constructs
>when there are varying priorities, retries, bypasses, etc.,
I agree that assertions become more complex with these various
techniques. One needs to construct (usually) multiple assertions
to deal with these interactions and sometimes extra machinery.
What I am looking at is that two threads should not be able to
progress on the same event. In my example,
{req; [1:10]; done}
If this becomes two executing threads, the second should complete
after (>, not >= ) the completion of the first executing thread.
Is this not possible in a general case of intersection expressions
or noncontiguous cycle expressions?
From my usage, allowing threads of an assertion to track overlapping
sequences without taking the same event allows designers to
write assertions very easy and safely. When threads can match on the
same event it confuses designers and IMO is a degeneration to
only one thread.
>It will be helpful if you can say more about things like the bound on
>the number of outstanding "req"s without corresponding "done" signals.
To me the bound is based on the number of cycles the regular expression
consumes. I usually write time bounded expressions as for simulation
they are more helpful than an error at the end of an expression saying
something timed out. There are uses for constraining the bound of
outstanding events (the number of outstanding threads?) and that sounds
like an attribute of the (executing) expression. One member of the
committee suggested system function to obtain this information:
:Would providing a function to count the number of activations of the
:assertion meet your needs?
: If ($num(a1) == 0) a1:assert ...
: a2: assert( ($num(a2) == 1) && ....
: a3: assert($num(a3) < N+1) && ....
Another attribute type would be an instance number(thread number)
of the assertion. CBV though has local state per thread that would
enable a similar capability without knowing a thread number/reference.
>The threaded assertions are not required all to sync to the same
>set of events. However, if the user codes them to do so, then they
>will. Code can be added to cause the threads to sync to different
>sets of events, but that code is not implicit.
Can you give an example of your last statement? It would be helpful
to see.
>I can comment on "all-match" vs. "first-match" in CBV.
Oh, oh, Professor Havlicek, :) I think I understood your explanation
of first-match, though this doesn't seem to affect how multiple
threads interact, correct? I didn't quite get the constrast between
first-match and all-match.
Thanks John.
Adam Krolnik
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Tue Apr 16 2002 - 08:27:05 PDT