Effective VIM Editor tips, tricks and plugins to improve coding speed in VLSI

One of our colleagues always had to struggle with the Verilog / SystemVerilog syntax. Whenever he opens a .sv file he needs to set the syntax manually as ":set syntax=verilog". This really kills time, especially when you are working on a project with tight schedules. 

So today we are sharing a bunch of good tricks and different plugins that will help you code efficiently, whether Verilog, System Verilog, UVM or scripting languages like Perl. 

VIM editor is so powerful that everything can be modified using the keyboard. No need to raise a hand to reach out to the mouse. Thus the efficiency of working improves a lot and also looks more professional.

By default, vim invokes .vimrc every time a new file is opened. So we may configure any settings upfront in ~/.vimrc for making life easy while working with files.

We will start with basic keyboard shortcuts which will help us to work faster than the actual way.

Opening a fine using GVIM

To open any file from shell type :

gvim <filename>

By default, vim invokes .vimrc every time a new file is opened. So we may configure any settings upfront in ~/.vimrc for making life easy while working with files.

if you want to open multiple files in tab pages

gvim -p <filename1> <filename2> ..

if you want to open multiple files in horizontal windows

gvim -o <filenames>

if you want to open multiple files in vertical windows

gvim -O <filenames>

Shortcuts for moving the cursor:

h - move left

j - move down

k - move up

l - move right

Shortcuts for quick editing:

Letter level

r - quickly replaces the letter under the cursor.

i - change to insert mode. (ready for typing from before the cursor position) Esc to come out of insert mode.

I - change to insert mode at the start of a line.

a - change to append mode. (ready for typing after the cursor position), type ESC to come out of append mode.

A - change to append mode at the end of the line.

x - deletes the alphabet under the cursor and starts deleting the forward direction.

X - exactly like the backspace function.

o - change to insert mode on the next line.

O - change to insert mode on the previous line.

f - find a letter in the forward direction of a line.

F - find a letter in the backward direction of a line.

Word Level

w - move to the start of one word at a time.

      You can put any number upfront to move that many words

      Eg: 5w - From 1st word jumps to the start of 6th word.

b - move to the beginning of the word at a time.

e - move to the end of one word at a time.

y - yanks (that means you can copy a word till the end of a word, or a line, etc by using commands ye, yw, yy, etc)

p - paste whatever is yanked after the cursor

P - paste whatever is yanked before the cursor

d - deletes (that means you can delete a word till the end of a word, or a line, etc by using commands de, dw, dd, etc)

D - deletes from the cursor position to the end of the line.

0 - Go to the start of the Line.

Other General commands with keys

u - undo

gg - Go to the start of the file

G -  Go to the end of the file

ZZ - write, save and close the file

H - Head of the file in the visible pane

M - Middle of the file in the visible pane.

L - Last of the file in the visible pane.

v- enter visual mode from the alphabet under the cursor.

V - enter visual mode from the line under the cursor.

Advanced commands :

q - recording (will explain this in detail)

/ - search a word (eg : /<pattern>)

n- searches any word in forwarding direction

N - searches any word in the backward direction

. - repeats the last done job again.

? - for searching a word backward (more powerful than / )

Other General commands with additional keys

ctrl + e - scroll in forward direction

ctrl + p - scroll in backward direction

ctrl + r - redo

ctrl + a - increment the number in the line.

ctrl + x - decrement the number in the line.

ctrl + q or ctrl + v, enter visual mode in the column.

Shift + ~ - Invert the text case under the cursor

Vu  - if you want to convert the whole line of text under the  cursor to a Lowercase line

VU - if you want to convert the whole line of text under the  cursor to an Uppercase line

In gvim by typing ":" we enter into command line mode, we have a specific set of commands to use at this level.

How do I switch between panes in a split mode in Vim/GVIM ??

In command mode, hit Ctrl-W and then a direction, or just Ctrl-W again to switch between panes.

:b <number>  will open the specified buffer in the current pane.

Example  : UNIX > vim test_1 test_2 ; #  This command opens two test_1 and test_2 files

But in vim, we can see only one file(by default the first file test_1) with this approach.

If want to go to the test_2 file then use :b 2

:ls will show your open buffers

If we opened multiple vim files like above and want to know which are in buffer use this command

and with the help of :b <number>, we can switch between files

If we open many windows in vim/gvim  and you want to have equal window size for all split pans

Esc mode  Ctrl+W =

For more info type:

:help window-resize

you can use <ctrl> + w + w To switch the panes in order.

A suggested way is to put these codes in your vimrc file

map <C-j> <C-W>j

map <C-k> <C-W>k

map <C-h> <C-W>h

map <C-l> <C-W>l

How to remove blank lines from a file?

Here's a handy one-liner to remove blank lines from a file.

           :g/^$/d

Breaking this down. The "g" will execute a command on lines that match a regular expression.

The regular expression matches blank lines, and the command is "d" (delete).

You can also use

           :v/./d

(v means complementary, so any line that doesn’t have a single character at least will be deleted)

How to implement AUTO-COMPLETION 

Ctrl+p   to insert the previous matching word

Ctrl+n  to insert the next matching word

Ctrl +x  followed by Ctrl+l to complete a whole line from the buffer

