Callback in System Verilog

Callback is one of the major confusing point for a System Verilog learner. Many people have asked the same question in many forums, but the answer doesn't seems to satisfy fully the quest of the person who has raised the querry. I too had the same issue, but I learned it slowly in a hard way. I am presenting here a way in which if I had an answer, I would have learned faster.

We can pass data member to any function. Now consider a case where you are passing a function (say func1) as a data member to another function (say func2) and you get what is called callback. The reason why it is called callback is that the function func2 now can call anywhere in its code function func1.

In computer programming, a callback is executable code that is passed as an argument to other code. It allows a lower-level software layer to call a subroutine (or function) defined in a higher-level layer.

Note that SV doesn't give a straight-forward way of passing a function as argument for another function. But we can get the same result (almost we can say!) by using OOP. The idea is to describe all the functions (both func1 type and func2 type) in a base class (don't implement the funct2 kind of function and make them virtual for polymorphism), and then extend the class to a derived class where you implement the func2 type of function.

Example:-

class abc_transactor;

virtual task pre_send(); endtask

virtual task post_send(); endtask

task xyz();

// Some code here

this.pre_send();

// Some more code here

this.post_send();

// And some more code here

endtask : xyz

endclass : abc_transactor

class my_abc_transactor extend abc_transactor;

virtual task pre_send();

... // This function is implemented here

endtask

virtual task post_send();

... // This function is implemented here

endtask

endclass : my_abc_transactor

Now let me explain how it is going to work. The base class abc_transactor has 3 tasks, 2 of which are declared virtual and are not implemented. But they are being called from another task xyz() which is fully implemented. The unimplemented virtual task are called callback class.

The child class, which extends from the base class, implements the previous unimplemented tasks. It inherits the xyz() task from the base class and hence doesn't need to change it. By this we can inject executable code to a function without modifying it.

Now the next question is why is done. There are many reasons for it.

1. The biggest advantage is that you can modify the behavior of task xyz() without modifying it in the base or child class. It is a big advantage as no one wants to fiddle with known good functioning code.

2. Consider a case where you are writing a base class which is going to be used by multiple test environment, and for each test environment a known part of the code, or a known function/task is going to change. The natural choice is to implement those change-in-every-case functions/tasks as callback method and let the user extend your base class with specifying only that part of the code which need to be changed in his case.

 

Get free daily email updates!

Follow us!

Programming FPGAs with Python

For everyone who wants to get started with developing for FPGA’s and dont want to waste time in learning a new programming  language or they just want to use their current knowledge of programming with Python to program an FPGA, this tool is just made for you!

The Python Hardware Processsor is written in Myhdl which makes it possible to run a very small subset of python on an FPGA, it converts a very simple Python code into either VHDL or Verilog and then a hardware description can be uploaded to the FPGA:

“Due to the python nature of Myhdl and the Python Hardware Prozessor written with it, it allows you, to write a Programm for the prozessor, to simulate the Hardware Processor and to convert the Processor to a valid hardware description (VHDL or Verilog) inside a single python environment.”

MyHDL surely won’t replace VHDL or Verilog but it could be a great tool for simulation and to test the behavior of your design and it’s certainly a tool worth looking into if you want to jump into the world of FPGAs.

Feel free to discuss in the comments thread.

Get free daily email updates!

Follow us!

Draw AND gate using XOR gates only

Hi friends….

Do any one know how to design an AND gate using XOR gate.?

This was a good question for discussion among me and my friends during graduation. At last solution was quite impressive. I thought i would be good to discuss it here also as I had found this question is interviews for freshers.

Please let us know your comments and views.

Is it really possible to design AND gate using XOR gate.?
If yes, then HOW?
If no, then WHY?

Get free daily email updates!

Follow us!

Verilog language reference manual LRM

