FSK bridge example

This should include everything needed to build the FSK bridge example from scratch.

1) Open existing hdl/quartus/bladerf.qsf project in Quartus
        a) Generate the Nios core
                i) Tools -> QSys -> File -> Open -> navigate to ./hdl/fpga/ip/altera/nios_system/nios_system.qsys
                ii) After opening qsys file, go to Generation tab, click the "Generate" button
        b) Compile the embedded Nios image
                i) Tools -> Nios II Software Build Tools for Eclipse
                        I)   File -> Import -> General -> Existing Projects into Workspace -> Next
                                -> Browse to checkout root directory -> check both lms_spi_controller and lms_spi_controller_bsp
                                -> Finish
                        II)  right click lms_spi_controller_bsp -> NIOS II -> Generate BSP
                        III) right click lms_spi_controller -> Build
                        IV)  right click lms_spi_controller -> Make Targets -> Build... -> select mem_init_generate -> Build
        c) Synthesize FPGA image
                i) Processing -> Start Compilation

2) Compile driver and user mode applications
        a) cd linux/kernel ; make ; inmod bladeRF.ko
        b) cd ../apps; make
        c) To program the fpga execute ./simple_load c4images/blink.rbf
                i) Load bladerf.rbf from the quartus output_files directory

3) Use bladeRF's UART as an FSK bridge!

NB. The firmware upgrade utility does work, only use it on valid .img files.
hdl: add RX and TX fifos

The RX fifo is a 32bit, 1024 element, dual clock domain FIFO.
The TX fifo is a 32bit, 4096 element, dual clock domain FIFO.

These values are the lowest values worked across all of the performance tests.
hdl: add GPIF and RX/TX signaltap STP file

This can be used to look at the GPIF bus and all of the state machine logic that
goes along with it.
hdl: nios: add RF RX, and  Nios 2 core as SPI master

This commit includes massive changes to the firmware running on the Nios 2 core
in the FPGA. The Nios 2 core will respond to UART requests sent to it from the
FX3 and it will turn them into SPI, I2C, and GPIO reads and writes based on the
uart "packet".

The UART protocol employed by the FX3 and Nios 2 Core is as follows:
   Byte 0) "Magic" byte is 'N'

   Byte 1) Indicates the direction and intended device of each subsequent
           operation. Count is number of struct uart_cmd data structures that
           will be transferred.
   //  | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |$
   //  |  dir  |  dev  |     cnt       |$

   Byte 2..N) The following byte pairs are struct uart_cmd, which consist of
           addresses and values;
   struct uart_cmd {$
       unsigned char addr;$
       unsigned char data;$
   };$

As an example, if you are looking to write 0xC0 to register 0x30 on the Si5338,
the UART packet you would have to send would have to look like this:
   Byte 0) 'N'
   Byte 1) UART_PKT_MODE_DIR_WRITE | UART_PKT_DEV_SI5338 | 0x01;$
   Byte 2) 0x30$
   Byte 3) 0xC0$
fx3: UART-SPI bridge baud rate change

115200 is the "slowest" fast speed we'll use, it should be able to go higher
however the Nios 2 Core has to be tweaked.
hdl: add can and should RX/TX

These variables control if an RX or TX transaction can occur (can_perform_*) due
to FIFO requirements being met. Should_perform_* determines if it is fair for
that particular operation to execute, ie. it is not fair to the RX queue if the
TX queue uses the GPIF bus twice in a row if the RX queue has data pending.
However, if there is no RX data pending, it is fair for the TX queue to use two
subsequent GPIF bus time slots.
hdl: add debug utility to conduct line speed testing of bladeRF

Enabling debug_line_speed causes the FPGA to toggle RX and TX DMA pins that go
the FX3 so that it can determine the maximum read and write speeds. The FPGA
does this without driving the GPIF bus.
hdl: add TX path

This commit adds the HDL state mechanie necessary to perform TX transactions.
hdl: add TX FIFOs and additional queueing controls

