Synplicity/Synplify and Systemverilog support?

A year ago, I heard Synplicity's (RTL synth) Systemverilog support was
terrible.

Altera Quartus-II 8.1 supports Systemverilog quite well (interfaces,
enums, typedefs, unique/priority case, always_comb/always_ff, etc.)
Not everything yet, but very usable.

So how does the current version of Synplicity compare, in terms of
Systemverilog language support? 

On 8 Nov., 08:23, "guestuser1" <guestus...@nowhere.net> wrote:
> A year ago, I heard Synplicity's (RTL synth) Systemverilog support was
> terrible.
>
> Altera Quartus-II 8.1 supports Systemverilog quite well (interfaces,
> enums, typedefs, unique/priority case, always_comb/always_ff, etc.)
> Not everything yet, but very usable.
>
> So how does the current version of Synplicity compare, in terms of
> Systemverilog language support?

9.4L tested still bad. Stay away from Synplicity for 1 year before
testing again. Maybe you'll discover its redundancy or even synplicity
will discover theirs.

On Nov 8, 10:23=9Aam, "guestuser1" <guestus...@nowhere.net> wrote:
> A year ago, I heard Synplicity's (RTL synth) Systemverilog support was
> terrible.
>
> Altera Quartus-II 8.1 supports Systemverilog quite well (interfaces,
> enums, typedefs, unique/priority case, always_comb/always_ff, etc.)
> Not everything yet, but very usable.
>
> So how does the current version of Synplicity compare, in terms of
> Systemverilog language support?

Well, Synplicity had been acquised by Synopsys last year. Synopsys, in
opposite of Cadence and Mentor,
did't adopt SV in own products till to last time. While Cadence and
Mentor collaborated into SV support and moved forward with OVM
initiative, Synopsys concentrates into conventional HDL support only.

Started from QuartusII v7.2 I develop my altera projects in SV only.
QII has a practically usefull synthesable SV subset support. I've
found only one annoyed problem - SoPCBuilder don't still deal with SV
modules :(

Digitally yours,
 =EDikhail Tsvetkov

"cms" <Michael.Tsvetkov@gmail.com> wrote in message 
news:94c10f19-554e-4e4f-8936-315ffc365847@g17g2000prg.googlegroups.com...
On Nov 8, 10:23 am, "guestuser1" <guestus...@nowhere.net> wrote:
> A year ago, I heard Synplicity's (RTL synth) Systemverilog support was
> terrible.
>
> Altera Quartus-II 8.1 supports Systemverilog quite well (interfaces,
> enums, typedefs, unique/priority case, always_comb/always_ff, etc.)
> Not everything yet, but very usable.
>
> So how does the current version of Synplicity compare, in terms of
> Systemverilog language support?
>
>Well, Synplicity had been acquised by Synopsys last year. Synopsys, in
>opposite of Cadence and Mentor,
>did't adopt SV in own products till to last time. While Cadence and
>Mentor collaborated into SV support and moved forward with OVM
>initiative, Synopsys concentrates into conventional HDL support only.

No, that's completely wrong.

Cadence was the *LAST* of the big EDA-vendors to support Systemverilog. 
Synopsys acquired Superlog about 5 years ago, which was the predecessor of 
the IEEE-standard Systemverilog.  VCS has had Systemverilog support for at 
least that long, far in advance of either Mentor Modelsim or Cadence 
Incisive.  Synopsys's other front-end design tools (Design Compiler, 
Formality, etc.) support Systemverilog quite well, and for some time, too. 
(Cadence's LEC also supports it quite well, but I couldn't try the others.)

Cadence and Mentor partnered to produce a cross-vendor methodology, OVM, 
which is a good thing. It's nice to know that OVM will work in more than 1 
simulator, and has *OFFICIAL* support from both.  But they did it because 
both were FAR BEHIND Synopsys in terms of Systemverilog (functional 
simulation) marketshare, not because they 'were ahead of the curve.' 
Synopsys VMM had a de-facto standard until OVM emerged. 

On Sat, 15 Nov 2008 11:45:02 -0800, "atass" wrote:

>> While Cadence and
>>Mentor collaborated into SV support and moved forward with OVM
>>initiative, Synopsys concentrates into conventional HDL support only.
>
>No, that's completely wrong.

Indeed it is; but your correction contains many misconceptions too.

>Synopsys acquired Superlog about 5 years ago, which was the predecessor of 
>the IEEE-standard Systemverilog.

Only of some parts of the language.  Superlog was the progenitor
of many of the design-related features, and of interfaces.
Some of the OOP features of SV came out of Vera (another 
Synopsys product).  But none of that matters any more; SV is
a formal IEEE standard, over 3 years old now and still under
active development (expect a significant revision in 2009).
The history no longer matters very much. 

