Very Large Scale Integration (VLSI)

Sunday, 4 October 2015

International Conference on VLSI Design and Embeded Systems - Jan 2016

Friends, get yourself ready for the 29th International Conference on VLSI Design and 15th International Conference on Embedded Systems which will be held during January 4-8, 2016 at Kolkata, West Bengal, India.

The theme for the conference this year is "Technologies for a Safe and Inclusive World". This 5 day conference comprises: first three days (January 4 to 6, 2016) of main conference followed by Tutorials during the last two days (January 7-8, 2016).

The convergence of technology with modern life has reached a state where dependence of human life on semiconductor technology is ubiquitous. Today semiconductor technology is poised to look beyond its traditional bastions of application with pervasive impact on healthcare, environment, energy, transportation, and disaster management. The 29th International Conference on VLSI Design and the 15th International Conference on Embedded Systems will bring together industry and academia to present front-end technology under the theme of Technologies for a Safe and Inclusive World.

The Technical tracks will be grouped under the theme track and the three broad categories namely, Design Methodologies and Technology, Design Tools and EDA and Embedded System Design and Tools. The conference proceedings will be published by the IEEE Computer Society Press. Selected papers from this conference will also be published as special issues of top archival journals.

Authors are invited to submit full-length (6 pages maximum) in IEEE CS proceedings format, original, unpublished papers with an abstract (200 words maximum) under the tracks listed below. To enable double blind review, the author list should be omitted from the main document. Papers violating length and blind-review criteria would be excluded from the review process. Previously published papers or papers currently under review for other conferences/journals should not be submitted and will not be considered for publication.

Track: Design Methodology and Technology

D1: System-level Design

ESL, System-level design methodology, Multicore systems, Processor and memory design, Concurrent interconnect, Networks-on-chip, Defect tolerant architectures

D2: Advances in Digital Design

Logic and Physical synthesis; Place & Route, Clock Tree, Physical Verification, Timing and Signal integrity, Power analysis and integrity, OCV, DFM; DFY; Challenges for advanced technology nodes

D3: Analog / RF Design

Analog Mixed Signal IP; High-Speed interfaces; SDR and wireless; Low-power Analog and RF; Effective use of Spectrum; Memory Design, Standard Cell Design

D4: Power Aware Design

Low-power design, micro-architectural techniques, thermal estimation and optimization, power estimation methodologies, and CAD tools

D5: Devices / Circuits

New Devices and architectures; Low power devices; Modeling and Simulation; Multi-domain simulation; Numerical methods; Device/circuit level variability models; Reliability simulation

D6: Emerging Technologies

Nano-CMOS technologies; MEMS; CMOS sensors; CAD/EDA methodologies for nanotechnology; Nano-electronics and Nano-circuits, Nano-sensors, MEMS applications, Nano-assemblies and Devices, Non-classical CMOS; Post-CMOS devices; Biomedical circuits, Carbon Nano-tubes based computing

Track : Design Tools and EDA

T1: Design Verification

Functional Verification; Behavioral Simulation; RTL Simulation; Coverage Driven Verification; Assertion Based Verification; Gate-level simulation; Emulation; Hardware Assisted Verification; Formal Verification; Equivalence Checking; Verification Methodologies

T2: Test Reliability and Fault-Tolerance

DFT, Fault modelling/simulation; ATPG; Low Power DFT; BIST & Repair; Delay test; Fault tolerance; Online test; AMS/RF test; Board-level and system-level test; Silicon debug, post-silicon validation; Memory test; Reliability test; static and dynamic defect- and fault-recoverability, and variation-aware design

T3: Computer-Aided Design (CAD)

Hardware/software co-design, logic and behavioural synthesis, logic mapping, simulation and formal verification, layout (partitioning, placement, routing, floorplanning, compaction)

Track : Embedded System Design and Tools

E1: Embedded Systems

Hardware/Software co-design & verification; Reconfigurable computing; Embedded multi-cores SOC and systems; Embedded software including Operating Systems, Firmware, Middleware, Communication, Virtualization, Encryption, Compression, Security, Reliability; Hybrid systems-on-chip; Embedded applications, Platforms & Case studies

