TosNet framework

About the TosNet project

TosNet is developed at the University of Southern Denmark, and is intended to:

• Reduce the development time of experimental robotic controllers to arrive faster and cheaper at fully working demonstrations of new technology and concepts.
• Increase the reusability of experimental systems and components, thus increasing the life-span and utilization of these, and reducing the amount of redundant work.
• Ease the use of interacting with experimental low-level controller, to open experimental robotics up to a wider audience, and to allow high-level developers a tighter integration with the physical robots, without involving them in the low-level particulars of embedded systems.

Until now TosNet has only been used inhouse for a number of projects. We would very much like to get feedback, opinions, ideas and comments from others though - anything will be appreciated!

Also have a look at uTosNet for a single-node "lite"-version of TosNet.

- Simon Falsig
University of Southern Denmark

Description

TosNet is a common name for the combination of an experimental control protocol, network and framework, mainly intended for use in research and development of modular, robotic systems. It provides a very easy-to-use way of interfacing various forms of electronic hardware to each other and to high-level applications on for instance a PC.

The name TosNet is used for a number of things:

• The TosNet protocol
  The TosNet protocol is the specification used for communicating data around a TosNet network. The protocol consists of a datalink layer and an application layer, each providing different services. The TosNet datalink layer supports ring-coupled networks, and performs the initial configuration of these. During transmission it provides a network watchdog and an 8-bit CRC error detection. The TosNet application layer on the other hand supports the isochronous transmission of data between nodes, along with various more advanced features such as double-buffered memory and asynchronous node-to-node and broadcast channels.


• The TosNet network
  The TosNet network is our current FPGA-based implementation of the TosNet protocol, and of a physical layer to support it. The implementation is completely FPGA-based, apart from the physical transmission components. For this, optical toslink transmitters and receivers from Toshiba are used, which can be connected directly to most FPGA chips. The physical layer provides an effective datarate of up to 10 Mbps, using an 8b10b encoding scheme and data scrambling to avoid DC offsets, and 4 times oversampling for clock recovery.


• The TosNet framework
  The TosNet framework is a complete suite of the TosNet protocol/network, FPGA-boards and add-on modules, and software parts, that make it easy to connect a number of different types of hardware to each other and to high-level applications on a PC.

The different parts have been made as a whole, and with each other in mind, but can (in theory at least) be implemented with other protocols, networks and frameworks also.

Currently available on SVN

Currently, the following files are available for download from the project SVN server:

• Documentation:
• TosNet userguide
• Gateware:
• TosNet rev3.2 (with premade ip-cores for xc3s400an-fg400 and xc6slx16-csg324 devices)
• TosNet rev3.2 MicroBlaze Peripheral, including drivers
• Hardware:
• Board designs for a modular FPGA board for a xc3s400an-fg400 device, and two different add-on boards

Coming soon:

• Documentation:
• Various updates
• Gateware:
• Testbench
• Software:
• Various software files for use with the Ethernet and USB gateways

Features

• 10 Mbps data rate
• Up to 15 nodes, each with up to eight 256 bit registers (128 bit read(readable from all nodes), 128 bit write(writeable from master node)).
• Cycletimes around 50 us (20 kHz cycle frequency) are achievable, depending on node and register count (typical cycletimes are 100-200 us (5-10 kHz))
• Cycletime jitter is (50 ns * node position in ring after master)
• Full duplex asynchronous channel with broadcast possibility, data rate of 12 bytes per cycle.
• 8 bit CRC error detection
• Synchronization between all nodes within a few microseconds (max 90 ns * number of slave nodes)
• Configurable network watchdog, restarts the network after a certain interval of network inactivity
• Distributed as VHDL code and CoreGen .xco files
• Physical layer uses Toslink optical cables for complete noise immunity in the transmission lines
• Dynamic master-slave protocol, a master node is automatically assigned at network reset
• Tested on: XC3S1500 (TosNet rev1), XC3S1000 (TosNet rev1/3), XC3S200 (TosNet rev1), XC3S250E (TosNet rev1/2), XC3S400AN (TosNet rev1/2/3), XC6SLX16 (TosNet rev2/3), XC6SLX45T (TosNet rev3)
• Protocol is completely implemented in the FPGA (only five additional external components are needed pr node)
• Controlapplications for PC available when using a Spartan3 PCI Express Starter Kit, the Xilinx Spartan-6 FPGA SP605 Evaluation Kit or similar
• Requires only a 50 MHz clock, and reset signal
• External interface consists mainly of a blockram interface
• MicroBlaze support through custom peripheral and driver

Revisions

• Revision 3.2 (initial release)
  A problem discovered with revision 3/3.1 caused certain node configurations (specifically networks with four nodes), to have very frequent communication breakdowns. This was traced to the jitter/latency optimizations implemented in revision 3, which have now been relaxed a bit. Synchronization for all nodes now happens within ~(number of nodes * 90 ns), with the jitter being ~(node address * 50 ns) for a given node. More exhaustive tests will be performed to make sure that everything now works as intended though. Additionally, the input data buffer in the datalink layer has been reduced from 8+1 bytes to 1+1 bytes. With the current application layer the large buffer was not at all necessary, and the implementation of it had been a thorn in my eye for some time now. Reducing its size decreased the slicecount by about 20 (in a Spartan6), and the RTL schematic of the datalink layer is actually viewable now :)


• Revision 3.1
  Exchanged the 8b10b encoder/decoder modules with homemade ones. The existing ones were from Xilinx and could not be distributed without a license, which was not optimal with regard to being distributed on OpenCores. The new ones have the exact same interface, and close to the same functionality. The only exceptions are that not all control symbols are supported, the code error detection is not completely failsafe (in the case of the primary/alternate encoding of HGF symbol "111"), and that the decoder is not able to provide a disparity error. Neither of these features were necessary though (let alone used;). The new modules even take up a bit less space than the old ones.


• Revision 3
  - Asynchronous communication added. Each cycle up to 12 bytes of data are sent from the master to a single specified slave node, or broadcast to all slavenodes. A FIFO buffer is used for both input and output. The transmission is not fail-safe though, as no error-check is performed on the data, and as data may be silently discarded if the receive buffer is full. A high-level protocol should thus be implemented if transmission safety is to be guaranteed.
  - MicroBlaze interface through the PLB bus. Drivers include support for full access to shared memory block, and functionality for using the asynchronous channel.
  - Possibility of disabling both master, slave and asynchronous functionality in each node, to minimize the size of the design.
  - Revised clocking scheme. Now uses clock enables instead of derived clocks, which is the "right" way to do it, as all parts of the design now use the same 50 MHz clock. It also reduces the number of clock lines needed.
  - Much improved jitter and synchronization performance. For a three-node network, the cycle-to-cycle deviation (jitter) is reduced to at most 60 ns, while synchronization for all nodes in the same network now happens within ~80 ns (~1.6 us with revision 2).


• Revision 2
  Features a redesigned physical layer, which now uses 8b10b encoding instead of 4b5b/NRZI encoding, which seems to have eliminated previous problems with offset errors. The physical layer has also been simplified by removing the MII interface, and instead using an 8-bit ad-hoc interface (similar to MII though). Thus the protocol stack uses an 8 bit datawidth all the way, simplifying quite a few elements.


• Revision 1
  Original version