Automatic softcore configuration based on intermediate representation (IR) compiler output

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.