E2: FPGA Design and Reconfigurable Systems

FPGA Architecture, FPGA Circuit Design, CAD for FPGA, FPGA Prototyping

E3: Wireless Systems

Wireless Sensor Networks, Low Power wireless Systems, Embedded Wireless, Wireless protocols, Wireless Power / Charging

Theme Track : Technologies for a Safe and Inclusive World

H1: Technologies for Healthcare Applications

H2: Technologies for Smart Management of Energy Systems

H3: Technologies for Intelligent and Secure Transportation Systems

H4: Technologies for Safety Assurance of Embedded Circuits and Systems

H5: Technologies for Secure Embedded Circuits and Systems

Proposals for Tutorials and Special Sessions/Panel Discussion on the above-listed topics (but not limited to) are invited. Please check conference website for details.

Important dates are the following:

REGULAR PAPERS

Abstract submission : July 19, 2015 (Sunday)

Full Paper submission : July 26, 2015 (Sunday)

Acceptance Notification : Sep 26, 2015 (Saturday)

Camera-ready version : Oct 11, 2015 (Sunday)

TUTORIALS

Tutorial Proposals : July 19, 2015 (Sunday)

Acceptance Notification : Sep 26, 2015 (Saturday)

Presentation Slides : Nov 15, 2015 (Sunday)

SPECIAL SESSIONS

Proposal submission : July 19, 2015 (Sunday)

General Chairs

Pradip Bose, IBM

Susmita Sur-Kolay, ISI

Vice-General Chairs

Indranil Sengupta, IITKGP

Parthasarathi Dasgupta, IIMC

Program Chairs

Krishnendu Chakrabarty, Duke

Pallab Dasgupta, IITKGP

Partha P. Das, IITKGP

Tutorial Chairs

Hafizur Rahaman, IIEST

Prabhat Mishra, UF

Annajirao Garimella, Intel

Publiciy chairs

Chandan Giri, IIESTS

Ken Stevens, U. Utah

Monica Pereira, UFRN

Robert Wille, U. Bremen

Swarup Bhunia, CWRU

T. -Y. Ho, NCKU

Monday, 21 September 2015

SVEditor - A SystemVerilog Editor Eclipse Plugin

Source code editors have features specifically designed to simplify and speed up input of source code, such as syntax highlighting, indentation, autocomplete and bracket matching functionality. Variety of source code editors are available for VLDH, Verilog & SystemVerilog. We have already posted feb of them like Scriptum, and Emacs.

Friday, 11 September 2015

UVM Interview Questions - 4

Q26: What is p_sequencer ? OR Difference between m_sequencer and p_sequencer?

m_sequencer is the default handle for uvm_vitual_sequencer and p_sequencer is the hook up for child sequencer.

m_sequencer is the generic uvm_sequencer pointer. It will always exist for the uvm_sequence and is initialized when the sequence is started.

