Thursday, March 08, 2012

Design for Testing and Testability Slides free links



http://www.mediafire.com/?rvzq35matcs3dx7
http://www.mediafire.com/?46xo6zgbc0q58bf
http://www.mediafire.com/?9rgcu3gi8czipme
http://www.mediafire.com/?2k338xfwqudczyj
http://www.mediafire.com/?weby5w1gko819bw
http://www.mediafire.com/?r26qr3dqpcc6aai
http://www.mediafire.com/?lv24a8ptx7jm8z2
http://www.mediafire.com/?fdky90kkdt8oeli
http://www.mediafire.com/?ax6rvs5510f6bmg
http://www.mediafire.com/?piaxia1u8qy2q9z
http://www.mediafire.com/?eloqfo548krku47
http://www.mediafire.com/?5kefjcthdrpgkgp
http://www.mediafire.com/?6d7n0p8f48430dm
http://www.mediafire.com/?7luvhoeswtqaua1
http://www.mediafire.com/?2cjuiaov9vow3cx
http://www.mediafire.com/?438d69bj17wmyk9
http://www.mediafire.com/?pcn6osg33xv9tj5
http://www.mediafire.com/?a3q0xti92cxg2b1
http://www.mediafire.com/?ir3lmam9jx4hcsd
http://www.mediafire.com/?73u97d5x8qbko79
http://www.mediafire.com/?qqklvihu7g4hc1h
http://www.mediafire.com/?z4zxkkhw6khdiju
http://www.mediafire.com/?ngbddck6wkvfjfy
http://www.mediafire.com/?5hwa6izyc0ya12z
http://www.mediafire.com/?wd15o3k4kluloe8
http://www.mediafire.com/?ilr01gcnsjfrmfw
http://www.mediafire.com/?x43ltczwzl5l673
http://www.mediafire.com/?3n44841pon4gnbg
http://www.mediafire.com/?454q1r5tjds59nz
http://www.mediafire.com/?djx4ia62di9odrs
http://www.mediafire.com/?e4fo3nzofxs11i1
http://www.mediafire.com/?8vcgctd19s019v6
http://www.mediafire.com/?e2b22apsqshlb2w
http://www.mediafire.com/?c58ucxxxbvaxdop
http://www.mediafire.com/?19racfbumkll24m
http://www.mediafire.com/?wrfhrkdsk4743cm
http://www.mediafire.com/?orgduspb782yajd
http://www.mediafire.com/?jnqd824d7k2b9do
http://www.mediafire.com/?6d1a5oaaxapo768
http://www.mediafire.com/?ngd4smj7dzojgla
http://www.mediafire.com/?vy3ssou1347d2zw

Verilog codes of combinational and sequential Circuits free download link

VLSI Seminars with PPTs free download

free seminars downloads with ppts on 4G and Blue eyes technology

VLSI & ECE seminar topics with PPTs free downloads


http://www.mediafire.com/?n77dan3ovdwyoy3   
http://www.mediafire.com/?8ncruxr37o1dbqb     
http://www.mediafire.com/?jqhvobf6j4gbp6e     
http://www.mediafire.com/?ldw3st2dga2stl5     
http://www.mediafire.com/?7vpjohszup17k17     
http://www.mediafire.com/?byqkx4heq467zrs
http://www.mediafire.com/?hdhpqp6bijp8eyb
http://www.mediafire.com/?8xpbj3cv6m923zc
http://www.mediafire.com/?4rx1a3bc32x6k9n
http://www.mediafire.com/?3f97tr27b9t0v73
http://www.mediafire.com/?ffr33ne7vt54ls5
http://www.mediafire.com/?24pekugj4ef2008
http://www.mediafire.com/?s9q17bsfa8d3d51
http://www.mediafire.com/?ee5luy94agbsa01
http://www.mediafire.com/?mab84v7i5zbp1ui
http://www.mediafire.com/?q0wkz9n93y4ln3z
http://www.mediafire.com/?3c679h3tum7bxrh
http://www.mediafire.com/?6z1q9vtu94c8soo
http://www.mediafire.com/?izrf4bbjj421l2j
http://www.mediafire.com/?2892s7foz3xaxb5
http://www.mediafire.com/?p3k68dbbn40cnb4




http://www.mediafire.com/?uznf0ycv2n9haac
http://www.mediafire.com/?cj5cbik26lgtdcb
http://www.mediafire.com/?navkma79im27ad4
http://www.mediafire.com/?hdq7hc5hac4g5f1
http://www.mediafire.com/?mafzei99pnplto3
http://www.mediafire.com/?y7d6c04p4t4unc7
http://www.mediafire.com/?1a7l840v4ph7cjp
http://www.mediafire.com/?gkdm8zakbh4bxpe
http://www.mediafire.com/?uof446duxnid90o
http://www.mediafire.com/?mbtta9ma4wivg2a
http://www.mediafire.com/?zp4vvj353u68bv8
http://www.mediafire.com/?av50d2652o43thx
http://www.mediafire.com/?l1p1vrqlzc9471c
http://www.mediafire.com/?qfxck7x5az4jxc3
http://www.mediafire.com/?ksfnj74sj7dgmoz
http://www.mediafire.com/?if69zw8w7lfo989
http://www.mediafire.com/?kt4k0nk5fbenk29
http://www.mediafire.com/?f42efzb26jg0xb6
http://www.mediafire.com/?bq922lxb9peiraj
http://www.mediafire.com/?93h9mvhusmcwbl2
http://www.mediafire.com/?b3wz7ldld0g1lju
http://www.mediafire.com/?0rdyelyksec50ue
http://www.mediafire.com/?x8q9mkir7v2od45
http://www.mediafire.com/?q84rbe4kfqryo7v
http://www.mediafire.com/?cbkczs1qdbej5cd
http://www.mediafire.com/?sheqwqwy1lfd2qo
http://www.mediafire.com/?82ock1vc41w33zm
http://www.mediafire.com/?i843eopsuvmr4i9



http://www.mediafire.com/?7bs62vo8kearx3a
http://www.mediafire.com/?x97n6ux8p0o8w7y
http://www.mediafire.com/?45btooj9oyylttu
http://www.mediafire.com/?97p91x7y87zk182
http://www.mediafire.com/?4d113gzzt151o3g
http://www.mediafire.com/?8euszpld7kox7uj
http://www.mediafire.com/?lbbkrsqe8r3g63r
http://www.mediafire.com/?xp5hpk5p9blp5ry
http://www.mediafire.com/?tomk8k43kjjb2vd
http://www.mediafire.com/?fz7auw8jf28omz2
http://www.mediafire.com/?ei5cq02y5qc0qyb
http://www.mediafire.com/?gmz6uej0bj3g0fr
http://www.mediafire.com/?bi4a5ngtfyl38xb
http://www.mediafire.com/?v3dg88cahq88fiv
http://www.mediafire.com/?ec4qziqv78t1dcx
http://www.mediafire.com/?1omvcc42v4k7pni
http://www.mediafire.com/?289g8a4c0sfxxa9
http://www.mediafire.com/?wgzqroahjgn68by
http://www.mediafire.com/?d42zd77st8l25cf
http://www.mediafire.com/?igfhqg7en2a38qz
http://www.mediafire.com/?9xaza4g6j9z2z49
http://www.mediafire.com/?9hb31r1p420eib2
http://www.mediafire.com/?d2ajewa0iyydo0w
http://www.mediafire.com/?drrc5z20ob9s5aj
http://www.mediafire.com/?3ar4aw38aaha2sh
http://www.mediafire.com/?h7dr4j463m9os21
http://www.mediafire.com/?cd53hfj35yzprh3

Saturday, March 03, 2012

VLSI ups IC forecast amid lull

VLSI Research Inc. has increased its IC growth forecast for 2011. For some time, VLSI said that the IC market would hit $268.7 billion in 2011, up 8.1 percent over 2010. In the new forecast, VLSI said that the IC market will now hit $270.7 billion in 2011, up 8.9 percent over 2010.


VLSI Research Inc. has increased its IC growth forecast for 2011.

For some time, VLSI said that the IC market would hit $268.7 billion in 2011, up 8.1 percent over 2010. In the new forecast, VLSI said that the IC market will now hit $270.7 billion in 2011, up 8.9 percent over 2010.

Last year, the IC market grew 30.9 percent, according to the firm. Right now, meanwhile, there are mixed signals in the IC market. ''Order activity turned lower for the first time this year,'' according to VLSI, in a a newsletter.

''It’s driven largely by the weakness in the memory market, according to the firm. ''DRAM orders have fallen to low levels and they’ve yet to bottom. NAND flash is doing well and it’s picked up some of the slack, though it has not been enough to offset the weakness in DRAM. The rebound of DRAM prices early in the year brought hopes that this market has turned the corner and that spending would pick up in the second half of the year. However, the recent slide of DRAM spot prices is troublesome, putting a big question mark for future spending plans.''

There is more bad new for DRAM. ''DRAM spot prices plunged for the second straight week despite rumors of supply disruptions. These rumors failed to drive prices higher because some DRAM manufacturers were releasing supply in the spot market. As a result, the earlier optimism among traders has turned into caution. NAND Flash fared better than DRAM. Still, slow demand is a nagging issue for NAND and it’s putting ASPs under pressure despite tight supply in the spot market,'' according to the firm.

