Changes between Version 5 and Version 6 of WARPLab/Reference/TriggerManager/TriggerProcessor


Ignore:
Timestamp:
Sep 14, 2015, 10:23:46 AM (9 years ago)
Author:
welsh
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WARPLab/Reference/TriggerManager/TriggerProcessor

    v5 v6  
    2323
    2424* Input Triggers
    25   * External Pins (For example:  D0 - D3, pins 12 - 15 on the [wiki:WARPLab/HardwareConfiguration#DebugHeader debug header] in the WARPLab reference design)
     25  * External Pins (For example:  EXT_IN_P0 - EXT_IN_P3, pins 12 - 15 on the [wiki:WARPLab/HardwareConfiguration#DebugHeader debug header] in the WARPLab reference design)
    2626  * Ethernet Packets
    2727  * Register writes (used for WARP v2 compatibility)
     
    3535
    3636* Output Triggers
    37   * External Pins (For example:  D0 - D3, pins 8 - 11 on the [wiki:WARPLab/HardwareConfiguration#DebugHeader debug header] in the WARPLab reference design)
     37  * External Pins (For example:  EXT_OUT_P0 - EXT_OUT_P3, pins 8 - 11 on the [wiki:WARPLab/HardwareConfiguration#DebugHeader debug header] in the WARPLab reference design)
    3838  * Baseband
    3939  * Automatic Gain Control (AGC) Start
     
    8888In our examples, we have two nodes, a transmitter ( nodes(1) ) and a receiver ( nodes(2) ):
    8989
    90 * Create a UDP broadcast trigger and trigger the transmitting node with the Ethernet packet
     90'''NOTE:''' These examples are for the WARPLab 7.6.0 syntax.  If looking for the legacy syntax for WARPLab 7.5.1 and prior, the please see the [wiki:WARPLab/Porting#ChangesinWARPLab7.6 WARPLab 7.6.0 porting guide].
     91
     92* Create a UDP broadcast trigger and set the transmitting node to trigger with an appropriate Ethernet packet
    9193{{{
    9294eth_trig = wl_trigger_eth_udp_broadcast;
    93 nodes(1).wl_triggerManagerCmd('add_ethernet_trigger',[eth_trig]);
     95wl_triggerManagerCmd(nodes(1), 'add_ethernet_trigger',[eth_trig]);
    9496}}}
     97
    9598  '''NOTE:'''  This will allow a host, like Matlab, to create an Ethernet packet to begin transmission 
    9699
    97 * Read Trigger IDs into workspace
    98 {{{
    99 [T_IN_ETH,T_IN_ENERGY,T_IN_AGCDONE,T_IN_REG,T_IN_D0,T_IN_D1,T_IN_D2,T_IN_D3] =  wl_getTriggerInputIDs(nodes(1));
    100 [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D0, T_OUT_D1, T_OUT_D2, T_OUT_D3] = wl_getTriggerOutputIDs(nodes(1));
    101 }}}
     100* Read Trigger IDs into workspace:
     101    {{{
     102    trig_in_ids  = wl_getTriggerInputIDs(nodes(1));
     103    trig_out_ids = wl_getTriggerOutputIDs(nodes(1));
     104    }}}
     105
    102106  '''NOTE:'''  These trigger IDs will be the same for all nodes in the system and should not be modified by the user.
    103107
    104108* For the transmit node, allow Ethernet to trigger the buffer baseband, the AGC, and Trigger output 0 (which is mapped by default in the WARPLab reference design to pin 8 on the [wiki:WARPLab/HardwareConfiguration#DebugHeader debug header])
    105 {{{
    106 nodes(1).wl_triggerManagerCmd('output_config_input_selection',[T_OUT_BASEBAND,T_OUT_AGC,T_OUT_D0],[T_IN_ETH,T_IN_REG]);
    107 }}}
    108   '''NOTE:'''  We use both {{{T_IN_ETH}}} and {{{T_IN_REG}}} so this example is compatible with both WARP v2 and WARP v3 hardware.  If using WARP v3 hardware, only {{{T_IN_ETH}}} is needed as the source of the trigger.
    109 
     109  {{{
     110  wl_triggerManagerCmd(nodes(1), 'output_config_input_selection', [trig_out_ids.BASEBAND, trig_out_ids.AGC, trig_out_ids.EXT_OUT_P0], [trig_in_ids.ETH_A]);
     111  }}}
     112
     113  '''NOTE:'''  As of WARPLab 7.5.1, we only have to use the {{{ETH_A}}} trigger id to be compatible with both WARP v2 and WARP v3 hardware.  In WARP v3, the Ethernet trigger can be set either through the hardware 'snooping' logic or through software.  This is controlled by the {{{set_ethernet_trigger_type}}} command.
    110114
    111115* For the receive node, allow the energy detector to trigger the buffer baseband and AGC core:
    112 {{{
    113 nodes(2).wl_triggerManagerCmd('output_config_input_selection',[T_OUT_BASEBAND,T_OUT_AGC],[T_IN_ENERGY]);
    114 }}}
     116  {{{
     117  wl_triggerManagerCmd(nodes(2), 'output_config_input_selection', [trig_out_ids.BASEBAND, trig_out_ids.AGC], [trig_in_ids.ENERGY_DET]);
     118  }}}
     119
    115120  Then enable the hold mode for the triggers driven by energy detection. This will prevent the buffer from being overwritten before we have a chance to read it:
    116 {{{
    117 nodes(2).wl_triggerManagerCmd('output_config_hold_mode',[T_OUT_BASEBAND,T_OUT_AGC],'enable');
    118 }}}
     121  {{{
     122  wl_triggerManagerCmd(nodes(2), 'output_config_hold_mode', [trig_out_ids.BASEBAND, trig_out_ids.AGC], 'enable');
     123  }}}
     124
    119125  Then get the IDs for the interfaces on the board and setup the configuration of the energy monitoring:
    120 {{{
    121 [RFA,RFB] = wl_getInterfaceIDs(nodes(2));
    122 
    123 rssi_sum_len = 15;
    124 
    125 nodes(2).wl_triggerManagerCmd('energy_config_average_length',rssi_sum_len);
    126 nodes(2).wl_triggerManagerCmd('energy_config_busy_threshold',rssi_sum_len*500);
    127 nodes(2).wl_triggerManagerCmd('energy_config_busy_minlength',10);
    128 nodes(2).wl_triggerManagerCmd('energy_config_interface_selection',RFA+RFB);
    129 }}}
     126  {{{
     127  ifc_ids = wl_getInterfaceIDs(nodes(2));
     128
     129  rssi_sum_len = 15;
     130
     131  wl_triggerManagerCmd(nodes(2), 'energy_config_average_length', rssi_sum_len);
     132  wl_triggerManagerCmd(nodes(2), 'energy_config_busy_threshold', rssi_sum_len*500);
     133  wl_triggerManagerCmd(nodes(2), 'energy_config_busy_minlength', 10);
     134  wl_triggerManagerCmd(nodes(2), 'energy_config_interface_selection', ifc_ids.RF_ON_BOARD);
     135  }}}
     136
    130137  Finally, when done processing, we can clear the energy detection trigger since it is holding the output due to setting the {{{'output_config_hold_mode'}}}
    131 {{{
    132 nodes(2).wl_triggerManagerCmd('output_state_clear',[T_OUT_BASEBAND,T_OUT_AGC]);
    133 }}}
     138  {{{
     139  wl_triggerManagerCmd(nodes(2), 'output_state_clear', [trig_out_ids.BASEBAND, trig_out_ids.AGC]);
     140  }}}
    134141
    135142* For the receive node, allow trigger input to trigger the buffer baseband and the AGC (this example assumes the WARPLab reference design configuration where we should connect trigger output 0, pin 8 of the [wiki:WARPLab/HardwareConfiguration#DebugHeader debug header], of the transmit node to trigger input 3, pin 15 of the [wiki:WARPLab/HardwareConfiguration#DebugHeader debug header], of the receive node):
    136 {{{
    137 nodes(2).wl_triggerManagerCmd('output_config_input_selection',[T_OUT_BASEBAND,T_OUT_AGC],[T_IN_D3]);
    138 }}}
     143  {{{
     144  wl_triggerManagerCmd(nodes(2), 'output_config_input_selection', [trig_out_ids.BASEBAND, trig_out_ids.AGC], [trig_in_ids.EXT_IN_P3]);
     145  }}}
     146
    139147  We will also enable the debounce circuitry on the trigger input to help with noise on the signal line:
    140 {{{
    141 nodes(2).wl_triggerManagerCmd('input_config_debounce_mode',[T_IN_D3],'enable');
    142 }}}
     148  {{{
     149  wl_triggerManagerCmd(nodes(2), 'input_config_debounce_mode', [trig_in_ids.EXT_IN_P3], 'enable');
     150  }}}
     151
    143152  Since the debounce circuitry is enabled, there will be a delay at the receiver node for its input trigger. To better align the transmitter and receiver, we can artifically delay the transmitters trigger outputs that drive the buffer baseband and the AGC:
    144 {{{
    145 nodes(1).wl_triggerManagerCmd('output_config_delay',[T_OUT_BASEBAND,T_OUT_AGC],[50]); %50ns delay
    146 }}}
    147   '''NOTE:''' The 50 ns delay was measured using the oscilloscope.  The procedure can be found here (Coming soon ...). 
     153  {{{
     154  wl_triggerManagerCmd(nodes(1), 'output_config_delay', [trig_out_ids.BASEBAND, trig_out_ids.AGC], 56.25);  % 56.25ns delay (9 clock cycles @ 160 MHz)
     155  }}}
     156
     157  '''NOTE:''' The 56.25 ns delay (ie 9 clock cycles at 160 MHz) was measured using the oscilloscope.  If debounce is disabled, then the delay is 31.25 ns (ie 5 clock cycles at 160 MHz).     
    148158
    149159
     
    205215Set the Ethernet trigger type[[BR]]
    206216
    207 In WARP v3, the ability was added to the trigger manager to "sniff" the axi stream between the Ethernet controller and the AXI interface to the Ethernet controller, such as the AXI DMA or AXI FIFO.  This allows for more predictable timing for Ethernet triggers since it does not depend on any SW interaction.  However, this feature could not be added to the WARP v2 trigger manager due to differences in Ethernet components.  Therefore, in reference designs since this feature was introduced, WARP v3 has used hardware for Ethernet triggers while WARP v2 has used software.[[BR]]
    208 
    209 Unfortunately, this introduced a large timing difference between WARP v2 and WARP v3 when asserting the Ethernet trigger within the node in response to a broadcast Ethernet trigger.  This adds a complication to experiments involving a mix of WARP v2 and WARP v3 nodes.  Therefore, trigger manager
    210 v1.04.a addressed this by being able to select between using the hardware capabilities WARP v3 or using software, like WARP v2, for Ethernet triggers.[[BR]]
    211 
    212 This command allows users to set whether the WARP v3 node uses hardware or software for Ethernet triggers.  Since WARP v2 does not support using hardware for Ethernet triggers, this command does nothing.
    213 
    214 
    215 '''Arguments:''' (TRIGGER_TYPE:  'hardware' or 'software')
     217In WARP v3, the ability was added to the trigger manager to "sniff"
     218the axi stream between the Ethernet controller and the AXI interface
     219to the Ethernet controller, such as the AXI DMA or AXI FIFO.  This
     220allows for more predictable timing for Ethernet triggers since it does
     221not depend on any SW interaction.  However, this feature could not be
     222added to the WARP v2 trigger manager due to differences in Ethernet
     223components.  Therefore, in reference designs since this feature was
     224introduced, WARP v3 has used hardware for Ethernet triggers while WARP v2
     225has used software.[[BR]]
     226
     227Unfortunately, this introduced a large timing difference between WARP v2
     228and WARP v3 when asserting the Ethernet trigger within the node in response
     229to a broadcast Ethernet trigger.  This adds a complication to experiments
     230involving a mix of WARP v2 and WARP v3 nodes.  Therefore, trigger manager
     231v1.04.a addressed this by being able to select between using the hardware
     232capabilities WARP v3 or using software, like WARP v2, for Ethernet triggers.[[BR]]
     233
     234This command allows users to set whether the WARP v3 node uses hardware
     235or software for Ethernet triggers.  Since WARP v2 does not support using
     236hardware for Ethernet triggers, this command does nothing.[[BR]]
     237
     238
     239'''Arguments:''' 'hardware' or 'software'
    216240
    217241'''Returns:''' none
     
    225249'''Arguments:''' node
    226250
    227 '''Returns:''' (uint32 TRIGGER_ASSOCIATION)[[BR]]
    228   TRIGGER_ASSOCIATION: bit-wise AND of associated trigger IDs[[BR]]
     251'''Returns:''' (uint32 TRIGGER_ASSOCIATION)
     252TRIGGER_ASSOCIATION: bit-wise AND of associated trigger IDs[[BR]]
    229253
    230254
     
    235259'''Arguments:''' (uint32 OUTPUTS), (uint32 OR_INPUTS), ![optional] (uint32 AND_INPUTS)
    236260
    237 '''Returns:''' none
    238 
    239 OUTPUTS:      vector of output trigger IDs, provided by wl_getTriggerOutputIDs[[BR]]
    240 
    241 OR_INPUTS:    vector of input trigger IDs, provided by wl_getTriggerInputIDs. Any triggers in this vector that assert will cause the output trigger to assert.[[BR]]
    242 
    243 AND_INPUTS:   vector of input trigger IDs, provided by wl_getTriggerInputIDs. Only if all triggers in this vector assert will the output trigger assert.   [[BR]]
    244 
    245 NOTE: This command replaces the current input selection on the board. The previous state is not saved.[[BR]]
     261  * '''OUTPUTS:'''      vector of output trigger IDs, provided by wl_getTriggerOutputIDs[[BR]]
     262  * '''OR_INPUTS:'''    vector of input trigger IDs, provided by wl_getTriggerInputIDs. Any triggers in this vector that assert will cause the output trigger to assert.[[BR]]
     263  * '''AND_INPUTS:'''   vector of input trigger IDs, provided by wl_getTriggerInputIDs. Only if all triggers in this vector assert will the output trigger assert.   [[BR]]
     264
     265'''Returns:''' none
     266
     267NOTE: This command replaces the current input selection on the board for the
     268specified outputs (unspecified outputs are not modified).  The previous
     269state of the output is not saved. [[BR]]
    246270
    247271
    248272
    249273=== {{{output_config_delay}}} ===
    250 Configures specified output triggers to be have an additional delay relative to their inputs[[BR]]
     274Configures specified output triggers to be have an
     275additional delay relative to their inputs[[BR]]
    251276
    252277
    253278'''Arguments:''' (uint32 OUTPUTS), (double DELAY_NS)
    254279
    255 '''Returns:''' none
    256 
    257 OUTPUTS:      vector of output trigger IDs, provided by wl_getTriggerOutputIDs[[BR]]
    258 
    259 DELAY_NS:     scalar value of the intended delay, specified in nanoseconds (1e-9 seconds)[[BR]]
     280  * '''OUTPUTS:'''      vector of output trigger IDs, provided by wl_getTriggerOutputIDs[[BR]]
     281  * '''DELAY_NS:'''     scalar value of the intended delay, specified in nanoseconds (1e-9 seconds)[[BR]]
     282
     283
     284'''Returns:''' none
     285
    260286
    261287
     
    267293'''Arguments:''' (uint32 OUTPUTS), (string MODE)
    268294
    269 '''Returns:''' none
    270 
    271 OUTPUTS:      vector of output trigger IDs, provided by wl_getTriggerOutputIDs[[BR]]
    272 
    273 MODE:         'enable' or 'disable'[[BR]]
     295  * '''OUTPUTS:'''      vector of output trigger IDs, provided by wl_getTriggerOutputIDs[[BR]]
     296  * '''MODE:'''         'enable' or 'disable'[[BR]]
     297
     298'''Returns:''' none
     299
    274300
    275301
    276302
    277303=== {{{output_state_read}}} ===
    278 Reads current state of output triggers. Note: this command is intended to be used on output triggers that have enabled their hold mode.[[BR]]
     304Reads current state of output triggers.
     305
     306NOTE:  This command is intended to be used on output triggers that have enabled their hold mode.[[BR]]
    279307
    280308
    281309'''Arguments:''' (uint32 OUTPUTS)
    282310
     311  * '''OUTPUTS:'''      vector of output trigger IDs, provided by wl_getTriggerOutputIDs[[BR]]
     312  * '''STATES:'''       vector of (true, false) trigger states corresponding to state of OUTPUTS vector[[BR]]
     313
    283314'''Returns:''' (bool STATES)
    284315
    285 OUTPUTS:      vector of output trigger IDs, provided by wl_getTriggerOutputIDs[[BR]]
    286 
    287 STATES:       vector of (true, false) trigger states corresponding to state of OUTPUTS vector[[BR]]
    288316
    289317
     
    295323'''Arguments:''' (uint32 OUTPUTS)
    296324
    297 '''Returns:''' none
    298 
    299 OUTPUTS:      vector of output trigger IDs, provided by wl_getTriggerOutputIDs[[BR]]
     325  * '''OUTPUTS:'''      vector of output trigger IDs, provided by wl_getTriggerOutputIDs[[BR]]
     326
     327'''Returns:''' none
     328
    300329
    301330
    302331
    303332=== {{{input_config_enable_selection}}} ===
    304 Configures specified input triggers to be enabled as inputs that feed the trigger manager core.[[BR]]
    305 Note: This command disables all inputs before enabling the selected inputs -- no previous state is stored in the node.[[BR]]
    306 
    307 
    308 '''Arguments:''' (uint32 INPUTS)
    309 
    310 '''Returns:''' none
    311 
    312 INPUTS:      vector of output trigger IDs, provided by wl_getTriggerInputIDs[[BR]]
    313 
    314333
    315334
    316335=== {{{input_config_debounce_mode}}} ===
    317 Configures specified input triggers to enable or disable debounce circuit. Note: debounce circuit adds delay of 4 cycles, where each cycle is a duration specified in the input_delayStep_ns property of the wl_trigger_manager_proc.m class.[[BR]]
     336Configures specified input triggers to enable or disable debounce circuit.
     337
     338NOTE:  The debounce circuit adds a delay of 4 cycles, where each cycle is a duration specified in the input_delayStep_ns property of the wl_manager_proc.m class.[[BR]]
    318339
    319340
    320341'''Arguments:''' (uint32 INPUTS), (string MODE)
    321342
    322 '''Returns:''' none
    323 
    324 INPUTS:      vector of output trigger IDs, provided by wl_getTriggerInputIDs[[BR]]
    325 
    326 MODE:         'enable' or 'disable'[[BR]]
     343  * '''INPUTS:'''      vector of output trigger IDs, provided by wl_getTriggerInputIDs[[BR]]
     344  * '''MODE:'''         'enable' or 'disable'[[BR]]
     345
     346'''Returns:''' none
     347
    327348
    328349
     
    334355'''Arguments:''' (uint32 INPUTS), (double DELAY_NS)
    335356
    336 '''Returns:''' none
    337 
    338 INPUTS:       vector of input trigger IDs, provided by wl_getTriggerInputIDs[[BR]]
    339 
    340 DELAY_NS:     scalar value of the intended delay, specified in nanoseconds (1e-9 seconds)[[BR]]
     357  * '''INPUTS:'''       vector of input trigger IDs, provided by wl_getTriggerInputIDs[[BR]]
     358  * '''DELAY_NS:'''     scalar value of the intended delay, specified in nanoseconds (1e-9 seconds)[[BR]]
     359
     360'''Returns:''' none
     361
    341362
    342363
     
    348369'''Arguments:''' (uint32 THRESH)
    349370
    350 '''Returns:''' none
    351 
    352 THRESH:      busy threshold. For the MAX2829-based interfaces, WARP uses a 10-bit ADC for RSSI (range of ![0,1023]).[[BR]]
    353 
    354 Note: RSSI averaging in the core does NOT divide by the number of samples that are summed together. Averaging by N cycles means that the maximum possible RSSI post-averaging is N*1023.[[BR]]
     371  * '''THRESH:'''      busy threshold. For the MAX2829-based interfaces, WARP uses a 10-bit ADC for RSSI (range of ![0,1023]).[[BR]]
     372
     373'''Returns:''' none
     374
     375
     376Note: RSSI averaging in the core does NOT divide by the number of samples that are summed together.  Averaging by N cycles means that the maximum possible RSSI post-averaging is N*1023.[[BR]]
    355377
    356378
     
    362384'''Arguments:''' (uint32 LENGTH)
    363385
    364 '''Returns:''' none
    365 
    366 LENGTH:      Number of samples over which RSSI is averaged.[[BR]]
    367 
    368 Note: For all hardware versions, RSSI is sampled at 10 MHz. Each sample is, therefore, 100 ns.[[BR]]
     386  * '''LENGTH:'''      Number of samples over which RSSI is averaged.[[BR]]
     387
     388'''Returns:''' none
     389
     390
     391NOTE: For all hardware versions, RSSI is sampled at 10 MHz. Each sample is, therefore, 100 ns.[[BR]]
    369392
    370393
     
    376399'''Arguments:''' (uint32 LENGTH)
    377400
    378 '''Returns:''' none
    379 
    380 LENGTH:      Minimum number of samples that RSSI must be busy before trigger is raised.[[BR]]
     401  * '''LENGTH:'''      Minimum number of samples that RSSI must be busy before trigger is raised.[[BR]]
     402
     403'''Returns:''' none
     404
    381405
    382406
     
    388412'''Arguments:''' (uint32 IFCSELECTION)
    389413
    390 '''Returns:''' none
    391 
    392 IFCSELECTION:     One or more interfaces that the energy detector system should monitor[[BR]]
    393 
    394 Note: IFCSELECTION is intended to be used with the return values from the wl_getInterfaceIDs method.[[BR]]
     414  * '''IFCSELECTION:'''     One or more interfaces that the energy detector system should monitor[[BR]]
     415
     416'''Returns:''' none
     417
     418
     419NOTE: IFCSELECTION is intended to be used with the return values from the wl_getInterfaceIDs method.[[BR]]
    395420
    396421