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!

From Perl to Python - Preliminaries

My first real job in the tech industry was for a small graphics design firm in Montreal.  I was 18 years old.  They hired me as a part-time web programmer.  The development environment that the company used at the time was a LAMP-like stack using Perl/CGI rather than PHP.  This was before the year 2000.  I will admit that I was not very experienced, so it goes without saying that I wrote a ton of ugly Perl code - but heck - it got the job done!

My experience with Perl grew over the years.  In graduate school, I wrote a handful of Perl scripts to stitch together a number of point tools that, together, made up a complete design/verification/FPGA implementation environment for the processor and SoC design that was the subject of my thesis.

As a hardware design verification engineer and as an EDA application engineer, I continued to write Perl scripts to do everything from log post-processing and checking, regression mining, to developing complete  front-end verification tools.  Perl became my #1 - it got the job done!

Inevitably, I also helped maintain a number of existing scripts that were written by other engineers.  Yes, Perl got the job done, but there were times that it was at the expensive of my sanity.

My experience so far has shown that while it is easy to write scripts using Perl, the result is often difficult to maintain code.  Engineers tend to treat the language as a simple shell script enhanced with regular expression matching.  Most understand basic data structures such as arrays and hashes, but only a select few can grasp more complex data structures (e.g. hashes of arrays), Perl references, one liners, OOP, exception handling, CPAN modules, etc.

Now, I realize that my opinion above could be considered by some as flamebait (especially because it is not well substantiated).  You can write poor code in any language, not just with Perl.  Being an experienced programmer helps, but I contend that the language itself does not do its part in encouraging the programmer to write good code.  Sure, you can train programmers to write better Perl code, but good luck with enforcing coding guidelines.

The purpose of this first of a series of blog posts is to introduce an alternative programming language for tasks that are typically relegated to Perl.

I first used Python in college to write a Blender 3D export script for my undergraduate computer graphics course.  My initial impression of the language was not very favorable: the use of tabs for indenting, no semi colons at the end of the line, etc.  I did not understand the hype.

I started to take notice of the language lately for a few reasons.  First, there was a colleague of mine at Sun Microsystems that could not stop raving about the language!  There is also the Google factor.  If the crack computer scientists at Google have selected Python as the company's scripting language of choice, shouldn't I take a closer look?  Finally, the Python community is very committed to coding guidelines and style.  There are great tools available for static source code linting (pyflakes, pylint) and for enforcing the style guide (pep8).

With the above in mind, I have decided to write a few posts on the language from the point of view of an intermediate- to advanced- Perl user.  Here are some of the topics that I will cover in the future, stay tuned!

• Vim Setup
• Parsing Command Line Arguments
• Program Flow and Exception Handling
• Logging
• File I/O
• Regular Expressions
• OS
• Lists and Dictionaries (and Dictionaries of Lists)

Vim Setup for SystemVerilog

It took some time and effort on my part to really become comfortable with using Vim.  Eventually, I became so productive with using the text editor that it became unnecessary to use anything besides it.

The two features that got me hooked to the text editor are the ability the select and manipulate columns in visual block mode and the large number of third-party plugins available.  My primary use for Vim is for programming in SystemVerilog.  I have found that the following plugins are extremely useful:

• matchit.vim (http://www.vim.org/scripts/script.php?script_id=39)
• verilog_systemverilog.vim (http://www.vim.org/scripts/script.php?script_id=1586)
• vcscommand.vim (http://www.vim.org/scripts/script.php?script_id=90)

The typical use of the % key in Vim is to move the cursor between matching curly braces.  I have a seen a number of SystemVerilog users adopt the following convention to make use of the feature.  It is a cumbersome practice that is entirely avoidable.

if (condition) begin // {
end // }

When configured correctly, match_it.vim allows the % key to be configured to match more than just single characters.  In the context of SystemVerilog, we can enable the user to move the cursor between Verilog-style statements that define blocks of code (e.g. begin/end, class/endclass, package/endpackage, etc.)

Configuring the plugin is pretty straightforward.  I started with the configuration posted at http://vblog.learn-asic.com/?p=40 and made some minor tweaks (make sure to use the tick character ', not `, ‘, or ’ when defining b:match_words).

filetype plugin on

source ~/.vim/plugin/matchit.vim
if exists('loaded_matchit')
let b:match_ignorecase=0
let b:match_words=
  \ '\<begin\>:\<end\>,' .
  \ '\<if\>:\<else\>,' .
  \ '\<module\>:\<endmodule\>,' .
  \ '\<class\>:\<endclass\>,' .
  \ '\<program\>:\<endprogram\>,' .
  \ '\<clocking\>:\<endclocking\>,' .
  \ '\<property\>:\<endproperty\>,' .
  \ '\<sequence\>:\<endsequence\>,' .
  \ '\<package\>:\<endpackage\>,' .
  \ '\<covergroup\>:\<endgroup\>,' .
  \ '\<primitive\>:\<endprimitive\>,' .
  \ '\<specify\>:\<endspecify\>,' .
  \ '\<generate\>:\<endgenerate\>,' .
  \ '\<interface\>:\<endinterface\>,' .
  \ '\<function\>:\<endfunction\>,' .
  \ '\<task\>:\<endtask\>,' .
  \ '\<case\>\|\<casex\>\|\<casez\>:\<endcase\>,' .
  \ '\<fork\>:\<join\>\|\<join_any\>\|\<join_none\>,' .
  \ '`ifdef\>:`else\>:`endif\>,'
endif

I only use the syntax plugin included in the verilog_systemverilog.vim package because I am disciplined enough to do a better job than the tool can.  The automation identation functionality gets in the way for me.  My filetype configuration for SystemVerilog files is as follows:

syntax on


autocmd BufRead,BufNewFile *.v,*.vh setfiletype verilog
autocmd BufRead,BufNewFile *.v,*.vh set expandtab tabstop=4 softtabstop=2 shiftwidth=2
autocmd BufRead,BufNewFile *.sv,*.svi set filetype=verilog_systemverilog
autocmd BufRead,BufNewFile *.sv,*.svi set expandtab tabstop=4 softtabstop=2 shiftwidth=2

I prefer spaces to tabs for the simple reason that the only way to align a a block of code idented with tabs is to use spaces, so why use tabs to begin with?  The only exception that I have found to the rule is for assembly languages and makefiles (because they require the use of the tab character).  Opinions vary widely on the subject, but the most important take away is to be aware of how the original author of the file that you are editing has chosen to ident their code and to not deviate from it.  To view the type of whitespace used for the file being edited, you can set these options in your .vimrc:

set listchars=eol:$,tab:\>\ ,trail:.,extends:>,precedes:<
set list   " to turn on (use :set nolist to turn off)


The last plugin that I have decided to blog about is vcscommand.vim (not to be confused with the simulator from Synopsys).  This plugin script is an excellent front end to CVS, SVN, and other source code control systems.  The feature that I use the most is command :VCSVimDiff to display differences between the most recent version of the file and the checked-in version of the file.  I map this command to key F12.  There are other options for file check in but I'll typically use the command line to do so.

map <F12> :VCSVimDiff<CR> " map F12

Hello World!

Watch out world, I have established my online presence!

Back in 2007, I graduated from Queen's University with a M.Sc. in Computer Engineering (emphasis on computer architecture).  The most difficult part in obtaining this degree was not the technical work, course work, or the academic research involved, as all of this comes (somewhat) naturally to me.  Writing research papers and ultimately a thesis did not.

Completing the degree was a great experience.  Without it, I would not have landed a killer job at Sun Microsystems in Santa Clara, CA where, initially, I worked on the Rock processor core.  It was an incredible experience!  Now, with a handful of years in industry under my belt, a second take away for me is that no matter how brilliant or sharp an engineer may be, communication skills (both written and interpersonal) trump all else.

So, writing skills are a valuable asset and they do not come naturally to me.  Practice makes perfect, thus no better reason to start a blog!  I also have a number of interesting projects brewing that could benefit from this type of outlet.