Avnet Spartan-6 LX9 Board: Or How ChipScope is your Saviour

I was recently working on a project which needed more gates than I had in my trusty current FPGA Board (Spartan3-200 on DLP-FPGA-HS). I quickly found the Avnet Spartan 6 LX9 board (AES-S6MB-LX9-G), which I could buy for $90 and have here in a few days. It also comes with a license for SDK for ChipScope, as it’s designed for experimenting with on-FPGA processors. It doesn’t have a full EDK license so you are a little limited in peripherals…

But for my project I didn’t care about that. I was however interested in ChipScope Pro, having used it previously at a job. This quick post will show you how valuable it can be – the license included with the LX9 board is “device locked” and will only work with XA6SLX9 parts. ChipScope Pro is not normally licensed as part of WebPack so the $90 board is a great deal when you consider the licensing cost.

My normal FPGA debugging, beyond Verilog testbenching, is to use a LogicPort on some spare IO lines. This works well – the LogicPort has a very high sampling rate (200MHz external, 500MHz internal). But it requires a physical connection, which requires a lot of IO pins. I was hoping ChipScope could eliminate this problem.

There is two cores of interest: the Integrated Logic Analyser (ILA) core, and the Virtual IO (VIO) core. They are both controlled by the Integrated Controller (ICON) core. You can only have one ICON, but it can control up to a number of ILA/VIO cores.

The VIO core gives you a virtual dashboard, where you can toggle bits and see results. This is pretty handy for validating/playing with cores to check they function as intended. Here I am checking a UART core from fpga4fun.com:


ChipScope Pro VIO

Note the VIO core doesn’t provide buffering, so data is transferred over the JTAG. This limits your polling speed of course, but makes it easy to play with things. It does let you define pulse trains or single pulses if you have special timing requirements on e.g.: load lines, as I had here.

The ILA core is strictly input. But it connects to BRAMs on-board the device, meaning you can buffer a fair amount of data. Since it’s all on-device the speed is basically limited by similar constraints to the rest of your design. Of course if you already have a packed chip you might not be able to spare any BRAMs…

Here I am debugging a state machine, note you how can even define ‘tokens’ so it decodes the states correctly:


ChipScope Pro ILA

 

So the combination of ChipScope ILA + VIO I’m hoping will make designs go by a lot faster.

Springer / SpringerLink MyCopy Review

Recently I was using an e-book I had access to through my school’s subscription to Springer. They advertised a ‘MyCopy’ service, which gives you a printed copy of the e-book for $25 including shipping http://www.springer.com/mycopy. I couldn’t find a review of the printing quality anywhere so though I’d post one quickly…

The actual copy would be $98 for softcover or $103 for hardcover. The trick with MyCopy is you can only order it assuming you have access to the e-book: thus you have a license to print a physical copy, and springer is just printing what you already are licensed for.

Anyway it looks good: colour wrap-around cover, B&W inside. Print quality is good – black is very “black”, although noticeably shiny. Paper seems bright and weight OK. As far as print on demand (POD) it’s great – better than I was expecting for $25. It’s lower quality than a real offset-print textbook, but it’s pretty close, better than other POD I’ve had. I recently bought a “real” book from the ‘Missing Manual’ series, which is apparently using POD for some books. The “real” book I got is far lower quality than the Springer MyCopy, so should give you some idea for comparison. The Springer MyCopy I got was printed in USA as well.

Some images (click for full resolution):

Front Cover:


MyCopy Example Cover

 

Binding Detail:


Image

 

Text close-up, white-looking areas are shiny reflections:


Image

 

Binding can be pushed down and lay somewhat flat without breaking:


Image

 

LPCXpresso LPC1114 J4 JTAG Pinout

I recently got an LPCXpresso board, which you can cut and make into a debugger. I wanted to use the 0.1″ header (J4) and not the specified JTAG (2×10 0.5″) header. Here is how I cut my board such it can be plugged back together: the female header is just half an IC socket:

LPCXpresso Cut in half

Counting pin 1 at the top of the board (near J49), the pinout is:

1: +3.3V
2: TMS/SWDIO
3: TCLK/SWCLK
4: TDO/SWO
5: TDI
6: RESET
7: +5V
8: GND

RTCK is not present on this header, it’s only on J5. You may wish to consider not mounting pin 7 (+5V) since if you ever connect the plug wrong this will give you serious trouble, since +5V at high current is available. I ended up removing pin 7 and plugging it, so I also used that as a key on the other side of my connector. This prevents me from plugging in something backwards.
>

