The Acme Systems shipping office will be closed for holidays from 14 august to 22 august
PLEASE NOTE: This article is obsolete or related to a discontinued product.

The FOXBONE interfacing protocol

written by Sergio Tanzilli and Roberto Asquini

FoxBone is the way to exchange data between Fox and FOXVHDL boards

The FoxBone interfacing protocol has been designed to realize a flexible unified electrical interface from the FOX Board towards several custom designed hardware peripherals embedded in reprogrammable FPGA components inside the Fox VHDL Board

Fox Board I/O capabilities

The FOX Board exports some digital lines through its two 40 pin headers: J6 and J7. The main usable blocks to interface external logic hardware are PortA, PortB and the GPIO or General Purpose Input Output port (ETRAX 100 LX I/O information). The possible throughput of the I/O interface depends from the software part. In userspace, using the gpio kernel driver, the signals are able to run in the order of some kHz. To achieve much better performance (in the order of magnitude of several megabytes per second) you have to write a kernel module to drive directly the IOg lines.

Fox Board + Fox VHDL

The coupling of Fox Board and Fox VHDL board permits to enhance a great deal the possibilities of fast I/O towards external peripherals, since the Fox Board can delegate to the hardware functions programmed inside the Fox VHDL (through the Fox Board itself) all the hi-speed functionalities needed by the user project that the Linux board could not be able to cope with for lack of real time capabilities. The possibility to act at nanosecond speed with state machines and custom designed hardware functions directly inside the FPGA frees the Fox Board from the real time tasks and let it for its best role: to communicate through the LAN and internet protocols with other computers and to concentrate on higher level tasks and functions. The capability to reprogram on the field the hardware inside the Fox VHDL FPGA FLASH memory through the same Fox Board and without needs for special hardware for the programming, opens up new possibilities for the designer that can re-configure and upgrade not only the software but also the hardware parts of its application even after deployment on the field.

A convenient and efficient way of communication between the Fox Board way of communications is needed to take advantage of this flexibility without sacrificing generality and speed. For this reason we present the FOXBONE bus architecture, a very simple and convenient protocol that permits the data exchange between Fox Board and Fox VHDL in a register oriented structure inside the FPGA. A special designed kernel driver named "foxbone" is available for userspace applications to communicate with the hardware functions registers inside the FPGA at higher speed respect to the use of the GPIO kernel driver.

It is possible to build specific kernel drivers for the hardware peripherals inside the FPGA so that application programs in userspace can use them seamlessly and very easily at max speed.

Architecture of the FOXBONE

Addressable interface

The possibility to realize custom hardware logic (embedding several, separate and all running together in parallel functional blocks) connected to the Fox Board through FPGA components poses immediately a requirement for the designer: to define rules to communicate with this custom logic blocks in an ordered and standard way so to cope with the different requirements of the single block without using separate interface wires for every single function.

Enabling an effective way of communication between the Fox Board and several custom logic blocks is a complex task since it has to satisfy several constraints. The architecture power and size of nowadays FPGA components lets to design and embed several different functions inside the same FPGA component that will work all in parallel, the FoxBone protocol should be flexible enough to let the Fox Board to effectively communicate to those different hardware functions with a limited number of electrical wires and to provide room for other additional ones without have to redesign the protocol. Another rule of design is to not impose policy on the protocol so to let it free for designer customization and to offer a common base leaving extension space for special needs without loss of generality.

Addressing scheme

The solution here proposed is to have an addressable 16 bit I/O (input/output) asynchronous interface to a series of 16 bits registers inside the FPGA which control the internal functions. The meaning of the registers and the number of them for every function is function specific so no assumption or policy is forced on the FoxBone bus. Through it the Fox Board will be able to read from a maximum of 65536 FPGA 16 bit registers (to be written by the FPGA) and to write to up to 65535 FPGA 16 bit different registers to be read from the programmable logic to directly control it.

To be able to reuse different functions without (if possible) rewrite the VHDL code we are suggesting a fixed addressing numbering space for every function we will present on these pages. So for example picking up the VHDL code for function1 that uses registers 3000h and 3001h and function4 that uses register from 2340h to 2347h, since both are using the Fox Bone interface they will cohexist inside the FPGA chip without problems. Also the kernel drivers will refer for every specific function to their fixed address, so it will be possible to assemble different ready built VHDL functions inside the FPGA from our library and continue to use our kernel drivers to access them from userspace programs without addressing problems. A range of 65000+ addresses should be enough (at least for these first releases of the protocol) to accommodate several different functions.

Inside the FPGA we will arrange the logic for a 16 bit address register and the decode logic for every data register needed by every function.

To limit the number of I/O lines the architecture of the bus (FOXBONE_BUS) is based on 16 bits for multiplexed addresses and data. So the Fox Board foxbone software will present first the desired address to be used, then it will write it in a special address register inside the FPGA. Then the Fox will read or write from/to this register preselected using the 16 I/O lines as data lines.

After loading in the first phase of the 16 bit I/O bus transaction the desired address, a line (ADDRESS_WRITE) will be used to write this required FPGA register address to be written or read, inside the FPGA address register.

