Changes between Version 5 and Version 6 of WARPLab/Reference/TriggerManager/TriggerProcessor
- Timestamp:
- Sep 14, 2015, 10:23:46 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WARPLab/Reference/TriggerManager/TriggerProcessor
v5 v6 23 23 24 24 * 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) 26 26 * Ethernet Packets 27 27 * Register writes (used for WARP v2 compatibility) … … 35 35 36 36 * 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) 38 38 * Baseband 39 39 * Automatic Gain Control (AGC) Start … … 88 88 In our examples, we have two nodes, a transmitter ( nodes(1) ) and a receiver ( nodes(2) ): 89 89 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 91 93 {{{ 92 94 eth_trig = wl_trigger_eth_udp_broadcast; 93 nodes(1).wl_triggerManagerCmd('add_ethernet_trigger',[eth_trig]);95 wl_triggerManagerCmd(nodes(1), 'add_ethernet_trigger',[eth_trig]); 94 96 }}} 97 95 98 '''NOTE:''' This will allow a host, like Matlab, to create an Ethernet packet to begin transmission 96 99 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 102 106 '''NOTE:''' These trigger IDs will be the same for all nodes in the system and should not be modified by the user. 103 107 104 108 * 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. 110 114 111 115 * 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 115 120 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 119 125 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 130 137 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 }}} 134 141 135 142 * 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 139 147 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 143 152 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). 148 158 149 159 … … 205 215 Set the Ethernet trigger type[[BR]] 206 216 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') 217 In WARP v3, the ability was added to the trigger manager to "sniff" 218 the axi stream between the Ethernet controller and the AXI interface 219 to the Ethernet controller, such as the AXI DMA or AXI FIFO. This 220 allows for more predictable timing for Ethernet triggers since it does 221 not depend on any SW interaction. However, this feature could not be 222 added to the WARP v2 trigger manager due to differences in Ethernet 223 components. Therefore, in reference designs since this feature was 224 introduced, WARP v3 has used hardware for Ethernet triggers while WARP v2 225 has used software.[[BR]] 226 227 Unfortunately, this introduced a large timing difference between WARP v2 228 and WARP v3 when asserting the Ethernet trigger within the node in response 229 to a broadcast Ethernet trigger. This adds a complication to experiments 230 involving a mix of WARP v2 and WARP v3 nodes. Therefore, trigger manager 231 v1.04.a addressed this by being able to select between using the hardware 232 capabilities WARP v3 or using software, like WARP v2, for Ethernet triggers.[[BR]] 233 234 This command allows users to set whether the WARP v3 node uses hardware 235 or software for Ethernet triggers. Since WARP v2 does not support using 236 hardware for Ethernet triggers, this command does nothing.[[BR]] 237 238 239 '''Arguments:''' 'hardware' or 'software' 216 240 217 241 '''Returns:''' none … … 225 249 '''Arguments:''' node 226 250 227 '''Returns:''' (uint32 TRIGGER_ASSOCIATION) [[BR]]228 251 '''Returns:''' (uint32 TRIGGER_ASSOCIATION) 252 TRIGGER_ASSOCIATION: bit-wise AND of associated trigger IDs[[BR]] 229 253 230 254 … … 235 259 '''Arguments:''' (uint32 OUTPUTS), (uint32 OR_INPUTS), ![optional] (uint32 AND_INPUTS) 236 260 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 267 NOTE: This command replaces the current input selection on the board for the 268 specified outputs (unspecified outputs are not modified). The previous 269 state of the output is not saved. [[BR]] 246 270 247 271 248 272 249 273 === {{{output_config_delay}}} === 250 Configures specified output triggers to be have an additional delay relative to their inputs[[BR]] 274 Configures specified output triggers to be have an 275 additional delay relative to their inputs[[BR]] 251 276 252 277 253 278 '''Arguments:''' (uint32 OUTPUTS), (double DELAY_NS) 254 279 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 260 286 261 287 … … 267 293 '''Arguments:''' (uint32 OUTPUTS), (string MODE) 268 294 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 274 300 275 301 276 302 277 303 === {{{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]] 304 Reads current state of output triggers. 305 306 NOTE: This command is intended to be used on output triggers that have enabled their hold mode.[[BR]] 279 307 280 308 281 309 '''Arguments:''' (uint32 OUTPUTS) 282 310 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 283 314 '''Returns:''' (bool STATES) 284 315 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]]288 316 289 317 … … 295 323 '''Arguments:''' (uint32 OUTPUTS) 296 324 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 300 329 301 330 302 331 303 332 === {{{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:''' none311 312 INPUTS: vector of output trigger IDs, provided by wl_getTriggerInputIDs[[BR]]313 314 333 315 334 316 335 === {{{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]] 336 Configures specified input triggers to enable or disable debounce circuit. 337 338 NOTE: 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]] 318 339 319 340 320 341 '''Arguments:''' (uint32 INPUTS), (string MODE) 321 342 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 327 348 328 349 … … 334 355 '''Arguments:''' (uint32 INPUTS), (double DELAY_NS) 335 356 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 341 362 342 363 … … 348 369 '''Arguments:''' (uint32 THRESH) 349 370 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 376 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]] 355 377 356 378 … … 362 384 '''Arguments:''' (uint32 LENGTH) 363 385 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 391 NOTE: For all hardware versions, RSSI is sampled at 10 MHz. Each sample is, therefore, 100 ns.[[BR]] 369 392 370 393 … … 376 399 '''Arguments:''' (uint32 LENGTH) 377 400 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 381 405 382 406 … … 388 412 '''Arguments:''' (uint32 IFCSELECTION) 389 413 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 419 NOTE: IFCSELECTION is intended to be used with the return values from the wl_getInterfaceIDs method.[[BR]] 395 420 396 421