NAND and other chips could get a boost, thanks to Apple Inc.'s iPad2 announcement, which is expected today. ''Regarding the iPad, our contacts see an improved iPad 2 production forecast for both 1Q11 and 2Q11. 1Q11 iPad production is now set at 5.5 million units, up from 5.1 million units previously, with iPad driving about 2 million units of that total (up from about 300,000 units previously),'' said Craig Berger, an analyst with FBR, in a report. ''For 2Q11, our contacts now see 7.2 million units of iPad production, with almost all of that production of iPad 2 devices, meaningfully ahead of the prior iPad 2 production ramp plans.''

But for the most part, there is a lull in the quarter. ''Regarding updated back-end assembly/test checks, we see stability in aggregate versus prior checks, with 1Q11 production set to seasonally fall about 6.5 percent quarter-over-quarter, with slight positive production revisions by Broadcom, AMD, and Xilinx not fully offsetting production declines by Mediatek and Marvell,'' he said.

Forecast mania

''SanDisk believes that 20-25 percent of the notebook market will eventually be cannibalized by tablets,'' said Hans Mosesmann, an analyst with Raymond James & Associates Inc.

The outlook is bright for NAND. ''Smartphone NAND content is expected to move from 8GB to 20GB by 2014. In tablets the move is from 31 GB to 96 GB,'' he said.

''SSDs are expected to be a bigger factor as HDD (hard disk drive) replacement becomes less important relative to 'small form factor' NAND (MacBook Air like products). Look for SSDs to be highly price elastic, particularly in 2012 as units increase to ~30 million units (130 GB content) from less than 10 million units (90 GB content) seen in 2010,'' he said.

''Interestingly, SanDisk sees the 128 GB SSD price 'delta', vs. a typical HDD (1 TB size), to close into the $50 range from last year's ~$200 delta. Notebook OEMs at the $50 price delta will move aggressively to SSD solutions and hence SanDisk believes 2012 will see an inflection point for SSD adoption, a dynamic we believe is tough to argue against,'' he said.

Rising sales of tablet devices coming at the expense of conventional netbook PCs will contribute to a low single-digit decline in shipments of hard disk drives (HDDs) for the first quarter of this year, according to IHS iSuppli.

HDD shipments in the first quarter of 2011 are anticipated to reach 160.9 million units, down 3.9 percent from 167.5 million in the fourth quarter of 2010.

“Tablets like Apple Inc.’s iPad represent a major threat to HDD demand,” said Fang Zhang, analyst for storage systems at IHS, in a report. “Among the various computing segments in which HDDs are used, the netbook—with lower computing capabilities than either a desktop or laptop—is considered the most vulnerable to being supplanted by tablets, which do not use hard disks as storage media. And as tablet adoption gains momentum, netbooks will suffer even greater declines.”

More forecasts

There are other mixed signals in the market. Pricing for large-sized liquid-crystal display (LCD) panels ''are continuing to decline in February in light of soft demand and rising inventories, but the situation could improve by April when brands increase their TV panel purchasing,'' according to IHS iSuppli research.

Prices of large-sized LCD panels, defined as those ranging from 10 inches to 55 inches in the diagonal dimension, are projected to fall 1.2 percent on average across the product’s three main applications of televisions, monitors and notebooks.

Price declines in the 1 percent range have been the norm in the last four months, and panel prices as a whole have not risen since March 2010, as shown in the attached figure. In particular, pricing for TV panels fell throughout the period, while that of monitor and notebook panels rose slightly in October and November.

“The current price retreat can be traced to escalating inventory for both suppliers and buyers,” said Sweta Dash, senior director for liquid-crystal displays at IHS, in a report. “While average inventory among panel suppliers stands at a normal 29 days, some suppliers are seeing a decrease while others are witnessing a surge, so the situation in general is more ambiguous than what inventory levels suggest.”

On another front, shipments of CMOS image sensors for digital still cameras (DSCs) are set for rapid growth over the next three years, allowing them to exceed those of charge-coupled devices (CCD) for the first time ever in 2013, according to new IHS iSuppli research.

CMOS image sensor shipments for DSCs in 2013 will reach 71.1 million units, up from 30.7 million in 2010. Meanwhile, CCD shipments will decline to 66.9 million in 2013, down from 94.1 million in 2010.

By 2014, more than 85 million DSC CMOS units will be shipping, compared to 51 million for CCD. The attached figure presents the 2009-2014 unit shipment forecast for CMOS and CCD image sensors in DSCs.

“After many years of using CCD technology, original equipment manufacturers (OEM) like Sony, Canon, Kodak, Casio and Samsung now are turning to CMOS, which has narrowed the image quality gap with CCDs to a great degree,” said Pamela Tufegdzic, analyst for consumer electronics at IHS, in a report. “This has allowed DSC makers to enjoy the advantages provided by CMOS sensors, including lower power consumption and reduced cost.”

On another front, automakers are starting to capitalize on the demand for the same dynamic multimedia experience in the car that consumers have become accustomed to in the home; that is, to integrate in-vehicle infotainment (IVI) systems into a wider range of automobiles in order to reenergize new vehicle sales. As a result, new In-Stat research forecasts that over 35 million in-vehicle infotainment (IVI) systems are expected to ship in 2015.

Next Generation Power Packages for Implantables

When it comes to implantable medical devices, space savings is one of the most critical design concerns. This article reviews packaging concepts available to reduce the space required by electronic power components so that the overall implant can shrink and/or more features can be added without enlargement.


The market for implantable medical devices remains significant. Both the demographic drivers and the number of uses are clearly expanding. Much of the growth comes from efforts to expand the therapies electronics can treat. Modified pacemaker type products can be used to block chronic back and leg pain, and migraines. Moreover, others modify behavior associated with depression, anxiety, obsessive compulsive disorders, and bulimia. Normally a slow change industry, increasing pressures on medical device suppliers for cost, performance, and quality are resulting in product and service innovations. But miniaturization remains the key growth driver for implantable medical devices. For patients, a smaller device is less intimidatingthe incision becomes smaller, the procedure is less obtrusive, the body heals quicker, and the implant is less noticeable.

High-power components used in implantable medical devices, such as IGBTs, SCRs, MOSFETs, and rectifiers, provide unique layout challenges for the circuit designer. First, a large die size is required to handle power. For example, in implantable cardio defibrillators, power can be as high as 700 volts with surge currents up to 60 amps. Second, electrical contact is needed on both the top and bottom of the device. Power devices utilize a “vertical” manufacturing structure that allow for higher blocking voltage in conjunction with higher currents. Third, high voltage arcing must be controlled. Chip and wire is still commonly used in implantables. Careful die and wire spacing, in addition to a protective coating, are critical to prevent arcing. Designers are looking for a package solution that eliminates arcing, coatings, and wire bonds, while minimizing board space. A chip scale, flip chip power package that brings the backside contact to the same plane with the front side is needed.

Ceramic Carrier
One method of creating a planar flip chip power package is to attach the die to a ceramic carrier. The ceramic carrier in this case is shaped like an inverted “L.” The die is soldered or epoxied onto the ceramic. Metal traces are then embedded into the ceramic, routing the backside contact to the front side, forming a planar device. Solder bumps are placed on both the die and the carrier to allow for the planar flip chip to be attached, resulting in overall space savings versus chip and wire. Moreover, ceramic is a good insulator against high voltage arcing. The manufacturing issues to be overcome include X, Y, and Z planarity since the die can shift or tilt when being attached to the carrier.

TSV
Another solution may be the use of metal filled through-silicon vias (TSV). When using this method, the die size is expanded to include non-active silicon adjacent to the active silicon region. A channel is created through the non-active silicon by first creating a hole through the silicon and then filling the hole with metal (Figure 1). Current can flow from the active region, through the backside metal and up the TSV. This allows the backside contact to be moved to the front side. The die size grows, but not as much as when a ceramic carrier is used. Figure 1 is just one configuration when using TSV. Several variations can be achieved from this basic structure. For example, creating backside contacts that allow for interposer connection or die stacking.

TSV is an emerging manufacturing process and appears to be a promising solution to also handle large currents associated with power devices. But based on observations made by VLSI Research at the recent International Interconnect Technology Conference, “High-volume TSV is still some years away.” Until high-volume is achieved, per wafer processing costs will remain prohibitively high. Lower cost TSV solutions are being examined for power device manufacturing.

Power Die Stacking

Power die stacking is being implemented today. The technology requires starting with two or more known good die and vertically soldering them together. These designs use well-established techniques, including interposers, soldering, and wirebonding, to vertically integrate the die functions. The major advantages of this method are that it requires half the board space and allows mixing of wafer process technologies. The major disadvantages are that wire bonds are still required, voltage arcing can still be an issue, and cumulative yield losses tend to drive costs higher. Folded flex circuits is another method of die stacking that can be used. Using origami-like folding methods, power die can be flipped upon each other. The trick is how to make contact on both the top and bottom of a power die without wire bonds while, at the same time, maintaining a low profile.

Power Silicon on Insulator
Power Silicon on Insulator (PSOI) is a sealed chip scale package that takes a different approach to bringing the electrical connections to the same side (Figure 2). PSOI develops the active regions on the same side using standard processing steps but joins the regions with a top metallization. The top side is then sealed and protected by attaching a top side insulator. External metalized contacts are developed on the bottom of the device much like a flip chip package, but with PSOI, the bottom and sides are insulated, forming a unique “wafer level package.” The die can then be sawn in any form, single, duals, quads, etc. The concept eliminates any back-end manufacturing steps. After sawing in wafer form, the product is tested and shipped in suitable containers, such as waffle or gel packs, for automatic pick-and-place.