(basically ctrl + x pressing will open a sub-mode from there on we can do a lot of stuff.

for example ctrl + l in submodel gives you to complete the whole line )

More content coming soon ....

Useful Vim plug-in for efficient coding in Perl

Think of a plug-in with which you can do the following while coding a Perl script:

• Auto addition of file header
• Easy addition of function/frame comment
• Quick inclusion of default code snippet
• Performing syntax check
• Reading documentation about a function
• Converting a full code block to comment, and vice versa
• Help to speed up the code writing with consistency in coding.

One-stop solution for all these things is a perl-support vim plug-in

The Perl-Support Vim Plugin – Perl-IDE offers the easiest way to do all of the above, saving a lot of time and keystrokes.

We have already discussed in an earlier article regarding Use of Scripting languages in VLSI

We will be covering the following in this article

1. How to install perl-support plugin to use it with VIM.

2. Powerful features of the Perl-support plugin.

Steps to install Perl-Support VIM Plug-in

1. Download the plugin from the vim.org website.

Click here to download to go to the download page

Alternatively use below command

cd /usr/src/
wget http://www.vim.org/scripts/download_script.php?src_id=9701

2. Copy the zip archive perl-support.zip to $HOME/.vim and run below command

  unzip perl-support.zip

This command will create following files:

  $HOME/.vim/autoload/mmtemplates/...

  $HOME/.vim/doc/...

  $HOME/.vim/plugin/perl-support.vim

3. Loading of plug-in files must be enabled in $HOME/.vimrc. If not use previously

  filetype plugin on

Create .vimrc if there is none or use the files in $HOME/.vim/perl-support/rc as a starting point.

After done with installation lets get to know about

The Powerful Features of Perl-support

1. Add Automatic Header to *.pl file whenever you create a new file

2. Insert statements

3. Insert frequently used statements

4. Insert special variables

5. insert code snippets and manage templates

6. Run a profiler

7.  Run the script, check the syntax, start the debugger

8. Make integration

Details of all these can be found at 

https://wolfgangmehner.github.io/vim-plugins/perlsupport.html

Latch Up In CMOS

What is latch up in CMOS design and ways to prevent it?

A Problem which is inherent in the p-well and n-well processes is due to relatively large number of junctions which are formed in these structures, the consequent presence of parasitic diodes and transistors.

Latch-up is a condition in which the parasitic components give rise to the Establishment of low resistance conducting path between VDD and VSS with Disastrous results

Latch-up may be induced by glitches on the supply rails or by incident radiation.

Latch-up pertains to a failure mechanism wherein a parasitic thyristor (such as a parasitic silicon controlled rectifier, or SCR) is inadvertently created within a circuit, causing a high amount of current to continuously flow through it once it is accidentally triggered or turned on. Depending on the circuits involved, the amount of current flow produced by this mechanism can be large enough to result in permanent destruction of the device due to electrical overstress (EOS).

Preventions for Latch-Up

• by adding tap wells, for example in an Inverter for NMOS add N+ tap in n-well and connect it to Vdd, and for PMOS add P+ tap in p-substrate and connect it to Vss.
• an increase in substrate doping levels with a consequent drop in the value of  Rs.
• reducing Rp by control of fabrication parameters and by ensuring a low contact resistance to Vss.
• and the other is by introducing of guard rings.....

Latchup in Bulk CMOS

A byproduct of the Bulk CMOS structure is a pair of parasitic bipolar transistors. The collector of each BJT is connected to the base of the other transistor in a positive feedback structure. A phenomenon called latchup can occur when (1) both BJT's conduct, creating a low resistance path between Vdd and GND and (2) the product of the gains of the two transistors in the feedback loop, b1 x b2, is greater than one. The result of latchup is at the minimum a circuit malfunction, and in the worst case, the destruction of the device.

  Cross section of parasitic transistors in Bulk CMOS

 Equivalent Circuit

Latchup may begin when Vout drops below GND due to a noise spike or an improper circuit hookup (Vout is the base of the lateral NPN Q2). If sufficient current flows through Rsub to turn on Q2 (I Rsub > 0.7 V ), this will draw current through Rwell. If the voltage drop across Rwell is high enough, Q1 will also turn on, and a self-sustaining low resistance path between the power rails is formed. If the gains are such that b1 x b2 > 1, latchup may occur. Once latchup has begun, the only way to stop it is to reduce the current below a critical level, usually by removing power from the circuit.

The most likely place for latchup to occur is in pad drivers, where large voltage transients and large currents are present.

Preventing latchup

Fab/Design Approaches:

1. Reduce the gain product b1 x b1

• move n-well and n+ source/drain farther apart increases width of the base of Q2 and reduces gain beta2 ­> also reduces circuit density
• buried n+ layer in well reduces gain of Q1

    2. Reduce the well and substrate resistances, producing lower voltage drops

· higher substrate doping level reduces Rsub

· reduce Rwell by making low resistance contact to GND

· guard rings around p- and/or n-well, with frequent contacts to the rings, reduces the parasitic resistances.

CMOS transistors with guard rings

Systems Approaches:

