SystemVerilog for Design

Hi,
We are considering switching from VHDL to SystemVerilog for our future design work (we already use SystemVerilog UVM for verification)

I cannot find any RTL coding guidelines for SV *RTL*, only for Verilog. Some of the new SV features: Interfaces, always_ff, always_comb, data types etc look interesting, but I don't know about tool support for these useful feature

- Are you aware of any recommendations for SV *RTL* development?
- Which features should we avoid.
- Are any of you actually using SV for design? If so, can you pass on any recommendations
- Are you aware of any tool support issues: Particular features or vendors?

Thanks,
Steveb

 

[unfrostedpoptart]

On Tuesday, October 15, 2013 12:06:26 PM UTC-7, Cary R. wrote:

On 10/15/2013 6:20 AM, moogyd wrote:

Hi, We are considering switching from VHDL to SystemVerilog for our
future design work (we already use SystemVerilog UVM for verification)
I cannot find any RTL coding guidelines for SV *RTL*, only for

Verilog. Some of the new SV features: Interfaces, always_ff,
always_comb, data types etc look interesting, but I don't know about
tool support for these useful feature

- Are you aware of any recommendations for SV *RTL* development? -
Which features should we avoid. - Are any of you actually using SV
for design? If so, can you pass on any recommendations - Are you

aware of any tool support issues: Particular features or vendors?



Thanks, Steveb





Stuart Sutherland and Don Mills have this paper "Synthesizing
SystemVerilog: Busting the Myth that SystemVerilog is only for
Verification" from a SNUG 2013 presentation. It can be found on their
respective web pages. I have not looked at it in detail, but it looked
promising enough that I have a copy stashed to read when I have some

free time.



To me the real answer to your question is what does the documentation
for the synthesis tool you plan to use say it supports?
Cary

They also have the book (sitting in front of me) "System Verilog For Design".
http://www.amazon.com/SystemVerilog-Design-Second-Edition-Hardware/dp/0387333991

As others have said, there has never been, is not, and will likely never be an official standard for what parts of the language are synthesizable. Even the most common things, like
always @ (posedge clk or posedge reset)
if (reset) myreg <= 0;
else myreg <= new_input;

are only "standard" because Synopsys did it that way. I don't think anything in the LRM says that that will generate a d flip-flop. Years ago, I had some Verilog code from someone using Synergy, Cadence's original synthesis tool. It used a different syntax with separate blocks for reset and clocked.

Anyway, it's a pain and you just have to check the documentation for every tool you use - and keep checking since companies are still adding support for SV constructs. I still run into issues of code that's fine for ASIC synthesis but doesn't work with FPGA tools. Sometimes just put in `ifdefs with different versions of the RTL. So much fun!

David

 

[GaborSzakacs]

moogyd@yahoo.co.uk wrote:

Hi,
We are considering switching from VHDL to SystemVerilog for our future design work (we already use SystemVerilog UVM for verification)

I cannot find any RTL coding guidelines for SV *RTL*, only for Verilog. Some of the new SV features: Interfaces, always_ff, always_comb, data types etc look interesting, but I don't know about tool support for these useful feature

- Are you aware of any recommendations for SV *RTL* development?
- Which features should we avoid.
- Are any of you actually using SV for design? If so, can you pass on any recommendations
- Are you aware of any tool support issues: Particular features or vendors?

Thanks,
Steveb

Synthesis support always lags the introduction of new standards by quite
a long time. It is important to look at the tools you expect to use
before you decide if this switch makes sense. The synthesizable
subset of SV is very tool dependent. If you know which tools you
want to (or must) use for your design target, you should look at their
documentation to see if the features you're interested in are
supported, and if not if they are on a short list for being implemented
soon. Without knowing how much tool support you have, any RTL coding
guidelines would be useless.

--
Gabor

 

[Cary R.]

On 10/15/2013 6:20 AM, moogyd@yahoo.co.uk wrote:

Hi, We are considering switching from VHDL to SystemVerilog for our
future design work (we already use SystemVerilog UVM for
verification)

I cannot find any RTL coding guidelines for SV *RTL*, only for
Verilog. Some of the new SV features: Interfaces, always_ff,
always_comb, data types etc look interesting, but I don't know about
tool support for these useful feature

- Are you aware of any recommendations for SV *RTL* development? -
Which features should we avoid. - Are any of you actually using SV
for design? If so, can you pass on any recommendations - Are you
aware of any tool support issues: Particular features or vendors?

Thanks, Steveb

Stuart Sutherland and Don Mills have this paper "Synthesizing
SystemVerilog: Busting the Myth that SystemVerilog is only for
Verification" from a SNUG 2013 presentation. It can be found on their
respective web pages. I have not looked at it in detail, but it looked
promising enough that I have a copy stashed to read when I have some
free time.

To me the real answer to your question is what does the documentation
for the synthesis tool you plan to use say it supports?

The "Gotcha..." papers (SNUG 2006-2007)/book also from the previous
authors may be of interest in relation to your second set of questions.

Cary

 

[Mark Curry]

In article <6b22b72e-93da-4308-95f9-06eb4b83a0f0@googlegroups.com>,
unfrostedpoptart <david@therogoffs.com> wrote:

They also have the book (sitting in front of me) "System Verilog For Design".
http://www.amazon.com/SystemVerilog-Design-Second-Edition-Hardware/dp/0387333991

As others have said, there has never been, is not, and will likely never be an
official standard for what parts of the language are synthesizable. Even the
most common things, like
always @ (posedge clk or posedge reset)
if (reset) myreg <= 0;
else myreg <= new_input;

are only "standard" because Synopsys did it that way. I don't think anything
in the LRM says that that will generate a d flip-flop. Years ago, I had some
Verilog code from someone using Synergy, Cadence's original synthesis tool.
It used a different syntax with separate blocks for reset and clocked.

Actually, there's an IEEE standard that defines verilog-2001 subset of the
language that is synthesizable (IEEE 1364.1-2002) (I was in the working group).

There was some sort of effort to do this again for Systemverilog / IEEE 1800.
One of the consultants suggested it in the working group, and it created some
sort of big tizzy for some reason or another - the details of which I don't
recall. I think the whole thing got dropped - in the end, it's left for the
vendors to independently define.

Regards,

Mark

 

[unfrostedpoptart]

On Tuesday, October 15, 2013 5:03:38 PM UTC-7, Mark Curry wrote:

In article <6b22b72e-93da-4308-95f9-06eb4b83a0f0@googlegroups.com>,

Actually, there's an IEEE standard that defines verilog-2001 subset of the
language that is synthesizable (IEEE 1364.1-2002) (I was in the working group).

There was some sort of effort to do this again for Systemverilog / IEEE 1800.
One of the consultants suggested it in the working group, and it created some
sort of big tizzy for some reason or another - the details of which I don't
recall. I think the whole thing got dropped - in the end, it's left for the
vendors to independently define.

Regards,

Mark

Interesting. I had never heard of this. I looked it up and found the replacement for it from 2005:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4140792

It's a great idea, but do any of the important companies (Synopsys, Cadence, Mentor) actually support this?

David