Verilog was started initially as a proprietary hardware modeling language by Gateway Design Automation Inc. around 1984. It is rumored that the original language was designed by taking features from the most popular HDL language of the time, called HiLo, as well as from traditional computer languages such as C. At that time, Verilog was not standardized and the language modified itself in almost all the revisions that came out within 1984 to 1990.

Verilog simulator was first used beginning in 1985 and was extended substantially through 1987. The implementation was the Verilog simulator sold by Gateway. The first major extension was Verilog-XL, which added a few features and implemented the infamous "XL algorithm" which was a very efficient method for doing gate-level simulation.

The time was late 1990. Cadence Design System, whose primary product at that time included Thin film process simulator, decided to acquire Gateway Automation System. Along with other Gateway products, Cadence now became the owner of the Verilog language, and continued to market Verilog as both a language and a simulator. At the same time, Synopsys was marketing the top-down design methodology, using Verilog. This was a powerful combination.

In 1990, Cadence recognized that if Verilog remained a closed language, the pressures of standardization would eventually cause the industry to shift to VHDL. Consequently, Cadence organized the Open Verilog International (OVI), and in 1991 gave it the documentation for the Verilog Hardware Description Language. This was the event which "opened" the language.

OVI did a considerable amount of work to improve the Language Reference Manual (LRM), clarifying things and making the language specification as vendor-independent as possible.

Soon it was realized that if there were too many companies in the market for Verilog, potentially everybody would like to do what Gateway had done so far - changing the language for their own benefit. This would defeat the main purpose of releasing the language to public domain. As a result in 1994, the IEEE 1364 working group was formed to turn the OVI LRM into an IEEE standard. This effort was concluded with a successful ballot in 1995, and Verilog became an IEEE standard in December 1995.

When Cadence gave OVI the LRM, several companies began working on Verilog simulators. In 1992, the first of these were announced, and by 1993 there were several Verilog simulators available from companies other than Cadence. The most successful of these was VCS, the Verilog Compiled Simulator, from Chronologic Simulation. This was a true compiler as opposed to an interpreter, which is what Verilog-XL was. As a result, compile time was substantial, but simulation execution speed was much faster.

In the meantime, the popularity of Verilog and PLI was rising exponentially. Verilog as a HDL found more admirers than well-formed and federally funded VHDL. It was only a matter of time before people in OVI realized the need of a more universally accepted standard. Accordingly, the board of directors of OVI requested IEEE to form a working committee for establishing Verilog as an IEEE standard. The working committee 1364 was formed in mid 1993 and on October 14, 1993, it had its first meeting.

The standard, which combined both the Verilog language syntax and the PLI in a single volume, was passed in May 1995 and now known as IEEE Std. 1364-1995.

After many years, new features have been added to Verilog, and the new version is called Verilog 2001. This version seems to have fixed a lot of problems that Verilog 1995 had. This version is called 1364-2001.

Timeline:

1984 Verilog-XL simulator and language developed by Gateway Design Automation
1987 Synopsys introduced a Verilog based synthesis tool.
1989 Cadence Design Systems acquired Gateway, and Verilog.
1990 Cadence placed the Verilog language in the public domain.
1995 Verilog HDL became (IEEE Std 1364-1995).
1997 Verilog VCS bought by Viewlogic
1997 Viewlogic bought by Synopsys
1998 Synopsys issues Verilog VCS
2001 A significantly revised version was published in 2001.

DOWNLOAD VERIOG LRM

Intel Is Cooling Entire Servers By Submerging Them in Oil

Air cooled computers are for wimps. But while the idea of keeping temperatures in check using water might be a step in the right direction, Intel is doing something even more radical: it's dunking entire servers—the whole lot—into oil to keep them chill.

Don't panic, though: they're using mineral oil, which doesn't conduct electricity. It's a pretty wacky idea, but it seems to be working. After a year of testing with Green Revolution Cooling, Intel has observed some of the best efficiency ratings it's ever seen. Probably most impressive is that immersion in the oil doesn't seem to affect hardware reliability.