1. Make sure power supplies are off before plugging a board. A "hot plug in" of an unpowered circuit board or module may cause signal pins to see surge voltages greater than 0.7 V higher than Vdd, which rises more slowly to is peak value. When the chip comes up to full power, sections of it could be latched.
2. Carefully protect electrostatic protection devices associated with I/O pads with guard rings. Electrostatic discharge can trigger latchup. ESD enters the circuit through an I/O pad, where it is clamped to one of the rails by the ESD protection circuit. Devices in the protection circuit can inject minority carriers in the substrate or well, potentially triggering latchup.
3. Radiation, including x-rays, cosmic, or alpha rays, can generate electron-hole pairs as they penetrate the chip. These carriers can contribute to well or substrate currents.
4. Sudden transients on the power or ground bus, which may occur if large numbers of transistors switch simultaneously, can drive the circuit into latchup. Whether this is possible should be checked through simulation.

Get free daily email updates!

Follow us!

Do U Know? Mobile devices said to consume more energy on storage tasks

Do u know that “Flash storage takes power to write - a 20 volt jolt to each cell - but needs almost none to maintain. The real power hog is the inefficient storage software stack that eats 200 times the power required for the hardware.”

Given the always-on mobile infrastructure - background updates, instant messages, email, updates, file sync, logging and more - lots of background storage I/O is happening all the time. And it's eating your device's power budget.

Researchers from Microsoft and the University of California at San Diego benchmarked how Android and Windows RT mobile devices used energy for storing data. They focused on activities that occur with the screen off, since displays are a major power consumer when lit. "Measurements across a set of storage-intensive micro benchmarks show that storage software may consume as much as 200x more energy than storage hardware on an Android phone and a Windows RT tablet," the research team wrote in a paper. "The two biggest energy consumers are encryption and managed language environments."

Results
On Windows RT they found that the OS/CPU/DRAM overhead was between 5 and 200 times the power used by the flash storage itself, depending on how DRAM power use was allocated. File system APIs, the language environment and encryption drove the CPU power consumption during I/O. Full disk encryption - protecting user data - incurred 42 percent of CPU utilization.

On an Android phone, the encryption penalty is even worse: 2.6–5.9x more energy per KB over non-encrypted I/O.

For applications, the team found that on Windows RT, the energy overhead in a managed environment is 12.6–18.3 percent while overhead on Android is between 24.3–102.1 percent. It appears that Android's algorithms are not optimized for application I/O power efficiency.

Assertion Debugging in Questa – few tips

Playing around debugging some complex assertions in Qeusta? Here are some tips:

1. Use vsim –assertdebug

2. Add –novopt for trivial code containing assertions + stim alone as otherwise many signals get optimized away. On real designs, perhaps you are better off with +acc* (Read doc for more)

3. Once the GUI comes up, the assertions are not listed in its own browser – ideally I would have liked to see a menu item under “Tools” menu. But it is hidden under “View –> Coverage –> Assertions” – GOK why! (GOK – God Only Knows)  :)

4. Before starting simulation, enable ATV

5. After sim one can do “view ATV” for advanced debug!

 

Get free daily email updates!

Follow us!

ModelSim VS QuestaSim

We as an ASIC Engineer are frequently using different simulators for our simulation activity. At present time we are frequently using modelsim/Questa and vcs. These are the industry popular and well proven simulators.
We have seen people who are using modelsim / Questa simulator from Mentors but dont really know the exact difference between them.
We have captured some difference between Questa and Modelsim. Though both are simulators from the Mentor Graphics there are some differences between them. Below are the differences We captured :

ModelSim is Mentor Graphics HDL simulator. Questa is Mentor Graphics advanced verification platform that uses ModelSim as its core simulation engine.

Features of the two tools can be grouped into five categories and compared as follows:

1. Language Support
- ModelSim supports SystemVerilog IEEE 1800 for Design only, as well as VHDL (1987, 1993, 2002), Verilog (1995, 2001, 2005), as well as options for mixed language and language neutral licensing and support for SystemC 2.2 IEEE 1666/OSCI 2.2.
- Questa supports all of this as well as SystemVerilog IEEE 1800 for Verification, mixed language licensing (Questa is by default language neutral), PSL IEEE 1850, and SystemC 2.2 IEEE 1666/OSCI 2.2 as standard features.

2. Simulation
- ModelSim supports a single-kernel simulation engine, Verilog RTL & gate level performance optimizations, VHDL RTL & VITAL performance optimizations, performance and memory profiler, separate elaboration, waveform management tool set, VCD and extended VCD support, VCD re-simulation, batch mode simulation, integrated simulation, checkpoint & restore,
- Questa’s simulation support is identical to ModelSim’s

3. Design Entry, Debug, and Analysis
- ModelSim supports an HDL editor, integrated project manager, source code templates and wizards, interactive and post-simulation debug, dataflow graphical and textual causality traceback, source annotation, memory window, extra standalone viewer, multiple waveform windows, waveform compare, C Debugger and transaction viewing for SystemC.
- Questa supports all of this and the C debugger and transaction viewing for SystemC and SystemVerilog are standard parts of the product.

4. Advanced Verification Methods
- ModelSim does not support any advanced verification features.
- Questa supports assertion-based verification (including a library of pre-written assertions called Questa Verification Library or QVL, and an assertion thread debugger), automated test stimulus generation via a constraint solver engine, and PowerAware RTL verification supporting both CPF and UPF formats.