Top, bottom, and side insulators isolate the junction from environmental contaminates and moisture sensitivity. The process eliminates wire bonds and protective coating, reducing overall chip size. PSOI can also be manufactured with top contacts for stacking, providing excellent thermal characteristics and small size while maintaining surge performance. This process provides die-to-die electrical isolation and reduces parasitics. Overall yields must be on par with standard wafer yields to match costs. Depending on the package technology currently in use, overall circuit footprint can be reduced 20% to 55%.

Conclusion
Fitting more features into a shrinking area while maintaining absolute quality are the leading technological challenges for today’s implantable medical design engineers. Unlike planar devices, power device shrinkage cannot be solved using lithography node reduction. Therefore, advanced 3D circuit packaging requiring the use of chip scale flip chip type power package is the solution.

Several options exist for creating a planar flip chip type power device. Most promising are the ceramic chip carrier, TSV, and PSOI packaging technologies.

Coverage - Examples

Coverage - Examples

Example for Coverage

(a) Ethernet

(i) Example

program Eth_cov;
bit x;
class Eth;
bit [63:0] header;
bit [0:15] frmlength;
bit clk;
covergroup cov1 @(posedge clk); // embedded covergroup
coverpoint frmlength
{
bins normal = { [1000:1536] };
bins normal_low = { [46:999] };
bins normal_d[] = default;

}
coverpoint header;
endgroup
function new();
cov1 = new();
endfunction

task clk_gen();
forever clk = #10 ~clk;
endtask
task pkt();
forever
begin
#10;
frmlength = frmlength+1;
header = header+2;
$display ($time," display the clock =%b header =%d frmlength =%d",clk,header,frmlength);
end
endtask
endclass
initial
begin
Eth ram;
ram = new();
fork ram.clk_gen;
ram.pkt;
#5000 $finish(); //Change Run time to increase COV
join_any
end
endprogram

Output in VCS

10 display the clock =1 header = 2 frmlength = 1
20 display the clock =0 header = 4 frmlength = 2
30 display the clock =1 header = 6 frmlength = 3
40 display the clock =0 header = 8 frmlength = 4
50 display the clock =1 header = 10 frmlength = 5
60 display the clock =0 header = 12 frmlength = 6
.
.
.
.
4940 display the clock =0 header = 988 frmlength = 494
4950 display the clock =1 header = 990 frmlength = 495
4960 display the clock =0 header = 992 frmlength = 496
4970 display the clock =1 header = 994 frmlength = 497
4980 display the clock =0 header = 996 frmlength = 498
4990 display the clock =1 header = 998 frmlength = 499

(ii) Example (2)

Program Eth_frm;
typedef enum bit {FALSE, TRUE} bool;
typedef enum {TOO_SHORT, SHORT, MEDIUM, LONG, TOO_LONG} eth_length_t;

class ethernet_frame_sized_payload;
rand bool legal_size;
rand eth_length_t ltype;
rand bit [15:0] tag_info;
constraint c2 {tag_info <= 1536;}
rand int unsigned data_size;
constraint c3 {{(legal_size)== (data_size==tag_info);}
{(ltype ==TOO_SHORT) -> (data_size inside {[1:45]});}
{(ltype ==SHORT) -> (data_size inside {[46:800]});}
{(ltype ==MEDIUM) -> (data_size inside {[801:1200]});}
{(ltype ==LONG) -> (data_size inside {[1201:1536]});}
{(ltype ==TOO_LONG) -> (data_size inside {[1536:2000]});}}
event eth_cov;
rand byte data [];
covergroup frame @(eth_cov);
coverpoint data_size {
bins frm_short = {[46:800]};
bins frm_medium = {[801:1200]};
bins frm_toolong = {[1536:2000]};
}
cov_tag: coverpoint tag_info;
cov_legal: coverpoint legal_size;
cross_cov: cross cov_tag,cov_legal; //cross coverage of tag_info and legal size
endgroup

function new();
frame = new();
endfunction;

task cov();
$display(" tag_info %h legal_size %h ltype %h " ,tag_info, legal_size,ltype);
endtask
endclass
initial
begin
ethernet_frame_sized_payload frm;
frm = new();
repeat(5)
begin
frm.randomize();
->frm.eth_cov;
frm.cov();
#100;
end
end
endprogram

Output in VCS

tag_info 0020 legal_size 0 ltype 00000002
tag_info 0499 legal_size 0 ltype 00000000
tag_info 053e legal_size 1 ltype 00000003
tag_info 01ca legal_size 1 ltype 00000001
tag_info 0536 legal_size 0 ltype 00000000




(b) Sonet

(i) Example

module coverage1();
logic [7:0] frame_data;
logic par,control ;
covergroup
parity_data @ (posedge control);
parity : coverpoint par {
bins even = {0};
bins odd = {1};
}
endgroup
// Instance of covergroup parity_data
parity_data par1 = new();
// Task to put data
task
put_data (input [7:0] data);
#10 control = 1;
frame_data = data;
par = ^data;
$display("@%2tns frame_data %x, parity %x", $time,data,par );
#10 control = 0;
frame_data = 0;
par = 0;
endtask
// Testvector generation
initial
begin
control = 0;
repeat (6);
begin
put_data ( $random);
end
#10 $finish;
end
endmodule

Output in VCS

@10ns frame_data 24, parity 0
@30ns frame_data 81, parity 0
@50ns frame_data 09, parity 0
@70ns frame_data 63, parity 0
@90ns frame_data 0d, parity 1
@110ns frame_data 8d, parity 0

(ii) Example

interface sonet;
logic req,gnt;
bit [773:0] payload;
bit [9:0] poh;
logic clk;
endinterface

module
section_tr(sonet data_in, input bit clk);
endmodule

module
signal_tr(sonet data_out, input bit clk);
endmodule

module top;
logic clk=0;
sonet frm_intf();
section_tr se_tr(frm_intf,clk);
signal_tr si_tr(.data_out(frm_intf),.clk(clk));
class Tranction;
covergroup sonet_cov @clk;
coverpoint frm_intf.payload
{
bins payload_high = {[0:100]};
bins payload_med = {[200:1000]};
bins others [] = default;
}
endgroup
function new();
sonet_cov = new();
endfunction
endclass
always
clk = #20 ~clk;
initial
begin
int count =0;
Transaction txr= new();
repeat (2)
begin
#10
frm_intf.payload = count;
count = count+1;
#100 $finish;
end
end
endmodule

Coverage - Defining Coverage Points

Coverage - Defining Coverage Points

A coverage point can be an integral variable or an integral expression. Each coverage point includes a set of bins associated with its sampled values or its value transitions. The bins can be explicitly defined by the user or automatically created by SystemVerilog.

The syntax for specifying coverage points is given below.

covergroup mux;
coverpoint sel@(enable or reset) ;
initial
begin


end endgroup

Specifying bins for transitions:

value1 => value2

It represents the value of coverage point at two successive sample points, that is, value1 followed by value2 at the next sample point. A sequence of transitions is represented as: value1 => value3 => value4 => value5

Defining cross coverage:

A coverage group can specify cross coverage between two or more coverage points or variables. Cross coverage is specified using the cross construct. When a variable V is part of a cross coverage, SystemVerilog implicitly creates a coverage point for the variable, as if it had been created by the statement coverpoint V;.

Thus, a cross involves only coverage points. Expressions cannot be used directly in a cross; a coverage point must be explicitly defined first.

bit [3:0] a, b;
covergroup cov @(posedge clk);
aXb : cross a, b;
endgroup

Specifying coverage options:

Options control the behavior of the covergroup, coverpoint and cross. There are two types of options: those that are specific to an instance of a covergroup, and those that specify an option for the covergroup type as a whole.

Options are as follows ;

weight= number
goal=number
name= string
comment=string

Predefined coverage methods:

The following coverage methods are provided for the covergroup. These methods can be invoked procedurally at any time.

Predefined coverage system tasks and functions:

SystemVerilog provides the following system tasks and functions to help manage coverage data collection.

$set_coverage_db_name ( name ) — Sets the filename of the coverage database into which coverage information is saved at the end of a simulation run.
$load_coverage_db ( name ) — Load from the given filename the cumulative coverage information for all coverage group types.
$get_coverage ( ) — Returns as a real number in the range 0 to 100 the overall coverage of all coverage group

Organization of option and type_option members

The type and type_option members of a covergroup, coverpoint, and cross items are implicitly declared structures with the following composition:

Coverage - Defining Coverage Points

Coverage - Defining Coverage Points

A coverage point can be an integral variable or an integral expression. Each coverage point includes a set of bins associated with its sampled values or its value transitions. The bins can be explicitly defined by the user or automatically created by SystemVerilog.

The syntax for specifying coverage points is given below.

covergroup mux;
coverpoint sel@(enable or reset) ;
initial
begin


end endgroup

Specifying bins for transitions:

value1 => value2

It represents the value of coverage point at two successive sample points, that is, value1 followed by value2 at the next sample point. A sequence of transitions is represented as: value1 => value3 => value4 => value5

Defining cross coverage:

A coverage group can specify cross coverage between two or more coverage points or variables. Cross coverage is specified using the cross construct. When a variable V is part of a cross coverage, SystemVerilog implicitly creates a coverage point for the variable, as if it had been created by the statement coverpoint V;.

Thus, a cross involves only coverage points. Expressions cannot be used directly in a cross; a coverage point must be explicitly defined first.

bit [3:0] a, b;
covergroup cov @(posedge clk);
aXb : cross a, b;
endgroup

Specifying coverage options:

Options control the behavior of the covergroup, coverpoint and cross. There are two types of options: those that are specific to an instance of a covergroup, and those that specify an option for the covergroup type as a whole.

Options are as follows ;

weight= number
goal=number
name= string
comment=string

Predefined coverage methods:

The following coverage methods are provided for the covergroup. These methods can be invoked procedurally at any time.

Predefined coverage system tasks and functions:

SystemVerilog provides the following system tasks and functions to help manage coverage data collection.

$set_coverage_db_name ( name ) — Sets the filename of the coverage database into which coverage information is saved at the end of a simulation run.
$load_coverage_db ( name ) — Load from the given filename the cumulative coverage information for all coverage group types.
$get_coverage ( ) — Returns as a real number in the range 0 to 100 the overall coverage of all coverage group

Organization of option and type_option members

The type and type_option members of a covergroup, coverpoint, and cross items are implicitly declared structures with the following composition:

Coverage - Introduction

Coverage - Introduction

Functional verification comprises a large portion of the resources required to design and validate a complex system. Often, the validation must be comprehensive without redundant effort. To minimize wasted effort, coverage is used as a guide for directing verification resources by identifying tested and untested portions of the design. Coverage is defined as the percentage of verification objectives that have been met. It is used as a metric for evaluating the progress of a verification project in order to reduce the number of simulation cycles spent in verifying a design.

Defining the coverage model: covergroup

The covergroup construct encapsulates the specification of a coverage model. Each covergroup specification can include the following components:

» A clocking event that synchronizes the sampling of coverage points
» A set of coverage points
» Cross coverage between coverage points
» Optional formal arguments
» Coverage options
A covergroup instance can be created via the new() operator.

A covergroup can contain one or more coverage points. A coverage point can be a variable or an expression.

Each coverage point includes a set of bins associated with its sampled values or its value-transitions. The bins can be explicitly defined by the user or automatically created by the tool.

enum { red, green, blue } color;
bit[3:0] pixel;
covergroupg1@(posedgeclk);
coverpoint color;
coverpoint pixel;
AxC: cross color, pixel;
endgroup

Using covergroup in classes:

A coverage group within a class definition, the covergroup provides a simple way to cover a subset of the class properties. In class xyz, defined below, members a and b are covered using an embedded

covergroup:
class abc; bit [3:0] a;
int b;
bit c;
covergroup cov1 @c ;
coverpoint a ;
coverpoint b ;
endgroup
function new(); cov1 = new;
endfunction
endclass

Interfaces - Examples

Interfaces - Examples

Example for Interfaces.

(a) Ethernet

(i) Example

interface interface_example
#( parameter BW = 8)( input clk);
logic SFD;
endinterface :interface_example

module Eth(interface_example eth_IF); // declaring the interface: IF = Interface
always @(posedge eth_IF.clk)
if(eth_IF.SFD)
$display("*****SFD is asserted*****");
endmodule

module Eth_testbench(interface_example TB_IF);//TB = Testbench
initial
begin
TB_IF.SFD = 0;
repeat(6);
#20 TB_IF.SFD = ~TB_IF.SFD;
$finish;
end
endmodule

module top_module();
bit clk;
initial
forever #5 clk = ~clk;
interface_example Eth_IF(clk); // interface instantiation
Eth dut(Eth_IF); // use interface for connecting Dut and Testbench
Eth_testbench tb(Eth_IF);
endmodule

Output in VCS

*****SFD is asserted*****
*****SFD is asserted*****
*****SFD is asserted*****
*****SFD is asserted*****
*****SFD is asserted*****
*****SFD is asserted*****

(ii) Example Virtual Interface

interface Mac_intf(input clk);
bit Tx_Reset;
bit [7:0] Tx_data;
bit [15:0] Tx_frm;
bit Tx_pause_request;
int length;
bit [15:0] length_type;
endinterface

module top ;
reg clk = 0 ;
always #5clk = ~clk ;
Mac_intf mac(clk) ;
test TB(mac) ;
endmodule

program test(Mac_intf mac_test);
class Tx_pause_frm;
virtual Mac_intf virt_mac;
function new(virtual Mac_intf mac_test);
this.virt_mac = mac_test;
endfunction
task Tx_pause ;
if (virt_mac.Tx_pause_request == 1)
$display ( $time, " Requesting Transmit pause ") ;
else
$display ( $time, " Transmit frame continue ") ;
endtask
endclass
Tx_pause_frm dut;
initial
begin
dut = new(mac_test) ;
repeat(10)
begin
@(mac_test.clk) ;
dut.Tx_pause() ;
#10
mac_test.Tx_pause_request = ~mac_test.Tx_pause_request;
end
end
endprogram

Output in VCS

5 Transmit frame continue
20 Requesting Transmit pause
35 Transmit frame continue
50 Requesting Transmit pause
65 Transmit frame continue
80 Requesting Transmit pause
95 Transmit frame continue
110 Requesting Transmit pause
125 Transmit frame continue
140 Requesting Transmit pause



(b) Sonet

(i) Example

interface b1mon_if( input bit clk);
logic reset,indicator;
logic[7:0] bip_prev, bip_calc;
modport DUT ( input clk, indicator, bip_prev, bip_calc);
modport TEST ( input clk, output indicator, bip_prev, bip_calc);
endinterface //DUT

module b1mon (b1mon_if.DUT if1);
always @ (posedge if1.clk)
begin
if (if1.indicator)
begin
if (if1.bip_prev == if1.bip_calc)
begin
#1 $display("No Parity Error");
end
else
begin
#1 $display("Parity Error");
end
end
end
endmodule //Test Bench

module b1mon_tb(b1mon_if.TEST if1);
initial
begin
if1.indicator = 1'b0;
$display("***************Parity Checking*******************");
$monitor("time:%0g if1.indicator:%0b if1.bip_prev:%0b if1.bip_calc:%0b clk:%0d\n",$time,if1.indicator,if1.bip_prev,if1.bip_calc,if1.clk);
end
initial
begin
@(posedge if1.clk)
begin
#10 if1.indicator = 1'b1; if1.bip_prev = 8'b01010101 ; if1.bip_calc = 8'b00110011;
#20 if1.indicator = 1'b1; if1.bip_prev = 8'b11001100 ; if1.bip_calc = 8'b11001100;
#10 if1.indicator = 1'b0;
#10 $finish;
end
end
endmodule //Top Module

module b1mon_top;
bit clk;
always #5 clk = ~clk;
b1mon_if if1(clk);
b1mon dut1 (if1);
b1mon_tb tb1 (if1);
endmodule : b1mon_top

Output in VCS

***************Parity Checking*******************
time:0 if1.indicator:0 if1.bip_prev:xxxxxxxx if1.bip_calc:xxxxxxxx clk:0

time:5 if1.indicator:0 if1.bip_prev:xxxxxxxx if1.bip_calc:xxxxxxxx clk:1

time:10 if1.indicator:0 if1.bip_prev:xxxxxxxx if1.bip_calc:xxxxxxxx clk:0

time:15 if1.indicator:1 if1.bip_prev:1010101 if1.bip_calc:110011 clk:1

Parity Error
time:20 if1.indicator:1 if1.bip_prev:1010101 if1.bip_calc:110011 clk:0

time:25 if1.indicator:1 if1.bip_prev:1010101 if1.bip_calc:110011 clk:1

Parity Error
time:30 if1.indicator:1 if1.bip_prev:1010101 if1.bip_calc:110011 clk:0

time:35 if1.indicator:1 if1.bip_prev:11001100 if1.bip_calc:11001100 clk:1

No Parity Error
time:40 if1.indicator:1 if1.bip_prev:11001100 if1.bip_calc:11001100 clk:0

time:45 if1.indicator:0 if1.bip_prev:11001100 if1.bip_calc:11001100 clk:1

time:50 if1.indicator:0 if1.bip_prev:11001100 if1.bip_calc:11001100 clk:0

(ii) Example

interface LOH_if (
input logic clk,
input logic reset,
input logic [7:0] data_in,
input logic H1_indic,
input logic B2_indic,
output logic [7:0] current_data,
output logic [7:0] calculated_data,
output logic [7:0] captured_data);
endinterface //DUT with INTERFACE

module LOH_frame (LOH_if LOH_frame);
always @(posedge LOH_frame.clk or negedge LOH_frame.reset)
begin
if (!LOH_frame.reset)
begin
LOH_frame.current_data[7:0] <= 8'h00;
$display("current data reset in the DUT :%h",LOH_frame.current_data);
LOH_frame.calculated_data[7:0] <= 8'h00;
end
else if (LOH_frame.H1_indic)
begin
LOH_frame.current_data[7:0] <= LOH_frame.data_in[7:0];
$display ("current data in the DUT: %h", LOH_frame.current_data);
$display("data_in H1 the DUT: %h",LOH_frame.data_in);
LOH_frame.calculated_data[7:0] <= LOH_frame.current_data[7:0];
end
else
begin
LOH_frame.current_data[7:0] <=LOH_frame.current_data[7:0] ^ LOH_frame.data_in[7:0];
$display("current data after xoring:%h",LOH_frame.current_data);
$display("data_in in the DUT:%h",LOH_frame.data_in);
end
end
always @(posedge LOH_frame.clk or negedge LOH_frame.reset)
begin
if ( !LOH_frame.reset)
begin
LOH_frame.captured_data[7:0]<= 8'h00;
end
else if ( LOH_frame.B2_indic)
begin
LOH_frame.captured_data[7:0] <= LOH_frame.data_in[7:0];
$display("captured_data in B2: %h",LOH_frame.captured_data);
end
else
LOH_frame.captured_data[7:0] <= LOH_frame.captured_data;
end
endmodule
//TESTBENCH

