Back to Basics

I have been working in hardware design verification since I graduated from school.  It has been nearly 7 years now, time flies, I can hardly believe it.

Hardware design verification is an extremely exciting field.  The field requires knowledge spanning multiple disciplines: software development, hardware implementation, and (in my case) computer/graphics systems.

My job at Qualcomm is also extremely challenging, we are at the forefront of all the above.

At school, I wasn't interested so much in academics or research as I was building things.  I spent a substantial amount of time working on overly ambitious projects.

The best example of that, perhaps, was my digital VLSI circuits class where I spent more time playing with tools to generate GDS-II from RTL than focusing on the class assignment which was to design and layout a custom digital cell.

In my undergraduate computer graphics class, I went way beyond the defacto rendered-with-OpenGL textured cube or simple ray tracer. I wrote my own scene graph, associated rendering engine, and custom Python-based Blender3D export plugin.  Not only that, but I took it a step further and wrote some custom shaders in ARB assembly language.  This was before there were high-level shader languages.

Fast forward to grad school.  I had taken a keen interest in computer architecture.  The thought and opportunity to understand these systems from the ground up was (and still is) very exciting for me.

As you can imagine, I wasn't interested so much in research as I was in hacking.  I spent a substantial amount of time building my own multiprocessor system-on-a-chip from the ground up and prototyped it on an FPGA.

The final product was documented in my thesis and in two conference papers.  Granted, my contributions weren't ground breaking, but in retrospec, it was a very rewarding experience.

Over the past few years, I haven't tinkered so much. I worked. I lived. I got married. I am still learning about work-life balance. But, the bug to tinker is still in me.

This long winded rant to say that I have recently been researching FPGA prototype boards to purchase and settled on this one the other day.  Besides cost, I was motivated by the availability of Ethernet ports and PCIe connector.  I/O is an area of system design that I know next to nothing about.

http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/LatticeECP3VersaDevelopmentKit.aspx

I do not plan to make any commitments regarding my tinkering, but it is a part of me that I hope to resurrect.

Vim Setup for Python - Part 2

A quick follow up of my previous post:

http://blog.edmondcote.com/2013/10/vim-setup-for-python.html

Tagbar install and shortcut

1. Install ctags
2. Download Tagbar from http://www.vim.org/scripts/download_script.php?src_id=21362
3. Install Tagbar using vim -c 'so %' -c 'q' tagbar.vmb
4. Add nmap <F8> :TagbarToggle<CR> to your $HOME/.vimrc

Shortcut to fix indentation

http://vim.wikia.com/wiki/Fix_indentation

