OpenSource Simulators / Tools for Verification / VLSI Design

 It had been a long cherished desire to see the development of opensource community in the VLSI industry. Though companies prefer to have paid tools because of their apparent reliability, many small start-ups never take-off because of the humongous cost of tools. The tools are costly because there is a huge amount of engineering R&D effort that lies behind the convenient user interface. Nevertheless a parallel opensource movement in the semiconductor community would definitely accelerate the technological development in the ASIC area.

The 2013 reports show that the current semiconductor industry revenues total upto $315 billions. Out of that the EDA industry had revenues of approximately 1.72 billions, which is about 0.5% of the entire semiconductor industry revenues. Which effectively explains how the value addition takes place further in the product lifecycle from raw RTL code to finished products. We as verification engineers live in the domain of RTL code and hence our jobs is to do quality verification with the tools available. However tools are not available that easily, they are expensive and smaller companies can afford only limited licenses. Having said that, the EDA industry acts as a key enabler in creating bug-free ASIC.

Within the given framework, ASIC development has to progress for new technologies to be proven fast. Hence a parallel opensource EDA development is not a bad idea. Actually it is a great idea.

What are the current free tools available :-

• Fedora Electronics Lab - This is a high-end design and simulation platform with opensource EDA software
• http://spins.fedoraproject.org/fel/
• http://fedoraproject.org/wiki/Electronic_Lab
•  EDA playground - http://www.edaplayground.com - You can type your code and simulate here
• http://dungspreader.blogspot.in/2013_03_01_archive.html - Some great ideas on opensource in verification
• http://www.semiwiki.com/forum/showwiki.php?title=Semi+Wiki:EDA+Open+Source+Tools+Wiki
• http://sourceforge.net/projects/veriwell/
• iverilog.icarus.com/
• http://sourceforge.net/projects/pvsim/
• http://www.veripool.org/wiki/verilator
• http://ghdl.free.fr/
• http://opencores.org/opencores,tools
• http://verilog.comuf.com/free.html
• iverilog.com/
• http://sourceforge.net/projects/gplcver/
• http://www.syncad.com/
• http://opencircuitdesign.com/verilog/ 
• http://www.myhdl.org/doku.php 
• http://rhdl.rubyforge.org/ 
• http://www.sugawara-systems.com/ 
• http://verilog.openhpsdr.org/
• http://6004.csail.mit.edu/6.371/cadtools/gtkwave/wave.html
• http://gtkwave.sourceforge.net/ 
• https://cocotb.readthedocs.org/en/latest/index.html
• https://github.com/potentialventures/cocotb
• http://www.gpleda.org
• http://jeffrey.co.in/blog/2014/01/installing-migen

 I think I will stop here. I believe this gives us an insight into the opensource tools that are out there and enthusiasts all over the world are working on them. Now the next thing is to create a opensource systemverilog simulator. The parser would be complex, but if everyone across the world works on it, its not difficult !! Please leave a comment if you are interested in being a part of the opensource systemverilog simulator development, and we can start a group....

Constants in SystemVerilog

Here is a brief note on SV - constants. Constants are data objects that never change. SV provides the following types of constants.

Elaboration time constants:-

1) parameter - A parameter has two attributes, type and range.
    e.g. parameter logic[7:0] BASE_ADDR = 8;

By default a parameter would take the type and range of the final value assigned to it. By default any parameter would be unsigned. Hierarchical references are not allowed in parameter declarations, reason being these are elaboration type constants. Package references are however allowed in parameter declarations. A parameter can be overridden by a defparam statement. However there is an exception in case of type parameters.
Type parameters:- A parameter constant which specifies a data type, e.g.,

module m1 (parameter type p1 = shortint);

    p1 i = 0;  // i here is shortint

    initial  begin

      int j = 0;

      j = i + 2;

      .

      .

    end

endmodule

A type parameter cannot be overridden by a defparam statement.

2) localparam - local parameters (localparam) are identical to paramters except they cannot be overridden by defparam or instance parameter value assignments.Inside a compilation unit, generate block, package or class body, parameter and localparam are synonymous.

3) specparam - this is a parameter type intended only for providing timing values or delays. These can be declared within specify blocks or the module body.

Note: specparam and param are not interchangeable.

Run-time constant:-

1) const - const can be set during elaboration and simulation/run time. However localparam can be set only during elaboration time.