All up, it's extremely promising: completely immersing components in liquid means you can pack components in more tightly as the cooling is so much more efficient. For now, though, it's probably best to avoid filling your computer case with liquid of any kind.

Get free daily email updates!

Follow us!

Vectors

Formal Definition

Vectors are multiple bit widths net or reg data type variables that can be declared by specifying their range.

Simplified Syntax

net_type [msb:lsb] list_of_net_identifiers;

reg [msb:lsb] list_of_register_identifiers;

Description

Vector range specification contains two constant expressions: the msb (most significant bit) constant expression, which is the left-hand value of the range and the lsb (least significant bit) constant expression, which is the right-hand value of the range. The msb and lsb constant expressions should be separated by a colon.

Both the msb constant expression and the lsb constant expression can be any value - positive, negative, or zero. The lsb constant expression can be greater, equal or less than the msb constant expression.

Vectors can be declared for all types of net data types and for reg data types. Specifying vectors for integer, real, realtime, and time data types is illegal.

Vector nets and registers are treated as unsigned values (see: Arithmetic expressions with registers and integers for more explanations).

Examples

Example 1

reg [3:0] addr;

The 'addr' variable is a 4-bit vector register made up of addr[3] (the most significant bit), addr[2], addr[1], and addr[0] (the least significant bit).

Example 2

wire [-3:4] d;

The d variable is 8-bit vector net made up of d[-3] (msb), d[-2], d[-1], d[0], d[1], d[2], d[3], d[4] (lsb).

Example 3

tri [5:0] x, y, z;

The above line declares three 6-bit vectors.

Important Notes

• Both the msb and the lsb expressions should be constant expressions.
• The msb and the lsb constant expressions may be positive, negative, or zero.
• The lsb constant expression may be greater, equal or less than the msb constant expression.
• Vectors can be declared only for nets and reg data types.
• Vector declaration for integer, real, realtime, and time data types are illegal.

Value Change Dump (VCD) File

Formal Definition

The Value change dump (VCD) file contains information about any value changes on the selected variables.

Simplified Syntax

$dumpfile(name)

$dumpvars

$dumpvars(level, list_of_variables_or_modules)

$dumpoff

$dumpon

$dumpall

$dumplimit

$dumpflush

Description

$dumpfile(filename)

This task is used to specify the VCD file name. The filename parameter is optional. If it is not given, then the file will be named "Verilog.dump”.

$dumpvars(level, list_of_variables_or_modules)

This task is used to specify which variables should be dumped. Both parameters are optional and if none are used, then all variables will be dumped.

If level = 0, then all variables within the modules from the list will be dumped. If any module from the list contains module instances, then all variables from these modules will also be dumped.

If level = 1, then only listed variables and variables of listed modules will be dumped.

$dumpoff

This task stops the dumping of variables. All variables are dumped with x value and all next changes of variables will not be dumped.

$dumpon

This task starts previously stopped dumping of variables.

$dumpall

When this task is used, then the current value of all dumped variables will be written to file.

$dumplimit(filesize)

This task can set the maximum size of the VCD file.

$dumpflush

This task can be used to make sure that all changes of dumped variables are written to file.

Examples

module top;
reg a, b;
wire y;
assign y = a & b;
always begin
  a = 1'b0;
  #10;
  a = 1'b1;
  #10;
  a = 1'bx;
  #10;
end
always begin
  b = 1'b0;
  #30;
  b = 1'b1;
  #30;
  b = 1'bx;
  #30;
end
initial begin
  $dumpfile("test.txt");
  $dumpvars(1,a,y);
  #200;
  $dumpoff;
  #200;
  $dumpon;
  #20;
  $dumpall;
  #10;
  $dumpflush;
end
endmodule

The dumpfile will contain only changes of 'a' and 'y' variables. After 200 time units, dumping will be suspended for 200 time units. Next, dumping will start again and after 20 time units, all variables will be dumped.

Important Notes

• Value change dump file can be used for hierarchical monitoring of all signal changes within design modules.