Another line (DATA_WRITE: active high) will be used in the second part of the transaction from the Fox to store the data in the previously addressed register of the FPGA.

The signal (DATA_READ: active high) is used instead from the Fox to read the previously address selected register from the FPGA.

A Reset signal (RESETN: active low) can be used from the Fox Board to initialize all the FPGA hardware registers and interface logic to a defined initial state.

An interrupt line to the FOXBOARD (active high) will enable the requesting of services for data transfers to/from the FOXVHDL with a mechanism to enable multiple interrupt sources through a interrupt registers scheme readable from the Fox Board.

Reserved Registers

There are a few FoxBone registers that have been reserved for administrative purposes:
  • address 0x0004 FoxBone release version (has to be hardcoded inside the FPGA). The 16 bits are organized in nibbles as follows:
    xxxxxxxx.xxxx.xxxx The most significant eight bits are the FoxBone release version (in Binary Coded Decimal from 0 to 99). The 4 bits in the middle are the subrelease number (also in Binary Coded Decimal from 0 to 9). The least significant 4 bits are the subsubrelease (also in BCD from 0 to 9). For example release 0.7.0 will be 0000000001110000b or 0x0070. Realease 1.4.9 will be: 0000000101001001b or 0x0149
  • address 0x0005 first hardware application word
  • address 0x0006 second hardware application word
  • address 0x0007 third hardware application word
The hardware application words are also hardwired inside the FPGA and are readable back from the Linux FoxBone driver so to be possible to align the software and the hardware versions and avoid misversioning during coupling of application software and application hardware inside the FPGA. The format for these fields will be released soon.

Organization of the FoxBone interface protocol (release 0.7.0)

(In the following we will consider signal directions from the FoxBoard point of view)
  • 16 bit address+data interface.
  • 3 output control signals: DATA_READ, ADDRESS_WRITE, DATA_WRITE (all active high), respectively to Read data from the FOX VHDL, to store the address of the required register to be used and to write data in the selected FOX VHDL register.
  • 1 input control signals: INT (active high) to interrupt the Fox CPU for immediate service requests.
  • 1 output Reset signal (RESETN: active low): to reset all the FPGA registers.
For the 16 address/data multiplexed bits of the FOXBONE_BUS we are using the external GPIO bits of the Fox Board from IOG8 to IOG23 (see Fox headers J6 and J7 ).
DATA_READ:     Og1 (Fox J6:23) (Fox output)
ADDRESS_WRITE: Og4 (Fox J6:25) (Fox output)
DATA_WRITE:    Og2 (Fox J6:21) (Fox output)
INT:           PA0 (Fox J7:38) (Fox input)
RESETN:        Og3 (Fox J6:26) (Fox output) 

FoxBone Logic Flow and example diagrams of working

This section describes the sequential phases of the protocol interface between the Fox Board and the FPGA.

Starting from all the five control signals (4 output and 1 input from the Fox side) in the low logic state we are in the reset state for the FPGA. Now after raising the Reset signal we will have the FOX VHDL ready to exchange data on the FoxBone interface with the Fox Board.

Writing a data word on the FPGA address 0x8000 and read it back

Reset phase: With any value (in the present specification) on the FOXBONE_BUS lines, pulse the RESETN line down once to reset all the logic registers inside the FPGA.

Then, starting from all signals low and RESETN high, the software driver program on the Fox Board has to do the following steps to write on the FPGA register 0x8000 through the Fox Bone and read it back:

  • Set the address value 0x8000 on the 16 FOXBONE_BUS address/data bits.
  • Set high and then low the ADDRESS_WRITE signal to store the address 0x8000 in the address register of the FPGA.
  • Set the desired data to be stored in the 0x8000 register on the 16 FOXBONE_BUS lines.
  • Set high and then low the DATA_WRITE signal to store the desired value in the FPGA 0x8000 register.
  • Release the FOXBONE_BUS to high impedance state (input state for the Fox) to prepare it for the reading phase from the FPGA.
  • Rise the DATA_READ signal to enable the FPGA output register selected to put the desired data on the FOXBONE_BUS.
  • Read the FOXBONE_BUS containing now the FPGA 0x8000 register value.
  • Lower the DATA_READ signal to finish the reading phase and make the FPGA bus lines to return to a high impedance state.
This sequence of operations is shown in the following diagram.

The final signal values will be all low except for the Reset signal

Repeat all the above steps to write or read in other registers.

Writing multiple words on the FPGA address 7000h

The diagram below describes how the Fox Bone protocol implements a multiple write to the same register of the FPGA. This can be useful for example to fill a buffer inside the FPGA to fast update the same register (as in the case of a PWM register when the fast update interests a single PWM generator address).

We are using this mode for example to transfer video buffers to the FOX VHDL Board from the Fox. Inside the FPGA has been realized a logic that stores the value on the bus at the rising edge of the DATA_WRITE signal and increments an internal counter (used as internal buffer address) on the falling edge of the DATA_WRITE signal.

FOX VHDL side: Implementation example in VHDL language of the FoxBone protocol inside the FPGA

Here is a sample VHDL code realizing, inside the FPGA, the FoxBone read/write register 0x8000 other than the release registers 0x0004 through 0x0007 above explained.