RE: [sv-bc] areas for future work

  

Dave,

Please notice that I first mentioned errata and clarity. If you look in
the old 1364 boyd.com data base, you'll see that there were a lot of
issues there, many still unsolved. These sections entered 1364-2001 less
polished and consistent with the rest of the LRM. Recently, I had two
issues with a certain vendor's simulator where the vendor claimed that
the standard is wrong and/or out of date. There are cases where in
practice vendors have advanced beyond what is in the standard. 

With respect to data types, I was not talking about exotic data types.
But currently you can only use in many places simple nets and maybe
simple variables. What about array elements? What about structure
elements, for example? Why should the standard of 2008 be defined
largely by what was allowed by Verilog-XL way back when?

In general, I think it does not make sense to say that SV is a giant
leap forward in the language, however, we are going to leave a couple of
clauses way back in their 2001 versions.

 

Shalom

 

________________________________

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Rich, Dave
Sent: Wednesday, February 01, 2006 5:47 PM
To: Bresticker, Shalom; sv-bc@eda.org
Subject: RE: [sv-bc] areas for future work

 

Shalom,

I worked on a lot of the semantics for specify blocks before it was a
standard (you can thank or curse me for specparams). And I never
suggested that we remove the gate-level simulation features from the
language. All I was trying to say is that I think the current gate-level
timing features are fine until someone points out a useful area that
needs to be enhanced. Do we need to support dynamic data types with
timing checks; I don't think so, but I'm willing to listen to a good
case for it, just not now. I don't agree with forming a task force just
to come up with enhancements, and I don't think we have the charter to
do that anyways.

Dave

________________________________

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Wednesday, February 01, 2006 12:26 AM
To: Rich, Dave; sv-bc@eda.org
Subject: RE: [sv-bc] areas for future work

 

Dave,

My experience as a user in both my current and previous companies is
that gate-level simulations with timing are not going to go away soon.
Most gate-level cell libraries use these. And even a lot of non-gate
level models depend on specify blocks and timing checks. A typical
example is memory models. Another is behavioral models like PLLs and
other analog models. I suspect you may be out of touch with the field.
It's not enough to talk only with people who write digital fully
synthesizable RTL models or testbenches. 

 

Shalom

 

________________________________

From: Premduth Vidyanandan [mailto:premduth.vidyanandan@xilinx.com] 
Sent: Thursday, January 12, 2006 8:33 AM
To: Rich, Dave; Bresticker, Shalom; sv-bc@eda.org
Subject: RE: [sv-bc] areas for future work

 

Hi Shalom,


This may apply a lot in the ASIC world, although in the world of FPGAs
we are still asking customers to use timing simulation. There are some
aspects that formal verification and static analysis by itself cannot
cover. In our models the most common one is block ram collisions in the
Dual Port memories, this can only be seen in timing simulation and thus
we ask people to run timing simulation still. In the last DVCON I
actually co-presented a paper on this as well.

Our recommendation is do both timing simulation as well as static timing
analysis for FPGA designs.

I can see the need to deprecate the text VCD file due to the size
problems, although I do not think that it should be done for the sole
purpose of not needing timing simulation. Xilinx also uses this VCD file
for power estimation so the decision to deprecate this can put us in a
lot of trouble.

 

Thanks

Duth

 

 

________________________________

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Rich, Dave
Sent: Thursday, January 12, 2006 9:20 AM
To: Bresticker, Shalom; sv-bc@eda.org
Subject: RE: [sv-bc] areas for future work

 

Shalom,

I would hope that you have specific requirements that need to be
addressed. Most people have moved away from using dynamic timing
analysis because it is not accurate enough. And people are now beginning
to replace gate-level simulation with formal equivalence checking

Section 30 of the 1800 LRM is supposed to replace the need for a text
VCD file, which should eventually be deprecated.

Dave

 

________________________________

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Tuesday, January 10, 2006 11:52 PM
To: sv-bc@eda.org
Subject: [sv-bc] areas for future work

 

Hi,

 

There are a few areas in Verilog/SystemVerilog which were not dealt with
very much in both 1364-2005 or 1800-2005, in terms of errata, clarity
and/or enhancements.

The ones which first come to mind are:

-  specify blocks/timing checks: all of errata, clarity, and
enhancements. Nearly everywhere we looked, we found problems here. And
new data types require enhancements. The problem is that most SV-BC
people probably are not well versed in these areas. Either 1800 should
create a new sub-committee for it or SV-BC should create a task force
for it. But we need to find people who are both well-versed in it and
have time and ability to do standards work.

-  UDPs: enhancements. I don't know whether this needs anything, but we
could probably find useful things.

-  VCD: enhancements. With new data types, this is badly out of date.

Thanks,

Shalom

Shalom Bresticker

Intel Jerusalem LAD DA

+972 2 589-6852

+972 54 721-1033

I don't represent Intel