Embedding a CPU via IP cores has long been popular in the world of FPGAs and ASICs.  In these times of the System-on-Chip (SoC), most large designs require a microprocessor to aid in speeding up development cycles, easing complexity, and improving time to market.  But what about CPUs with embedded FPGAs?

NetworkWorld is reporting that Intel will be embedding an Altera FPGA into the Atom E600 microprocessor.  The Atom is an Intel processor aimed at embedding computing platforms and portable devices like netbooks.  How are Intel going about doing this?  According to NetworkWorld,

In the E600C series, Intel attached the Altera FPGA to the E600 via a standard PCI Express connection with two lanes. Luse declined to comment on if or when Intel might manufacture the Atom and FPGA on a single die.

This has potentially interesting applications.  Instead of designing a separate PCIe card, engineers can now implement their design inside the CPU, reducing the need for other areas of design work, such as power circuitry, PCIe interface and circuit board layout. Designs with a PCIe interface can also be reused between regular FPGAs on a circuit board and embedded FPGAs.  While I don’t see such embedded FPGAs replacing FPGAs as they are today, I do see the potential for creating domain or application specific co-processors in the embedded FPGAs, for example, encryption engines.

I am curious about whether or not there will be an external I/O interface that connects directly to the FPGA.  I also wonder what type of clock speeds we can expect for the embedded FPGAs?


Connecting to the XP2 Brevia Board

Much to my surprise, my Lattice XP2 Brevia board arrived in the post today.  I printed out the User’s Guide with the schematic because I know I’ll be pouring over the schematics during my lunch break at work and when I get home in the evenings.  The kit contains a null-modem (serial port) cable, the 3 inch x 2 inch board, a parallel-port programming cable, and a power adapter with exchange sockets depending on the electrical standard in your region.  This is truly a versatile development kit for experimenting with FPGAs.

Because I don’t have a PC with a built in parallel port, I have to use a USB programmer, and I’m still waiting on my Lattice USB programming cable to arrive in the post.  Note: Lattice says that USB-to-parallel converters will not work with their parallel port programming cable.

It is often helpful to evaluate the status of the board before beginning with prototyping and development.  If I had designed the board myself, I would be checking the voltage levels at critical parts in the circuit and making sure they match they intended levels.  I’d also be checking the power-up sequence and reset circuits to make sure that these basic functions behave as expected.  I trust, however, that Lattice has taken care of this.

My test plan is:

  1. Connect to the board’s serial interface via a terminal and verify that the factory-installed demo application runs as expected
  2. Connect to the board’s serial interface with my own software and make sure I can interact with the factory-installed demo application

Connecting to the board with a terminal

If you have a Microsoft Windows workstation, you can follow the Lattice QuickState guide and use HyperTerminal to connect to the board.  Though I have Windows installed through a Virtual Machine, I only use it for the Lattice FPGA design software and device programmer.  I would like to use my preferred OS, Mac OS X, for interacting with the XP2 board.  While Mac OS X does not have a graphical application like Microsoft’s HyperTerminal pre-installed, we can use a terminal tool called screen.

Screen comes installed on Mac OS X and it is accessible via the terminal (of course).  The Lattice QuickStart guide says that the serial connection parameters are 8 data bits, no parity, 1 stop bit, no flow control and a baud rate (bits per second) or 115,200.  Most of the parameters, except for the baud rate, are rather standard, so I just have to specify the baud rate when I start a new screen session.

screen /dev/tty.usbserial-A600cGQW 115200

Now I just have to press the reset button on the XP2 board:

Voila!  I am now hooked up to the factory-installed demo application.  Next I will use some custom C software and make sure I can interact with the demo application.

Dissappointment with GNAT

I thought I would try using Ada to develop a simple serial port program for accessing my Lattice XP2 development board.  Imagine the disappointment I experienced when I saw this on my terminal:

It turns out that GNAT only supports the serial port module on Windows and Linux and it is not implemented for GNAT on Mac OS X.  How hard is it to support serial ports on a Mac?  After all, Mac OS X uses the standard POSIX interface.

USB to Serial Port for Mac OS X

The LatticeXP2 development kit I selected has an RS232 connector and buffer hooked up to the FPGA.  A primitive interface, you might say?  Having professionally developed both USB and PCI solutions, I was searching for a development board that had the simplest interface with the FPGA.  Why?  Well, I don’t want to spend 50% of the time tweaking kernel mode device drivers and data transfer libraries–I want to focus on the FPGA.  What could be simpler than the good ol’ serial port, right?  Every telecom application I’ve worked on has had hardware with a serial port for debug and engineering management.

It turns out that the PC industry really feels that serial ports are legacy, however.  Apple abandoned serial ports over a decade ago, and recent Dell desktop PCs don’t even have serial and parallel ports.  For applications requiring legacy ports, we are recommended to use USB-to-Serial Port adaptors.  Having worked with such devices since 2003, I can tell you that many are flaky and high unstable.  The biggest problem I’ve seen is that the drivers are of questionable quailty. I’ve tried many devices that resulted in a Windows blue-screen of death, in modern Windows NT-based OS (WinNT/2k/XP/Vista/7), and these days the only thing that can really bring down your system to the blue-screen is a kernel-mode error–or more likely- a bad device driver.

Over the years, I’ve found that USB-to-Serial devices that implement an FTDI solution are of superior quality.  FTDI is based out of the UK and provides device drivers for all flavors of Windows, Mac OS and Linux.  I highly recommend FTDI-based USB-to-RS232 cables if you’ll be using a Mac; just purchase your cable, download the latest driver and follow the installation guide and you’ll be up and running in no time.

After you install the driver, plug in the device and use the System Profier (in Applications->Utilities) to verify the device is recognized:

While there is probably a way to access the serial ports through Mac programming libraires like Cocoa and Carbon, for my purposes I’m going to keep things simple and use the POSIX interface.  You can determine the interface using the Terminal application and executing the follow commands:

cd /dev
ls cu.usbserial*
ls tty.usbserial*

The above should match devices with a serial number following the search pattern above.  The cu.usbserial* device is a call-up interface that you would use if your were dialing into a modem (ah, the good ol’ days!).  The tty.usbserial* interface is for listening to a device on a serial interface, and this is the interface I will use to communicate with my Lattice FPGA.  My kit has not yet arrived in the post, so I think I’ll start working on a simple terminal application to access the tty interface.