Quartus II 7.1 SystemVerilog support, complaints disguised a

[Edmond Coté]

Well, I decided to give QII 7.1's SV support another go this morning.
I had originally spent a fair deal more time evaluating 6.1's support
and it fell short in many respects, so short in fact that I uncovered
3 interface related synthesis issues that Altera's FAE assured me
would be fixed in 7.1.

The first error I have for you is shown below. Last time around, I
switched all "const bit" declarations to `define - I don't feel like
doing that today ...

package alu_package;
const bit [2:0] alu_add = 3'd0;
endpackage // alu_package

Error (10170): Verilog HDL syntax error at alu_package.sv(2) near text
"const"; expecting an identifier ("const" is a reserved keyword )
[...]

The second error I got is:

always_comb
begin
request.address = '0;
for (integer i=0; i<NUM_MASTER; i++)
if (request_oe)
request.address = request_address;
end

Error (10170): Verilog HDL syntax error at smp.sv(50) near text
"integer"; expecting an identifier ("integer" is a reserved keyword )
[...]

For this error, you can declare 'i' outside of the loop and it works.
Unfortunately, I have a dozen of these loops spread out and I would
have to declare multiple loop variables, e.g., i, j, k, etc. - again,
I don't have the time, or patience, to work around that today (... and
did I mention I have access to a Precision RTL license?)

Regarding the above loop, would someone, ahem, please implement
modport expressions (section 20.4.4 of IEEE 1800-2005) already?

These comments will make their way eventually to Altera. They were
responsive last time around and they seem to be making some progress.
With XST 10 rumored to support SV synthesis, I think it'll only be a
matter of time before we start seeing some solid tools emerge.


-- Edmond Coté

 

[Jonathan Bromley]

Edmond Cote wrote

<a tale of woe and disappointment about SystemVerilog tool support>

Regarding the above loop, would someone, ahem, please implement
modport expressions (section 20.4.4 of IEEE 1800-2005) already?

I've been complaining about exactly this both publicly and
privately for at least two years now, and no-one seems to be
terribly interested. This completely mystifies me, since
modport expressions are one of the most obvious contributions
to parameterisable/configurable design in SystemVerilog.

Credit to QuestaSim for gaining this feature in the 6.3 beta
release, which I believe will be "going live" soon. But it's
not a lot of use until the support is widespread across
many tools and a complete tool chain.

These comments will make their way eventually to Altera. They were
responsive last time around and they seem to be making some progress.
With XST 10 rumored to support SV synthesis, I think it'll only be a
matter of time before we start seeing some solid tools emerge.

All together now....

THE SYNTHESISABLE FEATURES OF SYSTEMVERILOG ARE THE EASY PART.

Support for interfaces raises one tool implementation headache -
synth. tools then are, for the very first time, obliged to
process just one particular special case of dotted
(hierarchical) names - but, in every other respect, the
whole thing is pretty straightforward. There is some
stuff that is potentially tricky - nested modules, anyone? -
but even that has a near-equivalent precedent, in VHDL blocks.
Wildcard ( .* ) port connection syntax will surely impose some
constraints on compilation order and source code visibility,
but I'm sure users would be prepared to live with some minor
tool-specific restrictions of that kind in order to reap the
benefits of the new constructs.

SystemVerilog's synthesisable design features offer big benefits
that designers can adopt easily, incrementally and with minimal
risk. I am completely unable to understand why there hasn't
been a huge outcry by designers wanting support for these
features NOW, not in version N+2 of whatever tools - especially
in view of the vigour and enthusiasm with which the
verification community has bought in to SystemVerilog's
OOP and modelling extensions.

Edmond's complaint is almost the first time I've seen anyone
here publicly asking for such support. C'mon, denizens of
Verilog-land - are you *so* conservative, *so* set in your
ways, *so* satisfied with the tools and techniques you have
been using for a decade and a half, that you really don't
want to push your tool vendors into supporting stuff that
could make your life much better?

I'm speaking strictly for myself here. Thanks for letting
me get all that off my chest
--
Jonathan Bromley

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.

 

[Kevin Neilson]

Jonathan Bromley wrote:

Edmond Cote wrote

a tale of woe and disappointment about SystemVerilog tool support

Regarding the above loop, would someone, ahem, please implement
modport expressions (section 20.4.4 of IEEE 1800-2005) already?

I've been complaining about exactly this both publicly and
privately for at least two years now, and no-one seems to be
terribly interested. This completely mystifies me, since
modport expressions are one of the most obvious contributions
to parameterisable/configurable design in SystemVerilog.

Credit to QuestaSim for gaining this feature in the 6.3 beta
release, which I believe will be "going live" soon. But it's
not a lot of use until the support is widespread across
many tools and a complete tool chain.

These comments will make their way eventually to Altera. They were
responsive last time around and they seem to be making some progress.
With XST 10 rumored to support SV synthesis, I think it'll only be a
matter of time before we start seeing some solid tools emerge.

All together now....

THE SYNTHESISABLE FEATURES OF SYSTEMVERILOG ARE THE EASY PART.

Support for interfaces raises one tool implementation headache -
synth. tools then are, for the very first time, obliged to
process just one particular special case of dotted
(hierarchical) names - but, in every other respect, the
whole thing is pretty straightforward. There is some
stuff that is potentially tricky - nested modules, anyone? -
but even that has a near-equivalent precedent, in VHDL blocks.
Wildcard ( .* ) port connection syntax will surely impose some
constraints on compilation order and source code visibility,
but I'm sure users would be prepared to live with some minor
tool-specific restrictions of that kind in order to reap the
benefits of the new constructs.

SystemVerilog's synthesisable design features offer big benefits
that designers can adopt easily, incrementally and with minimal
risk. I am completely unable to understand why there hasn't
been a huge outcry by designers wanting support for these
features NOW, not in version N+2 of whatever tools - especially
in view of the vigour and enthusiasm with which the
verification community has bought in to SystemVerilog's
OOP and modelling extensions.

Edmond's complaint is almost the first time I've seen anyone
here publicly asking for such support. C'mon, denizens of
Verilog-land - are you *so* conservative, *so* set in your
ways, *so* satisfied with the tools and techniques you have
been using for a decade and a half, that you really don't
want to push your tool vendors into supporting stuff that
could make your life much better?

I'm speaking strictly for myself here. Thanks for letting
me get all that off my chest

I checked out the section on modports. That looks great--I've long
wanted a way to create variable port maps without using lame `ifdefs.
But I don't know if complaints to vendors are useful. I started writing
emails as soon as Verilog 2001 was available, but it was like five years
before FPGA tools started supporting 'generate', and support is still
limited in many tools. So I am not holding my breath for rapid
SystemVerilog adoption. I am pleased with Modelsim's support and happy
with Synplify's limited support and wouldn't dare to hope for much more.
-Kevin

 

