streaming data from hardware to software -凯发k8网页登录

this example uses:

a systematic approach to design the data-path between hardware logic (fpga) and embedded processor using soc blockset.

applications are often partitioned between hardware logic and embedded processor on a system-on-chip (soc) device to meet throughput, latency and processing requirements. you will design and simulate the entire application comprising of fpga & processor algorithms, memory interface and task scheduling to meet the system requirements. you will then validate the design on hardware by generating code from the model and implementing on a soc device.

supported hardware platforms:

xilinx® zynq® zc706 evaluation kit
xilinx zynq ultrascale™ mpsoc zcu102 evaluation kit
xilinx zynq ultrascale™ rfsoc zcu111 evaluation kit
zedboard™ zynq-7000 development board
altera® cyclone® v soc development kit
altera arria® 10 soc development kit

design task and system requirements

consider an application that continuously process data on the fpga and the embedded processor. in this example, the fpga algorithm filters the input signal and streams the resulting data to the processor. in the implementation model , the buffer block represents the transfer of data from fpga to processor. the processor operates on the buffered data and classifies the data as either high or low frequency in the processor algorithm subsystem. fpga generates a test data of either low or high frequency sinusoid based on the dip switch setting in test data source subsystem.

the application has following performance requirements:

throughput: 10e6 samples per second
maximum latency: 100ms
samples dropped: < 1 in 10000

challenges in designing datapath

the fpga processes data sample by sample while the processor operates on a frame of data at a time. the data is transferred asynchronously between fpga and processor, and the duration of software task can vary for each execution. therefore, a queue is needed to hold the data between fpga and processor to prevent data loss. this queue is implemented in two stages, one as a fifo of bursts of data samples in fpga memory and other as a series of frame buffers in external memory. you will need to set three parameters related to the queue: frame size (number of samples in a frame of data), number of frame buffers and fifo size (number of bursts of samples in fifo).

these design parameters affect performance and resource utilization. increasing the frame size allows more time for software task execution and to meet throughput requirements at the cost of increasing latency. typically, you set these parameters only when you are ready to implement on hardware, which presents the following challenges:

it is difficult to debug issues like dropping of samples in hardware due to lack of visibility.
it is difficult to design your application efficiently without first evaluating the effects of hardware interfaces. it can take many design-implementation iterations as you can assess performance only via implementation on hardware.
it is difficult to optimize design since performance and cause-effect relationships are difficult to determine through implementation.

ideally you want to account for these hardware effects while you are developing the application at design time, before implementing and running on hardware. one way to satisfy these requirements is to simulate the hardware effects, at design time. if you can simulate the variation in task durations, utilization of memory buffers/fifos and external memory transfer latencies, you can evaluate their effects on application design and implement the proven design on hardware. soc blockset allows you to simulate these effects so you can evaluate the performance of the deployed application before running on hardware.

design using soc blockset

create an soc model from the implementation model using the . the top model includes fpga model and processor model instantiated as model references. the top model also includes axi4-stream to software block which model shared external memory between fpga and processor. these were earlier modeled using buffer block in the implementation model. to improve simulation performance, fpga algorithm is also modeled for frame-based processing and is included as model variant subsystem at the top level. you can select the model to run in frame-based or sample-based processing by selecting from the mask of fpga subsystem.

design to meet latency requirement : latency in the datapath from fpga to processor comprises of the latency through the fpga logic and the time for data transfer from fpga to processor through memory. in this example, the fpga clock is 10mhz and the latency is on the order of nanoseconds. this is negligible in comparison with latency within the memory, which is on the order of milliseconds. therefore, let us focus on designing for latency for data transfer in the following manner.

begin with a few potential frame sizes and calculate frame period for each frame size in table -1. frame period is the time between two consecutive frames from fpga to processor. for this example, fpga output sample time is 10e-6 as a valid data is output every 100 clock cycles from the fpga.

$frameperiod = frame size * fpgaoutputsampletime$

latency of the memory is due to time elapsed by samples in the queue of frame buffers and fpga fifo. let us size fpga fifo equivalent to one frame buffer. to stay within the maximum latency requirement, calculate the number of frame buffers for each frame size as per:

$(numframebuffers 1) * frameperiod <= maxlatency$

maximum latency allowed for this example is 100 ms. since the number of buffers account for maximum latency requirement, for all the cases in table-1, latency requirement is met. the maximum number of frame buffers allowed by the software dma driver is 64. a minimum of 3 frame buffers is needed in external memory for data transfer. while one of the frame buffers is written by fpga, the other frame buffer is read by processor. therefore, case #8-10 from the table below are rejected as they violate the minimum buffer requirement.

to visualize the latency, simulate the model and open axi4-stream to software block, go to performance tab and click on view performance plots under local master. select all the latency options under plot controls and click create plot. as captured in figure - 2, you will notice that the composite latency meets the < 100 ms requirement.

design to meet throughput requirement : on average, the software tasks processing must complete within a frame period, as otherwise, task will overrun leading to dropping of data and violate the throughput requirement. i.e.

$frameperiod > meantaskduration$

there are various ways of obtaining mean tasks durations corresponding to frame sizes for your algorithm, which are covered in task execution example. mean task durations for various frame sizes are captured in table 2.

