Get email delivery of the Cadence blog featured here
System Verilog has now been around for a number of years. In fact, its IEEE 1800 specification has been ratified over a year ago and its preliminary version IEEE P1800 has been out since mid 2005. Furthermore, earlier incarnations such as Superlog and the Accellera version of the specification have been around for more than 6 years. Yet, the use of System Verilog for design implementation remains limited and designers remain skittish about tool support despite most vendors claiming support for a substantial period of time already. I cannot help but wonder what keeps designers from adopting System Verilog for implementation. Specially, considering that verification experts around the globe have taken to it in significant numbers in recent times. The first question that comes to mind is whether or not it makes sense ? System Verilog offers a number of features that should help reduce Time-To-Market (TTM) and reduce the number of issues due to code quality.
Port connectivity inference, explicit latch / flop / combinational blocks, and the unique and priority statements that help remove the reliance on tool specific pragmas, are only a few of the features that come to mind. Such features reduce the lines of code (LOC) needed to specify a design thus facilitating code reviews and reducing the chances of simple but costly designer mistakes. Furthermore, these features also remove several ambiguities in earlier versions of the Verilog language that were the cause of many issues. The extension of System Verilog to implementation would better leverage the current use in the verification space as well. Then, what is preventing System Verilog wide adoption for implementation ? What is the pain factor as many of us like to say ?
While several vendors have claimed tool support for some time now, it is no secret that System Verilog support is not as robust as Verilog and VHDL that have been battle tested for longer periods of time. However, this is not to say that the support is not there and should be avoided altogether. In fact, I believe most features are supported by a large number of tools and vendors out there but it is the omissions and ambiguities in the specification that have not been ironed out yet and, in some cases, can cause issues and different behavior across tools and vendors.
I believe early adopters of System Verilog for implementation can reap large rewards but the key to avoiding 'pain' is to have a clear incremental path to adoption. Rather than adopt every feature possible, users should focus on individual features, based on their risk and rewards. There are many attractive features of System Verilog that are not only easy to implement for designers but simple for users to test and make sure they are compatible with their flows, tools, and vendors. These features should clearly be adopted first and more sophisticated features adopted at a later stage. What is your experience with System Verilog for implementation ? Are you using it ? Are you planning to ? What are the missing features that prevent you from adopting System Verilog ? I am curious to hear you views and comments.
Happy coding !!!
Is System Verilog going to stay? How you compare System C with System Verilog,for design & Verification?.Is SV an actual replacement for Verilog HDL or an addon with constructs not found in latter? Can the experts comment please
I'm working on my second project using SystemVerilog as an implementation language... And I've been advocating it's use among my peers for a while now. I've found the tool support lately to be very good, though that wasn't the case a year or two ago. It's frustrating whenever you come across a tool in your flow that doesn't support one of the new constructs you used. One such frustration I am currently dealing with is hal (version 8.10-p002), which doesn't allow packed structs. RTL Compiler supports them without problem. Now I'm worried that when I bring up IFV for this project, I might have to spend time re-writing code. It's problems such as these that I'm usually willing to work around (just because I'm eager to get access to a more productive methodology), but my colleagues usually aren't.