Posts Tagged ‘ project ’

Verilog vs. VHDL

When it comes to Hardware Description Languages (HDLs), the two giants in industry are Verilog and VHDL.  These two languages are vastly different and both provide ample advantages and disadvantages.  Here I’ll show what I think are the pros and cons to these languages.  Since I am a hardware design engineer, I’ll only speak to the synthesizable aspects to the two languages.

My Verilog History:
While plugging away at a Computer Engineering degree at the University of Utah, I was introduced to Verilog for digital circuit design.  At first, I struggled to comprehend Verilog.  I was proficient with C, C++, and Java, so the syntax was familiar but seemed to have odd differences that bothered me.  Once I got the hang of it, Verilog became very powerful in my hands.  I grasped a hold of digital design and completed numerous projects in the FPGA world.  The crux of my Verilog experience was a hand crafted 32-bit RISC processor design.  Through all these experiences I learned to ignore the annoyances of Verilog and hack around them.

Verilog Likes:
To a C, C++, C#, or Java programmer, Verilog syntax will make you feel right at home.  The constructs, operators, and numerical logic follows very closely with C.

Verilog Dislikes:
Verilog was syntactically designed after C.  C is a great software language, however, as one of my professors once said “C is a loaded gun aimed at your foot!”.  The lack of type enforcement is what makes C super fast and super scary.  Without dealing with type checking, compiled C code is very efficient.  For most developers, this also causes buggy code.  Fortunately, software is easy to debug.  Like C, Verilog has weak type enforcement.  Along the same lines, Verilog also doesn’t enforce equal sized bit widths for assignments, operations, and comparisons.  Unlike software, hardware isn’t faster when type checking is ignored.  I can’t tell you how many times a lack of type checking and/or width checking has burned me while designing hardware in Verilog!

My VHDL History:
After graduation I found employment with L-3 Communications in the Advanced Networking Hardware design group.  Due to legacy government contracts, L-3 has adopted VHDL as the HDL of choice.  Although I landed an absolutely awesome job, the thought of designing logic in a language that was derived from ADA gave me a sour taste.  As I begun a few projects, VHDL really annoyed me.  It seemed like I was typing the same thing over and over and over.  I realized that 100 lines of good Verilog translates to 300 lines of good VHDL.  As time went on I discovered the true power of VHDL.

VHDL Likes:
VHDL is inherently safe.  It basically has no primitive data types.  All data types are tied to some library which defines all operations.  Users can create their own data types and operators.  For synthesizable hardware this isn’t super useful however every state machine is best designed using a custom type.  Each time an operator is used, the corresponding function is called.  No automatic conversions are ever made.  You can’t accidentally get something you weren’t expecting.  VHDL is meticulously safe!  Along with being safe, the verbosity adds a level of confidence that what you are coding is what you’d expect.  For instance, the clock and reset structure for a ‘process’ is much better designed than ‘always’ blocks in Verilog.

VHDL Dislikes:
There are many little nuisances  in VHDL.  VHDL-2008 solves many of these nuisances but industry leading tools are not yet supporting the full VHDL-2008 standard.  Even though VHDL in inherently safe, older libraries and bad coding styles can still cause unwanted synthesis results.  VHDL considers all signals to be the same whether registered or not.  I like how Verilog has ‘reg’ and ‘wire’.  VHDL doesn’t have something like this.  I like to know just by seeing the declaration if it is a register or not.

The Winner Is…
After developing in both languages quite thoroughly, I choose VHDL as the best language for synthesizable logic.  The biggest reasoning for this is the safety aspect.  When it comes to hardware, it needs to have a blatant underlying implementation.  All arithmetic and comparisons should have obvious results.

Suggested Coding Standards:
There are several coding standards I live by to make VHDL a powerful language.  Before you criticize the guidelines, thoroughly think of the benefits they provide.  The rules are  here.


Starting a quad-rotor helicopter project

I recently graduated from the University of Utah in Computer Engineering. My senior project was a fly-by-wire system for an unmanned helicopter. We used an Align T-Rex 600 ESP helicopter for the project. Designing a stabilization system for this size of helicopter presents many problems. Given that the tips of the blades travel at 350 mph, physical danger was obviously the biggest concern. We successfully implemented our design.

Even though we felt moderate success, we didn’t feel that our system performed as well as it could have. All the supporting hardware and software was implemented but the time needed to calibrate the many features of stabilization caused us to end the project before all features could be utilized. The excessive calibration time is a result of calibrating a 53 inch helicopter during flight. Any changes in the system had to be modified very slowly.

This project gave me a lot of experience with inertial measurement and feedback control. It also gave me a HUGE desire to make something better!

Now I begin a multi-rotor helicopter project. I aim to fix all the faults in the previous design while overcoming many of the short comings of current multi-rotor designs. I will start by designing a 4 rotor system because it is the cheapest. Once I master the quadcopter, I’ll try a hexacopter or an octocopter. I have been impressed by many multicopter designs. Some are:

  • HexaKopter by MikroKopter
    This design shows a lot of intelligent software engineering. The GPS capabilities of this system are phenomenal. The supporting stabilization system is also very intelligent (see the oscillating coke bottle).
  • GRASP Labs Quadrotor
    Having the entire room and obstacles marked with position sensors is kind of cheating for autonomous vehicles, but I must admit that these helicopters are amazing! Recovering from severe initial conditions is very impressive.

My goals are to:

  • overcome the inheritly slow yaw response of current quad-rotor designs.
  • design an extremely aggressive stabilization system.
  • find a good balance between size and payload capability.
  • make the chassis rigid enough to survive moderately severe crashes.
  • create a quadcopter that is ridiculously fun to drive!

My initial design will be very minimal. I will start off with only a basic quad-rotor design controlled by a transmitter/receiver pair. No other communication will be used. I’m designing this to be minimal so that I can focus on the inertial measurements and feedback control. Once these are mastered, I’ll add fluffy features like:

  • software ground station
  • GPS hold and navigation
  • video downlink