As I noted in an earlier What's Next blog, I am talking to some of the visionaries of the programmable industry about where we have been, what today's challenges are, and where we might go in the next several years. The idea is to provide the rest of us with a starting point for discussions, thoughts, and prognostications.
In my column last week, I included comments from Navanee Sundaramoorthy, embedded platform manager at Xilinx (this site's sponsor), about today's challenges with FPGAs/MCUs -- devices that combine hard MCU cores with programmable FPGA fabric. Today's blog covers some of Navanee's thoughts on what the future will look like for these devices. As usual, I have started a new message board, where we can continue the discussion.
Automatic algorithmic partitioning
Navanee sees a couple of key long-term goals that will provide dramatic new capabilities to the typical design. Most of these capabilities are centered on the concept of providing an architecture -- along with design and verification tools -- to allow algorithms to be partitioned automatically between processing resources (the MCU) and the FPGA's programmable fabric. These capabilities can range from simple extensions of current features to completely new design techniques.
One simple example would be letting the user write code without needing to define the various MCU peripherals. The software would decide if DMA, SPI ports, etc. were required, allocate hard instantiated peripherals, and then add others using programmable fabric as required. This would make it easier for a typical MCU designer to use the FPGA. An even more complex version might analyze the software and determine if in-line code could be replaced with peripheral functions. For example, an obvious code-based timing function could be replaced with a timer and interrupt implementation.
Navanee also described a more advanced approach that takes a higher-level view of the design. Many designs have a variety of control loops that implement key portions of the overall design. For example, he described a controller for an industrial production line. Some parts of the algorithm, like the human-machine interface (HMI), will run fairly slowly. Others, like connection to a real-time Ethernet communications system, will operate very quickly. Still others, like motor control functions, will operate at a midrange speed. It is convenient to think of these control loops as having different "loop times," which we may think of as the time in which a single decision needs to be made. Fast control loops may have only nanoseconds to make a decision. Slow loops, like an HMI, may have milliseconds, and midrange control systems might have a microsecond.
@jacek hanke-- you are right to be considering future engineers. They will need to know how this is done in order to have a full, well-rounded knowledge. In other words, I couldn't have skipped calculus and differential equations just because I have a fancy scientific calculator!
Re: That would drive a new Paradigm to the DO-178/DO-254 Certification Split for FAA Certification
Maybe it would be a new paradigm, or you could treat it like software (C/C++). Today you veryify the software but don't necessarily check the compiler, assembler & linker. If you move to an abstracted hardware modeling language like MatLab, Vivado HLS (a C to HDL tool) then should they be treated like a compiler?
They convert from one language to another using prefixed libraries and defined instructions - like a compiler. Synthesis, place and route are like the assembler and linker and maybe they should be looked at the same way. That is C code with a "differnet" compiler, assembler and linker. You may have an advantage because you can simulate the HDL and verify that the output is the same as the MatLab or C output, which is more difficult to do with assembly and C.
The times they are a changing - standards, coding guidelines, tools, methodologies, verification, software and hardware are all going to be impacted. It'll be interesting to see where we are 5 and 10 years from now !!
That would drive a new Paradigm to the DO-178/DO-254 Certification Split for FAA Certification
With DO-178 covering the software portions and DO-254 Covering the hardware portions -- One would have to go in and see what the tool mapped to what to certify it -- or develop a new unified paridigm.
Hybrids are the inevitable result of the objective of FPGA vendors which is to provide an alternative to ASICs in the low-mid volume market. ASICs typically consist of custom digital logic ( which in turn consists of glue logic, advanced digital circuitry for DSP and hardware Acceleration), a microprocessor, memory, and possibly some Analog and RF stuff.
Pure FPGAs attempted to integrate the custom digital logic and uP found in ASICS by taking advantage of softcores such as Microblaze and NIOS I/II for over a decade now. These microprocessors where quite powerful and where implemented into the FPGA's fabric.
Now while softcores have advantages i.e. you can instantiate multiple cores on a large enough FPGA or instantiate only certain components of the needed core e.t.c, they had some severe disadvantages, basically their performance was limited by that of the FPGA fabric and they consumed significant amount of power.
Integrating hardwired silicon based cores with FPGA fabric was the ultimate next step in the evolution of FPGAs. And yes while it was attempted before e.g. Altera Excalibur (ARM9), Xilinx Virtex-5/ PowerPC e.t.c. I think that it will probably gain more traction now than a decade ago. The FPSLIC is not as good an example as Xilinx's Virtex-5/PowerPC parts which were relatively successful in the market in the past
Jacek Hanke 7/26/2012 2:42:09 AM User Rank Blogger
Re: Hybrids
The whole idea looks pretty cool and should save our time. I agree with almost all pros and cons. But did you guys think about future engineers? I mean the one who'll be taking their lessons in few years time? Wouldn't they be "stunted" or "belated" - if the sofware make for them almost all the stuff, wouldn't they be some kind of "narrow specialists"?
At first glance MCU + Programmable peripherals sounds sensible, but history is littered with those that tried this, and found you can now have too many balls in the air.
Atmel FPSLIC, was uC + FPGA, but the uC was constrained so customers had to need a uC, but not too large, and enough FPGA to wear the $$$ hike, but not too much of that either. End result is too few customers.
Next came Triscend and again, the same combinations shrink the customer set,
Now we have Cypress PSoC3/5, and Actel SmartFusion trying again.
Cypress prices are high, and the Logic fabric is sadly rather slow, and meanwhile, companies like Lattice offered MachXO2, so a [Choice of Std Micro] + [Choice of MaxhXO2] is looking like lower prices, and much better performance.
One thing Cypress did get right, is the wide Vcc operation.
Xilinx side-stepped one variable, by avoiding microcontrollers, and chosing Arm9 and external code memory, and targeting LCD bridge style customers.
The other approach many are quietly taking, is multi-core controllers, commonly asymmetric. NXP, Freeescale, Parallax, XMOS et al, have offerings. This can give deterministic peripherals, and is project flexible.
Then there are those who simply user more Microcontrollers. Checked how many uC are in your nearest vending machine, or car, lately ?
Warren has finally started to write some HDL code to implement his chess-playing FPGA, but he's not a professional coder, so he needs our help and advice.
What might we see in new Ultra Low Density (ULD) CPLD families three-to-five years down the road? Are there new technologies or programmable structures that will find their way into ULD devices?
We are ready to consider how to use our Move Generator to traverse the tree of possible moves efficiently and find the sequence that produces the best board position.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
