About a year ago (on an impulse) I began the discussion The discussion was meant to inspire a spirited conversation, that's why I started the discussion with:"The community does a ton of projects with MCUs. If they do the job for you, that's great. But the element14 community is about learning, experimenting and roadtesting. In this spirit, I am proposing that you should try building your next project with an FPGA (SoC), if it suits the application, of course. What's stopping you?"
What ultimately happened is that the discussion took on a life of its own and received a whopping 100 comments. (Imagine a room filled with 100 engineers gabbing, discussing, arguing passionately to put this "virtual" scene in a tangible form). The discussion surprised me. For sure, it generated a lot of opinions, but the one that stood out for me was a comment by element14 Top Member Workshopshed Andy Clark who answered the question posted in the title with the following:
The main reasons stopping me getting going [are]:
1) The need for a change of mindshift from sequential programming to logical building blocks
2) Learning a whole new toolset to get these things programmed
3) A Killer app. Given that I can do most things I need using a microcontroller I've no need to swap to FPGAs
Ah, the killer app! I guess this phenomenon is at the heart of technology inventing and re-inventing itself. I did a little research about killer apps and FPGAs, and found that there is a lot of FPGA market growth right now due to the "high adoption in smart-phones and hand held devices, [and their] implementation in wireless networks for increasing the bandwidth and growing demand for electronics components in automobile industry (Source: MarketWatch.com). But there's more to technology adoption than killer apps: the developers who design the products need to adopt the technology, don't they... That brings me back to me title. What's stopping you?
element14 member Andy Clark mentioned two other factors that may impede a design engineer from developing new products with programmable logic devices. These two reasons revolve around what I would define as the learning curve that a design engineer would need to go through to transition from designing hardware with microcontrollers/microprocessors to using programmable logic devices such as FPGAs or SoCs. Since the element14 community does a pretty good job, I think, of nurturing skills and building knowledge, this discussion morphed into the seed of what the element14 team called the "Path to Programmable" program.
The Path to Programmable: an FPGA/SoC Training Program
Using the comments in the above discussion, the element14 team had a few brainstorming meetings to discover if we could host a program that could tackle the learning curve challenges of adopting programmable logic device design. We fleshed out the idea and decided to launch a training program with a simple premise: provide some engineers who had limited (if any) experience designing with programmable devices a training program and have them blog regularly about their experiences to learn more about what is easy and what's hard about adopting PLD technology.
The Path to Programmable program had an application process where the applicants completed a detailed form. I read through a hundred pages of applications! After selection, we sent the official trainees an Avnet Development Board for MiniZed Single-core Zynq 7Z007S and gave them access to the MiniZed Speedway Design training. Then we had them complete the training and labs while we monitored, read, and enjoyed their blogs.
What We Learned About The Path To Programmable Devices
I had little doubt that the applicants I chose for trainees in the Path to Programmable program could handle the coursework and blog about it in a substantive way. After all, they are all engineers and very bright people! But they came from a variety of disciplines; not all of them had programmable logic device background. At least one was a software engineer and another was a student. Prior to offering this program, element14 published two Essentials learning modules on programmable logic and FPGA/SoCs to have some basic information for those who were not experts in this area.
So, after 126 blogs, 470 comments and 59,556 page views on the element14 community, what did we learn?
I read all the blogs and have summarized what I feel are the key conclusions of the program and the learning curve challenge:
- A lack of familiarity with new terms or elements (e.g. block RAM - BRAM) posed some problems. They were overcome through additional research. At least one trainee felt more videos should be available to explain new elements or terms to facilitate understanding.
- The complexity of the Zynq 7000 SoC makes it flexible and appealing from a design standpoint. But it also requires that the designer knows exactly what he/she is doing. One trainee said that the Speedway course "seems designed for true full-time embedded programmers who need to know the exact inner workings and the nuts and bolts of how to make their program run efficiently." Without this type of structured training, the complexity "hump" can become onerous and unnecessarily extend the learning curve.
- Another side of the complexity hump was expressed in the need of knowing more about the Programmable Logic (PL). Another trainee felt that connecting peripherals posed a bit of a challenge, and said "the AXI interconnects are used to interface the peripherals in a master/slave relationship. There are high speed and low speed AXI ports, and you can configure the data size and memory parameters for each port. I watched this video 3 times and did the lab twice to figure out what was going on."
- How to use VHDL/HDL was a concern of another trainee. He didn't feel he had a good handle on it.
- Getting comfortable with the Vivado and the Xilinx SDK was a hurdle for most of the trainees. The Speedway training walks you through fairly well. Again, without it, a designer would require a significant learning curve. One trainee probably said it best: "As we modify the hardware in Vivado, there are quite a few steps required to get it running on the actual board: Synthesize, generate Bitstream, Export. Open SDK, Import hardware and generate Board Support Package. Create a new application (even it it is an empty 'do nothing' app), THEN we can program the FPGA, Then we have to run the application."
A Taste of the Projects
The conclusion of the program was to build a project. I recommended that the trainees build a simple project due to time constraints of the program. Some of them are complete, while others, which are more complex, are still in progress. What follows is a taste of the projects.
While this project could easily have been done with a microcontroller, and often is, avnrdf decided to build one with the Minized, using both its PS and PL. Here's how it works: "The WS2812 RGB LED uses a single wire serial protocol that infers '1's and '0's by varying the width of a pulse. The project moves the serial output generation & refresh to the PL. The idea is that software in the PL simply writes 'data' to an 'address' in the BRAM (which corresponds to the RGB data of a LED of a given index), and the logic in the PL independently iterates through all the data in the BRAM using the other port, refreshing the LEDs. the main parts are the application that runs in the PS, the AXI4-Lite interface, a custom AXI to BRAM interface, dual port BRAM, a custom BRAM to RGB interface and a RGB to WS2812 generator. I could have used memory mapped BRAM using the Xilinx AXI-BRAM IP, but decided to build a custom interface that uses registers."
Designed by aspork42 and based in the FPGA fabric, "it generates an interrupt every "N" clock cycles; and I mapped it to the 48 MHz clock. This interrupt then feeds into the interrupt concatenator as interrupt #0. I used the IP Library to find new IP and import into my hardware design."
Continuing, "I then exported the hardware and made a new workspace & BSP in the SDK utility. I started with some base code in the SDK and got it working with my new hardware to run things. So I'm using both the PS + PL. I had to re-map the interrupt which was used in the base program to the one generated from Vivado."
Video Gimbal Project with PMOD TDM114 Camera Module
This project started out as something interesting using the PMOD TDM114 camera module. To control the camera module, "I'm going to use a X-Y gimbal made from RC servos. I will run the servos from the MiniZed. To do this, I have modified the code from the IP training to run two RC servos instead (and addition to) the PL LEDs." (Designed by rsc
Gamma Radiation Measurement with the Avnet MiniZed
This project was quite a suprise to me. But kk99 stated that "I have a really nice sensor module called GDK101 which measures gamma radiation in range up to 200 usV/h. This sensor has really simple communication interfaces: I2C or UART. There is also analog output which could be used for verifying the energy spectrum analysis of gamma photons." [His] plan [was] to use this module to measure gamma radiation and the energy spectrum analysis of gamma photons. The first step was to setup an I2C controller in PS of the MiniZed and communicate with sensor module. The second stop was to use the ADC sensor and create in PL a multichannel analyzer to see the spectrum.
The microphones included on the Minized board are surface mount ST MP45DT02 MEMS (Micro-Electro-Mechanical Systems) connected directly to Zync - 7000 AP SoC on the MiniZed board. It can take the PDM (pulse density modulation) from the microphone and convert it to 16 bit PCM (pulse code modulation) in two's complement format at a decimated sampling rate suitable for audio. mconners found an example project that would help him. He already had a version of MATLAB, which was necessary to conduct this experiment. That, along with System Generator utility of the Vivado design suite allow him to model circuits in MATLAB, using Xilinx IP blocks, and then export that design out to Vivado to program the FPGA.
Community Participation Drives Program Results
The blogs and the projects of the Path to Programmable program aren't the only thing that I looked at to gain insights that could be leveraged in future activities. Clearly, the Path to Programmable generated a lot of interest. This is typical (I think) of most element14 programs, But, often times, the real jewels of any element14 program are the probing comments and incredible discussions by members responding to the program blogs.
An example of one of these discussions in the Path to Programmable program was about boundary scan testing. Here it is:
"How does having multiple FPGAs on board each with boundary scan work - I would imagine with so many connections, it would be a case of increasing the number of combinations of inputs/outputs and perhaps taking longer? But would it be a case of just connecting the JTAG bus daisy chaining each of the FPGAs? Along that vein, any indication of how fast this can occur? From what I know, it is also digital rather than analog, but there is also "weak drive" capability for resolving conflicts/shorts ... is this correct?"
While the above comment may seem tangental to Path to Programmable program itself, discussions of this nature are critical to the integrated community fabric of element14. Perhaps a bit more "on topic" was a comment in response to the question how can the programmable logic device learning curve could be decreased?
Here it is:
"I think the learning curve for FPGAs is pretty steep as in the last 5 years a huge amount of progress has been made in the FPGA tool chain. And even I had to re-learn quite a bit to get a good hang of the new tool chain from designing hardware to writing your own software code and combining the both to get them going. [If there were] more simple projects and examples [available, this could] make it a bit easier to start. Available IPs for generic hardware sensors is something Xilinx is already doing. I have seen that often when people see working hardware they get excited. Another good step taken by Xilinx is that they made the tool Vivado free unlike [their] previous ISE. With this everyone can download and give it a go."
Before I Go: A Big Thank You
Before I wrap up, I'd like to thank all the people who participated directly in Path to Programmable, or indirectly as a commenter or an interested party. All of the official trainees have to my knowledge full time jobs, so they completed the lessons, labs, and the project-building on top of their other commitments. I really appreciate their efforts and value their participation in the element14 community. Are these the final words on Path to Programmable? Not quite. We are busy planning Path II. I'll keep you posted when I have more information.
Sincerely,
Randall Scasny
Path to Programmable Program Manager
Top Comments