I loved reading the post of respected sir Brian and comments of different personnels of hardware engineering faculty. I find myself interested to this topic and is researching on how can I implement FPGA as a more easier platform to be used in general purpose activity. I am a M.Tech(Embedded Systems Design) student. I have practically less experience then respected personnels but I promise to show my dedication and hard work on this field. I humbly request all the respected Sir to help me out informing and discussing the advancement taking place on this subject matter. Thank you.:)
What about approaches such as National Instruments LabVIEW FPGA? The FPGA essentially looks like a hardware accelerator. One could imagine architecting FPGAs so that they are optimized for a particular software development environment. The downside is that the resulting unit is like an SBC, not a chip.
It takes desire to realize optimum performance of a system that can only be achieved as a result of appropriate mapping of functions to processing elements. We will continue to see tighter integration of a variey of types of processing elements on the same die that give the system designer choices for optimal mapping of their functions. Many domain specific tools exist to assist the design, verification, and implementation of hardware and software. And, some tools exist to assist the co-design of hardware and software. Most of the co-design tools are collections of tools from the domain specific sets simply bolted together with incremental value added. For many years we have created new languages and augmented languages to extend their domains. We have not done such a good job at creating new capabilities to enable the analysis of designs expressed abstractly and successively refine the abstract to the explicit. We need tools that help us partition the system and enable trade-off analysis of key parameters such as Size Weight and Power (SWaP), and Performance as implemented on the variety of processing elements. Such tools would accelerate the decisions system designers need to make to realize an optimum system and return orders of magnitude returns over current methods and tools. So, FPGAs will become as ubiquitous as processors because they will be one in the same and we will have tools to design at an abstract level and simplify the process and reduce the time to deliver products that meet customer requirements. I am encouraged by the efforts of the big 3 and start-ups to provide these tools.
Standardization will indeed help a lot. Huge IP (Appstore) infrastructure deployable easily. I think the good news is things are going in positive direction to mix, both FPGA vendors and processor vendors have realized it(it will take a while indeed).
FPGA guys (Hard Processors, IP leverage, HLLs) and big guys (Intel Stellarton direction) indicate future is gona be mix of both and efforts are on way.
I agree with Jagdish we need to look at the heterogeneous computing devices emerging compared to absolutely comparing them. There can be opportunites for IP vendors, EDA vendors, new startups, Academia to levarage this trend (find research/business opportunities). As things are indeed heading for collison in future.
Some more stuff in a changes trends talk i gave few months back at FPL-10
I agree with Frank with the opinion that FPGAs donot really compete with microprocessors. In fact, if we complement both the technologies then we have a wonderful solution & such a thing is indeed happening around us with the integration of processor cores into FPGAs.
I feel we need to look at the situation with an attitude of combining the Two technologies, rather than trying to contrast them.
Given a system consisting of an embedded verified processor and several verified peripherals, then the software is the unverified part. It seems that a software simulator is needed for verification using this approach. How many embedded processors have software simulators and debuggers? Or is the RTL of the processor simulated and the software debugged based on the RTL?
I think the latter is the case, and it is doomed to failure.
Brian makes some excellent points. Like most types of design these days, verification is the major challenge. If we break down his key points, you’ll understand why:
Simplicity: The complexity is not in the way the design comes together, it is verifying that the design works as planned. Debugging of FPGA designs are in the stone age relative to other devices. Debug tools that enable direct diagnosis of implementation issues are required for FPGAs
Independence: The reason why software development and debug is so productive in hardwired microprocessors is that the source level debuggers generally run on the actual processor itself, meaning it is being tested in a “Native Device” manner. What is needed for FPGAs is the same “Device Native” debugging environment so the user sees the behavior of the code (in whatever form it originates) while in the software environment (i.e. the simulator). A Device Native approach like ours from GateRocket brings the microprocessor debug and verification use model to FPGAs.
Abstraction: The ability to work in higher levels of abstraction is nice – but to truly leverage its benefits from a verification standpoint, designers need to be able freely move blocks from the implementation (inside the FPGA) back to the software world (without having to re-run synthesis and place and route). In this way, teams can preserve design intent from HDL through to Silicon. We have a feature called SoftPatch that allows this type of interaction and flexibility that takes advantage of higher level design techniques, but also allows designers to work on only portions of the design.
Brian, here's a thought on your question:
"But why cannot FPGA become more like processors?" .. The FPGA tools focus on hardware description, placement, and routing. Computers focus on the sequences to perform a function. To date, synthesis main focus is the RTL/data flow and not on the control flow.
FPGA's need to have ways to map sequencial functions into hardware.
By parsing the C code and turning the sequencing conditions into Boolean, control logic can then be put into memory blocks and changes can be made to the memory contents rather than doing total synthesis, place, and route.
Less focus on how the hardware works is required.
Of course Synthesis will have to be trained to leave some spares laying around like we used to do with the 7400's.
This analogy works great even if the level of platform complexity is different. I think the key difference is in the maturity of 3rd-party apps/IP ecology of iPhone/FPGA platforms.
Before the venue of iPod/iPhone there was an existing mature ecology of 3rd-party IP providers in place (Sony Music selling “star IP” Céline Dion) but delivering IP on other media (CD). Apple’s success has been to make them converge on the same platform that’s replacing the CD by a file and the music store by a website (roughly). The level of maturity of this IP ecology was already at a point where the IP (CD) was completely decoupled from the platform (CD player) and since a very long time (before cassette/Walkman). This IP/platform decoupling had happened because people were asking better performance (professionals signers) and always cheaper and more private concerts (portable self-listening music). This sounds similar to the challenges that are facing the embedded systems design today (performance, costs, TTM).
In the embedded system space, no such 3rd-party IP ecology (I mean system-level, not component level) is still in place. On a system-level IP point of view, we are still at the age of people buying their chip&tools (instruments) to create their own songs (internally produced IP) and to sell them through their own product lines (private concerts?). However, this way to proceed as reached its limit in delivering more performance, cheaper and faster.
FPGA are well qualified to overcome those challenges but I agree with Dr.DSP, the key part resides in having a broader 3rd-party system-level IP ecology that allow apps to be provided on those FPGA. Would the iPhone been so popular if Apple expected people to program their apps themselves? Its success relies on the capacity to economically bring powerful 3rd-party apps/IP to easily customize a common HW platform (iPhone/FPGA). Everybody has the same HW but nobody has the same phone (apps/IP set).
More on my blog: www.pe-fpga.com
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.