5 Verification Management and Coverage
- ModelSim supports Code Coverage (it is included in ModelSim SE, and an option to other versions of ModelSim).
-Questa supports code coverage along with functional coverage, a unified coverage database (UCDB), coverage viewing, test ranking, and test plan tracking

Hope you find this information useful.

Get free daily email updates!

Follow us!

Modelsim Tips and Tricks

1. How to get rid of Std Arithmetic warnings around 0 ns?

# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, the result will be 'X'(es).
#    Time: 0 ns  Iteration: 1  Instance: /cordic_tb/uut/add3

Simply turn the Std checking off in your  .do or .tcl script file, example:

set StdArithNoWarnings 1
run 0 ns;
set StdArithNoWarnings 0
# Continue script

2. How to get rid of Std Arithmetic warnings until my reset is asserted?

If the warnings continue until a certain time or when a signal is asserted then the when statement can help out.

Example: the Std warnings can be ignored until the signal reset_s is asserted

when -label enable_StdWarn {reset_s == '1'} {echo "Enable StdArithWarnings" ; set StdArithNoWarnings 0 ;}

Example: the Std warnings can be ignored until 3800 ns

when -label enable_StdWarn {$now == @3800 ns} {echo "Enable StdArithWarnings" ; set StdArithNoWarnings 0 ;}

3. How to stop the simulator without using asserts?

The usual way to stop the simulator is to use the assert statement in VHDL. However, not everybody likes the Failure/Error message in the transcript window.

# ** Failure: End of Simulation
#    Time: 360 ns  Iteration: 0  Process: /test_tb/line__35 File: test_tb.vhd

An easy solution is the same construct as shown above. Simple add a signal to your testbench and assert this signal at the end of the simulation. Then use the when statement in your script to stop the simulator.

Example: stop the simulator when the signal end_of_simulation='1'

when -label end_of_simulation {end_of_sim == '1'} {echo "End of simulation" ; stop ;}

# End of simulation
# Simulation stop requested

Note: for maximum portability to other simulators the assert statement is recommended method!

4. How to speed up simulation/reduce wlf file size?

There are many ways to speed up simulation. If you are performing long simulation you can speed up the simulation by turning off the signal logging to the wlf file until you reach the time of interest.

Example: Disable signal logging until time 4420 us

nolog -all
when -label start_logging {$now == @4420 us} {echo "Start logging " ; log -r *;}

Tip: how to find out what a ModelSim error message means

Error messages and exit codes are described in the User's Manual, however a quick way to get this information is to use the verror command. Simply type verror #error_number to get a detailed description on the error number.

Related Posts:

1. Customize the ModelSim Wave View in the Xilinx ISE Simulation
2. Compiling Xilinx library for ModelSim simulator

Keep Environment Variables when Using SUDO

Recently we were developing a script in perl where we need to specify the environment variable UVM_LIBRARY_PATH = ../examples/UVM1.10, but when we run the code with sudo script/server, it doesn't run because that library path is not in root's env.

Its very easy to keep the env variables even while running the script with SUDO. All you need to do is modify your /etc/sudoers file

search following lines

Defaults    env_reset
Defaults    env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR \
                        LS_COLORS MAIL PS1 PS2 QTDIR USERNAME \
                        LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION \
                        LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME
                        LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS \
                        _XKB_CHARSET XAUTHORITY"

Add env variable eg. UVM_LIBRARY_PATH. in our case we have

Defaults    env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR \
                        LS_COLORS MAIL PS1 PS2 QTDIR USERNAME \
                        LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION \
                        LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME
                        LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS \
                        _XKB_CHARSET XAUTHORITY UVM_LIBRARY_PATH"

Save your file and run the script.

Get free daily email updates!

Follow us!

Linux/Unix - Search and remove files with one find command on fly

Some time it is necessary to find out files and remove them as we need to do today. However, rm command does not support search criteria.

However, with find command you can search for files in a directory and remove them on fly.

You need to combine find and rm command together.

Fortunately find command makes this operation quite easy.

You can use find command as follows:

find . -type d -print | grep <file_name/dir_name> | xargs -n1 rm -rf

Get free daily email updates!

Follow us!

6 Ways to Improve Chip Yield Even Before the Project Starts

Early on in Chip projects, yield is not taken very seriously. The common thinking goes –  anyhow there isn’t much to do as this early point of time. However, there are actually several things you can do even before the Chip design starts, which will translate to clear savings.

1- Know your Yield

Yield has a great deal of impact only if production volume is high. If you plan to manufacture only a few tens of thousands of components, perhaps yield is not the most important topic in your project’s plan.

Yield can be roughly calculated or estimated before the project has even started. Yet, if you have calculate a yield target of 95% there is no reason to invest money and efforts to try improving the yield from (the calculated) 95% to 99% because that would not be possible.  Therefore, it is important that you have calculated your yield and set that as a goal.

2- Consider Foundry Applicability

Semiconductor foundries are not taking any yield losses. It is not the fab responsibility whether your yield is high or low because they sell wafers and not dies. Therefore you should select the foundry the suits best to your Chip domain.

