Slashdot Mirror

← Back to Stories (view on slashdot.org)

Soft Processors in FPGAs?

Posted by ryuzaki0 on from the taking-embedded-programming-to-the-next-level dept.

cybergibbons asks: "We're students in the Department of Electrical and Electronic Engineering, Imperial College, and are carrying out some research for Altera into FPGAs, softcore processors, and hardware software co-design. Most embedded systems are a combination of hardware (for performance) and software (for versatility), and the design of these systems is getting more and more complex. Previously, the hardware and software was partitioned at the early stages of design, leading to sub-optimal solutions. New languages such as SystemC and Handel C aim to merge the hardware and software design with one common language combining the high level algorithm design and low level RTL design ? the ultimate goal being to allow conventional C++ programs to be synthesized directly into working systems, without any human intervention. However, what we seem to have found is a lot of marketing spiel and conceptual papers with no practical ideas. Is anyone using any of these new tools? Are any of the current co-design tools any good? Do you think a computer can partition designs effectively into hardware and software? What features would you like to see in future tools? Do you envision any amazing new applications for FPGAs using new co-design tools?"

26 comments

  1. an interesting use of FGPA technology: The C-One! by Tumbleweed · · Score: 3, Informative

    The Commodore-One Reconfigurable Computer

    From the About page:

    The Commodore One computer started off as a 2002 enhanced adaptation of the Commodore 64 -the most sold of any computer model (Guiness book of World Records) While retaining almost all of the original's capabilities the Commodore One adds modern features, interfacing and capabilities. The C-One fills a gap in the hobbyist computer market.

    During development, it evolved into a re-configurable computer, a new class of computers where the chips do not have dedicated tasks any more. The two main chips carry out different tasks, depending on the needs of the program. The technology used is called FPGA - field programmable gate arrays. These chips can be programmed to do the tasks that the chips of the C-64 or other computers have done. It's no emulation, but it's a re-implementation of the chips that are no longer available since many years.

    The one thing that is not contained in the FPGAs is the main processor - it would take too much space, resulting in too high cost. To maintain flexibility, the CPU resides on a card that can be exchanged by the user - as simple as plugging in a PCI card.

    After a cold start, the FPGA programs are loaded from a mass-storage device like harddrive, disk drive or a compact flash card. What's described in one short sentence is a giant leap in computer technology: The hardware can be altered by the user without even opening the computer. The FPGA programs - so-called 'cores' - turn the C-One into clones of famous 80's computers like the C64, VIC-20, plus/4, TI-99/4a, Atari 2600, Atari 400/800 series, Sinclair Spectrum, ZX81, Schneider CPC and many more. It can of course also be a completely new computer with specs unknown to these milestones in computer history. That's what the C-One 'native mode' will be - read more on the Specifications page

    The estimated price will be about 249,- EUR. The user will need to supply an ATX style case, ATX power supply, drive(s), PS/2 keyboard, mouse and SVGA capable monitor.

    ---

    Too cool!

  2. New languages for the birds... by stevew · · Score: 4, Insightful

    I think you'll find that Handle C , System C, etc are not likely to be very popular with the run-of-the-mill designer. Most of these folks (me included) don't see the need for yet another design language. We get along fine with Verilog or VHDL.

    There HAS been a need identified for verification constructs in the languages - Vera and E are examples of stand-alone verification languages that are used in conjunction with the RTL design in Verilog/VHDL. With the advent of Superlog/SystemVerilog these languages are being included within Verilog itself. This features the best of both worlds, i.e. old IP still runs, and new constructs are added to make verification easier.

    So while there are a few adopters of SystemC, etc. I suspect they will fall by the way-side as SystemVerilog becomes a reality. It seems the EDA industry is going to back SystemVerilog above the other choices, and most designers seem to feel this is the best solution.

    --
    Have you compiled your kernel today??
  3. FPGAs: good System C: you could do better by brejc8 · · Score: 4, Insightful

    System/Handel C[++] are languages with two good points.

    They allow software engineers to design hardware with minimal training and secondly they allow fantasticly fast simulations. The ultimate system of you feed in an MP3 decoder writen in C and you get a player with software at the other end is years (I think more than 10) away.

    C is not a natural language to describe hardware. It creates large slow designs with very little transparency to the generated design. Transparency is important as a small looking piece of C code will generate a large slow design while a larger code will generate a smaller faster design. While trasparency is partly implicit in computer programs (You have a vague idea as to what the compiler will generate from your code) in hardware it is very easy to be well off.

    FPGA's are getting more and more popular and powerfull. There are allready numerous CPU designs available and the current methods of creating them (mainly verilog and VHDL) seem to be generating much better results than system C ones.

    As for soft computers I really like the idea. I would not be surprised to see some FPGA parts on the next 3d cards or CPUs. They allow hardware structures to replace complex code (e.g. I was trying to write code which effectively can be dome with a piece of CAM. hash tables are just a method of emulating CAM in programs).

    To conclude, Yeah C based methods will become more popular but only because menagement like them. They produce appauling designs but as silicon area becomes nearly free and in areas where speed does not matter and you need to do a billion simulation runs to test it then yeah it will show it self more attractive to software engineers trying to do hardware. But at the end of the day this is all cheating. If you want to design hardware you really have to learn what structures there are at the bottom level and only then when you know what your compiler will produce for you can you effectively make use of such languages. If companys can affoard to get proper engineers to make hardware they may fetch some C monkey to do it instead but I think if you want to become one then you are selling your self short.

    --
    Mouse powered Chips, Open source Processors and Lego
  4. Hardware/software boundaries need to be flexible by cait56 · · Score: 3, Insightful

    What I find intriguing about these systems is the possibility of starting with some custom hardware, and lots of C code to perform logic, and interface with the custom hardware.

    Now, if I knew that interface was solid. I'd just want a processor and a custom systems chip that did the usual memory/peripheral interfacing and whatever my special functions required. If I wasn't all that worried about chip count I might even put the special logic entirely on the memory bus as a seperate device.

    But more frequently I have some complex logic that I probably want to do in hardware, but I'm not certain and I'm not 100% certain that the algorithm is correct. For speed of development and refinement I need to express that logic in a very conventional language such as C.

    But planning ahead, I still define the function to fit within a state machine, to have defined inputs and outputs, and to avoid doing things that won't implement in hardware very well (like complex wanderings through main memory)

    I now have a module that is suitable to be implemented in hardware or software. Since I can do either, I take the first draft in software.

    By the time the code stabilizes I'll be confident that the algorithm is correct and I'll know how important optimization is to the overall performance of the system. I can now prioritize which modules are most worthy of translating into hardware.

    With a soft core I can shift resources between "software" and "hardware" without having to re-layout the board, design new pinouts, etc. In other words, I actually can shift resources. Try getting a board layout changed on a successful product just to optimize things sometime.

    If the "hardware"/"software" boundaries ever stabilize a lot, I can even consider going back to a conventional processor core and full hardware solution. More likely the market will demand totally new features by then.

  5. Re:Hardware/software boundaries need to be flexibl by cait56 · · Score: 1

    Oh, I forgot to add, this "software first, hardware later", development approach requires that the software development tools be of high quality. With too many of the systems I evaluated, the tools were not of the quality that any open systems developer would expect.

  6. Good ideas, but not yet practical... by stienman · · Score: 1, Insightful

    Bottom line:
    FPGA's can't handle the complexity for the programs we write today for general computer use
    FPGA's are much more expensive in terms of power and cost than an equivilant processor/ASIC/specific purpose chip
    FPGA's are exceedingly slow. In order to make them worthwhile, the hardware algorithm they contain must be massively parallel, or not require speeds that modern processors can attain - which leads back to the FPGA's cannot represent extrememly complex systems yet.
    Those people who have an interest in both software and hardware tend to lean to one side or the other, and end up writing drivers for embedded systems, or designing hardware for embedded systems, very few actually participate in the whole enchillada because of the complexity fo the complete system
    There's still a metric ton and many years of research work to be done behind the idea of a language that can be translated into both hardware and software
    Before this happens you're going to see VHLL (Very High Level Languages) come into increasing use - languages which make it easier to program extremely large, complex, interconnected software systems using a small set of human resources.

    Because, let's face it, hardware is freaking dirt cheap . You can go buy a computer now that has the processing power of a 5 year old supercomputer (though it can't quite manage the flow of information that supercomputer can handle, but that's a different discussion altogether)

    -Adam

    1. Re:Good ideas, but not yet practical... by hamanu · · Score: 3, Informative
      Some of your points make me question weather you understand the concepts here.


      FPGA's can't handle the complexity for the programs we write today for general computer use


      Sure they can! You can implement a general purpose CPU inside an FPGA; it would be slow and expensive compared to a real CPU, but it would be able to run any general purpose algorithm you can think of. There is no fundamental reason why you can't do anything with an FPGA, it all comes down to the PARTICULAR task at hand, and how best to accomplish it.


      FPGA's are much more expensive in terms of power and cost than an equivilant processor/ASIC/specific purpose chip


      This is only true if you think of an FPGA as a replacement for a regular CPU, running regular software. But there are 2 easy examples of tasks where and FPGA is cheaper, and more powerful. The first is when you have several programs or ASICS that are only used one at a time, which you can replace by a single FPGA that switches configuration as needed. The second is for specialized software tasks that are rarely used, so they're not worth optimizing a general purpose CPU for, but used a lot in certain situations. An example is high volume cryptography -- you can buy a fixed function card that does the work for you, but what if a new algorithm comes out? You have to buy a new card! with an FPGA approach you can just update the functionality, and re-use the silicon to perform other tasks when you're not doing cryptography!

      Another thing to keep in mind is that ASICS are only cheaper than FPGAs if you get into high volumes... In many cases off the shelf FPGAs are cheaper than ASICs until your product starts to sell in high volumes.


      FPGA's are exceedingly slow.


      BULLSHIT!!! My 89 corvette is exceedingly slow too, I guess. I don't know where you get this idea from. The speed you get out of an FPGA is entirely a function of how you choose to design the circuit inside it. The bigger the design the greater the potential speed. FPGAs can run moderate designs in the hundreds of MHz, and not CPU-like single operation at a time MHz, more like completely pipelined, one datachunk fully processed per clock MHz.


      In order to make them worthwhile, the hardware algorithm they contain must be massively parallel, or not require speeds that modern processors can attain - which leads back to the FPGA's cannot represent extrememly complex systems yet.


      Actually, FPGAs do better on tasks that are pipelinable and not just parallel, which basically includes all kinds of number cruching, and bit twidling.

      You need to better define what you mean by complex systems. Nobody is advocating implementing powerpoint in an FPGA, researchers are trying to offload tasks that usually require specialized hardware to programable hardware, not replace cheap CPUs with expensive FPGAs for no reason.


      Those people who have an interest in both software and hardware tend to lean to one side or the other, and end up writing drivers for embedded systems, or designing hardware for embedded systems, very few actually participate in the whole enchillada because of the complexity fo the complete system


      My intrest in this area comes from the fact that when the hardware arrives, the software team and hardware team spend a few months blaming each other while the bugs are worked out. If they worked together they would have a competitive advantage by getting to market sooner.


      There's still a metric ton and many years of research work to be done behind the idea of a language that can be translated into both hardware and software


      And it's a metric ton of high paying, fun work, and I don't see anything wrong with that.

      --
      every _exit() is the same, but every clone() is different.
    2. Re:Good ideas, but not yet practical... by Muad'Dave · · Score: 1

      FPGA's are exceedingly slow.

      FPGA's can be exceedingly slow if not applied properly. For a particular pat pending project I'm working on, there isn't a standard CPU or DSP engine available in the free world that's fast enough to do what an admittedly rather large FPGA can do easily. (Lots of parallel RF DSP stuff). There is a lot to be said for choosing the right tool for the job.

      --
      Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
    3. Re:Good ideas, but not yet practical... by Sdrawcab · · Score: 1

      Well, after designing this wizbang custom DSP, for which FPGAs are pretty slick, wouldn't it be implemented as and ASIC for the final product and be ever so much faster. (Can anyone say exactly what the differance is? Like if Softcore A is implemented on and FPGA and as HDL at 1GHz, the FPGA will perform like and HDL at 100MHz, or 1MHz, or even less?)

    4. Re:Good ideas, but not yet practical... by Hast · · Score: 1

      I'm not sure if I interpret your question correctly, the last sentence is hard to parse. ;-)

      But if you have an FPGA clocked at 100MHz and an ASIC clocked at 100MHz then they will be equivalent in speed, naturally. (If they have the same logic.) The difference is that an ASIC can be clocked a lot faster than an FPGA (FPGAs are typically limited to a few 100 MHz currently AFAIK) and that the ASIC can be made smaller and draws less power.

      A big reason for not getting an ASIC done is because it's extremely expensive. You really need huge volumes for that to be a good idea, and if it's not on a product you're selling it could be quite a bit cheaper to just stck with FPGAs. (With FPGAs you also have the possibility of reconfiguring them if the need should arise.)

      Besides, when doing hardware there are a lot more parameters than pure speed. If your goal is to process video or audio then you most likely have a given data stream to process (30 FPS video in VGA resolution or something like that). Creating hardware which is faster than this is not only wasteful but also draws more power than needed.

    5. Re:Good ideas, but not yet practical... by Muad'Dave · · Score: 1

      It depends on the production volume and whether or not your product must be easily field-upgradable. An ASIC is not amenable to field upgrades; the config memory for an FPGA can be flashed in the field by <gasp>the user!</gasp>

      --
      Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
  7. Sounds like transmeta. by mnmn · · Score: 1


    FPGAs would always be slower, more power-hungry and require more transistors than other RISC processors at the same cost. Economically, one vendor would release a "standard" architecture, all developers would aim for that platform and the software base would require everyone to use that architecture. This is true of the x86, and to a lesser extent the powerpc, sparc and 68060. If an FPGA chip can "become" any of these chips at a minimal loss of performance, there is great business potential, but theres greater business potential in selling a proprietary architecture, setting up a software base around it and forcing the consumers to upgrade to only your chips.

    --
    "Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
    1. Re:Sounds like transmeta. by Anonymous Coward · · Score: 0

      "FPGAs would always be slower, more power-hungry and require more transistors than other RISC processors at the same cost"
      ... as long as all you're doing is emulating the original CPU's instructions.

      The key with FPGAs is that you can do arbitrarily complex logic directly in the fabric. E.g. in the NIOS system you can design your own NIOS CPU instructions. One instruction might be "oh, compute the FFT of these thingies, then pass them through MD5 and, uh, let's throw in a matrix multiply too". If that's the inner loop of your application that's taking up 95% of the time, then doing that logic directly in the FPGA fabric rather than in the simulated ALU's will get you an enormous speed gain.

      The speedup is application-dependent, of course.

    2. Re:Sounds like transmeta. by mnmn · · Score: 1

      I wonder if a compiler can compile code so it sets up the array for an important loop, so rather than setting up the FPGA for each arch type, it changes on the fly for each function or application.

      Ive seen the ARM7 MCUs that have a large FPGA array incorporated next to it. If such compilers exist, we have a pretty nice cpu+gpu implementation.

      --
      "Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
  8. OT: Code Morphing by MBCook · · Score: 2, Interesting

    I've always wondered why Transmeta hasn't extended code morphing to other cores. Why not release a core than runs PPC code? Why not make a core than can run BOTH PPC and x86 code. Think about this. Apple could use Transmeta processors (since in the past they haven't been as fast as x86 processors anyway) but software like VirtualPC could run at the equivelent of full speed by using different codemorphing. Or you could do things the other way on the PC side. It would allow people to program on one platform and test on another nativly (not through software emulation of hardware) on the same PC.

    I think making the code morphing system be able to do multiple cores on one chip could have a LOT of good effects.

    Just an idea.

    --
    Comment forecast: Bits of genius surrounded by a sea of mediocrity.
    1. Re:OT: Code Morphing by bmac · · Score: 2, Interesting

      I've wondered why you can't target the direct transmeta ML. It has to exist as its own, separate entity, right? Why not have an OS that targets it directly? And, lastly, why would you create a chip and not write an OS for it in its native code?

      More questions than answers here...

    2. Re:OT: Code Morphing by BJH · · Score: 1

      Linus has commented on this before (when someone asked basically the same question as you on LKML) - here's his reply:

      The translations are usually _better_ than statically compiled native code (because the whole CPU is designed for speculation, and the static compilers don't know how to do that), and thus going to native mode is not necessarily a performance improvement.

      Another problem he mentioned was that the Crusoe core can't be 'reflashed' to emulate another CPU in the production versions, so you'd need a special development CPU to do it. Not to mention that Transmeta haven't released the specs required to do this, anyway.

  9. Re:FPGAs: good System C: you could do better by kinnell · · Score: 1
    I respectfully beg to differ ;-)

    I think the argument that high level languages can't be used to design hardware rests mainly on the premise that software is sequential, whereas hardware is completely parallel. Handel C (and perhaps SystemC?) uses communicating sequential processes, much like VHDL, to allow the expression of both parallel and sequential algorithms. I don't agree with your assertion that software engineers can learn Handel C and become hardware engineers, because it requires a change of approach from sequential design to parallel design. Most software engineers can learn to write VHDL fairly easily, but as you know, simply getting a VHDL design to compile and simulate is a long way from designing good hardware.

    I think you also underestimate the advantage fast simulation.

    I think with the increasing capacity of FPGAs, high level languages will become a much more cost effective way of designing hardware, but on the other hand HDLs will almost certainly stay around. It will be similar to the use of assembly language vs. high level languages in software. For small, timing critical subsystems, HDLs will be better, for large complex subsystems which don't have to be particularly efficient, high level languages will be better.

    In the end of the day, it's about choosing the right tools for the right job.

    --
    If I seem short sighted, it is because I stand on the shoulders of midgets
  10. Why not make a core than can run BOTH PPC and x86 by Anonymous Coward · · Score: 0

    Because a number of Transmeta developers were formerly IBM developers working on the 615 project, which was exactly what you suggest. They knew what they were getting into.

    615 was slow, too.

  11. Automating co-design with AI by TuringTest · · Score: 1
    An aproach with I think is promissing for co-design is to use Constraint Programming. You build a declarative model (the algorithm you want to partition) and the intelligent system find through search the optimal partition, much in the same way as layout is currently done.

    If you have access to IEEE papers you can read an article about codesign with Constraint Satisfaction, or if not you can always ask Google about the subject.

    --
    Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
  12. Soft Core processors by Muad'Dave · · Score: 2, Funny

    ...softcore processors...

    Are these the processors they sell on late-night infomercials on ski^H^H^H Cinemax?

    --
    Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
  13. Some examples, for free! by XenonOfArcticus · · Score: 1

    The Free-IP project, put together by a friend of mine, aimed to do just this. They have a 6502 design, and a RISC processor as well. Unfortunately, other contributions were sparse, and Real Work has gotten in the way of him creating and giving away any other designs.

    --
    -- There is no truth. There is only Perception. To Percieve is to Exist.
    1. Re:Some examples, for free! by stevew · · Score: 1

      Well - the point is that www.opencores.org has FAR surpassed what these guys have. You can build REAL SOC's out of the large selection at opencores, and they actually work!

      --
      Have you compiled your kernel today??
  14. Wow, worked on this stuff at least 8 years ago... by Anonymous Coward · · Score: 0

    I worked on a project where we used reconfigurable logic via runtime reprogramming of Xilinx based FPGA's. We used 3030's which were the baddest of the breed back then. I think we might have been the first to do realtime reprogramming, shortly thereafter Xilinx got interested in this. We used them to do video/raster image processing & enhancement. The Xilinx had some pins dedicated into I/O busses between each FPGA, software controlled serializing and loading new CLB bits into the SRAM cells. I developed the RTOS, video processing code and other low-level functions. What the Xilinx FPGA's did for us was:
    1) beat the snot out of the other video processors in a variety of aspects, including cost.
    2) allowed us to reduce board real-estate and produce a more compact design.
    3) adapt the design to changes without the need to have new boards fabbed.

    There were many challenges using the FPGA's available at that time.

    One of the engineers I worked with went on to build some professional multi-channel DSP studio gear using a similar approach, and last I heard he had some company in Utah called Starbridge Systems or something like that, not sure if they have a shipping product or are just selling IP? http://www.starbridgesystems.com

  15. Future of hardware codesign is probably by baseinfinity · · Score: 1

    System Verilog

    Pretty much a HDL of the future that's still being developed, has all the best features and none of the bloat of VHDL and some other HDL languagues.