matlab to fpga in 5 steps video -凯发k8网页登录

hello everyone and welcome to this mathworks webinar ' matlab to fpga in 5 steps', an introduction to the hdl coder workflow.  

i am raghu sivakumar part of the product marketing team in india hyderabad, responsible for mathworks solutions for fpga, asic and soc development.

a quick overview of the webinar's agenda, i will talk about the motivation for the webinar, then take a pulse detector algorithm in matlab as an example for this webinar and then demonstrate the design workflow.  

in this webinar i will start with the pulse detector algorithm in matlab and by the end of the webinar, we will have a well-defined readable hdl code, with its inputs and outputs defined and its datatype defined in fixed point. and to get to this code, i did not have to write any of the hdl. in this webinar i will show how in incremental steps i went from matlab to hdl code.  

this brings me back nicely to the motivation of this webinar. we have many customers working on applications such as signal processing, wireless communication and image/video processing who are predominantly in matlab. they ask us how they can take their matlab algorithms, onto an fpga evaluation board! they either have little knowledge of fpga programming or their hardware design engineers are too busy. if this situation relates to you, i would request you to spend the next 30 minutes watching this webinar matlab to fpga in 5 steps.

lets now take the pulse detector algorithm in matlab. i choose the pulse detector as it’s a commonly used algorithm in many applications, and it is familiar to a wide audience. the key takeaway is the steps and rather than the algorithm, the algorithm can be a filter, a chirp signal ofdm etc.  

the pulse detector algorithm in matlab, i define the pulse, insert it in the transmit signal. for a real-world receive signal, i add noise to the transmit signal. now to find the pulse, i pass it through a filter with its coefficients defined and to detect the pulse pass it through a max function. so as you can see in matlab i was able to work on the entire frame. but in hardware this frame will be an incoming stream of data on which operations are performed, while managing the timing of parallel paths. simulink is good for this. we can visualize parallel paths; it has a built-in sense of timing and we can visualize data type propagation through the operations.  

both matlab and simulink work seamlessly together and you can even include matlab code within simulink. this i will demonstrate during the webinar.  

the design workflow we recommend to our customers is to take advantage of both textual programming and visual modelling of matlab and simulink and building a time-based system in a simulation environment.  

using matlab, we will create our golden reference. the part of the algorithm that we want implemented on the hardware, this will be our first step. in step 2 we will model a sample-based hardware implementation in simulink. we will optimize our hardware in step 3 where we will optimize for speed and resource usage. in step 4 we shall quantize the data type into fixed-point. and finally in step 5 generate the hdl code. at each step we will ensure that the functionality and correctness is verified against the matlab golden reference.

in step 2 we will model our peak detector in the simulink environment.  

the matlab frame based golden algorithm will be converted into a sample-based simulink model.  

in matlab we used a filter and passed the signal through the max function to detect the peak. in simulink we will design our model to work on the incoming stream of data and detect the peak by sliding a window on the last 11 samples. to detect the peak, we will use three stages, filter the incoming stream second computing the max function, and detect the local peak. 

let’s take a look at the demo.

we will make use of simulink's hdl optimized library with over 250 blocks to model the hardware implementation

the ' signal from workspace' block is used to create the stream of data, this sample data is then sent through a discrete fir filter block. the block parameters are the variable values from the matlab algorithm. we are simply re-using the work we did in matlab.

in simulink one can visualize the structure and the flow of data as it moves through the mode. we will log specific signals that we will later use to verify the simulink model with the matlab golden reference.

in matlab we were able to find the global max of the entire signal, and the function uses complex operations such as square root. in hardware as the signal is streaming in, we will calculate the local max. in order to save resource, rather than using complex operations like square-root, we will design it to sum both square of the real and imaginary part of the signal.

next, we calculate the max of the most recent 11 samples. this is easily done in matlab and we will use the matlab function block to include ml code in the model. the peak is found by checking if the middle sample is larger than others and also greater than a minimum threshold.  

this method enables detection of the pulse immediately, as this processes the streamed signal as it arrives. 

the peak is held by the delay enabled block and displayed when the detected signal becomes high.

in order to verify if this simulink model functions as per our matlab golden reference, we will run a comparison between the logged signals of the simulink design, against the golden reference. throughout this process, we will employ a matlab test bench script for the verification purpose.

the location of the peak detected in matlab and simulink are the same and the correlation error is in the range of -17 eps.