module tb();
logic clk;
logic reset;
logic [7:0] data_in;
logic H1_indic;
logic B2_indic;
logic [7:0] calculated_data;
logic [7:0] current_data;
wire captured_data;

//instantiate interface with DUT
LOH_if frame(
.clk (clk),
.reset (reset),
.data_in (data_in),
.H1_indic (H1_indic),
.B2_indic (B2_indic)
);
LOH_frame dut(.LOH_frame (frame));
initial
begin
reset = 1'b0;
clk = 1'b1;
end
always
#5 clk <= ~clk;
initial
begin
#2 reset<= 1'b1;
#2 H1_indic <= 1'b1;
#5 H1_indic <= 1'b0;
#5 H1_indic <= 1'b1;
end
initial
begin
#2 B2_indic <= 1'b1;
#2 B2_indic <=1'b1;
#5 B2_indic <=1'b0;
#5 B2_indic <= 1'b1;
end
initial
begin
#2 data_in[7:0] <= 'h34;
#2 data_in[7:0] <= 'h53;
#2 data_in[7:0] <= 'h50;
end
initial
begin
$monitor ($time,"clk=%b,reset=%b,data_in=%h,H1_indic=%b,B2_indic=%b \n",clk,reset,data_in,H1_indic,B2_indic);
#50 $finish;
$vcdpluson;
end
endmodule

Output in VCS

current data reset in the DUT :xx
0clk=1,reset=0,data_in=xx,H1_indic=x,B2_indic=x

2clk=1,reset=1,data_in=34,H1_indic=x,B2_indic=1

4clk=1,reset=1,data_in=53,H1_indic=1,B2_indic=1

5clk=0,reset=1,data_in=53,H1_indic=1,B2_indic=1

6clk=0,reset=1,data_in=50,H1_indic=1,B2_indic=1

9clk=0,reset=1,data_in=50,H1_indic=0,B2_indic=0

current data after xoring:00
data_in in the DUT:50
10clk=1,reset=1,data_in=50,H1_indic=0,B2_indic=0

14clk=1,reset=1,data_in=50,H1_indic=1,B2_indic=1

15clk=0,reset=1,data_in=50,H1_indic=1,B2_indic=1

current data in the DUT: 50
data_in H1 the DUT: 50
captured_data in B2: 00
20clk=1,reset=1,data_in=50,H1_indic=1,B2_indic=1

25clk=0,reset=1,data_in=50,H1_indic=1,B2_indic=1

current data in the DUT: 50
data_in H1 the DUT: 50
captured_data in B2: 50
30clk=1,reset=1,data_in=50,H1_indic=1,B2_indic=1

35clk=0,reset=1,data_in=50,H1_indic=1,B2_indic=1

current data in the DUT: 50
data_in H1 the DUT: 50
captured_data in B2: 50
40clk=1,reset=1,data_in=50,H1_indic=1,B2_indic=1

45clk=0,reset=1,data_in=50,H1_indic=1,B2_indic=1

Interfaces - Virtual Interfaces

Interfaces - Virtual Interfaces

Virtual interfaces provide a mechanism for separating abstract models and test programs from the actual signals that make up the design. A virtual interface allows the same subprogram to operate on different portions of a design, and to dynamically control the set of signals associated with the subprogram. Instead of referring to the actual set of signals directly, users are able to manipulate a set of virtual signals. Changes to the underlying design do not require the code using virtual interfaces to be re-written. By abstracting the connectivity and functionality of a set of blocks, virtual interfaces promote code-reuse.

interface SBus;
logic req, grant;
logic [7:0] addr, data;
endinterface

class SBusTransctor;
virtual SBus bus;
function new( virtual Bus s );
bus = s;
endfunction
task request();
bus.req <= 1’b1;
endtask
task wait_for_bus();
@(posedge bus.grant);
endtask
endclass
endinterface

Parameterized Interfaces

Interface definitions can take advantage of parameters and parameter redefinition, in the same manner as module definitions.

Access to Interface Objects

Access to all objects declared in an interface is always available by hierarchical reference, regardless of whether or not the interface is connected through a port. When an interface is connected with a modport in either the module header or port connection, access by port reference is limited to only those objects listed in the modport, for only those types of objects legal to be listed in modports (nets, variables, tasks, and functions) All objects are still visible by hierarchical reference.

Interfaces - Tasks & Functions

Interfaces - Tasks & Functions

Tasks and functions can be defined within an interface, or they can be defined within one or more of the modules connected. This allows a more abstract level of modeling. For example “read” and “write” can be defined as tasks, without reference to any wires, and the master module can merely call these tasks. In a modport these tasks are declared as import tasks.

An example of using tasks in an interface

interface simple_bus (input bit clk); // Define the interface
logic req, gnt;
logic [7:0] addr, data;
logic [1:0] mode;
logic start, rdy;
task masterRead(input logic [7:0] raddr); // masterRead method

// ...
endtask: masterRead
task slaveRead; // slaveRead method
// ...
endtask: slaveRead
endinterface: simple_bus

Interfaces - Ports

Interfaces - Ports

One limitation of simple interfaces is that the nets and variables declared within the interface are only used to connect to a port with the same nets and variables. To share an external net or variable, one that makes a connection from outside of the interface as well as forming a common connection to all module ports that instantiate the interface, an interface port declaration is required. The difference between nets or variables in the interface port list and other nets or variables within the interface is that only those in the port list can be connected externally by name or position when the interface is instantiated.

interface port(input x, output y, inout z);
wire p;
endinterface

Modports:

To restrict interface access within a module, there are modport lists with directions declared within the interface.

The keyword modport indicates that the directions are declared as if inside the module.

interface if;
reg p, q, r, s;
modport i1 (input p, q, output r, s);
modport i2 (output p, q,input r, s);
endinterface :if

Interfaces and specify blocks:

The specify block is used to describe various paths across a module and perform timing checks to ensure that events occurring at the module inputs satisfy the timing constraints of the device described by the module. The module paths are from module input ports to output ports and the timing checks are relative to the module inputs. The specify block refers to these ports as terminal descriptor. Module inout ports can function as either an input or output terminal. When one of the port instances is an interface, each signal in the interface becomes an available terminal, with the default direction as defined for an interface, or as restricted by a modport.

A ref port cannot be used as a terminal in a specify block. The following shows an example of using interfaces together with a specify block:

interface itf;
logic c,q,d;
modport flop (input c,d, output q);
endinterface
module dtype (itf.flop ch);
always_ff @(posedge ch.c) ch.q <= ch.d;
specify
( posedge ch.c => (ch.q+:ch.d)) = (5,6);
$setup( ch.d, posedge ch.c, 1 );
endspecify
endmodule

Interfaces - Using Bundles

Interfaces - Using Bundles

Named Bundles

The simplest form of a SystemVerilog interface is a bundled collection of variables or nets. When an interface is referenced as a port, the variables and nets in it are assumed to have ref and inout access, respectively.

The following interface example shows the basic syntax for defining, instantiating and connecting an interface. Usage of the SystemVerilog interface capability can significantly reduce the amount of code required to model port connections.

interface simple_bus; // Define the interface
logic req, gnt;
logic [7:0] addr, data;
logic [1:0] mode;
logic start, rdy;
endinterface: simple_bus
module memMod(simple_bus a, // Access the simple_bus interface
input bit clk);
logic avail;
// When memMod is instantiated in module top, a.req is the req
// signal in the sb_intf instance of the ’simple_bus’ interface
always @(posedge clk) a.gnt <= a.req & avail;
endmodule
module cpuMod(simple_bus b, input bit clk);
...
endmodule
module top;
logic clk = 0;
simple_bus sb_intf(); // Instantiate the interface
memMod mem(sb_intf, clk); // Connect the interface to the module instance
cpuMod cpu(.b(sb_intf), .clk(clk)); // Either by position or by name
endmodule

Generic Modules

A module header can be created with an unspecified interface reference as a place-holder for an interface to be selected when the module itself is instantiated. The unspecified interface is referred to as a "generic" interface reference.

The following interface example shows how to specify a generic interface reference in a module definition.

module memMod (interface a, input bit clk);
...
endmodule
module cpuMod(interface b, input bit clk);
...
endmodule

interface simple_bus; // Define the interface
logic req, gnt;
logic [7:0] addr, data;
logic [1:0] mode;
logic start, rdy;
endinterface: simple_bus

module top;
logic clk = 0;
simple_bus sb_intf(); // Instantiate the interface
memMod mem (.a(sb_intf), .clk(clk));
cpuMod cpu (.b(sb_intf), .clk(clk));
endmodule

Interfaces - Introduction

Interfaces - Introduction

The communication between blocks of a digital system is a critical area that can affect everything from ease of RTL coding, to hardware-software partitioning to performance analysis to bus implementation choices and protocol checking. The interface construct in SystemVerilog was specifically created to encapsulate the communication between blocks, allowing a smooth migration from abstract system-level design through successive refinement down to lower-level register-transfer and structural views of the design. By encapsulating the communication between blocks, the interface construct also facilitates design re-use. The inclusion of interface capabilities is one of the major advantages of System Verilog.

At its lowest level, an interface is a named bundle of nets or variables. The interface is instantiated in a design and can be accessed through a port as a single item, and the component nets or variables referenced where needed. A significant proportion of a Verilog design often consists of port lists and port connection lists, which are just repetitions of names. The ability to replace a group of names by a single name can significantly reduce the size of a description and improve its maintainability.

