WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2015-Jun-26 20:57:53

vten3075
Member
Registered: 2015-Mar-05
Posts: 18

Node Sync & Artificial Delay with CM-PLL

Hi,

We are trying to sync about 9-10 WARP v3 nodes with the CM-PLL modules, but can't figure out how to sync it with the modules.

We are using the hardware guide for CM-PLL http://warpproject.org/trac/wiki/Hardwa … des/CM-PLL and are currently trying to sync just two nodes. Our nodes are configured as follows:

First node of the daisy chain:
- DIP switches set to '110000'
- Cable connected from OUT header to IN header of 2nd node

2nd node:
- DIP switches set to '001000'
- Cable connected from OUT header of 1st node to IN header
- Another cable will be connected from OUT header to 3rd node's IN header when we implement the larger number of synced nodes

We're not sure if we need to set the last three DIP switches in any way (since http://warpproject.org/trac/wiki/cores/ … controller says that it should be set to '101', '110' or '111'), and also if we need to implement any sort of artificial delay into the modules so all the nodes are correctly synced in a daisy chain configuration.

Also, what code should we use when we start running it, do we use the NodeSync example from http://warpproject.org/trac/wiki/WARPLa … s/nodeSync , or is there another code we need to use?

Can you help us? Thanks.

Offline

 

#2 2015-Jun-29 09:57:56

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Node Sync & Artificial Delay with CM-PLL

vten3075 wrote:

We are using the hardware guide for CM-PLL http://warpproject.org/trac/wiki/Hardwa … des/CM-PLL and are currently trying to sync just two nodes. Our nodes are configured as follows:

First node of the daisy chain:
- DIP switches set to '110000'
- Cable connected from OUT header to IN header of 2nd node

2nd node:
- DIP switches set to '001000'
- Cable connected from OUT header of 1st node to IN header
- Another cable will be connected from OUT header to 3rd node's IN header when we implement the larger number of synced nodes

We're not sure if we need to set the last three DIP switches in any way (since http://warpproject.org/trac/wiki/cores/ … controller says that it should be set to '101', '110' or '111'), and also if we need to implement any sort of artificial delay into the modules so all the nodes are correctly synced in a daisy chain configuration.

The correct switch positions for WARPLab using the CM-PLL are documented here. That document is basically the union of the CM-PLL hardware docs and the w3_clock_controller docs. The reason for the split is that the leftmost three bits affect state physically on the CM-PLL hardware itself while the right 3 bits are just I/O to the FPGA so their effects are design-dependent. For WARPLab, you want your head node to be configured as 110101. You want all 8 of your "middle" nodes to be configured as 101101. You finally want your tail node to be configured as 001110.

vten3075 wrote:

Also, what code should we use when we start running it, do we use the NodeSync example from http://warpproject.org/trac/wiki/WARPLa … s/nodeSync , or is there another code we need to use?

Can you help us? Thanks.

That's really the best place to start. Another good example is the 8x2 Array. That example uses the CM-MMCX clock module to synchronize two nodes to act as a single transmitter. The specifics of cabling up a CM-MMCX are different (and more tedious) than the newer CM-PLL, but both the concept and the MATLAB script needed to use the synchronized nodes is the same.

As you mentioned earlier, with a daisy chain that long you'll likely need to tweak delay values to make sure every node gets triggered at the same time. An oscilloscope will be handy here, as you can probe the debug header on each board to make sure the Tx and Capture signals are aligned on each board after you calibrate the correct delay values.

You will want to set delays using the same method as that nodeSync example (specifically this line). For the sake of argument, let's say that your application requires 10 transmit nodes to begin their transmission simultaneously. In this case, the 8x2 Array example is the best place to look. Here is a code snippet from that example:

Code:

% For the primary transmit node, we will allow Ethernet to trigger the buffer
% baseband, the AGC, and debug0 (which is mapped to pin 8 on the debug
% header). We also will allow Ethernet to trigger the same signals for the 
% receiving node.
wl_triggerManagerCmd([node_tx1,node_rx], 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D0], [T_IN_ETH_A]);

% For the receive node, we will allow debug3 (mapped to pin 15 on the
% debug header) to trigger the buffer baseband, and the AGC
node_tx2.wl_triggerManagerCmd('output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC], [T_IN_D3]);

% For the receive node, we enable the debounce circuity on the debug 3 input
% to deal with the fact that the signal may be noisy.
node_tx2.wl_triggerManagerCmd('input_config_debounce_mode', [T_IN_D3], 'enable'); 

% 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 artificially delay the transmitters trigger outputs that
% drive the buffer baseband and the AGC.
node_tx1.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 56.25); % 56.25ns delay

That code snippet tells the primary node_tx1 to assert the T_OUT_D0 output on the debug header and tells the secondary node_tx2 to accept triggers on its T_IN_D3 input on the debug header. Those pins on the debug header were connected explicitly through external cabling. The reason we chose those two pins is that they are both next to the GND pins on the header so it made connected a twisted pair cable between them easier. Since you are using the CM-PLL, you don't have to worry about any connections other than the ribbons between the CM-PLL modules. Internally, T_OUT_D0 is tied to T_IN_D0 on the next board in the chain.

Additionally, this code recognizes that debouncing the input trigger on node_tx2 takes some time, so node_tx1 should hold off 56.25ns before actually starting its transmission. From this code snippet, we can extrapolate to the hypothetical 10 transmit node example. Let node_tx1 represent the first node in the chain and node_tx10 represent the final node in the daisy chain. Your script should then look something like:

Code:

primary_tx_node = [node_tx1];
secondary_tx_nodes = [node_tx2, node_tx3, node_tx4, node_tx5, node_tx6, node_tx7, node_tx8, node_tx9, node_tx10];

