When compiling a piece of software (with LLVM for exmple), you first transform your code into some kind of intermediate representation (IR code). This IR code needs to be converted to your target specific assembly code.

When we have a fixed processor architecture, often optimizations are made to make the machine run a bit faster, or consume less memory. It is always a trade off when designing the ISA, is this computation general enough to dedicate a separate instruction for it, so that later on when compiling software, these optimizations can be made.

With soft cores, however, we could make a whole new processor every time we have a new piece of code. Often we see soft cores being designed for a specific purpose, while still keeping them general purpose enough so that they can be reused, or still work well when the software is changed.

It seems possible to, instead of first making designing the processor and then compiling the code for the target, making the processor based on your code. Profiling and debugging could be done on a general purpose machine running the intermediate representation code. Based on those results, an effective instruction set can be generated. With that instruction set, a soft core can be generated.

Designing an instruction set and building a good soft core and making a proper tool chain for target compilation steps is a lot of work, but it seems possible to automate this process. I could not find anything on this topic however.

Is this just too complex to do, and are we just better of having a few settings for your soft core with a bunch of optional extensions? Like you often see with soft cores like the Microblaze or NIOS II.

Or is this already a thing and can I just not find it? I do know of coarse grain reconfigurable architectures, but these are more for parallel computations and aim to replace FPGAs for some purposes.

Also, is this stack exchange the right place for these quite multidisciplinary questions?

  • 1
    $\begingroup$ There are commercial offering from at least Cadence and Synopsys. The keyword to use when looking in the design automation literature is "hardware-software co-design", but you seem to be aware of it. $\endgroup$ Mar 15 '18 at 21:18

Soft cores are still intented to be able to run different applications and have a general purpose, with of course some new instructions or peripherals usefull for the needs of what will run on the FPGA.

When wanting to optimize only one application from a common software programming language to run on a FPGA, there are already some compilers trying to do this, like recently reconfigure.io which aims to use Go: https://reconfigure.io/

If the project doesn't need to be able to load and run new programs in a general way, you're better to not use a soft core as it will waste a lot of resources on your FPGA.

If for example you're using the LLVM IR representation of a software, you could effectively optimize a soft core for it, but it's losing the aim of a core to be able to run multiple programs efficiently. If you're intending to run only one program in an optimized way, generating an hardware description of it (like what you're doing by using languages such as VHDL or Verilog) will be more efficient.

  • $\begingroup$ That is kind of what I meant, writing a program and compiling it to hardware. The problem with things like vhdl and HLS is that if you are trying to implement every functionality, it takes way to many resources and time. You can make some hardware software co-design where you still need a general purpose core and dedicated hardware. If you can make a core that offloads to hardware by design, I expect you could be a lot more efficient. $\endgroup$ Mar 15 '18 at 11:54

An ISA is an interface specification between the hardware and the software. It's a "stake in the ground" that allows the software engineers (sequential thinkers) and the hardware engineers (parallel thinkers) to communicate and cooperate effectively when working on an application.

Removing that stake by making the ISA variable would require that everyone involved be equally expert in both domains.

A fixed ISA is not that much of an impediment to optimization anyway. Look at x86 — over the decades in which it has been in existence, there have been implementations that

  • use multiple clocks to execute each instruction
  • execute one instruction per clock
  • execute multiple instructions per clock
  • $\begingroup$ The compiler takes care of most of the software, resulting in the IR. We now have a compiler backend in which we need to be compatible to the ISA. These are all non functional requirements, just the made up constrains by people making that stake. Then when during profiling we find out we need to offload something to hardware, we make an extension or co-processor or something, and then revisit the compiler backend or application software. It seemed kind of time inefficient and might not result in something close to an optimal solution. $\endgroup$ Mar 15 '18 at 16:23
  • $\begingroup$ Start by defining "optimal"! At the application level, there are too many dimensions to the problem (time, energy, area, etc.) and the answer may very well be data-dependent. This is far from being a solved problem. $\endgroup$
    – Dave Tweed
    Mar 15 '18 at 16:43
  • $\begingroup$ That is ofcourse very true, but once you start playing arround with partitioning the IR instructions into functional blocks, you can start giving values to configurations and start finding some good configurations. It's up to the software developer to provide test vectors for it's own program, he needs to do some profiling and testing anyways, that doesn't change a lot. I'm not realy asking how this all can be solved, that is probably a lifes works work, but more 'are there parties working on this, and if not, why'. $\endgroup$ Mar 15 '18 at 18:11
  • $\begingroup$ While this question would be on-topic on Computer Science, there isn't a lot of hardware design expertise there, so I don't think it's a better fit for this question. In any case, since the question has been asked here, you should migrate it only if it's off-topic here, never mind whether it might also be on-topic here. But if this question is off-topic here, then it's welcome on Computer Science. $\endgroup$ Mar 15 '18 at 20:09
  • $\begingroup$ @Gilles: Thanks for the feedback. Since the question is rather "too broad" for EE, I'm going to go ahead an migrate it. $\endgroup$
    – Dave Tweed
    Mar 15 '18 at 20:47

