MultiMac Draft Web Page

DJ Greaves, S Suh, D Gordon, N Khan, R Leiser.

The HanLan is sponsored by Virata .

Summary

MultiMac is a project to investigate media access control and baseband communication link technology from the point of view of a set of loadable modules. The MultiMac environment will allow both rapid prototyping of communications systems and implementation of flexible and reconfigurable communication systems.

MultiMac will start with a set of modules implemented in C++ and Verilog, where the Verilog has often been synthesised from C++. The modules represent all the common functions found in communications systems. The modules will be assembled to form working systems, both in simulation and on FPGAs.

Aim

Our aim is to answer the following questions:
  • Is highly-dynamic plugging and reconfiguring of the low-levels of a networking stack useful and if so in what way ?

  • How much meta-bandwidth (network control traffic) is needed and why ?

  • For multi-access networks, can we achieve fine-grain sharing and hence good QoS control when encumbered with advanced modulation techniques originally used only for point-to-point links ?

  • Are combinations of solutions useful to meet heterogeneous traffic requirements and can these combinations be automated ?

  • Can we develop a generic architecture for communications where the timing recovery, MAC, modulation renegotiation and QoS control framework is automaticly generated from our choice of data processing components ?

Targets

We would aim to encode the following communications systems as real examples in our system. We would also aim to to operate several at once, or parts of several at once, to evaluate tradeoffs.
  • ATM25
  • Ethernet 10baseT
  • HomePNA 2.0
  • xDSL and HDSL2
  • HanLan
  • CAP51
  • Firewire P1394
  • G.703 E1
  • An ATM switch

Note that we have deliberately chosen a mixture of LAN and advanced point-to-point link technologies, together with the ATM switch and Firewire, which has active nodes.

Components Needed

The following list has some of the data processing modules needed in our system:

  • Physical media access port (access to media)
  • DAC
  • ADC
  • Line filter, analog section model
  • Replicator and decimator (integer ratios and cyclic prefixes)
  • Sample rate conversion
  • FFT
  • FIR, IIR, DFB, Error Predictor and Whitener block
  • Echo canceller block
  • Interleaver (for RS coding etc)
  • FEC and Reed Solomon block
  • Bit repacking blocks of various types
  • Viterbi block
  • Detector block (PAM and constellation decoder)
  • Encoder block (PAM and constellation encoder)
  • Framing block
  • CRC and Error Detection block (including CRC32 and HEC8)
  • Block coder (4B5B, HDB3, Manchester etc.)
  • ATM SAR

The meta-blocks that do not sit in the data path but which control it include the followings. As stated above, an aim is to automatically generate these blocks as a result of our decisions (dynamic decisions even) regarding the data path components.

  • Timing recovery, VCO and master clock
  • Power control
  • QoS control
  • Transmit order schedule
  • Adaptive and reactive controllers for filter coefficients, FEC and bit packing
  • Preamble and midamble insertion

Physical Media

In the simulation, a media simulator interconnects the media access ports. We have a lumped element simulator and an analytical simulator that can be used to model various wiring topologies and types of wire. In the implementations, we can fit various types of wire between the terminals of our FPGA boards.

Data Sources

Data sources will be PRBS generators, real network traces and connection to real networks of the real implementations.

System Architecture

The system architecture is a methodology for communication system design and is seen as one of the main reseach results of the project.

Each block will normally be written in C++. A block will have an input port, an output port, a management port and a description vector.

The C++ description includes details of the local state and the algorithm to be performed to move data from the input port to the output port.

The management port includes the ability to start and stop the block, to recover it from a known error, to flag an error and to context swap the block when it is about to handle a different logical stream.

The description vector enables the system to know what types of data may flow through the input and output ports. The C++ type system is not sufficient. The type information must include the maximum and minimum rates of data, whether it is in analog or digital form, whether it is continuous, gapped or framed and noise information.

Many of our communications blocks are concerned with overcomming noise. A combination of blocks can be checked for consistency using a predicate function on the port vectors, which includes their noise performance. The definition of this predicate function is seen as a significant research result. We model the following forms of noise in our architecture:

  • Guassian additive white noise
  • Burst analog noise
  • Erasures, correlated and uncorrelated
  • Bit errors, correlated and uncorrelated
  • X-Talk from HAM Radio, VDSL and HomePNA sources.

Experiments

Experiment 1: Automatic MAC synthesis

Given a set of communications blocks which we wish to use in a multi-access LAN modulation system, can we generate the MAC semi-automatically ?

Evaluation criteria: line throughput, latency, granularity of sharing.

Experiment 2: Random MAC evaluation

We will randomly generate a large number of communications systems and see if any work better than those designed by hand (or committee).

Final Remarks

This is an ambitious project based on a starting idea from Mr Suh. We shall have to think on it for a week or two now.

End of document. Computer Laboratory HAN pages .