New Horizons

Welcome to my blog

My name is Sven Andersson and I
work as a consultant in embedded
system design, implemented in ASIC
and FPGA.
In my spare time I write this blog
and I hope it will inspire others to
learn more about this fantastic field.
I live in Stockholm Sweden and have
my own company

Contact

You are welcome to contact me
and ask questions or make comments
about my blog.

Before we start synthesizing the design, let's make sure we have a clean design that won't give us any problems. We will use the HDL Analysis and Lint (HAL) tool from Cadence to check our design. There are other tools available like, Spyglass from Atrenta, Indigo RTL Analysis from Blue Perl Software and Leda from Synopsys. We will use HAL because it is an efficient tool and it is part of the Incisive HDL simulator toolbox.

Using HAL

The first thing we will do is to read the HAL user guide to find out more about the program.To open the user guide execute the following command: xpdf /cadence_install_dir/doc/hal/hal.pdf &I have problems using the Cadence documentation system cdsdoc. I much prefer to read the pdf files using a standard PDF viewer like xpdf. To read the HAL reference manual use the following command: xpdf /cadence_install_dir/doc/halref/halref.pdf &

Introduction

This text is taken from the HAL user guide: "Functional closure in the ever-shrinking design cycles is achievable only by catching issues as early and as rapidly as possible. Design verification engineers need detection of problems related to multiple phases of design cycle, while the design is still under development at the RTL level. Such early warnings are a key to avoiding the expensive design iterations, and meeting quality and time-to-market goals. HAL checks the design for:

Design consistency, reusability and portability

Semantic correctness

Synthesizability

Testability and more"

Beautiful words let's see how good it is in reality. The flow diagram shows the two ways you can use HAL. The snapshot-based flow and the source file-based flow. We will use the snapshot-based flow.

Here is the complete HAL flow:

Compile the design blocks into a library (design)

Elaborate the design and save the result in a snapshot file (ETC_snapshot)

Start hal using the following command: hal design.ETC_snapshot

HAL will execute and the result will be stored in a log file: hal.log

To analyze the result start ncbrowse using the following command: ncbrowse -sortby severity -sortby category -sortby tag hal.log

We can use Mongoose (see Zoo Design Platform) to run the HDL analysis using HAL. But before we do let's save the current setup using the Load/Save Setup window.

We will save the current setup in the file ETC_simulation.setup and then create a new setup called ETC_analysis.setup to be used during the HAL runs. When we want to return to the simulation setup we will load ETC_simulation.setup and everything in Mongoose will be restored. This way we can handle a new task in Mongoose without interfering with other tasks.

This time we will only elaborate the design files and exclude the testbench. Let's change the top entity to ETC and give a name to the snapshot file : ETC_snapshot.

Oophs! 2 errors and 2082 warnings. That's a lot of errors and warnings. Let's open the NCBrowse tool to analyze what is going on. Use the command: ncbrowse -sortby severity -sortby category -sortby tag hal.log &. Why not add this command to a user defined button. See previous chapter for a description.

A look at the log file reveals that the Xilinx memory is a behavioral verilog model that generates the two errors and many of the warnings we see. We have to exclude the memory from the analysis by adding this code in the design_info file (see HAL User Guide):bb_list { designunit = ETC_DUAL_PORT_1024x32; file = /home/svenand/root/projects/ETC/design/ETC_DUAL_PORT_1024x32.v; }

This code will blackbox the memory and everything inside the memory block. When we rerun hal with the design_info file included we get the following result:

We have go through the remaining warnings and see which ones can be ignored and which ones we have to investigate further.

Warning

Description

Comment

Ignored

BITUSD

Unused bits inside a always block

No

CDEFCV

Redundant default clause used

No

CNSTLT

Literal '3'b1' should be replaced with a constant

Yes

CTLCHR

Control characters in the source code found (tabs)

Yes

DIRRNG

Inconsistent ordering of bits [0:31]

OPB bus swapped

Yes

IMPTYP

Implicit type conversion

No

LCVARN

Uppercase characters used for names

I prefer upper case

Yes

MAXLEN

Lines too long (more than 80 charcters)

Yes

MPCMPE

Complex expressions, should add parentheses

No

NESTIF

A nested if, in which the same variable is used in if comparisons, has been detected

No

NETDCL

Declarations made prior to non-declarative statements

I will move the parameter statements

No

NOBLKN

Always blocks not labeled

Yes

POIASG

Overflow not verified

Counters will always wrap-around

Yes

SEPLIN

Use a separate line for each HDL statement

Yes

STYVAL

Numeric value used for identifier

Yes

UCCONN

Lowercase characters used for identifier

Yes

URDPRT

Unconnected port

No

HAL setup window:

After disabling the warnings we decided to ignore, here is the final result. I will take a closer look at these warnings and make the changes needed to get the design to pass HDL analysis.We are then ready for the final synthesis run.