>Cadence and Mentor partnered to produce a cross-vendor methodology, OVM, 
>which is a good thing. It's nice to know that OVM will work in more than 1 
>simulator, and has *OFFICIAL* support from both.  

Yes.   You will find that the OVM library is written using entirely
IEEE Std.1800-2005 compliant code, with the minor exception of pure
virtual functions which are coded using the modified syntax from
1800-2009.  The "official support" is in the sense that both vendors
claim (correctly) that their tools will run OVM code, and therefore
will support customers if they experience problems in trying to do so.

> But they did it because 
>both were FAR BEHIND Synopsys in terms of Systemverilog (functional 
>simulation) marketshare, not because they 'were ahead of the curve.'

Phrases like "far behind" represent value-judgements that are very
hard to back up.

>Synopsys VMM had a de-facto standard until OVM emerged. 

Neither OVM nor VMM are in any real sense de facto standards.
They are both published, documented, supported class libraries,
and happily both are now open-source.  Both are changing and
developing sufficiently fast that it would be foolish to 
describe either as a standard.  All three big players in this
space are working with Accellera to define interoperability
standards for verification methodology, and that can only
be a good thing for users.

It is *not* a good thing for users when people spread the
kind of half-truth and unsupportable opinion-dressed-as-fact
that has been far too evident in this thread.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

On 2008-11-15, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:
> Synopsys product).  But none of that matters any more; SV is
> a formal IEEE standard, over 3 years old now and still under
> active development (expect a significant revision in 2009).

This sounds interesting, do you happen to have a link to a
webpage with more information about upcoming possible
revisions?

Personally, I'm hoping for a nicer solution to the problem discussed
in for example http://groups.google.se/group/comp.lang.verilog/browse_thread/thread/b517b5f1b94379e7

Andreas

On Mon, 17 Nov 2008 08:34:08 +0000 (UTC), Andreas Ehliar wrote:

>> expect a significant revision [of SV standard] in 2009.

>This sounds interesting, do you happen to have a link to a
>webpage with more information about upcoming possible
>revisions?

Sadly the LRM drafts are under IEEE copyright; you can
pay money for them, but that sounds a bit silly when you'll
probably want to buy the real thing later anyway.

Expect a flurry of conference papers and sundry announcements
during 2009.  The draft is now frozen ready for the formal
IEEE balloting process, in which various key players in the
industry have a chance to examine the new spec thoroughly
and raise any critical objections (and, indeed, to veto some 
proposed changes if they feel that's the only way forward).

>Personally, I'm hoping for a nicer solution to the problem discussed
>in for example http://groups.google.se/group/comp.lang.verilog/browse_thread/thread/b517b5f1b94379e7

To my considerable disappointment, SV interfaces have not
received much attention in SV-2009.  Some tricky issues
relating to type parameterization of virtual interfaces
have been cleaned up - there was a paper about this in
the San Jose Mentor User2User conference recently - but 
the design aspects have not been addressed at all.  It's
high on my list of things I want to lobby for in the
next-next revision, but of course that won't hit the
streets until 2013 or so at the earliest.

There should, however, be some really attractive things
in it that are also fairly easy to implement, so there
will be no excuse for simulator vendors :-) - for example:
- the ability to have a module parameter with no default,
  so that it becomes mandatory to override it at instantiation
  (like you've been able to do in VHDL for 20 years...)
- nicer ways to concatenate unpacked arrays
- improvements in the unique/priority qualifiers for 
  conditionals, making them useful in combinational code
  as well as clocked logic, and providing a new "unique0"
  keyword to match the requirements of "parallel_case"
- improvements in procedural assertions, allowing them
  to be protected against combinational glitches that 
  could otherwise cause false firing
- various improvements for randomize...with {...}

Also look out for...
- lots of cleanup and improvement of LRM definitions;
- complete merger of the Verilog and SystemVerilog LRMs;
- clarifications and enhancements of the functional 
  coverage constructs;
- major enhancements to the assertion language

And a bunch of other stuff that I can't remember....
quite a lot of changes to the VPI (C interface) too,
but that's a bit outside my comfort zone.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

On Nov 15, 10:45=A0pm, "atass" <at...@lajta.com> wrote:

> No, that's completely wrong.
>
> =A0VCS has had Systemverilog support for at
> least that long, far in advance of either Mentor Modelsim or Cadence
> Incisive. =A0Synopsys's other front-end design tools (Design Compiler,
> Formality, etc.) support Systemverilog quite well, and for some time, too=
.
> (Cadence's LEC also supports it quite well, but I couldn't try the others=
.)

Well, well, well. Let's read latest VCS User's Guide, "What VCS
Supports":

 - The SystemVerilog 3.1a language (with some exceptions) as
defined in SystemVerilog 3.1a Accellera=92s Extensions to Verilog

