Thursday, March 6, 2014

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 :-
 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....

Monday, March 3, 2014

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 !!)