1. Add map <F7> mzgg=G`z<CR> to your $HOME/.vimrc

Tab-completion of Python code

1. Download latest version of Pydiction http://www.vim.org/scripts/script.php?script_id=850
2. Install Pydiction

Vim Setup for Python

I have used a number of modern IDEs for software development.  For example, I think it is neat how one can draw up UML diagrams and generate code from them (or vice versa).  Integration with the-more-complex revision control systems is also nice.  What I dislike is vendor lock in loss of control of the development flow.  I could speak more about this, but it is a different topic than what I'd like to cover today.

I like the Vim editor because of it's point tool nature.  It does it's job and it does it well.  It is well supported by the community, it is available on virtually every Linux installation (and Windows), and it is extremely customization.

A number of blog posts have been written that describe their settings for configuring Vim to edit Python files. This will be yet another.  The default configuration for Python in Vim leaves to be desired.  Fortunately, there are a few easy steps one can take to enable a streamlined experience.

The first step is to make sure to enable the Vim filetype plugin using command filetype plugin indent on in your $HOME/.vimrc.  The following site has more information about why to use this plugin.  To summarize, it allows the user to move filetype-specific commands outside of their main configuration file, reducing clutter in the file.

http://vim.wikia.com/wiki/Keep_your_vimrc_file_clean

For indentation, first create a Python-specific configuration file $HOME/.vim/ftplugin/python.vim containing the following lines:

setlocal tabstop=4

setlocal softtabstop=4

setlocal shiftwidth=4

setlocal textwidth=79 " to comply with PEP-8 style guide

setlocal smarttab

setlocal expandtab

Eric McSween developed a Vim plugin for smart indentation of  Python code.  The utility is available here: http://www.vim.org/scripts/script.php?script_id=974.  Installation is straightforward, simply download the latest version of the script and copy the file to $HOME/.vim/indent/python.vim.  Use of the filetype plugin, as described above, will automatically enable the utility.

Last, Dmitry Vasiliev developed a Vim plugin for Python syntax highlighting.  The utility is available here: http://www.vim.org/scripts/script.php?script_id=790.  To install the plugin, download the latest version of the script and copy the file to $HOME/.vim/syntax/python.vim.  Enable the plugin by adding command syntax on to your $HOME/vim.rc file.

I recommend the use of a static code analyzer for anyone developing new code.  Pylint is my analysis tool of choice.  It is typically available as a binary package in most Linux distros - i.e. may need to talk to your sys admin.  There is some overhead of using code analysis in the short term, but long term, you will benefit from a code base with that looks pretty and smells less.

For integration with my editor, I use the following plugin: http://www.vim.org/scripts/script.php?script_id=891.  Installation of the plugin and requires the user to copy the downloaded script to directory $HOME/.vim/compiler. 

My Dot Files

This post is to follow up on the previous one.  I recently brought up a new Windows system and installed Cygwin.  Rather than simply save my dot files in a safe location, I decided to do a short write up on them.

.cshrc.local

I use C shell (tcsh) and not bash. Based on my experiences, I've observed that it is the preferred shell in the world of hardware engineering.  I won't argue here, the discussion about bash vs. tcsh is not worth any of my spare cycles.  I don't tend to need much more than the default settings and I seem to have converged on the following options:

set history=1000
set ignoreeof     # Don't let ^D exit the shell
set notify        # Print message when background jobs complete
set autoexpand    # Expand history when completing

bindkey -k down history-search-forward # Essential, see my previous blog post
bindkey -k up history-search-backward

alias df 'df -h'    # Print sizes in human readable format
alias du 'du -h'
alias g  'egrep -i' # Default to egrep and ignore case
alias h  'history'
alias l  'less'
alias la 'ls -a'
alias ll 'ls -l'
alias ls 'ls --color'
alias rg  'g -r'    # Alias for recursive grep
alias vi  'vim'     # Shortcut for vim and gvim
alias gi  'gvim'

.vimrc

It wasn't until I switch to vim (not vi) that I begun to call myself not-an-emacs user.  I have never been comfortable with legacy vi key mappings, so I disable compatibility within vim.  In addition to that setting, I typically set the following ones:

" Allow backspace to work in insert mode
set backspace=indent,eol,start

" Use VIM settings, rather than Vi settings
set nocompatible

" " Enable default ruler and always display status line
set ruler
set laststatus=2

" Indentation, use spaces not tabs
set shiftwidth=4
set tabstop=4
set expandtab

" Search
set ignorecase
set hlsearch
set incsearch
set nowrap

rxvt and .Xdefaults

I use the rxvt-native package for my Cygwin console rather than Microsoft's vanilla console or (name of your variant of) xterm + X11 server.  It works very well.  To run rxvt.exe, I created a shortcut to the following command line:

E:\cygwin\bin\rxvt.exe -display :0 -fn "Lucida Console-14" -tn rxvt-cygwin-native -e /bin/tcsh -l

Rather than use option -rv for reverse video (dark background, light foreground), I set the following options in my .Xdefaults file.  rxvt-native will use the values specified in this file even though it does not require an X server.

 rxvt*background: Black
 rxvt*foreground: LightGrey

Tcsh history-search-forward and history-search-backward

Linux and I go way back.  From 1998 on, it has been my operating system of choice for web development, software programming, kernel and compiler toolchain hacking for embedded systems, and more recently, hardware design and verification.  For technical work, my productivity using Linux is unmatched when compared to using Windows.

There is a catch, however.  This increase in productivity is only applicable when my shell is configured how I like it.  For me, the most important option in my shell configuration are editor commands history-search-forward and history-search-backwards.  These are two options that you absolutely cannot live without, here's why...

By default, the up and down arrow keys are configured to display adjacent items in the history list.  That is, if your last command executed is 'gvim', pressing up will recall that command.  When history-search-forward and history-search-backward are enabled, the up and down keys will search your history backwards and forwards, respectively, for entries matching the current input.

Here is an example to illustrate the option's usefullness.  First, we execute gmake.  Next, we run a number of commands.  To run gmake again, type g, then press up, and gmake is copied from the history buffer.

To enable this functionality, add the following lines to your local .cshrc file and open a new terminal window.

bindkey -k down history-search-forward
bindkey -k up history-search-backward

Enjoy!