David Smith: Post slides on site
SV-CC: Update VPI submission to
include 3.1a submissions in other committees.
SV-Chairs: Discuss staggering
deadlines and other options for working through all of the issues within the timeframe (or extend timeframe).
SV-Chairs: Record overlaps and document.
David Smith: Verify that the AC extensions that were migrated to EC have been properly accounted for.
Peter Flake: Look at Operator Overloading and extending to Function/Task overloading.
Arturo Salz: Check consistency of
use of $ in passing unbounded range and in queues
Alec Stanculescu - Fintronic
Alok Kuchlous - Synopsys
Amadies Sun
- Novas
Arif Samid - Synopsys
Arturo Salz -Synopsys
Brad Pierce - Synopsys
Cliff Cummins - Sunburst Design
Connie O'Dell - Independent (Phone)
Dave Rich - Synopsys
David Smith - Synopsys
Doug Warmke
-
Faisal Haque
- CISCO
Francoise Martinolle - Cadence
(Phone)
Ghassan Khoory - Synopsys (Phone)
Jay Lawrence - Cadence
Jayant Nagda - Synopsys
Karen Pieper - Synopsys.
Mehdi Mohtashemi - Synopsys
Neil Korpusik - Sun
Oz Levia
- Synopsys
Richard Newell - Aptix
Rishiyur
S. Nikhil - Bluespec
Steve Wang - Axis
Stu Sutherland - Sutherland HDL
Surrendra Dudani
- Synopsys
Vassilios Gerousis
- Infineon
Reviewed agenda.
During the meeting the slides were reviewed (available on SV site).
Package proposal is close to being
approved. Some new input will be considered, voted on, and, once approved, sent
to the full SV-BC.
Vassilios: Are packages part of
separate compilation?
Karen: Packages are one of the
solutions. With packages there is no limitation on root. Need to handle some of
the other problems with $root that packages do not address. Separate root helps
to address this.
Jay: Something like packages is
necessary but we will not be able to remove $root.
Karen: Namespace, packages, etc are
3 different names for this same thing.
During the meeting the slides were reviewed (available on SV site).
Arif has
taken Stephen's role as co-chair.
All extensions have been submitted.
Jay: Reduced to about 16 submissions
and one open errata. So, given that time line are you
comfortable with accomplishing this?
Faisal: There are a number that
group together. It is not as bad as the 3.1 schedule.
Arif:
There is already some consensus on a number of issues.
Faisal: In 6-7 meetings we should
be able to handle this.
Jay: There will be a new full time
representative on SV-AC from Cadence.
During the meeting the slides were reviewed (available on SV site).
Jay: Were donations actually
received?
Ghassan:
We have received 3 donations from Novas, Synopsys, and
During the meeting the slides were reviewed (available on SV site).
Jay: Are the AC extension in the
list of extensions.
David: Need to check on the AC
extensions that were migrated to EC and make sure that we have taken care of
them.
During the meeting the slides were reviewed (available on SV site).
Constraints Enhancements (Slide 4):
Alec: Can you give hint why foreach would be better than for loop?
Arturo: There is no for loop usable
with constraints. Iterate for declaration.
Jay: All of the Perl
hacks will like the foreach outside of constraints.
Random Sequence Generation (Slide
6):
Karen: 94 vs
6 ??
Arturo: Each rule has its own
distribution wieght (not have to add to 100).
Nikhil:
Is this a context free generation?
Arturo: Yes. Could generate an
infinitely recursive rule.
foreach Statement (Slide 7):
Doug: The foreach
only works on unpacked?
Arturo: Correct
Karen: Do you take a consideration
of the width of j.
Arturo: Yes. It is an implicitely declared variable.
Jay: Is this different than
original proposal (multiple dimension)?
Arturo: No it is there.
Alec: The multi-dimension makes the
foreach different than the for.
Queues (Slide 9):
Nikhil:
After prepending the indices get renumbered?
Arturo: Yes. There is some
assumption of constant time.
Nikhil:
Will queues subsume the list in the appendix?
Arturo: There is still a
difference. You cannot get the pointer to elements in the middle. Queues are
optimized to work on ends.
Karen: Does foreach
work on this?
Arturo: Yes.
Jay: Not sure concatenation syntax
works with this.
Arturo: It is already there for
arrays.
Jay: But there is ambiguity. We can
deal with it in committee.
Dave: Most of the syntax came from Superlog and has been there for four years.
Bit-stream casting (Slide 10):
Arturo: Request from CISCO. Simple
extension of what is already there.
Francoise: Why is pack/unpack
useful?
Arturo: Common to use in networking
to serialize.
Arif: Not
just networking.
Francoise: Would it be easier to
write a function to do this?
Arturo: Philosophical. It is really
complex to write this and error prone.
Doug: The LRM has to be really
clear about this representation of this so that it can be written and read from
one to another.
Dave: The actual bit pattern is not
what is important.
Jay: The issue is only on transfer
between different vendors.
Alok: Is
the order of bits defined in the queue?
Arturo: It is.
Dave: There is a specific order of
how to access the bit order in the arrays.
Arturo: The bit order is not
implementation but in the language.
Reacting to Assertions (Slide 13):
Alec: How is this expect different
than assertions?
Arturo: The assertion is not in the
procedural code.
Karen: Could you say "expect boolean_statement" and then check in reactive region.
Arturo: It has to be a property. If
you can convert the Boolean to a property then it works.
Jay: Where you are going is boolean invariance.
Arturo: Would have to put this in
an always block.
Jay: Before we only allowed boolean?
Surrendra: This is a blocking
statement.
Jay: In an immediate assertion we
do not allow sequences.
Arturo: This starts the sequence at
the clock edge.
Vassilios: This can be used in a
module not just a program block.
Arturo: You can put it there but it
will be evaluated in the observe region.
Virtual Interfaces (Slide 14):
Arturo: Request from Sun.
Nikhil:
The difference is that this is not instantiated?
Arturo: This is an alias to an
existing interface and does not create a new interface.
Doug: Why not use a ref?
David: We have not defined the use
of ref except on arguments.
Arturo: It would be confusing since
then you would expect refs on any data type.
Karen: Is this for testbenches?
Arturo: Yes.
Neil: It is used a lot.
Jay: Why not allow interfaces as
arguments?
Dave: This is an elaboration issue.
Arturo: You can create an array of
interfaces but cannot use a variable index.
Alok:
This does not allow static elaboration.
Dave: This interface has to be
instantiated.
Jay: This seems to be passing
interfaces as arguments.
Brad: Is this one of the 1364
proposals?
Jay: We have always held that
interfaces and modules are the same. We have proposed modules as ports. This is
an interesting extension.
Vassilsios: This is important to understand that this request comes from a user.
During the meeting the slides were reviewed (available on SV site).
Operator Overloading (Slide 18):
Jay: You mean that it is not for
the built-in types.
Arturo: That is a typo. It means
the operators on built-in types cannot be overloaded.
Jay: VHDL allows for disambiguation
on return types.
Nikhil:
Can you have functions which are disambiguated by type?
Arturo: Does this allow generic
overloading?
Dave: It only works with operators.
Go read it.
Nikhil:
This is a point solution. I would like something more general, but I am not
volunteering.
Vassilios: Can you have Peter look
at this?
Jay: Let the slippery slope begin.
Hardware functions (Slide 19):
Jay: Is this just syntactic
replacement with no new semantics?
Arturo/Dave: Yes
Jay: They have no names so cannot
debug.
Dave: They do have names within the
module. The spec includes naming conventions.
During the meeting the slides were reviewed (available on SV site).
NBA Assignments (Slide 3):
Jay: What does after observe region
mean?
Brad: In the reactive region.
Arturo: Is it scheduled in the
reactive region or as an NBA?
Surrendra: As an NBA.
Property Assumptions (Slide 4):
Karen: Can assume be embedded in a
regular module? Is it assumed that simulation tools will use?
Surrendra: It can be used there.
The simulation can use it.
Alec: It is easy to check as
assertion but difficult to happen all the time.
Surrendra: This is already being
used.
Alec: The simulator must make sure
that the constraints are held.
Jay: Seems like a lot of overlap
with constraints.
Surrendra: Customer (Motorola)
wanted a simple mechanism. This requires no manual control to optimize.
Sequential constraints in
Constraint block (Slide 6):
Jay: Can they be sequences?
Surrendra: Yes. The can be
converted to boolean
constraints.
Jay: At any cycle can look at it as
a boolean but need to do reachability analysis.
Surrendra: This is the same as
solving boolean constraints on
each clock tick. This allows it to be specified more simply. This provides
manual control where it can be processed.
Access to Sampled Values (Slide 7):
Jay: So if used $sampled with event
then it is used to do sampled so can use anywhere?
Surrendra: Yes.
Jay: What if same variable sampled
by multiple expressions?
Surrendra: So will use all of them
and use as appropriate.
Arturo: No different then using in
clocking domain. This is Adam's proposal. There is one character difference.
Passing unbounded range (Slide 9):
Jay: Is the use of $ for unbounded
with Queues investigated?
Arturo: This needs to be looked at.
Improved messaging (Slide 10):
Surrendra: The slide has $sampled
which is incorrect (as is the rest of the slide. This is a request but there is
no submission.
Arturo: Could we just use bind?
Surrendra: Bind is not suited to
this.
During the meeting the slides were reviewed (available on SV site).
Alok: The
VPI always follows the language so 3.1a is not there.
Karen: How long is it?
Alok: 30
pages. It uses the existing object model.
Stu: Any new VPI functions?
Alok: No
new functions but just some new types.
Stu: It will be real important to
have 3.1a included in the VPI extensions.
During the meeting the slides were reviewed (available on SV site).
Jay: There was an issue in SV-BC to
extend VCD.
Karen: We left it open as an item
for future work.
Jay: Was there any consideration
for lifetime of variables. We now have variables that come and go. Does the
database account for this. This is already a problem
with functions.
Amadies:
Will look into the answer.
Alec: This is Novas's
API?
Alok: Yes
it is.
Namespace/Package
During the meeting the slides were reviewed (available on SV site).
DPI Exported Task
During the meeting the slides were reviewed (available on SV site).
David: Dare we ask if you had
System-C in mind?
Doug: That plus VHDL etc..
Jay: May become important during
discussion on accelerated testbenches.
Arturo: Can the export declarations
return values?
Doug: Yes
Arturo: How do you handle the
value?
Dave: Void functions can be used to
distinguish between things that consume time (tasks) and those which do not (void
function).
Alec: Not necessary that task
consumes time.
Dave: Does not make a problem.
Alec: Why not anaylze
the C code to determine?
Doug: DPI requires separate
compilation so it is an issue.
Cliff: Like idea of being able to
call tasks from C code. This is a question for Dave Rich since Superlog has it. I assume that a task does consume time and
provide no time attribute if it does not.
Doug: Functions are now a lot
closer to tasks than before; major difference is in time consumption.
Jay: In the details of proposal do
we just need to create export task instead of attribute.
Nikhil:
Use the task and function terminology.
Jay: Change DPI to use task and
function which references consume and not.
Cliff: How close are packages to
VHDL packages?
Doug: Yes.
Cliff: Why not use the same
terminology.
Jay: Not been discussed. It could
be. We are voting to move to BC.
Francoise: There are differences.
Arturo: If it looks like VHDL it
should be VHDL.
Nikhil:
Are the differences due to improvements or language basis?
Dave: Some of the differences come
from hierarchical.
Jay: Some things were intentionally
left out since the Verilog community did not want compilation units.
During the meeting the slides were reviewed (available on SV site).
Oz: What is the business advantage?
Nikhil:
Coding at higher level (comprehension, easier). Others we can explore off-line.
Nikhil: Bluespec goes into a different direction than other behavioral
synthesis.
Surrendra: This can be expanded
into SystemVerilog directly?
Nikhil:
Yes. This is more efficient since the compiler can type check this.
Alec: Do you have ability to
specify where and how the tags should be encoded for synthesis?
Nikhil:
Since pack and unpack you can choose whatever you like.
Karen: The donation has it defined
in it.
Alec: Instead of comment do you
want to explicitly show the opcode (in the
example).
Nikhil:
The example is shown expanded. The donation includes the way that the taggedunion can be expanded.
Nikhil:
The canonical representation needs to be specified in the LRM so that it is
known.
Oz: In the example is there
coverage in the case across the tags.
Nikhil:
Whatever Verilog does can still work.
Jay: We would have to do to this
form of case as we have done to the regular case (priority, default, random,
etc...)
Jayant: What are the other items
you are considering?
Nikhil:
Parametric polymorphism (write fcns where parameterizing over the type of the function - foreach, sort are examples). Atomic state transition (term
rewriting system - design as collection of rules and actions). We need to take
more time to consider how these ideas fit within SystemVerilog.
Arturo: We have already taken some
of these ideas. We have adopted some ideas into SystemVerilog from Haskell,
etc...
Jayant: What is the main goal of Bluespec?
Nikhil:
Our goal is to describe at a higher level. Going to Behavioral level describing
in terms of software rules makes it hard to figure out how to map to hardware.
We are using the higher concepts to describe hardware.
Vassilios: Any issues?
Jay: This looks like a heck of a
lot of material to get through in 3 months. It is also not clear that the
amount of material relates to the goals for 3.1a. The goals were meant to be stabilize. We are dealing with a lot more extensions instead
of errata. It is not clear we are actually focusing on stability.
Stu: But 3.1 was not complete; VCD
for example.
Jayant: This is about 1/4th or
1/5th then last year; compared to that this is pretty small.
Jay: But the time frame is less.
Doug: Why does the board need to
take so much time?
Jay: It is in the bylaws.
Vassilios: The two months are for
us to review. Nothing says the date is golden. We can change this is required.
David: There is less donated and
much work has been done to make it consistent with Verilog.
Dave: Can we stagger the deadlines
for each of the committees? Having the same deadlines makes it harder to review
the other work.
Vassilios: We will consider that.
We need to discuss this. I did not give a firm deadline to the board.
Vassiliois:
We need to increase the synchronization between the committees. This means that
some items will be handled between committees.
Jay: Appears to be more overlap
within the committees. We need to consider if we are doing the same thing
in multiple places. For example overlap of assume with constraints, automatic variables,
etc... Assume leads to deadends much easier than random
constraints do; requires reachability.
Arturo: You either have an
explosion due to reachability or due to deadlocks. We
picked deadlocks.
Vassilios: I have made a proposal
to the Accellera board of the timeline for all Accellera standards to migrate
to the IEEE. This will take a couple of months to work through.
I am also excited to see donations
from different companies and from a startup. Bluespec
is interesting since it is mathematically based.
Stu: It would be helpful to get
more notice on the face-to-face meetings. At least 3 weeks would be helpful.
Jay: We had a month at least.
Stu: Need it to be less vague.
Vassilios: The planning was done
earlier. The location was somewhat later. We will try to get the details out
earlier.
Alec: The Accellera board could
work faster than 2 months.
Vassilios: The board is working
with the IEEE societies which iswhat will take the
time. There are a number of societies that have interest in standards and we
need to establish a formal relation with how items are transferred.
Alec: Wasn't this done with 1364?
Vassilios: We are working with IEEE
to work on having things migrate more quickly through the IEEE process. This
will take modifications both in the IEEE and Accellera process. We want to have
a fast track.
Jay: Are there other examples of
such issues.
Vassilios: IEEE recognizes that
this is a requirement.
Mehdi: The European standards are
much faster.
Cliff: Hold the next meeting up
Vassilios: If Sun goes then we will
go.