The solutions provided here mainly discuss how to decrease the processing time. It also addresses some of the issues listed in the previous section.

Reentrant VIs

LabVIEW is a data flow programming tool. It can execute data independent codes in parallel if programmed in such a way. In the simulation there are several instances where a same chunk of code is repeated a number of times. This code is defined as a VI and is called every time the main code wants to utilize it. However by default, VIs are not reentrant and the execution system will not run multiple calls to the same subVI simultaneously. If it is tried to call a subVI that is not reentrant from more than one place, one call runs and the other call waits for the first to finish before running. In reentrant execution, calls to multiple instances of a subVI can execute in parallel with distinct and separate data storage. If the subVI is reentrant, the second call can start before the first call finishes running. In a reentrant VI, each instance of the call maintains its own state of information. Then, the execution system runs the same subVI simultaneously from multiple places. Thus this reduces the processing time as the simulation can execute several parts of codes in parallel rather than waiting for one part to finish before starting the second part. Some of the VI which are reentrant in the simulation model are symbol manipulation VI, symbol demanipulation VI, Jakes fading VI, etcetera.

Using same symbols and path gains

 (for all iterations and SNR)

As discussed in 5.1.1 the simulation model runs multiple times for a single SNR value to find out the average BER. This is time consuming. Moreover during each of the iterations, the symbols and the fading channel changes but the overall effect remains the same as the system parameters don’t change after each iteration as well as the SNR value. Thus it is possible to use the symbols and fading channel path gains generated for a particular SNR for all other SNR values. This saves a lot of processing time otherwise used up in generating the symbols and fading profile. This tweak doesn’t have a detrimental effect on the results; the improvement in processing time is up to 4000%.

  Using file read write

The solution provided above works very well but still it takes up time in creating the symbols and fading profile for the first iteration. There is a possibility that the same simulation can be carried out later. So it will help the processing time if during a new execution of the model, the symbols and fading profile generated earlier can be used. Thus file functionality was added to the simulation model. If ‘Read from previously created data’ is selected, it reads the symbols and path gain information from a previously stored file. If ‘Create new data’ is selected, it generates fresh new data and overwrites the old file.

 Storing Complex numbers

As discussed in section 5.1.4 LabVIEW doesn’t support writing complex numbers directly to a spreadsheet file. So the problem was solved by breaking the real and imaginary part of the complex number and storing them in adjacent columns of the spreadsheet file as double data types. The file is read accordingly.

Timed Loop

previous post described Hardware’s limitations. As discussed it calls for a measure to explicitly assign data independent VIs to separate processing cores. Timed Loop addresses this problem. It has the capacity to explicitly assign separate VIs to the separate cores. Figure 5.1 shows a screenshot of Timed Loop function. The node encircled in red is of prime importance as far as explicit assignment of cores is concerned. 

The value of that node specifies the processor one wants to handle execution. The default is -1, which means LabVIEW automatically assigns a processor. To manually assign a processor, a number between 0 and 255 is entered, where 0 represents the first available processor. If a number that exceeds the number of available processors is entered, a run-time error is generated and the timed structure does not execute. Parallel assignments are done by placing two instances of a VI in two timed loops each assigned a separate processor. The timed loop can help only if the VIs are independent from each other. Thus to make this possible not all the SNR values are calculated in a single VI. The first timed loop assigned to core 0 does the BER calculations for odd SNR values and the second timed loop assigned to core 1 does the BER calculations for even SNR values. It can be other way round too. Thus this cuts down the processing time to half.