Re: [sv-bc] Re: Please respond with your #1 SV-BC enhancement priority (due by end of January)

From: David Jones <djones@xtreme-eda.com>
Date: Thu Jan 28 2010 - 07:37:56 PST

I've looked through the few Mantis open for SV-BC. In terms of
productivity, I feel that most of these items are minor.

The one thing that we can do is improve the standard: make it a
rigorous description of the language and explicitly call out places
where vendors may diverge (in informative sections). The preprocessor
has already been mentioned as a candidate for a more precise
description. I like the description of the ANSI C preprocessor given
in K&R.

But really, for end-user productivity, I feel that the onus is now on
the vendors. The base language (for which I am excluding the SV-EC
verification constructs) is fairly complete. There are a few areas for
improvement (VHDL-style configurations, for example) but in terms of
day to day productivity, here's what slows me down:

- Compile times. If I change one line of SV code in the project I'm
working on now, it will be a good 30 minutes to recompile the design.
In contrast, if I change one line of C++ verification code, then it
takes less than a minute to recompile that file and relink. I
understand the issues surrounding Verilog elaboration, and that to
achieve good optimization you really do need to look at the entire
design again even if one line has changed, but surely some
improvements can be made in this area.
- Diagnostics. Most implementations will abort if they detect a parse
error, rather than trying to recover. Certain semantic errors (such as
misspelled identifiers) will also cause a quick abort. In contrast,
GCC will attempt to recover (sometimes well, sometimes not). I'd be
much more productive if I could correct more errors at once.
- Language support. The big three vendors implement three different
subsets of the language. If you're trying to write code that works on
all three then you have a very frustrating time indeed. Most users
won't have this problem - they've picked a tool, and their testbench
runs on that tool. At least until business concerns encourage them to
switch...

None of these areas are things that SV-BC (or SV-EC) can readily fix.
Instead, it's up to the vendors to improve their implementations.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Jan 28 07:38:12 2010

This archive was generated by hypermail 2.1.8 : Thu Jan 28 2010 - 07:38:32 PST