Subject: TBV WG telecon meeting minutes, July 18, 2003
From: Jayaram Bhasker (JBhasker@esilicon.com)
Date: Sat Jul 19 2003 - 19:14:00 PDT
TBV WG telecon meeting minutes, July 18, 2003
Attendees:
Erich Marschner, Cadence
Francoise Martinolle, Cadence
J. Bhasker, eSilicon
1. FM raised the issue of what happens when two assignments try to write to a fifo at the same time.
It was agreed that it was reasonable to assume standard VHDL resolution semantics, which is, if no bus resolution
function is associated with the signal, then it is an error, if not, the bus res func is called to determine the
effective value which is then stored in the fifo.
2. EM raised the issue of whether fifos of fifos were allowed or not. Clearly, we would want to want allow fifos having
any composite objects, including a fifo itself. A follow-up question from EM was whether a copy of composite obj
is stored or a reference to the composite object is stored in the fifo. It would seem reasonable that a reference to
the composite obj (incl a fifo) be stored in the fifo. A side-effect of this is that a user can modify the contents of the
composite objects if the user had a reference to it without directly affecting the fifo.
3. EM made the suggestion that we allow assignment semantics to fifos in addition to push/pop (he prefers insert/remove
instead of push/pop). The idea was that with a single assignment, a stream of values on a signal could be stored in a fifo.
This seems like a very useful suggestion. So an assignment to a fifo is treated as a push on the fifo. A reference of the fifo
in a RHS invloves reading the topmost item in the fifo (without deleting it).
4. FM noticed that while for assoc arrays, subprograms were used, for the others, attributes were used to implement
the operations. Her issue was whether they ought to be consistent. I explained my rationale behind this - basically
would like to implement whatever is the easist to use - which in my opinion is the attribute style - but had to resort
to subprograms for assoc arrays because there was no clean way to implement the traversal operations using attributes.
5. FM asked how list traversals can be performed and how a list can be dumped.
6. FM suggested that for sequentail-blocks (fork-join) that there be a mechanism to kill a seqblock or to suspend a seqblock.
7. FM also suggested that the labels for seq blocks be made optional within a fork-join and be given implicit indices, starting
from 0 (index name being the fork-join label), so that a user can write a for-loop and query the status of the seqblocks.
Labels would still be allowed on seqblocks but they would be like an alias name.
8. FM suggested that we add dynamic processes to the list of enhancements.
9. FM pointed out the the resolution method specified in TBV7 was incorrect (second last para). The correct interpretation
is that the multiple events occurring at the same time are always resolved using a predefined resolution function, which is,
resolving to one event.
10. FM suggested that a wait stmt of the form:
wait for A, then B, then C, then D;
would be useful. At present, this can easily be achieved by writing multiple wait stmts. Would like feedback from others.
11. FM suggested that we use an operator (such as that used in Verilog) to indicate a event occurrence. FM later agreed that
'CAUSE_EVENT was more descriptive of the action than any kind of operator symbol that we may come up with.
12. FM suggested making event typeless - remove the type info as it is redundant.
13. FM clarify: signal event can only be connected to another signal of type event.
14. FM: Not all aatributes need to be supported for events. List the ones which we should.
Next WG meeting: Aug 1, 12:00-1:30EST (9:00-10:30PST).
- bhasker
------
J. Bhasker, eSilicon Corp
1605 N. Cedar Crest Blvd, Ste 615, Allentown, PA 18104
jbhasker@esilicon.com, 610.439.6831, 610.770.9634(fax)
This archive was generated by hypermail 2b28 : Sat Jul 19 2003 - 19:15:13 PDT