with this step, we have modelled the hardware implementation in simulink, and established that both environments matlab and simulink work seamlessly together, as we even included matlab code inside simulink.

the takeaway from this step -  

1. by using simulink's 250 and more hdl optimized blocks, we created the hardware implementation of the peak detector.
2. it was possible to visualize the data flow from different operations
3. logging the simulink signals of interest later utilize for verifying against the golden reference…
4. including matlab code in simulink environment.

having modelled our hardware implementation in simulink, we will focus on optimizing our architecture - making it efficient and optimized hardware design.

we will first prepare our model for hdl code generation, then use optimization techniques to control speed and area tradeoffs in hardware design. additionally, we will add a signal validity check to the hardware design.  

running the hdlsetup command, calls a series of instructions which will run in the background and configure several model parameters. this sets the model solver to a discrete fixed step time solver, and each sample tick will correspond to one clock cycle of the fpga - how fast data gets clocked and the timing of signals through parallel paths. sample rate time on the blocks is represented in color, red depicts the fastest sample rate.

the pulse detection implementation is grouped in a sub-system which we will call pulse-detector. this sub-system also called device under test (dut), will be implemented on the hardware target (hdl will be generated from this part of the simulink model). we can now focus on the individual blocks inside this pulse detector subsystem to optimize the hardware.  

we will replace the discrete fir filter block with a discrete fir filter hdl hardware optimized block. this block offers filter architecture and pipeline register placement that are designed to be dsp blocks resource efficient. simulink provides a range of such hdl optimized blocks that are optimized for hardware design.

the discrete filter block has a built-in signal validity check option. using data valid checks is a good practice and also commonly used in hardware designs that interface with non-continuous data source. and for this demo i have set the receive signal to be true, as input to the valid signal for the filter.  

among the factors that determines how fast the clock cycle/discrete time fixed step is on the fpga, is how much operations or computation needs to be done in a given clock cycle. inserting pipeline registers along parallel paths improves clock speed. hdl coder offers a variety of ways to insert pipeline stages during code generation to shorten paths so you can run at a higher frequency. its delay balancing feature inserts matching pipeline stages on the parallel paths. i will illustrate here by inserting them all manually, which also gives me the ability to simulate this behavior at a high level.

to visualize the effect of pipelines we will insert them manually on the parallel paths and simulate the hardware design model. the parallel paths being the inputs to the fir filter block and the outputs from the local peak subsystem and the filter_valid signal path.

we will make sure the changes made to the simulink model has not affected its functionality and verify the logged signals against the golden reference. running the verification test, we can see that the location of both the matlab and simulink environments are the same and also the correlation error is in the -17 eps range.

the key takeaway form step 3

1. we used the hdlsetup command to prepare the model for code generation, learnt how simulink's solver relates to the to the fpgas clock rate.
2. used hardware efficient blocks and added valid signal check. we used pipelining methods to improve the clock rate - a key factor that decides the clock speed in the functional design
3. also, by verifying our hardware optimization without datatype quantization, ensures quantization noise does not hide your design errors.

so far, we have converted our frame-based matlab algorithm to sample based simulink model, demonstrated how matlab and simulink environments work seamlessly together. we took the sample based simulink model, optimized it for code generation and added details for efficient use of hardware resources.

in step 4 we will quantize the data types to fixed point and verify it against the golden reference.

in matlab the data type defaults to 64-bit double precision floating point, and in digital hardware data type is represented by fixed-point as it is resource efficient and also reduces power consumption. in matlab fixed point is represented as signed or unsigned followed by the word length made up of the integer and fraction part.

so in this section we will take advantage of simulink's ability to visualize data type propagations through operations and use the data type conversion blocks to convert the data into fixed point. in this demo, i have predefined my fixed-point data variables, ensuring the entire range of receive signal is represented. we will enter the fixed-point variables in the model using the data type conversion blocks. we will update the model to visualize the word length of the fixed-point data through the operations to show that simulink automatically propagates fixed point and maintains precision. when we reach the multiply operation, we recommend to convert the signal to 18bits word-size and similarly convert the word length to 18 bits after the add operation. the reason we do that is for the multiply and add operations to get mapped to a single dsp block on the fpga hardware.

for this demonstration it was possible to define the fixed-point variables and convert the data types, but for large and complex models, we can use the fixed-point designer tool. the tool collects the range of data by running the model, it then proposes the fixed-point data types, and we can apply the proposed value or set your own. finally, we can run the model, see the effects of quantization, and go back and make changes where necessary. this allows for re-run the simulation with multiple quantization options and provides visual information on data overflow, underflow.

