Blog
Comment
one_armed_bandit
This same concept was obvious to me when FPGAs first came out. Either case: the ...
BobC_
I've been hungrily monitoring this concept for over a decade, trying to ...
Dynamic reprogrammability seems rather static
Brian Bailey
8/22/2011 5:46 PM EDT
Some technologies see quick adoption, while others languish in the shadows. There are times when a technology that sees quick adoption dumbfounds me as to what people see in it, or why it should become so popular.
I am not going to list my idea of the dumbest technologies because in doing so I would surely offend all those who think it is really neat – or at the very least show my ignorance for the real utility that they have. On the flip side, there are technologies that have seemed to me to make a lot of sense that just never seem to take off, and sometimes I cannot fathom out why. I would like to discuss one of those very briefly here.
The technology in question is dynamic reprogramming. For those of you who have ever read one of my books that deal with taxonomies for ESL (ESL Design and Verification or ESL Models and their Application), you will know that I have an axis specifically allocated to this very concept – Configurability. Also, I have spoken about this subject in general in a Previous Blog.
Today, I want to talk specifically about the one extreme of the axis that I defined as dynamic configuration. By this I mean the ability to reprogram an FPGA, or at least part of it, while the system is running. Blocks of code would be pre-compiled and ready to be mapped into an FPGA with a fixed configuration. Standard interfaces would be used to communicate between the software and hardware such that the routine could continue to operate in software, if acceleration resources were not available, and would have an efficient connection to the hardware if that was to be used. Streaming interfaces and several memory access mechanisms would be available depending on the application needs.
It was probably 15 years ago that I tried to get a research program started on this very subject, and even though I was offering money to fund the program I couldn’t find a single professor interested enough to take it up. It seemed to me to be a logical extension to an operating system. To start thinking about FPGA resources as being just another limited and shared resource that had to be allocated to software that wanted to use it.
This would make the scheduling a little more difficult because of the time necessary to reprogram the FPGA, and even more complex if something was using the FPGA when a higher priority task came along and wanted to use the resources for itself. But by treating the FPGA as a sort of cache, such that functionality can be paged in and out, it would be a fairly controlled environment. I think part of the problem back then was it didn’t appeal to the hardware guys because it involved an operating system and it didn’t appeal to the software guys because too much hardware knowledge was required. Those days are gone in many Universities today with the EE and CS departments either fully joined or at the very least cooperating. I do find a few papers on the subject, but few that seem to make real progress.
Historically there were also some practical limiters such as those associated with global reprogramming and load time. By global reprogramming I mean that you could only reprogram the entire FPGA and thus a system would need several independent resources if it wanted to keep using one while another one was being prepared. The other limiter was the time it took to reprogram them. This is just a matter of the time it takes to write all of the necessary configuration data into the device. But it seems to me as if both of these limitations have been overcome, or at the very least improved to the point that they are no longer show stoppers. The configuration time is still significant, but it would appear to me that for many of the cases where this is to be used, the need to schedule an “algorithm” to be prepared for execution in an FPGA can be anticipated such that the load time should not be an issue.
So, I would love to hear your opinions as to why this is not a practice that is seeing more widespread usage. Is there still a cost issue such that the devices that could really make use of it cannot afford the monetary cost, the power budget, or some other factors? I do remember hearing concerns about verifying such dynamically configurable systems, but I also consider this to be a well controlled problem. Each block does need to get verified twice – once in software and once in hardware, and the mechanism to load the modules needs to be verified, so there is some incremental cost – but is this enough to kill the idea?
Brian Bailey (www.brianbailey.us) – keeping you covered
If you found this article to be of interest, visit Programmable Logic Designline where you will find the latest and greatest design, technology, product, and news articles with regard to programmable logic devices of every flavor and size (FPGAs, CPLDs, CSSPs, PSoCs...).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
I am not going to list my idea of the dumbest technologies because in doing so I would surely offend all those who think it is really neat – or at the very least show my ignorance for the real utility that they have. On the flip side, there are technologies that have seemed to me to make a lot of sense that just never seem to take off, and sometimes I cannot fathom out why. I would like to discuss one of those very briefly here.
The technology in question is dynamic reprogramming. For those of you who have ever read one of my books that deal with taxonomies for ESL (ESL Design and Verification or ESL Models and their Application), you will know that I have an axis specifically allocated to this very concept – Configurability. Also, I have spoken about this subject in general in a Previous Blog.
Today, I want to talk specifically about the one extreme of the axis that I defined as dynamic configuration. By this I mean the ability to reprogram an FPGA, or at least part of it, while the system is running. Blocks of code would be pre-compiled and ready to be mapped into an FPGA with a fixed configuration. Standard interfaces would be used to communicate between the software and hardware such that the routine could continue to operate in software, if acceleration resources were not available, and would have an efficient connection to the hardware if that was to be used. Streaming interfaces and several memory access mechanisms would be available depending on the application needs.
It was probably 15 years ago that I tried to get a research program started on this very subject, and even though I was offering money to fund the program I couldn’t find a single professor interested enough to take it up. It seemed to me to be a logical extension to an operating system. To start thinking about FPGA resources as being just another limited and shared resource that had to be allocated to software that wanted to use it.
This would make the scheduling a little more difficult because of the time necessary to reprogram the FPGA, and even more complex if something was using the FPGA when a higher priority task came along and wanted to use the resources for itself. But by treating the FPGA as a sort of cache, such that functionality can be paged in and out, it would be a fairly controlled environment. I think part of the problem back then was it didn’t appeal to the hardware guys because it involved an operating system and it didn’t appeal to the software guys because too much hardware knowledge was required. Those days are gone in many Universities today with the EE and CS departments either fully joined or at the very least cooperating. I do find a few papers on the subject, but few that seem to make real progress.
Historically there were also some practical limiters such as those associated with global reprogramming and load time. By global reprogramming I mean that you could only reprogram the entire FPGA and thus a system would need several independent resources if it wanted to keep using one while another one was being prepared. The other limiter was the time it took to reprogram them. This is just a matter of the time it takes to write all of the necessary configuration data into the device. But it seems to me as if both of these limitations have been overcome, or at the very least improved to the point that they are no longer show stoppers. The configuration time is still significant, but it would appear to me that for many of the cases where this is to be used, the need to schedule an “algorithm” to be prepared for execution in an FPGA can be anticipated such that the load time should not be an issue.
So, I would love to hear your opinions as to why this is not a practice that is seeing more widespread usage. Is there still a cost issue such that the devices that could really make use of it cannot afford the monetary cost, the power budget, or some other factors? I do remember hearing concerns about verifying such dynamically configurable systems, but I also consider this to be a well controlled problem. Each block does need to get verified twice – once in software and once in hardware, and the mechanism to load the modules needs to be verified, so there is some incremental cost – but is this enough to kill the idea?
Brian Bailey (www.brianbailey.us) – keeping you covered
If you found this article to be of interest, visit Programmable Logic Designline where you will find the latest and greatest design, technology, product, and news articles with regard to programmable logic devices of every flavor and size (FPGAs, CPLDs, CSSPs, PSoCs...).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
|
|
|
|
|
Navigate to related information
Max the Magnificent
8/22/2011 5:55 PM EDT
Hi Brian -- I totally agree -- I think dynamic reprogramability (which I take to be the ability to reprogram specific portions of an FPGA while the rest performs its task) is full of potential ... like an algorithm implemented in hardware that fine-tunes itself to better match the profile of the data it's seeing ... but I can also see why it would be such a pain from the perspective of the folks who create the design tools ... and the thought of debugging such a design makes my eyes water :-)
Sign in to Reply
BrianBailey
8/22/2011 6:03 PM EDT
But I don't see why debug should be a nightmare. It is no different than if you verified the function in an FPGA to begin with, or debugged it in software. Then if a bug is found in the hardware version of that function, it can be fixed with a download, or flagged to not run in hardware.
Sign in to Reply
bpadalino
8/22/2011 6:09 PM EDT
I believe we will be seeing this more and more, especially with hard ARM cores with AMBA being the high speed interconnect. More importantly, you won't need to verify twice. You verify once in C, and let your ESL tool take your functions and make the appropriate hardware out of it. You get fast simulation speed (in C) and the FPGA vendor proves out their system loading capability. In something like linux, imagine the FPGA loading happens before the program ever starts in some crt0.s - then depending on which parts are loaded into the FPGA, those parts are hardware accelerated.
I believe you'll see Xilinx really attacking this hard - especially with the purchase of AutoESL and their AutoPilot tool.
For these systems, where the IO doesn't matter and the computational power does, PCIe or close AMBA will be used for communication, and everything will be transaction level modeling.
I am surprised this isn't being worked on right now with all the PCIe add-in cards you can see with FPGAs. It's the first step in customized hardware acceleration.
Sign in to Reply
BrianBailey
8/22/2011 7:17 PM EDT
This is a slightly different and lessor form of reconfigurability. The configuration here is basically fixed at design time. Then we take the design through a bunch of steps and finish up with a design that does not change from that point onwards. Because an FPGA is used, we do have to configure it as part of the "boot" procedure, but after that the FPGA does not get modified during operation. On my axis this would be termed configurable.
Now it is also possible that some of the IP blocks used may also be programmable, such as a communications controller and these setup parameters could be changed during operation.
For full dynamic configuration I mean that part of the FPGA will get reloaded with completely different functionality during operation.
Sign in to Reply
BobC_
8/22/2011 8:03 PM EDT
I've been hungrily monitoring this concept for over a decade, trying to conceptually map real-world problems to dynamically cooperating hardware and software solutions, waiting for the required technologies to converge and mature.
The first problem is that FPGAs are still too awkward to use from the perspectives of design implementation and of operating system utilization.
I believe the entire process must evolve to the point that a moderately capable embedded/real-time developer such as myself (a Computer Engineer) can do the whole basic process, soup-to-nuts, with a high-end EE needed only for optimization.
To do this, the FPGA design process must evolve to be closer to current software development norms. In particular, the test environments for the hardware and the software components must be close to identical: The test harness used to test a software function must also be used to test its hardware doppelganger, the only permitted differences being in the timing domain.
And, ideally, the language used to create the test harness should be the same one used to create both the software and hardware implementations. Perhaps different code for each, but the same language.
Impossible? Not any more! I recently stumbled across MyHDL, a Python-based HDL that uses a restricted Python for the HDL, and unleashes the full power of Python for the test harness. And it emits both Verilog and VHDL for feeding to conventional FPGA toolchains.
Similarly, the PyPy project permits Python to run at speeds equivalent to native C++. Yes, Python!
Now you can code a complete cyborged application in Python, both the software, hardware and test system. I have just started down this path, studying MyHDL and ordering an FPGA development board.
What do you think? Are you ready to have an entire hardware-software application be Python Powered (tm)?
Sign in to Reply
one_armed_bandit
8/25/2011 9:25 PM EDT
This same concept was obvious to me when FPGAs first came out. Either case: the system detects a change (ie an event, like a normal state machine), and loads the code to handle the case; or generates the code on-the-fly as a function of several inputs - both tables and chunks of logic. Two FPGAs could ping-pong back and forth.
This is similar to swap or dynamic load areas on early DOS systems, where there was not enough memory to hold all code. Particular functions/mini-programs would be dynamically swapped in to execute, then free up the area when done. These areas had a specific name I cannot remember right now. (A specific example was the DOS used on the Signetics TWIN and TEK 8001/8002 ICE systems - the same machine, different generations.)
Since C variants are becoming more wide-spread for FPGA programming, the on-the-fly is becoming closer to reality. One concept is something similar to YACC, ie feed a on-the-fly generated table of some sort to a code generator (as one feeds BNF to YACC), which generates the C code, which is then compiled and fed into another FPGA or portion of the same FPGA.
BTW - I hereby publicly put this into the public domain. If you see a patent on the concept, please fight it. (I am sure the same concepts occurred to others, and the article/comments heavily imply when they do not explicitly state the concepts. Just tired of patents on prior art and obvious stuff...)
Sign in to Reply