Changes between Version 19 and Version 20 of WARPLab/BufferSizes

Timestamp:

Feb 10, 2015, 10:17:40 AM (9 years ago)

Author:

murphpo

Comment:

--

WARPLab/BufferSizes

@@ -3 +3 @@
 = WARPLab: Sample Buffer Sizes  =
 
-In WARPLab 7.4 and earlier, all transmit and receive samples were stored in buffers of BRAM directly on the FPGA. As of WARPLab 7.5 these samples are buffered in the BRAM but stored in the DRAM SODIMM attached to the WARP v3 hardware.  For each interface:
+WARPLab 7.5 for WARP v3 supports sample storage in the board's 2GB DDR3 DRAM. As a result WARPLab 7.5 can be used with much longer waveforms than previous releases, which were limited to the FPGA's on-chip BRAM.
 
-|| ||=  '''WARPLab 7.4'''  =||=  '''WARPLab 7.5 (4RF)'''  =||=  '''WARPLab 7.5 (2RF)'''  =||
-|| Tx max samples  ||  32 kSamp  ||  56 MSamp  ||  112 MSamp  ||
-|| Tx max duration at 40MHz sampling  ||  819.2 µsec  ||  1.468 sec  ||  2.9360 sec  ||
-|| Rx max samples  ||  32 kSamp  ||  64 MSamp  ||  128 MSamp  ||
-|| Rx max duration at 40MHz sampling  ||  819.2 µsec  ||  1.6777 sec  ||  3.3554 sec  ||
+The table below summarizes the maximum Tx and Rx waveform lengths in WARPLab 7.5 for WARP v3.
 
-The table above summarizes the maximum buffer sizes for the WARPLab 7.5 design. Since the buffer space is divided among RF interfaces, the 2RF design can store more samples than the 4RF design. WARPLab 7.5 maintains full backward compatibility with WARPLab 7.4, so all existing scripts compatible with WAPRLab 7.4 will "just work" with the new design and will use the existing WARPLab 7.4 limitations on buffer sizes.
+||= '''WARPLab Ver''' =||=  '''Tx Samps'''  =||=  '''Tx Time'''  =||=  '''Rx Samps'''  =||=  '''Rx Time'''  =||
+||  7.5 (2RF)  || 56M || 1.46 sec || 128M || 1.67 sec ||
+||  7.5 (4RF)  || 112M || 2.93 sec || 128M || 3.35 sec ||
+||  7.4  || 32k || 819.2 µsec || 32k || 819.2 µsec ||
+
+Notes:
+ * The waveform durations above assume 40MHz sampling at the ADCs and DACs, the default in the WARPLab 7.5 reference design hardware
+ * The '''k''' and '''M''' prefixes represent factors of 2^10^ and 2^20^, respectively
 
 == Performance Considerations ==
 
-With all of the extra buffer space that the hardware design is capable of, the chief limitation on usable buffer sizes shifts burden to the user's PC. Each sample is represented as a complex double precision floating point number in a MATLAB, occupying 16 bytes in memory.
+With the extra buffer space that the hardware design is capable of, the chief limitation on usable buffer sizes shifts burden to the user's PC. Each sample is represented as a complex double precision floating point number in a MATLAB, occupying 16 bytes in memory.
 
 The table below shows the storage size of various sample vectors, up to the new maximum vector lengths in WARPLab 7.5. Note these sizes are how much RAM is required to store each vector in the MATLAB workspace. Retrieving the vector and processing the vector requires additional RAM. Depending on the amount of RAM on the host PC and what other programs are currently running, a user should limit the number of samples they are working with to stay under the total available memory. If MATLAB's memory utilization rises too far, it is common that the MATLAB application will stall while the OS swaps memory to disk. On Windows the MATLAB {{{memory}}} command will summarize the available RAM and largest supported array size in your MATLAB instance.
@@ -27 +30 @@
 
 
-One thing to note is that these are steady state memory figures for a request of a single interface.  Peak memory usages may be greater than this due to some copying of data between structures during fetches from the transport.  
+One thing to note is that these are steady state memory figures for a request of a single interface.  Peak memory usages may be greater than this due to MATLAB's internal memory management when building a matrix of samples retrieved from multiple RF interfaces.
 
-In WARPLab 7.5.0, due to the way the transport processes samples:
+The worst-case memory usage in WARPLab 7.5 occurs during a {{{read_iq}}} command when reading samples from multiple RF interfaces. The peak memory usage (during command execution) and stead-state (after the command returns) are functions of the number of RF interfaces being processed.
+   * Peak memory usage = (Num Interfaces + N) * (Occupied Memory for the Sample Vector Length)
+    * N = 0 for 1 RF interface
+    * N = 1 for >1 RF interface
    * Steady state memory usage = (Num Interfaces) * (Occupied Memory for the Sample Vector Length)
-   * Peak memory usage = (Num Interfaces + 1) * (Occupied Memory for the Sample Vector Length)
 
-For example, we we were trying to capture 2^25^ samples (ie 32 MSamples) for 4 interfaces, this would have a steady state memory usage of 2 GBytes (ie 4 Interfaces * 512 MBytes / Interface) and a peak memory usage of 2.5 GBytes (ie 5 Interfaces * 512 MBytes / Interface).
+For example, when reading 32M samples from 4 interfaces, the final memory usage would be 2 GBytes (4 Interfaces * 512 MBytes / Interface) and a peak memory usage of 2.5 GBytes during the {{{read_iq}}} command execution. 
+
+A future (API-compatible) revision of the WARPLab mex transport implementation will reduce the peak memory usage to the steady state level.