Additional power of the interface comes from its ability to encapsulate functionality as well as connectivity, making an interface, at its highest level, more like a class template. An interface can have parameters, constants, variables, functions and tasks.

A simple interface declaration is as follows.

interface ALU;
...
interface_items
...
endinterface [ : ALU ]

Example without using interfaces:

This example shows a simple bus implemented without interfaces. Note that the logic type can replace wire and reg if no resolution of multiple drivers is needed.

module memMod( input bit req, bit clk, bit start, logic [1:0] mode, logic [7:0] addr, inout wire [7:0] data, output bit gnt, bit rdy );
logic avail;
...
endmodule
module cpuMod(input bit clk, bit gnt, bit rdy, inout wire [7:0] data, output bit req, bit start, logic [7:0] addr, logic [1:0] mode );
...
endmodule
module top;
logic req, gnt, start, rdy; // req is logic not bit here
logic clk = 0;
logic [1:0] mode;
logic [7:0] addr;
wire [7:0] data;
memMod mem(req, clk, start, mode, addr, data, gnt, rdy);
cpuMod cpu(clk, gnt, rdy, data, req, start, addr, mode);
endmodule

Hierarchy - Examples

Hierarchy - Examples

Example for Hierarchy.

(a) Ethernet

(i) Example Extern module

extern module carrier_sense_infullduplex(input carrier_sense,clk);//the module carrier_sense_infullduplex is made visible here

module extern_module;
reg carrier_sense;
reg clk=0;
always
begin
#5 clk=~clk;
end

carrier_sense_infullduplex c1(carrier_sense,clk);
initial
begin
$monitor("time:%0g carrier_sense:%0d clk:%0d\n",$time,carrier_sense,clk);
@(posedge clk)
begin
#5 carrier_sense=0;
#10 carrier_sense=1;
#15 carrier_sense=1;
#20 carrier_sense=0;
#20 $finish;
end
end
endmodule

//should be written in another file
module carrier_sense_infullduplex(input carrier_sense,clk);
always @(posedge clk)
begin
if(carrier_sense==1)
begin
$display("no collision occurs in full duplex,continue to transmit frames\n");
end
else
begin
$display("transmission is continued\n");
end
end
endmodule

Output in Questasim

# time:0 carrier_sense:x clk:0
#
# transmission is continued
#
# time:5 carrier_sense:x clk:1
#
# time:10 carrier_sense:0 clk:0
#
# transmission is continued
#
# time:15 carrier_sense:0 clk:1
#
# time:20 carrier_sense:1 clk:0
#
# no collision occurs in full duplex,continue to transmit frames
#
# time:25 carrier_sense:1 clk:1
#
# time:30 carrier_sense:1 clk:0
#
# no collision occurs in full duplex,continue to transmit frames
#
# time:35 carrier_sense:1 clk:1
#
# time:40 carrier_sense:1 clk:0
#
# no collision occurs in full duplex,continue to transmit frames
#
# time:45 carrier_sense:1 clk:1
#
# time:50 carrier_sense:1 clk:0
#
# transmission is continued
#
# time:55 carrier_sense:0 clk:1
#
# time:60 carrier_sense:0 clk:0
#
# transmission is continued
#
# time:65 carrier_sense:0 clk:1
#
# time:70 carrier_sense:0 clk:0
#

(ii) Example using packages

//File1
package pkgfile1;
typedef enum {FALSE, TRUE} bool;
task begin2init (string msg);
reg frameWaiting,deferring,newCollision,transmitting ,receiving ,halfDuplex,bursting;
frameWaiting=FALSE;
deferring=FALSE;
newCollision=FALSE;
transmitting=FALSE;
receiving=FALSE;
halfDuplex=TRUE;
bursting=FALSE;
$display ("@%0dns : %s frameWaiting=%0d,deferring=%0d,newCollision=%0d,transmitting=%0d ,receiving=%0d ,halfDuplex=%0d,bursting=%0d",$time, msg, frameWaiting, deferring, newCollision, transmitting, receiving, halfDuplex, bursting);
endtask
endpackage

//File2
package pkgfile2;
task condn2 (string msg);
$display ("@%0dns %s : \n start execution of all process ",$time,msg);
$finish;
endtask
endpackage

//File3
`include "pkgfile1.sv" //include the files whichever needed
`include "pkgfile2.sv"
import pkgfile1::*; //imports all the identifiers within the package
import pkgfile2::condn2; // imports only the identifier condn2 within the package
module initialize_mac();
bool carrierSense = pkgfile1::TRUE;
bool receiveDataValid = pkgfile1::FALSE;
initial
begin
if(carrierSense || receiveDataValid)
begin
pkgfile2::condn2("when condition is true\n"); //calls the task begin2init in package file1.sv
end
else
begin
pkgfile1::begin2init("when condition is false\n"); //calls the task condn2 in package file1.sv
end
end
endmodule

Output in VCS

@0ns when condition is true
:
start execution of all process
$finish at simulation time
//for else condition change carriersense to FALSE in initialize_mac.sv
@0ns : when condition is false
frameWaiting=0,deferring=0,newCollision=0,transmitting=0 ,receiving=0 ,halfDuplex=1,bursting=0

(iii) Example Hierarchy

module module1();
task frame();
byte preamble[1:7]='{10,10,10,10,10,10,10};
byte sfd=8'd171; //'{10101011};
byte dest_addr[1:6]='{5,6,3,2,7,8};
byte src_addr[1:6]='{2,8,4,1,7,5};
byte len_type[1:2]='{default:0};
byte fcs[1:4]='{4,3,6,7};
$display("4th byte of preamble=%0b\n sfd=%0b\n 1st byte of dest_addr=%0d\n 2nd byte of src_addr=%0d\n 2nd byte of len_type=%0d\n 3rd byteof fcs=%0d\n ",preamble[4], sfd, dest_addr[1], src_addr[2], len_type[2], fcs[3]);
endtask
initial
begin
$root.top.U.U.frame();//using frame within instance U within instance U
end
endmodule

