Posts Tagged ‘SystemVerilog’
Wednesday, February 27th, 2013
At this week’s DVCon 2013 conference, the IEEE Standards Association (IEEE-SA) and Accellera Systems Initiative (Accellera) have jointly announced the public availability of the IEEE 1800 SystemVerilog Language Reference Manual at no charge through the IEEE Get Program.
As I posted a few weeks ago, the 1800-2012 is not a major revision of the standard, but does contain a few enhancements that will be of interest to design and verification engineers alike. However, providing the standard as freely available download is major news.
Even though the relative cost of the LRM was minor compared to the cost of most projects utilizing the standard, there seemed to be a barrier in most engineer’s minds in justifying the expense. So most just continued to use the last freely available SystemVerilog 3.1a LRM, which was 9 years old and very obsolete for such a rapidly changing technology.
Monday, February 14th, 2011
Somebody asked me a simple question: Why do need two different macros (`ovm_object_utils and `ovm_object_param_utils) to register classes with the factory, and why can’t it tell me when I’ve used the wrong one? The answer turns out to be quite long, and demonstrates the dangers of using certain macros without first understanding the code behind them. Some I’m posting the response here. Adam Erickson will be presenting a paper Are Macros in OVM & UVM Evil? at the upcoming DVCon11 on Wednesday, March 2nd that goes into more details about the costs and benefits of the OVM macros.
First I need to talk about parameterized classes in SystemVerilog and how they interact with static members of those kinds of classes.
When you declare a parameterized class, it is more like a template, or generic class than a real class type. Only specializations of parameterized classes are real types. Suppose I have the two class definitions in the table below:
static string name = “packet”;
|class B #(int w=1);
static string name = “packet”;
Tuesday, March 23rd, 2010
At a recent SystemVerilog requirements gathering meeting,I was quite amused to see “deprecating features” come out as one of the top 10 user requested priorities for the next revision of the IEEE 1800 standard. Even more amazing was that this request came out without listing which features were to be considered for deprecation.
I’m sure most people don’t understand the meaning of the word deprecate. I thought I understood until I looked it up in a dictionary. According to Merriam-Webster:
1 a archaic : to pray against (as an evil) b : to seek to avert <deprecate the wrath…of the Roman people — Tobias Smollett>
2 : to express disapproval of
3 a : play down : make little of <speaks five languages…but deprecatesthis facility — Time> b : belittle, disparage<the most reluctantly admired and least easily deprecated of…novelists — New Yorker>
Friday, September 25th, 2009
Another installment of “Longwinded Answers to Frequent SystemVerilog Questions: $unit versus $root”
Believe me – I tried to make this shorter. It’s difficult for me to explain things without a historical perspective.
Verilog was invented to be an interpreted language. Verilog-XL was (and still is) an interpretive engine with single compilation unit use model. In an interpreted engine, all of the source code is parsed and loaded into memory. This means you have to specify all the source files of a design, including the source files of any required libraries, within a single command line before simulating.
VCS (Verilog Compiled Simulator) continued this single compilation use model even though it compiled the code into a machine object saved on disk. Later, it introduced an incremental compile feature that only compiled certain files that needed it, but you still had to specify all the source files on the command line. This is not the same as separate compilation available in most software programming languages where source code can be converted into machine code independently.
Friday, September 11th, 2009
I have lots of blog entries about 95% ready to publish. This entry is from an e-mail I wrote a few months ago when somebody asked about SystemVerilog coding guidelines. I thought it would make a good article. It’s been sitting as a draft because I always have trouble finding the right title or opening words to catch people’s attention. I couldn’t come up with anything better, so here it is: SystemVerilog Coding Guidelines
My official position about this is that you pick a style and stick to it.
Which style you pick is far less important than developing the required culture that will follow it. People can spend hours arguing over the merits of camelCaps versus under_score, but once the decision is made, people on the project need to document it, adhere to it, and police it. Otherwise you’re just wasting everyone’s time.
Why are coding guidelines so important? So someone else can read your code, or maybe you can read your own code six months after you wrote it. Good comments and documentation are an import part, but you still need to be able to read the code.
Tuesday, July 7th, 2009
I’ve been around simulation and synthesis languages for a while; back when you needed an NDA to see the Verilog LRM, and again with SUPERLOG, the predecessor to SystemVerilog. It’s easy for those like me to get caught up in the features of the language and forget that any programming language is just a tool. With any technology, people pick the tools they think will get the job finished most effectively. Tools evolve to meet the challenges and requirements of their users. Verilog and VHDL have clearly evolved to become the prevailing languages for hardware design.
But before the language wars came the methodology wars. At the time when Verilog and VHDL were being introduced in the late 1980s, most hardware design was by schematic gale-level entry. We would come to our clients with our simulators and synthesis tools and try to change their design methodology by writing RTL. They would bring their best engineers to compete with our tools – and the engineer would always win by producing a design with better area and timing! However, once the productivity of synthesizing large designs with practical quality of results prevailed over the manual effort, the methodology shift was an easier sell.
Thursday, June 4th, 2009
That’s a frequent SystemVerilog question I’m asked. Program blocks came directly from donation of the Vera language to SystemVerilog by Synopsys , and try to mimic the scheduling semantics that a PLI application has interacting with a Verilog simulator. So coming from a Vera background, program blocks make perfect sense and do help people transitioning from Vera to SV. But looking at SV from scratch, they are just extra language baggage.
Who would have ever thought we’d be having language wars within the same language!
As far as I can tell, a program block by itself only addresses two race conditions between the testbench and DUT, both of which are covered by using a clocking block by itself.
- Erroneous use of blocking assignments for sequential logic. You have a race within your DUT regardless of the race between your testbench and DUT.
- Erroneous use of non-blocking assignments in combinational gated clock logic. You may have a race within your DUT regardless of the race between your testbench and DUT.
As a user, if you don’t understand why these create races within your DUT, you’re going to have the same races within your testbench, and there’s nothing a program block does that prevent races within your testbench. There lays the false sense of security of having a race-free testbench.