This is possible, but the gains might not be as substantial as one would hope for, except in special cases.

A "soft core" is where you use a FPGA to build a processor. So, you are talking about taking a program, selecting a custom processor architecture, building that processor architecture on a FPGA, and then compiling the program to that custom architecture so it will run on the "soft core".

The problem with this approach is that soft cores are generally significantly slower than a dedicated processor, potentially by an order of magnitude or so (or even more). It's unlikely that the customization of the soft core can make up for that performance gap. In particular, if you choose a "soft core" that is basically doing the same thing as an existing dedicated processor, then it's likely that your soft core will be far slower than the dedicated processor. So you have to hope that your program is doing something so special, that you can identify a custom processor architecture that is so different from existing general-purpose processors, that you can regain more than a 10x speedup. While it might be possible in some narrow cases, that's usually hard, for most programs.

Alternatively, there's a more direct way to use a FPGA. Rather than using the FPGA to build a soft core, then compile your program to run on that soft core, you could compile the program to run directly on the FPGA. Or, you can try to identify the performance-critical inner loops of your program and compile them into logic for the FPGA. This is known as reconfigurable computing, and there is lots of research and commercial work on that problem. I suggest reading up on reconfigurable computing, where you'll find lots of information about it. It is in some sense a "better" version of what you are asking about.

One limitation of reconfigurable computing is that FPGAs are significantly slower than dedicated processors, as FPGAs are typically built with a slower and older process, so you have to identify some task in the program where custom hardware is significantly faster than a general microprocessor so that you can make up for this gap. Some programs have a core inner loop that is amenable to such speedups with custom hardware. However, many end-user programs don't have any obvious way to get big speedups like that. So, this ends up being something that only yields speedups for a subset of programs. Also, to be interesting, this approach also needs to be faster than the alternatives. Right now the GPGPU is a competitor: many of the programs that see speedups with custom hardware, also see speedups when run on a GPGPU, so the benefits of reconfigurable computing over using an existing GPGPU might not be large enough to warrant the cost and complexity of reconfigurable computing, except in special cases.

But you can read the literature and learn a lot more about this topic, and gain a deeper understanding about where it is likely to be useful and where it is not.

  • $\begingroup$ Yeah, I was thinking about use cases where you need a bunch of control on your FPGA and some offloading. This is often done with a soft core, and a hardware software codesign, as this is 'easier' to integrate in your design than connecting the FPGA to an external CPU (is also often done). Picking a soft core is not a trivial task however. Reconfigurable Computing is a thing, yes, but I cannot find any tools or projects where the computing unit is generated from the aplication you want to run. Often this is configured 'by hand' through some kind of HDL. $\endgroup$ Mar 15 '18 at 22:03
  • $\begingroup$ Also, FPGAs by no means use 'old' processes. They are always one of the first to use the 'newest' process. A soft core will not perform that well on benchmarks as a external general purpose processor as it is configured hardware, not dedicated hardware. The terminals are still there loading the signal paths, and routing constraints are a lot more strict on FPGAs making high clock frequencies hard to achieve. $\endgroup$ Mar 15 '18 at 22:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.