p_sequencer is a typed-specific sequencer pointer, created by registering the sequence to the sequencer using macros (`uvm_declare_p_sequencer) . Being type specific, you will be able to access anything added to the sequencer (i.e. pointers to other sequencers, etc.). p_sequencer will not exist if we have not registered the sequence with the `uvm_declare_p_sequencer macros.

The drawback of p_sequencer is that once the p_sequencer is defined, one cannot run the sequence on any other sequencer type.

Q27: What is the difference between Active mode and Passive mode with respect to agent?

An agent is a collection of a sequencer, a driver and a monitor.

In active mode, the sequencer and the driver are constructed and stimulus is generated by sequences sending sequence items to the driver through the sequencer. At the same time the monitor assembles pin level activity into analysis transactions.

In passive mode, only the monitor is constructed and it performs the same function as in an active agent. Therefore, your passive agent has no need for a sequencer. You can set up the monitor using a configuration object.

Q28: What is the difference between copy and clone?

The built-in copy() method executes the __m_uvm_field_automation() method with the required copy code as defined by the field macros (if used) and then calls the built-in do_copy() virtual function. The built-in do_copy() virtual function, as defined in the uvm_object base class, is also an empty method, so if field macros are used to define the fields of the transaction, the built-in copy() method will be populated with the proper code to copy the transaction fields from the field macro definitions and then it will execute the empty do_copy() method, which will perform no additional activity.

The copy() method can be used as needed in the UVM testbench. One common place where the copy() method is used is to copy the sampled transaction and pass it into a sb_calc_exp() (scoreboard calculate expected) external function that is frequently used by the scoreboard predictor.

The clone() method calls the create() method (constructs an object of the same type) and then calls the copy() method. It is a one-step command to create and copy an existing object to a new object handle.

Q29: What is UVM factory?

UCM Factory is used to manufacture (create) UVM objects and components. Apart from creating the UVM objects and components the factory concept essentially means that you can modify or substitute the nature of the components created by the factory without making changes to the testbench.

For example, if you have written two driver classes, and the environment uses only one of them. By registering both the drivers with the factory, you can ask the factory to substitute the existing driver in environment with the other type. The code needed to achieve this is minimal, and can be written in the test.

Q30: What are the types of sequencer? Explain each?

There are two types of sequencers :

uvm_sequencer #(REQ, RSP) :

When the driver initiates new requests for sequences, the sequencer selects a sequence from a list of available sequences to produce and deliver the next item to execute. In order to do this, this type of sequencer is usually connected to a driver uvm_driver #(REQ, RSP).

uvm_push_sequencer #(REQ, RSP) :

The sequencer pushes new sequence items to the driver, but the driver has the ability to block the item flow when its not ready to accept any new transactions. This type of sequencer is connected to a driver of type uvm_push_driver #(REQ, RSP).

<< PREVIOUS NEXT >>

Thursday, 10 September 2015

UVM Interview Questions - 3

Q21: What is analysis port?

Analysis port (class uvm_tlm_analysis_port) — a specific type of transaction-level port that can be connected to zero, one, or many analysis exports and through which a component may call the method write implemented in another component, specifically a subscriber.

port, export, and imp classes used for transaction analysis.

uvm_analysis_port

Broadcasts a value to all subscribers implementing a uvm_analysis_imp.

uvm_analysis_imp

Receives all transactions broadcasted by a uvm_analysis_port.

uvm_analysis_export

Exports a lower-level uvm_analysis_imp to its parent.

Q22: What is TLM FIFO?

In simpler words TLM FIFO is a FIFO between two UVM components, preferably between Monitor and Scoreboard. Monitor keep on sending the DATA, which will be stored in TLM FIFO, and Scoreboard can get data from TLM FIFO whenever needed.

// Create a FIFO with depth 4

tlm_fifo = new ("uvm_tlm_fifo", this, 4);

Q23: How sequence starts?

start_item starts the sequence

virtual task start_item ( uvm_sequence_item item,

int set_priority = -1,

uvm_sequencer_base sequencer = null )

start_item and finish_item together will initiate operation of a sequence item. If the item has not already been initialized using create_item, then it will be initialized here to use the default sequencer specified by m_sequencer.

Q24: What is the difference between UVM RAL model backdoor write/read and front door write/read ?

Fontdoor access means using the standard access mechanism external to the DUT to read or write to a register. This usually involves sequences of time-consuming transactions on a bus interface.

Backdoor access means accessing a register directly via hierarchical reference or outside the language via the PLI. A backdoor reference usually in 0 simulation time.

Q25: What is objection?

The objection mechanism in UVM is to allow hierarchical status communication among components which is helpful in deciding the end of test.

There is a built-in objection for each in-built phase, which provides a way for components and objects to synchronize their testing activity and indicate when it is safe to end the phase and, ultimately, the test end.

The component or sequence will raise a phase objection at the beginning of an activity that must be completed before the phase stops, so the objection will be dropped at the end of that activity. Once all of the raised objections are dropped, the phase terminates.

Raising an objection: phase.raise_objection(this);

Dropping an objection: phase.drop_objection(this);

<< PREVIOUS NEXT >>

Wednesday, 9 September 2015

UVM Interview Questions - 1

Q11: Difference between module & class based TB?

Ans: A module is a static object present always during of the simulation.

A Class is a dynamic object because they can come and go during the life time of simulation.

Q12: What is uvm_config_db ? What is difference between uvm_config_db & uvm_resource_db?

Ans: uvm_config_db is a parameterized class used for configuration of different type of parameter into the uvm database, So that it can be used by any component in the lower level of hierarchy.

uvm_config_db is a convenience layer built on top of uvm_resource_db, but that convenience is very important. In particular, uvm_resource_db uses a "last write wins" approach. The uvm_config_db, on the other hand, looks at where things are in the hierarchy up through end_of_elaboration, so "parent wins." Once you start start_of_simulation, the config_db becomes "last write wins."

All of the functions in uvm_config_db#(T) are static, so they must be called using the :: operator

It is extended from the uvm_resource_db#(T), so it is child class of uvm_resource_db#(T)

Q13: What is the advantage and difference of `uvm_component_utils() and `uvm_object_utils()?

Ans: The utils macros define the infrastructure needed to enable the object/component for correct factory operation.

The reason there are two macros is because the factory design pattern fixes the number of arguments that a constructor can have. Classes derived from uvm_object have constructors with one argument, a string name. Classes derived from uvm_component have two arguments, a name and a uvm_component parent.

The two `uvm_*utils macros inserts code that gives you a factory create() method that delegates calls to the constructors of uvm_object or uvm_component. You need to use the respective macro so that the correct constructor arguments get passed through. This means that you cannot add extra constructor arguments when you extend these classes in order to be able to use the UVM factory.

Q14: Difference between `uvm_do and `uvm_rand_send ?

Ans: `uvm_do perform the below steps:

create
start_item
randomize
finish_item
get_response (optional)

while `uvm_rand_send perform all the above steps except create. User needs to create sequence / sequence_item.

Q15: Difference between uvm_transaction and uvm_seq_item?

Ans: class uvm_sequence_item extends uvm_transaction

uvm_sequence_item extended from uvm_transaction only, uvm_sequence_item class has more functionality to support sequence & sequencer features. uvm_sequence_item provides the hooks for sequencer and sequence , So you can generate transaction by using sequence and sequencer , and uvm_transaction provide only basic methods like do_print and do_record etc .

<< PREVIOUS NEXT >>

UVM Interview Questions - 2

Q16: Is uvm is independent of systemverilog ?

Ans: UVM is a methodology based on SystemVerilog language and is not a language on its own. It is a standardized methodology that defines several best practices in verification to enable efficiency in terms of reuse and is also currently part of IEEE 1800.2 working group.

Q17: What are the benefits of using UVM?

Ans: Some of the benefits of using UVM are :

Modularity and Reusability – The methodology is designed as modular components (Driver, Sequencer, Agents , env etc) which enables reusing components across unit level to multi-unit or chip level verification as well as across projects.
Separating Tests from Testbenches – Tests in terms of stimulus/sequencers are kept separate from the actual testbench hierarchy and hence there can be reuse of stimulus across different units or across projects
Simulator independent – The base class library and the methodology is supported by all simulators and hence there is no dependence on any specific simulator
Better control on Stimulus generation – Sequence methodology gives good control on stimulus generation. There are several ways in which sequences can be developed which includes randomization, layered sequences, virtual sequences etc which provides a good control and rich stimulus generation capability.
Easy configuration – Config mechanisms simplify configuration of objects with deep hierarchy. The configuration mechanism helps in easily configuring different testbench components based on which verification environment uses it and without worrying about how deep any component is in testbench hierarchy
Factory mechanism – Factory mechanisms simplifies modification of components easily. Creating each components using factory enables them to be overridden in different tests or environments without changing underlying code base.

Q18: Can we have user defined phase in UVM?

Ans: In addition to the predefined phases available in uvm , the user has the option to add his own phase to a component. This is typically done by extending the uvm_phase class the constructor needs to call super.new which has three arguments

Name of the phase task or function
Top down or bottom up phase
Task or function

The call_task or call_func and get_type_name need to be implemented to complete the addition of new phase.

Below is a simple example

Example

class custom_phase extends uvm_phase;

function new();

super.new(“custom”,1,1);

endfunction

task call_task ( uvm_component parent);

my_comp_type comp;

if ( $cast(comp,parent) )

comp.custom_phase();

endtask

virtual function string get_type_name();

return “custom”;

endfunction

endclass

Q19: What is uvm RAL model ? why it is required ?

Ans: In a verification context, a register model (or register abstraction layer) is a set of classes that model the memory mapped behavior of registers and memories in the DUT in order to facilitate stimulus generation and functional checking (and optionally some aspects of functional coverage). The UVM provides a set of base classes that can be extended to implement comprehensive register modeling capabilities.

Q20: What is the difference between new() and create?

Ans: We all know about new() method that is use to allocate memory to an object instance. In UVM (and OVM), the create() method causes an object instance to be created from the factory. This allows you to use factory overrides to replace the desired object with an object of a different type without having to recode.

<< PREVIOUS NEXT >>

UVM Interview Questions

Q1: What is UVM? What is the advantage of UVM?

Ans: UVM (Universal Verification Methodology) is a standardized methodology for verifying the both complex & simple digital design in simple way.

UVM Features:

First methodology & second collection of class libraries for Automation
Reusability through testbench
Plug & Play of verification IPs
Generic Testbench Development
Vendor & Simulator Independent
Smart Testbench i.e. generate legal stimulus as from pre-planned coverage plan
Support CDV –Coverage Driven Verification
Support CRV –Constraint Random Verification
UVM standardized under the Accellera System Initiative
Register modeling

Q2: UVM derived from which language?

Ans: Here is the detailed connection between SV, UVM, OVM and other methodologies.

Q3. What is the difference between uvm_component and uvm_object?

We already have uvm_object, why do we need uvm_component which is actually derived class of uvm_object?

Ans:

uvm_component:

Quasi Static Entity (after build phase it is available throughout the simulation)
Always tied to a given hardware(DUT Interface) Or a TLM port
Having phasing mechanism for control the behavior of simulation
Configuration Component Topology

uvm_object:

Dynamic Entity (create when needed, transfer from one component to other & then dereference)
Not tied to a given hardware or any TLM port
Not phasing mechanism

Q4: Why phasing is used? What are the different phases in uvm?

Ans: UVM Phases is used to control the behavior of simulation in a systematic way & execute in a sequential ordered to avoid race condition. This could also be done in system verilog but manually.

List of UVM Phases:
buid_phase
connect_phase
end_of_elaboration_phase
start_of_simulation_phase
run _phase (task)
Sub Phases of Reset Phase:

pre_reset_phase

reset_phase

post_reset_phase

pre_configure_phase

configure_phase

post_configure_phase

pre_main_phase

main_phase

post_main_phase

pre_shutdown_phase

shutdown_phase

post_shutdown_phase
extract_phase
check_phase
report_phase

Below figure makes it more clear

Q5: Which uvm phase is top - down , bottom – up & parallel?

Ans: Only build phase is a top-down & other phases are bottom-up except run phase which is parallel. The build phase works top-down since the testbench hierarchy may be configure so we need to build the branches before leafs

Q6: Why build phase is top – down & connect phase is bottom – up?

Ans: The connect phase is intended to be used for making TLM connections between components, which is why it occur after build phase. It work bottom-up so that its got the correct implementation all the way up the design hierarchy, if worked top-down this would be not possible

Q7: Which phase is function & which phase is task?

Ans: Only run phase is a task (time consuming phase) & other phases are functions (non-blocking)

Q8: Which phase takes more time and why?

Ans: As previously said the run phase is implemented as task and remaining all are function. run phase will get executed from start of simulation to till the end of simulation. run phase is time consuming, where the testcase is running.

Q9: How uvm phases initiate?

Ans: UVM phases initiate by calling run_test(“test1”) in top module. When run_test() method call, it first create the object of test top & then call all phases.

Q10: How test cases run from simulation command line?

Ans: In top module write run_test(); i.e. Don't give anything in argument.

Then in command line : +UVM_TESTNAME=testname

Next >>