[Edmond Coté]

On May 16, 4:10 pm, Jonathan Bromley &lt;jonathan.brom...@MYCOMPANY.com&gt; wrote:

[...]

Regarding the ".*" feature, once you instantiate two identical blocks
in a top-level module, it becomes useless - except for clock, reset,
and enable lines - but I would never risk it.

For example:

wire d_a,q_a;
dff dff_a(.*); // would need to be ".*_a" to be of any value

wire d_b,q_b;
dff dff_b(.*) // ".*_b"

Better yet:

dff_if dff_a_if();
dff dff_a(.*, dff_a_if.dff);

dff_if dff_b_if();
dff dff_a(.*, dff_b_if.dff);

Even better yet (embed the logic in the interface):

dff_if dff_a_if(...);
dff_if dff_b_if(...);

I'm sure all of this has been proposed before, but I figure I might as
well re-iterate.

Credit to QuestaSim for gaining this feature in the 6.3 beta
release, which I believe will be "going live" soon. But it's
not a lot of use until the support is widespread across
many tools and a complete tool chain.

I'll make a mental note of that... Though unfortunately, ever since
Mentor updated their support site (last week?), I am no longer able to
download software releases for my test machine using my SupportNet
account. Of course this is nothing but a formality, but never
underestimate how bureaucracy reins in academia

