Archive for the 'Tutorials' Category

Making Xilinx Suck Less: A VHDL Preprocessor

Oh VHDL, you make my life so wonderful. I just want to be able to enable or disable different debugging features at compile time. But no, there’s no real preprocessor support in the VHDL world.

So my solution was to write a wrapper script that fakes out GCC into using its preprocessor and then generating a new VHDL file. It takes two files as input: the [cci]prj[/cci] file you would use for XST and a [cci]config[/cci] file that has a bunch of key=value pairs that get passed as directives for the GCC preprocessor.

For each file, it then invokes the following magic:

[cc lang=”bash”]gcc -Dwhatever=whatever -traditional-cpp -E -x c -P -C file.vhd[/cc]

This causes GCC to treat the VHDL file as just a generic C file and only processes the standard preprocessor directives like [cci lang=”c”]#if[/cci].

It then saves the result to a new file. So if you were processing [cci]file.vhd[/cci], it would generate (by default) [cci]file.gen.vhd[/cci]. It stores these files in the same directory as their pre-preprocessed versions.

Finally it creates a new [cci]prj[/cci] file that you should pass into XST.

So, it’s super easy to use. All you need to do is run [cci lang=”bash”] -p /path/to/project.prj -c /path/to/config[/cci] and all your files will be preprocessed.

Fixing a Seiko watch not reseting to 12

I was using my chronograph on my Seiko watch that I’ve had for a few years (7T92-0FX0) and noticed that when I reset it, the seconds hand was returning to the 57 second mark and not to 0. I Googled for a while and found this guide for another watch. This method didn’t work, so I tried a few other things.

Turns out the correct thing to do was to pull the stem out to the second click (for setting time) and then holding the top button for about 5 seconds. This will cause one of the dials to turn around fully. But, I was confused because it just put the dial back to the 57 second mark. Then, I tried hitting the bottom button, and it advanced. So, after two more presses, it was back at 0 and when I pushed the stem back in, the chronograph was reseting correctly again.

By pressing and holding the top button, you’re selecting which dial you want to reset. So if you press and hold the top button two times, it will make a different dial spin around, and then you can adjust that dial by hitting the bottom.


Making Xilinx Suck Less: A Better Build Environment

One of the biggest problems with the Xilinx workflow is that it doesn’t adhere to the way that people typically work on their projects nowadays. The Xilinx tools basically vomit intermediate build files and log files all over your build directory, making it hard to tell which files are the ones that are important (i.e. modifiable by you) and which ones are just debris.

Can we fix this? Mostly, yeah. Here’s how. These are the things I wanted to have happen:

  • Compatible with version control software — all build files should go in a separate directory from config files and source files
  • Completely command-line build and programming process (so that I can easily automate what I’m doing)
  • Easily-available logs and reports

    So, I have a directory structure that goes like this:

  • gen/ — Coregen-generated files
  • hdl/ — VHDL sourcecode
  • proj/ — project config files
  • xil/ — build files generated by Xilinx tools
    • xil/xst — I’ll get to these later
    • xil/ngdbuild
    • xil/map
    • xil/par
    • xil/trce
    • xil/bitgen
    • xil/reports — Final spot for all logfiles generated
  • other crap

This way, I can just add xil to my .gitignore file and all the build files will be ignored, but everything else will be tracked. I can easily switch between code branches without having to worry that my project files will be stale. Perfect!

All right, now to tackle the next problem: how do you actually make Xilinx follow these standards? Well, I created a build script (note: I am ashamed to say that I still have pretty much no clue how Makefiles work, so I just wrote a shellscript). Here’s how I built it. Knowing this process will help you to set up your own projects for command-line building.

  1. The first step is to just make your project with the Xilinx ISE GUI. It will automatically set up all the files you need for building. Yes, you can make all these config files yourself, but that’s a huge pain and you only need to do this once.
  2. After you set up a project with the GUI, build it all the way through generating a bitfile. This will allow you to figure out what commands ISE actually runs in order to produce your buildfiles. You can find these commands in the logs that are generated (search for “Command Line:”).
  3. Now check out this build script. You should be able to roughly match each command that ISE runs with a command here. Basically, the process for going from HDL to a bitfile is this:
    1. xst takes your sourcefiles and generates an NGC file
    2. ngdbuild takes your NGC file and generates an NGD file
    3. map takes the NGD file and makes an NCD file
    4. par takes that NCD file and does placement and routing, producing another NCD file
    5. trce uses that NCD file to check timing constraints and stuff
    6. bitgen also uses the NCD file to create a BIT file

    By passing some special flags into each of the programs, we can tell them where to store all their intermediate files, making things nice and neat!

  4. The build script I included needs some modification so that it works with your project. Based on what you see from ISE and from this buildscript, you should be able to modify the command line switches to get what you want. Also, take a look at the Xilinx Command Line Tools reference guide.
  5. You’ll need the following project configuration files from the project you generated with ISE (projname being the name of your project). Put these in your proj/ folder.
    • projname.lso
    • projname.prj
    • projname.ut
    • projname.xst

    You should also put your UCF file in your proj/ folder.

  6. Check projname.prj to make sure that the HDL source files are with relation to your base directory (if you follow my design, they should look like hdl/something.hdl).
  7. projname.xst needs to be modified a bit.
    1. tmpdir should be xil/xst/tmp
    2. xsthdpdir should be xil/xst
    3. Make sure there is a line that looks like -lso proj/projname.lso after the run command. If not, add it.
  8. Finally, I have a batch script for Impact for programming my device (ML605 for me). This is highly dependent on what board you have, but here’s my batch file. To make your own, consult the Impact documentation and also run the Impact GUI and watch for the commands it runs in the command window when you program your board.

