Developing in the sandbox
Today's digital applications demand more custom, high-speed processing than ever before. Consider the US Military, who might be monitoring the air for enemy radar pulses. When an enemy pulse is detected, the military can capture and process the enemy's signal, and spit back an altered version of the pulse to confuse the enemy. To be effective, this of course needs to be done blisteringly quick--in real-time. The only way to achieve data processing rates in real-time at these speeds is to use hardware. This can be done with customizable networks of parallelized logic using FPGAs--what the digital community has been referring to as "the sandbox". These customizable play-pens are where designers create artwork. Just as a blank canvas is to an artist, an FPGA sandbox is to a designer. Forward-thinking companies are paying big bucks for engineers to get their hands dirty and play in the sand.
Everybody is talking about the sandbox, but few are playing in the sand.
Unlike the traditional school yard sandbox, the FPGA sandbox can be a daunting one to enter. Firmware design truly is a different animal than the design of sequential software algorithms, and there is a steep learning curve to even get started. Learning FPGA design cannot be taken on as a side project--you won't be able get away with putting an hour a day to learn. Software designers are brought out of their comfort zone with the idea of parallel processing. This parallelization goes against the sequential way of thinking that humans are programmed to do. Debugging can be orders of magnitude harder than debugging a software program; often times it will call for both software and hardware debugging (hopefully you kept that DMM from ECE 1A!). The software tools that are used in firmware development (contrary to let’s say Visual Studio) are not as polished. Error messages are not nearly as helpful and syntax mistakes can be costly. And once source files are successfully compiled, there is a whole 'nother universe called design verification. Separate, gargantuan programs are written (testbenches) which can often times be larger and more complex than the actual component that is being tested. And having an operational testbench does nothing towards guaranteeing that simulated results will map over to hardware. With all of these drawbacks of developing in the sandbox, one should hope that the resulting sandcastles are magnificent sculptures -- and they are! Despite these knocks, the sandbox has still seen an increase in population of engineers capable of programming it. Some of these engineers are abandonees from the world of ASICs, the more-expensive, riskier-to-develop older brother of the FPGA.
Get yourself a nice shovel
If there is one thing that you can do to maximize your efficiency in developing in a sandbox, it's get yourself a nice shovel and bucket! There are oodles of tools available to those willing to venture down the rabbit hole that is firmware design. Each successive generation of FPGA that comes out is accompanied by a new generation of IP cores and supporting software. Actually, there is an entire industry that is developing who's foundation is based on the development of DSP IP Cores. Aside from a growing sea of IP cores, the newest Vivado builds have more 3rd party software tools (such as MATLAB or Modelsim) stitched into their fabrics. Testbenches thousands of lines of code long have been pre-developed to save engineers time and headaches.
Keysight Technologies provides these tools in various forms, such as the U5340A FDK. This FDK (or “FPGA Development Kit”) is a bundle of software packaged together to ensure the user fast and efficient design creation. Included in these packages are example designs, IP cores databases and predefined components, a script based development and simulation environment, a calibration digitizer, integrated debug facilities, and specific software API. To find out more information about the U5340A FDK, visit Keysight.com/find/U5340A. You can also explore Keysight.com for more firmware development tools, such as SystemVue or M3602A. Knowing which tools are available to design and debug is half of the battle. The other half? Digging your knees into the sand and grinding away!