Thursday 8 November 2012

Assertion to check Frequency/time period


time clk_period = 6400;
//property chk_period(`DUT_TOP.sd0_rx_clk_0, time clk_period);
property chk_period(time clk_period);
time current_time;
@(posedge `DUT_TOP.sd0_rx_clk_0)
disable iff((!`DUT_TOP.reset))
if($stable(clk_period, @(posedge `DUT_TOP.sd0_rx_clk_0 )))
('1,current_time = $time) ##1 ((clk_period) == ($time- current_time));
endproperty: chk_period

Sunday 30 September 2012

God Explained in a Taxi Ride by Paul Arden

God Explained in a Taxi Ride: Since the bginning of mankind, more thought has gone into the understanding of God than any other subject under the sun ... this little book explains once and for all




God Explained in a Taxi Ride: Since the bginning of mankind, more thought has gone into the understanding of God than any other subject under the sun ... this little book explains once and for all



www.scribd.com/doc/.../GOD-EXPLAINED-IN-A-TAXI-RIDEppt

Monday 10 September 2012

Asynchronous and Synchronous Reset



Asynchronous and Synchronous Reset

ASYNCHRONOUS RESET
A fully asynchronous reset is one that both asserts and de-asserts a flip-flop asynchronously. Here, asynchronous reset refers to the situation where the reset net is tied to the asynchronous reset pin of the flip-flop. Additionally, the reset assertion and de-assertion is performed without any knowledge of the clock. This type of reset is very common but is very dangerous if the module boundary represents the FPGA boundary.

The biggest problem with the asynchronous reset circuit described above is that, it will work most of the time. However, if the edge of the reset deassertion is too close to the clock edge and violate the reset recovery time, then the output of FF goes to metastable. The reset recovery time is a type of setup timing condition on a flip-flop that defines the minimum amount of time between the de-assertion of reset and the next rising clock edge as shown in Figure.


It is important to note that reset recovery time violations only occur on the de-assertion of reset and not the assertion. Therefore, fully asynchronous resets are not recommended.

SYNCHRONOUS RESET
The most obvious solution to the problem introduced in the preceding section is to fully synchronize the reset signal as you would any asynchronous signal.

The advantage to this type of topology is that the reset presented to all functional flip-flops is fully synchronous to the clock and will always meet the reset recovery time. The interesting thing about this reset topology is actually not the deassertion of reset for recovery time but rather the assertion In the previous section, it was noted that the assertion of reset is not of interest, but that is true only for asynchronous resets and not necessarily with synchronous resets. Consider the scenario illustrated in Figure.
Consider the scenario where the clock is running sufficiently slow, the reset is not captured due to the absence of a rising clock edge during the assertion of the reset signal. The result is that the flip-flops within this domain are never reset.

Fully synchronous resets may fail to capture the reset signal itself (failure of assertion) depending on the nature of the clock.

For this reason, fully synchronous resets are not recommended unless the capture of the reset signal (reset assertion) can be guaranteed by design.

Asynchronous Assertion, Synchronous De-assertion
A third approach that captures the best of both techniques is a method that asserts all resets asynchronously but de-asserts them synchronously.
In Figure, the registers in the reset circuit are asynchronously reset via the external signal, and all functional registers are reset at the same time. This occurs asynchronous with the clock, which does not need to be running at the time of the reset. When the external reset de-asserts, the clock local to that domain must toggle twice before the functional registers are taken out of reset. Note that the functional registers are taken out of reset only when the clock begins to toggle and is done so synchronously.

A reset circuit that asserts asynchronously and de-asserts synchronously generally provides a more reliable reset than fully synchronous or fully asynchronous resets.

Wednesday 5 September 2012

What Young India Wants -Chetan Bhagat


What Young India Wants Overview

In his latest book, What Young India Wants, Chetan Bhagat asks hard questions, demands answers and presents solutions for a better, more prosperous India.

• Why do our students regularly commit suicide?
• Why is there so much corruption in India?
• Can’t our political parties ever work together?
• Does our vote make any difference at all?
• We love our India, but shouldn’t some things be different?

All of us have asked these questions at some time or the other. So does Chetan Bhagat, India’s most loved writer, in What Young India Wants, his first book of non-fiction. What Young India Wants is based on Chetan Bhagat’s vast experience as a very successful writer and motivational speaker. In clear, simple prose, and with great insight, he analyses some of the complex issues facing modern India, offers solutions and invites discussion on them. And, at the end, he asks this important question: Unless we are all in agreement on what it is going to take to make our country better, how will things ever change? If you want to understand contemporary India, the problems that face it, and want to be a part of the solution, What Young India Wants is the book for you.

Tuesday 21 August 2012

Kissing Ass by Clyde D'Souza


Kissing Ass by Clyde D'Souza 


Some people can kiss ass naturally, some can’t do it to save their lives, and many just don’t know how! Kissing Ass: The Art of Office Politics is a no-bullshit, jargon-free, non-sloppy guide that breaks down typical workplace situations and offers you not textbook advice but real sucking-up solutions to them. From nervous first days to elated farewell mails, Kissing Ass gives you tips and tricks on how to act, react, or play dumb as per the scenario. Learn different types of ego massage techniques, what to say to the CEO in the loo, how to reply to work emails over weekends, and, yes, even how to deal with sex at work! So polish your corporate lips, pucker up, and get ready to kiss your way to success. Sales points • A tongue-in-cheek book on what people don’t tell you about office politics • One of a kind in the market • Fast-paced, humourous, and written in a casual tone • Uses Indian references as examples and diagrams to make it visually appealing and readerfriendly • Aimed at the BlackBerry-toting, instant-gratification-seeking Indian • Clyde D’Souza has written scripts for MTV and spoofs for JAM magazine

Monday 20 August 2012

Revolution 2020 and 2-states - by Chetan Bhagat

Read revolution 2020 - chetan bhagat , very nicely written , Once start reading you dont even like to stop in between , too good , became fan of Chetan Bhagat , suggesting to all readers..

Read "2-states" again from the list of chetan bhagat , interesting love story and a msg driven book for all generations ...

"The Present" by Spencer Johnson.

Read "The Present" by Spencer Johnson. 

This book is a good reference for those who wants to enjoy present and future . 
Good thing about Spencer is he explains things with story which catch holds the reader till the end. 
He has nicely explained how to balance personal and professional life.. It's 100 odd pages book. 
Personally suggest this book to all the active readers and those who wants to develop reading as their hobby :)

" Screw it , lets do it" by Richard Branson

Read " Screw it , lets do it" by Richard Branson. 
Richard Branson is founder of Virgin Group. There are many more businesses on his name ... It's 100 page book but worth spending time.. After reading I feel if I can do 10% of what he has done , my life will be rocking.. He is a go-getter..

"THE SECRET" by rhondo rhyne.

Read " THE SECRET" by rhondo rhyne. 

Very powerful book , suggested all the readers to read it , "The Secret" reveals the most powerful law in the universe. 

e.g Everybody in this universe had dreams in life - some one want to be a millionaire , some want beautiful GF/Wife, some want BMW, some want to be social activist .. any dame dream can come true if you follow the rules define in this book . 

This books talks about law of attraction and the how universe reacts to your thoughts .. Good to have it in your pocket. Readers not only read it even try to follow . It works in my case.

You can even go to moon if you have a strong desire/thought.. Enjoy reading.. .

Thursday 16 August 2012

SystemVerilog Language Guidelines


SystemVerilog Language Guidelines

 

1.1 Rule: Check that $cast() has succeeded
If you are going to use the result of the cast operation, then you should check the status returned by the $cast call and deal with it gracefully, otherwise the simulation may crash with a null pointer.
Note that it is not enough to check the result of the cast method, you should also check that the handle to which the cast is made is not null. A cast operation will succeed if the handle from which the cast is being done is null.
// How to check that a $cast has worked correctly
function my_object get_a_clone(uvm_object to_be_cloned);
  my_object t;
 
  if(!$cast(t, to_be_cloned.clone()) begin
    `uvm_error("get_a_clone", "$cast failed for to_be_cloned")
  end
  if(t == null) begin
    `uvm_fatal("get_a_clone", "$cast operation resulted in a null handle, check to_be_cloned handle")
  end
 
  return t;
endfunction: get_a_clone

1.2 Rule: Check that randomize() has succeeded
If no check is made the randomization may be failing, meaning that the stimulus generation is not working correctly.
// Using if() to check randomization result
if(!seq_item.randomize() with {address inside {[o:32'hF000_FC00]};}) begin
  `uvm_error("seq_name", "randomization failure, please check constraints")
end

1.3 Rule: Use if rather than assert to check the status of method calls
Assert results in the code check appearing in the coverage database, which is undesired. Incorrectly turning off the action blocks of assertions may also produce undesired results.

Constructs to be Avoided

The SystemVerilog language has been a collaborative effort with a long history of constructs borrowed from other languages. Some constructs have been improved upon with newer constructs, but the old constructs remain for backward compatibility and should be avoided. Other constructs were added before being proven out and in practice cause more problems than they solve.
1.4 Rule: Do not place any code in $unit, place it in a package
The compilation unit, $unit, is the scope outside of a design element (package, module, interface, program). There are a number of problems with timescales, visibility, and re-usability when you place code in $unit. Always place this code in a package.
1.5 Guideline: Do not use associative arrays with a wildcard index[*]
A wildcard index on an associative array is an un-sized integral index. SystemVerilog places severe restrictions on other constructs that cannot be used with associative arrays having a wildcard index. In most cases, an index type of [int] is sufficient. For example, a foreach loop requires a fixed type to declare its iterator variable.
string names[*]; // cannot be used with foreach, find_index, ...
string names[int];
...
foreach (names[i])
  $display("element %0d: %s",i,names[i]);

1.6 Guideline: Do not use #0 procedural delays
Using a #0 procedural delay, sometimes called a delta delay, is a sure sign that you have coded incorrectly. Adding a #0 just to get your code working usually avoids one race condition and creates another one later.Often, using a non-blocking assignment ( <= ) solves this class of problem.

 

Coding Patterns

Some pieces of code fall into well recognized patterns that are know to cause problems
1.7 Rule: Do not rely on static variable initialization order, initialize on first instance.
The ordering of static variable initialization is undefined. If one static variable initialization requires the non-default initialized value of another static variable, this is a race condition. This can be avoided by creating a static function that initializes the variable on the first reference, then returns the value of the static variable, instead of directly referencing the variable.
typedef class A;
typedef class B;
A a_top=A::get_a();
B b_top=B::get_b();
class A;
  static function A get_a();
    if (a_top == null) a_top =new();
    return a_h;
  endfunction
endclass : A
class B;
  A a_h;
  protected function new;
    a_h = get_a();
  endfunction
  static function B get_b();
    if (b_top == null) b_top =new();
    return b_top;
  endfunction
endclass : B

 

Covergroups

1.8 Guideline: Create covergroups within wrapper classes
Covergroups have to be constructed within the constructor of a class. In order to make the inclusion of a covergroup within a testbench conditional, it should be wrapped within a wrapper class.
1.9 Guideline: Covergroup sampling should be conditional
Build your covergroups so that their sample can be turned on or off. For example use the 'iff' clause of covergroups.
// Wrapped covergroup with sample control:
class cg_wrapper extends uvm_component;
 
logic[31:0] address;
bit coverage_enabled
 
covergroup detail_group;
  ADDRESS:  coverpoint addr iff(coverage_enabled) {
    bins low_range = {[0:32'h0000_FFFF]};
    bins med_range = {[32'h0001_0000:32'h0200_FFFF]};
    bins high_range = {[32'h0201_0000:32'h0220_FFFF]};
  }
// ....
endgroup: detail_group
 
function new(string name = "cg_wrapper", uvm_component parent = null);
  super.new(name, parent);
  // Construct covergroup and enable sampling
  detail_group = new();
  coverage_enabled = 1; 
endfunction
 
// Set coverage enable bit - allowing coverage to be enabled/disabled
function void set_coverage_enabled(bit enable);
  coverage_enabled = enable;
endfunction: set_coverage_enabled
 
// Get current state of coverage enabled bit
function bit get_coverage_enabled();
  return coverage_enabled;
endfunction: get_coverage_enabled
 
// Sample the coverage group:
function void sample(logic[31:0] new_address);
  address = new_address;
  detail_group.sample();
endfunction: sample
Coverpoint sampling may not be valid in certain situations, for instance during reset.
// Using iff to turn off unnecessary sampling:
 
// Only sample if reset is not active
coverpoint data iff(reset_n != 0) {
  // Only interested in high_end values if high pass is enabled:
  bins high_end = {[10000:20000]} iff(high_pass);
  bins low_end = {[1:300]};
  }

 

Collecting Coverage

1.10 Guideline: Use the covergroup sample() method to collect coverage
Sample a covergroup by calling the sample routine, this allows precise control on when the sampling takes place.

1.11 Rule: Label coverpoints and crosses
Labelling coverpoints allows them to be referenced in crosses and easily identified in reports and viewers.
payload_size_cvpt: coverpoint ...
Labelling crosses allows them to be easily identified
payload_size_X_parity: cross payload_size_cvpt, parity;

1.12 Guideline: Name your bins
Name your bins, do not rely on auto-naming.
bin minimum_val = {min};
 

1.13 Guideline: Minimize the size of the sample
It is very easy to specify large numbers of bins in covergroups through autogeneration without realising it. You can minimise the impact of a covergroup on simulation performance by thinking carefully about the number and size of the bins required, and by reducing the cross bins to only those required.

Thursday 9 August 2012

How to choose the proper bus between SPI, I2C, UART?

Uart 
Advantages : single wire, easy interface to PCs,MCU UARTSs etc. range of standard physical interfaces (TTL, RS232, RS422, RS485) covers a big range of distance/speed capabilites with off-the-shelf hardware. 
Disadvantages : Needs reasonable clock accuracy both ends. Max data rate in practice about 1mbit/sec (typically limited by UART capabilities). 

SPI 
Advantages: Potentially very fast (10-20mbits/sec), very simple interface, very easy to implement in hard logic,FPGA or software. 
Self-clocking so can wake an MCU on reception and have the data byte available once woken. 
Flexible data word sizes

Disadvantages : 
Multiple devices need multiple select lines.

I2C
Advantages : 
Only 2 wires to support multiple devices. Multimaster capability
Timing constraints of protocol reduce likelihood of false data (e.g. eeprom corruption) in noisy or powerup/down situations.  

Disadvantages : 
More complex protocol than SPI, harder to level-shift or optoisolate due to bidirectional lines. 
Speed up to 400kbit/sec (1mbit for a few devices), but in practice can be limited to lower rates by capacitance if tracks are long.

Tuesday 24 July 2012

Proposed Reusable Verification Environment Architecture


Thanks to Moore’s Law “The numbers of transistors that can be placed on
a semiconductor die doubles approximately every 18 months”.
From 1965 till date the density of transistors on the die is increasing which
in turn result in to exponentially increase in the complexity of the whole SoC
design
Verification challenges increases drastically as time to market becomes
crucial for every company. Some companies are having their legacy
environment which exists from long and some is moving towards latest UVM
based env, so it is very important that VIP’s should designed and architected
in such a way that it meets all the required scenarios as well as met time to
market.
Through this paper I will try to put sample environment architecture which is
fully reusable at every level. To move ahead it is very important to highlight
on important question- why reusable?

Why reusable?
As design complexity is increasing and as a result 50-70 % of total effort
goes in to verification. Due to complexity risk is also rising exponentially.
Reusability will provide:
1. Build effort will reduced.
2. It will decrease the verification risk.
3. Team gets ready to use the VIP with limited expertise of
technology/protocol.
4. Easy to integrate with existing environments.
5. It is easy to take multiple instantiation.
6. Test case development is comparatively easy.
7. Post sales support needs will reduce exponentially.
Verification Environment Components and Industry best practices:


In this section we will brief about each verification component shown above
in figure1 and the best practices followed to make it as reusable
components.

  1. Scoreboard
  2. Checker
  3. Monitor
  4. Coverage
  5. Data/Transaction/Messaging
  6. Scripting/Directory Structure
  7. Documentation


Scoreboard
Purpose of the scoreboard is to collect data and compare the same. i.e. data
integrity.
Scoreboard should be designed in such a way that it can be easily integrated
at:

  • Block level
  • End - End level

Scoreboard should independent component it should not depend on any BFM
or Monitor signals. Scoreboard should be parameterized. There should not be
any hardcoded/constant value for any items/fifo/memory etc.

Checker
I would suggest dividing the checker in to five parts:

  • Timing Checker
  • Functional Checker
  • Clock checker
  • Reset Checker
  • x/z checker

I suggest all the above checkers should be develop using system verilog
assertions to the extent possible. In addition there should not be any fixed
values, it should be configurable.
Also checkers should be designed in such a way that it can be plug without
dependency on any of the other verification components.

Monitor
As shown above in the architecture, monitor is classified in to –

  • BFM monitor
    • Active Monitor
    • Passive Monitor
  • Interface Monitor

Monitor job is not only to monitor the activity on the interface but it has to
even deliver the data to scoreboard and checker. Point should be taken care
that monitor should not snoop any design signals even it should not have
any dependency on scoreboard and checker to complete its activity. It
should have a capacity to work as an independent component. Monitor
should have a facility to disable/enable it’s functionality as per user needs.

Coverage
Coverage can be classified in to –

  • Functional coverage
  • Checker coverage
  • Test coverage

Coverage should be designed in such a way that we can separate
implementation and non-implementation specific coverage for reusability.

Data/Transaction/Messaging
Data/Transaction is a very important part of any environment. It should be
designed in such a way that we can make maximum use of randomization.
Constraints on data items is written in such a way that it does not contain
any fixed values e.g if we want to generate address in range 32’h00-32’h0f,
we have to pass config field to set the values , this way of design will give us
mode of reusability.
Messaging plays a very crucial role; it should be clear and distinct. Some of
the common messaging rule which we can follow is to have a separate id for
each id/note. In addition we have to put a clear thought on termination
messages. Special care needs to be given on formatting of the message.

Scripting/Directory Structure
Scripting is a very important part in automation. Scripting should not contain
any absolute path. Directory structure should be kept simple. Script should
be designed to create a complete directory structure and brings only the
necessary files. Even we have to take care that user does not have to pass
more option to generate the requested data.

Documentation
Plays a very crucial role, I would recommend three different type of
documentation:

· Integration document – It will highlight ways to connect
components. E.g How to connect scoreboard at block level, end-end
level etc. In case of Ethernet VIP this document will highlights the way
in which VIP can be used as a MAC or PHY. In case of PCIe documents
will highlight the ways to use it as End-point, Root Complex or Switch.

· Configuration document - In this document we should highlight the
different ways in which we can modify BFM, data class, scoreboard,
checker and monitor. E.g If we want to configure VIP for x4 lane this
document should highlights the corresponding parameter or macro
which users need to configure to make all the Verif components work
in x4 mode. This document should also highlight the test related
configuration that user can set to generate the desired scenario.

· Architecture document – Intention of this document is to give
detailed information about the whole VIP starting from licensing,
directory structure, scripting to architecture and internals of the same.
This should be the ultimate guide for the user.
Above practices will not only ease the life of verification engineer but
definitely increase the quality of verification and not needed to say that it
will save time and help companies to tap time to market.