Subject: Re: [sv-ec] Meeting logistics (19 February) and future.
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Thu Feb 13 2003 - 13:45:53 PST
Section 12 comments:
I have the same objection for semaphores and mailboxes as classes with respect to
declaration i.e. they can only be declared dynamically. As Jay pointed out that is
contrary to previous Verilog types. Since these are primitive objects it seems likely
to me that we will want to be able to synthesize them, and synthesizing things
which are created dynamically is going to be hard.
12.2.1: It says the key-count can be reset at any time, I think that also works against
synthesis. Can we also add an optional maximum-keys value to limit the
size of the bucket? That might help trap a few user errors too.
12.2.3: It says "The semaphore waiting queue is First-In First-Out". I think semaphore
queuing should not have an enforced order, this is another attempt to create order
in the simulator which probably won't be there in the hardware (or won't be required
in the hardware). If they need to be ordered you can create a subclass to do it; maybe
using a mailbox to order the requests.
12.4.2: I would rather not have this function since there is no guarantee that if you
call "num" and then call "get" that there will be no intervening "get" from
another thread making the return from "num" obslete - "try_peek/get" seem
sufficient.
If "num" is to be supported it should only be usuable while the calling thread
has exclusive access to the mailbox - which means adding locking semantics
and defining a "critical section" in some way.
12.4.5: As with semaphores the last sentence ("The mailbox waiting queue is FIFO" )
seems like an attempt to order simulation events unnecessarily. If it needs
ordering create a subclass to do it.
12.6...: Still think ".active" is a better solution, these semantics and syntax will make it
difficult for users reading other peoples' code. The $wait.. functions should
be replaced by syntax using @.
12.8/.1: SV regular events shouldn't be different to Verilog, they should have the same
instantiation semantics. If you want to assign events to events you should use
references instead E.g.:
event foo;
ref event bar = foo;
...
@(bar) // wait for foo
bar = null;
@(bar) // doesn't block
foo = null; // illegal
12.8.2: Is this necessary?
12.9: What's wrong with "@(<variable> or <..." ?
Regards,
Kev.
-- National Semiconductor, Tel: (408) 721 3251 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Thu Feb 13 2003 - 13:48:49 PST