Subject: RE: [sv-ec] Chapter 12 issues
From: Mehdi Mohtashemi (Mehdi.Mohtashemi@synopsys.com)
Date: Tue Feb 18 2003 - 12:47:43 PST
Kevin,
The intended use model for mailbox and semaphore as is donated here is strictly
for inter-process synchronization and communication. What I have seen in the
past specially with Vera users, the abstraction of semaphore and mailbox,
the FIFO ordering, provide a simple yet powerful mechanism for stimulus
generation and checking, specially. The fact that the behaviour is built-in without adding
any user code as well as the unbounded size has been very useful for developers
with regards to synchronization of generation and checking dynamic threads.
Of course these built-in elements may not address everyone's requirements,
but provides abstract building block for the [software] verification code that
will dynamically mimic the rest of the system around the device under test. Within this
context I have also seen interests in placing a bound on a mailbox for test scenario
and sequence/data generation, as well as a few other modes for advanced
software queuing.
We can discuss this in more detail in the conf. call tomorrow.
- Mehdi
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org]On Behalf Of Kevin
Cameron x3251
Sent: Saturday, February 15, 2003 11:28 PM
To: Mehdi.Mohtashemi@synopsys.COM
Cc: sv-ec@eda.org
Subject: Re: [sv-ec] Chapter 12 issues
Why do you think no-one would want to use mailboxes and semaphores to
model hardware, they are things that are built in silicon. The major
difference is that the hardware version has to be a fixed size.
Adding optional limits to the size of these objects allows them to
be synthesized more easily, as does static declaration.
If they are synthesizable, forcing the order of access (FIFO in your
proposal) unnecessarily constrains the behavior.
Kev.
-- mailto:Kevin.Cameron@nsc.com http://www-galaxy.nsc.com/~dkc/
This archive was generated by hypermail 2b28 : Tue Feb 18 2003 - 12:51:56 PST