this is the fourth part of our series on targeting vision applications to FPGA or
ASIC hardware the previous video outlines some specific hardware implementation decisions made
for the Lane detection design and this video will focus on the actual implementation typically once
you have designed your implementation and verified it against your golden reference
you would quantize it to the smallest data types that get used sufficient accuracy HDL coder can
synthesize single precision floating point types but for most digital hardware fixed point types
will reduce resource usage the challenge is always balancing this versus enough accuracy
the fixed point designer tool walks you through the process but for designs that use the vision
HDL toolbox gateways it is a no is necessary one of the really nice aspects of Simulink is being
able to visualize data types as they move through the data path the pixel data coming out of the
gateway block here is an unsigned 8-bit integer and as Simulink propagates it through the data
path it ends up coming out of the image filter as assigned 24-bit word data length with 15 of those
bits being fraction bits the same applies in the block where I left off at the end of the previous
video this block takes a rolling average of the last 16 Lane widths which are twelve bit integers
but Simulink automatic propagation takes the safe approach and provides as many bits as it would
possibly need when dividing by sixteen which is 32 bits with one bit being a sign bit and 18 fraction
bits knowing the design I know that it's going to be a positive number so it can be unsigned
and I don't need any fraction bits so I can just specify that it be unsigned twelve bits as this
and its left lane counterpart propagate forward into a multiplier the 32 bit input would require
tube DSP slices so using smaller data types can potentially save some key resources again fixed
point designer can take care of all of this for you but it helps to know what the design is doing
after verifying that it still generates results within my accuracy tolerance I can then generate
HDL the easiest way to get started is with the HDL workflow advisor which walks you through all
the steps I'm just going to focus on a couple key steps I'm going to target a zhiling zinc
device and I want to map my left and right lane outputs to registers that the software running
on the arm can read so I choose IP core generation and that lets me do this mapping in the next step
the pixels and control signals are coming in from an external memory buffer and the AXI stream for
video protocol is built right in for that and then the outputs here are all talking to the software
running on the arm so those will get mapped to AXI light registers now skipping ahead a bit I want to
make sure all these reports are generated so I can see how well it's mapping to my device there are
advanced options to customize the generated code and optimization options but all the defaults are
good starting points so I can just generate code and this takes a minute or so and it brings up
the reports the first thing I usually look at is the high-level resource usage report and compare
it to the resources on my devices datasheet to make sure it all fits often first things to look
at or multiply our resource usage because DSP slices are precious resources and RAM usage for
similar reasons both of those would typically be addressed by making design or optimization
trade-offs the critical path estimation tells you how long your slowest path is which is the gating
factor in how fast a clock frequency you can use in this case it's not a big challenge for
each second I want to process 30 frames of pixels with blanking intervals which comes out to twelve
point six megahertz which isn't very challenging that clock period is about 79 nanoseconds for
more challenging clock periods if I need to I can insert extra pipeline stages to break
long paths in the design or let HDL code or do it automatically finally the IP core generation
report will give you detailed instructions on integrating the core into your system on chip
device and the downstream implementation tools this video series covered a lot of ground at
a high level in order to give you an idea as to what it to implement a video processing subsystem
in hardware it may sound like a lot of work but this workflow has proven over and over to be more
productive than hand writing code in traditional workflows you can find more detailed information
on all of these steps in the product documentation and a great place to start are the examples such
as this Lane detection example since they walk you through practical applications in real scenarios