wl_triggerManagerCmd([primary_tx_node], 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D0], [T_IN_ETH_A]); %First node triggered by Ethernet
wl_triggerManagerCmd([secondary_tx_nodes], 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D0], [T_IN_D0]); %All other nodes triggered by CM-PLL trigger connections
wl_triggerManagerCmd([secondary_tx_nodes], 'input_config_debounce_mode', [T_IN_D0], 'enable'); 

%Now we set the delays at each node

node_tx1.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 9*56.25); 
node_tx2.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 8*56.25); 
node_tx3.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 7*56.25); 
node_tx4.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 6*56.25); 
node_tx5.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 5*56.25); 
node_tx6.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 4*56.25); 
node_tx7.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 3*56.25); 
node_tx8.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 2*56.25); 
node_tx9.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 1*56.25); 
node_tx10.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 0);

Obviously, the above code could be cleaned up a bit in a FOR loop, but I wanted to be explicit in calling out the various values in this post. Basically, each hop in the daisy chain is going to cause additional delay in the trigger (primarily due the the debouncing circuitry). So, we want to artificially delay the earlier nodes in the chain more than the later nodes in the chain. Those values should be close, but you can lock it in by using an oscilloscope to explicitly compare the relative start times of each node.

Offline

 

#3 2015-Jun-29 10:46:28

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: Node Sync & Artificial Delay with CM-PLL

Just a quick update on Chris' post.  In WARPLab 7.5.1, the maximum output delay for the baseband (T_OUT_BASEBAND) is only 193.75 ns (you can see the calculation here; 6.25 ns clock with 31 delay flip-flops).  However, this does not mean that you cannot use all ten nodes to transmit at the same time (if you need that), you just have to set up the experiment in a slightly different way: 

1) You could turn off debounce for the secondary TX nodes to reduce the delay needed.  The reason we had enabled the debounce was that there was very little noise control when using random wires to connect debug header pins.  However, with the CM-PLL module, there is a lot more noise control for the trigger inputs / outputs that run between nodes.  We have not characterized this but we believe that you should not need debounce when using the CM-PLL module.

2) Since 193.75 ns is much greater than one 40 MHz baseband clock cycle (i.e. 25 ns), you could just digitally delay the waveform in MATLAB by appending dummy samples at the beginning of the waveform for nodes that require larger output delays.

Please let us know if you have any additional questions.

Offline

 

#4 2015-Jul-02 01:38:37

vten3075
Member
Registered: 2015-Mar-05
Posts: 18

Re: Node Sync & Artificial Delay with CM-PLL

Hi,

Thanks for your detailed response, we are trying to implement the multi-node system now. We need all the nodes to be synchronised so we can transmit at the same time, but the 193.75ns delay seems to be very long, and we are not sure if we will be able to resolve the channel information in that time. Will it be easier to use an external clock to trigger all 10 boards at once?

Thanks.

Offline

 

#5 2015-Jul-02 11:12:02

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: Node Sync & Artificial Delay with CM-PLL

The setup that Chris described (i.e. daisy chaining all of the triggers) is the easiest in terms of cabling.  If you need the delay to be tighter from when you trigger the primary transmitter (i.e. the node which is generating all the clocks and triggers) using the Ethernet trigger to when all nodes begin to actually transmit the waveform, then there are different cabling and setup options. 

First, you would continue to use the CM-PLL TFM cables to synchronize the RF and sample clocks for each board.  However, the distribution of the triggers would be more of a tree setup in order to minimize the propagation latency.  In WARPLab 7.5, we updated the hardware configuration of the debug header.  While there are still only 4 trigger outputs on the debug header, each output is replicated to two pins.  If you combine this with the trigger outputs in the CM-PLL TFM cable (which are replicated signals of the debug header trigger outputs), this means that a single primary node can trigger up to 9 secondary nodes (i.e. 1 node via the CM-PLL cable an 8 nodes via twisted pair wiring using the debug header).  The main issue is that there are only 4 ground pins on the debug header so it will require a little "creative wiring" in order to connect all 8 trigger outputs of the debug header to the other nodes using twisted pair cabling.   

In this type of setup, you would have the primary node set all of its trigger outputs and all the other nodes would just use one trigger input (I chose T_IN_D3 for the same reason as the 8x2 array example; it is next to a ground pin on the debug header which makes it easy to connect):

Code:

primary_tx_node    = [node_tx1];
secondary_tx_nodes = [node_tx2, node_tx3, node_tx4, node_tx5, node_tx6, node_tx7, node_tx8, node_tx9, node_tx10];

wl_triggerManagerCmd([primary_tx_node], 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D0, T_OUT_D1, T_OUT_D2, T_OUT_D3], [T_IN_ETH_A]); % First node triggered by Ethernet
wl_triggerManagerCmd([secondary_tx_nodes], 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC], [T_IN_D3]); % All other nodes triggered by twisted pair or CM-PLL trigger connections
wl_triggerManagerCmd([secondary_tx_nodes], 'input_config_debounce_mode', [T_IN_D3], 'enable'); 

% Now we have to delay the output of the primary node so it is in sync with the other triggered nodes

node_tx1.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 56.25);

Hopefully, that helps.  One quick follow up to something I had mention previously:  If you disable the debounce circuitry (which you should not do if using twisted pair cabling), the propagation delay of the triggers is 31.25  ns vs 56.25 ns with the debounce circuitry enabled.  This would still make the delay for daisy chaining 10 triggers 312.5 ns, which is greater than the 193.75 output delay that is supported by the trigger manager.  Therefore, you would still need to digitally delay the waveform by appending dummy samples for a few nodes in order to make the delay long enough so that all nodes transmitted the waveform at the same time.

Offline

 

Board footer