If you chip requires small node geometries go to GLOBALFOUNDRIES, TSMC etc. If you chip needs excellent RF performance go to: IBM, TowerJazz etc. The foundry can help you calculating the wafer yield based on their own process technology. If you can provide them with die size, number of layers, process node and options, they should be able to provide you with a very accurate yield figures for your project.

3- Match Design Team Experience to Your Project

If you have decided to outsource the frond-end and physical design activities to an external vendor, the main yield-related risk here is experience. If the design team does not have the relevant experience that matches your chip project (for instance: RF, High Voltage) you are really wasting your time. Don’t hire analog designer without high voltage experience if you need to design a 120V chip.

4- Select Silicon Proven IPs

More and more companies are shopping for Semiconductor IPs to help reduce time to market and minimize engineering cost. There are many IP vendors with high quality products and some with lower quality. The keyword here is risk minimization. You really want to make sure the IP blocks you are about to purchase and integrate into your chip are bug free and have been silicon proven and qualified for your process. Ask for test results and references.

5- Follow Package Design Rules

For simple QFN packages there are no real concerns besides following the assembly house design rules. However complex packages can reduce yield dramatically. If your chip uses a package that consists of a multilayer substrate with high speed signals, this substrate should be considered as part of the silicon die. Improper routing of high speed signals, for example, will make the substrate performance very marginal and thus result in failures during final test.

6 – Say No to Tight Test Limits, Say Yes to Better Hardware

The only place to measure yield is at the testing phase. And this is done by the ATE.

Great ASIC engineers often try to over-engineer the chip design and as a by-product also tighten up the test result criteria. These limits will have direct impact on your profit. Every device that fails to meet limits during the screening process will be scraped. Therefore, don’t create the perfect test specification. Make one that meets your system requirements.

Loadboards, sockets and probecards have different quality levels and therefore different cost. But since these are the actual physical interface between your chip and the tester, you want to make sure they have the right quality and durably to allow solid connectivity to the tester during the test period. Otherwise, lower quality hardware will shave off your yield figures. Sockets for example, have limited number of insertions; you therefore should buy a socket that meets your chip production volume. Bottom-line — don’t compromise on the quality of the hardware interfacing your chip.

There is so much more to write on this topic, we promise to write more articles in the future. Stay tuned.

Get free daily email updates!

Follow us!

How to read an NGC netlist file

For the occasions that you find yourself with a netlist file and you don’t know where it came from or what version it is, etc. this post is about how you can interpret the netlist file (ie. convert it into something readable).

Today I found myself with two netlists and I needed to know if they were the same. Yes of course you can try comparing the two files with a program such as Beyond Compare, but if the netlists were compiled on separate dates, you will have trouble recognizing this from the raw binary data. The best thing to do in this case is to convert the netlists to EDIF files, a readable, text file version of the netlist. Another option is to convert the netlists into VHDL or Verilog code. Here is how you can do this:

To convert a netlist (.ngc) to an EDIF file (.edf)

1. Get a command window open by typing “cmd” in the Start->Run menu option in Windows. If you use Linux, open up a terminal window.
2. Use the “cd” command to move to the folder in which you keep your netlist.
3. Type “ngc2edif infilename.ngc outfilename.edf” where infilename and outfilename correspond to the input and output filenames respectively.
4. Open the .edf file with any text editor to view the netlist.

To reverse engineer a netlist with ISE versions older than 6.1i

1. Convert the netlist to an EDIF file using the above instructions.
2. Type “edif2ngd filename.edf filename.ngd” to convert the EDIF file into an NGD file (Xilinx Native Generic Database file).
3. To convert the netlist into VHDL type “ngd2vhdl filename.ngd filename.vhd“.
4. To convert the netlist into Verilog type “ngd2ver filename.ngd filename.v“.

To reverse engineer a netlist with ISE versions 6.1i and up

1. To convert the netlist into VHDL type “netgen -ofmt vhdl filename.ngc“. Netgen will create a filename.vhd file.
2. To convert the netlist into Verilog type “netgen -ofmt verilog filename.ngc“. Netgen will create a filename.v file.

Now you should have all the tools you need to read an NGC netlist file.

Get free daily email updates!

Follow us!

Creating a simple FPGA Project with Xilinx ISE

We would like to write this post for our friends who wants to create a simple FPGA Project with Xilinx ISE. 

Software

Xilinx ISE as a software package containing a graphical IDE, design entry tools, a simulator, a synthesizer (XST) and implementation tools. Limited version of Xilinx ISE (WebPack) can be downloaded for free from the Xilinx website.

It is not mandatory to use Xilinx software for all tasks (for example, synthesis can be done with Synplify, simulation - with Modelsim etc.), but it is the easier option to start off.

The information in this article applies to Xilinx ISE version 9.2.03i, but other versions (since 8.x) shouldn't be very different. If your version is older than 8.x, you'd better upgrade.

Creating a project

To create a project, start a Project Navigator and select File->New Project. You will be asked for project name and folder. Leave "top-level source type" as HDL.

Now we should choose a target device (we will use a Spartan-3A xc3s50a device as an example) as well as set up some other options:

The Project Navigator window contains a sidebar, which is on the left side by default. The upper part of this sidebar lists all project files, and the lower part lists tasks that are applicable for the file selected in the upper part.