with the device under test now quantized to fixed-point, we will verify if the changes made give us the desired results as per the golden reference. running the verification test, quantization errors are highlighted as a warning. this is an expected behavior due to saturation and scaling of the data-types. the whole idea of quantization for hardware design is to find the balance between efficiency and accuracy. while the location of the peak from the matlab and simulink is same, the correlation error has increased due to quantization.

in step 4 we covered the following topics…

1. we saw simulink's ability to propagate and maintain data-type precision through the operations,
2. managing bit growth. converting the word length to 18 bits so that multiply-add operations get mapped to a single dsp block
3. fixed point designer a graphical user interface tool, that collects the data range, proposes fixed-point, and lets you simulate and compare results.
4. and we verified the quantized model against the golden reference.

in the final step 5, we will generate and synthesize our hdl code. for demo purpose we will choose the xilinx zynq device and in order to synthesize after generating the hdl code, we include the xilinx vivado synthesis tool on the matlab path.

in this section, we will see the capabilities of the hdl workflow advisor and also demonstrate reports that trace between the generated code and the simulink model.  

to start we will run through a sequence of checks, using the hdl code advisor. this checks for model, ports and blocks settings to ensure compatibility for code generation. additionally, this also enables you to check the compatibility with native floating point and industry standard checks. as these two are not applicable, we shall skip these. when running these checks if there are errors in the checks, you can either directly make the changes recommended in the model or choose the 'modify settings' to make the changes automatically.  

having checked our model, we will use the hdl advisor, which will take us through a series of tasks and settings selections. here we will enter details of our target device, device package, target frequency and the synthesis tool. in hdl code generation settings, under the optimizations section we opt for adaptive pipelining, and to get reports and choose the clock setting we will opt the necessary choices.  

having made our selections, we can now generate the hdl code by running the task ' generate rtl code and testbench'. when all the tasks have completed successfully you have generated the hdl code which is well structured, commented and readable. the reports that we opted for provide us with information on resource utilization and estimates multiplier, dsp blocks utilization. optimization report links to where additional registers were inserted in the final model, for example in the compute power subsystem block, you can see hdl coder has automatically added pipeline registers in order to improve the overall clock speed. the traceability works both ways, one can either use the generated hdl code to navigate to the simulink model and from a block in the model trace its hdl code. for this demonstration i have chosen the multiply block, and i am showing you how i can trace it back from the code to the model and from the model back to the code.

with the generated hdl code, you can synthesize using the hdl workflow advisor which supports third party synthesis tools, else you can use the synthesis tool of your choice. using the hdl workflow, the tool creates the necessary files and folders and runs the synthesis in the background and in addition provides reports on critical timing path on the model. this design workflow enables users to explore the design at a higher abstraction level and leads to quickly finding the best hardware architecture to meet their goals.  one such customer 'orolia' a company which provides positioning, navigation and timing (pnt) solutions for defense and space applications, had to develop receiver hardware for their second-generation beacons. prior to this they had utilized analog designs and had little experience with designing and implementing digital receiver. using matlab and simulink they designed a specialized sdr and implemented the design on an analog devices rf system on module. hdl coder was used to generated synthesizable hdl. this enabled the engineers to focus on designing intelligent algorithms and by taking this design approach the engineers were able to shorten development by 8 months and reduced the fpga implementation time by 50%.

with hdl coder, we can connect our matlab algorithm and system design to fpga prototyping hardware. with the hdl coder you are generating synthesizable, vhdl or verilog from matlab functions, simulink models and stateflow charts. taking the time to build the sample-based model in simulink, adding hardware architecture, converting to fixed point and verifying each of the steps against the golden reference lets you control resource utilization and target your algorithms on fpga in systematic steps. the hdl code that is generated is target-independent and portable, and if you have to try the code on another device you can.

i hope what we discussed and demonstrated today was of interest to all. to find out more use the following resource links which provides information on topics of verifying the code, fixed-point conversion and i encourage you to try the hdl self-guided tutorial available on mathworks file-exchange. if you are interested in evaluating the hdl coder tool and want to get started visit our getting started page or get in touch with your mathworks sales contacts.

thank you all for listening and we can now spend rest of the time answering questions regarding the topics discussed.