module module2();
task vlanframe();
typedef struct {bit [15:0]tag_type;bit [15:0]control_info;}vlan_byte;
vlan_byte v1='{'d33024,11110000};
vlan_byte v2 [0:1]='{'{'d33024,00011100},'{'h8100,00111111}};
$display("tag_type=%0h control_info=%0h",v1.tag_type,v1.control_info);
$display("tag_type=%0h control_info=%0h",v2[0].tag_type,v2[1].control_info);
$display("%m : Inside Module2");
endtask
module1 U ();
initial
begin
$root.top.U2.frame();//using frame within top instance U2
$root.top.U.vlanframe();//using frame within top instance U
end
endmodule

module topmodule();
module2 U(); //instantiates the local module2 declared above
module1 U2(); //instantiates the local module1 declared above
task print();
$display("%m : Inside Top Module ");
endtask
endmodule

Output in Questasim

# 4th byte of preamble=1010
# sfd=10101011
# 1st byte of dest_addr=5
# 2nd byte of src_addr=8
# 2nd byte of len_type=0
# 3rd byteof fcs=6
#
# 4th byte of preamble=1010
# sfd=10101011
# 1st byte of dest_addr=5
# 2nd byte of src_addr=8
# 2nd byte of len_type=0
# 3rd byteof fcs=6
#
# tag_type=8100 control_info=8670
# tag_type=8100 control_info=b207
# top.U.vlanframe : Inside Module2
# 4th byte of preamble=1010
# sfd=10101011
# 1st byte of dest_addr=5
# 2nd byte of src_addr=8
# 2nd byte of len_type=0
# 3rd byteof fcs=6




(b) Sonet

(i) Example Hierarchy

typedef struct {
logic [7:0]SPE_byte ;
logic[7:0] data;
} global_frame;
global_frame root_frame;

task global_task(input global_frame H1_ind);
$display("%g SPE_byte:%d,data:%b",$time,H1_ind.SPE_byte,H1_ind.data);
endtask

module octet;
global_frame J1_byte;
terminal N();
initial
begin
#10 J1_byte.data =1; J1_byte.SPE_byte =10;
global_task(J1_byte);
end
endmodule

module terminal;
logic[7:0]H3 ;
global_frame B2_byte;
initial
begin
#20 B2_byte.data =2;
B2_byte.SPE_byte =11;
global_task(B2_byte);
#30;
$root.root_frame.data =3;
$root.root_frame.SPE_byte =12;
global_task($root.root_frame);
end
endmodule

Output in VCS

10 SPE_byte: 10,data:00000001
20 SPE_byte: 11,data:00000010
50 SPE_byte: 12,data:00000011

(ii) Example Hierarchy

//FILE 1.
extern module payload(input clk,reset,logic frame_in,logic H1_indicator,logic [7:0]J0_byte,output logic [7:0] data_out);

module extern_exp();
logic clk =0;
always #1 clk = ~clk;
logic reset;
logic frame_in;
logic H1_indicator;
logic [7:0] J0_byte;
reg [7:0] data_out;
payload P(clk,reset,H1_indicator,J0_byte,data_out);
initial begin
$display("********************************************************************�);
$monitor ("%g H1_indicator=%b,JO_byte=%b,data_out =%b",$time,H1_indicator,J0_byte,data_out);
# 1 reset <= 0;
# 2 reset <= 1;
# 2 H1_indicator <= 1'b0;
# 2 frame_in <= 1'b0;
# 2 J0_byte <= 'b11110000;
# 2 H1_indicator <= 1'b1;
# 2frame_in <= 1'b1;
# 2 J0_byte <= 'b10101010;
# 2 H1_indicator <= 1'b0;
# 2 frame_in <= 1'b0;
# 2 J0_byte <= 'b11001100;
# 20 $finish;
end
endmodule

//FILE 2.
module payload ( input clk,reset,H1_indicator,[7:0 ]J0_byte, output logic [7:0]data_out);
always @ (posedge clk or negedge reset)
if (!reset)
begin
data_out <= 'b00000000;
end
else if (H1_indicator)
begin
data_out <= J0_byte;
end
else
data_out <= data_out;
endmodule

Output in Questasim

# **********************************************************************
# 0 H1_indicator=x,JO_byte=xxxxxxxx,data_out =xxxxxxxx
# 1 H1_indicator=x,JO_byte=xxxxxxxx,data_out =00000000
# 5 H1_indicator=0,JO_byte=xxxxxxxx,data_out =00000000
# 9 H1_indicator=0,JO_byte=11110000,data_out =00000000
# 11 H1_indicator=1,JO_byte=11110000,data_out =00000000
# 13 H1_indicator=1,JO_byte=11110000,data_out =11110000
# 15 H1_indicator=1,JO_byte=10101010,data_out =11110000
# 17 H1_indicator=0,JO_byte=10101010,data_out =10101010
# 21 H1_indicator=0,JO_byte=11001100,data_out =10101010
# ** Note: $finish : extern_b2gen.sv(33)
# Time: 41 ns Iteration: 0 Instance: /extern_exp
============================================

Hierarchy- Extern Modules Hierarchy- Extern Modules

Hierarchy- Extern Modules

To support separate compilation, extern declarations of a module can be used to declare the ports on a module without defining the module itself. An extern module declaration consists of the keyword extern followed by the module name and the list of ports for the module.

extern module mux (input a,b,sel output y);
module mux_design();
endmodule
module mux tb();
endmodule

Port Declarations

With SystemVerilog, a port can be a declaration of a net, an interface, an event, or a variable of any type, including an array, a structure or a union.

typedef struct {
bit isfloat;
union { int i; shortreal f; } n;
} tagged_st; // named structure
module mh1 (input int in1, input shortreal in2, output tagged_st out);
...
endmodule
ex:
module mh4(x, y);
wire x;
tri0 y;
...
endmodule

Time unit and precision

SystemVerilog has a time unit and precision declaration which has the equivalent functionality of the ‘timescale compiler directives in Verilog-2001. Use of these declarations removes the file order dependencies problems with compiler directives. The time unit and precision can be declared by the timeunit and timeprecision keywords, respectively, and set to a time literal which must be a power of 10 units.

For example:

timeunit 100ps;
timeprecision 10fs;

Module instances

A module can be used (instantiated) in two ways, hierarchical or top level. Hierarchical instantiation allows more than one instance of the same type. The module name can be a module previously declared or one declared later. Actual parameters can be named or ordered. Port connections can be named, ordered or implicitly connected. They can be nets, variables, or other kinds of interfaces, events, or expressions. See below for the connection rules.

» Instantiation using positional port connections
» Instantiation using named port connections
» Instantiation using implicit .name port connections
» Instantiation using implicit .* port connections
Port connection rules

If a port declaration has a wire type (which is the default), or any other net type, then its direction controls

how it can be connected as follows:

An input can be connected to any expression of a compatible data type. If left unconnected, it shall have the value 'z.
An output can be connected to a net type (or a concatenation of net types) or a compatible variable type (or a concatenation of variable types).
An inout can be connected to a net type (or a concatenation of net types) or left unconnected, but not to a variable type.
Port connection rules for interfaces:

A port declaration can be a generic interface or named interface type. An interface port instance must always be connected to an interface instance or a higher-level interface port. An interface port cannot be left unconnected.

Compatible port types:

The same rules for assignment compatibility are used for compatible port types for ports declared as an input or an output variable, or for output ports connected to variables. SystemVerilog does not change any of the other port connection compatibility rules

Unpacked array ports and arrays of instances:

For an unpacked array port, the port and the array connected to the port must have the same number of unpacked dimensions, and each dimension of the port must have the same size as the corresponding dimension of the array being connected.

Hierarchy- Nested Modules

Hierarchy- Nested Modules

A module can be declared within another module. The outer name space is visible to the inner module, so that any name declared there can be used, unless hidden by a local name, provided the module is declared and instantiated in the same scope.

module first_counter (clock ,reset ,enable ,counter_out );
module ports()
input clock ;
input reset ;
input enable ;
output [3:0] counter_out ;
wire clock ;
wire reset ;
wire enable ;
reg [3:0] counter_out ;
endmodule

always @ (posedge clock)
begin : COUNTER // Block Name
if (reset == 1'b1) begin
counter_out <= #1 4'b0000;
end
else if (enable == 1'b1) begin
counter_out <= #1 counter_out + 1;
end
end
endmodule

module first_counter_tb();
reg clock, reset, enable;
wire [3:0] counter_out;

module functionality ()
initial begin
$display ("time\t clk reset enable counter");
$monitor ("%g\t %b %b %b %b", $time, clock, reset, enable, counter_out);
clock = 1; // initial value of clock
reset = 1; // initial value of reset
enable = 1; // initial value of enable
#5 reset = 1; // Assert the reset
#10 reset = 0; // De-assert the reset
#10 enable = 1; // Assert enable
#100 enable = 0; // De-assert enable
endmodule
#5 $finish; // Terminate simulation
end

always begin
#5 clock = ~clock; // Toggle clock every 5 ticks
end

first_counter U_counter (
clock,
reset,
enable,
counter_out
);
endmodule

Hierarchy

Hierarchy

Verilog HDL has a simple organization. All data, functions and tasks are in modules except for system tasks and functions, which are global, and can be defined in the PLI. A Verilog module can contain instances of other modules. Any uninstantiated module is at the top level. This does not apply to libraries, which therefore have a different status and a different procedure for analyzing them.

A hierarchical name can be used to specify any named object from anywhere in the instance hierarchy. The module hierarchy is often arbitrary and a lot of effort is spent in maintaining port lists.

SystemVerilog adds many enhancements for representing design hierarchy:

» Packages containing declarations such as data, types, classes, tasks and functions
» Separate compilation support
» A compilation-unit scope visible only within a compilation unit
» Nested module declarations, to aid in representing self-contained models and libraries
» Relaxed rules on port declarations
» Simplified named port connections, using .name
» Implicit port connections, using .*
» Time unit and time precision specifications bound to modules
» A concept of interfaces to bundle connections between modules.
Packages:

SystemVerilog packages provide an additional mechanism for sharing

» parameters
» data type
» task
» function
» sequence
» property declarations amongst multiple SystemVerilog modules
interfaces and program Packages are explicitly named scopes appearing at the outermost level of the source text. Types, variables, tasks, functions, sequences, and properties may be declared within a package. Such declarations may be referenced within modules, macromodules, interfaces, programs, and other packages by either import or fully resolved name.

Above can be shared across SystemVerilog modules, macromodule interfaces and programs. Few rules that should be followed with packages are.

» Packages can not contain any assign statement.
» Variable declaration assignments within the package shall occur before any initial, always, always_comb, always_latch, or always_ff blocks
» Items within packages cannot have hierarchical references.
» Assign statment on any net type is not allowed.
Accessing data, functions or types in packages there are two ways.

» By class scope resolution operator ::
» By import statement : The import statement provides direct visibility of identifiers within packages.
package ComplexPkg;
typedef struct {
float i, r;
} Complex;
function Complex add(Complex a, b);
add.r = a.r + b.r;
add.i = a.i + b.i;
endfunction
function Complex mul(Complex a, b);
mul.r = (a.r * b.r) - (a.i * b.i);
mul.i = (a.r * b.i) + (a.i * b.r);
endfunction
endpackage : ComplexPkg

Referencing data in packages

Packages must exist in order for the items they define to be recognized by the scopes in which they are imported. One way to use declarations made in a package is to reference them using the scope resolution operator “::”.

ComplexPkg::Complex cout = ComplexPkg::mul(a, b);

An alternate method for utilizing package declarations is via the import statement.

Compilation unit support

SystemVerilog supports separate compilation using compiled units. The following terms and definitions are provided:

compilation unit: a collection of one or more SystemVerilog source files compiled together
compilation-unit scope: a scope that is local to the compilation unit. It contains all declarations that lie outside of any other scope
$unit: the name used to explicitly access the identifiers in the compilation-unit scope
Top-level instance:

The name $root is added to unambiguously refer to a top level instance, or to an instance path starting from the root of the instantiation tree. $root is the root of the instantiation tree.

For example:
$root.A.B // item B within top instance A
$root.A.B.C // item C within instance B within instance A

Assertions - Examples

Assertions - Examples

Example for Assertions.
(a) Ethernet

(i) Example Immediate Assertion

module assert_immediate;
logic Rx_data_valid;
logic clk,reset;
always_ff @(posedge clk or posedge reset)
begin
if (Rx_data_valid)
begin
CHECK_RESET_WHEN_RX_DATA_VALID: assert (reset && Rx_data_valid) //checking assert condition
begin
$display(" Collect the bits from frame");
end
else
begin
$error("assert failed at time %0t",$time);
$display("the frame is truncated");
end
end
end

initial
begin
$monitor("Rx_data_valid = %0d clk = %d reset = %d",Rx_data_valid,clk,reset);
reset = 0;
Rx_data_valid = 0;
#6 Rx_data_valid = 1;
#8 Rx_data_valid = 0;
#7 reset = 1;
end
initial
begin
$display("Rx_data_valid = %0d clk = %d reset = %d",Rx_data_valid,clk,reset);
#50 $finish;
end
initial
begin
clk = 0;
forever
begin
#10;
clk = ~clk;
end
end
endmodule

Output in VCS

Rx_data_valid = 0 clk = x reset = 0
Rx_data_valid = 0 clk = 0 reset = 0
Rx_data_valid = 1 clk = 0 reset = 0
"assert_imm.sv", 9: assert_immeadiate.CHECK_RESET_WHEN_RX_DATA_VALID: started at 10s failed at 10s
Offending '(reset && Rx_data_valid)'
Error: "assert_imm.sv", 9: assert_immeadiate.CHECK_RESET_WHEN_RX_DATA_VALID: at time 10
assert failed at time 10
the frame is truncated
Rx_data_valid = 1 clk = 1 reset = 0
Rx_data_valid = 0 clk = 1 reset = 0
Rx_data_valid = 0 clk = 0 reset = 0
Rx_data_valid = 0 clk = 0 reset = 1
Rx_data_valid = 0 clk = 1 reset = 1
Rx_data_valid = 0 clk = 0 reset = 1
(ii) Example Sequential Assertion

module asser_seq;
int da,sa,en; // destination address , source address
int frame;
int reset;
logic clk;
always @(posedge clk or negedge reset)
begin
if(en)
begin
if(frame>64) || (frame<511))
begin
$display("Normal frame is transmitted without extension",frame);
end
else
$display("Normal frame transmitted with extention",frame);
end
end

property frame_transmit; //Transmit the frame using property
@(posedge clk)
en |-> frame;
endproperty

frame_transmit_assert: assert property (frame_transmit) //assert condition
else
$display("@ %0d assertion filed",$time);
initial
begin
en = 0;
reset = 0;
#15 en = 1;
#10 reset = 1;
#5 reset = 1;
#3 en = 1;
end
initial
begin
clk = 0;
forever
begin
#5 clk++;
end
end
initial
begin
$display(" %d %d %d %d ", en,reset,frame,clk,$time);
#100 $finish;
end
endmodule

Output in VCS

0 0 0 0 0
Normal frame is transmitted without extension 0
Normal frame is transmitted without extension 0
"assert_seq.sv", 24: asser_seq.frame_transmit_assert: started at 25s failed at 25s
Offending 'frame'
@ 25 assertion filed
Normal frame is transmitted without extension 0
"assert_seq.sv", 24: asser_seq.frame_transmit_assert: started at 35s failed at 35s
Offending 'frame'
@ 35 assertion filed
Normal frame is transmitted without extension 0
"assert_seq.sv", 24: asser_seq.frame_transmit_assert: started at 45s failed at 45s
Offending 'frame'
@ 45 assertion filed
Normal frame is transmitted without extension 0
"assert_seq.sv", 24: asser_seq.frame_transmit_assert: started at 55s failed at 55s
Offending 'frame'
@ 55 assertion filed
Normal frame is transmitted without extension 0
"assert_seq.sv", 24: asser_seq.frame_transmit_assert: started at 65s failed at 65s
Offending 'frame'
@ 65 assertion filed
Normal frame is transmitted without extension 0
"assert_seq.sv", 24: asser_seq.frame_transmit_assert: started at 75s failed at 75s
Offending 'frame'
@ 75 assertion filed
Normal frame is transmitted without extension 0
"assert_seq.sv", 24: asser_seq.frame_transmit_assert: started at 85s failed at 85s
Offending 'frame'
@ 85 assertion filed
Normal frame is transmitted without extension 0
"assert_seq.sv", 24: asser_seq.frame_transmit_assert: started at 95s failed at 95s
Offending 'frame'
@ 95 assertion filed
$finish at simulation time 100



(b) Sonet

(i) Example immediate assertion

module assert_on_FP();
bit clk;
bit frame_pulse;
reg [7:0]section_A1;
reg [7:0]section_A2;
bit [7:0]sonet_data_in;
bit A1A2_indicator;
initial
begin
clk = 0;
frame_pulse = 0;
sonet_data_in = 8'b0;
sonet_data_in = 8'b0;
#5 sonet_data_in = 'hf6;
#1 sonet_data_in = 'h28;
#1 A1A2_indicator= 1'b1;
#1 frame_pulse = 1'b1;
#1 sonet_data_in = 'h56;
#4 A1A2_indicator= 1'b0;
#4 frame_pulse = 1'b0;
#1 sonet_data_in = 'h99;
#1 sonet_data_in = 'h88;
#5sonet_data_in = 'hf6;
#1 sonet_data_in = 'h28;
#1 A1A2_indicator= 1'b1;
#1 frame_pulse = 1'b1;
#1 sonet_data_in = 'h56;
#4 A1A2_indicator= 1'b0;
#4 frame_pulse = 1'b0;
#1 sonet_data_in = 'h100;
#1 sonet_data_in = 'h28;
#5 sonet_data_in = 'hf6;
#1 sonet_data_in = 'h28;
#1 A1A2_indicator= 1'b1;
#1 frame_pulse = 1'b1;
#1 sonet_data_in = 'h56;
#4 A1A2_indicator= 1'b0;
#4frame_pulse = 1'b0;
#1 sonet_data_in = 'h44;
#1 sonet_data_in = 'h33;
#100 $finish;
end
always #1 clk = ~clk;

// Assertion used in always block
always @ (posedge clk)
begin
if(A1A2_indicator==1'b1)
CHECK_IF_FRAME_PULSE_IS_HIGH : assert (frame_pulse== 1'b1)
begin
$display ( "Assert Passed at time %0t",$time);
end
else
begin
$error( "assert failed at time %0t", $time);
end
end
endmodule

Output in VCS

"immd_assert.sv", 50: assert_on_FP.CHECK_IF_FRAME_PULSE_IS_HIGH: started at 7s failed at 7s
Offending '(frame_pulse == 1'b1)'
Error: "immd_assert.sv", 50: assert_on_FP.CHECK_IF_FRAME_PULSE_IS_HIGH: at time 7
assert failed at time 7
Assert Passed at time 9
Assert Passed at time 11
Assert Passed at time 27
Assert Passed at time 29
Assert Passed at time 31
"immd_assert.sv", 50: assert_on_FP.CHECK_IF_FRAME_PULSE_IS_HIGH: started at 45s failed at 45s
Offending '(frame_pulse == 1'b1)'
Error: "immd_assert.sv", 50: assert_on_FP.CHECK_IF_FRAME_PULSE_IS_HIGH: at time 45
assert failed at time 45
Assert Passed at time 47
Assert Passed at time 49

(ii) Example Concurrent Assertion

module assert_on_FP();
bit clk;
bit frame_pulse;
reg [7:0]section_A1;
reg [7:0]section_A2;
bit [7:0]sonet_data_in;
bit A1A2_indicator;
initial
begin
clk = 0;
frame_pulse = 0;
sonet_data_in = 8'b0;
sonet_data_in = 8'b0;
#1 A1A2_indicator= 1'b1;
#1 frame_pulse = 1'b1;
#1 sonet_data_in = 'h56;
#1 sonet_data_in = 'h28;
#1 sonet_data_in = 'h38;
#3 A1A2_indicator= 1'b0;
#4 frame_pulse = 1'b0;
#1 sonet_data_in = 'h00;
#1 sonet_data_in = 'h00;
#1 sonet_data_in = 'h00;
#1 sonet_data_in = 'h00;
#3 A1A2_indicator= 1'b1;
#1 frame_pulse = 1'b1;
#1 sonet_data_in = 'h00;
#1 sonet_data_in = 'h00;
#1 sonet_data_in = 'h00;
#1 sonet_data_in = 'h00;
#1 sonet_data_in = 'h00;
#1 sonet_data_in = 'h00;
#4 A1A2_indicator= 1'b0;
#4 frame_pulse = 1'b0;
#1 sonet_data_in = 'h100;
#1 sonet_data_in = 'h28;
#5 sonet_data_in = 'hf6;
#1 sonet_data_in = 'h28;
#1 A1A2_indicator= 1'b1;
#1 frame_pulse = 1'b1;
#1 sonet_data_in = 'h56;
#1 sonet_data_in = 'h86;
#1 sonet_data_in = 'h96;
#4 A1A2_indicator= 1'b0;
#4 frame_pulse = 1'b0;
#1 sonet_data_in = 'h00;
#1 sonet_data_in = 'h00;
#100 $finish;
end
always #1 clk = ~clk;
// Sequences with different operators
sequence A1A2indic_framepulse;
A1A2_indicator ##1 frame_pulse;
endsequence

sequence framepulse_sonet_data_in;
frame_pulse ##[2:5] sonet_data_in;
endsequence
//Property Layer
property seq_of_seq;
@(posedge clk)
A1A2indic_framepulse |-> framepulse_sonet_data_in;
endproperty
//Assertion Directive Layer
check_property: assert property(seq_of_seq);
endmodule

Output in VCS

"conc_assert.sv", 70: assert_on_FP.check_property: started at 21s failed at 33s
Offending 'sonet_data_in'
"conc_assert.sv", 70: assert_on_FP.check_property: started at 23s failed at 35s
Offending 'sonet_data_in'
"conc_assert.sv", 70: assert_on_FP.check_property: started at 51s failed at 63s
Offending 'sonet_data_in'

Popular Posts