Design Entry

Now, let's add a new source file to our project. We'll start from a simple 8-bit counter, which adds 1 to its value every clock cycle. This counter will have the following ports:

• CLK - input clock signal;
• CLR - input asynchronous clear signal (set counter value to 0);
• DOUT - output counter value (8-bit bus).

We'll define our counter as a VHDL module. VHDL language will be covered in more details in further chapters.

To create a new source file, choose "Create New Source" task and select "VHDL module" source type. The name of our module will becounter.vhd. Then you will be asked which module to associate the testbench with; choose counter.

Let's write the following code in counter.vhd:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity counter is
    Port ( CLK : in  STD_LOGIC;
           CLR : in  STD_LOGIC;
           DOUT : out  STD_LOGIC_VECTOR (7 downto 0));
end counter;

architecture Behavioral of counter is

signal val: std_logic_vector(7 downto 0);

begin

process (CLK,CLR) is
begin
    if CLR='1' then
        val<="00000000";
    elsif rising_edge(CLK) then
        val<=val+1;
    end if;
end process;

DOUT<=val;

end Behavioral;

ISE inserted library and ports declarations automatically, we only need to write an essential part of VHDL description (inside thearchitecture block).

To check VHDL syntax, select "Synthesize - XST => Check Syntax" task for our module.

Simulation

In order to check that our code works as intended, we need to define input signals and check that output signals are correct. It can be done by creating a testbench.

To create a testbench for our counter, select "Create New Source" task, choose "VHDL Test Bench" module type and name it, for instance, counter_tb.vhd.

VHDL test bench is written in VHDL, just like a hardware device description. The difference is that a testbench can utilize some additional language constructs that aren't synthesizable and therefore cannot be used in real hardware (for example wait statements for delay definition).

In order for testbench file to be visible, choose "Behavioral Simulation" in the combobox in the upper part of the sidebar.

ISE automatically generates most of the testbench code, we need only to add our "stimulus":

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_unsigned.all;
USE ieee.numeric_std.ALL;

ENTITY counter_tb_vhd IS
END counter_tb_vhd;

ARCHITECTURE behavior OF counter_tb_vhd IS

    -- Component Declaration for the Unit Under Test (UUT)
    COMPONENT counter
    PORT(
        CLK : IN std_logic;
        CLR : IN std_logic;         
        DOUT : OUT std_logic_vector(7 downto 0)
        );
    END COMPONENT;

    --Inputs
    SIGNAL CLK :  std_logic := '0';
    SIGNAL CLR :  std_logic := '0';

    --Outputs
    SIGNAL DOUT :  std_logic_vector(7 downto 0);

BEGIN

    -- Instantiate the Unit Under Test (UUT)
    uut: counter PORT MAP(
        CLK => CLK,
        CLR => CLR,
        DOUT => DOUT
    );
    -- Clock generation   
    process is
    begin
        CLK<='1';
        wait for 5 ns;
        CLK<='0';
        wait for 5 ns;
    end process;

    tb : PROCESS
    BEGIN

        CLR<='1';
        wait for 100 ns;

        CLR<='0';

        wait; -- will wait forever
    END PROCESS;

END;

We have added the clock generation process (which generates 100MHz frequency clock) and reset stimulus.

Now select a test bench source file and apply "Xilinx ISE Simulator => Simulate Behavioral Model" task. We should get something like this:

It can be seen that our counter works properly.

Synthesis

The next step is to convert our VHDL code into a gate-level netlist (represented in the terms of the UNISIM component library, which contains basic primitives). This process is called "synthesis". By default Xilinx ISE uses built-in synthesizer XST (Xilinx Synthesis Technology).

In order to run synthesis, one should select "Synthesis/Implementation" in the combobox in the upper part of the sidebar, select a top-level module and apply a "Synthesize - XST" task. If the code is correct, there shouldn't be any pproblems during the synthesis.

Synthesizer report contains many useful information. There is a maximum frequency estimate in the "timing summary" chapter. One should also pay attention to warnings since they can indicate hidden problems.

After a successful synthesis one can run "View RTL Schematic" task (RTL stands for register transfer level) to view a gate-level schematic produced by a synthesizer:

Notice that an RTL schematic in question contains only one primitive: a counter, which is directly an element from the UNISIM library.

Synthesizer output is stored in NGC format.

Implementation

Implementation design flow

1. Translate - convert NGC netlist (represented in the terms of the UNISIM library) to NGD netlist (represented in the terms of the SIMPRIM library). The difference between these libraries is that UNISIM is intended for behavioral simulation, and SIMPRIM is a physically-oriented library (containing information about delays etc.) This conversion is performed by the program NGDBUILD and is rather straightforward. The main reason for it to be included is to convert netlist generated by different design entry methods (e.g. schematic entry, different synthesizers etc.) into one unified format.
2. Map is a process of mapping the NGD netlist onto the specific resources of the particular device (logic cells, RAM modules, etc.) This operation is performed by the MAP program with resutls being stored in NCD format. For Virtex-5 MAP also does placement (see below).
3. Place and route - as can be inferred from its name, this stage is responsible for the layout. It performs placement (logic resources distribution) and routing (connectivity resources distribution). Place and route is performed by a PAR program. For Virtex-5 devices, though, placement is performed by MAP program (and routing still by PAR program). The output of PAR is stored, again, in NCD format.

