#Netmap explanation driver

Typical ways network stacks address performance limits are, Who would even want to have scope functionality if continous capture can be archived? When this continous capture and streaming is archived, scope functionality can be left in the other FPGA branch, no reason to waste bits for that in continous capture DDR Dump code if they both need same resources. This would good to have feature for say network streaming, could use packet size buffers (see zero copy below) and also would not require as much real time work to track the status of ddr_curr_addr.

#Netmap explanation driver

After this one goes in use, CPU driver side can then see the ddr_next_addr in ddr_curr_addr and load next one.Īnd after that, I'm thinking about solution to have the ring buffer of addresses in the BRAM in DDR Dump firmware and trigger load of the ddr_next_addr stuff from there. Do you think it would be good idea to implement some kind of ddr_next_addr thing that could be loaded before the previous buffer finishes? Using large enough buffers might give the CPU enough time to refresh the next buffer in queue and allow more continous operation. Plot (time(1:n_plot_points),adc(1:n_plot_points,2),'r') Īnd for converting the 'wrong' misinterpreted Int16- to double-values i use this function: % transfer from 'misinterpreted' two's complement to double and scale to voltage % reformat to matrix (1MSample, 2 channels)

%% read data from file, interpret as unsigned int16