Hardware Design with SystemVerilog

[Petter Gustad]

info2@rayed.de writes:

enum, generate, struct, class, union, interface, package,
multidimensional arrays ... you must be making fun.

And always_ff, always_comb, always_latch, unique, and priority also
comes to mind. And I would like to use assertions and convergroups
within the design even though the syntesis tool will ignore them.

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Dwayne Dilbeck]

I wasn't making fun, but I was being overly simplistic. If a person is just
getting into HDL design the differences between verilog and System Verilog
is going to be difficult to judge. I feel it is better to use the large
range of books that are out there to learn Verilog then go on to learn the
new features. The addition of the types like "logic" will make more sense
once the new comer to verilog understands the issues that were created by
"wire" and "reg".

I frequently have trouble seperating where VHDL ends and Verilog picks up.
"enum, generate, struct(record), packages, multidimensional arrays" I have
been using since I learned VHDL. Thus I discounted "stuct" and "packages"
from being added by System Verilog, simply because I have been using them
for a long time.

"class, and union", I am unsure how usedul these will be for design.

"interface" Will be VERY useful once they are fully supported by the
Synthesis tools.
The tools I am using now, barely have support.

I admit I completely forgot about "System Verilog For Design". I remembered
the book on the way into work, If no one had mentioned the book I would have
posted it.

My original post did have some valid comments, and it had over
simplifications, which is why there are other posters on this board to chime
in and correct my faulty brain.



<info2@rayed.de> wrote in message
news:8845b676-433f-4971-b9a3-233dec496a99@z17g2000hsg.googlegroups.com...

On 20 Feb., 02:11, "Dwayne Dilbeck" <ddilb...@yahoo.com> wrote:
System Verilog can be broken into two feature sets.

System Verilog for Design
and
System Verilog for Verification

The majority of the features in System Verilog for Design came from
IEEE1364-2005.
Or put another way System Verilog for Design is a minor superset of
verilog.
The System Verilog design constructs include things like "cnt++;"

A minor superset of verilog?

enum, generate, struct, class, union, interface, package,
multidimensional arrays ... you must be making fun.

Most people that are migrating to SV right now are interested in the
Verification section.
Most people moving to SV are old hands at verilog design, but may have
never
used assertion languages. This creates the reason why you can't find any
System verilog for Design books. The book industry feels that there
isn't
a market for System Verilog Design books, when alot of the information
would
be rehashing the Verilog design books.
They want to get in on the large population of engineers who need to
learn
assertions, then they will go back and create the SV Design books.

What about "System Verilog For Design" by Stuart Sutherland, Simon
Davidman & Peter Flake ISBN-10: 0-387-33399-1 ?

Additionally, the more interesting SV Design constructs are not supported
by
synthesis tools. I doubt any synethesis tool is able to synthesize
classes
yet.

This seems true, the lower-end Synthesis tools like Mentor Precision
and Synplify lack some language features, what about Synopsys &
Cadence?

But on the other hand, classes seem to me less useful for synthesis
than what already is implemented.
Modules and interfaces make more sense to me and they are implemented.

 

On Feb 20, 9:12 am, in...@rayed.de wrote:

A minor superset of verilog?

enum, generate, struct, class, union, interface, package,
multidimensional arrays ... you must be making fun.

Generate and multidimensional arrays were already in Verilog, and were
not added by SystemVerilog. You are right about the rest of the list,
and there are others that you did not list. It is a significant set
of features. However, it looks much smaller when compared with the
set of added verification features.

 

On 20 Feb., 02:11, "Dwayne Dilbeck" <ddilb...@yahoo.com> wrote:

System Verilog can be broken into two feature sets.

System Verilog for Design
and
System Verilog for Verification

The majority of the features in System Verilog for Design came from
IEEE1364-2005.
Or put another way System Verilog for Design is a minor superset of verilog.
The System Verilog design constructs include things like "cnt++;"

A minor superset of verilog?

enum, generate, struct, class, union, interface, package,
multidimensional arrays ... you must be making fun.

Most people that are migrating to SV right now are interested in the
Verification section.
Most people moving to SV are old hands at verilog design, but may have never
used assertion languages. This creates the reason why you can't find any
System verilog for Design books. The book industry feels that there isn't
a market for System Verilog Design books, when alot of the information would
be rehashing the Verilog design books.
They want to get in on the large population of engineers who need to learn
assertions, then they will go back and create the SV Design books.

What about "System Verilog For Design" by Stuart Sutherland, Simon
Davidman & Peter Flake ISBN-10: 0-387-33399-1 ?

