Changes between Version 3 and Version 4 of WARPLab/Framework/Modules


Ignore:
Timestamp:
May 15, 2013, 3:03:53 PM (11 years ago)
Author:
chunter
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WARPLab/Framework/Modules

    v3 v4  
    66[[Image(typical.png,width=800)]]
    77
    8 The above figure shows how these 5 modules relate to one another in the context of a typical WARPLab example script. Additionally, the figure shows another framework element, the {{{Trigger}}}, which is not a part of a WARPLab node, but is one way of coordinating action among the multiple nodes in a WARPLab experiment.
     8The above figure shows how these 5 modules relate to one another in the context of a typical WARPLab example script. A module generally consists of two paired components: a software and hardware design that runs on the board coupled with a MATLAB class that is used to issue commands and handle responses from the hardware/software pair that runs on the board.
     9
     10Additionally, the figure shows another framework element, the {{{Trigger}}}, which is not a part of a WARPLab node, but is one way of coordinating action among the multiple nodes in a WARPLab experiment.
    911
    1012=== Node ===
    1113
    12 A {{{Node}}} is responsible for broker commands to other modules within the node and collect responses to those commands to deliver back to the user. The other modules in the system belong to the {{{Node}}} module. Furthermore, the {{{Node}}} may also process commands for the node itself and not any of the other modules. The WARPLab Reference Design's implementation of a {{{Node}}} module is [wiki:../../Reference/Node described here].
     14A {{{Node}}} module is responsible for broker commands to other modules within the node and collect responses to those commands to deliver back to the user. The other modules in the system belong to the {{{Node}}} module. Furthermore, the {{{Node}}} may also process commands for the node itself and not any of the other modules. The WARPLab Reference Design's implementation of a {{{Node}}} module is [wiki:../../Reference/Node described here].
    1315
    14 === Trigger ===
    15 [[Image(trigger.png,width=800)]]
     16=== Baseband ===
    1617
    17 A {{{Trigger}}} is an object from the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_trigger.m wl_trigger.m] abstract class. Currently, the only class that subclasses from this abstract class is [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_trigger_eth_udp_broadcast.m wl_trigger_eth_udp_broadcast.m]. This is a simple class that contains an ID (provided by [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_trigger_IDs.m wl_trigger_IDs.m]) and a method for sending the trigger through a broadcast {{{Transport}}} object.
     18A {{{Baseband}}} module is the processing component that is meant to deal with the samples being sent to and from the radio interfaces available to a node. The WARPLab Reference Design's implementations of a {{{Baseband}}} modules are [wiki:../../Reference/Baseband described here].
     19
     20The MATLAB implementation of {{{Baseband}}} modules are intended to inherit from the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_baseband.m wl_baseband.m] abstract class.
     21
     22=== Interface Group ===
     23
     24An {{{Interface Group}}} module is the processing component that deals with configuring radio interfaces. The WARPLab Reference Design's implementations of a {{{Interface Group}}} modules are [wiki:../../Reference/Interface described here].
     25
     26The MATLAB implementation of {{{Interface Group}}} modules are intended to inherit from the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_interface_group.m wl_interface_group.m] abstract class.
    1827
    1928=== Transport ===
    20 [[Image(transport.png,width=800)]]
    2129
    22 A {{{Transport}}} is an object from the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_transport.m wl_transport] abstract class. Currently, four subclasses of wl_transport exist:
     30A {{{Transport}}} module is responsible for handling messages to and from the WARP hardware. Typically, these messages are exchanged with a host PC. The WARPLab Reference Design's implementations of a {{{Transport}}} modules are [wiki:../../Reference/Transport described here].
    2331
    24 Unicast Transports:
    25  * [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_transport_eth_udp_java.m wl_transport_eth_udp_java.m]
    26  * [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_transport_eth_udp_pnet.m wl_transport_eth_udp_pnet.m]
     32The MATLAB implementation of {{{Transport}}} modules are intended to inherit from the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_interface_group.m wl_interface_group.m] abstract class.
    2733
    28 Broadcast Transports:
    29  * [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_transport_eth_udp_java_bcast.m wl_transport_eth_udp_java_bcast.m]
    30  * [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_transport_eth_udp_pnet_bcast.m wl_transport_eth_udp_pnet_bcast.m]
    31 
    32 The pnet/java variants are functionally identical, but use either compiled Mex code or built-in java code, respectively, for opening UDP sockets. The unicast and broadcast variants serve different purposes:
    33 
    34 ==== Unicast Transport ====
    35 A Unicast {{{Transport}}} object is attached to the {{{Node}}} and is responsible for sending to and receiving from a specific IP address and port associated with a WARP node. Additionally, the unicast objects will process [wiki:../../Commands/Transport#CommandListandDocumentation transport commands] brokered by the {{{Node}}}.
    36 
    37 ==== Broadcast Transport ====
    38 A Broadcast {{{Transport}}} object does not process any commands, but contains a method for transmitting to more than one WARP node at once. This is used by the {{{Trigger}}} object as well as the [wiki:../../Utility#wl_initNodes wl_initNodes] utility function.
    39 
    40 === Interface Group ===
    41 [[Image(interface.png,width=800)]]
    42 
    43 An {{{Interface Group}}} is an object from the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_interface_group.m wl_interface_group.m] abstract class. Currently, the only subclass of wl_interface_group is [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_interface_group_X245.m wl_interface_group_X245.m], which allows control over the 2.4/5GHz transceivers available on WARP. An "interface group" is a collection of multiple identical interfaces. For example, on WARP v3 hardware, a single wl_interface_group_X245 object is used to control both of the on-board interfaces (RFA and RFB) and the two extra interfaces (RFC and RFD) provided by the [wiki:HardwareUsersGuides/FMC-RF-2X245 FMC-RF-2X245 card] if it is mounted on the WARP v3 carrier.
    44 
    45 === Baseband ===
    46 [[Image(baseband.png,width=800)]]
    47 
    48 A {{{Baseband}}} is an object from the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_baseband.m wl_baseband.m] abstract class. For the WARPLab Reference Design, we provide the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_baseband_buffers.m wl_baseband_buffers.m] subclass that provides buffers for sending and receiving custom I/Q waveforms provided by MATLAB. [wiki:../../../Extensions#AdvancedExtensions Advanced user extensions] are intended to replace wl_baseband_buffers with custom classes that support user-added baseband processing running on WARP hardware.
     34A {{{Transport}}} is an object from the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_transport.m wl_transport] abstract class.
    4935
    5036=== Trigger Manager ===
    51 [[Image(trigger_manager.png,width=800)]]
    5237
    53 A {{{Trigger Manager}}} is an object from the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_trigger_manager.m wl_trigger_manager.m] class. This object allows WARPLab scripts to associate or deassociate particular triggers on particular WARP nodes. For example, a WARPLab script can create two {{{Trigger}}} objects and have a subset of nodes be sensitive to each. This way, a {{{Trigger}}} need not apply to every {{{Node}}} in the network -- it only applies to the ones whose {{{Trigger Manager}}} objects have been configured to allow the {{{Trigger}}}.
     38A {{{Trigger Manager}}} module is responsible for managing how a WARP node's actions are coordinated with other nodes that are in an experiment. The WARPLab Reference Design's implementations of a {{{Trigger Manager}}} modules are [wiki:../../Reference/TriggerManager described here].
     39
     40The MATLAB implementation of {{{Trigger Manager}}} modules are intended to inherit from the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_trigger_manager.m wl_trigger_manager.m] abstract class.
    5441
    5542== User Extension ==
    56 [[Image(user.png,width=800)]]
    5743
    58 A {{{User Extension}}} is an object from the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_user_ext.m wl_user_ext.m] abstract class. We do not provide any subclasses that implement this abstract; it is intended that users create their own subclasses for [wiki:../../../Extensions#SimpleExtensions:AddingNewCommandswithUserExtensionObjects extending WARPLab] with new commands.
     44A {{{User Extension}}} is meant to deal with extra commands in a WARPLab design that may not be covered by the other modules. By design, the WARPLab Reference Design does not have an implementation of a user extension. Instead, users can add their own module to the WARPLab Reference Design for easy customization.
     45
     46The MATLAB implementation of {{{User Extension}}} modules are intended to inherit from the [browser:ResearchApps/PHY/WARPLAB/WARPLab7/M_Code_Reference/classes/wl_user_ext.m wl_user_ext.m] class.