Meaning of blocksize at ReadFromBlockPipeOut() in DLL

Hi all,

I’m working ReadFromBlockPipeOut() which is included in DLL library.

okDLLEXPORT long DLL_ENTRY okUsbFrontPanel_ReadFromBlockPipeOut(okUSBFRONTPANEL_HANDLE hnd, int epAddr, int blockSize, long length, unsigned char *data);

  1. What does the blockSize mean?

  2. I know high speed bulk payload is 512bytes. But in matlab function’s
    comment, the blockSize is limited to 1024. What does bulk payload size
    relate to the blockSize?

  3. I have read FrontPanel-UM.pdf that has release date 20070126.
    on page 22, you have mentioned for “Block-Throttled Pipes” , but I
    don’t understan exactly for these realtions.



Block-Throttled Pipes are transferred in a programmable block size with the option of the FPGA providing a READY signal to throttle the transfer.

Refer to the FrontPanel User’s Manual for timing waveforms of the okBTPipeIn and okBTPipeOut HDL modules. The FrontPanel API Reference documents the blockSize parameter. Finally, the FrontPanel User’s Manual has a table showing the relative performance of different block sizes.

I have a related question as well. It has to do with parameter order in the Matlab function call

function epvalue = readfrompipeout(obj, epaddr, blksize, bsize, psize)
Notice the order is blksize-bsize-psize, which is consistent with the following statement
calllib(‘okFrontPanel’, ‘okUsbFrontPanel_ReadBlockFromPipeOut’, obj.ptr, epaddr, blksize, bsize, pv);

However, in statements further down, the order changed to

[x,pv] = calllib(‘okFrontPanel’, ‘okUsbFrontPanel_ReadFromBlockPipeOut’, obj.ptr, epaddr, blksize, psize, pv);

now it is blksize - psize - pv

I am wondering if this is a bug, or it does not matter in this case.


Read the Frontpanel UM and the note in readfromblockpipeout.m several times. It seems clear to me that for larger data bulk transfer (say 8Mb), I should should choose
blksize = 1024 for the best peformance with BTpipe, and
bsize = 8Mb ( the data size of my application)

What about the packet size psize ? Should I always use psize = bsize, or 2048 ?


In my program on C ++ Builder I do not manage to use length of transmission more than 32 K. Why it so occurs?

My guess is that the C++ drivers are probably fine. According to the C++ control panel in the provided example PipeTest, the limits are

BlockSize: 2~1024(bytes)
Transfer length (your total data ): 16~32768 kBytes (32MB !)
Packet size: 16~8192 kBytes (8MB!)

So my conclusion is that the data sizes for BTpipeIn/Out need to be
bsize = your-data-size

if yourdatasize <= 8MB
psize = yourdatasize;
psize = 8MB;

O-K, can you straighten us out ?:slight_smile:

I tried to that with a simple Matlab stript (wrote by a buddy of mine at work), and using the provided PipeTest bit file, and the result seems confirming that. The following is the matlab script. Remember, the PipeTest firmware has only one 1k-byte buffer connected to the BTPipeIn EP and 1k-byte buffer for the BTPipeOut EP. So the matlab first write in a 1k byte test data, and then read out a 8k Byte chunk as if there is a 8k buffer in the FPGA. In reality, the FPGA just read out the 1kx16 buffer 4 times with the address pointer turning around (see the verilog)

oops, the buffer size in the hardware is 1k-word (16-bit) each, not 1k byte as in my previous post.

Here is the matlab script I used which is a bit of messy, but got the answer for me.

% function pipeRWtest()
clear all;
%if ~libisloaded(‘okFrontPanel’)
% loadlibrary(‘okFrontPanel’, ‘okFrontPanelDLL.h’);


xptr = gb_init();

gb_configFPGA(xptr, ‘C:\Program Files\Opal Kelly\FrontPanel\Samples\PipeTest\PipeTest-xem3010-1500.bit’);

%writeout = zeros(2048, 1);
%for i=1:2048
% writeout(i) = rand() & 255;

epaddr = hex2dec(‘81’);
blksize = 1024;

% psize = 2048;
bsize = 4*2048;
psize = bsize;
n = 5;

writeout = ceil(n.*rand(2048,1));
epvalue = writeout’;
err = uint8(zeros(1,bsize));
gb_activatetriggerin(xptr, hex2dec(‘40’), 0);
gb_writetoblockpipein(xptr, epaddr, blksize, epvalue, psize);
gb_activatetriggerin(xptr, hex2dec(‘40’), 0);
readin = gb_readfromblockpipeout(xptr, hex2dec(‘a1’), blksize, bsize, psize);

% datacop = [writeout readin]
nerr = 0;
for i = 0:psize-1
err(i+1) = writeout(mod((i),2048)+1)- readin(i+1);
fprintf(‘row ‘,num2str(i), ‘: ‘, num2str(writeout(mod((i),2048)+1)),’ ‘]);
fprintf([num2str(readin(i+1)),’ \n’]);
if err(i+1)~= 0
nerr = nerr + 1;
display([num2str(nerr),’ errors found in BTPipe in/out data transfer.’]);
% test the configuration. It is OK during development.
fprintf(‘Test 1: SetWireInValue\n’);
fprintf(‘Look at the LEDs on XEM3010 … \n’);
fprintf(‘LED bit turn on ‘]);
for i = 0:7
decimal_bitval=2^i; % the decimal(int32) value for each of the eight WireIns
% calllib(‘okFrontPanel’, ‘okUsbFrontPanel_SetWireInValue’,xptr, 0,decimal_bitval,65535); %decimal ‘0’ for ep00, decimal ‘65535’ for “update all bits”.
gb_setwireinvalue(xptr, 0, decimal_bitval,65535)
% calllib(‘okFrontPanel’, ‘okUsbFrontPanel_UpdateWireIns’,xptr);
fprintf(’, ‘, num2str(i)]);


function xptr = gb_init()
%if ~libisloaded(‘okFrontPanel’)
% loadlibrary(‘okFrontPanel’, ‘okFrontPanelDLL.h’);
if ~libisloaded(‘okFrontPanel’)
loadlibrary(‘okFrontPanel’, ‘okFrontPanelDLL.h’);
xptr = calllib(‘okFrontPanel’, ‘okUsbFrontPanel_Construct’);