Additionally, the more interesting SV Design constructs are not supported by
synthesis tools. I doubt any synethesis tool is able to synthesize classes
yet.

This seems true, the lower-end Synthesis tools like Mentor Precision
and Synplify lack some language features, what about Synopsys &
Cadence?

But on the other hand, classes seem to me less useful for synthesis
than what already is implemented.
Modules and interfaces make more sense to me and they are implemented.

 

[Dwayne Dilbeck]

System Verilog can be broken into two feature sets.

System Verilog for Design
and
System Verilog for Verification

The majority of the features in System Verilog for Design came from
IEEE1364-2005.
Or put another way System Verilog for Design is a minor superset of verilog.
The System Verilog design constructs include things like "cnt++;"

Most people that are migrating to SV right now are interested in the
Verification section.
Most people moving to SV are old hands at verilog design, but may have never
used assertion languages. This creates the reason why you can't find any
System verilog for Design books. The book industry feels that there isn't
a market for System Verilog Design books, when alot of the information would
be rehashing the Verilog design books.
They want to get in on the large population of engineers who need to learn
assertions, then they will go back and create the SV Design books.

Additionally, the more interesting SV Design constructs are not supported by
synthesis tools. I doubt any synethesis tool is able to synthesize classes
yet.

<jjlindula@hotmail.com> wrote in message
news:4e189ab2-18e0-432c-a5c1-8ff6495d653f@z70g2000hsb.googlegroups.com...

Hello, I am a newbie learning Verilog for FPGA programming and just
ran across an article today on SystemVerilog for FPGA design. When
ever I do a search for SystemVerilog books I don't get books on how to
learn the language for FPGA design, but books on Verification and
writing Testbenches. I'm a little confused here, I thought SV was
replacing Verilog, if so why aren't there introduction to SV books out
there to help people learn the HDL for hardware design, what am I
missing?

thanks,
joe

 

[jjlindula@hotmail.com]

Hello, I am a newbie learning Verilog for FPGA programming and just
ran across an article today on SystemVerilog for FPGA design. When
ever I do a search for SystemVerilog books I don't get books on how to
learn the language for FPGA design, but books on Verification and
writing Testbenches. I'm a little confused here, I thought SV was
replacing Verilog, if so why aren't there introduction to SV books out
there to help people learn the HDL for hardware design, what am I
missing?

thanks,
joe

 

[anonyposter]

Dwayne Dilbeck wrote:

I wasn't making fun, but I was being overly simplistic. If a person is just
getting into HDL design the differences between verilog and System Verilog
is going to be difficult to judge. I feel it is better to use the large
range of books that are out there to learn Verilog then go on to learn the
new features. The addition of the types like "logic" will make more sense
once the new comer to verilog understands the issues that were created by
"wire" and "reg".

I tend to agree. I come across a lot of newly written Verilog RTL which
fails to take advantage of Verilog-2001 features (always @*, ANSI-C
module headers, etc.) Mostly due to ignorance on the part of the designer.

There's a large group of Verilog engineers who fall into that group (as
I myself did.)

I frequently have trouble seperating where VHDL ends and Verilog picks up.
"enum, generate, struct(record), packages, multidimensional arrays" I have
been using since I learned VHDL. Thus I discounted "stuct" and "packages"
from being added by System Verilog, simply because I have been using them
for a long time.

"class, and union", I am unsure how usedul these will be for design.

I don't think class is really synthesizeable, as it doesn't contain
design hierarchy. One could make a case for unions, but I don't think
too many (synthesis) tools (outside Synopsys Design Compiler) support
unions yet. And one major simulation tool doesn't support unions yet --
I assume this means customers aren't pushing it.

"interface" Will be VERY useful once they are fully supported by the
Synthesis tools.
The tools I am using now, barely have support.

Altera Quartus-II 7.2 supports the basic interface + modport
declarations. If that's what you mean by 'barely support', then I think
most SV-synthesis tools are at this level. Once you add
clocking-blocks, functions, and other bells & whistles, most
synthesis-tools choke. (And wasn't there a huge discussion about odd
behavior when mixing clocking-blocks with modports in a single interface?)

 

[Mike Treseler]

anonyposter wrote:

I tend to agree. I come across a lot of newly written Verilog RTL which
fails to take advantage of Verilog-2001 features (always @*, ANSI-C
module headers, etc.)

I like the 2001 comma separated parameter and port lists:

#(parameter small_c = 5,
parameter big_c = 14
)

(input clock,
input reset,
output reg [small_c-1:0] q_a,
..

-- Mike Treseler