This commit expands on the previous commit and adds the TX FIFOs.

This commit also upgrades the repostiory to Quartus 12.1 along the way.
hdl: change from 15KLE to 40KLE part

This commit replaces support for the 15KLE board in favor of the pre-production
40KLE board. Commits from this point on are not guranteed and are likely to not
work with the prototype boards.
hdl: add Avalon compatible I2C controller from OpenCores

This is a direct copy from the "I2C controller core" OpenCore project found at
http://opencores.org/project,i2c
quartus: add IPX file

The IPX file tells Qsys where to look for the Avalon compatible I2C controller
core.
hdl: add I2C controller to qsys project

This commit adds I2C controller functionality to the Nios 2 Core.
hdl: nios: enable I2C controller

This commit ties the I2C controller to the Nios 2 Core and updates the system
pinout.
hdl: update BSP build scripts

After Qsys modification a BSP update is necessary to ensure that the Nios 2
firmware builds correctly.
hdl: add Si5338 support to the nios core

This commit adds UART packet protocol support for the Si5338 on the Nios 2.
Since the Si5338 sits on an I2C bus, the Nios firmware intializes the I2C core
as well.
new USB ID

The OpenMoko project has given us a PID within their VID.

The new USB ID is:
VID 0x1d50
PID 0x6066
linux driver: add RX and TX buffering

This commit adds RX and TX functionality for the bladeRF. The driver uses a ring
buffer of URBs that are allocated when the driver probe()s each bladeRF. At the
moment the driver allocates 1024 4KB URB buffers for RX and TX, meaning that
each bladeRF requires at least 8MB of RAM. The total number of allocated URBs
(NUM_DATA_URB) can be lowered when operating at USB 2.0, but the number should
be a power of 2 for the ring buffer to work.

Test read/write speeds of 320MB/s were observed with this driver on an Intel xHCI.
linux driver: add support for writing to the LMS, Si5388, and the VCTCXO

This commit adds the ioctls necessary to configure the LMS, Si5338, and VCTCXO.
The FX3's second endpoint is configured to receive and transmit things over
UART. At the other end of the UART is the Nios II core in the FPGA. The Nios
core simply parses the read or write operation and sends it to the appropriate
device.

NB: At least a 16byte URB has to be sent to the FX3 for it to send data on UART
due to a minimum buffer count enforced by the GPIF's DMA controller.

The UART packet format is as follows:
   Byte 0) "Magic" byte is 'N'

   Byte 1) Indicates the direction and intended device of each subsequent
           operation. Count is number of struct uart_cmd data structures that
           will be transferred.
   //  | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |$
   //  |  dir  |  dev  |     cnt       |$

   Byte 2..N) The following byte pairs are struct uart_cmd, which consist of
           addresses and values;
   struct uart_cmd {$
       unsigned char addr;$
       unsigned char data;$
   };$

As an example, if you are looking to write 0xC0 to register 0x30 on the Si5338,
the UART packet you would have to send would have to look like this:
   Byte 0) 'N'
   Byte 1) UART_PKT_MODE_DIR_WRITE | UART_PKT_DEV_SI5338 | 0x01;$
   Byte 2) 0x30$
   Byte 3) 0xC0$

Before sending this packet to the second endpoint, the packet would have to be
zero padded to the nearest 16 byte boundary.
fx3 firmware: enable 32bit GPIF

Due to an unconfirmed bug in the SDK's support for the GPIF II, it is not
xpossible to switch a 16bit GPIF over to 32bit funtionality once the FX3
enumerates. As a temporary work around, the firmware now uses a 32bit GPIF bus
when loading the Cyclone 4. This introduces some issues with headless execution
because enabling 32bit mode disables the SPI peripheral, which is how the FX3
communicates with the SPI flash. Conversely, in headless mode the unit has no
need to enter 32bit mode because it is not connected via USB3.0, therefore
during headless mode the bladeRF can choose to configure the GPIF 2 into 16bit
mode.