to simulate the model with the parameters corresponding to rows (#2-#7) in the table use the function set_hwsw_stream_set_parameters function with row # as an argument. set the model parameters for row # 2 as below:

soc_hwsw_stream_set_parameters(2); % row # 2

since the mean task duration of 1.56 ms is more than the frame period of 1.0 ms, the data is dropped in the memory. open logic analyzer and notice that signal icfifodroppedcount is increasing throughout the simulation as captured in figure 3, indicating accumulating amount of dropped data.

since data is dropped during transfer from fpga to processor through memory, this is reflected as a drop in throughput. open axi4-stream to software block, go to performance tab and click on view performance plots button under memory controller to see the memory throughput plot as in figure 4. note that the throughput is less than the required 0.4 mbps. since the fpga output data sample time is 10e-6 and each sample is 4 bytes wide, the required streaming throughput for the system is 4 bytes/10e-6 = 400 kbps.

design to meet drop samples requirement : since the task durations can vary for many reasons like different code execution paths and variation in os switching time, it is possible that data is dropped in the memory. specify the mean task execution duration and statistical distribution for task durations in the mask of task manager block. size the fifo equivalent to one frame buffer. set the fifo burst size to 16 bytes and calculate the fifo depth:

$fifo_depth = framesize / fifoburstsize$

now, simulate the model for 100 sec (10e6 samples at 10e-6 samples per second) for cases # 3-7. open the logic analyzer and note the number of samples dropped on signal icfifodroppedcount.

soc_hwsw_stream_set_parameters(3); % set the model parameters for #3

open simulation data inspector and add signals from memory as shown in figure 5 below. note that as buffers usage (signal buffavail) increase to the maximum 11, the fifo usage (signal isfifoentries ) begin to increase. when fifo is completely used, the samples get dropped (signal isfifodroppedcount )

the results of simulation for all the cases #3-7 and resultant sample dropped per 10000 are tabulated in table 3.

the highlighted entries (rows #4 and #5) are valid design choices since they meet throughput, latency and drop samples requirement.

implement and run on hardware

following products are required for this section:

hdl coder™
embedded coder®
soc blockset support package for xilinx devices, or
soc blockset support package for intel devices

for more information about support packages, see soc blockset supported hardware.

to implement the model on a supported soc board, use the tool. open the mask of the fpga subsystem and set the model variant to sample based processing. by default, the example implements the model on a xilinx zynq zc706 evaluation kit. to open soc builder, click configure, build, & deploy in the toolstrip and follow these steps:

on the setup screen, select build model. click next.
on the select build action screen, select build, load, and run. click next.
on the select project folder screen, specify the project folder. click next.
on the review hardware mapping screen, click next.
on the review memory map screen, view the memory map by clicking view/edit. click next.
on the validate model screen, check the compatibility of the model for implementation by clicking validate. click next.
on the build model screen, begin building the model by clicking build. an external shell opens when fpga synthesis begins. click next.
on the connect hardware screen, test the connectivity of the host computer with the soc board by clicking test connection. to go to the run application screen, click next.

the fpga synthesis often takes more than 30 minutes to complete. to save time, use the provided soc_hwsw_stream_top-zc706 bitstream by following these steps:

close the external shell to terminate synthesis.
copy soc_hwsw_stream_top-zc706 bitstream to your project folder by running this command.

copyfile(fullfile(matlabshared.supportpkg.getsupportpackageroot,'toolbox','soc',...
        'supportpackages','xilinxsoc','xilinxsocexamples','bitstreams',...
        'soc_hwsw_stream_top-zc706.bit'), './soc_prj');

load the pre-generated bitstream and run the model on the soc board by clicking load and run.

while the application is running on hardware, toggle the dip switch on your board to change the test data from 'low' to 'high' frequency and notice the blinking of corresponding led on the board. you can also read the samples dropped count in the model running on external mode. thus, you verify that your implementation from soc blockset model matches the simulation and meets the requirements.

implementation on other boards: to implement the model on a supported board other than the xilinx zynq zc706 evaluation kit board, you must first configure the model for the supported board and set parameters by following these steps.

in the simulink toolstrip, on the system on chip tab, open the configuration parameters window by clicking hardware settings.
in the configuration parameters window, in hardware implementation, select your board from the hardware board list for the top and processor models.
in the hardware board settings section, expand target hardware resources. under groups, click fpga design (top level). select include 'axi manager' ip for host-based interaction and specify ip core clock frequency (mhz) as 10.
under groups, click fpga design (debug). select include axi interconnect monitor.

next, open soc builder and follow the same steps as for the xilinx zynq zc706 board. modify the copyfile command to match the bitstream corresponding to your board. for example, if you are using an altera arria® 10 soc development kit, use this command to copy the the .periph and .core rbf files.

copyfile(fullfile(matlabshared.supportpkg.getsupportpackageroot,'toolbox','soc', ...
         'supportpackages','intelsoc','intelsocexamples','bitstreams', ...
         'soc_hwsw_stream_top-c5soc.rbf'), './soc_prj');

this examples includes these bitstream files with the .bit or .rbf extension:

soc_hwsw_stream_top-zc706
soc_hwsw_stream_top-zedboard
soc_hwsw_stream_top-zcu102
soc_hwsw_stream_top-xilinxzynqultrascale_rfsoczcu111evaluationkit
soc_hwsw_stream_top-c5soc
soc_hwsw_stream_top-a10soc.periph
soc_hwsw_stream_top-a10soc.core

conclusion

in this example, you use a systematic approach to design the data path between hardware logic and an embedded processor. you can configure the example to meet your system performance requirements of throughput, latency, and number of dropped samples. by simulating and visualizing the effects of these parameters on the complete model containing hardware logic, processor algorithms, external memory and processor task durations, you can uncover issues like loss of throughput, latency, and dropping of samples before implementing the model on hardware. use this example to ensure that your design works on hardware before implementation and avoid long design-implementation iterations.