HDL Code Analysis For ASICs in Mobile Systems

The complex work of designing new ASICs today and the increasing costs of time to market (TTM) delays are putting high responsibility on the research and development teams to make fault free designs.

The main purpose of implementing a static rule checking tool in the design flow today is to find errors and bugs in the hardware definition language (HDL) code as fast and soon as possible. The sooner you find a bug in the design, the shorter the turnaround time becomes, and thereby both time and money will be saved.

There are a couple of tools in the market that performs static HDL analysis and they vary in both price and functionality. In this project mainly Atrenta Spyglass was evaluated but similar tools were also evaluated for comparison purpose.

The purpose of this master thesis was to evaluate the need of implementing a rule checking tool in the design flow at the Digital ASIC department PDU Base Station development in Kista, who also was the commissioner for this project.

Based on the findings in this project it is recommended that a static rule checking tool is introduced in the design flow at the ASIC department. However, in order to determine which of the different tools the following pointers should be regarded:

• If the tool is only going to be used as for lint checks (elementary structure and code checks) on RTL, then the implementation of Mentors Design Checker is advised.

• If the tool is going to be used for more sophisticated structural checks, clock tree/reset tree propagation, code checks, basic constraints checks, basic Clock Domain Crossings (CDC) checks, then Synopsys LEDA is advised.

• If the tool is going to be used as for advanced structural checks, extensive clock tree/reset tree propagation, code checks, constraints checks, functional Design For Test (DFT) checks (as testmode signal propagation) and functional CDC checks on RTL as well as on netlist level, then Atrenta Spyglass is advised.

The areas regarding checks that could be of interest for Ericsson is believed to be regular lint checks for RTL (naming, code and basic structure), clock/reset tree propagation (netlist and RTL), constraints and functional DFT checks (netlist and RTL).
Source: Linköping University
Author: Wickberg, Fredrik

Download Project

>> 100+ Easy Electronics Projects for Engineering Students

>> Wireless Communication Projects for Students

Similar Projects:

For Free ECE/EEE Project Downloads:

Enter your email address:
( Its Free 100% )

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>