The following code-snippet might give some insights into the usage details of the different constant types.

Parameter as $ : Parameter can be assigned a value $ for integer types only.
The LRM gives an example in terms of assertions.

It would be interesting to run the following code-snippet and see how different simulators respond to it.

A note on defparam : Parameter values can be changed in any module, interface or program using cross-module references using the defparam statement.

However the SV-2012 LRM does give an indication to deprecate this feature in future versions, hence it is a good idea to take care of not using this feature where re-usability is of prime importance (which is always !!)

+: operator in SystemVerilog

An interesting code snippet on usage of +: operator in SystemVerilog.

module test;

bit [7:0] a;
integer i;
integer j;

initial begin

  //a = 8'hAB; 

  //a = 8'h1C; 
  a = 8'h19; 
  i = 4; 

  j = a[i[7:0]];
  $display("a = %h", a); 

  $display("j = %0d", j);
  j = a[0+:3]; 
  j = a[2+:2]; 
  $display("j = %0d", j);

  r = {8{1'b0}};

  $display("r = %h", r);

  #3 $finish;
 end

endmodule

Fibonacci series using SystemVerilog

This is a code for generating Fibonacci series using systemverilog. Recursion is used here in an in-efficient manner. An interesting exercise would be to optimize the following code :-

How to parse command-line arguments in Ruby using OptionParser

I do my scripting in Ruby. I did a lot of scripting in Perl in the past. Usually people prefer getoptlong in Perl to elegantly process command-line arguments.

As with Ruby, there is more than one way to do a particular thing. Ruby has OptionParser.
OptionParser provides a beautiful framework for processing command-line arguments.

Here is a simple demonstration of its usage :-

#!/usr/bin/ruby

require 'optparse'
 

options = {} # Hash where all the options are stored
optparse = OptionParser.new do |opts|
  opts.banner = "Usage: ./script -f "
  opts.on("-f INPUT_FILE", String,"regression list") do |a|
    options[:input_file] = a.chomp
  end
end

if ARGV.empty?  #In case no arguments are provided, help message is displayed
  puts optparse      #./script -h or --help also displays the usage information
  exit
else
  optparse.parse!

end

regression_list = options[:input_file]

< Rest of the code for dealing with the regression list and simulations etc.>

Note - if you use parse! then ARGV is taken as the input argument by default
If you choose to use parse, then you would have to supply the input list explicitly, e.g., ARGV

On the mathematics of verification

Many of you would wonder why I am writing after more than 3 years. My last post was way back in 2010. Well I am still in the business of ASIC verification.  These years had been immensely profound and educating. When you get a glimpse of infinity, all our lifetime's learning appear to be a drop of water in the ocean.

But the quest for knowledge still goes on. I may not be able to ever understand the workings of this universe, but I still want to pursue the quest, even if it is for the mundane.

So in continuation to my last post "on the mathematics of assertions", I have got some really concrete insight into the problem from a much broader perspective. The problem of verification is far more complex than we perceive through dynamic simulations. There is a profound mathematical basis for the behavior of complex boolean systems. I have got a hold on the mathematics, but there is lot of work to be done before I can come to any publishable conclusion.

On the mathematics of assertions

Assertions are boolean functions and are sampled at regular time intervals. This currently is the known definition. Boolean algebra doesn't have any notion of continuity. There are only two logical states, which are true and false. Time is not a discrete quantity. It's a continuously increasing quantity. Digital circuits can be modeled as boolean functions. But the state of these functions cannot be determined with reference to a continuously varying quantity. Because in that case there is a violation of the algebraic properties of boolean functions. I don't have sufficient mathematics in place to prove this. The only way that seems reasonable is either to model time in terms of a boolean quantity or convert the resulting boolean function into a decimal function. The domain of comparison must be same. Its the same way that we cannot compare an integer with a complex number. The imaginary part adds additional attribute to it. For the time being there is a tendency to rely heavily on the accuracy of assertions for the functional correctness of a digital circuit. But aren't we missing something?

Patents and intellectual property

Many of the technology companies in the American silicon valley have branches in the Indian silicon valley in Bangalore. Most of these companies keep on filing patents on a regular basis and keep on enriching their knowledge treasury. Most of these patents are technology related. What then are the areas where verification engineers can file patents? We can take our time and think about it. But a few things before us. Many of us work in the services/outsourcing models. We still are bound by our agreement with our employers that whatever work we would do, it would be the property of the employer. On one hand you work onsite running regressions and debugging failures, on the other hand if you by dint of your determination do something worthy of patents, it would go to the employer. Thats how it works. So why not think about independent consultancy. It offers more money, more freedom and satisfaction. The model is yet to establish itself here. Only a reputed few enjoy that option, but gradually it would work its way out.

I was curious about the concept of patents. So I did some googling. What I found was a patent is valid only in the country where it is filed and granted. So if you file a patent in India it would not be valid in U.S and vice-versa. Filing a patent in India is affordable. While if an Indian engineer (who is working in India) wants to file a patent in U.S, the fees are not affordable. I am not going into the specific details, but this is my general finding. Also I found that if your patent work is not related to your employer's primary business area, you might have it to yourself, of course after discussions with the relevant people in your company.

So we can start by filing patents in India atleast. Thereby enriching our country's intellectual property base. Business repercussions are a possibility. But thats something that would come as an effect. And maybe in a positive way. The room for innovation is very big. All we need to do it to start thinking. I am sure there are ample areas where our employers would not object to us owning the patents.
U.S is the land of opportunity and enterprise, nevertheless many of us have decided to stay back in India and enjoy the roadside tea, the informal socialising, the sambar, rasam, the idly and masala dosa. By the way is there a patent for masala dosa..?

ASIC verification in the next few years - probable trends

There was VHDL, and then came Verilog. Soon SystemC followed. Synopsys lanched Vera and Cadence acquired Verisity. Methodology for designs remained the same but verification tools and techniques have changed by leaps and bounds. Though it is not very blatanly visible since the whole thing is packaged so nicely as a part of the marketing, the fact remains is that we are borrowing technologies that are already standard practices in Software engineering. OOPs is an example. We are just giving it a different flavour. But thats part of the customisation process. Under the hood everything is C or C++.  Barring the performance criteria, we could have used Perl or Python to build simulators. I am not getting into the relative merits vis-a-vis demerits. But there is always a business reason. So the bottom line is we are adapting software engineering methodologies and calling it a layered architecture. My view is if we are borrowing from software then we might as well borrow well. Software engineering is rich terms of methodologies, techniques and development models. I don't see any reason why we cannot bring in Agile or Scrum in our verification development processes. As a forecast I can bet for it that these things will come with a different name and in a more restrictive and proprietary form in future, because it is hardware.

Google has already started developing "go language". Which in future might replace C or C++. It would be an ideal language to develop simulators especially in the case of ASIC Verification, where concurrency plays such an important role. Then there could be a possibility of distributed systems that can probably address the problems of ever increasing design and testbench complexities. Afterall one needs to run the simulation and finish in time. Formal verification has already started influencing verification cycles and productivity. Its not unlikely that an algorithimic approach might take precedence over simulation.

With development in programming logic technology, and better tools for probing signals, people may not even think of simulations in future. The scope is huge. The intensity of renaissance in verification technology can be great. But for the time being what we can do is start adapting software engineering techniques in verification in a proactive way. The wheel is already invented, all we have to do is to use it. And use it well.

The state of the semiconductor industry in India from a career perspective

The semiconductor industry started in India when Texas Instruments started their development centre in Bangalore more than a decade ago. I remember, ten years ago not many people were aware of the VLSI market in India. We had read about the term in textbooks. The concept of ASIC verification was not much known. Then gradually some educational institutes started incorporating topics in their curriculum. Some more institutes started running some short term certificate courses.

In the following five years things started changing. There was a huge demand in the market for skilled VLSI professionals in India because outsourcing had started big time. An engineer with some basic knowledge of digital electronics and HDL was considered a great asset. The pay was good those days. Everything looked very green and promising. Once you entered the VLSI industry, you were considered to be one from the esteemed class. Then recession came, it was bad for Software as well for VLSI. But VLSI resource base was still limited, so impact of recession was not felt to a very high extent. But software engineers were losing jobs in a big way.

After the recession, 2003 started to look up. Things were improving and the market was good. VLSI engineers were again in high-demand. The general engineering pool was full of a lot of attitude. People were very choosy and picky in terms of work and salary. Services companies were obliging them because they could easily afford a big "buffer" strength.  But this was not to last for more than five years and 2008 started to look down. This time the recession had a full-grown global nature. It affected every possible sector. Semiconductor, for the first time in India saw what it had never seen before. Major semiconductor companies ramped-down rapidly. Consequently service providers had to reduce their additional resource pool. "Buffer" was considered a dangerous word. "Bench strength" as it is often referred to, was reduced nearly to zero. There was a huge set of unemployed people who had nowhere to go, because they had skill sets which could not be used anywhere else. A Java programmer can switch a domain from finance to retail and still do Java programming. But what would ASIC verification engineers do with their Verilog or VHDL knowledge. Their C/C++ skills were just good enough to do the processor programming or their PERL/UNIX skills were just enough to build the environment. They could not write code to build applications. They could only do ASIC verification. They could not enhance their skills because they needed simulators which were highly expensive. Opensource simulators were limited in functionality and could not simulate HVLs like SystemVerilog. There were very few engineers who had knowledge of domains like wireless, graphics etc. because most of them were only running regressions and debugging failures. A true analogy would not even compare to an industrial worker. Because an industrial worker with a specific skill set has more versatility in career choice than an ASIC verification engineer.

2010 started to look a little better and a few companies started recruiting. For 4 positions, companies would get 200 applications. And every company wanted experts in SystemVerilog or hands-on project experience in SystemVerilog. But until 2009 very few companies were actually active in SystemVerilog. They now needed people with strong SystemVerilog skills. This was ironical. On top of that there was recession. Then there were EDA companies who kept on pushing for SystemVerilog to get their business going. They also needed to survive. For an average ASIC verification professional life was really bad. People who had engrossed themselves completely in their work suddenly woke up to find that they were jobless, because they had kept themselves away from the management politics. So when the time came, there was nobody to back them up. In India there is no system of government aid to the unemployed. People who had financial liabilities and a family to take care saw the worst nightmare of their lives.

Joblessness as it is is a very difficult situation. But generic skill-sets enable a professional with more versatility in terms of career options. ASIC verification skills are very specific. At the same time in Indian semiconductor companies, there is very limited exposure to domain knowledge. Most of the semiconductor industry in India is comprised of subsidiary branches of American, European or Japanese semiconductor companies and Indian service providers. There is hardly any Indian company which is willing to take the risk to develop a product. The work that is done in the Indian branches of the MNCs has as it is very limited developmental content. On top of that the more repetitive and laborious kinds are outsourced to service providers. Engineers who are from reputed institutes work in the coveted MNC's in their Indian branches. In a country with a population of 1 billion a handful of IITs or similar colleges, the majority of the engineering talent belongs to the average group. However as far as ASIC verification is considered, any average engineer can learn the technologies and tools and perform verification. It is only a matter of opportunity.

Humanity is not a characteristic of economics. In business the only thing that is fair is profit. The current economic recession has taught us many lessons. These lessons can help us if they are remembered and practiced. We may not be able to change the business dynamics of the semiconductor industry as individuals, but we together can definitely make some significant changes in our respective careers. I can think of some of them as follows:-

1) Those of us who are not doing too well in terms of skills or performance in asic verification can either think of changing skill sets early in career or revamping existing skills to meet the future challenges. The domain of knowledge is huge and there can be other fields that can generate passion and money

2) We must realise that Indian semiconductor industry is small. Though there are a lot of companies, the positions are less

3) Most of the recruitment happens through internal referrals. Companies should open-up their positions to everyone and conduct recruitments in a fair manner. Most of us are aware of the plausible areas of corruption in the recruitment process

4) License costs of simulators and tools are humungous. So Indian semiconductor startups would never take-off, until their primary overhead, which is the license cost of tools, can be compensated for. This can happen only in one situation. That is when we start developing our own tools. A good solution to the problem is to develop opensource simulators and tools. The whole world has witnessed the opensource revolution and the great products and tools that are developed through collaboration. Opensource tools would be a big leap for not only the semiconductor market in India but also for the whole world. The wherewithal needs to be affordable for the product to emerge out of the foundry

Refer to the following article in eetimes:-

http://www.eetimes.com/news/design/columns/tool_talk/showArticle.jhtml?articleID=17404385

5) Lastly we all must collaborate with fellow engineers with a spirit of camaraderie irrespective of affiliations

Though businesses can apparently grow at the cost of ethics and morality, but such businesses are doomed to be failures. The current recession has shown this to the world. Economics though harsh is a great leveler and is driven by fundamentals. Fundamentals after all are driven by values. Hence businesses without values cannot survive, and so is the case with technology.