Edmond's complaint is almost the first time I've seen anyone
here publicly asking for such support. C'mon, denizens of
Verilog-land - are you *so* conservative, *so* set in your
ways, *so* satisfied with the tools and techniques you have
been using for a decade and a half, that you really don't
want to push your tool vendors into supporting stuff that
could make your life much better?

As I alluded to, I am an "exceptional" product of academia. Prior to
this project, I had a good handle of VHDL and just decided to try
something new - much to the discontent of those in charge. The good
news is that after much convincing (ie. I'm not working in VHDL
anymore.. deal with it) and all the heartache it caused (ie. no
hotline to a Mentor FAE's.. well.. without much bureaucracy), those
"in charge" have finally decided to take a look at what's new on the
Verilog front.

Truth is, it's common sense that most companies will not tolerate this
type of risk. Come August or September when I'll be out looking for
work, I certainly doubt that I'll be pushing SV as much as I am today.


-- Edmond Coté

 

[Jonathan Bromley]

On 16 May 2007 21:00:08 -0700, Edmond
Coté &lt;edmond.cote@gmail.com&gt; wrote:

Was this superb pun intentional?

never underestimate how bureaucracy reins in academia

reigns in? reins-in?

and yes, I've been there, and I've no need to (under)estimate
because I've seen it first-hand...

Truth is, it's common sense that most companies will not tolerate this
type of risk. Come August or September when I'll be out looking for
work, I certainly doubt that I'll be pushing SV as much as I am today.

Yeah... but it's precisely the well-known risk-aversion of industry
that motivated the development of SystemVerilog so that it could
be adopted incrementally, so that the risk at each step is not only
manageable but also can easily be worked-around if things don't
work out right. And the crazy thing is that the design subset of
SV does indeed have this valuable incremental-adoption property,
but it has been largely ignored by the user community; whereas
the verification extensions, which demand radical risk-taking
on the part of adopters, have been taken up eagerly.

It feels like going to a building site and finding the surveyors,
architects and building inspectors using the latest high-tech
tools like laser levels, GPS surveying and X-ray nondestructive
testing, while the builders are still using bamboo scaffolding
and mud bricks.

Thanks for the insights and viewpoint.
--
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.

 

[Mike Treseler]

Jonathan Bromley wrote:

It feels like going to a building site and finding the surveyors,
architects and building inspectors using the latest high-tech
tools like laser levels, GPS surveying and X-ray nondestructive
testing, while the builders are still using bamboo scaffolding
and mud bricks.

Exactly.
The computer science guys may figure out
gates and flops before the hardware guys
figure out text description and verification.
The architects and building inspectors will
eventually specify steel.

-- Mike Treseler

 

[Edmond Coté]

On May 17, 4:47 am, Jonathan Bromley &lt;jonathan.brom...@MYCOMPANY.com&gt;
wrote:

Was this superb pun intentional?

never underestimate how bureaucracy reins in academia

reigns in? reins-in?

Oh!, how I wish I was that clever. That is a very good
observation ...

-- Edmond Coté

 

[Edmond Coté]

On May 16, 4:10 pm, Jonathan Bromley &lt;jonathan.brom...@MYCOMPANY.com&gt;
wrote:

Credit to QuestaSim for gaining this feature in the 6.3 beta
release, which I believe will be "going live" soon. But it's
not a lot of use until the support is widespread across
many tools and a complete tool chain.

I'm not sure if this was implied, but I was informed that the recently
released ModelSim 6.3, including the free PE edition, also supports
modport expressions.

-- Edmond Coté

 

[Xilinx user]

Yay! A fellow Systemverilog person! I classify myself as a
'dabbler'/novice,
because all my practice was done in the free Modelsim 6.2c Xilinx Edition.
(6.2b and later is a step up from the bugs in 6.1g and earlier, which is the
latest offered by Altera.)

"Edmond Coté" &lt;edmond.cote@gmail.com&gt; wrote in message
news:1179338641.321266.214230@e65g2000hsc.googlegroups.com...

The first error I have for you is shown below. Last time around, I
switched all "const bit" declarations to `define - I don't feel like
doing that today ...

Yup, I ran into that problem, too.
To be fair, Xilinx's "Verilog-2001" support (as of XST 9.1i.03) has more
limitations (and fatal bugs) than Quartus-II 7.1.
For example, these constructs cause compiler errors:
reg [7:0] my_memory [0:255]

always @* data_out = my_memory[address];
always @* begin : xst9_no_likey
integer i, j;
for ( i = 0; i &lt; 10; i = i + 1 )
for ( j = i; j &lt; 10; j = j + 1 )
my_bits = my_bits[j]; // ok, degenerate example, but XST9
rejects 'j' as non-constant!

package alu_package;
const bit [2:0] alu_add = 3'd0;
endpackage // alu_package

Wow, you got packages to work? I tried to use a Systemveirlog package
declaration,
but Quartus-II couldn't find it no matter what. Do I need to do anything
special when
I add files to my project? (All of my systemverilog files are suffixed
".sv")

The second error I got is:

always_comb
begin
request.address = '0;
for (integer i=0; i&lt;NUM_MASTER; i++)
if (request_oe)
request.address = request_address;
end

Error (10170): Verilog HDL syntax error at smp.sv(50) near text
"integer"; expecting an identifier ("integer" is a reserved keyword )
[...]

Yup, same here.
By the way, for loop-iterators, you really should use the 2-state 'int'
instead of integer.

These comments will make their way eventually to Altera. They were
responsive last time around and they seem to be making some progress.
With XST 10 rumored to support SV synthesis, I think it'll only be a
matter of time before we start seeing some solid tools emerge.

Given the state of XST9's Verilog-2001 synthesis, I think it'll be some time
before Xilinx Systemverilog is ready for mainstream use... to be fair, look
at
quibbles still in Quartus-II 7.1, and Quartus has had systemverilog for a
year now!

 

[Rob Dekker]

"Jonathan Bromley" &lt;jonathan.bromley@MYCOMPANY.com&gt; wrote in message news:d9pm43h9n51co0podt5fgqcg9o9tsk8ur3@4ax.com...

Edmond Cote wrote

a tale of woe and disappointment about SystemVerilog tool support

Regarding the above loop, would someone, ahem, please implement
modport expressions (section 20.4.4 of IEEE 1800-2005) already?

I've been complaining about exactly this both publicly and
privately for at least two years now, and no-one seems to be
terribly interested. This completely mystifies me, since
modport expressions are one of the most obvious contributions
to parameterisable/configurable design in SystemVerilog.

Credit to QuestaSim for gaining this feature in the 6.3 beta
release, which I believe will be "going live" soon. But it's
not a lot of use until the support is widespread across
many tools and a complete tool chain.

These comments will make their way eventually to Altera. They were
responsive last time around and they seem to be making some progress.
With XST 10 rumored to support SV synthesis, I think it'll only be a
matter of time before we start seeing some solid tools emerge.

All together now....

THE SYNTHESISABLE FEATURES OF SYSTEMVERILOG ARE THE EASY PART.

Support for interfaces raises one tool implementation headache -
synth. tools then are, for the very first time, obliged to
process just one particular special case of dotted
(hierarchical) names - but, in every other respect, the
whole thing is pretty straightforward. There is some
stuff that is potentially tricky - nested modules, anyone? -
but even that has a near-equivalent precedent, in VHDL blocks.
Wildcard ( .* ) port connection syntax will surely impose some
constraints on compilation order and source code visibility,
but I'm sure users would be prepared to live with some minor
tool-specific restrictions of that kind in order to reap the
benefits of the new constructs.

SystemVerilog's synthesisable design features offer big benefits
that designers can adopt easily, incrementally and with minimal
risk. I am completely unable to understand why there hasn't
been a huge outcry by designers wanting support for these
features NOW, not in version N+2 of whatever tools - especially
in view of the vigour and enthusiasm with which the
verification community has bought in to SystemVerilog's
OOP and modelling extensions.

Edmond's complaint is almost the first time I've seen anyone
here publicly asking for such support. C'mon, denizens of
Verilog-land - are you *so* conservative, *so* set in your
ways, *so* satisfied with the tools and techniques you have
been using for a decade and a half, that you really don't
want to push your tool vendors into supporting stuff that
could make your life much better?

I'm speaking strictly for myself here. Thanks for letting
me get all that off my chest

Jonathan,

You are totally right that tool support for SV differs widely for many tools.
Much of that I think has to do with the fact that SV is so absurtly large, and so insanely poorly specified,
that differences in behavior for many tools implementations are likely to occur, and are likely to remain for a long time.

We at Verific are attempting to at least iron out differences between tools, by providing the same SV front-end to many different
tools.

You guys mostly talk about SV support in the most popular tools like ModelSim, VCS, Synplify and now Quartus.
How about the other wide range of tool vendors with SV support ?

Companies like Jasper, Sequence (RTL power analysis), RealIntent, LigaSystems, SiliconNavigator, EVE, Veritools etc etc.
I just wonder if anyone has put their SV support to the test....

Rob

--
Jonathan Bromley

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.

 

[Jonathan Bromley]

On Sat, 26 May 2007 20:27:52 -0700, Rob Dekker wrote:

[Jonathan Bromley

I'm speaking strictly for myself here. Thanks for letting
me get all that off my chest

You are totally right that tool support for SV differs widely for many tools.
Much of that I think has to do with the fact that SV is so absurtly
large, and so insanely poorly specified,
that differences in behavior for many tools implementations
are likely to occur, and are likely to remain for a long time.

The current round of language changes is making good progress towards
dealing with that, as you are of course aware.

We at Verific are attempting to at least iron out differences between tools
, by providing the same SV front-end to many different tools.

As I hope was clear from my various posts, my main beef here is
not with tool vendors - who, it seems to me, have done an
astonishingly good job in providing a wide range of SV feature
support rather quickly - but with *users*, particularly in
the design space, who seem oddly reluctant to engage with SV
and the various good things it can do for them. Without a
visible pull from customers, it's hard to see the tool vendors
providing support for new features when they're already
up to their ears in providing support for features they *know*
they can sell. This problem must be even harder for you,
as you presumably see the user pull mainly in a second-hand
way through your own OEM customers.

You guys mostly talk about SV support in the most popular tools
like ModelSim, VCS, Synplify and now Quartus.
How about the other wide range of tool vendors with SV support ?
Companies like Jasper, Sequence (RTL power analysis), RealIntent,
LigaSystems, SiliconNavigator, EVE, Veritools etc etc.
I just wonder if anyone has put their SV support to the test....

Good question. I don't yet make heavy use of formal model checkers,
and the other classes of tools you mention (power analysis,
emulation, ...) are way off my patch. My bias towards mainstream
simulation and synthesis tools is simply a matter of habit and
experience. Obviously, the availability of a small number of
widely used front end tools like yours will be great for typical
users - they will get what's effectively a guarantee of portability
of code from one tool to another, not just in terms of language
standard but also in feature support, command-line options and/or
pragmas, and - dare I say it - bug lists One of the complaints
I hear most frequently from large customers who want to adopt SV
is that the tool chain is woefully incomplete: simulation generally
leads the pack, synthesis supports some but not all of what they
would like, and back-end tools are largely working in the land of
Verilog-95 netlists. The need to move to plain old Verilog for
the back-end flow can make ECO tracking and some kinds of debugging
very painful indeed if the design was written in SystemVerilog.
--
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.