Hit the Road(map) Jack

First, with apologies to the awesome Ray Charles and his hit song, Hit the Road Jack, from which I borrowed this blog's catchy title, I want to introduce the idea of creating a roadmap for your next FPGA development project as a simple way to keep every project team's eye-on-the-target(s).

Now some will immediately respond with, "We have a formal project schedule that defines our roadmap". Just as quickly, I offer my snappy response, "Your project schedule reaks of greatness. Congratulations on producing it but can you show me the roadmap in it?"

Really, a project schedule does not replace a roadmap. (And certainly not vice versa!) But how can this be?

FPGA Development Roadmaps and Schedules

According to Merriam-Webster, a "road map (n)" is a detailed plan to guide progress toward a goal. I could not disagree more. I also do not want to incur the overarching process behind a technology roadmap. The Webster definition invokes more of a schedule connotation especially in regards to detail.

A schedule gives every task, duration, resource and dependency all in one handy Gantt chart. The A problem with a Gantt chart stems from the requirement for some poor soul to be pretty good at Microsoft Project to make changes to the project data and the distinct possibility that doing so is only allowed by one person who controls the document. It captures the exquisite detailed planning for reaching some goal, deliverable, or outcome. As the dictionary definition alludes, it is beautiful but delicate. So, not something you want to mess with lightly.

An FPGA development roadmap (just roadmap from here on), only requires experience with paper and pencil, a white board or perhaps Microsoft OneNote and does not have the rigidity and delicatness of a full on project schedule. Instead it strives to communicate where your FPGA design will potentially end up many releases in the future. Perhaps it is more like Horace Greeley's exultation, "Go west young man" -- which was less about an exact geographic destination then a suggestion of where success could be found.

The roadmap is the place where you deposit your ideas about features, capabilities, bug fixes, and in general any future modification of the design. It innoculates agains the ever present feature creep virus by providing an outlet and storage location for great ideas. It is the chilling air that keeps the current development effort frozen and therefore focused on a fixed set of features.

It should not be a place where ideas are discarded. Using the road map in this way promotes team unity by explicitly valuing all ideas as keepers.

The roadmap contains multiple parts:

  1. Prototype Design
  2. Past Released design(s)
  3. Frozen Development Design (in progress)
  4. Future Design(s)
  5. Idea Pile
  6. Codename List

Each page (yeah you only get one) in the roadmap contains the codename for the design, the version number string, the short descriptive goal of this design and an ordered list or table of features. I use the term feature generically here -- they could be bug fixes, enhancements to functionality, possibly removal of unused capabilities, you name it. The feature ordering is by rough priority the further down the list of roadmap pages you are. However, the Frozen Development Design page should have a very formal priority. Items at the end of the list are fair game for movement at the last moment into the next-in-line Future Design pile.

Rules for Adding Features to the FPGA Development Roadmap

  1. New ideas are always placed in the Idea Pile prior to roadmap discussions. They need to age there for a time prior to movement into any of the Future Design pages.
  2. The Frozen Development  Design page needs to have the names of all the participants and principles recorded on it to signify their acceptance of the frozen state.



Often times FPGA projects suffer from feature creap or scope creap. 

The urge to fix things that are not broken yet.


Idea Pile

Codename List

I like project codenames. They help to associate an easily discussed name for what is probably a complicated set of features.The name probably has nothing even remotely remenisicant of the actual features so the arbitraryness may seem like an empediment. In actual practice I have found it easy to use when a roadmap document is present to help qualify the features associated with the name. Also, if you choose a name set with ascending, alphabetically sequenced names, you add a simple sense of history for where you are at.

"Hafnium was a total failure, but Iodine has saved the day".

There are probably good name sets and bad based on ease of pronunciation and length in characters. Here are ones to consider:


An FPGA development roadmap helps you to document and agree upon a nice evenly sequenced set of design milestones. It helps prevent feature creap by acting as a respository for ideas which do not all require implementation immediately. It provides a discussion vehicle as everything is written down. It can help non subject matter experts (nSME) like managers get a grip on incremental progress milestones.


As to whether, roadmap or road map is the proper sequence of characters, I defer to history but prefer roadmap for its memory saving footprint.