Hi, Brian: So far about a year has passed, several bloggers have ZED boards, and the biggest deal has been that Adam Taylor has an OS running on one core and bare metal on the other.
Xilinx changed Vivado and has a new architecture for the latest device that seems to emphasize HLS rather than ARM SoC. (haven't heard much about Altera)
Sure makes me wonder about the popularity/success of ARM on FPGA.
OpenCL is just a generalization of the Graphics PU concept rather than a general system solution to the memory wall/ von Neumann bottleneck.
Just as in most designs most paths are not critical for performance but absolutely necessary for product success. As you know, I am working on a design that is programmable using "C" source. It takes 3 true dual port memory blocks and 100 to 200 LUTs. NO proprietary HW or RISC.
I think this portability or vendor independency of OpenCL will kill the enthusiasm of the FPGA vendors to promote this language. Will the same happen to OpenCL as that happened to SystemC a decade ago?
I longed to see A's OpenCL tool to support the ARM+AXI4+FPGA SoC architecture rather than supporting the PC+PCIe+FPGA arch, but this does not happen until now. The hardware platform is not the bottleneck. The CPU and the on-chip Bus has all the power, and the application demands for OpenCL to differentiate the target embeded products are not rare. I believe the reason is not from engineering but from marketing. They need something proprietary to stop the users from easily moving to the other side.
Why does not X get into the OpenCL and A hold on its OpenCL release for SoC arch? Is it because of the Openness of it and the Portability non-issue?
Fool that I am, I can only hope that standards win over "lock-out" spec details re the soft- or hard-core processors. I think ARM is a great opportunity for some inter-brand compatibility to be introduced..... And I share the general skepticism that it will be so.
"Do you think the fact that ARM and OpenCL's names keep on popping up in both FPGA brands will help increase portability?"
My answer is No. Aside from the standard interfaces that come with the "ARM" it is the FPGA fabric/design that makes the product, but that still depends on the vendor tool chain.
The task is to design a system rather than an FPGA that is a "smart" peripheral. A system has many independent functions that range from slow human interaction to critical algorithm calculation.
The point is that a single tool flow and design approach is not appropriate.
And the ASIC world has plenty of cheap ARMs and interfaces. The main advantage for FPGA is a shorter design time, but the number of cells and wires on the latest dice will probably make P&R times unacceptable.
For complex FPGA functionality, I go with Brand X. For CPLDs, I go with XC9572XL and/or XC9536XL. If I need more than that, it's time for an FPGA. For small FPGAs, I've had good luck with ProASIC3 and Igloo from Brand M(A) [Brand M, formerly also known as a different Brand A]. However, if I were given the choice today for a small FPGA I'd certainly check out Brand L, specifically the iCE40 series (formerly known as SB).
I've used Brand A in the past with good luck, but I haven't seen a compelling differentiator between Brand A and Brand X once Brand X improved its tool usability around 2000. But then, maybe I'm just sore because AHDL didn't catch on :-)
My knee-jerk reaction is that you would be more likely to see something like (A || X || M) & L (where M & L stand for Microsemi and Lattice Semiconductor, respectively). I wonder if anyone would care to comment on this?
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.