Featured post
Top 5 books to refer for a VHDL beginner
VHDL (VHSIC-HDL, Very High-Speed Integrated Circuit Hardware Description Language) is a hardware description language used in electronic des...
Wednesday, 16 April 2014
Intel’s e-DRAM
Thursday, 13 June 2013
How 450mm wafers will change the semiconductor industry
The semiconductor industry's transition to making chips on 450-millimeter wafers is better described as a "transformation," Jonathan Davis of Semiconductor Equipment and Materials International writes. "The shift to 450mm will take a several years to manifest and numerous complexities are being skillfully managed by multiple organizations and consortia," he writes, adding, "However, once the changeover occurs, in hindsight, most in the industry will recognize that they participated in something transformational."
Even for the segments that continue manufacturing semiconductor devices on 300mm and 200mm silicon wafers, the industry will change dramatically with the introduction of 450mm wafer processing. The 450mm era will impact industry composition, supply chain dynamics, capital spending concentration, future R&D capabilities and many other facets of today’s semiconductor manufacturing industry — not the least of which are the fabs, wafers and tools with which chips are made.
The shift to 450mm will take a several years to manifest and numerous complexities are being skillfully managed by multiple organizations and consortia. For those reasons, the evolutionary tone of “transition” seems appropriate. However, once the changeover occurs, in hindsight, most in the industry will recognize that they participated in something transformational.
No transformation occurs in isolation and other factors will contribute to the revolutionary qualities of 450mm. Market factors, new facilities design, next generation processing technology, the changing dynamics of node development and new materials integration will simultaneously affect the industry landscape.
While reading about the implications of 450mm is valuable, I believe that there is much to learn by being a part of the discussion. How is this future transformation being envisioned and acted on today? I hope that you will join us — at our “live” event, where you will have the opportunity to hear first-hand information… direct from well-informed experts in the industry.
Potential revisions in the 450mm wafer specification are under consideration. At least two issues are currently being evaluated by the industry and both portend significant ramifications for wafer suppliers, equipment makers and those technologies that interface with the wafer.
First, the wafer orientation method may be revised to eliminate the orientation “notch” on the perimeter of the substrate. The notch was introduced in the 300mm transition as an alternative to the flat. However, both equipment suppliers and IC makers, through a constructive and collaborative dialog, have concluded that eliminating the notch can potentially improve the die yield, tool performance and cost.
Secondly, reduction of the wafer edge exclusion area — that peripheral portion of the silicon on which no viable device structure occurs — also offers potential yield advantages. The current 450mm wafer specification (SEMI E76-0710), originally published in 2010, calls for a 2mm edge exclusion zone. IC makers believe that reduction of this area to a 1.5mm dimension offers the cost equivalence of a 1 percent yield increase. Though a percent may sound trivial, it is represents substantial increased value over time.
Along with cost and efficiency improvements, IC makers and consortia driving the transition to 450mm manufacturing expect to achieve similar or better environmental performance. Larger footprints and resource demands from 450mm facilities in conjunction with mandates for environmentally aware operations are compelling fabs and suppliers to consider sustainability and systems integration at greater levels than ever before.
Experts in fab facilities, energy, water and equipment engineering will discuss the implications of 450mm to environment, health and safety during the SEMICON West 450mm Manufacturing EHS Forum on Wednesday, July 10.
Included in the presentations are perspectives from the Facility 450 Consortium (F450C) including Ovivo, Edwards and M+W Group. A holistic Site Resource Model that provides semiconductor manufacturers visibility into effective reduction of total energy and water demands for individual systems, as well as for the entire facility will be reviewed by CH2M Hill. The model is an integrated analytical approach to assess and optimize a semiconductor facility’s thermal energy, electrical energy, and water demand, as well as the cost associated with these resources.
Thursday, 28 February 2013
French researchers print first ADC on plastic
Millions of tons of food are wasted annually because 'the date'. But the date on the package is always a conservative estimate, so much food that is still good in the waste lands. Would it not be useful if the pack 'taste' of the food is still good? Researchers at the CEA-Liten, Eindhoven University of Technology, STMicroelectronics and University of Catania presented last week in the U.S. technical capstone that makes this possible - a plastic analogue to-digital converter. This gives a plastic sensor circuit of less than one euro cent feasible, which is an acceptable price increase is for example, a bag of potato chips or a piece of meat. The ultra cheap plastic electronics has many potential applications, for example in medicine.
“Organic electronics is still in its infancy, thus only simple digital logic and analogue functions have been demonstrated yet using printing techniques,” said CEA-Liten.
The ADC circuits printed by CEA-Liten include more than 100 n- and p-type transistors and a resistive layer on a transparent plastic sheet. The ADC circuit offers a resolution of 4 bits and has a speed of 2Hz.
The carrier mobility of the printed transistors is higher than the one observed in amorphous silicon, which is widely used in the display industry (CEA technology p-type µp = 1.8 cm²/V.s and n-type µn = 0.5 cm²/V.s).
Monday, 7 January 2013
What to expect at the VLSI Conf Pune 2013
The 26th International Conference on VLSI Design is currently going on at the Hyatt, in Pune (Jan 7th to 9th, 2013), and with a large number of keynotes, research paper presentations, panel discussions, workshops and other things being presented in 5 different tracks to 800+ delegates, it is full of activity for anyone interested in the field of VLSI design/EDA/Embedded systems.
Here are the details of the technical program:
- New Research Ideas
- Often 5-10 years from practical applications
- 3 parallel tracks from 7th to 9th Jan
-
- User/Designer Track
- Novel ideas to and from practitioners (not researchers)
- Can be used today to enhance your next design
- One track on 7th and 8th Jan
-
- Student-Oriented Talks/Workshops
- Design Contest
- Industry Form
- 9 keynotes: by people from LSI, IBM, Marvell, APM, Howard Hughes Medical Institute, Intel, Solarsis, Xilinx
- Panels and Embedded Tutorials for people new to the field
- 66 accepted talks, out of 310 submissions, in all areas of design/EDA/embedded systems
There are 23 companies who have set up exhibit stalls, and includes Intel, QLogic, Xilinx, TI, ARM, Agilent and a bunch of other companies, and includes many companies who have significant Pune presence.
VLSI AND EMBEDDED SYSTEMS CONFERENCE PROGRAM
Day 1 | 7th January 2013 | Inauguration, Technical Sessions, Exhibits, Student Conference |
Day 2 | 8th January 2013 | Valedictory/Award, Technical Sessions, Exhibits, Student Conference |
Day 3 | 9th January 2013 | Technical Sessions, Exhibits, RASDAT 2013 |
Day 4 | 10th January 2013 | RASDAT 2013 |
Day T1 | 5th January 2013 | Tutorials |
Day T2 | 6th January 2013 | Tutorials |
VLSI AND EMBEDDED SYSTEMS CONFERENCE IMPORTANT DATES
Regular Paper Submissions | 24th July, 2012 (Closed) |
Tutorial Submissions | 17th August, 2012 (Closed) |
User/Designer Submissions | 24th August, 2012 (Closed) |
Call for embedded tutorials, | 24th August, 2012 (Closed) |
special sessions, and panels | |
Design Contest Submission | 30th November, 2012 (Final deadline) |
User Track Acceptance Notification | 19th October, 2012 (Closed) |
Camera ready paper due | 15th October, 2012 (Closed) |
Sunday, 14 October 2012
Cyclic Redundancy Check - CRC
Error detection is an important part of communication systems when there is a chance of data getting corrupted. Whether it’s a piece of stored code or a data transmission, you can add a piece of redundant information to validate the data and protect it against corruption. Cyclic redundancy checking is a robust error-checking algorithm, which is commonly used to detect errors either in data transmission or data storage. In this multipart article we explain a few basic principles.
Modulo two arithmetic is simple single-bit binary arithmetic with all carries or borrows ignored. Each digit is considered independently. This article talks about how modulo two addition is equivalent to modulo two subtraction, and can be performed using an exclusive OR operation followed by a brief on Polynomial division where remainder forms the CRC checksum.
For example, we can add two binary numbers X and Y as follows:
10101001 (X) + 00111010 (Y) = 10010011 (Z)
From this example the modulo two addition is equivalent to an exclusive OR operation. What is less obvious is that modulo two subtraction gives the same results as an addition.
From the previous example let’s add X and Z:
10101001 (X) + 10010011 (Z) = 00111010 (Y)
In our previous example we have seen how X + Y = Z therefore Y = Z – X, but the example above shows that Z+X = Y also, hence modulo two addition is equivalent to modulo two subtraction, and can be performed using an exclusive OR operation.
In integer division dividing A by B will result in a quotient Q, and a remainder R. Polynomial division is similar except that when A and B are polynomials, the remainder is a polynomial, whose degree is less than B.
The key point here is that any change to the polynomial A causes a change to the remainder R. This behavior forms the basis of the cyclic redundancy checking.
If we consider a polynomial, whose coefficients are zeros and ones (modulo two), this polynomial can be easily represented by its coefficients as binary powers of two.
In terms of cyclic redundancy calculations, the polynomial A would be the binary message string or data and polynomial B would be the generator polynomial. The remainder R would be the cyclic redundancy checksum. If the data changed or became corrupt, then a different remainder would be calculated.
Although the algorithm for cyclic redundancy calculations looks complicated, it only involves shifting and exclusive OR operations. Using modulo two arithmetic, division is just a shift operation and subtraction is an exclusive OR operation.
Cyclic redundancy calculations can therefore be efficiently implemented in hardware, using a shift register modified with XOR gates. The shift register should have the same number of bits as the degree of the generator polynomial and an XOR gate at each bit, where the generator polynomial coefficient is one.
Augmentation is a technique used to produce a null CRC result, while preserving both the original data and the CRC checksum. In communication systems using cyclic redundancy checking, it would be desirable to obtain a null CRC result for each transmission, as the simplified verification will help to speed up the data handling.
Traditionally, a null CRC result is generated by adding the cyclic redundancy checksum to the data, and calculating the CRC on the new data. While this simplifies the verification, it has the unfortunate side effect of changing the data. Any node receiving the data+CRC result will be able to verify that no corruption has occurred, but will be unable to extract the original data, because the checksum is not known. This can be overcome by transmitting the checksum along with the modified data, but any data-handling advantage gained in the verification process is offset by the additional steps needed to recover the original data.
Augmentation allows the data to be transmitted along with its checksum, and still obtain a null CRC result. As explained before when obtain a null CRC result, the data changes, when the checksum is added. Augmentation avoids this by shifting the data left or augmenting it with a number of zeros, equivalent to the degree of the generator polynomial. When the CRC result for the shifted data is added, both the original data and the checksum are preserved.
In this example, our generator polynomial (x3 + x2 + 1 or 1101) is of degree 3, so the data (0xD6B5) is shifted to the left by three places or augmented by three zeros.
0xD6B5 = 1101011010110101 becomes 0x6B5A8 = 1101011010110101000.
Note that the original data is still present within the augmented data.
0x6B5A8 = 1101011010110101000
Data = D6B5 Augmentation = 000
Calculating the CRC result for the augmented data (0x6B5A8) using our generator polynomial (1101), gives a remainder of 101 (degree 2). If we add this to the augmented data, we get:
0x6B5A8 + 0b101 = 1101011010110101000 + 101
= 1101011010110101101
= 0x6B5AD
As discussed before, calculating the cyclic redundancy checksum for 0x6B5AD will result in a null checksum, simplifying the verification. What is less apparent is that the original data is still preserved intact.
0x6B5AD = 1101011010110101101
Data = D6B5 CRC = 101
The degree of the remainder or cyclic redundancy checksum is always less than the degree of the generator polynomial. By augmenting the data with a number of zeros equivalent to the degree of the generator polynomial, we ensure that the addition of the checksum does not affect the augmented data.
In any communications system using cyclic redundancy checking, the same generator polynomial will be used by both transmitting and receiving nodes to generate checksums and verify data. As the receiving node knows the degree of the generator polynomial, it is a simple task for it to verify the transmission by calculating the checksum and testing for zero, and then extract the data by discarding the last three bits.
Thus augmentation preserves the data, while allowing a null cyclic redundancy checksum for faster verification and data handling.
Wednesday, 19 September 2012
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.
Monday, 10 September 2012
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.
Sunday, 9 September 2012
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.
UDP State Table
Formal Definition
A UDP state table defines the behavior of UDP.
Simplified Syntax
table
comb_input comb_input ... comb_input : output;
seq_input seq_input ... seq_input : current_state : next_state;
endtable
Description
Each row of the state table defines the behavior of the UDP for a specific input combination. Each combination of inputs can be given only one time. It is illegal to define the same combination of inputs for different outputs.
The number of input values must match the number of UDP inputs in a port declaration.
The UDP state table for combinational and sequential UDPs is different. The combinational UDPs (Example 1) contain two fields: an input field and an output field. The sequential UDPs (Example 2) contain three fields: an input, a current state, and the next state (output) field.
The input field should contain a list of values (separated by white spaces), which should match the number of UDP input ports. The order of these ports is highly important. The first input port on the UDP port list matches the first input value in each row.
The rows of the state table can contain only 0, 1, unknown (x) value, and special characters. The high-impedance (z) value cannot be specified. The special characters are provided to increase readability of a description and to make it easier (Example 3).
Symbol | Interpretation | Comments |
0 | Logic 0 | |
1 | Logic 1 | |
x | Unknown value | Not permitted in output field. |
b | Substitute for 0 and 1 | Not permitted in output field. |
? | Substitute for 0, 1, and x | Not permitted in output field. |
- | No change | Permitted only in output field of sequential UDPs. |
(vw) | Transition from v to w value | Permitted only in input field of sequential UDPs. v and w can be 0, 1, x, b, and ? |
* | Same as (??) | Any value change on input. Permitted only in input field of sequential UDPs. |
r | Same as (01) | Rising edge on input. Permitted only in input field of sequential UDPs. |
f | Same as (10) | Falling edge on input. Permitted only in input field of sequential UDPs. |
p | Same as (01), (0x), (x1) | Positive edge on input. Permitted only in input field of sequential UDPs. |
n | Same as (10), (1x), (x0) | Negative edge on input. Permitted only in input field of sequential UDPs. |
Table 25: Summary of symbols
If some combinations of input signal values are not specified in a UDP state tables then the output value will be unknown (x).
Only one transition can appear in each row of sequential UDPs.
Examples
Example 1
primitive mux (o, i3, i2, i1, i0, a1, a0);
output o;
input i3, i2, i1, i0, a1, a0;
table
// i3 i2 i1 i0 a1 a0 : o;
0 ? ? ? 1 1 : 0;
1 ? ? ? 1 1 : 1;
? 0 ? ? 1 0 : 0;
? 1 ? ? 1 0 : 1;
? ? 0 ? 0 1 : 0;
? ? 1 ? 0 1 : 1;
? ? ? 0 0 0 : 0;
? ? ? 1 0 0 : 1;
endtable
endprimitive
If any address bit (a1, a0) is unknown, then the output value will be unknown (because there is no row which describes the output value for this combination of address signals).
If a1 = 0 and a0 = 0 then the signal from input i0 is driven to output (value of others inputs does not matter).
If a1 = 0 and a0 = 1 then signal from input i1 is driven to the output.
If a1 = 1 and a0 = 0 then signal from input i2 is driven to the output.
If a1 = 1 and a0 = 1 then signal from input i3 is driven to the output.
Example 2
primitive special_d_ff (q, clk, m, d, rst, set);
output q;
reg q;
input clk, m, d, rst, set;
table
// clk m d rst set : current : next;
// positive edge on clk and normal mode (m = 0)
(01) 0 0 0 0 : ? : 0 ; // line 1
(0x) 0 0 0 0 : ? : 0 ; // line 2
(x1) 0 0 0 0 : ? : 0 ; // line 3
(01) 0 1 0 0 : ? : 1 ; // line 4
(0x) 0 1 0 0 : ? : 1 ; // line 5
(x1) 0 1 0 0 : ? : 1 ; // line 6
// positive edge on clk and negation mode (m = 1)
p 1 ? 0 0 : 0 : 1 ; // line 7
p 1 ? 0 0 : 1 : 0 ; // line 8
// negative edge on clk and any mode (m = 0 or m = 1)
n ? ? 0 0 : ? : - ; // line 9
// reset
? ? ? 1 ? : ? : 0 ; // line 10
// preset
? ? ? 0 1 : ? : 1 ; // line 11
// any changes on inputs with no changes on clk
? * ? ? ? : ? : - ; // line 12
? ? * ? ? : ? : - ; // line 13
? ? ? * ? : ? : - ; // line 14
? ? ? ? * : ? : - ; // line 15
endtable
endprimitive
This is 'd' flip-flop with an additional input, which can convert it into a modulo 2 counter.
If m = 0 then this UDP works as a normal 'd' flip-flop (lines 1-6), but if m = 1 then it negates its current value (lines 7 and 8). If any falling edge occurs on the clk input, then it will not change the output (line 9). If rst is 1, then the output will go to 0 (line 10). If the rst is 0 and set is 1, then the output will go to 1 (line 11 - it means that rst has higher priority than set).
Any changes on the data input will not cause any changes on output (lines 12-15).
Example 3
primitive circuit_1 (o, i1, i2, i3);
output o;
input i1, i2, i3;
table
0 0 0 : 1 ;
0 0 1 : 1 ;
0 0 x : 1 ;
0 1 0 : 1 ;
0 1 1 : 1 ;
0 1 x : 1 ;
1 0 0 : 0 ;
1 0 1 : 0 ;
1 0 x : 0 ;
1 1 0 : 1 ;
1 1 1 : 1 ;
1 1 x : 1 ;
x 0 0 : 0 ;
x 0 1 : 0 ;
x 0 x : 0 ;
x 1 0 : 0 ;
x 1 1 : 0 ;
x 1 x : 0 ;
endtable
endprimitive
primitive circuit_2 (o, i1, i2, i3);
output o;
input i1, i2, i3;
table
0 ? ? : 1 ;
1 0 ? : 0 ;
1 1 ? : 1 ;
x b ? : 0 ;
endtable
endprimitive
'Circuit_1' and 'circit_2' are the same circuit, but the behavior of the 'circuit_1' was specified without special characters.
Important Notes
- Each row of sequential UDPs can contain only one transition.
- Special characters can make the UDP state table easier to read and write.
- Any undefined combination of inputs will set the output to x value.
UDP Instantiation
Formal Definition
The UDP instantiation provides a means of using UDP in modules.
Simplified Syntax
udp_name (strengths) #(delays) instance_name[range] (list of ports);
Description
UDPs can be instantiated only within modules.
The name of an instance is optional (Example 1). A UDP instantiation can contain strength and delays declarations (Example 2). UDPs do not support high-impedance (z) values, therefore only two delays are permitted. Signals connected to input ports can be any net or reg data type. Only net data type variables can be connected to the output port. The strength declaration can contain only drive strength.
It is possible to specify an array of UDP instances by using a range (Example 3).
Examples
Example 1
primitive d_ff (q, clk, d);
...
endprimitive
d_ff (q, clk, d);
The name of an instance is optional.
Example 2
d_ff (weak1, strong0) #5 d1 (q, clk, d);
UDP instance with strength and delay declaration.
Example 3
wire [3:0] q;
reg [3:0] d;
reg clk;
d_ff flips[3:0] (q, clk, d);
Important Notes
· UDP instantiation can contain up to two delay values.
Timing Check Tasks
Formal Definition
Timing Check Tasks are for verification of timing properties of designs and for reporting timing violations.
Simplified Syntax
$setup (data_event, reference_event, limit[, notifier]) ;
$skew (reference_event, data_event, limit[,notifier]) ;
$hold (reference_event, data_event, limit[,notifier]) ;
$recovery (reference_event, data_event, limit, [notifier]) ;
$setuphold (reference_event, data_event, setup_limit, hold_limit, [notifier]) ;
$width (reference_event, limit, threshold [,notifier]) ;
$period (reference_event, limit[,notifier]) ;
$nochange (reference_event, data_event, start_edge_offset, end_edge_offset [,notifier]) ;
Description
Timing check tasks are invoked every time critical events occur within given time limits. See the table below with descriptions of all arguments:
Argument | Description | Type |
Reference_event | The transition at a control signal that establishes the reference time for tracking timing violations on the data_event | Module input or inout that is scalar or vector net |
Data_event | The signal change that initiates the timing check and is monitored for violations. | Module input or inout that is scalar or vector net |
Limit | A time limit used to detect timing violations on the data_event | Constant expression or specparam |
Threshold | The largest pulse width that is ignored by the timing check $width | Constant expression or specparam |
Setup_limit | A time limit used to detect timing violations on the data_event for $setup. | Constant expression or specparam |
Hold_limit | A time limit used to detect timing violations on the data_event for $hold. | Constant expression or specparam |
Notifier | An optional argument that "notifies" the simulator when a timing violation occurs | Register |
$setup checks setup time. When modeling synchronous circuits, flip-flops need time to force a correct value. Data cannot change within the setup time because flip-flops cannot detect the new value. If data changes within a given time limit, $setup reports a timing violation. If a data event and reference event occur at the same time there is no violation. The$setup first checks timing data then records a new data value. The formula to report a timing violation is as shown below:
(time of reference event) - (time of data event) < limit
Notice that the limit argument has to be a positive number.
$skew checks the following:
(time of data event) - (time of reference event) > limit
$skew can be used to check synchronicity of clocks inside a circuit. If different clocks are used in a design and are synchronized, $skew will report a timing violation when the active edge of one of them occurs outside the time limit allowed for the other clock to occur.
When the data event and the reference event occur at the same time, $skew will not report a timing violation.
$hold will report a timing violation if the following formula is true:
(time of data event) - (time of reference event) < limit
$hold simply checks that data is stable in the specified interval of time after the edge of the clock. In flip-flops, data should remain stable for a given time after the active edge of the clock to allow for propagation of data.
Also, a violation will be reported if the data event and the reference event occur at the same time.
$recovery responds when the following formula is true:
(time of data event) - (time of reference event) < limit
The 'reference_event' must be an edge-triggered event: posedge or negedge. A timing violation occurs if the time interval between an edge-triggered reference event and a data event exceeds the 'limit'. If a reference event and data event occur at the same time, a timing violation is reported. If a 'reference_event' argument is specified without edge specification, an error is reported.
$setuphold checks setup and hold timing violations. This task combines the functionality of $setup and $hold in one task. The following formula has to be applied:
setup_limit + hold_limit > 0
'reference_event' have to be one of the following:
- $hold lower bound event
- $setup upper bound event
'data_event' have to be one of the following:
- $hold upper bound event
- $setup lower bound event
In $width both limit and threshold have to be positive numbers. The 'reference_event' must be the edge specification, otherwise an error will be reported. The 'data_event' is not specified directly, but by default means 'reference_event' with opposite edge. A timing violation occurs with the following formula:
threshold < (time of data event) - (time of reference event) < limit
$width reports when width of the active-edge is too small. In FF case it is very important to ensure that the width of an active-edge is sufficient and FF will work properly.
The $period checks that a period of signal is sufficiently long. The reference_event has to be an edge specification. The data_event is not specified directly and by default, is the same as a reference_event. The $period reports a timing violation when the following formula comes true:
(time of data event) - (time of reference event) < limit
The $nochange checks if the data signal is stable in an interval of start_edge_offset and end_edge_offset. If the signal has changed, a timing violation is reported. The reference_event argument can be posedge or negedge but the edge control specifiers are disallowed.
Examples
Example 1
module setup (data1, data2, q);
input data1, data2;
output q;
and (q, data1, data2);
specify
specparam tsetup = 7, delay = 10 ;
(data1 => q) = 10 ;
$setup(data1, posedge data2, tsetup);
endspecify
endmodule
Example 2
module two_clocks (clk1, clk2, q);
input clk1, clk2;
output q;
specify
specparam tskew = 7;
$skew(posedge clk1, posedge clk2, tskew);
endspecify
endmodule
Example 3
module hold (data1, data2, q);
input data1, data2;
output q;
and (q, data1, data2);
specify
specparam thold = 7, delay = 10 ;
(data1 => q) = 10 ;
$hold(posedge data2, data1, thold);
endspecify
endmodule
Example 4
module recovery (in1, out1);
input in1 ;
output out1 ;
assign out1 = in1 ? 1'b1 : 1'bz ;
specify
specparam trecovery = 10;
$recovery(posedge in1, out1, trecovery);
endspecify
endmodule
Example 5
module setuphold (data1, data2, q);
input data1, data2;
output q;
and (q, data1, data2);
specify
specparam tsetup = 7,
thold = 7,
delay = 10 ;
(data1 => q) = 10 ;
$setuphold(posedge data2, data1, tsetup, thold);
endspecify
endmodule
Example 6
module width (data1, data2, q);
input data1, data2;
output q;
and (q, data1, data2);
specify
specparam twidth = 10,
delay = 10 ;
(data2 => q) = 10 ;
$width(posedge data2, twidth);
endspecify
endmodule
Example 7
module dff (clk, q);
input clk;
output q;
buf (q, clk);
specify
specparam tperiod = 100 ;
$period(posedge clk, tperiod);
endspecify
endmodule
Example 8
module nochange (data1, data2, q);
input data1, data2;
output q;
and (q, data1, data2);
specify
specparam tstart = -5,
tend = 5 ;
$nochange(posedge data2, data1, tstart, tend);
endspecify
endmodule
Important Notes
- All timing check system tasks should be invoked within specify blocks.
Tasks
Formal Definition
Tasks provide a means of splitting code into small parts. Often tasks consist of frequently used functionalities.
Simplified Syntax
task identifier;
parameter_declaration;
input_declaration;
output_declaration;
inout_declaration;
register_declaration;
event_declaration;
statement;
endtask
Description
Task definition begins with the keyword task and ends with the keyword endtask. A task should be followed by a task identifier and end with a semicolon. A task can contain a declaration of parameters, input arguments, output arguments, inout arguments, registers and events (these declarations are similar to module items declaration) but they are not required. Net declaration is illegal.
A task can contain zero or more behavioral statements, e.g. case statement, if statement. A begin-end block is required for bracketing multiple statements.
The task enabling statement should be made up of a task identifier and the list of comma-separated task arguments. The list of task arguments should be enclosed in parenthesis. If the task does not contain any argument declarations, then it should be enabled by specifying its identifier followed by a semicolon (Example 2).
The list of task enabling arguments should correspond exactly to the list of task arguments. If a task argument is declared as an input, then a corresponding argument of the task enabling statement can be any expression. If a task argument is declared as an output or an inout then the corresponding argument of the task enabling statement should be one of the following items:
- Register data types
- Memory references
- Concatenations of registers or memory references
- Bit-selects and part-selects of reg, integer and time registers
Only the last assignment to an output or an inout argument is passed to the corresponding task enabling arguments. If a task has assignments to global variables, then all changes of these variables are effective immediately.
Tasks can enable others tasks (Example 3) and functions. A task may be enabled several times in a module. If one task is enabled concurrently, then all registers and events declared in that task should be static, i.e., one variable for all instances.
A task can contain time-controlling statements. A task does not return a value by its name.
Examples
Example 1
task first_task;
parameter size = 4;
input a;
integer a;
inout [size-1:0] b;
output c;
reg [size-1:0] d;
event e;
begin
d = b;
c = |d;
b = ~b;
if (!a) -> e;
end
endtask
This is an example of using parameters, input arguments, inout arguments, output arguments, registers and events within tasks. The 'a' argument is declared as an input and as an integer data type.
'First_task' can be enabled as follows:
integer x;
reg a, b, y;
reg [3:0] z;
reg [7:0] w;
first_task(x, z, y);
first_task(x, w[7:4], w[1]);
first_task(1, {a, b, w[3], x[0]}, y);
When being enabled, the first argument of the 'first_task' should be an integer data type expression, the second should be a 4-bit register expression, and the last argument should be 1-bit register expression.
Example 2
reg a, b;
task my_task; // task definition
begin
a = 1'b1;
b = 1'bx;
end
endtask
my_task; // task enabling
If 'my_task' is enabled then it will change the value of global variables 'a' and 'b'.
Example 3
task negation;
inout data;
data = ~data;
endtask
task my_nor;
input a, b;
output c;
begin
negation(a);
negation(b);
c = a & b;
end
endtask
The 'my_nor' task enables negation tasks.
Important Notes
- A task can contain time-controlling statements
- A task does not return any value by its name
Structured Procedures
Formal Definition
Structured procedures provide a means of modeling blocks of procedural statements.
Simplified Syntax
always statement
initial statement
function
task
Description
Functions and tasks are described in the section: Task and Functions.
The initial statement (Example 1) is executed only during a simulation run. The always procedural block statement (Example 2) is executed continuously during simulation, i.e. when the flow of program reaches the last statement in the block, the flow continues with the first statement in the block.
The always statement should contain at least one procedural timing control because otherwise it may hang the simulation.
Module definition can contain more than one initial or always statement.
Care must be taken when same reg type variables are used in multiple procedural blocks, initial or always. This is because these blocks run in parallel and changing or assigning to one variable affects the same variable in another parallel block.
Examples
Example 1
initial out = 1'b0;
initial begin
#10;
a = 1'b0;
#10;
a = 1'b1;
#10;
a = 1'bz;
end
Example 2
always @(posedge clk)
q = d;
always #10 clk = ~clk;
initial clk = 0;
initial repeat(20)#\10 clk=~clk;
The first initial statement sets clk to 0 at time 0, and the second initial block toggles the clk 20 times every 10 time units.
Important Notes
· The always statement should contain at least one procedural timing control.
Strings
Formal Definition
The strings are sequences of 8-bit ASCII characters enclosed within quotation marks.
Simplified Syntax
"This is a string"
reg [8*number_of_characters:1] string_variable;
Description
The string should be given in one line. Strings can contain special characters (Example 1).
Character | Meaning |
\n | New line character |
\t | Tab character |
\\ | \ character |
\” | " character |
\ddd | A character specified by octal digit |
Table 24: Summary of special characters
String variables should be declared as reg type vectors (Example 2). Each character needs 8 bits.
If a string variable is used in an expression, it should be treated as an unsigned value. If the size of a string assigned to a string variable is smaller than the declared size of the variable, then it will be left-padded with zeros.
The null string "” should be treated same as "\0”.
Concatenations of string variables preserve left-padded zeros of these variables (Example 3).
Examples
Example 1
"\n This is the first line\n This is the second line"
"\t Line\t with\t tab\t characters"
Example 2
reg [8*12:1] message;
The message variable can contain 12 characters.
Example 3
reg [10*8:1] s1, s2;
s1 = "Verilog";
s2 = "-HDL";
{s1, s2} <> {"Verilog", "-HDL"}
These expressions are not equal because {s1, s2} has 0s between "Verilog” and "-HDL” and {"Verilog”, "-HDL”} does not have any 0s between words.
Important Notes
- Concatenation of string variables preserves left-padded zeros of these variables.
Strengths
Formal Definition
The strength declaration construct is used for modeling net type variables for a close correspondence with physical wires.
Simplified Syntax
(Strength1, Strength0)
(Strength0, Strength1)
Strength1:
supply1, strong1, pull1, large1, weak1, medium1, small1, highz1
Strength0:
supply0, strong0, pull0, large0, weak0, medium0, small0, highz0
Description
Strengths can be used to resolve which value should appear on a net or gate output.
There are two types of strengths: drive strengths (Example 1) and charge strengths (Example 2). The drive strengths can be used for nets (except trireg net), gates, and UDPs. The charge strengths can be used only for trireg nets. The drive strength types are supply, strong, pull, weak, and highz strengths. The charge strength types are large, mediumand small strengths.
All strengths can be ordered by their value. The supply strength is the strongest and the highz strength is the weakest strength level. Strength value can be displayed by system tasks ($display, $monitor - by using of the %v characters - see Display tasks for more explanation).
Strength | Value | Value displayed by display tasks |
supply | 7 | Su |
strong | 6 | St |
pull | 5 | Pu |
large | 4 | La |
weak | 3 | We |
medium | 2 | Me |
small | 1 | Sm |
highz | 0 | HiZ |
Table 23 Strengths ordered by value
If two or more drivers drive a signal then it will have the value of the strongest driver (Example 3).
If two drivers of a net have the same strength and value, then the net result will have the same value and strength (Example 4).
If two drivers of a net have the same strength but different values then signal value will be unknown and it will have the same strength as both drivers (Example 5).
If one of the drivers of a net has an H or L value, then signal value will be n1n2X, where n1 is the strength value of the driver that has the smaller strength, and n2 is strength value of driver that has the larger strength (Example 6).
The combinations (highz0, highz1) and (highz1, highz0) are illegal.
Examples
Example 1
and (strong1, weak0) b(o, i1, i2);
Instance of and gate with strong1 strength and weak0 strength specified.
Example 2
trireg (medium) t;
The charge strength declaration for trireg net.
Example 3
buf (strong1, weak0) g1 (y, a);
buf (pull1, supply0) g2 (y, b);
If a = 0 and b = 0 then y will be 0 with supply strength because both gates will set y to 0 and supply (7) strength has bigger value than weak (3) strength.
If a = 0 and b = 1 then y will be 1 with pull strength because g1 will set y to 0 with weak (3) strength and g2 will set y to 1 with pull (5) strength (pull strength is stronger than the weak strength).
If a = 1 and b = 0 then y will be 0 with supply strength because g1 will set y to 1 with strong (6) strength and g2 will set y to 0 with supply (7) strength (supply strength is stronger than the strong strength).
If a = 1 and b = 1 then y will be 1 with strong strength because g1 will set y to 1 with strong (6) strength and g2 will set y to 1 with pull (5) strength.
Example 4
buf (strong1, weak0) g1 (y, a);
buf (strong1, weak0) g1 (y, b);
If a = 0 and b = 0 then y will be 0 with weak strength.
If a = 1 and b = 1 then y will be 1 with strong strength.
Example 5
buf (strong1, weak0) g1 (y, a);
buf (weak1, strong0) g1 (y, b);
If a = 1 and b = 0 then y will be x with strong strength.
Example 6
bufif0 (strong1, weak0) g1 (y, i1, ctrl);
bufif0 (strong1, weak0) g2 (y, i2, ctrl);
If ctrl = x, i1 = 0, and i2 = 1 then y will be x with 36X strength, because g1 will set y to L with strong strength (StL - 6) and g2 will set y to H with weak strength (WeH - 3).
Important Notes
- If one of the drivers has an H or L value, then the output value will be X.
Stochastic Analysis Tasks
Formal Definition
Stochastic analysis tasks provide a means of managing queues.
Simplified Syntax
$q_initialize(identifier, type, length, status) ;
$q_add(identifier, job, information, status) ;
$q_remove(identifiers, job, information, status) ;
$q_full(identifier, status) ;
$q_exam(identifier, statistic_code, statistic_value, status) ;
Description
All statistic analysis tasks include identifier, and status arguments. The identifier is a unique integer value identifying the queue. The status argument is an output integer parameter giving information about the correctness of the specified task execution.
Status | Message |
0 | The queue generation was successful. |
1 | The queue cannot be increased; queue is full. |
2 | The identifier is undefined; please define an identifier. |
3 | Cannot remove a value; queue is empty. |
4 | The queue cannot be generated; this type is unsupported. |
5 | The length parameter is <= 0; the queue cannot be generated. |
6 | The identifier is duplicated; please define new identifier. |
7 | The queue cannot be generated; insufficient memory. |
$q_initialize creates a queue. Parameter type determines the type of a queue. In case of 1, the created queue is FIFO and in case of 2 the queue is LIFO. Parameter length is an integer value specifying the maximum number of entries.
$q_add adds a new entry to the queue. Parameter job identifies the job. The special user-defined parameter, information, can maintain any information useful for the user.
$q_remove receives data from the queue. Parameters of this task are the same as those of the $q_add task.
$q_full checks to see of the queue identified by the identifier parameter is full.
$q_exam returns statistical information about the queue. Parameter statistic_code determines what you need to check and returns the result in statistic_value. The following table lists all possible values of statistic_code:
Statistic_code | Statistic_value |
1 | Length of queue. |
2 | Mean interarrival time. |
3 | Maximum length of queue. |
4 | Shortest wait time. |
5 | Longest wait time for jobs still in the queue. |
6 | Average wait time in the queue. |
Examples
Example 1
always @(posedge clk)
begin
// check if queue1 is full
$q_full(queue1, status);
// if full then show message and remove one item
if (status) begin
$display("Queue is full”);
$q_remove(queue1, 1, info, status);
end
// add a new item to queue1
$q_add(queue1, 1, info, status);
// show message if there was an error
if (status)
$display("Error %d”,status);
end
end
This example shows how to add a new element to the queues.
Important Notes
- The status parameter value should be checked after all operations on the queue.
Specify Block
Formal Definition
Allows a specific delay across a module.
Simplified Syntax
specify
specparam declaration ;
path declaration ;
system timing check ;
endspecify
Description
The Specify block was designed to define a delay across a module. It starts with specify and ends with the endspecify keyword. Inside the block the user can specify: specparamdeclaration, path declaration or system timing check.
The syntax of specparam declaration is the same as that of the parameter declaration. After the specparam keyword the user can specify any number of parameters but only constant expressions are allowed on the right-hand sides of parameter assignments. A comma can separate the assignments, and the last statement ends with a semicolon. A previously declared specparameter can be used to declare the new specparameters. Unlike parameters, specparams cannot be overwritten, nor can they be used outside of a specify block.
Examples
Example 1
module ...
...
specify
(In => Out) = (10);
endspecify
...
endmodule
A specify block with only a path declaration. Delay between input In and output Out is 10 time units.
Example 2
module ...
...
specify
specparam TRise = 10,
TFall = 15;
(In => Out) = (TRise, TFall) ;
endspecify
...
endmodule
Specparam declaration with two parameters TRise and TFall to specify delays on rising transition and falling transition.
Example 3
module ...
...
specify
specparam TRise = 10,
TFall = 15;
(In => Out) = (TRise, TFall) ;
$setup(Data_in, posedge Clock, TRise) ;
endspecify
...
endmodule
The full specify block with specparam declaration, path declaration and system timing check task.
Important Notes
· Specify blocks have to be inside the module declaration location.
· Specparams are not visible outside of the Specify blocks.
· The defparam keyword cannot be used to override a specparam value.
State Dependent Path
Formal Definition
State Dependent Path is a path that occurs only when the condition is met.
Simplified Syntax
if (condition) simple_module_path;
if (condition) edge_sensitive_path;
ifnone simple_module_path;
Description
Generally, state dependent path is comprised of three parts. A condition that enables the module path, a module path description and a delay that applies to the module path.
The condition is an expression using scalars or vectors of any type. It can also be part-selects or bit-selects of a vector. Constant numbers and specparams can be used in the condition expression. The result of the conditional expression can be one bit or multiple bits. If it is more than one bit, the least significant bit represents the result.
When no edge transition is specified for the inputs, it is called the simple state-dependent path. Example 1 shows the simple-dependent path.
If any edge transition is specified for the input, then it is called an edge-sensitive state-dependent path. Different delays can be used to the same path if the following rules are followed:
a. A declaration must be unique and should use an edge or a conditional expression or both.
b. The port for which the delay is specified must be referenced in exactly the same way. You cannot mix part select, bit-select and complete ports.
Examples
Example 1
module example1 (cond, in_1, in_2, out);
input in_1, in_2, cond ;
output out ;
and (out, in_1, in_2) ;
specify
specparam TRise1 = 5,
TFall1 = 5,
TRise2 = 7,
TFall2 = 7;
if (cond) ( in_1, in_2 *> out ) = (TRise1, TFall1);
if (~cond) ( in_1, in_2 *> out ) = (TRise2, TFall2);
endspecify
endmodule
If a conditional expression 'cond' is true, TRise1 and TFall1 will be assigned to a path as delays. When the conditional expression 'cond' is false, TRise2 and TFall2 will be used as the path delays.
Important Notes
· When a conditional expression evaluates to x or z, it should be treated as true.
-
This is 8-bit microprocessor with 5 instructions. It is based on 8080 architecture. This architecture called SAP for Simple-As-Possible comp...
-
Q1: What is UVM? What is the advantage of UVM? Ans: UVM (Universal Verification Methodology) is a standardized methodology for verify...
-
There are some differences between UDIMMs and RDIMMs that are important in choosing the best options for memory performance. First, let’s ta...
-
Up/down counter circuits are very useful devices. A common application is in machine motion control, where devices called rotary shaft encod...
-
A small RISC CPU (written in VHDL) that is compatible with the 12 bit opcode PIC family. Single cycle operation normally, two cycles when th...