Implementation Constraints

Constraints are very important during the implementation. They define pin assignments, clocking requirements and other parameters influencing implementation. Constraints are stored in UCF format (user constraints file).

In order to add constraints one need to add a new source (using "Create New Source" task) and choose "Implementation constraints file" source type. UCF file is a text file that can be directly edited by a user, however, simple consraints can be defined with graphical interface.

When a constraints file is selected in the upper part of the sidebar, the specific tasks become available. These include "Create Timing Constraints" and "Assign Package Pins".

For example, if we specify a frequency requirement on CLK as 100 MHz, the corresponding section of the constraints file will be:

NET "CLK" TNM_NET = CLK;
TIMESPEC TS_CLK = PERIOD "CLK" 100 MHz;

When timing requirements are specified in the constraints file, the implementation tools will strive to meet them (and report an error in the case it can't be met).

Package pins constraints must also be set (according to the board layout).

MAP program converts UCF constraints to the PCF format which is later used by PAR.

There are also synthesis constraints stored in XCF files. They are used rarely and shouldn't be confused with implementation constraints.

Programming file generation

After placement and routing, a file should be generated that will be loaded into the FPGA device to program it. This task is performed by a BITGEN program.

The programming file has .bit extension.

The programming file is loaded to the FPGA using iMPACT.

Get free daily email updates!

Follow us!

Customize the ModelSim Wave View in the Xilinx ISE Simulation

When ModelSim is automatically lunched within the ISE environment it  just displays the top entity level signals in the Wave View window. However, to either facilitate debugging tasks or check specific behavior of lower level components most of the time internal signals also need to be displayed in the Wave View window of ModelSim. Moreover, coloring, ordering and grouping signals  is especially useful in complex designs. Hence, having one or several custom views and invoking them automatically will help the verification job.

Scripts files (.do) created in ISE

When ModelSim is launched from the Xilinx ISE, Project Navigator automatically creates a .do script file that contains all of the necessary commands to compile the .vhd  source  files, load, start  and run the
simulation in ModelSim.
The .do script file created by Project Navigator has different extensions based on the type of simulation launched. For instance, for a Behavioral (functional) Simulation these are the three files created:

<TestBenchName>.fdo           ModelSim commands for behavioral simulation
<TestBenchName>.udo           ModelSim user commands
<TestBenchName_wave>.fdo  ModelSim Wave window format commands for behavioral simulation

A detail of the ModelSim commands in a <TestBenchName>.fdo script file created by Project Navigator, when running a Behavioral Simulation, is described below:

The <TestBenchName>.fdo script file is regenerated each time a behavioral simulation is launched. Therefore, any modification done in this file will be automatically overwriting. Still, in this script file there is a command line, do{<TestBenchName_wave>.fdo}, that invokes the <TestBenchName_wave>.fdo script file. This script file never is neither modified nor overwritten by Project Navigator. Hence, the best file that can be used to customize the Wave window format in the ModelSim environment is the <TestBenchName_wave>.fdo script file. By default, this file has the following structure:

The ‘add wave *’ command means that, by default, all the top level entity signals will be displayed in the Wave view of ModelSim. Likewise, when running simulation after translating, mapping or PAR processes, similar script files are created. A detail of the script files created in each process is showed below:

Simulation Post-translate
<TestBenchName>.ndo            ModelSim commands for post-translate simulation
<TestBenchName>.udo            ModelSim user commands
<TestBenchName_wave>.ndo  ModelSim waves format commands for post-translate simulation

Simulation Post-Map Process
<TestBenchName>.mdo ModelSim commands for post-map simulation
<TestBenchName>.udo ModelSim user commands
<TestBenchName_wave>.mdo ModelSim waves format commands for post-map simulation

Simulation Post-PAR
<TestBenchName>.tdo ModelSim commands for post-par simulation
<TestBenchName>.udo ModelSim user commands
<TestBenchName_wave>.tdo ModelSim waves format commands for post-par simulation

In general, the script file <TestBenchName_wave>.*do will be the file to be modified to customize the Wave window in the ModelSim environment in any of the different simulation cases. As it was detailed above, the “add wave *” command states to display just the top level entity signals. However; to facilitate debugging tasks most of the time internal signals also need to be displayed in the Wave window. Moreover, coloring, ordering and grouping the signals in the Wave window is especially useful in complex designs.

Customization Process

The process to customize the Wave window in ModelSim when running the simulation flow in Xilinx ISE environment is detailed below:

1) Create a new ISE project or just open one already created. Write your VHDL code, create your test bench and execute either the functional, post-translate, post-map or post-par simulation of your design, which will open ModelSim simulation tool.

2) Within the Wave window, ModelSim offers several methods to customize the view.