Interfacing to 34401A

I recently got my 34401A bench meter out of storage, and wanted it working with my computer, something I hadn’t done for several years. I forgot to get my ‘official’ Agilent connection cable, but figured I could use my standard cables no problem.

This took a bit of effort to actually get working, so here is my notes on the issue:

  1. The required settings are 9600 Baud, 1 Start Bit, 2 Stop Bits, Hardware flow control. Hyperterminal never seemed to work, possibly because the 34401A uses full RTS/CTS + DTR/DSR flow control. I did however have success with the ‘Termite’ program with the following settings: Image
  2. Send the SYSTem:REMote command first, you should see a little ‘RMT’ appear on the 34401A VFD front panel. This indicates comms are working. Try a READ? command too; As an example see the following, blue is what I’ve sent and green is the meter responding: Image
  3. I first tried a small null-modem adapter + RS232 extension cable. You need to ensure your cable has all lines connected, since the 34401A uses full flow control. My null-modem adapter didn’t have lines 1 & 9 connected straight-through, as the 34401A manual says it should be. I figured it wouldn’t matter since it doesn’t claim to use them, and the rest of the lines were connected as required, but the meter didn’t respond to any commands. Using a null-modem cable which had line 9 connected straight-through, but not 1, seemed to work fine. So the hardware can be an issue!
  4. So far the Excel/Word Plug-In hasn’t worked for me. I know it did at one point, so still working on that, but I might end up just using Python or something instead anyway.

>

Meet me Live, Site Updates, and Book Updates

If you will be in San Diego this coming Monday/Tuesday/Wednesday I encourage you to attend Smart Grid Security West (http://www.smartgridsecuritysummit.com/), where I’ll be discussing some of my work in wireless security. Hope to meet you there!

I added a link to one of my big new projects, a book about all these wireless networks. It’s called “IPv6 for the (Wireless) Masses”, and I hope the playful title will make you to believe that perhaps it will offer more than just regurgitated standards and information you can find elsewhere with a bit of Googling.

I’ve also upgraded my TikiWiki software version (again), so let me know what else breaks. I’ve been playing around with menus and plan on updating my ‘random tips’ blog more often with what I am up to.
>

Compass Circles

In my effort to build the calibration software for my simple Digital Compass, I’ve been working on doing tests with it.

Here is a screen-shot of the output (using MATLAB to interface to the serial port), it shows a plot of X & Y magnetic field readings plotted on X/Y axis. You can see it’s a (fairly) nice circle. The object will be mapping a distorted circle due to iron in the area onto something like that…

Image

>

Making AT90USBKEY Run on 5V (Easy Way)

I needed to use my AT90USBKEY at higher than 3.3V for ADC input purposes. It’s not documented in the manual, but the schematic shows they anticipated this. You can easily convert the AT90USBKEY to run on 5V with a few changes. The changes needed are:

  • Remove resistor R20 (0-ohm resistor)
  • Remove resistor R16 (0-ohm resistor)
  • Place a 0-ohm resistor on pads at R21 (move R16 or R20)

That’s it! The DataFLASH chip’s VCC needs to be in the 2.5-3.6V range, but with those changes it is still powered by the 3.3V regulator. Thus you don’t need to remove the DataFLASH chips. The DataFLASH devices have 5V tolerant I/O, so even though your MCU is running at 5V, it won’t fry the DataFLASH. Note the logic high levels of the DataFLASH may not be sufficient to actually work with the MCU, since it’s logic high will only be using 3.3V logic.

The following diagram shows the changes, red = remove resistor, green = new resistor, yellow = optional change. I actually removed the DataFLASH in this photo only because I wanted the I/O lines the DataFLASH was using.
Image

Note that D3 drops the 5V input to about 4.2V. The actual VCC with just the resistor change is 4.2V. If you want full 5V from the USB, you also need to remove diode D3 and replace with a short. This is the change highlighted in yellow above.

When running from 5V you need to ensure the USB regulator is enabled. If using LUFA make sure the ‘USB_OPT_REG_ENABLED’ is enabled. e.g. in the Makefile:

LUFA_OPTS += -D USE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)"

Another hint too: If you aren’t removing resistors permanently, just slide them onto one of the pads. This way you won’t lose the parts when you want to put them back. For example when I was using the line with the HWB pushbutton:

Image

>