In his post “12 Steps to Better code“, Joel Spolsky identifies 12 must haves for improving your software design process. Today’s FPGA design is modeled well by current software development processes but not perfectly. Joel’s test however is a great starting point for hardware design. His test asks:
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do new candidates
- Do you have testers?
- write code during their interview?
- Do you do hallway usability testing?
From a hardware/FPGA design perspective, I’d like to re-arrange slightly and expand on these steps;
1. Do You have a spec?
Starting off with a design spec is important to FPGA design - especially when other groups such as software are involved. The most common complaint I hear regarding hardware specs is “I’ll write the spec when the design is done”. The advantage of writing the spec first or at least while you work out the design is that it forces you to do just that - Work through the whole design. Before starting RTL coding or drawing schematics, working out interfaces, bandwidth equations, an address map, register variables etc… gives you and everyone else involved a clear picture of what is being built. The spec also lets you address how your design will meet any design requirements. In fact, the step before this could be titled “Do you have clear design requirements?” but that is commonly derived from either a marketing survey or other customer input and probably deserves it’s own article.
2. Do you have an up-to-date schedule?
Equally important to a design spec is having a good clear perspective on how long it is going to take to do this project. Often the schedule is done prior to the spec being written and that is OK for a first cut. Once the design spec is complete however, you should be able to put together a very detailed schedule that you feel confident you can achieve. I may do another article on hardware schedules but the most critical point is that the people doing the work review and sign off on any schedule you submit to project management. Like the specification, other groups in your organization rely on your schedule being both accurate and achievable. For an FPGA schedule, the board designer, DV team, software, marketing and sales may all have a vested interest in you meeting your schedule. No pressure, just make it accurate!
3. Do you use source control?
Some of my colleagues will laugh at this because I was once a heretic but: Source control is invaluable. Yet, so many hardware designers resist it. From the hardware side, I’m talking about source control for RTL specifically. Schematics are not usually binary files and do not really benefit from the tools RCS can offer. Formulating an in-house method of saving schematic revisions is a good idea though. The most common I have used is saving the database, using the date in the file name, to a server that gets backed up. If this is done on a regular basis, recovering lost data or undoing a change is fairly straight forward.
RTL development is perfect for a revision control system. There are a bunch around, I prefer Subversion over others I have used but as a contractor, I end up using whatever the customer has in-house. Being able to make labels to group a current functioning set of files is invaluable. Being able to roll back changes for files has saved me a ton of time. Whether your working as part of a team or as an individual, check out a revision control system.
4. Can you make a build in one step? Do you make daily builds?
I’m grouping these two together as: Can anyone build your chip? For any organization, key person management is important at all levels. If you are out sick for a prolonged period and someone needs to make a build of your FPGA, run a simulation or compile a schematic netlist for PCB layout, can they? Getting crafty with Make and a couple of Perl scripts will allow anyone in your organization to type in one command and either synthsize a part or run a simulation. This is a huge time saver for you and for anyone else involved. Hardware designs certainly do not need to be synthesized or do a timing analysis on a daily basis but once a design reaches critical mass, running nightly regressions is extremely valuable. Do it.
5. Do you have a bug database? Do you fix bugs before writing new code?
This is one of the most touchy subjects I have run across in hardware development. The hardware folks at one company I was at refused to use a bug database for fear that management would use it against them at review time. Like RCS, there are a bunch of good bug tracking packages out there and again because I have been consulting for a while, I have used many of them. I have found that for communicating between RTL and DV or RTL and software, often a simple spreadsheet will suffice. The advantage to tracking bugs (or “open issues”) is that nothing falls through the cracks. Say DV finds a minor corner case bug that you can’t afford the time to track down immediately. Before you release the chip, go through the open issues list and close any thing you may have forgotten about. It will pay huge dividends down the road.
The second part of the question is do you fix bugs before writing new code? In a perfect world you would right? This should depend on the ability to grade the value of each bug and that is up to each designer. If it something that breaks a regression test then yes you should fix it immediately. If as I illustrated earlier, it is an odd-ball clock skew, corner case that only happens when a virtual impossibility occurs on an input pin then making a note of it and closing it before release is usually OK… just don’t forget it.
6.Do programmers have quiet working conditions?
This is why they invented the iPod right? Honestly, it would be great if every engineer could have a walled office with a door but in most of the offices I have been in, that’s not going to happen anytime soon. The best you can hope for are quiet cube neighbors and good headphones. Get in the flow and shut everything else out.
7. Do you use the best tools money can buy?
This is another one where I think software and hardware differ quite a bit. While the “best” hardware tools are often way out of the budget for many hardware design groups, I am amazed at how many companies I have worked at - this includes huge companies - that only provide the freebie or lowest cost simulators to the hardware teams building the platforms the company will rely on for revenue. There are great and affordable mid-range tool sets that go a long way for testing and verifying hardware designs. FPGA vendors like Altera will provide a great version of Modelsim with their Quartus distribution for reasonable money.
As for compute power, there is no excuse for not having hardware on your desk or in a server room that can compile your design in a reasonable time. Computers (memory, disks, monitors) are relatively cheap these days - insist on a platform that can get the job done.
8. Do you have testers?
If at all possible, having someone that is not designing the FPGA test it is preferable. Of course in many departments where there is just one designer, having someone else do the DV work is impracticable.
On a large ASIC development there will be a dedicated DV team who will approach the problem from a requirements perspective but on too many FPGA designs, a single engineer writes both the code and the testbench and ends up making the same assumptions and mistakes on both sides of the job. If your FPGA is small and very well defined, this can be OK but for larger efforts involving many FPGA’s see if there is any way you can get help on one side or the other. Talk an idle software guy into learning Verilog or System C to write a test bench or hire a consultant to write one - it will save you time in debug for sure.
9. Do prospects write code during their interview?
I started doing this at the last company I was at full time. I came up with one question that I asked every prospect (it was a simple question). I was amazed how many missed it entirely and I was in most cases prompting them along the way. We did hire the guy that answered it right though and he turned out to be a great engineer.
So, my thanks and apologies to Joel for distorting his test somewhat. I used to have it pinned to the wall of my cube but ended up explaining to anyone that asked how I felt hardware development differed. Joel’s last item “Do you do hallway usability testing?” is really hard to apply to hardware unless you are making a cool consumer gadget but the notion is good - get feedback on your design. A final question missing from Joel’s test is:
10. Do you hold a “What we could have done better” meeting?
After your product ships, get everyone involved into a room and talk about what you could have done better. Learn from your mistakes together and move on.