Yeah, it’s a bit of a process for getting things to work, but once they do, your productivity should go up quite a bit. Once you get used to this design anyways, it’s easy to create new projects that look similar. Best of all, they’re very compatible with version-control programs.

Yay, now Xilinx ISE sucks a little less! 🙂

Making Xilinx Suck Less: Replacing Chipscope

I’ve spent January doing some initial work on my thesis. I’m working on channel emulation for the Airborne Networks Group of MIT Lincoln Lab. My work involves the use of a sweet FPGA eval board (Xilinx ML605, which has a Virtex 6) and an even sweeter addon board that has two high-speed (i.e. expensive) ADCs and DACs on it.

Unfortunately, interfacing the addon board (called FMC110) is a complete pain in the ass thanks to the complete lack of implementation specifications. It’s been a lot of reverse-engineering 4DSP’s reference design and taking guesses and I’m still having no luck with even the most basic aspects of interfacing the board, but nevertheless I’m still trying.

I use Chipscope a lot since I don’t have a logic analyzer. Chipscope is an FPGA-integrated logic analyzer that lets you capture data on your FPGA and view the waveforms on your computer using their software.

It works pretty well. I’ve found that you have to put everything into registers before you send the data out (pipelining everything), but other than that, integration is very easy.

What sucks, though, is the Chipscope software. The waveform viewer is written in Java and doesn’t even support horizontal scrolling. Come on. Seriously? Like literally the most important thing you should ever have in a waveform viewer is the ability to easily scroll around. Chipscope lacks a whole bunch of other features so I’ve been anxious to get rid of it. I didn’t know that you could until I discovered that if you go to File -> Export, you get this window:

Turns out, there are waveform viewers that are free and are actually reasonable! For example, GTKWave! So, by exporting all the buses to a VCD file, you can import this file into GTKWave and view your signals without the misery of having to use Chipscope. Check it out:

Mutt: A faster way to mark messages as read

I was looking for a macro for Mutt to mark all the messages in a mailbox as read and came across this post which suggested:

[cce]macro index M “T.*\n;WN” “Mark all messages as read”[/cce]

However, this is slow because it performs a tag matching against the Regex pattern “.*”, which is computationally intensive. Another post recommended using ~A instead of .*, but this still has to tag everything in your mailbox and that kind of sucks big-time. So, I came up with this instead:

[cce]macro index <esc>m “T~N<enter>;WNT~O<enter>;WO\CT~T<enter>” “mark all messages read”[/cce]

It first selects all messages marked “New” and untags them. Then, it selects all messages marked “Old” but unread and untags them as well. Finally, it gets rid of all the tag markings by doing T ~A.

Seems to be working pretty snappily.

Replacing Leaky Caps in a 1992 Dodge Stealth

My mom drives a 1992 Dodge Stealth (Mitsubishi 3000GT). Despite the fact that the car is almost 20 years old, it still runs pretty well, with the occasional exception. For example, recently, the window regulator (on the driver’s side) broke and had to be fixed. Then, a few weeks later, the car would stall shortly after starting it, making a clicking noise in the process.

It turns out that one of the most likely causes for this failure is due to leakage of the electrolytic capacitors on the engine control module (ECM), the computer responsible for sparkplug timing. ECMs go for anywhere from $800-$1000, so if you can identify this problem and replace the capacitors, you will have saved quite a bit of money.

So my dad and I took apart the car, following these instructions and extracted the ECM. When we opened it up, we found that two of the caps had pretty heavily leaked on the board, while the other two (yes, there were four in this car — not sure why given that every guide I’ve seen has shown 3) were probably okay. We decided to clean the board replace all of them. Unfortunately, the board was covered in a conformal coating, and we didn’t remove the coating before working, which lead to having to fix things very carefully afterwards. I think that in the end, this would have been the best way to do things.

  1. Completely remove the conformal coating in the area surrounding (and under!) the capacitors using alcohol.
  2. Desolder the capacitors from the board and use a solder sucker to clear the barrels. Note that you need a fairly powerful iron — a standard microelectronics iron won’t work as effectively as a larger iron with a chisel tip.
  3. Clean the board with more alcohol to remove the fluid that has leaked from the capacitors. In our case, it hadn’t actually corroded the board yet, so it wasn’t necessary to repair the underlying PCB. But, it was important to ensure that all of the electrolyte was removed.
  4. Ensure that the barrels are okay. It might even be a good idea to very gently sand them to reveal a fresh layer of copper.
  5. Solder new capacitors onto the board. On our board, there were two 47uF @ 50V caps, one 100uF @ 16V, and one 22uF @ 50V. We used caps that were rated up to 105C. Use lots of flux.
  6. Ensure that all electrical connections are good. Then, inspect to make sure that the caps are mechanically sound.
  7. Clean off the flux with alcohol.
  8. Apply a new conformal coating. We used acrylic coating, but maybe urethane or silicon coating would be better. As you can see below, I inspected the coating with a blu-ray laser (UV light works well too). I chose not to coat the capacitors entirely, but that probably would have been a good idea.

Removing the conformal coating before doing anything else really is a necessary first step. I thought it wasn’t, and that heat from my iron would lift the coating easily, but it didn’t. Otherwise, we were able to create pretty decent solder joints.

Here are a few pictures of the process. Unfortunately, I forgot to take more in order to really illustrate the removal of the conformal coating, but these are sufficient. In the first two pictures, we see the leakage of the electrolyte. Next, we see the result of cleaning the area around the capacitor (again, I didn’t remove the conformal coating before desoldering like I should have). Finally, in the last two pictures, the new capacitors are safely in place and the board is ready to be installed back into the car.