Nothing about IEEE-1800-2005/2007. SystemVerilog 3.1a was predecessor,
you are right.
But it was five years ago (April'2004). And nothing changed! Is it an
advanced support?

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message 
news:j2fuh4dfg0ckic1h8m97lga8cggkps6rbt@4ax.com...
> On Sat, 15 Nov 2008 11:45:02 -0800, "atass" wrote:
>
>>> While Cadence and
>>>Mentor collaborated into SV support and moved forward with OVM
>>>initiative, Synopsys concentrates into conventional HDL support only.
>>
>>No, that's completely wrong.
>
> Indeed it is; but your correction contains many misconceptions too.

My apologies, I was in an aggressive mode when I wrote my original
response.  I do appreciate your patient corrections to my misconceptions!

>>Synopsys acquired Superlog about 5 years ago, which was the predecessor of
>>the IEEE-standard Systemverilog.
>
> Only of some parts of the language.  Superlog was the progenitor
> of many of the design-related features, and of interfaces.
> Some of the OOP features of SV came out of Vera (another
> Synopsys product).  But none of that matters any more; SV is
> a formal IEEE standard, over 3 years old now and still under
> active development (expect a significant revision in 2009).
> The history no longer matters very much.

This is something I did not know, thanks for the correction.

>> But they did it because
>>both were FAR BEHIND Synopsys in terms of Systemverilog (functional
>>simulation) marketshare, not because they 'were ahead of the curve.'
>
> Phrases like "far behind" represent value-judgements that are very
> hard to back up.

I'll admit that was a value judgement.  I used IUS quite a bit over the past 
3 years, and my personal *opinion* (not an objective measure by any means!) 
is that IUS's Systemverilog progress was disappointing until about a year 
ago (IUS61/62.)  That's a sentiment echoed with a lot of engineers who've 
tried building their own Systemverilog testbench in these earlier IUS 
releases.  Basically, if they didn't have a Cadence fellow on hand to guide 
the them around simulator and implementation obstacles, they ended up very 
very disappointed like I did.

Some major features still aren't supported at all (unions come to mind, 
though I guess not too many engineers use them.)
And IUS still has plenty of implementation restrictions: enum-declarations 
are still limited to 'literal constants', i.e. if I want to declare an 
address-map, I can't use an expression of 'BASE + OFFSET', the 
righthand-value must be a literal constant.

Of the features I tried, Questasim's language support (feature-wise) "felt" 
more complete than Cadence.  I never had access to VCS, so I don't have a 
full perspective on Synopsys's idiosyncracies -- I'm sure it has many.  (For 
one thing, it won't compile OVM out of the box , so that can't be a good 
thing...)
A lot of teams feel IUS has better runtime performance for large SoC 
simulations.  (Since ASIC teams generally don't run identical simulation 
environments side by side, a claim like this is inherently hard to verify.)

Having said all that, IUS81 is much much better than the earlier versions. 
No complaints from me now (except for the 2 nitpicks above.)

>>Synopsys VMM had a de-facto standard until OVM emerged.
>
> Neither OVM nor VMM are in any real sense de facto standards.
> They are both published, documented, supported class libraries,
> and happily both are now open-source.  Both are changing and
> developing sufficiently fast that it would be foolish to
> describe either as a standard.  All three big players in this
> space are working with Accellera to define interoperability
> standards for verification methodology, and that can only
> be a good thing for users.

Looks like I drank a bit too much kool-aid from the Synopsys hype/marketing 
machine (and I read too much into John Cooley's user survey)  :)

I was under the impression, which is suspect, that early Systemverilog users 
overwhelmingly selected VCS, because 3+ years ago it was the only (usable) 
offering.  (And because Synopsys was aggressive with pricing the 
Systemverilog early adopters.)  Of those Systemverilog teams, I *assumed* a 
majority of them would have been directed toward VMM, which is the official 
best-practice/methdology for users of VCS/Systemverilog.

> It is *not* a good thing for users when people spread the
> kind of half-truth and unsupportable opinion-dressed-as-fact
> that has been far too evident in this thread.

Agreed.  Indeed, when it comes to the religious EDA-tool wars, I 'll hold my 
tongue in the future :) 

Hi,

In early 2008, Stuart Sutherland presented a paper at DVCON 2008 on the
enhancements to the standard which were approved by the committee up to
that time. The paper can be found at
http://sutherland-hdl.com/papers-by-sutherland.php.

Brad Pierce recently posted on the SV-BC mail reflector, at
http://www.eda.org/sv-bc/hm/8983.html, an updated list of enhancements to
the SV-BC part of the standard (mostly the general and design constructs).

Regarding VCS, the new version (2008.09) supports the IEEE 1800-2005
version of the standard.

IUS82 now supports unions.

I personally feel that Questa has the best implementation of
SystemVerilog, but VCS and IUS are closing the gap.

Shalom Bresticker
Intel LAD, Jerusalem