Embecosm develops commercially robust open source compilers for a wide range of processors. By commercially robust, we mean compilers which reliably produce correct code which is fast and/or compact.

To achieve this robustness, we must thoroughly test and benchmark the compilers. This can be achieved by running on the target architecture's silicon. However we are often developing compilers pre-silicon, and so we must rely on processor models for testing. For functional testing we can use design models or instruction set simulators, although there is always the small risk that the design specification does not match the final implementation. However for benchmarking and sign-off testing, we must use the implementation, for which there are broadly three choices.

1. We can test against traditional event-driven simulation, but such simulators are not very fast, mostly closed source and are not easy to interface to from software environments.

2. We can use FPGA emulation, although not all designs work well in emulation, and large FPGAs can be expensive.

3. Finally, Verilator models are an attractive option, because they are cycle accurate, reasonably fast and easy to interface.

To test a compiler, the target needs more than the processor core. It has to be combined with memory in which to hold programs and data. And for all but the simplest processors its needs a debug unit, to allow the processor to be halted with its exterior state (registers, memory) in a consistent state.

Creating the target with memory and debug is often problematic. It is not the final chip, so has to be created just to allow the tool chain to be tested. X-Heep is the potential solution to this, allowing us to generate FPGA implementations or Verilator models with flexible memory and debug configurations. For this reason we chose X-Heep for testing the compilers for the OpenHW Group's CV32E40Pv2 processors.

In this talk, I'll take you through our experience with X-Heep and its use to generate FPGA bitstreams and Verilator models. I'll look at what worked well and what did not, and I'll present some suggestions on how X-Heep can be improved for the future.

See slides here