• Adding internal signals: in the Instance view of ModelSim (left most pane) you can find the test bench name and underneath it, you can see the instance name of the entity under test. The instance name is actually the label used in the instantiation of the top level entity in the test bench. Click over the ‘+’ symbol to be able to see all the unit components of the top level entity. Then, select the unit that holds the signals you want to add to the Wave window by single click over the unit’s name. After that, on the Objects window (usually the window in the middle) the name of the signals of the selected unit will be displayed. Select the signal you want to add to the Wave window by single click over it, then drag and drop the signal into the Wave window. You can repeat this process and add as many signals as needed. Once a signal is added to the Wave window, you can move it up or down as explained below.
• Moving signals: it is also possible to move either up or down the signals displayed in the Wave window to facilitate reading the waveforms. For instance, you can place all the input signals on the top of all the other signals, then the control signals in the middle and the output signals at the bottom. To move up or down the signals in the Wave window, select the signal you want to move (single right-mouse click over the signal). Then, drag the signal up or down, by keeping the right-mouse button pressed and moving the mouse up or down, and drop the signal, release the mouse button, wherever you like.
• Adding dividers: signal dividers can be added in the Wave window to label the signals grouped with a specific purpose. For instance, you can add dividers labeled Input Signals, Control Signals, Rx Signals, Memory Read, Clocks, and such. To add a divider select the signal over which you want the divider. Then, right-mouse click and select ‘Insert Divider’ from the down menu. The divider dialog window will come up. You can add a name describing the function of the signals that will be under the divider. You can also set the Divider Height, though this is not usually changed.
• Coloring the waveform: for some specific purposes, for instance for a quick waveform reference among hundreds of waveforms, it is advantageous to change the color of a specific waveform as well as the color of signal name. Highlight (select) the signal that you want to change the waveform color, then right-mouse click and select Properties, the Wave Properties window should come up. In the View tab, you will find the Wave Color and Name Color selections. To change the default colors, click on the Colors button and select the desired color. When finished, click on Apply.

3) Once you are done adding signal, dividers and changing colors, it is then necessary to save this new customized Wave window format to be able to use it again:

• Be sure to select (highlight) the Wave window among the other ModelSim views.
• Go to File -> Save Format. Then, click OK in the Save Format dialog window to save the new wave format in the default directory (ISE project directory) or in the directory you would like by browsing to it. The default name is wave.do. In case you are planning to have a customized wave view for the different simulations (like functional, post-map, post-PAR), change the default wave.do name to something like wave_f.do for functional, wave_m.do for mapping and so on for the other type of simulation.

4) Go back to the ISE Project Manager window.

5) There are a couple of options to load automatically the saved wave.do file (item 3.b) when running a simulation from Project Navigator. As it was explained before, the easiest way is to modify the <TestBenchName_wave.fdo> file. Hence, open to edit the <TestBenchName_wave.fdo> file that resides in the ISE Project Directory. Remove or comment out (by using the # character) the command line “add wave *” and then add a new command line that will invoke the customized waveform; by writing “do wave.do” (or whatever name you use when saving the Wave window format). If you have saved the wave.do file in a directory different than the ISE Project Directory, you will need to write the complete path where the file wave.do resides. Below, there are two examples of how the <TestBenchName_wave.fdo> file would look like, one for a complete directory path, and the other with a relative path:

Once finishing with the modifications, save the customized <TestBenchName_wave.fdo> file.

6) From now on for every behavioral simulation to be executed, Project Navigator will use the custom wave.do waveform format when launching ModelSim.

Even though it has been explained the process to customize the behavioral simulation, similar steps have to be followed, for instance, for customizing the post-place and route simulation. The file to be changed in this case is the <TestBenchName_wave>.tdo (as it was explained before) and just follows all the steps detailed above for the behavioral simulation.

More on Customization
Besides of modifying the <TestBenchName_wave.fdo> file for customizing the Wave window format, another ModelSim commands can also be added with other purposes. For instance, one useful command for designs with a large amount of internal signals is the following: log –r /*

This command will log all the data objects in the design. For example, if after running the simulation you find out you would like to see an internal signal not currently displayed in the Wave view, you just need to select the signal you want to add, drag and drop it in the Wave view. Then, its respective waveform will immediately be displayed.

Without the log command, if that particular internal signal is not in the list of signals in the wave.do script, it is not logged; therefore no waveform will be displayed for that signal. In this case, it will be necessary to add the signal to the Wave window, save the wave.do again and then rerun the simulation.

The drawback of the log command is that it could make the simulation much slower since it needs to log all the signals of the design. One point to keep in mind is the fact that internal signals after PAR usually do not keep the same name as before the PAR. This means that the wave.do saved for functional simulation, may or may not be able to display all the internal signals when doing a post-PAR simulation.

One solution for this problem is to create another customized wave.do for the post-PAR simulation naming it something like wave_par.do. Then, change the <TestBenchName_wave.tdo> file as explained in point 5 above. Another helpful point to know is the fact that it is possible to rerun the simulation without closing ModelSim, avoiding returning to Project Navigator.

For instance, if you find an error when running the simulation in one of the .vhd source files, you can edit the VHDL file, still keeping open ModelSim (even you can use ModelSim text editor), save the modifications of the VHDL file and rerun the simulation by typing do {TestBenchName.fdo} and pressing enter in the transcript window (bottom window) of ModelSim. You can also use the up-arrow key in the transcript window to go through all the executed commands until you find the do {TestBenchName.fdo} command, and then just press enter to execute it.

Get free daily email updates!

Follow us!